[Arm-netbook] Testing: GPIO

[Jonathan Neuschäfer]

On Sat, Mar 03, 2018 at 12:11:02AM -0700, Richard Wilbur wrote:
> On Mar 2, 2018, at 15:43, Jonathan Neuschäfer <j.neuschaefer at gmx.net> 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