[Arm-netbook] Testing: GPIO

[Luke Kenneth Casson Leighton]

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


On Fri, Mar 2, 2018 at 11:24 PM, Richard Wilbur
<richard.wilbur at gmail.com> wrote:
> On Mar 1, 2018, at 20:40, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>>
>> On Thu, Mar 1, 2018 at 10:42 PM, Richard Wilbur
>> <richard.wilbur at gmail.com> wrote:
>>
>>> Luke, have you tested the D/A circuit on the micro-desktop board?
>>
>> yep it works great up to 1024x768.  i haven't yet been able to get it
>> to sync at anything greater than that, because you have to manually
>> convert the signals into A20 timings... and of course if you can't
>> read the EDID data you don't know *exactly* what the settings are in
>> the first place for any given monitor.
>>
>> 1024x768, being a common VESA standard, has worked consistently on
>> every monitor i've tried.
>
> So if we could read the EDID the driver would figure out the A20 timings?

 no.  some code is needed to *translate* EDID into A20 timings.


> Does the A20 already have a graphics driver capable of that?

 no.  the general assumption is that RGB/TTL is used for *fixed* size
LCDs.  therefore why on earth, the logic goes, would you put a dynamic
EDID bridge in place?


>  (In which case the bit-banging VESA DDC driver becomes very
>  important.)  How much of this infrastructure already exists?

 bits and pieces.  mainly it's integration.

> I'm bringing my tools, where do we start building?

 :)

> I have a collection of VGA monitors with different aspect ratios
> and sizes (3 CRT and 3 LCD).  I'd be happy to test resolutions above
>  and below 1024x768.

 yay.

>>> Only thing I would worry about is the hold time on the data lines.  If
>>> the A20 sets up the data quickly (relative to the pixel time) and
>>> holds it until the next setup, we should be in good shape.
>>
>> sigh yeah i thought about that... using buffer ICs with a "hold", and
>> linking up the clock line to it.... never got round to it.  i'd prefer
>> to just skip the entire circuit and use a TFP410 (or maybe it's a
>> TFP401a), or a Chrontel RGB/TTL to VGA converter IC.  CH7036 i think
>> it is.
>
> Are you thinking of octal D flip-flops?  I'll have to look up those datasheets.  What do those chips offer over the flip-flops?  How do the prices compare?

 no idea haven't investigtated.

> […]
>> yyup.  exactly.  remember, you can't do more than one interface on
>> any given set of pins, so i had to pick one (RGB/TTL or LVDS or MIPI
>> or eDP), that then means you have to have a conversion IC in-place on
>> the Card if a particular SoC doesn't *have* that interface... and many
>> of the lower-cost SoCs don't because they're not part of the MIPI or
>> DisplayPort cartel(s)....
>
> Yes, that's the awful thing about so many industry standards:
> you can't get the text without signing documents and paying
> a handsome price, you can't use them without paying royalties
> to the patent owners.

 ... which is why i'm not putting CAN bus into any of the libre-riscv SoCs...

>> ... and even if you had LVDS, the cost on the other side (Housing
>> side) of having an LVDS-to-RGB/TTL converter is so high relative to
>> the cost of the LCD itself that companies would rebel and not bother
>> with the standard at all.
>>
>> so, bizarrely, RGB/TTL, by being both "free" and also unencumbered by
>> patents *and* by being lowest-common-denominator, wins out on all
>> fronts.  except for the fact that you need a 125mhz clock-rate for
>> 1920x1080 at 60fps, which is a bit... high.  but hey.
>
> Will the A20 clock the RGBTTL interface that high?

 yes.  despite the fuckwits in the marketing department in *competing
divisions* inside allwinner trying to tell the world otherwise.
they've dumbed down the public marketted specification of the A20 to
1024x768 because its capabilities for the price were making other
offerings look *really* bad.

l.