* [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
* [PATCH] ghes_edac: enable HIP08 platform edac driver
From: Borislav Petkov @ 2018-05-14 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb24735c-d251-4dd2-a02f-91e476776824@arm.com>
On Mon, May 14, 2018 at 04:12:08PM +0100, James Morse wrote:
> I'm afraid I'd like to keep both doors open. Kernel-first handling will require
> some ACPI-table/DT property as some aspects of the CPU extensions aren't
> discover-able. Can't we use this to pick up whether the platform supports
> firmware-first (HEST and GHES entries) or kernel-first via some as-yet-undefined
> HEST bits?
So how you detect those platforms is largely undefined as we're walking
new grounds here with the FF crap on the one hand and platform-specific
drivers on the other. So whatever works for you and as long as the
ugliness is nicely hidden. :-)
> Without GHES entries this code would never be run. So we 'just' need to catch
> systems that are describing both. (which can be the platform specific kernel
> first bits problem to do)
So the reason why we're doing this on x86 is that the majority of
GHES-advertizing platforms out there are a serious turd when it comes
to functioning fw.
So we've opted for known-good platforms list where there's backing from
the vendor to have firmware which is getting fixes and is being tested
properly.
And everything else we assume is crap. Thus we use the platform-specific
EDAC driver which we know it works and we can fix if there's an issue.
VS firmware which we can't. (I doubt anyone can, for that matter. :)...)
Anyway, this is the story in x86 land. JFYI guys in case it helps making
some decisions.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs
From: Chen-Yu Tsai @ 2018-05-14 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZAOVg6EZoMi=LRuKEcrnDM_tzYfK1WnBN-_d-pmjNS6Nw@mail.gmail.com>
On Mon, May 14, 2018 at 1:20 AM, Jagan Teki <jagan@amarulasolutions.com> wrote:
> On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki <jagan@amarulasolutions.com> wrote:
>>> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them
>>> as default.
>>>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>> drivers/clk/sunxi-ng/Kconfig | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
>>> index 79dfd296c3d1..1fffd3bf6ff3 100644
>>> --- a/drivers/clk/sunxi-ng/Kconfig
>>> +++ b/drivers/clk/sunxi-ng/Kconfig
>>> @@ -58,6 +58,8 @@ config SUN8I_V3S_CCU
>>>
>>> config SUN8I_DE2_CCU
>>> bool "Support for the Allwinner SoCs DE2 CCU"
>>> + default ARM64 && ARCH_SUNXI
>>> + depends on (DRM_SUN4I && (ARM64 && ARCH_SUNXI)) || COMPILE_TEST
>>
>> There is no reason to depend on DRM_SUN4I. There is no compile dependency.
>
> Since this CCU is for DE2 I've make DRM_SUN4I for that matter, any problem?
Users may very well be just using simplefb, but with all the clock drivers
enabled. That is a valid, if very limited, use case. So again, you should
not limit this driver based on DRM_SUN4I. There is no compile dependency.
>
>>
>> Also, this is needed on SUN8I as well, pretty much anything with DE 2.0.
>> So you shouldn't limit it to ARM64. That pretty much breaks things for
>> people with A83T's or H3's. In fact you should enable it by default for
>> these as well.
>
> True, I've skipped SUN8I since this series for A64.
And yet you are breaking existing users, which is a big no-no.
ChenYu
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Daniel Vetter @ 2018-05-14 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c25f81e0-5b7b-c605-5b58-0ecc88830124@axentia.se>
On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
> On 2018-05-10 10:10, Andrzej Hajda wrote:
> > On 04.05.2018 15:52, Peter Rosin wrote:
> >> If the bridge supplier is unbound, this will bring the bridge consumer
> >> down along with the bridge. Thus, there will no longer linger any
> >> dangling pointers from the bridge consumer (the drm_device) to some
> >> non-existent bridge supplier.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> >> ---
> >> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> >> include/drm/drm_bridge.h | 2 ++
> >> 2 files changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >> index 78d186b6831b..0259f0a3ff27 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -26,6 +26,7 @@
> >> #include <linux/mutex.h>
> >>
> >> #include <drm/drm_bridge.h>
> >> +#include <drm/drm_device.h>
> >> #include <drm/drm_encoder.h>
> >>
> >> #include "drm_crtc_internal.h"
> >> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> >> if (bridge->dev)
> >> return -EBUSY;
> >>
> >> + if (encoder->dev->dev != bridge->odev) {
> >
> > I wonder why device_link_add does not handle this case (self dependency)
> > silently as noop, as it seems to be a correct behavior.
>
> It's kind-of a silly corner-case though, so perfectly understandable
> that it isn't handled.
>
> >> + bridge->link = device_link_add(encoder->dev->dev,
> >> + bridge->odev, 0);
> >> + if (!bridge->link) {
> >> + dev_err(bridge->odev, "failed to link bridge to %s\n",
> >> + dev_name(encoder->dev->dev));
> >> + return -EINVAL;
> >> + }
> >> + }
> >> +
> >> bridge->dev = encoder->dev;
> >> bridge->encoder = encoder;
> >>
> >> if (bridge->funcs->attach) {
> >> ret = bridge->funcs->attach(bridge);
> >> if (ret < 0) {
> >> + if (bridge->link)
> >> + device_link_del(bridge->link);
> >> + bridge->link = NULL;
> >> bridge->dev = NULL;
> >> bridge->encoder = NULL;
> >> return ret;
> >> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >> if (bridge->funcs->detach)
> >> bridge->funcs->detach(bridge);
> >>
> >> + if (bridge->link)
> >> + device_link_del(bridge->link);
> >> + bridge->link = NULL;
> >> +
> >> bridge->dev = NULL;
> >> }
> >>
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index b656e505d11e..804189c63a4c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> >> * @list: to keep track of all added bridges
> >> * @timings: the timing specification for the bridge, if any (may
> >> * be NULL)
> >> + * @link: drm consumer <-> bridge supplier
> >
> > Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> > to the bridge" would be better.
>
> I meant "<->" to indicate that the link is bidirectional, not that the
> relationship is in any way symmetric. I wasn't aware of any implication
> of a symmetric relationship when using "<->", do you have a reference?
> But I guess the different arrow notations in math are somewhat overloaded
> and that someone at some point must have used "<->" to indicate a
> symmetric relationship...
Yeah I agree with Andrzej here, for me <-> implies a symmetric
relationship. Spelling it out like Andrzej suggested sounds like the
better idea.
-Daniel
>
> > Anyway:
> > Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
>
> Thanks!
>
> Cheers,
> Peter
>
> > ?--
> > Regards
> > Andrzej
> >
> >> * @funcs: control functions
> >> * @driver_private: pointer to the bridge driver's internal context
> >> */
> >> @@ -271,6 +272,7 @@ struct drm_bridge {
> >> struct drm_bridge *next;
> >> struct list_head list;
> >> const struct drm_bridge_timings *timings;
> >> + struct device_link *link;
> >>
> >> const struct drm_bridge_funcs *funcs;
> >> void *driver_private;
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [GIT PULL] Reset controller fixes for v4.17
From: Olof Johansson @ 2018-05-14 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526313274.4936.21.camel@pengutronix.de>
On Mon, May 14, 2018 at 05:54:34PM +0200, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.pengutronix.de/pza/linux.git tags/reset-fixes-for-4.17
>
> for you to fetch changes up to e6914365fd280fce303a89b8a8d4529af5a2e0f9:
>
> reset: uniphier: fix USB clock line for LD20 (2018-04-27 11:51:12 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.17 (#1)
From: Olof Johansson @ 2018-05-14 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zi123adf.fsf@bootlin.com>
On Mon, May 14, 2018 at 10:33:00AM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for fixes for mvebu for v4.17.
>
> Gregory
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.17-1
>
> for you to fetch changes up to f43194c1447c9536efb0859c2f3f46f6bf2b9154:
>
> ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node (2018-04-27 17:47:24 +0200)
>
> ----------------------------------------------------------------
> mvebu fixes for 4.17 (part 1)
>
> Declare missing clocks needed for network on Armada 8040 base boards
> (such as the McBin)
Thanks!
How well should I expect mcbin to work with a mainline kernel now? I
still use the 4.4 mcbin kernel on mine in "production" (I use one for
all my maintainer work). What's missing from that kernel on mainline?
-Olof
^ permalink raw reply
* [GIT PULL] firmware: scmi: updates for v4.18
From: Sudeep Holla @ 2018-05-14 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM-SoC team,
Please pull !
Regards,
Sudeep
--
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-4.18
for you to fetch changes up to 632de8f542bcd44c756637da0e7d824e7129e496:
firmware: arm_scmi: simplify exit path by returning on error (2018-05-10 10:52:00 +0100)
----------------------------------------------------------------
SCMI cleanups for v4.18
This contains all of the trivial review comments that were not
addressed as the series was already queued up for v4.17 and were not
critical to go as fixes.
They generally just improve code readability, fix kernel-docs, remove
unused/unnecessary code, follow standard function naming and simplifies
certain exit paths.
----------------------------------------------------------------
Sudeep Holla (8):
firmware: arm_scmi: improve code readability using bitfield accessor macros
firmware: arm_scmi: fix kernel-docs documentation
firmware: arm_scmi: rename get_transition_latency and add_opps_to_device
firmware: arm_scmi: rename scmi_xfer_{init,get,put}
firmware: arm_scmi: drop unused `con_priv` structure member
firmware: arm_scmi: remove unnecessary bitmap_zero
firmware: arm_scmi: improve exit paths and code readability
firmware: arm_scmi: simplify exit path by returning on error
drivers/cpufreq/scmi-cpufreq.c | 4 +-
drivers/firmware/arm_scmi/base.c | 43 +++++++-------
drivers/firmware/arm_scmi/bus.c | 22 ++++----
drivers/firmware/arm_scmi/clock.c | 24 ++++----
drivers/firmware/arm_scmi/common.h | 22 ++++----
drivers/firmware/arm_scmi/driver.c | 109 ++++++++++++++++++------------------
drivers/firmware/arm_scmi/perf.c | 38 ++++++-------
drivers/firmware/arm_scmi/power.c | 16 +++---
drivers/firmware/arm_scmi/sensors.c | 20 +++----
include/linux/scmi_protocol.h | 18 ++++--
10 files changed, 166 insertions(+), 150 deletions(-)
^ 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