On Sat, Mar 03, 2018 at 12:11:02AM -0700, Richard Wilbur wrote: > On Mar 2, 2018, at 15:43, Jonathan Neuschäfer <[email protected]> wrote: > >> On Fri, Mar 02, 2018 at 03:26:32PM -0700, Richard Wilbur wrote: > > […] > > I'm not actively working on any of this, but I'm interested in the > > devicetree side of things. > > To what does your interest in devicetree extend? Are you interested > in helping create the devicetree mappings for EOMA68 hardware, or > following developments, etc. How would you like to be involved? > Thank you for imparting your knowledge below.
Following the development and discussions like this, and offering some input every now and then. I might also write some small kernel patches. > >> From what I'm hearing, once the device tree is ready we could work on > >> "automagically" configuring the VESA DDC driver to bit-bang the > >> correct GPIO pins. Does the bit-banging VESA DDC driver exist already? > >> (I wrote a bit-banging I2C driver in VxWorks at a previous position so > >> the topic is not foreign.) > > > > Mainline Linux has a driver[1] for I2C-over-GPIO. It's been there since > > 2.6.22, albeit initially without devicetree support, which came in 3.4. > > > > There's also a generic devicetree binding[2] for I2C-over-GPIO in > > Linux's Documentation/devicetree/bindings directory. > > That's wonderful news! So with the devicetree for the micro-desktop we > should be able to setup the I2C driver. Next question: has anyone created a > VESA DDC driver that will get the EDID from any connected monitor given when > given access to an I2C device (as exposed by our bit-banging I2C driver). > > VESA DDC is a standard that specifies a protocol on top of I2C for obtaining > monitor information (supported resolutions and timings, color gamma, etc.). > > >> If none of this is underway I'll continue mapping things out so we can > >> create the device tree for the micro-desktop. If I remember correctly > >> we also should create a device tree for the DS-113 v2.7.4 and v2.7.5? The devicetree for the CPU card should be relatively straight-forward, at least the parts that don't involve the EOMA68 connector. And for the connector and what's beyond, I see two solutions: Short-term solution: Write an A20-specific DT snippet, either as an overlay that's loaded by u-boot (this will preclude hot-plug of the card into a different housing). Long-term solution: Work with the mainline kernel folks to create something that lets us represent SoC-independent connectors properly, and also implement DTo loading based on the config EEPROM. > > > > What is DS-113? > > EOMA68-A20 the CPU card. Aaah! Thanks. Jonathan _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
