[Arm-netbook] Testing: GPIO

[Richard Wilbur]

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?  Does the A20 already have a graphics driver capable of that?  (In which case the bit-banging VESA DDC driver becomes very important.)  How much of this infrastructure already exists?  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.

>> 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?

[…]
> 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.

> ... 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?