On Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer j.neuschaefer@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.