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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
