Skip to content
  1. Apr 16, 2018
  3. Mar 13, 2018
  5. Mar 12, 2018
  7. Mar 02, 2018
  9. Mar 01, 2018
    • Douglas Anderson's avatar
      arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset) · 2560da49
      Douglas Anderson authored 
      Back in the early days when gru devices were still under development
we found an issue where the WiFi reset line needed to be configured as
early as possible during the boot process to avoid the WiFi module
being in a bad state.

We found that the way to get the kernel to do this in the earliest
possible place was to configure this line in the pinctrl hogs, so
that's what we did.  For some history here you can see
<http://crosreview.com/368770>.  After the time that change landed in
the kernel, we landed a firmware change to configure this line even
earlier.  See <http://crosreview.com/399919>.  However, even after the
firmware change landed we kept the kernel change to deal with the fact
that some people working on devices might take a little while to
update their firmware.

At this there are definitely zero devices out in the wild that have
firmware without the fix in it.  Specifically looking in the firmware
branch several critically important fixes for memory stability landed
after the patch in coreboot and I know we didn't ship without those.
Thus, by now, everyone should have the new firmware and it's safe to
not have the kernel set this up in a pinctrl hog.

Historically, even though it wasn't needed to have this in a pinctrl
hog, we still kept it since it didn't hurt.  Pinctrl would apply the
default hog at bootup and then would never touch things again.  That
all changed with commit 981ed1bf

 ("pinctrl: Really force states
during suspend/resume").  After that commit then we'll re-apply the
default hog at resume time and that can screw up the reset state of
WiFi.  ...and on rk3399 if you touch a device on PCIe in the wrong way
then the whole system can go haywire.  That's what was happening.
Specifically you'd resume a rk3399-gru-* device and it would mostly
resume, then would crash with some crazy weird crash.

One could say, perhaps, that the recent pinctrl change was at fault
(and should be fixed) since it changed behavior.  ...but that's not
really true.  The device tree for rk3399-gru is really to blame.
Specifically since the pinctrl is defined in the hog and not in the
"wlan-pd-n" node then the actual user of this pin doesn't have a
pinctrl entry for it.  That's bad.

Let's fix our problems by just moving the control of
"wlan_module_reset_l pinctrl" out of the hog and put them in the
proper place.

NOTE: in theory, I think it should actually be possible to have a pin
controlled _both_ by the hog and by an actual device.  Once the device
claims the pin I think the hog is supposed to let go.  I'm not 100%
sure that this works and in any case this solution would be more
complex than is necessary.

Reported-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
Fixes: 48f4d979 ("arm64: dts: rockchip: add Gru/Kevin DTS")
Fixes: 981ed1bf

 ("pinctrl: Really force states during suspend/resume")
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Tested-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      2560da49
  11. Feb 20, 2018
  13. Feb 19, 2018
  15. Feb 17, 2018
  17. Feb 16, 2018
    • Robin Murphy's avatar
      arm64: dts: rockchip: Fix DWMMC clocks · ca9eee95
      Robin Murphy authored 
      Trying to boot an RK3328 box with an HS200-capable eMMC, I see said eMMC
fail to initialise as it can't run its tuning procedure, because the
sample clock is missing. Upon closer inspection, whilst the clock is
present in the DT, its name is subtly incorrect per the binding, so
__of_clk_get_by_name() never finds it. By inspection, the drive clock
suffers from a similar problem, so has never worked properly either.

Fix up all instances of the incorrect clock names across the 64-bit DTs.

Fixes: d717f735 ("arm64: dts: rockchip: add sdmmc/sdio/emmc nodes for RK3328 SoCs")
Fixes: b790c2ca

 ("arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board")
Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      ca9eee95
    • Robin Murphy's avatar
      arm64: dts: rockchip: Fix RK3328 UART DMAs · 1255fe03
      Robin Murphy authored 
      

Using a serial console on RK3328 provokes an error from
of_dma_request_slave_channel() since the UART nodes have a "dmas"
property but are missing the mandatory "dma-names" to go with it.

Replace the bogus "#dma-cells" - these UARTs are DMA channel consumers,
not providers - with the appropriate names instead. DMA still doesn't
actually work, since the PL330 driver doesn't quite implement everything
the 8250 driver demands, but at least it makes the DT correct.

Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      1255fe03
  19. Feb 14, 2018
  21. Feb 12, 2018
  23. Dec 20, 2017
  25. Dec 17, 2017
  27. Dec 06, 2017
    • Heiko Stuebner's avatar
      arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now · bc631943
      Heiko Stuebner authored 
      

It looks like either the current kernel or the hardware has reliability
issues when the gmac is actually running at 1GBit. In my test-case
it is not able to boot on a nfsroot at this speed, as the system
will always lose the connection to the nfs-server during boot, before
reaching any login prompt and not recover from this.

So until this is solved, limit the speed to 100MBit as with this the
nfsroot survives stress tests like an apt-get upgrade without problems.

Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      bc631943
    • Klaus Goger's avatar
      arm64: dts: rockchip: remove vdd_log from rk3399-puma · 87eba071
      Klaus Goger authored 
      

vdd_log has no consumer and therefore will not be set to a specific
voltage. Still the PWM output pin gets configured and thence the vdd_log
output voltage will changed from it's default. Depending on the idle
state of the PWM this will slightly over or undervoltage the logic supply
of the RK3399 and cause instability with GbE (undervoltage) and PCIe
(overvoltage). Since the default value set by a voltage divider is the
correct supply voltage and we don't need to change it during runtime we
remove the rail from the devicetree completely so the PWM pin will not
be configured.

Signed-off-by: default avatarKlaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      87eba071
  29. Dec 05, 2017