Hi Joan, joancarles wrote: > >> > 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. > > Just to make sure, we're talking about the LCD noise reduction > mentioned in 44.3.8.
Yes, we do. > >> 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 have enabled those bits (named them TGCR_HSYNCEN and TGCR_HSYNCPOL) > and put the following code into imx_ts_init(): > > /* Set LCD hsync enable to reduce noise effects from LCD */ > imx_adc_ts_set_tgcr(ts->imx_adc, TGCR_HSYNCEN); > imx_adc_ts_set_tgcr(ts->imx_adc, TGCR_HSYNCPOL); > > And I adjusted the imx_adc_ts_set_tgcr() function in adc-v1.c to keep > those bits (for safety reasons): > > /* restrict access to touchscreen relevant bits */ > val &= TGCR_PEN_DEBT_MASK | TGCR_PDBEN | TGCR_PDEN > | TGCR_HSYNCEN | TGCR_HSYNCPOL; > > reg = readl(adc->regs + TGCR) & > ~(TGCR_PEN_DEBT_MASK | TGCR_PDBEN | TGCR_PDEN > | TGCR_HSYNCEN | TGCR_HSYNCPOL); > > Now, the only combination of TGCR_HSYNCEN and TGCR_HSYNCPOL that works, > is having them in original TGCR register state, which is 0/0. Enabling > either one of the bits or both results in the touch screen driver not > reporting any value, hence not detecting the PEN DOWN interrupt. Funny result. Maybe I also tested these bits and it failed also here. I do not remember. This ADC with its statemachine is a beast and the manual for it is a pain. > >> 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. > > The LCD data sheet (Chinese manufacturer :)) does not mention anything, > however in this case it does not matter, because I have tested all > possible combinations of the two bits and the only working one is > setting both to 0, which is the default. Interesting enough, setting > only TGCR_HSYNCPOL without the TGCR_HSYNCEN using the above mentioned > changes also results in the driver not detecting the PEN DOWN interrupt. :( > >> 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. ;) > > Reading the specs I would say that it is completely irrelevant from a > timing point of view. But then again, the specs have deceived me more > than once in the past. Most important argument against using this feature now is: it does not work. ;) > >> >> 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. > > Fair enough. But I reckon if the pad routing were incorrect, I wouldn't > be seeing anything on my LCD. But if only a part of the routing is incorrect, you see most of the image on LCD, but not all. > >> > 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. > > I need to read more about this. Currently, the setup is as follows in > my platform: > > [...] > > The oscilloscope shows that LCD clock is around 24MHz, which > corresponds to the .pixclock setting for the frame buffer driver. > Independent of the VSYNC and HSYNC clock and the DE signal, I have not > touched those values and the hardware has not changed: so why on earth > does the kernel 2.6.x work fine, while kernel 3.3.x gives me wash-outs > on the LCD, taking into account that the the imxfb driver has not > changed, that the basic MX25 PAD configuration setup has not changed, > etc. If you are a git expert you could use its bisecting feature to find the code change that gives you this visible change. But it takes time to do it. > A (currently) clueless cheers Sorry, I also run out of ideas now. Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
