* [PATCH v3] coresight: documentation: update sysfs section
From: Kim Phillips @ 2018-05-14 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a09cbbb5-0237-31f5-dc81-d816c9ec26c5@infradead.org>
- Align and show updated ls devices output from the TC2, based on
current driver
- Provide an example from an ETMv4 based system (Juno)
- Reflect changes to the way the RAM write pointer is accessed since
it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
management entries").
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
v3: address Randy Dunlap's showns->shown, corrected - and + line merging
v2: address Mathieu's comment about clarifying the sinks on the Juno
vs. TC2 platforms.
Documentation/trace/coresight.txt | 43 +++++++++++++++++++------------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..15d2a0f1e1b8 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -141,13 +141,25 @@ register the device with the core framework. The unregister function takes
a reference to a "struct coresight_device", obtained at registration time.
If everything goes well during the registration process the new devices will
-show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
+show up under /sys/bus/coresight/devices, as shown here for a TC2 platform:
root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:~#
+and here for a Juno platform:
+
+root at juno:~# ls /sys/bus/coresight/devices/
+20010000.etf 20120000.replicator 22040000.etm 230c0000.funnel
+20030000.tpiu 20130000.funnel 220c0000.funnel 23140000.etm
+20040000.funnel 20140000.etf 22140000.etm 23240000.etm
+20070000.etr 20150000.funnel 23040000.etm 23340000.etm
+root at juno:~#
+
+Note that on Juno users can select the ETF, ETR and TPIU as a sink target while
+on TC2, the ETB and TPIU can be selected.
+
The functions take a "struct coresight_device", which looks like this:
struct coresight_desc {
@@ -193,16 +205,16 @@ the information carried in "THIS_MODULE".
How to use the tracer modules
-----------------------------
-Before trace collection can start, a coresight sink needs to be identify.
+Before trace collection can start, a coresight sink needs to be identified.
There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
class will have an "active" entry in sysfs:
root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
+enable_sink mgmt power subsystem trigger_cntr uevent
root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
1
@@ -216,16 +228,13 @@ trigger a trace capture:
root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+
+Observe the write pointer moving:
+
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x1a8
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x19a6
Trace collection is stopped the same way:
--
2.17.0
^ permalink raw reply related
* [PATCH v6 04/11] firmware: xilinx: Add query data API
From: Jolly Shah @ 2018-05-14 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <85f8f8c5-a177-dad8-e095-a9dd1c513e8d@arm.com>
HI Sudeep,
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Thursday, May 10, 2018 7:12 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; mturquette at baylibre.com;
> sboyd at codeaurora.org; michal.simek at xilinx.com; robh+dt at kernel.org;
> mark.rutland at arm.com; linux-clk at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com>
> Subject: Re: [PATCH v6 04/11] firmware: xilinx: Add query data API
>
>
>
> On 10/04/18 20:38, Jolly Shah wrote:
> > From: Rajan Vaja <rajanv@xilinx.com>
> >
> > Add ZynqMP firmware query data API to query platform specific
> > information(clocks, pins) from firmware.
> >
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > ---
> > drivers/firmware/xilinx/zynqmp.c | 14 ++++++++++++++
> > include/linux/firmware/xlnx-zynqmp.h | 20 ++++++++++++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > b/drivers/firmware/xilinx/zynqmp.c
> > index 44b43fa..ef09c44 100644
> > --- a/drivers/firmware/xilinx/zynqmp.c
> > +++ b/drivers/firmware/xilinx/zynqmp.c
> > @@ -258,9 +258,23 @@ static int zynqmp_pm_ioctl(u32 node_id, u32
> ioctl_id, u32 arg1, u32 arg2,
> > arg1, arg2, out);
> > }
> >
> > +/**
> > + * zynqmp_pm_query_data() - Get query data from firmware
> > + * @qdata: Variable to the zynqmp_pm_query_data structure
> > + * @out: Returned output value
> > + *
> > + * Return: Returns status, either success or error+reason */ static
> > +int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata, u32 *out)
> > +{
> > + return zynqmp_pm_invoke_fn(PM_QUERY_DATA, qdata.qid,
> qdata.arg1,
> > + qdata.arg2, qdata.arg3, out);
> > +}
> > +
> > static const struct zynqmp_eemi_ops eemi_ops = {
> > .get_api_version = zynqmp_pm_get_api_version,
> > .ioctl = zynqmp_pm_ioctl,
> > + .query_data = zynqmp_pm_query_data,
>
> Can you give more insight into this ? How will be this used ?
> How this aligns with data we get from DT ? I am just trying to understand how is
> this information split between this API and DT for example.
>
> --
> Regards,
> Sudeep
This API is used to get clock information from firmware and register clocks accordingly in driver. In our case, firmware maintains database of all clocks available on chip. DT will provide information for off chip reference clocks only.
This is to avoid duplication of clocks data in DT and firmware both as firmware anyways need clock data to manage them.
Thanks,
Jolly Shah
^ permalink raw reply
* [PATCH v6 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
From: Jolly Shah @ 2018-05-14 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c351b9a3-5f26-7202-7171-0dcc7adef7c0@arm.com>
Hi Sudeep,
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Thursday, May 10, 2018 7:09 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; mturquette at baylibre.com;
> sboyd at codeaurora.org; michal.simek at xilinx.com; robh+dt at kernel.org;
> mark.rutland at arm.com; linux-clk at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com>
> Subject: Re: [PATCH v6 03/11] firmware: xilinx: Add zynqmp IOCTL API for device
> control
>
>
>
> On 10/04/18 20:38, Jolly Shah wrote:
> > From: Rajan Vaja <rajanv@xilinx.com>
> >
> > Add ZynqMP firmware IOCTL API to control and configure devices like
> > PLLs, SD, Gem, etc.
> >
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > ---
> > drivers/firmware/xilinx/zynqmp.c | 20 ++++++++++++++++++++
> > include/linux/firmware/xlnx-zynqmp.h | 2 ++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > b/drivers/firmware/xilinx/zynqmp.c
> > index 490561a..44b43fa 100644
> > --- a/drivers/firmware/xilinx/zynqmp.c
> > +++ b/drivers/firmware/xilinx/zynqmp.c
> > @@ -239,8 +239,28 @@ static int get_set_conduit_method(struct
> device_node *np)
> > return 0;
> > }
> >
> > +/**
> > + * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs
> > + * @node_id: Node ID of the device
> > + * @ioctl_id: ID of the requested IOCTL
> > + * @arg1: Argument 1 to requested IOCTL call
> > + * @arg2: Argument 2 to requested IOCTL call
> > + * @out: Returned output value
> > + *
> > + * This function calls IOCTL to firmware for device control and configuration.
> > + *
> > + * Return: Returns status, either success or error+reason */ static
> > +int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
> > + u32 *out)
> > +{
> > + return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id,
> > + arg1, arg2, out);
> > +}
> > +
> > static const struct zynqmp_eemi_ops eemi_ops = {
> > .get_api_version = zynqmp_pm_get_api_version,
> > + .ioctl = zynqmp_pm_ioctl,
> > };
> >
> > /**
> > diff --git a/include/linux/firmware/xlnx-zynqmp.h
> > b/include/linux/firmware/xlnx-zynqmp.h
> > index cb63bed..2eec6e7 100644
> > --- a/include/linux/firmware/xlnx-zynqmp.h
> > +++ b/include/linux/firmware/xlnx-zynqmp.h
> > @@ -34,6 +34,7 @@
> >
> > enum pm_api_id {
> > PM_GET_API_VERSION = 1,
> > + PM_IOCTL = 34,
>
> I am not for this API. IIUC there are more fined grained well defined APIs(if I am
> not wrong from enum 2 upto 33). This is open ended API which allows user to do
> whatever setting it needs. And that defeats the purpose of other APIs.
>
> I will look through the series for the usage of this to understand this better, but I
> am guessing how it can be (ab)used.
>
> --
> Regards,
> Sudeep
There are well defined APIs for general clock controls. Ioctl is for some specific operations which may not apply to all platforms.
For clock driver, ioctl is used to get/set Pll fraction/integer mode and data.
Thanks,
Jolly Shah
^ permalink raw reply
* [PATCH RESEND net-next v2 0/8] net: stmmac: dwmac-sun8i: Support R40
From: David Miller @ 2018-05-14 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
From: Chen-Yu Tsai <wens@csie.org>
Date: Mon, 14 May 2018 03:14:17 +0800
> This is a resend of the patches for net-next split out from my R40
> Ethernet support v2 series, as requested by David Miller. The arm-soc
> bits will follow, once I rework the A64 system controller compatible.
Series applied, but please continue to follow-up with Andrew Lunn about
how best to handle these RX and TX delays.
Thank you.
^ permalink raw reply
* [PATCH v6 02/11] firmware: xilinx: Add Zynqmp firmware driver
From: Jolly Shah @ 2018-05-14 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9cbfb3cd-daa3-f145-c6f2-f15f61d1bea0@arm.com>
Hi Sudeep,
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Thursday, May 10, 2018 7:05 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; mturquette at baylibre.com;
> sboyd at codeaurora.org; michal.simek at xilinx.com; robh+dt at kernel.org;
> mark.rutland at arm.com; linux-clk at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com>
> Subject: Re: [PATCH v6 02/11] firmware: xilinx: Add Zynqmp firmware driver
>
>
>
> On 10/04/18 20:38, Jolly Shah wrote:
> > From: Rajan Vaja <rajanv@xilinx.com>
> >
> > This patch is adding communication layer with firmware.
> > Firmware driver provides an interface to firmware APIs.
> > Interface APIs can be used by any driver to communicate to
> > PMUFW(Platform Management Unit). All requests go through ATF.
> >
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > ---
>
> [...]
>
> > +
> > +/**
> > + * get_set_conduit_method() - Choose SMC or HVC based communication
> > + * @np: Pointer to the device_node structure
> > + *
> > + * Use SMC or HVC-based functions to communicate with EL2/EL3.
> > + *
> > + * Return: Returns 0 on success or error code */ static int
> > +get_set_conduit_method(struct device_node *np) {
> > + const char *method;
> > +
> > + if (of_property_read_string(np, "method", &method)) {
> > + pr_warn("%s missing \"method\" property\n", __func__);
> > + return -ENXIO;
> > + }
> > +
> > + if (!strcmp("hvc", method)) {
> > + do_fw_call = do_fw_call_hvc;
> > + } else if (!strcmp("smc", method)) {
> > + do_fw_call = do_fw_call_smc;
> > + } else {
> > + pr_warn("%s Invalid \"method\" property: %s\n",
> > + __func__, method);
> > + return -EINVAL;
> > + }
> > +
>
> Mark R did some cleanup around SMCCC conduits[1]. It makes sense to base this
> on top that. But if you manage to push this for v4.18, then you may need to wait
> for that to be merged and clean it up after v4.18
>
> --
> Regards,
> Sudeep
Mark R did change for SMCCC enums and we are not using any SMCCC enums so we don't have any dependency on that.
Thanks,
Jolly Shah
>
> [1] https://www.spinics.net/lists/arm-kernel/msg650305.html
^ permalink raw reply
* [PATCH 07/11] driver core: Respect all error codes from dev_pm_domain_attach()
From: Ulf Hansson @ 2018-05-14 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514151907.GK98604@atomide.com>
On 14 May 2018 at 17:19, Tony Lindgren <tony@atomide.com> wrote:
> Ulf,
>
> * Ulf Hansson <ulf.hansson@linaro.org> [180426 09:01]:
>> The limitation of being able to check only for -EPROBE_DEFER from
>> dev_pm_domain_attach() has been removed. Hence let's respect all error
>> codes and bail out accordingly.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> drivers/base/platform.c | 17 ++++++++---------
>> 1 file changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index 8075ddc..9460139 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -572,17 +572,16 @@ static int platform_drv_probe(struct device *_dev)
>> return ret;
>>
>> ret = dev_pm_domain_attach(_dev, true);
>> - if (ret != -EPROBE_DEFER) {
>> - if (drv->probe) {
>> - ret = drv->probe(dev);
>> - if (ret)
>> - dev_pm_domain_detach(_dev, true);
>> - } else {
>> - /* don't fail if just dev_pm_domain_attach failed */
>> - ret = 0;
>> - }
>> + if (ret)
>> + goto out;
>> +
>> + if (drv->probe) {
>> + ret = drv->probe(dev);
>> + if (ret)
>> + dev_pm_domain_detach(_dev, true);
>> }
>>
>> +out:
>> if (drv->prevent_deferred_probe && ret == -EPROBE_DEFER) {
>> dev_warn(_dev, "probe deferral not supported\n");
>> ret = -ENXIO;
>> --
>
> Looks like this causes Linux next to not boot for me with device
> probes failing with error -17. So that's at least omaps, looks
> like kernelci has others failing too.
Yep, problem also reported for some Exynos5 platforms.
Omap suffers from the similar problem, because of its SoC specific way
of attaching devices to PM domains.
>
> Reverting for 8c123c14bbba ("driver core: Respect all error codes from
> dev_pm_domain_attach()") fixes the issue for me.
>
> Sounds like something is missing, any ideas?
This should solve the problem:
https://patchwork.kernel.org/patch/10398597/
Kind regards
Uffe
^ permalink raw reply
* [PATCH v2] coresight: documentation: update sysfs section
From: Randy Dunlap @ 2018-05-14 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514121959.a9a3d2fb3d3d270849ffbc39@arm.com>
On 05/14/2018 10:19 AM, Kim Phillips wrote:
> - Align and show updated ls devices output from the TC2, based on
> current driver
>
> - Provide an example from an ETMv4 based system (Juno)
>
> - Reflect changes to the way the RAM write pointer is accessed since
> it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
> management entries").
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> v2: address Mathieu's comment about clarifying the sinks on the Juno
> vs. TC2 platforms.
>
> Documentation/trace/coresight.txt | 41 +++++++++++++++++++------------
> 1 file changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/trace/coresight.txt
> b/Documentation/trace/coresight.txt index 6f0120c3a4f1..134994e9fa6d
> 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -144,10 +144,22 @@ If everything goes well during the registration
> process the new devices will show up under /sys/bus/coresight/devices,
> as showns here for a TC2 platform:
as shown here
> root:~# ls /sys/bus/coresight/devices/
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> +20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> replicator +20030000.tpiu 2201c000.ptm 2203c000.etm
> 2203e000.etm root:~#
>
> +and here for a Juno platform:
> +
> +root at juno:~# ls /sys/bus/coresight/devices/
> +20010000.etf 20120000.replicator 22040000.etm
> 230c0000.funnel +20030000.tpiu 20130000.funnel
> 220c0000.funnel 23140000.etm +20040000.funnel
> 20140000.etf 22140000.etm 23240000.etm
> +20070000.etr 20150000.funnel 23040000.etm
> 23340000.etm +root at juno:~# +
> +Note that on Juno users can select the ETF, ETR and TPIU as a sink
> target while +on TC2, the ETB and TPIU can be selected.
> +
> The functions take a "struct coresight_device", which looks like this:
>
> struct coresight_desc {
> @@ -193,16 +205,16 @@ the information carried in "THIS_MODULE".
> How to use the tracer modules
> -----------------------------
>
> -Before trace collection can start, a coresight sink needs to be
> identify. +Before trace collection can start, a coresight sink needs to
The - and + lines seems to be merged...
> be identified. There is no limit on the amount of sinks (nor sources)
> that can be enabled at any given moment. As a generic operation, all
> device pertaining to the sink class will have an "active" entry in
> sysfs:
> root:/sys/bus/coresight/devices# ls
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> +20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> replicator +20030000.tpiu 2201c000.ptm 2203c000.etm
> 2203e000.etm root:/sys/bus/coresight/devices# ls 20010000.etb
> -enable_sink status trigger_cntr
> +enable_sink mgmt power subsystem trigger_cntr uevent
> root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> 1
> @@ -216,16 +228,13 @@ trigger a trace capture:
> root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> 1
> -root:/sys/bus/coresight/devices# cat 20010000.etb/status
> -Depth: 0x2000
> -Status: 0x1
> -RAM read ptr: 0x0
> -RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> -Trigger cnt: 0x0
> -Control: 0x1
> -Flush status: 0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> +
> +Observe the write pointer moving:
> +
> +root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
> +0x1a8
> +root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
> +0x19a6
>
> Trace collection is stopped the same way:
>
>
--
~Randy
^ permalink raw reply
* [PATCH 2/2] ARM: dts: iimx51-eukrea-mbimxsd51-baseboard: Fix USB PHY duplicate unit-address
From: Fabio Estevam @ 2018-05-14 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526322576-5838-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Currently the following DTC warning is seen with W=1:
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dtb: Warning (unique_unit_address): /usbphy/usbphy at 0: duplicate unit-address (also used in node /usbphy/usbh1phy at 0)
Fix it by moving the USB PHY node outside of simple-bus and drop the
unneeded unit-address.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
.../arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
index b3d952f..29b0b7b 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
@@ -83,19 +83,12 @@
fsl,mux-ext-port = <3>;
};
- usbphy {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "simple-bus";
-
- usbh1phy: usbh1phy at 0 {
- compatible = "usb-nop-xceiv";
- reg = <0>;
- clocks = <&clks IMX5_CLK_USB_PHY_GATE>;
- clock-names = "main_clk";
- clock-frequency = <19200000>;
- #phy-cells = <0>;
- };
+ usbh1phy: usbphy {
+ compatible = "usb-nop-xceiv";
+ clocks = <&clks IMX5_CLK_USB_PHY_GATE>;
+ clock-names = "main_clk";
+ clock-frequency = <19200000>;
+ #phy-cells = <0>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx51-babbage: Fix USB PHY duplicate unit-address
From: Fabio Estevam @ 2018-05-14 18:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Currently the following DTC warning is seen with W=1:
arch/arm/boot/dts/imx51-babbage.dtb: Warning (unique_unit_address): /usbphy/usbphy at 0: duplicate unit-address (also used in node /usbphy/usbh1phy at 0)
Fix it by moving the USB PHY node outside of simple-bus and drop the
unneeded unit-address.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx51-babbage.dts | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index b8ca73d..de46906 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -170,20 +170,13 @@
mux-ext-port = <3>;
};
- usbphy {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "simple-bus";
-
- usbh1phy: usbh1phy at 0 {
- compatible = "usb-nop-xceiv";
- reg = <0>;
- clocks = <&clk_usb>;
- clock-names = "main_clk";
- reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
- vcc-supply = <&vusb_reg>;
- #phy-cells = <0>;
- };
+ usbh1phy: usbphy1 {
+ compatible = "usb-nop-xceiv";
+ clocks = <&clk_usb>;
+ clock-names = "main_clk";
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vusb_reg>;
+ #phy-cells = <0>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 07/21] i2c: efm32: make use of i2c_8bit_addr_from_msg
From: Uwe Kleine-König @ 2018-05-14 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514145330.4857-8-peda@axentia.se>
Hello Peter,
On Mon, May 14, 2018 at 04:53:16PM +0200, Peter Rosin wrote:
> Because it looks neater.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/i2c/busses/i2c-efm32.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-efm32.c b/drivers/i2c/busses/i2c-efm32.c
> index aa336ba89aa3..5f2bab878b2c 100644
> --- a/drivers/i2c/busses/i2c-efm32.c
> +++ b/drivers/i2c/busses/i2c-efm32.c
> @@ -144,8 +144,7 @@ static void efm32_i2c_send_next_msg(struct efm32_i2c_ddata *ddata)
> struct i2c_msg *cur_msg = &ddata->msgs[ddata->current_msg];
>
> efm32_i2c_write32(ddata, REG_CMD, REG_CMD_START);
> - efm32_i2c_write32(ddata, REG_TXDATA, cur_msg->addr << 1 |
> - (cur_msg->flags & I2C_M_RD ? 1 : 0));
> + efm32_i2c_write32(ddata, REG_TXDATA, i2c_8bit_addr_from_msg(cur_msg));
Nice,
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards and thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Adam Ford @ 2018-05-14 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <825847d0-c29c-859b-43fd-0987f94e28a5@ti.com>
On Mon, May 14, 2018 at 7:35 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Monday 14 May 2018 04:22 PM, Adam Ford wrote:
>> On Mon, May 14, 2018 at 12:29 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> Hi Adam,
Added Tomi, Laurent, and Jyri for feedback.
>>>
>>> On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
>>>> When using the board files the LCD works, but not with the DT.
>>>> This adds enables the original da850-evm to work with the same
>>>> LCD in device tree mode.
>>>>
>>>> The EVM has a gpio for the regulator and a gpio enable. The LCD and
>>>> the vpif display pins are mutually exclusive, so if using the LCD,
>>>> do not load the vpif driver.
>>>
>>> Its not sufficient just note this in patch description.
>>>
>>> a) Disable (status = "disabled") the VPIF node which clashes for pins
>>> with LCD.
>>> b) Add a comment on top of the status = "disabled" giving information on
>>> how user can enable it (disable lcdc node and then change to status =
>>> "okay").
>>>
>>>>
>>>> Signed-off-by: Adam Ford <aford173@gmail.com>
>>>> ---
>>>> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
>>>> backlight which better matches the schematic. Updated the description to explain
>>>> that it cannot be used at the same time as the vpif driver.
>>>>
>>>> V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>>> index 2e817da37fdb..3f1c8be07efe 100644
>>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>>> @@ -27,6 +27,50 @@
>>>> spi0 = &spi1;
>>>> };
>>>>
>>>> + backlight {
>>>> + compatible = "gpio-backlight";
>>>> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
>>>
>>> The gpio-backlight binding does not describe a property called
>>> enable-gpios. It should just be gpios.
>>
>> I will fix that.
>>
>>>
>>> a) Are you using gpio-backlight because you are not able to get the PWM
>>> to work?
>>>
>> Yes, You told me not to worry about doing a PWM backlight because the
>> legacy board does not PWM either.
>
> Yeah, I meant not to add backlight control till the time we are able to
> get it working using PWM. Is this needed for the basic LCD functionality
> to work? I would like to avoid the churn of adding it using GPIO now and
> changing to PWM later, if possible.
>
>>
>>> b) What is GP0[7] connected to in the schematic you have? In the
>>> schematic I have I see LCD_PWM0 is connected to
>>> SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
>>
>> I have schematic 1016572 dated Wednesday, August 18, 2010. According
>> to it, AXR15 / EPWMN0_TZ[0] / ECAP2_APWM2 / GPIO0[7] connects to U25,
>> Pin 46 to generate M_LCD_PWM0. You might have one of the early,
>> pre-release versions.
>
> Ah, okay. In your schematic, is GP2[14] connected to anything?
>
>>
>>>
>>> c) The /* GP0[7] */ comment is not really useful on its own as it can be
>>> computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
>>> Same for other places like this below.
>>
>> I can do that.
>>>
>>>> @@ -35,6 +79,16 @@
>>>> regulator-boot-on;
>>>> };
>>>>
>>>> + backlight_reg: backlight-regulator {
>>>> + compatible = "regulator-fixed";
>>>> + regulator-name = "lcd_backlight_pwr";
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
>>>> + regulator-always-on;
>>>
>>> Why should this regulator never be disabled?
>>
>> The gpio-backlight does not have a way that I can see to associate the
>> regulator to it. I read through the bindings, but I didn't see an
>> option to associate a regulator it. I use this regulator to drive
>> lcd_backlight_pwr and the backlight driver to write lcd_pwm0. Without
>> this option, the system disables lcd_backlight_pwr and the screen is
>> blank
>
> It sounds like this is a hack to enable backlight on this board. I think
> either the backlight driver needs to gain functionality to enable the
> GPIO. Or backlight could be treated as part of the panel and enabled
> using enable-gpios property in the panel. TBH, I will be okay either
> way. Can you check with Jyri, Tomi and rest of the DRM folks on what
> should be right way of dealing with this?
Per your request I added them into this thread. I added Tomi, Jyri,
and Laurent to this as Laurent's name is associated with the gpio
backlight driver.
I am not sure why you think it's a hack. I pulled up the schematic
for the LCD to see what it's doing, and the lcd_backlight_pwr pin
controls the power-on sequence of the back-light controller. Without
this, there is no power, so it seems to me that the 'regulator-fixed'
device is the correct way to do it.
The separate pin associated to the gpio is used to tell the backlight
IC to actually turn on/off the back-light. Ideally it seems like it
would nice to have the gpio-backlight driver be able to specify the
regulator, so when the backlight is in use, it would power the
regulator, but until that's available, the it seems like
'regulator-always-on' is the way to make it stay on.
Laurent, Jyri, Tomi, do you have any thoughts on this matter?
Thanks,
adam
>
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
From: Jagan Teki @ 2018-05-14 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180419093225.614-5-wens@csie.org>
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> This panel is marketed as Banana Pi 7" LCD display. On the back is
> a sticker denoting the model name S070WV20-CT16.
>
> This is a 7" 800x480 panel connected through a 24-bit RGB interface.
> However the panel only does 262k colors.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../display/panel/bananapi,s070wv20-ct16.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++
> 2 files changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
> new file mode 100644
> index 000000000000..2ec35ce36e9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
> @@ -0,0 +1,7 @@
> +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
> +
> +Required properties:
> +- compatible: should be "bananapi,s070wv20-ct16"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index cbf1ab404ee7..9bc037f74d6c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
> },
> };
>
> +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
> + .clock = 30000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 40,
> + .hsync_end = 800 + 40 + 48,
> + .htotal = 800 + 40 + 48 + 40,
> + .vdisplay = 480,
> + .vsync_start = 480 + 13,
> + .vsync_end = 480 + 13 + 3,
> + .vtotal = 480 + 13 + 3 + 29,
> +};
> +
> +static const struct panel_desc bananapi_s070wv20_ct16 = {
> + .modes = &bananapi_s070wv20_ct16_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> +};
I think this parallel RGB interface right? I too have same display
with DSI I'm sure these setting will not useful right? do we need to
write separate panel driver for that?
^ permalink raw reply
* [patch v20 1/4] drivers: jtag: Add JTAG core driver
From: Randy Dunlap @ 2018-05-14 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526314803-3532-2-git-send-email-oleksandrs@mellanox.com>
On 05/14/2018 09:20 AM, Oleksandr Shamray wrote:
Hi,
Just a bit more Kconfig fixing below.
> ---
> Documentation/ioctl/ioctl-number.txt | 2 +
> MAINTAINERS | 10 ++
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/jtag/Kconfig | 18 +++
> drivers/jtag/Makefile | 1 +
> drivers/jtag/jtag.c | 274 ++++++++++++++++++++++++++++++++++
> include/linux/jtag.h | 41 +++++
> include/uapi/linux/jtag.h | 105 +++++++++++++
> 9 files changed, 454 insertions(+), 0 deletions(-)
> create mode 100644 drivers/jtag/Kconfig
> create mode 100644 drivers/jtag/Makefile
> create mode 100644 drivers/jtag/jtag.c
> create mode 100644 include/linux/jtag.h
> create mode 100644 include/uapi/linux/jtag.h
> diff --git a/drivers/jtag/Kconfig b/drivers/jtag/Kconfig
> new file mode 100644
> index 0000000..ba72a2b
> --- /dev/null
> +++ b/drivers/jtag/Kconfig
> @@ -0,0 +1,18 @@
> +menuconfig JTAG
> + tristate "JTAG support"
> + help
> + This provides basic core functionality support for JTAG class devices
(end sentence above with '.') devices.
> + Hardware that is equipped with a JTAG microcontroller can be
> + supported by using this driver's interfaces.
> + This driver exposes a set of IOCTL to the user space for
IOCTLs
> + another commands:
various commands:
or
the following commands:
or
associated commands:
> + SDR: (Scan Data Register) Performs an IEEE 1149.1 Data Register scan
> + SIR: (Scan Instruction Register) Performs an IEEE 1149.1 Instruction
> + Register scan.
> + RUNTEST: Forces the IEEE 1149.1 bus to a run state for a specified
> + number of clocks or a specified time period.
> +
> + If you want this support, you should say Y here.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called jtag.
thanks,
--
~Randy
^ permalink raw reply
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Dominik Brodowski @ 2018-05-14 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-9-mark.rutland@arm.com>
> +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> +{
> + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> + regs->regs[2], regs->regs[3],
> + regs->regs[4], regs->regs[5]);
> +}
Any specific reason to have this in a separate function? This seems to be
called only from one instance, namely
> +asmlinkage void invoke_syscall(struct pt_regs *regs, int scno, int sc_nr,
> + syscall_fn_t syscall_table[])
> +{
> + if (scno < sc_nr) {
> + syscall_fn_t syscall_fn;
> + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> + __invoke_syscall(regs, syscall_fn);
> + } else {
> + regs->regs[0] = do_ni_syscall(regs);
> + }
> +}
and result in a one-liner in the last patch of the series.
Thanks,
Dominik
^ permalink raw reply
* [PATCH] ARM: dts: imx: Switch NXP boards to SPDX identifier
From: Fabio Estevam @ 2018-05-14 17:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx23-evk.dts | 13 +++-------
arch/arm/boot/dts/imx25-pdk.dts | 13 +++-------
arch/arm/boot/dts/imx27-pdk.dts | 13 +++-------
arch/arm/boot/dts/imx28-evk.dts | 13 +++-------
arch/arm/boot/dts/imx35-pdk.dts | 15 +++--------
arch/arm/boot/dts/imx50-evk.dts | 17 ++++--------
arch/arm/boot/dts/imx51-babbage.dts | 15 +++--------
arch/arm/boot/dts/imx53-qsb-common.dtsi | 15 +++--------
arch/arm/boot/dts/imx53-qsb.dts | 15 +++--------
arch/arm/boot/dts/imx53-qsrb.dts | 15 +++--------
arch/arm/boot/dts/imx53-smd.dts | 17 ++++--------
arch/arm/boot/dts/imx6dl-sabreauto.dts | 10 +++-----
arch/arm/boot/dts/imx6dl-sabresd.dts | 10 +++-----
arch/arm/boot/dts/imx6q-sabreauto.dts | 16 ++++--------
arch/arm/boot/dts/imx6q-sabresd.dts | 15 +++--------
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 15 +++--------
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 15 +++--------
arch/arm/boot/dts/imx6qp-sabreauto.dts | 44 +++-----------------------------
arch/arm/boot/dts/imx6qp-sabresd.dts | 44 +++-----------------------------
arch/arm/boot/dts/imx6sl-evk.dts | 10 +++-----
arch/arm/boot/dts/imx6sx-sabreauto.dts | 10 +++-----
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 10 +++-----
arch/arm/boot/dts/imx7d-sdb-sht11.dts | 44 +++-----------------------------
arch/arm/boot/dts/imx7d-sdb.dts | 44 +++-----------------------------
24 files changed, 86 insertions(+), 362 deletions(-)
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 9d92ece82..d3cdd3b 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -1,13 +1,6 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, I/*
/dts-v1/;
#include "imx23.dtsi"
diff --git a/arch/arm/boot/dts/imx25-pdk.dts b/arch/arm/boot/dts/imx25-pdk.dts
index 7696e0c0..a5626b4 100644
--- a/arch/arm/boot/dts/imx25-pdk.dts
+++ b/arch/arm/boot/dts/imx25-pdk.dts
@@ -1,13 +1,6 @@
-/*
- * Copyright 2013 Freescale Semiconductor, Inc.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2013 Freescale Semiconductor, Inc.
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
diff --git a/arch/arm/boot/dts/imx27-pdk.dts b/arch/arm/boot/dts/imx27-pdk.dts
index 924b90c..f9a882d 100644
--- a/arch/arm/boot/dts/imx27-pdk.dts
+++ b/arch/arm/boot/dts/imx27-pdk.dts
@@ -1,13 +1,6 @@
-/*
- * Copyright 2012 Sascha Hauer, Pengutronix
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Sascha Hauer, Pengutronix
/dts-v1/;
#include "imx27.dtsi"
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index b0d3965..6b0ae66 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -1,13 +1,6 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
/dts-v1/;
#include "imx28.dtsi"
diff --git a/arch/arm/boot/dts/imx35-pdk.dts b/arch/arm/boot/dts/imx35-pdk.dts
index 646b125..df613e8 100644
--- a/arch/arm/boot/dts/imx35-pdk.dts
+++ b/arch/arm/boot/dts/imx35-pdk.dts
@@ -1,14 +1,7 @@
-/*
- * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
- * Copyright 2014 Freescale Semiconductor, Inc.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+// Copyright 2014 Freescale Semiconductor, Inc.
/dts-v1/;
#include "imx35.dtsi"
diff --git a/arch/arm/boot/dts/imx50-evk.dts b/arch/arm/boot/dts/imx50-evk.dts
index 23f1833..f0622ec 100644
--- a/arch/arm/boot/dts/imx50-evk.dts
+++ b/arch/arm/boot/dts/imx50-evk.dts
@@ -1,15 +1,8 @@
-/*
- * Copyright 2013 Greg Ungerer <gerg@uclinux.org>
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2013 Greg Ungerer <gerg@uclinux.org>
+// Copyright 2011 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
/dts-v1/;
#include "imx50.dtsi"
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index cf7a196..b8ca73d 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -1,14 +1,7 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2011 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
/dts-v1/;
#include "imx51.dtsi"
diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi b/arch/arm/boot/dts/imx53-qsb-common.dtsi
index 485a69d..ef7658a 100644
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -1,14 +1,7 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2011 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
#include "imx53.dtsi"
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index d3d662e..6df6d85 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -1,14 +1,7 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2011 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
/dts-v1/;
#include "imx53-qsb-common.dtsi"
diff --git a/arch/arm/boot/dts/imx53-qsrb.dts b/arch/arm/boot/dts/imx53-qsrb.dts
index 4e103a9..1bbf24a 100644
--- a/arch/arm/boot/dts/imx53-qsrb.dts
+++ b/arch/arm/boot/dts/imx53-qsrb.dts
@@ -1,14 +1,7 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2011 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx53-smd.dts b/arch/arm/boot/dts/imx53-smd.dts
index 705af5e..95bdb98 100644
--- a/arch/arm/boot/dts/imx53-smd.dts
+++ b/arch/arm/boot/dts/imx53-smd.dts
@@ -1,15 +1,8 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2011 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
/dts-v1/;
#include <dt-bindings/input/input.h>
#include "imx53.dtsi"
diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dts b/arch/arm/boot/dts/imx6dl-sabreauto.dts
index a6ce7b4..660d52a 100644
--- a/arch/arm/boot/dts/imx6dl-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6dl-sabreauto.dts
@@ -1,10 +1,6 @@
-/*
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2013 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dts b/arch/arm/boot/dts/imx6dl-sabresd.dts
index 9607afe..cd6bbf2 100644
--- a/arch/arm/boot/dts/imx6dl-sabresd.dts
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dts
@@ -1,10 +1,6 @@
-/*
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2013 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts b/arch/arm/boot/dts/imx6q-sabreauto.dts
index 334b924..66f2728 100644
--- a/arch/arm/boot/dts/imx6q-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
@@ -1,14 +1,8 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
index 527772b..eec9446 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -1,14 +1,7 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 54b0139..0e28e36 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -1,14 +1,7 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
#include <dt-bindings/gpio/gpio.h>
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index c2de225..15744ad 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -1,14 +1,7 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
diff --git a/arch/arm/boot/dts/imx6qp-sabreauto.dts b/arch/arm/boot/dts/imx6qp-sabreauto.dts
index 5ce3840..d4caeeb 100644
--- a/arch/arm/boot/dts/imx6qp-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6qp-sabreauto.dts
@@ -1,44 +1,6 @@
-/*
- * Copyright 2016 Freescale Semiconductor, Inc.
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright 2016 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6qp-sabresd.dts b/arch/arm/boot/dts/imx6qp-sabresd.dts
index a8a5004..f1b9cb1 100644
--- a/arch/arm/boot/dts/imx6qp-sabresd.dts
+++ b/arch/arm/boot/dts/imx6qp-sabresd.dts
@@ -1,44 +1,6 @@
-/*
- * Copyright 2016 Freescale Semiconductor, Inc.
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright 2016 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index 37e792f..92ad01f 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -1,10 +1,6 @@
-/*
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+//Copyright (C) 2013 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index bfbcf70..841a27f 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -1,10 +1,6 @@
-/*
- * Copyright (C) 2014 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2014 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
index 6d720b2..2438669 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
@@ -1,10 +1,6 @@
-/*
- * Copyright (C) 2015 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2015 Freescale Semiconductor, Inc.
/dts-v1/;
diff --git a/arch/arm/boot/dts/imx7d-sdb-sht11.dts b/arch/arm/boot/dts/imx7d-sdb-sht11.dts
index 64a20ed..9965555 100644
--- a/arch/arm/boot/dts/imx7d-sdb-sht11.dts
+++ b/arch/arm/boot/dts/imx7d-sdb-sht11.dts
@@ -1,44 +1,6 @@
-/*
- * Copyright (C) 2015 Freescale Semiconductor, Inc.
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright (C) 2015 Freescale Semiconductor, Inc.
#include "imx7d-sdb.dts"
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 598d662..722a45a 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -1,44 +1,6 @@
-/*
- * Copyright (C) 2015 Freescale Semiconductor, Inc.
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright (C) 2015 Freescale Semiconductor, Inc.
/dts-v1/;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64/sve: Write ZCR_EL1 on context switch only if changed
From: Dave Martin @ 2018-05-14 17:51 UTC (permalink / raw)
To: linux-arm-kernel
Writes to ZCR_EL1 are self-synchronising, and so may be expensive
in typical implementations.
This patch adopts the approach used for costly system register
writes elsewhere in the kernel: the system register write is
suppressed if it would not change the stored value.
Since the common case will be that of switching between tasks that
use the same vector length as one another, prediction hit rates on
the conditional branch should be reasonably good, with lower
expected amortised cost than the unconditional execution of a
heavyweight self-synchronising instruction.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/fpsimdmacros.h | 12 +++++++-----
arch/arm64/kernel/entry-fpsimd.S | 2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimdmacros.h b/arch/arm64/include/asm/fpsimdmacros.h
index e050d76..4684351 100644
--- a/arch/arm64/include/asm/fpsimdmacros.h
+++ b/arch/arm64/include/asm/fpsimdmacros.h
@@ -207,12 +207,14 @@
str w\nxtmp, [\xpfpsr, #4]
.endm
-.macro sve_load nxbase, xpfpsr, xvqminus1, nxtmp
+.macro sve_load nxbase, xpfpsr, xvqminus1, nxtmp, xtmp2
mrs_s x\nxtmp, SYS_ZCR_EL1
- bic x\nxtmp, x\nxtmp, ZCR_ELx_LEN_MASK
- orr x\nxtmp, x\nxtmp, \xvqminus1
- msr_s SYS_ZCR_EL1, x\nxtmp // self-synchronising
-
+ bic \xtmp2, x\nxtmp, ZCR_ELx_LEN_MASK
+ orr \xtmp2, \xtmp2, \xvqminus1
+ cmp \xtmp2, x\nxtmp
+ b.eq 921f
+ msr_s SYS_ZCR_EL1, \xtmp2 // self-synchronising
+921:
_for n, 0, 31, _sve_ldr_v \n, \nxbase, \n - 34
_sve_ldr_p 0, \nxbase
_sve_wrffr 0
diff --git a/arch/arm64/kernel/entry-fpsimd.S b/arch/arm64/kernel/entry-fpsimd.S
index 73f17bf..12d4958 100644
--- a/arch/arm64/kernel/entry-fpsimd.S
+++ b/arch/arm64/kernel/entry-fpsimd.S
@@ -49,7 +49,7 @@ ENTRY(sve_save_state)
ENDPROC(sve_save_state)
ENTRY(sve_load_state)
- sve_load 0, x1, x2, 3
+ sve_load 0, x1, x2, 3, x4
ret
ENDPROC(sve_load_state)
--
2.1.4
^ permalink raw reply related
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Andy Shevchenko @ 2018-05-14 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a3930b867cf8c279953d08c5d5dd1d93113a43b.camel@microchip.com>
First of all, do not remove mailing lists from Cc and people if you
are not sure they do not need your stuff.
On Mon, May 14, 2018 at 11:11 AM, Radu Pirea <radu.pirea@microchip.com> wrote:
> On Sun, 2018-05-13 at 16:33 +0300, Andy Shevchenko wrote:
>> On Fri, May 11, 2018 at 1:38 PM, Radu Pirea <radu.pirea@microchip.com
>> > wrote:
>> > +static void at91_usart_spi_cleanup(struct spi_device *spi)
>> > +{
>> > + struct at91_usart_spi_device *ausd = spi->controller_state;
>> > +
>> > + if (!ausd)
>> > + return;
>>
>> Is it even possible?
> Theoretically yes.
I would like to know real circumstances when it might happen.
>>
>> Anyway the code below will work fine even if it's the case.
>>
>> > +
>> > + spi->controller_state = NULL;
>> > + kfree(ausd);
>> > +}
>> The question is, why you didn't utilize what SPI core provides you?
> I tried, but it did not work the way I expected.
So, what is not going as expected in "SPI core takes care of CSs" case?
Did you use oscilloscope for that?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] coresight: documentation: update sysfs section
From: Kim Phillips @ 2018-05-14 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyQLan3XajOz2uuoOF8OQchGfeu2ZkZJ9H1Xm9q==aXTw@mail.gmail.com>
- Align and show updated ls devices output from the TC2, based on
current driver
- Provide an example from an ETMv4 based system (Juno)
- Reflect changes to the way the RAM write pointer is accessed since
it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
management entries").
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
v2: address Mathieu's comment about clarifying the sinks on the Juno
vs. TC2 platforms.
Documentation/trace/coresight.txt | 41 +++++++++++++++++++------------
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/Documentation/trace/coresight.txt
b/Documentation/trace/coresight.txt index 6f0120c3a4f1..134994e9fa6d
100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -144,10 +144,22 @@ If everything goes well during the registration
process the new devices will show up under /sys/bus/coresight/devices,
as showns here for a TC2 platform:
root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
replicator +20030000.tpiu 2201c000.ptm 2203c000.etm
2203e000.etm root:~#
+and here for a Juno platform:
+
+root at juno:~# ls /sys/bus/coresight/devices/
+20010000.etf 20120000.replicator 22040000.etm
230c0000.funnel +20030000.tpiu 20130000.funnel
220c0000.funnel 23140000.etm +20040000.funnel
20140000.etf 22140000.etm 23240000.etm
+20070000.etr 20150000.funnel 23040000.etm
23340000.etm +root at juno:~# +
+Note that on Juno users can select the ETF, ETR and TPIU as a sink
target while +on TC2, the ETB and TPIU can be selected.
+
The functions take a "struct coresight_device", which looks like this:
struct coresight_desc {
@@ -193,16 +205,16 @@ the information carried in "THIS_MODULE".
How to use the tracer modules
-----------------------------
-Before trace collection can start, a coresight sink needs to be
identify. +Before trace collection can start, a coresight sink needs to
be identified. There is no limit on the amount of sinks (nor sources)
that can be enabled at any given moment. As a generic operation, all
device pertaining to the sink class will have an "active" entry in
sysfs:
root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
replicator +20030000.tpiu 2201c000.ptm 2203c000.etm
2203e000.etm root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
+enable_sink mgmt power subsystem trigger_cntr uevent
root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
1
@@ -216,16 +228,13 @@ trigger a trace capture:
root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+
+Observe the write pointer moving:
+
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x1a8
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x19a6
Trace collection is stopped the same way:
--
2.17.0
^ permalink raw reply
* [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()
From: Mark Rutland @ 2018-05-14 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-14-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> Using this helper allows us to avoid the in-kernel calls to the
> compat_sys_{f,}statfs64() sycalls, as are necessary for parameter
> mangling in arm64's compat handling.
>
> Following the example of ksys_* functions, kcompat_sys_* functions are
> intended to be a drop-in replacement for their compat_sys_*
> counterparts, with the same calling convention.
>
> This is necessary to enable conversion of arm64's syscall handling to
> use pt_regs wrappers.
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 6723ea51ec99..e0bf3e4bb897 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -59,6 +59,7 @@ struct tms;
> struct utimbuf;
> struct mq_attr;
> struct compat_stat;
> +struct compat_statfs64;
> struct compat_timeval;
> struct robust_list_head;
> struct getcpu_cache;
> @@ -1150,6 +1151,13 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,
> ssize_t ksys_readahead(int fd, loff_t offset, size_t count);
> unsigned int ksys_personality(unsigned int personality);
>
> +#ifdef CONFIG_COMPAT
> +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
> + struct compat_statfs64 __user * buf);
> +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> + struct compat_statfs64 __user * buf);
> +#endif
I've moved these to <linux/compat.h>, so that they live with the rest of
the compat syscall stuff. That should avoid build failures the kbuild
test robot picked up where compat_size_t wasn't dfined.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] edac: altera: Fix ARM64 warning
From: thor.thayer at linux.intel.com @ 2018-05-14 17:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <thor.thayer@linux.intel.com>
The kbuild test robot reported the following warning on altera_edac.c:
drivers//edac/altera_edac.c: In function 'ocram_free_mem':
drivers//edac/altera_edac.c:1410:42: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
gen_pool_free((struct gen_pool *)other, (u32)p, size);
^^^
After adding support for ARM64 architectures, the unsigned long parameter
is 64bits and causes a build warning with arm64-allyesconfig
Fix by casting to the correct size (unsigned long) instead of u32.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: c3eea1942a16 ("EDAC, altera: Add Altera L2 cache and OCRAM support")
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
drivers/edac/altera_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 5672f6718262..c5104ea7e1fb 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1415,7 +1415,7 @@ static void *ocram_alloc_mem(size_t size, void **other)
static void ocram_free_mem(void *p, size_t size, void *other)
{
- gen_pool_free((struct gen_pool *)other, (u32)p, size);
+ gen_pool_free((struct gen_pool *)other, (unsigned long)p, size);
}
static const struct edac_device_prv_data ocramecc_data = {
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Laurent Pinchart @ 2018-05-14 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514102326.GG30519@bigcity.dyn.berto.se>
Hi Niklas,
On Monday, 14 May 2018 13:23:26 EEST Niklas S?derlund wrote:
> On 2018-05-14 09:39:34 +0200, Jacopo Mondi wrote:
> > On Sun, May 13, 2018 at 02:57:55PM +0200, Niklas S?derlund wrote:
> >> On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> >>> Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> >>> development board.
> >>>
> >>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >>> ---
> >>>
> >>> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 +++++++++++++++++++
> >>> 1 file changed, 68 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> >>> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index
> >>> d03f194..e0ce462 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
[snip]
> >>> +&vin4 {
> >>> + pinctrl-0 = <&vin4_pins>;
> >>> + pinctrl-names = "default";
> >>> +
> >>> + status = "okay";
> >>> +
> >>> + ports {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + port at 0 {
> >>> + reg = <0>;
> >>> +
> >>> + vin4_in: endpoint {
> >>> + hsync-active = <0>;
> >>> + vsync-active = <0>;
> >>
> >> Comparing this to the Gen2 bindings some properties are missing,
> >>
> >> bus-width = <24>;
> >> pclk-sample = <1>;
> >> data-active = <1>;
> >
> > The VIN driver does not parse them, so there is no value in having
> > them there, if not confusing people as it happened to me reading the
> > Gen2 DT.
>
> I have no objection removing them. Trying to understand why the
> description differed from Gen2.
>
> >> This is not a big deal as the VIN driver don't use these properties so
> >> no functional change should come of this but still a difference.
> >
> > Exactly.
> >
> > On a side note. I have not seen a way to configure the pixel clock
> > sampling level in the interface datasheet. The register used to
> > configure synchronism signals polarities is VnDMR2, and there I read
> > we can configure HSYNC/VSYNC and CLOCKENB (which is data enable, not
> > pixel clock) polarities. Is it configured through some other
> > register?
>
> I have not seen such a register no.
>
> >> Over all I'm happy with this change but before I add my tag I would like
> >> to understand why it differs from the Gen2 configuration for the adv7612
> >> properties.
> >>
> >> Also on a side not it is possible with hardware switches on the board
> >> switch the VIN4 source to a completely different pipeline CVBS connector
> >> -> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
> >> this seems to be how the boards are shipped. But maybe mentioning this
> >> in the commit message would not hurt if you end-up resending the patch.
> >
> > Oh I see. SW-49 to SW-52 enables the HDMI input, SW53-SW54 CVBS one.
> > And actually, reading the 'initial setting of slide switches' in the
> > Draak board manual, it turns out that the board default configuration
> > is with CVBS input selected... What should we do here? reflect
> > defaults in the DT, or prioritize HDMI?
>
> I feel this is a question for Laurent. My feeling for how we handled
> this in other cases is to go with the board default settings. I'm
> however sure there are exceptions to the rule. So maybe we should go
> with the most useful (what ever that is) configuration?
I think I'd go with CVBS as I don't think HDMI would be considered as the most
useful configuration here. The Draak board is unlikely to be used by us as a
reference platform to test HDMI capture, is it ?
This being said, you can instantiate the adv7612 and HDMI connector in DT,
without connecting them to the VIN. That would make it easy to quickly change
the configuration.
> >>> +
> >>> + remote-endpoint = <&adv7612_out>;
> >>> + };
> >>> + };
> >>> + };
> >>> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 00/21] i2c: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-14 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c83bb5ddf36b419c4c01e20384c7b532c9a48cd4.camel@perches.com>
On 2018-05-14 18:11, Joe Perches wrote:
> On Mon, 2018-05-14 at 16:53 +0200, Peter Rosin wrote:
>> Hi!
>>
>> The nice little inline i2c_8bit_addr_from_msg is not getting
>> enough use. This series improves the situation and drops a
>> bunch of lines in the process.
>
> Perhaps the inline should test for I2C_M_REV_DIR_ADDR
> as there is at least one use like
>
> - addr = msg->addr << 1;
> - if (flags & I2C_M_RD)
> - addr |= 1;
> + addr = i2c_8bit_addr_from_msg(msg);
> if (flags & I2C_M_REV_DIR_ADDR)
> addr ^= 1;
>
> which look odd
I say no, because the driver has to also indicate support with
I2C_FUNC_PROTOCOL_MANGLING and I don't see a sane way to check
that part of the contract. But what do I know. Seems orthogonal.
> Do any of these changes now no longer need
> the temporary flags variable?
Right, I thought I had made any obvious further simplification made
possible by these changes, but I overlooked that one. The flags
variable is certainly over-engineered in i2c-algo-pcf.c and would
be a good candidate for removal. But that's only patch 3/21.
I'll wait for a bit with an update, and Wolfram can adjust this on
the way in if he feels like it.
Cheers,
Peter
^ permalink raw reply
* [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Andy Shevchenko @ 2018-05-14 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a75568e-a52e-3872-f465-d707372a5c12@sorico.fr>
On Mon, May 14, 2018 at 1:57 PM, Richard Genoud
<richard.genoud@gmail.com> wrote:
> On 11/05/2018 12:38, Radu Pirea wrote:
>> This patch modifies the place where resources and device tree properties
>> are searched.
> I think it may be simpler with something like:
> + int size = mfd_pdev->resource[0].end - mfd_pdev->resource[0].start + 1;
Isn't resource_size() macro for this very purpose?
>> + int size = to_platform_device(pdev->dev.parent)->resource[0].end -
>> + to_platform_device(pdev->dev.parent)->resource[0].start + 1;
>>
> ditto
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Laurent Pinchart @ 2018-05-14 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094900.GF30519@bigcity.dyn.berto.se>
Hi Niklas,
On Monday, 14 May 2018 12:49:00 EEST Niklas S?derlund wrote:
> On 2018-05-14 05:49:41 +0300, Laurent Pinchart wrote:
>
> [snip]
>
> >>> +&vin4 {
> >>> + pinctrl-0 = <&vin4_pins>;
> >>> + pinctrl-names = "default";
> >>> +
> >>> + status = "okay";
> >>> +
> >>> + ports {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + port at 0 {
> >>> + reg = <0>;
> >>> + vin4_in: endpoint {
> >>> + hsync-active = <0>;
> >>> + vsync-active = <0>;
> >>
> >> Comparing this to the Gen2 bindings some properties are missing,
> >>
> >> bus-width = <24>;
> >> pclk-sample = <1>;
> >> data-active = <1>;
> >>
> >> This is not a big deal as the VIN driver don't use these properties so
> >> no functional change should come of this but still a difference.
> >
> > I think the VIN DT bindings should be updated to explicitly list the
> > endpoint properties that are mandatory, optional, or not allowed.
>
> I think it's documented as it reference video-interfaces.txt which lists
> all these properties as optional. And in deed they are all optional.
I don't think that's good enough. They're all listed as optional in video-
interfaces.txt as the generic documentation can't know whether a particular
device will require a particular property or not. It's the responsibility of
device DT bindings to refine the bindings description. The VIN DT bindings
should explicitly list the properties that apply to the VIN and tell whether
they're optional or mandatory for the VIN. For optional properties, the
default behaviour when the property is not specified should be documented too.
For instance, does VIN support selecting which pixel clock edge to sample data
on ? If so the pclk-sample property should listed as either mandatory or
optional with a documented default, even if not used by the driver today.
> If the VIN driver makes use of all the optional ones is another matter. How
> do we know that the remote subdevice is not looking at its remote
> endpoint for bus parameters not considered by the rcar-vin driver?
No driver should parse properties of remote nodes, as those properties are to
be interpreted in the context of the remote node's DT bindings, which the
driver doesn't know about. Parsing OF graph properties (ports and endpoints)
is an exception, as by connecting a remote node to the local node with OF
graph properties you imply that the remote node uses OF graph DT bindings, so
those properties (and only those properties) can be parsed.
> The thing is that the rcar-vin driver only looks at the remote endpoint
> for these properties and ignores the on its local endpoint. Maybe some
> v4l2 framework change is needed here to make sure the bus properties are
> the same on both endpoints of a link. But I fear such a change would
> break a lot of stuff.
Properties are specified on both endpoints to account for components such as
inverter gates between the two devices. They can thus be different on the two
sides, that's perfectly valid. The VIN driver should parse its local
properties, not the remote properties.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] thermal: exynos: Reduce severity of too early temperature read
From: Bartlomiej Zolnierkiewicz @ 2018-05-14 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513175402.28887-1-krzk@kernel.org>
On Sunday, May 13, 2018 07:54:02 PM Krzysztof Kozlowski wrote:
> Thermal core tries to read temperature during sensor registering in
> thermal_zone_of_sensor_register(). In that time Exynos TMU driver and
> hardware are not yet initialized. Commit 0eb875d88aaa ("thermal:
> exynos: Reading temperature makes sense only when TMU is turned on")
> added a boolean flag to prevent reading bogus temperature in such
> case but it exposed warning message during boot:
> [ 3.864913] thermal thermal_zone0: failed to read out thermal zone (-22)
>
> Return EAGAIN in such case to skip omitting such message because it
> might mislead user.
Hi Krzysztof,
I've fixed this in generic way a month ago:
https://lkml.org/lkml/2018/4/10/376
(there has been not much feedback on it yet)
However since my patchset is not v4.17 material:
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Eduardo, please queue it for v4.17 if possible, thanks.
> ---
> drivers/thermal/samsung/exynos_tmu.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
> index 3b20309789e3..c24969d740d1 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -666,8 +666,14 @@ static int exynos_get_temp(void *p, int *temp)
> struct exynos_tmu_data *data = p;
> int value, ret = 0;
>
> - if (!data || !data->tmu_read || !data->enabled)
> + if (!data || !data->tmu_read)
> return -EINVAL;
> + else if (!data->enabled)
> + /*
> + * Called too early, probably
> + * from thermal_zone_of_sensor_register().
> + */
> + return -EAGAIN;
>
> mutex_lock(&data->lock);
> clk_enable(data->clk);
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox