Skip to content
  1. Mar 02, 2018
  2. 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
  3. 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
  4. Feb 12, 2018
  5. Jan 23, 2018
  6. Jan 13, 2018
  7. Jan 12, 2018
  8. Jan 09, 2018
  9. Jan 06, 2018
  10. Jan 05, 2018
  11. Jan 04, 2018
  12. Jan 01, 2018