[Openchrome-users] DVI-02 funkiness

[Philip Prindeville]

Philip Prindeville wrote:
> Thomas Hellstr?m wrote:
>   
>> Philip Prindeville wrote:
>>
>>   
>>     
>>> Well, I'm going through my Xorg.0.log on my SP-13000, and
>>> seeing in it:
>>>
>>> (II) VIA(0): ViaI2CBus3Init
>>> (II) VIA(0): I2C bus "I2C bus 3" initialized.
>>> (II) VIA(0): ViaI2CScan: Scanning I2C bus 2
>>> (II) VIA(0): ViaI2CScan: Scanning I2C bus 3
>>> (--) VIA(0): Found slave on I2C bus 3 - 0x40
>>> (--) VIA(0): Found slave on I2C bus 3 - 0x70
>>> (--) VIA(0): Found slave on I2C bus 3 - 0x74
>>> (--) VIA(0): Found slave on I2C bus 3 - 0xA0
>>>
>>>
>>> so I hacked up a driver to try to read a byte from Bus 3, address 0x70,
>>> sub-address 0x00: which should be the first byte of the Sil164 device...
>>> but the read fails.
>>>
>>> So...  why is the read failing?  Is the bus not being
>>> initialized with the correct timings?
>>>
>>> Or are there things that don't have stuff starting at sub-address 0?
>>>
>>> Also, going through the Via drivers to try to figure how they do
>>> things...  I notice that they also probe using something called
>>> GPIOI2C_*
>>>
>>> Not sure what that is.  Is there another I2C bus that isn't
>>> accessible with the xf86i2c.c code?  Has anyone else pored over
>>> that part of the VT code?
>>>
>>> Thanks,
>>>
>>> -Philip
>>>
>>>
>>>  
>>>
>>>     
>>>       
>> Luc once moved VIA's GPIOI2C_ stuff over to the generic xf86i2c code.
>> IIRC, While doing so, he altered some timings in order to make it work 
>> with a chip he had on his mainboard. Those alterations made it fail 
>> reading from the vt1623 device, it even got the device id wrong, so I 
>> changed those timings back to something like what's in the VIA code to 
>> make vt1623 working.
>>
>> It's possible that the read timing needs more tweaking. Try to compare 
>> the failing function with the corresponding one in the VIA code and see 
>> if you can make it work
>>
>> /Thomas
>>   
>>     
>
>
> That's the thing: the Via code defaults the xf86I2CBusRec
> initialization... and the driver also clones the DevRec values
> from the bus they are attached to.
>
> But looking at the actual read/write routines that they plug
> in as handlers, there are no delays at all!
>
> static void
> VIAI2C1GetBits(I2CBusPtr b, int *clock, int *data)
> {
>     CARD8 reg;
>
>     outb(0x3c4, 0x26);
>     reg = inb(0x3c5);
>
>     *clock = (reg & DDC_SCL_READ_MASK) != 0;
>     *data  = (reg & DDC_SDA_READ_MASK) != 0;
> }
>
>
>
> The code just runs "flat out", no delays.
>
> I'm thinking that maybe the BusRec should
> be initialized with no delays, but that the VT1623
> driver should have locally-specified delays.
>
> -Philip
>   

Tried various other permutations of delays, etc.

No joy.

Jon: can you arrange access to the appropriate contacts
at Via so we can figure out why we're able to sense the
TMDS encoder's presence, but not get data out of it?

Also, is there a reason why the stock GetBits/PutBits,
etc. functions from hw/xfree86/i2c/ couldn't be used,
and replacement methods were needed specifically for
the Via hardware?

Does anyone (Luc, Thomas, Jon, Xavier...) hang out on
#xorg-devel or any other IRC's?

Thanks,

-Philip