Addressing the intel VCH on the i2c bus / R31 dithering

Addressing the intel VCH on the i2c bus / R31 dithering

[Thomas Richter]

Hi folks, hi Daniel, hi Ville,

thanks again for getting my old Laptops (the R31 and the S6010) back to
life. It's been quite a way, but everything looks fine now.

There is one interesting observation I made, though, on my IBM R31
laptop: The i830GM graphics supports 24bpp pipes, thought the panel is
only a 6-bit panel, i.e. 18bpp. As you say, the i830GM does not support
dithering, but interestingly, as I found out by accident, the iVCH DVO
chip in the laptop does. If you press FN+F8 (usually to control the
scaling of the display per bios), the image quality improves
dramatically, apparently by reconfiguring the settings of the iVCH
bypassing the kernel. This is handled by the Bios.

Now, I would like to find the settings the Bios leaves in the iVCH.
Unfortunately, there is a catch here: According to the kernel sources,
the iVCH is connected to the i2c-bus, but at address #2. My knowledge of
i2c is limited, but from what I know, this is actually not a valid
address and is rather used for some control mechanism of i2c itself.
Hence, the usual i2c tools do not allow me to reach out for the chip and
read its registers.

Question:

How can possibly read out the settings of the i2c chip with system
tools? I know the kernel does a register dump of what it installs during
DVO initialization, and have these values, but what I don't have are the
values the bios leaves when I press FN+F8.

Thanks for any ideas,
	Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Addressing the intel VCH on the i2c bus / R31 dithering

[Daniel Vetter]

On Fri, Mar 27, 2015 at 09:03:35AM +0100, Thomas Richter wrote:
> Hi folks, hi Daniel, hi Ville,
> 
> thanks again for getting my old Laptops (the R31 and the S6010) back to
> life. It's been quite a way, but everything looks fine now.
> 
> There is one interesting observation I made, though, on my IBM R31
> laptop: The i830GM graphics supports 24bpp pipes, thought the panel is
> only a 6-bit panel, i.e. 18bpp. As you say, the i830GM does not support
> dithering, but interestingly, as I found out by accident, the iVCH DVO
> chip in the laptop does. If you press FN+F8 (usually to control the
> scaling of the display per bios), the image quality improves
> dramatically, apparently by reconfiguring the settings of the iVCH
> bypassing the kernel. This is handled by the Bios.
> 
> Now, I would like to find the settings the Bios leaves in the iVCH.
> Unfortunately, there is a catch here: According to the kernel sources,
> the iVCH is connected to the i2c-bus, but at address #2. My knowledge of
> i2c is limited, but from what I know, this is actually not a valid
> address and is rather used for some control mechanism of i2c itself.
> Hence, the usual i2c tools do not allow me to reach out for the chip and
> read its registers.
> 
> Question:
> 
> How can possibly read out the settings of the i2c chip with system
> tools? I know the kernel does a register dump of what it installs during
> DVO initialization, and have these values, but what I don't have are the
> values the bios leaves when I press FN+F8.

i2c uses 7 bits for address and bit 8 for read/write indication. There's a
bit confusion between tools and kernel about whether to include the
read/write bit or not, so maybe try with 1 instead?

Plan b would be to extend the ivch_dump_regs and wire that up into a
debugfs file. Then you could dump the registers through the kernel
before/after pressing the magic key.

but tbh I don't have much i2c clue either.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Addressing the intel VCH on the i2c bus / R31 dithering

[Ville Syrjälä]

On Fri, Mar 27, 2015 at 09:40:56AM +0100, Daniel Vetter wrote:
> On Fri, Mar 27, 2015 at 09:03:35AM +0100, Thomas Richter wrote:
> > Hi folks, hi Daniel, hi Ville,
> > 
> > thanks again for getting my old Laptops (the R31 and the S6010) back to
> > life. It's been quite a way, but everything looks fine now.
> > 
> > There is one interesting observation I made, though, on my IBM R31
> > laptop: The i830GM graphics supports 24bpp pipes, thought the panel is
> > only a 6-bit panel, i.e. 18bpp. As you say, the i830GM does not support
> > dithering, but interestingly, as I found out by accident, the iVCH DVO
> > chip in the laptop does. If you press FN+F8 (usually to control the
> > scaling of the display per bios), the image quality improves
> > dramatically, apparently by reconfiguring the settings of the iVCH
> > bypassing the kernel. This is handled by the Bios.
> > 
> > Now, I would like to find the settings the Bios leaves in the iVCH.
> > Unfortunately, there is a catch here: According to the kernel sources,
> > the iVCH is connected to the i2c-bus, but at address #2. My knowledge of
> > i2c is limited, but from what I know, this is actually not a valid
> > address and is rather used for some control mechanism of i2c itself.
> > Hence, the usual i2c tools do not allow me to reach out for the chip and
> > read its registers.
> > 
> > Question:
> > 
> > How can possibly read out the settings of the i2c chip with system
> > tools? I know the kernel does a register dump of what it installs during
> > DVO initialization, and have these values, but what I don't have are the
> > values the bios leaves when I press FN+F8.
> 
> i2c uses 7 bits for address and bit 8 for read/write indication. There's a
> bit confusion between tools and kernel about whether to include the
> read/write bit or not, so maybe try with 1 instead?
> 
> Plan b would be to extend the ivch_dump_regs and wire that up into a
> debugfs file. Then you could dump the registers through the kernel
> before/after pressing the magic key.
> 
> but tbh I don't have much i2c clue either.

Address 0x2 is reserved for non-standard protocol, and that's clearly
what ivch is using since it's doing the trickery with the NOSTART flag.

So yeah, doing more ivch_dump_regs() from either debugfs (or possible
just before dpms off) would allow capturing the stuff. I did something
like that when dumping the ns2501 BIOS values last year. I actually made
it dump it out in the struct ns2501_reg format so that I could just copy
paste the results into the code ;)

Another option is to write a custom userspace tool to do the dumping.
You can specify the exact message format when you poke at /dev/i2c with
the ioctls. If you do this then we could push the resulting tool into
igt, in case someone else would need to do that same thing in the future.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

R31 dithering

[Thomas Richter]

Hi Daniel, hi Ville,

thanks for your help. I used now the debug output to research how to 
enable dithering on the intel VCH. Apparently, it is bit #4 in register
VR01 that enables dithering. This is cross-checked by enabling in the
dvo_ivch.c file, which greatly improves image quality for 24bpp output. 
The bit itself is documented as "reserved" in the intel documentation, 
though it works quite nicely here.

I will now cross-check a little bit which other side effects this bit
has if combined with other DVO features (16bpp output, and scaler 
enabled). As soon as I have more, I'll prepare a small kernel patch for
it.

Thanks and have a nice weekend,

Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: R31 dithering

[Ville Syrjälä]

On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote:
> Hi Daniel, hi Ville,
> 
> thanks for your help. I used now the debug output to research how to 
> enable dithering on the intel VCH. Apparently, it is bit #4 in register
> VR01 that enables dithering. This is cross-checked by enabling in the
> dvo_ivch.c file, which greatly improves image quality for 24bpp output. 
> The bit itself is documented as "reserved" in the intel documentation, 
> though it works quite nicely here.
> 
> I will now cross-check a little bit which other side effects this bit
> has if combined with other DVO features (16bpp output, and scaler 
> enabled). As soon as I have more, I'll prepare a small kernel patch for
> it.
> 
> Thanks and have a nice weekend,

BTW I think this bug is about failure to restore the ivch to proper
state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838
Just in case you're looking for more stuff to do around the ivch ;)

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: R31 dithering

[Thomas Richter]

Am 30.03.2015 um 13:55 schrieb Ville Syrjälä:
> On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote:

>> Thanks and have a nice weekend,
> 
> BTW I think this bug is about failure to restore the ivch to proper
> state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838
> Just in case you're looking for more stuff to do around the ivch ;)

Well, no x30 around here unfortunately, though I can possibly check for
helpers in a German Thinkpad forum. Maybe somebody with enough
Linux-awareness can remote-debug and provide a couple of register
listings to re-enable the DVO as required during wake-up. Or provides an
x30. (-:

I'll check and let you know.

Greetings,
	Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: R31 dithering

[Ville Syrjälä]

On Mon, Mar 30, 2015 at 03:54:29PM +0200, Thomas Richter wrote:
> Am 30.03.2015 um 13:55 schrieb Ville Syrjälä:
> > On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote:
> 
> >> Thanks and have a nice weekend,
> > 
> > BTW I think this bug is about failure to restore the ivch to proper
> > state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838
> > Just in case you're looking for more stuff to do around the ivch ;)
> 
> Well, no x30 around here unfortunately, though I can possibly check for
> helpers in a German Thinkpad forum. Maybe somebody with enough
> Linux-awareness can remote-debug and provide a couple of register
> listings to re-enable the DVO as required during wake-up. Or provides an
> x30. (-:
> 
> I'll check and let you know.

I was assuming your R31 or whatever would have the same problems.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: R31 dithering

[Thomas Richter]

Am 30.03.2015 um 15:59 schrieb Ville Syrjälä:
> On Mon, Mar 30, 2015 at 03:54:29PM +0200, Thomas Richter wrote:
>> Am 30.03.2015 um 13:55 schrieb Ville Syrjälä:
>>> On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote:
>>
>>>> Thanks and have a nice weekend,
>>>
>>> BTW I think this bug is about failure to restore the ivch to proper
>>> state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838
>>> Just in case you're looking for more stuff to do around the ivch ;)
>>
>> Well, no x30 around here unfortunately, though I can possibly check for
>> helpers in a German Thinkpad forum. Maybe somebody with enough
>> Linux-awareness can remote-debug and provide a couple of register
>> listings to re-enable the DVO as required during wake-up. Or provides an
>> x30. (-:
>>
>> I'll check and let you know.
> 
> I was assuming your R31 or whatever would have the same problems.

No, astonishingly, not. Suspend/resume and hibernate work fine. Well,
somewhat... Actually, the R31 only supports S1 (standby) correctly and
not S3 (suspend to RAM), even though ACPI (the DSDT) makes you believe
that S3 would work.

Problem is that the bios does not even enter the kernel anymore once you
wake it up from S3 - it's completely dead then and the user mode entry
point of the kernel is never reached. So the kernel can hardly do
anything about this in first place.... I personally "solved" the problem
by providing a custom DSDT which just disables S3, and it worked happily
ever after...

Greetings,
	Thomas


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx