On Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer
>> 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
> 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, 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.
arm-netbook mailing list email@example.com
Send large attachments to arm-netb...@files.phcomp.co.uk