Merge tag 'qcom-drivers-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers
Qualcomm ARM Based Driver Updates for v5.4
* Add AOSS QMP support
* Various fixups for Qualcomm SCM
* Add socinfo driver
* Add SoC serial number attribute and associated APIs
* Add SM8150 and SC7180 support in Qualcomm SCM
* Fixup max processor count in SMEM
* tag 'qcom-drivers-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: aoss: Add AOSS QMP support
dt-bindings: soc: qcom: aoss: Add SM8150 and SC7180 support
dt-bindings: firmware: scm: Add SM8150 and SC7180 support
dt-bindings: firmware: scm: re-order compatible list
soc: qcom: smem: Update max processor count
soc: qcom: socinfo: Annotate switch cases with fall through
soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.
soc: qcom: socinfo: Expose image information
soc: qcom: socinfo: Expose custom attributes
soc: qcom: Add socinfo driver
base: soc: Export soc_device_register/unregister APIs
base: soc: Add serial_number attribute to soc
firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem()
firmware: qcom_scm: Fix some typos in docs and printks
firmware: qcom_scm: Use proper types for dma mappings
Lokesh Vutla [Tue, 27 Aug 2019 03:00:41 +0000 (20:00 -0700)]
soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access
TISCI protocol supports for enabling the device either with exclusive
permissions for the requesting host or with sharing across the hosts.
There are certain devices which are exclusive to Linux context and
there are certain devices that are shared across different host contexts.
So add support for getting this information from DT by increasing
the power-domain cells to 2.
For keeping the DT backward compatibility intact, defaulting the
device permissions to set the exclusive flag set. In this case the
power-domain-cells is 1.
Lokesh Vutla [Tue, 27 Aug 2019 03:00:40 +0000 (20:00 -0700)]
dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access
TISCI protocol supports for enabling the device either with exclusive
permissions for the requesting host or with sharing across the hosts.
There are certain devices which are exclusive to Linux context and
there are certain devices that are shared across different host contexts.
So add support for getting this information from DT by increasing
the power-domain cells to 2.
Lokesh Vutla [Tue, 27 Aug 2019 03:00:40 +0000 (20:00 -0700)]
firmware: ti_sci: Allow for device shared and exclusive requests
Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw. Current tisci
driver enables this flag for every device requests. But this may not
be true for all the devices. So provide a separate commands in driver
for exclusive and shared device requests.
The probe function is no longer __init, so anything it calls now
must also be available at runtime, as Kbuild points out when building
with clang-9:
WARNING: vmlinux.o(.text+0x6e7040): Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
The function weim_probe() references
the function __init imx_weim_gpr_setup().
This is often because weim_probe lacks a __init
annotation or the annotation of imx_weim_gpr_setup is wrong.
WARNING: vmlinux.o(.text+0x6e70f0): Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
The function weim_probe() references
the function __init weim_timing_setup().
This is often because weim_probe lacks a __init
annotation or the annotation of weim_timing_setup is wrong.
Remove the remaining __init markings that are now wrong.
Fixes: 4a92f07816ba ("bus: imx-weim: use module_platform_driver()") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Marek Behún [Thu, 22 Aug 2019 01:43:17 +0000 (03:43 +0200)]
firmware: Add Turris Mox rWTM firmware driver
This adds a driver to communicate with the firmware running on the
secure processor of the Turris Mox router, enabling the kernel to
retrieve true random numbers from the Entropy Bit Generator and to read
some information burned into eFuses when device was manufactured:
and to
sign messages with the ECDSA private key burned into each Turris Mox
device when manufacturing.
This also adds support to read other information burned into eFuses:
- serial number
- board version
- MAC addresses
- RAM size
- ECDSA public key (this is not read directly from eFuses, rather it
is computed by the firmware as pair to the burned private key)
The source code of the firmware is open source and can be found at
https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi
The firmware is also able to, on demand, sign messages with the burned
ECDSA private key, but since Linux's akcipher API is not yet stable
(and therefore not exposed to userspace via netlink), this functionality
is not supported yet.
Colin Ian King [Thu, 22 Aug 2019 01:03:50 +0000 (03:03 +0200)]
bus: moxtet: fix unsigned comparison to less than zero
Currently the size_t variable res is being checked for
an error failure however the unsigned variable is never
less than zero so this test is always false. Fix this by
making variable res ssize_t
Link: https://lore.kernel.org/r/20190822010351.15660-2-marek.behun@nic.cz
Addresses-Coverity: ("Unsigned compared against 0") Fixes: 5bc7f990cd98 ("bus: Add support for Moxtet bus") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'davinci-for-v5.4/fbdev' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/drivers
This converts the da8xx fbdev driver to use GPIO backlight device
and regulator devices. This will finally help get rid of legacy
GPIO API calls and simplify DaVinci GPIO driver.
* tag 'davinci-for-v5.4/fbdev' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
fbdev: da8xx: use resource management for dma
fbdev: da8xx-fb: drop a redundant if
fbdev: da8xx-fb: use devm_platform_ioremap_resource()
fbdev: da8xx: remove panel_power_ctrl() callback from platform data
ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc
fbdev: da8xx: add support for a regulator
ARM: davinci: da850-evm: model the backlight GPIO as an actual device
Merge tag 'imx-drivers-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/drivers
i.MX drivers update for 5.4:
- A series from Anson Huang to add UID support for i.MX8 SoC and SCU
drivers.
- A series from Daniel Baluta to add DSP IPC driver for communication
between host AP (Linux) and the firmware running on DSP embedded in
i.MX8 SoCs.
- A small fix for GPCv2 error code printing.
- Switch from module_platform_driver_probe() to module_platform_driver()
for imx-weim driver, as we need the driver to probe again when device
is present later.
- Add optional burst clock mode support for imx-weim driver.
* tag 'imx-drivers-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
soc: imx: gpcv2: Print the correct error code
bus: imx-weim: use module_platform_driver()
firmware: imx: Add DSP IPC protocol interface
soc: imx-scu: Add SoC UID(unique identifier) support
bus: imx-weim: optionally enable burst clock mode
firmware: imx: scu-pd: Add IRQSTR_DSP PD range
firmware: imx: scu-pd: Add mu13 b side PD range
firmware: imx: scu-pd: Rename mu PD range to mu_a
soc: imx8: Add i.MX8MM UID(unique identifier) support
soc: imx8: Add i.MX8MQ UID(unique identifier) support
Merge tag 'amlogic-drivers-2.1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/drivers
soc: amlogic: updates for v5.4 (round 2)
- add power domain controller
* tag 'amlogic-drivers-2.1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
dt-bindings: power: add Amlogic Everything-Else power domains bindings
soc: amlogic: Add support for Everything-Else power domains controller
Merge tag 'v5.3-next-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/drivers
cmdq helper:
reoder function parameter and change size of the parameters
* tag 'v5.3-next-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
soc: mediatek: cmdq: change the type of input parameter
soc: mediatek: cmdq: reorder the parameter
Merge tag 'sunxi-drivers-for-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/drivers
Allwinner drivers patches for 5.4
One driver to remove a redundant error message in the Allwinner RSB
driver.
* tag 'sunxi-drivers-for-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
bus: sunxi-rsb: Remove dev_err() usage after platform_get_irq()
Merge tag 'renesas-drivers-for-v5.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers
Renesas driver updates for v5.4 (take two)
- Improve "always-on" PM Domain handling on SH/R-Mobile SoCs,
- Automatic errata selection for Cortex-A7/A9,
- Small fixes and improvements.
* tag 'renesas-drivers-for-v5.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
soc: renesas: rmobile-sysc: Set GENPD_FLAG_ALWAYS_ON for always-on domain
soc: renesas: rcar-sysc: Eliminate local variable gov
soc: renesas: rcar-sysc: Add goto to of_node_put() before return
Merge tag 'samsung-drivers-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/drivers
Samsung soc drivers changes for v5.4
Add Exynos Chipid driver for identification of product IDs and SoC
revisions. The driver also exposes chipid regmap, later to be used by
Exynos Adaptive Supply Voltage driver (adjusting voltages to different
revisions of same SoC).
* tag 'samsung-drivers-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
soc: samsung: chipid: Convert exynos-chipid driver to use the regmap API
soc: samsung: Add exynos chipid driver support
Neil Armstrong [Fri, 23 Aug 2019 09:04:15 +0000 (11:04 +0200)]
soc: amlogic: Add support for Everything-Else power domains controller
Add support for the General Purpose Amlogic Everything-Else Power controller,
with the first support for G12A and SM1 SoCs dedicated to the VPU, PCIe,
USB, NNA, GE2D and Ethernet Power Domains.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The driver data is always set in probe. The remove() callback won't be
called if probe failed which is the only way for it to be NULL. Remove
the redundant if.
We want to remove the hacky platform data callback for power control.
Add a regulator to the driver data and enable/disable it next to
the current panel_power_ctrl() calls. We will use it in subsequent
patch on da850-evm.
ARM: davinci: da850-evm: model the backlight GPIO as an actual device
Instead of enabling the panel backlight in a callback defined in board
file using deprecated legacy GPIO API calls, model the line as a GPIO
backlight device.
Bibby Hsieh [Tue, 20 Aug 2019 08:49:28 +0000 (16:49 +0800)]
soc: mediatek: cmdq: change the type of input parameter
According to the cmdq hardware design, the subsys is u8,
the offset is u16 and the event id is u16.
This patch changes the type of subsys, offset and event id
to the correct type.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
ARM Erratum 754322 affects Cortex-A9 revisions r2p* and r3p*.
Automatically enable support code to mitigate the erratum when compiling
a kernel for any of the affected Renesas SoCs:
- RZ/A1: r3p0,
- R-Mobile A1: r2p4,
- R-Car M1A: r2p2-00rel0,
- R-Car H1: r3p0,
- SH-Mobile AG5: r2p2.
EMMA Mobile EV2 (r1p3) and RZ/A2 (r4p1) are not affected.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
ARM Erratum 814220 affects Cortex-A7 revisions r0p2-r0p5.
Automatically enable support code to mitigate the erratum when compiling
a kernel for any of the affected Renesas SoCs:
- R-Mobile APE6: r0p2,
- RZ/G1E: r0p5,
- RZ/G1C: r0p5,
- R-Car H2: r0p3,
- R-Car E2: r0p5,
- RZ/N1: r0p5.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
soc: renesas: rmobile-sysc: Set GENPD_FLAG_ALWAYS_ON for always-on domain
Currently the R-Mobile "always-on" PM Domain is implemented by returning
-EBUSY from the generic_pm_domain.power_off() callback, and doing
nothing in the generic_pm_domain.power_on() callback. However, this
means the PM Domain core code is not aware of the semantics of this
special domain, leading to boot warnings like the following on
SH/R-Mobile SoCs:
sh_cmt e6130000.timer: PM domain c5 will not be powered off
Fix this by making the always-on nature of the domain explicit instead,
by setting the GENPD_FLAG_ALWAYS_ON flag. This removes the need for the
domain to provide power control callbacks.
soc: samsung: chipid: Remove the regmap lookup error log
In commit 40d8aff614f7 ("soc: samsung: chipid: Convert exynos-chipid
driver to use the regmap API") of_find_compatible_node() call was
substituted with syscon_regmap_lookup_by_compatible() but also an error
log was added for case where lookup fails. On multiplatform the lookup
will always fail on any non-samsung device so the log is incorrect.
Remove the error log and just return an error code from
syscon_regmap_lookup_by_compatible() which internally calls
of_find_compatible_node().
Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Nishka Dasgupta [Mon, 19 Aug 2019 07:27:06 +0000 (12:57 +0530)]
soc: amlogic: meson-gx-socinfo: Add of_node_put() before return
The variable np in function meson_gx_socinfo_init takes the return value
of of_find_compatible_node, which gets a node but does not put it. If
this node is not put it may cause a memory leak. Hence put np after its
usefulness has been exhausted.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Fixes: a9daaba2965e ("soc: Add Amlogic SoC Information driver") Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add the Amlogic SM1 Compatible for the clk-measurer IP.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Colin Ian King [Fri, 16 Aug 2019 22:21:51 +0000 (23:21 +0100)]
soc: samsung: chipid: Fix memory leak in error path
Currently when the call to product_id_to_soc_id fails there
is a memory leak of soc_dev_attr->revision and soc_dev_attr
on the error return path. Fix this by adding a common error
return path that frees there obects and use this for two
error return paths.
Addresses-Coverity: ("Resource leak") Fixes: 3253b7b7cd44 ("soc: samsung: Add exynos chipid driver support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
soc: renesas: rcar-sysc: Eliminate local variable gov
As of commit 980532a5dda319ee ("soc: renesas: rcar-sysc: Use
GENPD_FLAG_ALWAYS_ON"), the local variable "gov" is assigned just once,
so it can be eliminated.
Nishka Dasgupta [Thu, 15 Aug 2019 06:13:54 +0000 (11:43 +0530)]
soc: renesas: rcar-sysc: Add goto to of_node_put() before return
The local variable np in function rcar_sysc_pd_init takes the return
value of of_find_matching_node_and_match(), which gets a node but does
not put it. If np is not put before the function returns, it may cause
a memory leak.
Hence, remove the return statement that does not immediately follow a
putting of np. Replace it with a goto pointing to a pre-existing label
that first puts np and then returns the required value.
Issue found with Coccinelle.
Fixes: afa6f53df6052968 ("soc: renesas: rcar-sysc: Add support for fixing up power area tables") Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Sascha Hauer [Wed, 14 Aug 2019 08:23:16 +0000 (10:23 +0200)]
bus: imx-weim: use module_platform_driver()
Switch from module_platform_driver_probe() to module_platform_driver().
The former is not suitable for booting with device tree as the driver
will be registered before the device and thus won't be probed again
when the device is present.
Starting with commit 72175d4ea4c4 ("driver core: Make driver core own
stateful device links") stateful device links are owned by the driver
core and should not be explicitly removed on device unbind. Delete all
device_link_del appearances from the fsl-mc bus.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-By: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Starting with commit 72175d4ea4c4 ("driver core: Make driver core
own stateful device links") stateful device links are owned by the
driver core and should not be explicitly removed on device unbind.
Delete all device_link_remove appearances from the dpio driver.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Roy Pledge [Thu, 1 Aug 2019 20:17:05 +0000 (20:17 +0000)]
soc/fsl/qbman: Update device tree with reserved memory
When using the reserved memory node in the device tree there are
two options - dynamic or static. If a dynamic allocation was
selected (where the kernel selects the address for the allocation)
convert it to a static allocation by inserting the reg property.
This will ensure the same memory is reused after a kexec()
Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Roy Pledge [Thu, 1 Aug 2019 20:17:03 +0000 (20:17 +0000)]
soc/fsl/qbman: Fixup qman_shutdown_fq()
When shutting down a FQ on a dedicated channel only the
SW portal associated with that channel can dequeue from it.
Make sure the correct portal is use.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Roy Pledge [Thu, 1 Aug 2019 20:16:59 +0000 (20:16 +0000)]
soc/fsl/qbman: Fix drain_mr_fqni()
The drain_mr_fqni() function may be called fron uninterruptable
context so convert the msleep() to an mdelay(). Also ensure that
the valid bit is updated while polling.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Roy Pledge [Thu, 1 Aug 2019 20:16:57 +0000 (20:16 +0000)]
soc/fsl/qbman: Cleanup QMan queues if device was already initialized
If the QMan device was previously initialized make sure all the
frame queues are out of service once all the portals are probed.
This handles the case where the kernel is restarted without the
SoC being reset (kexec for example)
Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Roy Pledge [Thu, 1 Aug 2019 20:16:55 +0000 (20:16 +0000)]
soc/fsl/qbman: Cleanup buffer pools if BMan was initialized prior to bootup
Clean the BMan buffer pools if the device had been initialized
previously. This will ensure a consistent state if the kernel
was soft restarted (kexec for example)
Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Stephen Boyd [Tue, 30 Jul 2019 21:36:06 +0000 (14:36 -0700)]
soc: fsl: qbman: Remove dev_err() usage after platform_get_irq()
We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.
While we're here, remove braces on if statements that only have one
statement (manually).
Cc: Thierry Reding <treding@nvidia.com> Cc: Li Yang <leoyang.li@nxp.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Pankaj Dubey [Tue, 13 Aug 2019 15:08:19 +0000 (17:08 +0200)]
soc: samsung: Add exynos chipid driver support
Exynos SoCs have Chipid, for identification of product IDs and SoC
revisions. This patch intends to provide initialization code for all
these functionalities, at the same time it provides some sysfs entries
for accessing these information to user-space.
This driver uses existing binding for exynos-chipid.
Changes by Bartlomiej:
- fixed return values on errors
- removed bogus kfree_const()
- added missing Exynos4210 EVT0 id
- converted code to use EXYNOS_MASK define
- fixed np use after of_node_put()
- fixed too early use of dev_info()
- made driver fail for unknown SoC-s
- added SPDX tag
- updated Copyrights
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
[m.szyprowski: for suggestion and code snippet of product_id_to_soc_id] Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
[s.nawrocki: updated copyright date, removed uneeded headers inclusion] Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Arnd Bergmann [Wed, 14 Aug 2019 18:46:37 +0000 (20:46 +0200)]
Merge tag 'scmi-updates-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers
ARM SCMI updates/fixes for v5.4
Handful of fixes/updates including:
1. SCMI v2.0(recently released) support for:
- Performance protocol fast channels
- Reset Management Protocol
2. SCMI infrastructure/core support for recieve(Rx) channels,
asynchronous commands and delayed response
3. Usage of asynchronous commands for clock rate setting and sensor
reading based on the attributes read from the firmware
4. Miscellaneous cleanups(typos, naming alignment with specification,
and SPDX License identifier)
5. Couple of fixes: removal of extra check for invalid length and
additional check to ensure platform/firmware has released shared
memory before using it in OSPM
* tag 'scmi-updates-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (22 commits)
reset: Add support for resets provided by SCMI
firmware: arm_scmi: Add RESET protocol in SCMI v2.0
dt-bindings: arm: Extend SCMI to support new reset protocol
firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors
firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible
firmware: arm_scmi: Drop config flag in clk_ops->rate_set
firmware: arm_scmi: Add asynchronous sensor read if it supports
firmware: arm_scmi: Drop async flag in sensor_ops->reading_get
firmware: arm_scmi: Add support for asynchronous commands and delayed response
firmware: arm_scmi: Add mechanism to unpack message headers
firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx
firmware: arm_scmi: Add receive channel support for notifications
firmware: arm_scmi: Segregate tx channel handling and prepare to add rx
firmware: arm_scmi: Reorder some functions to avoid forward declarations
firmware: arm_scmi: Check if platform has released shmem before using
firmware: arm_scmi: Use the term 'message' instead of 'command'
firmware: arm_scmi: Fix few trivial typos in comments
firmware: arm_scmi: Remove extra check for invalid length message responses
...
Marek Behún [Mon, 12 Aug 2019 16:11:17 +0000 (18:11 +0200)]
drivers: gpio: Add support for GPIOs over Moxtet bus
This adds support for interpreting the input and output bits of one
device on Moxtet bus as GPIOs.
This is needed for example by the SFP cage module of Turris Mox.
Marek Behún [Mon, 12 Aug 2019 16:11:15 +0000 (18:11 +0200)]
dt-bindings: bus: Document moxtet bus binding
This adds device tree binding documentation for the Moxtet bus, a bus
via which the different modules connected to the Turris Mox router can
be configured.
Marek Behún [Mon, 12 Aug 2019 16:11:14 +0000 (18:11 +0200)]
bus: Add support for Moxtet bus
On the Turris Mox router different modules can be connected to the main
CPU board: currently a module with a SFP cage, a module with MiniPCIe
connector, a PCIe pass-through MiniPCIe connector module, a 4-port
switch module, an 8-port switch module, and a 4-port USB3 module.
For example:
[CPU]-[PCIe-pass-through]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]
Each of this modules has an input and output shift register, and these
are connected via SPI to the CPU board.
Via SPI we are able to discover which modules are connected, in which
order, and we can also read some information about the modules (eg.
their interrupt status), and configure them.
From each module 8 bits can be read (of which low 4 bits identify the
module) and 8 bits can be written.
For example from the module with a SFP cage we can read the LOS,
TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and
RATE-SELECT signals.
This driver creates a new bus type, called "moxtet". For each Mox module
it finds via SPI, it creates a new device on the moxtet bus so that
drivers can be written for them.
It also implements a virtual interrupt controller for the modules which
send their interrupt status over the SPI shift register. These modules
do this in addition to sending their interrupt status via the shared
interrupt line. When the shared interrupt is triggered, we read from the
shift register and handle IRQs for all devices which are in interrupt.
The topology of how Mox modules are connected can then be read by
listing /sys/bus/moxtet/devices.
Arnd Bergmann [Wed, 14 Aug 2019 13:26:43 +0000 (15:26 +0200)]
Merge tag 'renesas-drivers-for-v5.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers
Renesas driver updates for v5.4
- Fix a flexible array member definition in the R-Car SYSC driver.
* tag 'renesas-drivers-for-v5.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: rcar-sysc: Use [] to denote a flexible array member
Arnd Bergmann [Tue, 13 Aug 2019 12:29:29 +0000 (14:29 +0200)]
Merge tag 'reset-for-v5.4' of git://git.pengutronix.de/git/pza/linux into arm/drivers
Reset controller changes for v5.4
This tag adds support for the i.MX8MM SRC via the reset-imx7 driver
and for DesignWare IP reset controllers via the reset-simple driver.
A typo in the i.MX8MQ DSI reset definitions is fixed, and the Meson
reset driver and binding headers are updated to SPDX license
identifiers.
* tag 'reset-for-v5.4' of git://git.pengutronix.de/git/pza/linux:
reset: Add DesignWare IP support to simple reset
dt-bindings: Document the DesignWare IP reset bindings
dt-bindings: reset: amlogic,meson8b-reset: update with SPDX Licence identifier
dt-bindings: reset: amlogic,meson-gxbb-reset: update with SPDX Licence identifier
reset: reset-meson: update with SPDX Licence identifier
dt-bindings: reset: Fix typo in imx8mq resets
dt-bindings: reset: imx7: Add support for i.MX8MM
Daniel Baluta [Thu, 1 Aug 2019 09:56:36 +0000 (12:56 +0300)]
firmware: imx: Add DSP IPC protocol interface
Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
the Tensilica HiFi4 DSP for advanced pre- and post-audio
processing.
The communication between Host CPU and DSP firmware is
taking place using a shared memory area for message passing
and a dedicated Messaging Unit for notifications.
DSP IPC protocol offers a doorbell interface using
imx-mailbox API.
We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
request-reply protocol.
Connection 1 (txdb1, rxdb1):
- DSP writes a message to shared memory [SHMEM]
- DSP sends a request [MU]
- Host handles request [SHMEM]
- Host sends reply [MU]
The protocol interface will be used by a Host client to
communicate with the DSP. First client will be the i.MX8
part from Sound Open Firmware infrastructure.
The protocol offers the following interface:
On Tx:
- imx_dsp_ring_doorbell, will be called to notify the DSP
that it needs to handle a request.
On Rx:
- clients need to provide two callbacks:
.handle_reply
.handle_request
- the callbacks will be used by the protocol on
notification arrival from DSP.
On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control. System Control and Management Interface(SCMI) Message Protocol
is defined for the communication between the Application Cores(AP)
and the SCP.
Adds support for the resets provided using SCMI protocol for performing
reset management of various devices present on the SoC. Various reset
functionalities are achieved by the means of different ARM SCMI device
operations provided by the ARM SCMI framework.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Add RESET protocol in SCMI v2.0
SCMIv2.0 adds a new Reset Management Protocol to manage various reset
states a given device or domain can enter. Device(s) that can be
collectively reset through a common reset signal constitute a reset
domain for the firmware.
A reset domain can be reset autonomously or explicitly through assertion
and de-assertion of the signal. When autonomous reset is chosen, the
firmware is responsible for taking the necessary steps to reset the
domain and to subsequently bring it out of reset. When explicit reset is
chosen, the caller has to specifically assert and then de-assert the
reset signal by issuing two separate RESET commands.
Add the basic SCMI reset infrastructure that can be used by Linux
reset controller driver.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
dt-bindings: arm: Extend SCMI to support new reset protocol
SCMIv2.0 adds a new Reset Management Protocol to manage various reset
states a given device or domain can enter. Extend the existing SCMI
bindings to add reset protocol support by re-using the reset bindings
for both reset providers and consumers.
Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
SCMI v2.0 adds support for "FastChannel" which do not use a message
header as they are specialized for a single message.
Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET}
commands are supported over fastchannels. As they are optional, they
need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command.
Further {LIMIT,LEVEL}_SET commands can have optional doorbell support.
Add support for making use of these fastchannels.
Cc: Ionela Voinescu <Ionela.Voinescu@arm.com> Cc: Chris Redpath <Chris.Redpath@arm.com> Cc: Quentin Perret <Quentin.Perret@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
SCMI v2.0 adds support for "FastChannel", a lightweight unidirectional
channel that is dedicated to a single SCMI message type for controlling
a specific platform resource. They do not use a message header as they
are specialized for a single message.
Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET}
commands are supported over fastchannels. As they are optional, they
need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command.
Further {LIMIT,LEVEL}_SET commands can have optional doorbell support.
Add support for discovery of these fastchannels.
Cc: Ionela Voinescu <Ionela.Voinescu@arm.com> Cc: Chris Redpath <Chris.Redpath@arm.com> Cc: Quentin Perret <Quentin.Perret@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Sudeep Holla [Wed, 7 Aug 2019 12:46:27 +0000 (13:46 +0100)]
firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors
Instead of type-casting the {tx,rx}.buf all over the place while
accessing them to read/write __le{32,64} from/to the firmware, let's
use the existing {get,put}_unaligned_le{32,64} accessors to hide all
the type cast ugliness.
Suggested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum
number of pending asynchronous clock rate changes supported by the
platform. If it's non-zero, then we should be able to use asynchronous
clock rate set for any clocks until the maximum limit is reached.
Tracking the current count of pending asynchronous clock set rate
requests, we can decide if the incoming/new request for clock set rate
can be handled asynchronously or not until the maximum limit is
reached.
Cc: linux-clk@vger.kernel.org Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Drop config flag in clk_ops->rate_set
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum
number of pending asynchronous clock rate changes supported by the
platform. If it's non-zero, then we should be able to use asynchronous
clock rate set for any clocks until the maximum limit is reached.
In order to add that support, let's drop the config flag passed to
clk_ops->rate_set and handle the asynchronous requests dynamically.
Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Add asynchronous sensor read if it supports
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor
supports asynchronous read. We can read that flag and use asynchronous
reads for any sensors with that attribute set.
Let's use the new scmi_do_xfer_with_response to support asynchronous
sensor reads.
firmware: arm_scmi: Drop async flag in sensor_ops->reading_get
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor
supports asynchronous read. Ideally we should be able to read that flag
and use asynchronous reads for any sensors with that attribute set.
In order to add that support, let's drop the async flag passed to
sensor_ops->reading_get and dynamically switch between sync and async
flags based on the attributes as provided by the firmware.
firmware: arm_scmi: Add support for asynchronous commands and delayed response
Messages that are sent to platform, also known as commands and can be:
1. Synchronous commands that block the channel until the requested work
has been completed. The platform responds to these commands over the
same channel and hence can't be used to send another command until the
previous command has completed.
2. Asynchronous commands on the other hand, the platform schedules the
requested work to complete later in time and returns almost immediately
freeing the channel for new commands. The response indicates the success
or failure in the ability to schedule the requested work. When the work
has completed, the platform sends an additional delayed response message.
Using the same transmit buffer used for sending the asynchronous command
even for the delayed response corresponding to it simplifies handling of
the delayed response. It's the caller of asynchronous command that is
responsible for allocating the completion flag that scmi driver can
complete to indicate the arrival of delayed response.
firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx
Currently we pre-allocate transmit buffers only and use the first free
slot in that pre-allocated buffer for transmitting any new message that
are generally originated from OS to the platform firmware.
Notifications or the delayed responses on the other hand are originated
from the platform firmware and consumes by the OS. It's better to have
separate and dedicated pre-allocated buffers to handle the notifications.
We can still use the transmit buffers for the delayed responses.
In addition, let's prepare existing scmi_xfer_{get,put} for acquiring
and releasing a slot to identify the right(tx/rx) buffers.
firmware: arm_scmi: Add receive channel support for notifications
With scmi_mbox_chan_setup enabled to identify and setup both Tx and Rx,
let's consolidate setting up of both the channels under the function
scmi_mbox_txrx_setup.
Since some platforms may opt not to support notifications or delayed
response, they may not need support for Rx. Hence Rx is optional and
failure of setting one up is not considered fatal.
firmware: arm_scmi: Segregate tx channel handling and prepare to add rx
The transmit(Tx) channels are specified as the first entry and the
receive(Rx) channels are the second entry as per the device tree
bindings. Since we currently just support Tx, index 0 is hardcoded at
all required callsites.
In order to prepare for adding Rx support, let's remove those hardcoded
index and add boolean parameter to identify Tx/Rx channels when setting
them up.
firmware: arm_scmi: Reorder some functions to avoid forward declarations
Re-shuffling few functions to keep definitions and their usages close.
This is also needed to avoid too many unnecessary forward declarations
while adding new features(delayed response and notifications).
Keeping this separate to avoid mixing up of these trivial change that
doesn't affect functionality into the ones that does.
firmware: arm_scmi: Check if platform has released shmem before using
Sometimes platfom may take too long to respond to the command and OS
might timeout before platform transfer the ownership of the shared
memory region to the OS with the response.
Since the mailbox channel associated with the channel is freed and new
commands are dispatch on the same channel, OS needs to wait until it
gets back the ownership. If not, either OS may end up overwriting the
platform response for the last command(which is fine as OS timed out
that command) or platform might overwrite the payload for the next
command with the response for the old.
The latter is problematic as platform may end up interpretting the
response as the payload. In order to avoid such race, let's wait until
the OS gets back the ownership before we prepare the shared memory with
the payload for the next command.
Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Use the term 'message' instead of 'command'
In preparation to adding support for other two types of messages that
SCMI specification mentions, let's replace the term 'command' with the
correct term 'message'.
As per the specification the messages are of 3 types:
commands(synchronous or asynchronous), delayed responses and notifications.
firmware: arm_scmi: Remove extra check for invalid length message responses
scmi_xfer_get_init ensures both transmit and receive buffer lengths are
within the maximum limits. If receive buffer length is not supplied by
the caller, it's set to the maximum limit value. Receive buffer length
is never modified after that. So there's no need for the extra check
when receive transmit completion for a command essage.
Further, if the response header length is greater than the prescribed
receive buffer length, the response buffer is truncated to the latter.
Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
projects / linux.git / log