Skip to content

GitLab

Switch branch/tag
  1. 27 Jan, 2017 1 commit
    • Patrice Chotard's avatar
      ARM: dts: STiH407-family: set snps,dis_u3_susphy_quirk · 8413299c
      Patrice Chotard authored 
      
Since v4.10-rc1, the following logs appears in loop :
[  801.953836] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[  801.960455] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
[  801.966611] usb usb6-port1: cannot disable (err = -32)
[  806.083772] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[  806.090370] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
[  806.096494] usb usb6-port1: cannot disable (err = -32)

After analysis, xhci try to set link in U3 and returns an error.
Using snps,dis_u3_susphy_quirk fix this issue.
Signed-off-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      8413299c
  3. 23 Nov, 2016 1 commit
  5. 20 Oct, 2016 1 commit
  7. 19 Sep, 2016 1 commit
  9. 14 Sep, 2016 4 commits
  11. 08 Sep, 2016 1 commit
    • Lee Jones's avatar
      ARM: dts: STiH407-family: Provide interconnect clock for consumption in ST SDHCI · 78567f13
      Lee Jones authored 
      
The STiH4{07,10} platform contains some interconnect clocks which are used
by various IPs.  If these clocks aren't handled correctly by ST's SDHCI
driver MMC will break and the following output can be observed:

[   13.916949] mmc0: Timeout waiting for hardware interrupt.
[   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
[   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
[   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
[   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
[   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
[   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
[   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
[   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
[   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
[   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
[   13.992252] sdhci: Host ctl2: 0x00000000
[   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
[   14.001990] sdhci: ===========================================
[   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.

Cc: stable@vger.kernel.org
Tested-by: default avatarPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
Acked-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      78567f13
  13. 06 Sep, 2016 1 commit
  15. 02 Sep, 2016 2 commits
  17. 10 Aug, 2016 1 commit
  19. 19 Jun, 2016 1 commit
    • Lee Jones's avatar
      ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes · 0e289e53
      Lee Jones authored 
      This patch fixes a non-booting issue in Mainline.

When booting with a compressed kernel, we need to be careful how we
populate memory close to DDR start.  AUTO_ZRELADDR is enabled by default
in multi-arch enabled configurations, which place some restrictions on
where the kernel is placed and where it will be uncompressed to on boot.

AUTO_ZRELADDR takes the decompressor code's start address and masks out
the bottom 28 bits to obtain an address to uncompress the kernel to
(thus a load address of 0x42000000 means that the kernel will be
uncompressed to 0x40000000 i.e. DDR START on this platform).

Even changing the load address to after the co-processor's shared memory
won't render a booting platform, since the AUTO_ZRELADDR algorithm still
ensures the kernel is uncompressed into memory shared with the first
co-processor (0x40000000).

Another option would be to move loading to 0x4A000000, since this will
mean the decompressor will decompress the kernel to 0x48000000. However,
this would mean a large chunk (0x44000000 => 0x48000000 (64MB)) of
memory would essentially be wasted for no good reason.

Until we can work with ST to find a suitable memory location to
relocate co-processor shared memory, let's disable the shared memory
nodes.  This will ensure a working platform in the mean time.

NB: The more observant of you will notice that we're leaving the DMU
shared memory node enabled; this is because a) it is the only one in
active use at the time of this writing and b) it is not affected by
the current default behaviour which is causing issues.

Fixes: fe135c63

 (ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory)
Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
Reviewed-by Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: default avatarMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      0e289e53
  21. 26 Apr, 2016 8 commits
  23. 15 Oct, 2015 1 commit
  25. 01 Oct, 2015 1 commit
  27. 30 Sep, 2015 1 commit
  29. 29 Sep, 2015 2 commits
  31. 21 Sep, 2015 1 commit
  33. 03 Aug, 2015 1 commit
  35. 22 Jul, 2015 3 commits
  37. 13 May, 2015 3 commits
  39. 07 May, 2015 2 commits
  41. 30 Apr, 2015 3 commits