Skip to content

ARM: dts: exynos: Prepare Spring

Tomasz Figa linux-arm-kernel linux-devicetree linux-samsung-soc lkml 2 versions – New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v6 Latest0 of 10 patches 0 repliesNew
  2. v50 of 10 patches 0 repliesSuperseded

Patches in v6 No applies recorded yet

None of the 10 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v6 yet.

Read the v6 thread

Cover letter [PATCH v6 00/10] ARM: dts: exynos: Prepare Spring

On 02.08.2014 12:25, Andreas F?rber wrote:

[snip]

Quoted 3 lines

One thing I've wondered is whether we should put status = "disabled" on the dp node with some comment, since it's known not to work as is (but better having the data here than leaving it out, I believe).

Does the DP node itself need more data to work or just some external things are missing? If the former then probably status = "disabled" should be set, otherwise "okay" is fine if provided data are enough to probe the Exynos DP driver.

Quoted 4 lines

Of course if either of you has input on the discussions on the drm bridge/panel series V6 [1] for how to enable non-simplefb display and iommus, that would be valuable.

Support for Exynos IOMMU is being worked on right now and patches adding DT support from Marek Szyprowski should show up on the lists in very near future. However I think you don't strictly need IOMMU to get non-simplefb display, as CMA can be used to allocate contiguous memory.

Quoted 3 lines

[1] http://www.spinics.net/lists/linux-samsung-soc/msg35274.html

[snip]

Quoted 5 lines

For the touchpad it seems DT support has landed in the input tree as "atmel,maxtouch". Backporting just that patch does not make it work though. (Tried the rejected pinctrl approach to be on the safe side.)
https://code.google.com/p/chromium/issues/detail?id=371114
https://patchwork.kernel.org/patch/3976801/

Looking at what we already have in mainline and the discussion in Chromium issue tracker, current driver should be already in shape to handle the Chromebooks. Apparently it even supports recovery from bootloader mode without the need to parse bootloader address from DT (it somehow calculates possible addresses from main address).

Best regards,
Tomasz