Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v8 0/8] power: add power sequence library
From: Peter Chen @ 2016-10-17  1:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5097336.earU4jV2qd@vostro.rjw.lan>

On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > Hi all,
> > 
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> > 	 
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> > 
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> > 
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> > 
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > 
> > Changes for v8:
> > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> >   preallocate instances problem which the number of instance is decided at
> >   compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
> >   match method. [Patch 2/8]
> > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> > 
> > Changes for v7:
> > - Create kinds of power sequence instance at postcore_initcall, and match
> >   the instance with node using compatible string, the beneit of this is
> >   the host driver doesn't need to consider which pwrseq instance needs
> >   to be used, and pwrseq core will match it, however, it eats some memories
> >   if less power sequence instances are used. [Patch 2/8]
> > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> >   use device_node for parameters at pwrseq_on. [Patch 2/8]
> > - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> > - Tested three pwrseq instances together using both specific compatible string and
> >   generic libraries.
> > 
> > Changes for v6:
> > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > - Applies Joshua Clayton's three dts changes for two boards,
> >   the USB device's reg has only #address-cells, but without #size-cells.
> > 
> > Changes for v5:
> > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > - Fix the linker error when the pwrseq user is compiled as module
> > 
> > Changes for v4:
> > - Create the patch on next-20160722 
> > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> > - Using more friendly wait method for reset gpio [Patch 2/6]
> > - Support multiple input clocks [Patch 2/6]
> > - Add Rob Herring's ack for DT changes
> > - Add Joshua Clayton's Tested-by
> > 
> > Changes for v3:
> > - Delete "power-sequence" property at binding-doc, and change related code
> >   at both library and user code.
> > - Change binding-doc example node name with Rob's comments
> > - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> >   add additional code request gpio with proper gpio flags
> > - Add Philipp Zabel's Ack and MAINTAINER's entry
> > 
> > Changes for v2:
> > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > - Should use structure not but its pointer for kzalloc
> > - Since chipidea core has no of_node, let core's of_node equals glue
> >   layer's at core's probe
> > 
> > Joshua Clayton (2):
> >   ARM: dts: imx6qdl: Enable usb node children with <reg>
> >   ARM: dts: imx6q-evi: Fix onboard hub reset line
> > 
> > Peter Chen (6):
> >   binding-doc: power: pwrseq-generic: add binding doc for generic power
> >     sequence library
> >   power: add power sequence library
> >   binding-doc: usb: usb-device: add optional properties for power
> >     sequence
> >   usb: core: add power sequence handling for USB devices
> >   usb: chipidea: let chipidea core device of_node equal's glue layer
> >     device of_node
> >   ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
> > 
> >  .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
> >  .../devicetree/bindings/usb/usb-device.txt         |  10 +-
> >  MAINTAINERS                                        |   9 +
> >  arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
> >  arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++-
> >  arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
> >  drivers/power/Kconfig                              |   1 +
> >  drivers/power/Makefile                             |   1 +
> >  drivers/power/pwrseq/Kconfig                       |  19 ++
> >  drivers/power/pwrseq/Makefile                      |   2 +
> >  drivers/power/pwrseq/core.c                        | 191 +++++++++++++++++++++
> >  drivers/power/pwrseq/pwrseq_generic.c              | 183 ++++++++++++++++++++
> >  drivers/usb/chipidea/core.c                        |  27 ++-
> >  drivers/usb/core/hub.c                             |  41 ++++-
> >  drivers/usb/core/hub.h                             |   1 +
> >  include/linux/power/pwrseq.h                       |  72 ++++++++
> >  16 files changed, 621 insertions(+), 41 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >  create mode 100644 drivers/power/pwrseq/Kconfig
> >  create mode 100644 drivers/power/pwrseq/Makefile
> >  create mode 100644 drivers/power/pwrseq/core.c
> >  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> >  create mode 100644 include/linux/power/pwrseq.h
> 
> Meta question: Who's the maintainer you are targetting this at?
> 

Sebastian Reichel mentioned it is better through your tree.
I could be the maintainer for it, and send "GIT PULL" for you
through my git
(https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/)
Is it ok for you?

-- 

Best Regards,
Peter Chen

^ permalink raw reply

* rockchip: drm: analogix_dp-rockchip would stock the kernel
From: Randy Li @ 2016-10-17  1:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <580421E5.9030609@rock-chips.com>



On 10/17/2016 08:57 AM, Mark yao wrote:
> On 2016?10?16? 02:03, ayaka wrote:
>> Hello:
>>    I meet a problem with eDP in rk3288 with the linux next 20161006,
>> it is just like the early stage of 4.4
>> kernel.  I have added a eDP panel entry in the firefly reload board,
>> once the kernel loaded analogix_dp-rockchip.ko, after printed the
>> following two lines, the kernel stop working.
>> rockchip-drm display-subsystem: bound ff940000.vop (ops
>> vop_component_ops [rockchipdrm])
>> rockchip-drm display-subsystem: bound ff930000.vop (ops
>> vop_component_ops [rockchipdrm])
>
> Hi ayaka
>
> This log seems no problem.
I found the problem, it is the eDP_AVDD_1V0 and eDP_AVDD_1V8 must have a 
proper power supply. I would submit a patch to enable the regulator at 
DP driver.
>
> How about tested it with build-in? we had test it with build-in.
>
> Maybe this patch can help you, you can have a try.
>     https://patchwork.kernel.org/patch/9374135
>
> Thanks.
>
>> In the early June of the 4.4 kernel, I meet the same problem with
>> rk3288 evb board with different error message, I have to disable the
>> display system that time.
>>   In the today test, I meet the same problem with rk3399 evb board in
>> 4.4.
>>   I have no idea what caused that, and it is a little hard to debug as
>> kernel still would never kill that task.
>>                                                             Randy Li
>>
>>
>>
>
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================

^ permalink raw reply

* rockchip: drm: analogix_dp-rockchip would stock the kernel
From: Mark yao @ 2016-10-17  0:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1a7ebbe4-a9d8-610d-7cd5-41f5fe8355a5@soulik.info>

On 2016?10?16? 02:03, ayaka wrote:
> Hello:
>    I meet a problem with eDP in rk3288 with the linux next 20161006, 
> it is just like the early stage of 4.4
> kernel.  I have added a eDP panel entry in the firefly reload board, 
> once the kernel loaded analogix_dp-rockchip.ko, after printed the 
> following two lines, the kernel stop working.
> rockchip-drm display-subsystem: bound ff940000.vop (ops 
> vop_component_ops [rockchipdrm])
> rockchip-drm display-subsystem: bound ff930000.vop (ops 
> vop_component_ops [rockchipdrm])

Hi ayaka

This log seems no problem.

How about tested it with build-in? we had test it with build-in.

Maybe this patch can help you, you can have a try.
     https://patchwork.kernel.org/patch/9374135

Thanks.

> In the early June of the 4.4 kernel, I meet the same problem with 
> rk3288 evb board with different error message, I have to disable the 
> display system that time.
>   In the today test, I meet the same problem with rk3399 evb board in 
> 4.4.
>   I have no idea what caused that, and it is a little hard to debug as 
> kernel still would never kill that task.
>                                                             Randy Li
>
>
>


-- 
?ark Yao

^ permalink raw reply

* [PATCH] watchdog: at91sam9: keep watchdog running in idle mode
From: Sylvain Rochet @ 2016-10-16 20:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <59c665f8-de09-c11c-f62a-5064016cd8fd@roeck-us.net>

Hi Guenter,

On Sun, Oct 16, 2016 at 08:55:41AM -0700, Guenter Roeck wrote:
> On 10/16/2016 08:50 AM, Guenter Roeck wrote:
> > On 10/16/2016 08:33 AM, Sylvain Rochet wrote:
> > > 
> > > Looks like this one falls through the cracks, it didn't reach mainline
> > > and therefore wasn't applied to stable branches.
> > 
> > Possibly that happened because you did not copy the watchdog mailing list.
> 
> ... and your other patches were not sent to the watchdog mailing list either,
> so you should not expect them to be picked up either.
> 
> Seriously, how do you expect _any_ patch to be picked up if you neither copy
> the subsystem mailing list nor the subsystem maintainer ?

Whoops, thanks for the heads up, I wonder how I managed to mess up that 
at that time, I usually take care of that. The other series need 
respinning anyway so I can fix it for v2 (if any).

Cheers,
Sylvain

^ permalink raw reply

* RK3288 USB issues with ath9k_htc Wi-Fi dongles on veyron devices
From: Paul Kocialkowski @ 2016-10-16 20:01 UTC (permalink / raw)
  To: linux-arm-kernel

I'm trying to use ath9k_htc Wi-Fi dongles with various rk3288 veyron devices,
which currently do not work.

I have a bunch of different dongles, that all work nicely with other devices.
The kernel I'm running is 4.9-rc1 and the USB connectors I'm using are linked to
OTG and HOST1 (both DWC2 controllers).

I have applied the latest version of Randy Li's patches, that fix an USB error
with these controllers. They do not fix my issue, or otherwise change the
behavior I'm seeing. The very same device running with the chromeos-3.14 kernel
works nicely and doesn't have this issue.

There are two different cases, that happen interchangeably and randomly:

1. The dongle is detected and the driver is probed but the first register reads
fail:

[??322.841142] usb 2-1: new high-speed USB device number 3 using dwc2
[??323.104591] usb 2-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[??323.113489] usb 2-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[??323.122204] usb 2-1: ath9k_htc: Firmware htc_9271.fw requested
[??323.414012] usb 2-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
[??323.665556] ath9k_htc 2-1:1.0: ath9k_htc: HTC initialized with 33 credits
[??324.710992] ath: phy1: Timeout waiting for WMI command: WMI_REG_READ_CMDID
[??324.717899] ath: phy1: REGISTER READ FAILED: (0x4020, -110)
[??324.723525] ath: phy1: Mac Chip Rev 0x0f.3 is not supported by this driver
[??324.730416] ath: phy1: Unable to initialize hardware; initialization status: -95
[??324.737853] ath: phy1: Unable to initialize hardware; initialization status: -95
[??324.745296] ath9k_htc: Failed to initialize the device
[??324.755440] usb 2-1: ath9k_htc: USB layer deinitialized

2. The dongle is detected, the first few register reads succeed but register
reads fail as soon as the dongle enters power-saving mode:

[???68.070377] ath: phy0: Removed a station entry for VIF 0 (idx: 0)
[???68.078752] ath: phy0: Detach Interface at idx: 0
[???68.085260] ath: phy0: AWAKE -> FULL-SLEEP
[???68.090766] ath: phy0: FULL-SLEEP -> AWAKE
[???68.107512] ath: phy0: AWAKE -> FULL-SLEEP
[???68.112756] ath: phy0: Driver halt
[???68.117108] ath: phy0: Starting driver with initial channel: 2412 MHz
[???68.123577] ath: phy0: FULL-SLEEP -> AWAKE
[???69.191104] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID
[???69.197987] ath: phy0: REGISTER READ FAILED: (0x7044, -110)
[???70.231015] ath: phy0: Timeout waiting for WMI command: WMI_REG_RMW_CMDID

What could be causing these issues?

Cheers!

-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161016/1b55bd2d/attachment.sig>

^ permalink raw reply

* [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.
From: Paul Kocialkowski @ 2016-10-16 19:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87twd1vzc5.fsf@aikidev.net>

Hi,

Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit?:
> This essentially mimics what was done with rk3288-veyron-minnie in
> commit 984926781122f034d5bc9962815d135b6c4a8e1d.
> 
> The eMMC of the speedy Chromebook also appears to need the same tuning
> workaround, as it frequently fails to recognize the eMMC without it.

I have a device where (without this patch) eMMC sometimes fails, with:
[????3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 175
[????3.571742] mmc2: new HS200 MMC card at address 0001
[????3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
[????3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
[????3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
[????3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
[????3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0

And sometimes works, with:
[????3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 176
[????3.491093] mmc2: new HS200 MMC card at address 0001
[????3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
[????3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
[????3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
[????3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
[????3.493548]??mmcblk2: p1 p2

However, with this change, it always fails, with:
[????3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[????3.333174] mmc2: error -110 whilst initialising MMC card

I don't have so much time to investigate this issue, but it's clear that this
patch doesn't fix the issue (and actually worsens it) for my device.

Cheers!

> Signed-off-by: Vagrant Cascadian <vagrantc@aikidev.net>
> ---
> Changes in v2:
> ?- Added Signed-off-by.
> 
> ?arch/arm/boot/dts/rk3288-veyron-speedy.dts | 5 +++++
> ?1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> index a0d033f..500fd18 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -124,6 +124,11 @@
> ????????????&sdmmc_bus4>;
> ?};
> 
> +
> +&emmc {
> +???????/delete-property/mmc-hs200-1_8v;
> +};
> +
> ?&vcc_5v {
> ????enable-active-high;
> ????gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161016/6ae8dfd0/attachment.sig>

^ permalink raw reply

* [PATCH] ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: SF Markus Elfring @ 2016-10-16 19:03 UTC (permalink / raw)
  To: linux-arm-kernel

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 16 Oct 2016 20:48:28 +0200

Some data were printed into a sequence by six separate function calls.
Print the same data by a single function call instead.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 arch/arm64/kernel/cpuinfo.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index b3d5b3e..f22687d 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -148,14 +148,17 @@ static int c_show(struct seq_file *m, void *v)
 				if (elf_hwcap & (1 << j))
 					seq_printf(m, " %s", hwcap_str[j]);
 		}
-		seq_puts(m, "\n");
-
-		seq_printf(m, "CPU implementer\t: 0x%02x\n",
-			   MIDR_IMPLEMENTOR(midr));
-		seq_printf(m, "CPU architecture: 8\n");
-		seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
-		seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
-		seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
+		seq_printf(m,
+			   "\n"
+			   "CPU implementer\t: 0x%02x\n"
+			   "CPU architecture: 8\n"
+			   "CPU variant\t: 0x%x\n"
+			   "CPU part\t: 0x%03x\n"
+			   "CPU revision\t: %d\n\n",
+			   MIDR_IMPLEMENTOR(midr),
+			   MIDR_VARIANT(midr),
+			   MIDR_PARTNUM(midr),
+			   MIDR_REVISION(midr));
 	}
 
 	return 0;
-- 
2.10.1

^ permalink raw reply related

* [PATCH] ARM: at91/dt: pullup dbgu rx instead of tx
From: Sylvain Rochet @ 2016-10-16 16:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6d2d5aba-cca3-93c6-0c59-3acbbd7b6169@lysator.liu.se>

Hi Peter,

On Sun, Oct 16, 2016 at 12:57:09PM +0200, Peter Rosin wrote:
> Hi again,
> 
> I forgot about this, and it's been a year. But isn't it time to
> upstream those pull-up fixes that Sylvain provided?

Thank you for your reminder, actually I waited an answer on this nice 
subject: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368643.html

But this is not relevant for this change anyway, if we should set a 
pull-(up|down) on all push-pull pads to reduce power consumption it 
should be enforced in the pinctrl driver, the dt must stay logical.

I just sent a v2 with all useless comments removed as suggested by 
Alexandre and without the explanation about the removed extra power 
consumption when removing a pull-(up|down) on a push-pull output because 
it does even seem to be the contrary on Atmel SoCs.

Sylvain

^ permalink raw reply

* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Sylvain Rochet @ 2016-10-16 16:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161016162145.26193-1-sylvain.rochet@finsecur.com>

Remove pullup on dbgu DTXD signal, it is a push-pull output thus the
pullup is pointless.

Add pullup on dbgu DRXD signal, it prevents the DRXD signal to be left
floating and so consuming a useless extra amount of power in crowbarred
state if nothing is externally connected to dbgu.

Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
---
 arch/arm/boot/dts/at91rm9200.dtsi  | 4 ++--
 arch/arm/boot/dts/at91sam9260.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9261.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9263.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9n12.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9rl.dtsi  | 4 ++--
 arch/arm/boot/dts/at91sam9x5.dtsi  | 4 ++--
 arch/arm/boot/dts/sama5d3.dtsi     | 4 ++--
 arch/arm/boot/dts/sama5d4.dtsi     | 4 ++--
 10 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
index 4e913c2..f057e0b 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -481,8 +481,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA30 periph A */
-							 AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PA31 periph with pullup */
+							<AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index a3e363d..9e035b2 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -412,8 +412,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB14 periph A */
-							 AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PB15 periph with pullup */
+							<AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9261.dtsi b/arch/arm/boot/dts/at91sam9261.dtsi
index 32752d7..3fe77c3 100644
--- a/arch/arm/boot/dts/at91sam9261.dtsi
+++ b/arch/arm/boot/dts/at91sam9261.dtsi
@@ -302,8 +302,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOA 9  AT91_PERIPH_A AT91_PINCTRL_NONE>,
-							<AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
+							<AT91_PIOA 9  AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
+							<AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index aeb1a36..a1888f6 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -412,8 +412,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOC 30 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC30 periph A */
-							 AT91_PIOC 31 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PC31 periph with pullup */
+							<AT91_PIOC 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOC 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index b3501ae..e567d5f 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -478,8 +478,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB12 periph A */
-							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB13 periph A */
+							<AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 3b3eb3e..f43d769 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -500,8 +500,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA9 periph A */
-							 AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PA10 periph with pullup */
+							<AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9rl.dtsi b/arch/arm/boot/dts/at91sam9rl.dtsi
index 70adf94..f4c129a 100644
--- a/arch/arm/boot/dts/at91sam9rl.dtsi
+++ b/arch/arm/boot/dts/at91sam9rl.dtsi
@@ -438,8 +438,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOA 21 AT91_PERIPH_A AT91_PINCTRL_NONE>,
-							<AT91_PIOA 22 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
+							<AT91_PIOA 21 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
+							<AT91_PIOA 22 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index ed4e4bd..f66bae9 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -460,8 +460,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA9 periph A */
-							 AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PA10 periph A with pullup */
+							<AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 4c84d33..b06448b 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -549,8 +549,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB30 periph A */
-							 AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PB31 periph A with pullup */
+							<AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 65e725f..d136ebd 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1461,8 +1461,8 @@
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
-							<AT91_PIOB 24 AT91_PERIPH_A AT91_PINCTRL_NONE>,     /* conflicts with D14 and TDI */
-							<AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;  /* conflicts with D15 and TDO */
+							<AT91_PIOB 24 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+							 AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE>;
 					};
 				};
 
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Sylvain Rochet @ 2016-10-16 16:21 UTC (permalink / raw)
  To: linux-arm-kernel

Changes since v1:
  * While we are at it, remove useless pinctrl comments, as suggested
    by Alexandre.
  * Remove consumption story about the pull-up on a push-pull output
    in the commit message, it does not seem to be the case, or rather
    the contrary, as per
    http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368643.html
    results, the dt must be logical anyway.

Sylvain Rochet (1):
  ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx

 arch/arm/boot/dts/at91rm9200.dtsi  | 4 ++--
 arch/arm/boot/dts/at91sam9260.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9261.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9263.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9n12.dtsi | 4 ++--
 arch/arm/boot/dts/at91sam9rl.dtsi  | 4 ++--
 arch/arm/boot/dts/at91sam9x5.dtsi  | 4 ++--
 arch/arm/boot/dts/sama5d3.dtsi     | 4 ++--
 arch/arm/boot/dts/sama5d4.dtsi     | 4 ++--
 10 files changed, 20 insertions(+), 20 deletions(-)

-- 
2.9.3

^ permalink raw reply

* [PATCH] watchdog: at91sam9: keep watchdog running in idle mode
From: Guenter Roeck @ 2016-10-16 15:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <67fe262e-31e4-b9dc-da71-af601079bfec@roeck-us.net>

On 10/16/2016 08:50 AM, Guenter Roeck wrote:
> On 10/16/2016 08:33 AM, Sylvain Rochet wrote:
>> Hi,
>>
>> On Wed, Oct 07, 2015 at 01:01:12PM +0200, Alexandre Belloni wrote:
>>> On 06/10/2015 at 22:28:45 +0200, Sylvain Rochet wrote :
>>>> Since turning on idle-halt in commit 5161b31dc39a (watchdog:
>>>> at91sam9_wdt: better watchdog support"), SoCs compatible with
>>>> at91sam9260-wdt not using a device tree no longer reboot if the watchdog
>>>> times out while the CPU is in idle state. Removing the
>>>> AT91_WDT_WDIDLEHLT flag that was set by default fixes this.
>>>>
>>>> Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
>>>> Fixes: 5161b31dc39a ("watchdog: at91sam9_wdt: better watchdog support")
>>>> Cc: <stable@vger.kernel.org> # 3.14+
>>>
>>> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>
>>> However, we don't really care about that for kernels after 3.18 as no
>>> users are using pdata anymore.
>>> I think you could send a follow-up patch removing pdata support
>>> completely.
>>
>> Looks like this one falls through the cracks, it didn't reach mainline
>> and therefore wasn't applied to stable branches.
>>
> Possibly that happened because you did not copy the watchdog mailing list.
>

... and your other patches were not sent to the watchdog mailing list either,
so you should not expect them to be picked up either.

Seriously, how do you expect _any_ patch to be picked up if you neither copy
the subsystem mailing list nor the subsystem maintainer ?

Guenter

^ permalink raw reply

* [PATCH] watchdog: at91sam9: keep watchdog running in idle mode
From: Guenter Roeck @ 2016-10-16 15:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161016153316.rsrcgnki6kn7gola@finsecur.com>

On 10/16/2016 08:33 AM, Sylvain Rochet wrote:
> Hi,
>
> On Wed, Oct 07, 2015 at 01:01:12PM +0200, Alexandre Belloni wrote:
>> On 06/10/2015 at 22:28:45 +0200, Sylvain Rochet wrote :
>>> Since turning on idle-halt in commit 5161b31dc39a (watchdog:
>>> at91sam9_wdt: better watchdog support"), SoCs compatible with
>>> at91sam9260-wdt not using a device tree no longer reboot if the watchdog
>>> times out while the CPU is in idle state. Removing the
>>> AT91_WDT_WDIDLEHLT flag that was set by default fixes this.
>>>
>>> Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
>>> Fixes: 5161b31dc39a ("watchdog: at91sam9_wdt: better watchdog support")
>>> Cc: <stable@vger.kernel.org> # 3.14+
>>
>> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>
>> However, we don't really care about that for kernels after 3.18 as no
>> users are using pdata anymore.
>> I think you could send a follow-up patch removing pdata support
>> completely.
>
> Looks like this one falls through the cracks, it didn't reach mainline
> and therefore wasn't applied to stable branches.
>
Possibly that happened because you did not copy the watchdog mailing list.

Guenter

> I just checked, it still apply properly on today's linux-next branch.
>
> Cheers,
> Sylvain
>

^ permalink raw reply

* [PATCH 2/2] ARM: dts: uniphier: increase register region size of sysctrl node
From: Masahiro Yamada @ 2016-10-16 15:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476632563-7446-1-git-send-email-yamada.masahiro@socionext.com>

The System Control node has 0x10000 byte of registers.  The current
reg size must be expanded to use the cpufreq driver because the
registers controlling CPU frequency are located at offset 0x8000.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm/boot/dts/uniphier-common32.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi b/arch/arm/boot/dts/uniphier-common32.dtsi
index 8c8a851..d067f38 100644
--- a/arch/arm/boot/dts/uniphier-common32.dtsi
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -183,7 +183,7 @@
 		sysctrl at 61840000 {
 			compatible = "socionext,uniphier-sysctrl",
 				     "simple-mfd", "syscon";
-			reg = <0x61840000 0x4000>;
+			reg = <0x61840000 0x10000>;
 
 			sys_clk: clock {
 				#clock-cells = <1>;
-- 
1.9.1

^ permalink raw reply related

* [PATCH 1/2] arm64: dts: uniphier: increase register region size of sysctrl node
From: Masahiro Yamada @ 2016-10-16 15:42 UTC (permalink / raw)
  To: linux-arm-kernel

The System Control node has 0x10000 byte of registers.  The current
reg size must be expanded to use the cpufreq driver because the
registers controlling CPU frequency are located at offset 0x8000.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 +-
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 3eb4c42..da3cdd8 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -320,7 +320,7 @@
 		sysctrl at 61840000 {
 			compatible = "socionext,uniphier-ld11-sysctrl",
 				     "simple-mfd", "syscon";
-			reg = <0x61840000 0x4000>;
+			reg = <0x61840000 0x10000>;
 
 			sys_clk: clock {
 				compatible = "socionext,uniphier-ld11-clock";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 08fd7cf..efb47ea 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -311,7 +311,7 @@
 		sysctrl at 61840000 {
 			compatible = "socionext,uniphier-sysctrl",
 				     "simple-mfd", "syscon";
-			reg = <0x61840000 0x4000>;
+			reg = <0x61840000 0x10000>;
 
 			sys_clk: clock {
 				compatible = "socionext,uniphier-ld20-clock";
-- 
1.9.1

^ permalink raw reply related

* [PATCH] watchdog: at91sam9: keep watchdog running in idle mode
From: Sylvain Rochet @ 2016-10-16 15:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20151007110112.GD3485@piout.net>

Hi,

On Wed, Oct 07, 2015 at 01:01:12PM +0200, Alexandre Belloni wrote:
> On 06/10/2015 at 22:28:45 +0200, Sylvain Rochet wrote :
> > Since turning on idle-halt in commit 5161b31dc39a (watchdog:
> > at91sam9_wdt: better watchdog support"), SoCs compatible with
> > at91sam9260-wdt not using a device tree no longer reboot if the watchdog
> > times out while the CPU is in idle state. Removing the
> > AT91_WDT_WDIDLEHLT flag that was set by default fixes this.
> > 
> > Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
> > Fixes: 5161b31dc39a ("watchdog: at91sam9_wdt: better watchdog support")
> > Cc: <stable@vger.kernel.org> # 3.14+
> 
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> 
> However, we don't really care about that for kernels after 3.18 as no
> users are using pdata anymore.
> I think you could send a follow-up patch removing pdata support
> completely.

Looks like this one falls through the cracks, it didn't reach mainline 
and therefore wasn't applied to stable branches.

I just checked, it still apply properly on today's linux-next branch.

Cheers,
Sylvain

^ permalink raw reply

* [PATCH] ARM/orion/gpio: Replace three seq_printf() calls by seq_puts() in orion_gpio_dbg_show()
From: Andrew Lunn @ 2016-10-16 15:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <92ba3c30-386a-bb86-623d-0917cd9e61a2@users.sourceforge.net>

On Sun, Oct 16, 2016 at 12:38:26PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 16 Oct 2016 12:30:48 +0200
> 
> Strings which did not contain data format specifications should be put
> into a sequence. Thus use the corresponding function "seq_puts".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* [PATCH] clk: uniphier: fix type of variable passed to regmap_read()
From: Masahiro Yamada @ 2016-10-16 15:25 UTC (permalink / raw)
  To: linux-arm-kernel

The 3rd argument of regmap_read() takes a pointer to unsigned int.
This driver is saved just because u32 happens to be typedef'ed as
unsigned int, but we should not rely on that fact.  Change the
variable type just in case.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
index 15a2f2c..2c243a8 100644
--- a/drivers/clk/uniphier/clk-uniphier-mux.c
+++ b/drivers/clk/uniphier/clk-uniphier-mux.c
@@ -42,7 +42,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
 	struct uniphier_clk_mux *mux = to_uniphier_clk_mux(hw);
 	int num_parents = clk_hw_get_num_parents(hw);
 	int ret;
-	u32 val;
+	unsigned int val;
 	u8 i;
 
 	ret = regmap_read(mux->regmap, mux->reg, &val);
-- 
1.9.1

^ permalink raw reply related

* [PATCH] clk: uniphier: add system clock support for sLD3 SoC
From: Masahiro Yamada @ 2016-10-16 15:11 UTC (permalink / raw)
  To: linux-arm-kernel

I do not know why, but I missed to add this compatible string in
the initial commit of this driver.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 drivers/clk/uniphier/clk-uniphier-core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
index 5ffb898..f4e0f6b 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -111,6 +111,10 @@ static int uniphier_clk_remove(struct platform_device *pdev)
 static const struct of_device_id uniphier_clk_match[] = {
 	/* System clock */
 	{
+		.compatible = "socionext,uniphier-sld3-clock",
+		.data = uniphier_sld3_sys_clk_data,
+	},
+	{
 		.compatible = "socionext,uniphier-ld4-clock",
 		.data = uniphier_ld4_sys_clk_data,
 	},
-- 
1.9.1

^ permalink raw reply related

* [PATCH 3/3] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC
From: Masahiro Yamada @ 2016-10-16 14:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476629958-25368-1-git-send-email-yamada.masahiro@socionext.com>

Add a CPU clock to every CPU node and CPU OPP tables to use the
generic cpufreq driver.  All the CPUs in each cluster share the
same OPP table.

Note:
clock-latency-ns (300ns) was calculated based on the CPU-gear switch
sequencer spec; it takes 12 clock cycles on the sequencer running
at 50 MHz, plus a bit additional latency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 84 ++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 6f48e82..0ebcdbb 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -79,28 +79,36 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a72", "arm,armv8";
 			reg = <0 0x000>;
+			clocks = <&sys_clk 32>;
 			enable-method = "psci";
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		cpu1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a72", "arm,armv8";
 			reg = <0 0x001>;
+			clocks = <&sys_clk 32>;
 			enable-method = "psci";
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		cpu2: cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x100>;
+			clocks = <&sys_clk 33>;
 			enable-method = "psci";
+			operating-points-v2 = <&cluster1_opp>;
 		};
 
 		cpu3: cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x101>;
+			clocks = <&sys_clk 33>;
 			enable-method = "psci";
+			operating-points-v2 = <&cluster1_opp>;
 		};
 	};
 
@@ -109,6 +117,82 @@
 		method = "smc";
 	};
 
+	cluster0_opp: opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp at 250000000 {
+			opp-hz = /bits/ 64 <250000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 275000000 {
+			opp-hz = /bits/ 64 <275000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 550000000 {
+			opp-hz = /bits/ 64 <550000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 666666666 {
+			opp-hz = /bits/ 64 <666667000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 733333333 {
+			opp-hz = /bits/ 64 <733334000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 1100000000 {
+			opp-hz = /bits/ 64 <1100000000>;
+			clock-latency-ns = <300>;
+		};
+	};
+
+	cluster1_opp: opp_table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp at 250000000 {
+			opp-hz = /bits/ 64 <250000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 275000000 {
+			opp-hz = /bits/ 64 <275000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 550000000 {
+			opp-hz = /bits/ 64 <550000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 666666666 {
+			opp-hz = /bits/ 64 <666667000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 733333333 {
+			opp-hz = /bits/ 64 <733334000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 1100000000 {
+			opp-hz = /bits/ 64 <1100000000>;
+			clock-latency-ns = <300>;
+		};
+	};
+
 	clocks {
 		refclk: ref {
 			compatible = "fixed-clock";
-- 
1.9.1

^ permalink raw reply related

* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Masahiro Yamada @ 2016-10-16 14:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476629958-25368-1-git-send-email-yamada.masahiro@socionext.com>

Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.

Note:
clock-latency-ns (300ns) was calculated based on the CPU-gear switch
sequencer spec; it takes 12 clock cycles on the sequencer running
at 50 MHz, plus a bit additional latency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 38 ++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 73e0acf..e3eb10f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -70,14 +70,18 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x000>;
+			clocks = <&sys_clk 33>;
 			enable-method = "psci";
+			operating-points-v2 = <&cluster0_opp>;
 		};
 
 		cpu1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x001>;
+			clocks = <&sys_clk 33>;
 			enable-method = "psci";
+			operating-points-v2 = <&cluster0_opp>;
 		};
 	};
 
@@ -86,6 +90,40 @@
 		method = "smc";
 	};
 
+	cluster0_opp: opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp at 245000000 {
+			opp-hz = /bits/ 64 <245000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 250000000 {
+			opp-hz = /bits/ 64 <250000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 490000000 {
+			opp-hz = /bits/ 64 <490000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 653333333 {
+			opp-hz = /bits/ 64 <653334000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 666666666 {
+			opp-hz = /bits/ 64 <666667000>;
+			clock-latency-ns = <300>;
+		};
+		opp at 980000000 {
+			opp-hz = /bits/ 64 <980000000>;
+			clock-latency-ns = <300>;
+		};
+	};
+
 	clocks {
 		refclk: ref {
 			compatible = "fixed-clock";
-- 
1.9.1

^ permalink raw reply related

* [PATCH 1/3] arm64: dts: uniphier: switch over to PSCI enable method
From: Masahiro Yamada @ 2016-10-16 14:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476629958-25368-1-git-send-email-yamada.masahiro@socionext.com>

At the first system bring-up, I chose to use spin-table because ARM
Trusted Firmware was not ready for this platform at that moment.

Actually, these SoCs are equipped with EL3 and able to provide PSCI.
Now I finished porting the ATF BL31 for the UniPhier platform, so it
is ready to migrate to PSCI enable method.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 13 ++++++++-----
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 19 ++++++++++---------
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index da3cdd8..73e0acf 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -43,7 +43,7 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-/memreserve/ 0x80000000 0x00000008;	/* cpu-release-addr */
+/memreserve/ 0x80000000 0x00080000;
 
 / {
 	compatible = "socionext,uniphier-ld11";
@@ -70,19 +70,22 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x000>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0 0x80000000>;
+			enable-method = "psci";
 		};
 
 		cpu1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x001>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0 0x80000000>;
+			enable-method = "psci";
 		};
 	};
 
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
 	clocks {
 		refclk: ref {
 			compatible = "fixed-clock";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index efb47ea..6f48e82 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -43,7 +43,7 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-/memreserve/ 0x80000000 0x00000008;	/* cpu-release-addr */
+/memreserve/ 0x80000000 0x00080000;
 
 / {
 	compatible = "socionext,uniphier-ld20";
@@ -79,35 +79,36 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a72", "arm,armv8";
 			reg = <0 0x000>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0 0x80000000>;
+			enable-method = "psci";
 		};
 
 		cpu1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a72", "arm,armv8";
 			reg = <0 0x001>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0 0x80000000>;
+			enable-method = "psci";
 		};
 
 		cpu2: cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x100>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0 0x80000000>;
+			enable-method = "psci";
 		};
 
 		cpu3: cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0 0x101>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0 0x80000000>;
+			enable-method = "psci";
 		};
 	};
 
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
 	clocks {
 		refclk: ref {
 			compatible = "fixed-clock";
-- 
1.9.1

^ permalink raw reply related

* [PATCH 0/3] arm64: dts: uniphier: switch to PSCI, DT-side support for cpufreq driver
From: Masahiro Yamada @ 2016-10-16 14:59 UTC (permalink / raw)
  To: linux-arm-kernel

The UniPhier clock driver was merged, and now ARM Trusted Firmware
poring was finished.

Now, I can upstream more features with this platform.



Masahiro Yamada (3):
  arm64: dts: uniphier: switch over to PSCI enable method
  arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
  arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi |  51 +++++++++--
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 103 +++++++++++++++++++++--
 2 files changed, 140 insertions(+), 14 deletions(-)

-- 
1.9.1

^ permalink raw reply

* [PATCH v2] ARM: dts: imx6sx: Add UDOO Neo support
From: Andreas Färber @ 2016-10-16 14:44 UTC (permalink / raw)
  To: linux-arm-kernel

Add initial device trees for UDOO Neo Basic, Extended and Full boards:
* Serial console is enabled, other serial ports are prepared.
* I2C based PMIC is enabled.
* Ethernet is enabled for Basic and Full.
* SDHC is enabled, with the SDIO_PWR GPIO modeled as a regulator.
* Both user LEDs are enabled, with the orange one reserved for the M4
  and with the SD card as default trigger for the red LED.

The decision on a board compatible string is deferred to later.

Cc: Ettore Chimenti <ettore.chimenti@udoo.org>
Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 v1 -> v2:
 * Dropped iomuxc imx6sx-udoo-neo subnode (Uwe)
 * Reordered status property (Shawn)
 * Used vmmc-supply and dropped always-on (Shawn)
 * Fixed fec1 reset gpio (Uwe)
 
 arch/arm/boot/dts/Makefile                     |   5 +-
 arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts    |  69 ++++++
 arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts |  54 +++++
 arch/arm/boot/dts/imx6sx-udoo-neo-full.dts     |  69 ++++++
 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi         | 293 +++++++++++++++++++++++++
 5 files changed, 489 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
 create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts
 create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo-full.dts
 create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..259117a97f28 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -416,7 +416,10 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
 	imx6sx-sabreauto.dtb \
 	imx6sx-sdb-reva.dtb \
 	imx6sx-sdb-sai.dtb \
-	imx6sx-sdb.dtb
+	imx6sx-sdb.dtb \
+	imx6sx-udoo-neo-basic.dtb \
+	imx6sx-udoo-neo-extended.dtb \
+	imx6sx-udoo-neo-full.dtb
 dtb-$(CONFIG_SOC_IMX6UL) += \
 	imx6ul-14x14-evk.dtb \
 	imx6ul-geam-kit.dtb \
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts b/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
new file mode 100644
index 000000000000..0b888789efc6
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
+ * 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 library 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 library 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.
+ */
+
+/dts-v1/;
+
+#include "imx6sx-udoo-neo.dtsi"
+
+/ {
+	model = "UDOO Neo Basic";
+	compatible = "fsl,imx6sx";
+
+	memory {
+		reg = <0x80000000 0x20000000>;
+	};
+};
+
+&fec1 {
+	phy-handle = <&ethphy1>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy1: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts b/arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts
new file mode 100644
index 000000000000..d6fdd17cd3ac
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
+ * 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 library 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 library 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.
+ */
+
+/dts-v1/;
+
+#include "imx6sx-udoo-neo.dtsi"
+
+/ {
+	model = "UDOO Neo Extended";
+	compatible = "fsl,imx6sx";
+
+	memory {
+		reg = <0x80000000 0x40000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo-full.dts b/arch/arm/boot/dts/imx6sx-udoo-neo-full.dts
new file mode 100644
index 000000000000..d8c3577c9dd5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo-full.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
+ * 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 library 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 library 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.
+ */
+
+/dts-v1/;
+
+#include "imx6sx-udoo-neo.dtsi"
+
+/ {
+	model = "UDOO Neo Full";
+	compatible = "fsl,imx6sx";
+
+	memory {
+		reg = <0x80000000 0x40000000>;
+	};
+};
+
+&fec1 {
+	phy-handle = <&ethphy1>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy1: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
new file mode 100644
index 000000000000..314d25b15641
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -0,0 +1,293 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
+ * 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 library 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 library 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.
+ */
+
+#include "imx6sx.dtsi"
+
+/ {
+	compatible = "fsl,imx6sx";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		red {
+			label = "udoo-neo:red:mmc";
+			gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+			linux,default-trigger = "mmc0";
+		};
+
+		orange {
+			label = "udoo-neo:orange:user";
+			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
+			default-state = "keep";
+		};
+	};
+
+	sdio_pwr_reg: sd-gpio-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-name = "SDIO_PWR";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+};
+
+&cpu0 {
+	arm-supply = <&sw1a_reg>;
+	soc-supply = <&sw1c_reg>;
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet1>;
+	phy-mode = "rmii";
+	phy-reset-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	clock-frequency = <100000>;
+	status = "okay";
+
+	pmic: pmic at 08 {
+		compatible = "fsl,pfuze3000";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1a {
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1475000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1b {
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1475000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw2_reg: sw2 {
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3a_reg: sw3 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <1650000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen1_reg: vldo1 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen2_reg: vldo2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen3_reg: vccsd {
+				regulator-min-microvolt = <2850000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen4_reg: v33 {
+				regulator-min-microvolt = <2850000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vldo3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen6_reg: vldo4 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_enet1: enet1grp {
+		fsl,pins =
+			<MX6SX_PAD_ENET1_CRS__GPIO2_IO_1	0xa0b1>,
+			<MX6SX_PAD_ENET1_MDC__ENET1_MDC		0xa0b1>,
+			<MX6SX_PAD_ENET1_MDIO__ENET1_MDIO	0xa0b1>,
+			<MX6SX_PAD_RGMII1_TD0__ENET1_TX_DATA_0	0xa0b1>,
+			<MX6SX_PAD_RGMII1_TD1__ENET1_TX_DATA_1	0xa0b1>,
+			<MX6SX_PAD_RGMII1_TX_CTL__ENET1_TX_EN	0xa0b1>,
+
+			<MX6SX_PAD_ENET1_TX_CLK__ENET1_REF_CLK1	0x3081>,
+			<MX6SX_PAD_ENET2_TX_CLK__GPIO2_IO_9	0x3081>,
+			<MX6SX_PAD_RGMII1_RD0__ENET1_RX_DATA_0	0x3081>,
+			<MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1	0x3081>,
+			<MX6SX_PAD_RGMII1_RX_CTL__ENET1_RX_EN	0x3081>,
+			<MX6SX_PAD_RGMII1_RXC__ENET1_RX_ER	0x3081>,
+
+			<MX6SX_PAD_ENET2_RX_CLK__ENET2_REF_CLK_25M	0x91>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins =
+			<MX6SX_PAD_GPIO1_IO00__I2C1_SCL		0x4001b8b1>,
+			<MX6SX_PAD_GPIO1_IO01__I2C1_SDA		0x4001b8b1>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins =
+			<MX6SX_PAD_GPIO1_IO04__UART1_TX		0x1b0b1>,
+			<MX6SX_PAD_GPIO1_IO05__UART1_RX		0x1b0b1>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins =
+			<MX6SX_PAD_GPIO1_IO06__UART2_TX		0x1b0b1>,
+			<MX6SX_PAD_GPIO1_IO07__UART2_RX		0x1b0b1>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins =
+			<MX6SX_PAD_SD4_DATA4__UART5_RX		0x1b0b1>,
+			<MX6SX_PAD_SD4_DATA5__UART5_TX		0x1b0b1>;
+	};
+
+	pinctrl_uart6: uart6grp {
+		fsl,pins =
+			<MX6SX_PAD_CSI_DATA00__UART6_RI_B	0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA01__UART6_DSR_B	0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA02__UART6_DTR_B	0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA03__UART6_DCD_B	0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA04__UART6_RX		0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA05__UART6_TX		0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA06__UART6_RTS_B	0x1b0b1>,
+			<MX6SX_PAD_CSI_DATA07__UART6_CTS_B	0x1b0b1>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins =
+			<MX6SX_PAD_SD2_CMD__USDHC2_CMD		0x17059>,
+			<MX6SX_PAD_SD2_CLK__USDHC2_CLK		0x10059>,
+			<MX6SX_PAD_SD2_DATA0__USDHC2_DATA0	0x17059>,
+			<MX6SX_PAD_SD2_DATA1__USDHC2_DATA1	0x17059>,
+			<MX6SX_PAD_SD2_DATA2__USDHC2_DATA2	0x17059>,
+			<MX6SX_PAD_SD2_DATA3__USDHC2_DATA3	0x17059>,
+			<MX6SX_PAD_SD1_DATA0__GPIO6_IO_2	0x17059>; /* CD */
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+/* Cortex-M4 serial */
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "disabled";
+};
+
+/* Arduino serial */
+&uart5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5>;
+	status = "disabled";
+};
+
+&uart6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart6>;
+	uart-has-rtscts;
+	status = "disabled";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	vmmc-supply = <&sdio_pwr_reg>;
+	bus-width = <4>;
+	cd-gpios = <&gpio6 2 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	status = "okay";
+};
-- 
2.6.6

^ permalink raw reply related

* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Michael Niewöhner @ 2016-10-16 14:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475871962.1697.12.camel@mniewoehner.de>

Hi Felipe,
On Fri, 2016-10-07 at 22:26 +0200, Michael Niew?hner wrote:
> Hi Felipe,
> 
> On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > Michael Niew?hner <linux@mniewoehner.de> writes:
> > > 
> > > > 
> > > > The clocks are same across working/non-working.
> > > > Is it possible to bisect the commit that's causing hang for 4.8x ?
> > > 
> > > 
> > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths
> > > This patch causes both the hang on reboot and the lsusb hang.
> > 
> > How to reproduce? Why don't we see this on x86 and TI boards? I'm
> > guessing this is failed bisection, as I can't see anything in that
> > commit that would cause reboot hang. Also, that code path is *NOT*
> > executed when you run lsusb.
> > 
> 
> I've tested this procedure multiple times to be sure:
> 
> - checkout?c499ff71, compile, boot the odroid
> - run lsusb -v => lsusb hangs, can't terminate with ctrl-c
> - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below)
> - revert c499ff71, mrproper, compile, boot the odroid
> - run lsusb -v => shows full output, not hanging
> - run reboot or poweroff => board powers off / reboots just fine
> 
> 
> dmesg poweroff not working:
> ...
> [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144???????
> [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...???
> [??120.769212] systemd-shutdown[1]: Unmounting file systems.????????????????????
> [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.???????????????
> [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.?????????????????????
> [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
> [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
> [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
> [??121.101014] systemd-shutdown[1]: All filesystems unmounted.??????????????????
> [??121.106523] systemd-shutdown[1]: Deactivating swaps.?????????????????????????
> [??121.111585] systemd-shutdown[1]: All swaps deactivated.??????????????????????
> [??121.116661] systemd-shutdown[1]: Detaching loop devices.?????????????????????
> [??121.126395] systemd-shutdown[1]: All loop devices detached.??????????????????
> [??121.130525] systemd-shutdown[1]: Detaching DM devices.???????????????????????
> [??121.135824] systemd-shutdown[1]: All DM devices detached.????????????????????
> [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.?????
> [??121.171739] systemd-shutdown[1]: Powering off.
> 
> => at this point removing the sd card would show a message?
> "removed mmc0" (not sure what the real message was...) so the board is not completely off.
> 
> 
> dmesg poweroff working:
> ...
> [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144???????
> [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...???
> [??120.769212] systemd-shutdown[1]: Unmounting file systems.????????????????????
> [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.???????????????
> [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.?????????????????????
> [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
> [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
> [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
> [??121.101014] systemd-shutdown[1]: All filesystems unmounted.??????????????????
> [??121.106523] systemd-shutdown[1]: Deactivating swaps.?????????????????????????
> [??121.111585] systemd-shutdown[1]: All swaps deactivated.??????????????????????
> [??121.116661] systemd-shutdown[1]: Detaching loop devices.?????????????????????
> [??121.126395] systemd-shutdown[1]: All loop devices detached.??????????????????
> [??121.130525] systemd-shutdown[1]: Detaching DM devices.???????????????????????
> [??121.135824] systemd-shutdown[1]: All DM devices detached.????????????????????
> [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.?????
> [??121.171739] systemd-shutdown[1]: Powering off.
> [??121.182331] rebo?
> 
> 
> 
> Best regards
> Michael Niew?hner


I did some more tests with next-20161016. Reverting / commenting out
one part of your patch "solves" the lsusb hang, the reboot problem
and also the "debounce failed" message. [1]
Another "solution" is to call phy_power_off before phy_power_on. [2]

Disclaimer: I have no idea what I was doing ;-) These were just some
simple trial-and-error attempts that maybe help to find the real
cause of the problems.

[1]
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7287a76..5ef589d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -724,6 +724,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
?	/* Adjust Frame Length */
?	dwc3_frame_length_adjustment(dwc);
?
+/*
?	usb_phy_set_suspend(dwc->usb2_phy, 0);
?	usb_phy_set_suspend(dwc->usb3_phy, 0);
?	ret = phy_power_on(dwc->usb2_generic_phy);
@@ -733,6 +734,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
?	ret = phy_power_on(dwc->usb3_generic_phy);
?	if (ret < 0)
?		goto err3;
+*/
?
?	ret = dwc3_event_buffers_setup(dwc);
?	if (ret) {

[2]
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7287a76..f6c8e13 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -726,6 +726,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
?
????????usb_phy_set_suspend(dwc->usb2_phy, 0);
????????usb_phy_set_suspend(dwc->usb3_phy, 0);
+???????phy_power_off(dwc->usb2_generic_phy);
+???????phy_power_off(dwc->usb3_generic_phy);
????????ret = phy_power_on(dwc->usb2_generic_phy);
????????if (ret < 0)
????????????????goto err2;


Best regards
Michael

^ permalink raw reply related

* [PATCH v2] clk: samsung: clk-exynos-audss: Fix module autoload
From: Javier Martinez Canillas @ 2016-10-16 13:45 UTC (permalink / raw)
  To: linux-arm-kernel

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias
alias:          platform:exynos-audss-clk

After this patch:

$ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias
alias:          platform:exynos-audss-clk
alias:          of:N*T*Csamsung,exynos5420-audss-clockC*
alias:          of:N*T*Csamsung,exynos5420-audss-clock
alias:          of:N*T*Csamsung,exynos5410-audss-clockC*
alias:          of:N*T*Csamsung,exynos5410-audss-clock
alias:          of:N*T*Csamsung,exynos5250-audss-clockC*
alias:          of:N*T*Csamsung,exynos5250-audss-clock
alias:          of:N*T*Csamsung,exynos4210-audss-clockC*
alias:          of:N*T*Csamsung,exynos4210-audss-clock

Fixes: 4d252fd5719b ("clk: samsung: Allow modular build of the Audio Subsystem CLKCON driver")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Changes in v2:
- Add fixes tag. Suggested by Krzysztof Kozlowski.
- Add Krzysztof Kozlowski's Reviewed-by and Tested-by tags.

 drivers/clk/samsung/clk-exynos-audss.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 51d152f735cc..17e68a724945 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -106,6 +106,7 @@ static const struct of_device_id exynos_audss_clk_of_match[] = {
 	},
 	{ },
 };
+MODULE_DEVICE_TABLE(of, exynos_audss_clk_of_match);
 
 static void exynos_audss_clk_teardown(void)
 {
-- 
2.7.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox