Hi Joan, joancarles wrote: > > joancarles wrote: > >> ADDENDUM: > >> > The Y-values are seem within a max 5% error margin (200 of 4096), > >> > however the X value go completely nuts. What's this all about? > >> > >> If I disable the frame buffer device, Juergen's new touch screen > >> driver works perfectly well, both for Y values and for X values. > > > > A resistive touchscreen is like a large capacitor. And all the > > electrical emission of the LCD itself you can also measure at the > > touchscreen lines. So, measuring while the HSYNC is asserted might be a > > good idea. > > > > Take a look into the datasheet, chapter 44, register TGCR, bit 6 > > (HSYNCEN) and bit 7 (HSYNCPOL). This lets the ADC do the conversion when > > the HSYNC is active and all signals to the LCD are static at this time. > > Maybe it helps you to get better ADC values. > > Ok, so what you are saying is that your driver currently reads ADC > value independent of the settings of the TGCR register bit 6 and 7?
I said, it just does the conversion not synced to the LCD signals unless these bits are used. > I'll have a look at the driver and see if I can fix those values to read > while HSYNC is asserted (TGCR.6 and TGCR.7==0?). One of these bits enable the feature, the second defines the active polarity of the HSYNC. As I do not know your LCD and its requirements, its up to you, to select the correct polarity. > What speaks against doing this in general in your driver? It slows down the ADC conversions rate. But I'm not sure if it is relevant. ;) > >> I have been experiencing a washout on the LCD, most likely caused by > >> the red channel not being set to 0xFF, after switching from 2.6.39 to 3.3 > >> kernels. Since a diff of the drivers/video/imxfb.c shows almost no > >> difference, I didn't bother to address this issue yet. However, there > >> seems to be a weird connection between the mal-functioning of the imxfb > >> driver and the adc-ts driver. > > > > Sounds like a pad routing issue. Check the MX25_PAD_*__LD* macros if > > they still do the pad routing correctly. > > git diff v2.6.39 arch/arm/plat-mxc/include/mach/iomux-mx25.h > > shows nothing besides a completely unrelated change. Am I missing the > point? No. It was just an idea and a location where I would check first if I would have such an issue. > > And are the clock frequencies still correct in the newer kernel (CLK, > > HSYNC, VSYNC)? > > Where would I check those and which ones are you referring to exactly? > There are a lot of clock definitions in the kernel, let alone for the > MX25. It could be that I misunderstood your pointer. I don't talk about the SoC's internal clocks. I mean the real clocks the LCD receives from the CPU: pixel clock (check the correct edge), VSYNC and HSYNC clock (polarity the right one?). And maybe also the DE signal. Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
