[Arm-netbook] Testing: GPIO

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Mar 2, 2018 at 10:26 PM, Richard Wilbur
<richard.wilbur at gmail.com> wrote:
> On Mar 1, 2018, at 20:30, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
>
> Sent from my iPhone
>> On Thu, Mar 1, 2018 at 9:46 PM, Richard Wilbur <richard.wilbur at gmail.com> wrote:
>>> It looks to me like the fastest way to test the GPIO lines connected
>>> on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to
>>> connect a VGA monitor to the micro-desktop and make sure it is
>>> properly detected and a test image looks right on it.
>>
>> yep, pretty much... with one slight fly in the ointment: the SCL and
>> SDA lines are straight GPIO and will need a bit-banging I2C linux
>> kernel driver.  once that's configured, doing i2cdetect _should_ be
>> enough to test the circuit, although scanning the data and running
>> read-edid on it would be awesome and amazing: it would mean being able
>> to *really* do proper VESA detection.
>
> Is someone already working on that?

 no.

>  Sounds like we need the device tree for the micro-desktop to be
> populated.

 patches to linux mainline are needed to include the ability to have
devicetree fragments before that can happen.

 however... the A20 linux sunxi mainline source is *not 100%
functional* so it's kinda moot.

> If we did it for micro-desktop v1.7 it would be something to build off for micro-desktop v1.8 and also a good place to begin for the laptop.
>
> 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.)

 i found a random driver somewhere for I2C - don't know about the
linking to userspace / DDC.


> If none of this is underway I'll continue mapping things out so we can
> create the device tree for the micro-desktop.

 that would be useful... *if* the A20 linux sunxi mainline source
supports 100% of the functionality of an A20.

>  If I remember correctly we also should create a device tree for the DS-113 v2.7.4 and v2.7.5?

 again same caveat.... *thinks*.... yeah.

> I'd be happy to work on that if you think that is the highest
> priority right now.  It sounds like it will help both testing and
> deployment.

 let me think...

 two conditional things need to happen:

 1. the A20 sunxi mainline code needs to have 100% functionality
support for ALL hardware

 2. the "devicetree fragment" patch also needs to be confirmed as mainline.

 then it's useful.

l.