[Arm-netbook] Testing: GPIO

[Luke Kenneth Casson Leighton]

On Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer
<j.neuschaefer at gmx.net> wrote:

>>  excellent, can you look up the status of A20 and the devicetree fragments?
>
> There has been some work on HDMI on the A10/A20 in October (merged in
> 4.15): https://www.spinics.net/lists/devicetree/msg198941.html
> Reportedly, HDMI works now. I'm not sure what else was/is missing.

 the *full* hardware set is needed.  except for NAND, which has been
removed from 2.7.5.

> About DT fragments: I'm not sure what you mean exactly. Mainline support
> devicetree overlays which should do (half of) the job for EOMA68, though.

 ah, yes, that's the official name.  overlays.

 question: do you know if they've added the patches to *REMOVE*
overlays yet?  Cards could potentially be dynamically removed... or at
least put into sleep / suspend only to wake up with a totally
different Housing.


> The tricky part would be figuring out how the same overlay can be used
> on base devicetrees for different SoCs, as the exposed busses will have
> different names.

 ... i'm not sure what you're referring to, here.  do you have an example?

> This may be solved by a future iteration of this
> patchset: https://www.spinics.net/lists/kernel/msg2710913.html

 there's nothing mentioned about what standard he's referring to.  is
there a link, or can you do a quick summary?

> The other side of the DT job is the dynamic loading of a devicetree
> overlay based on the EEPROM of the connected housing.

 yes that's correct.

> Mainline Linux
> doesn't have something like capemgr[1], AFAIK; But I think this could
> also be handled in userspace.

 it has to be handled in u-boot (at least partially).


> And then there's the question of how the kernel/userspace is supposed to
> know on which i2c bus it finds the EOMA68 EEPROM.

 good point.  the bus utilised will be in the Card's devicetree file:
it will have to be named as such.

l.