Hi Joan,
[email protected] wrote:
> [...]
> The most important and crucial step to fix
> the jittering and weird Y value reporting was fixed by introducing 4 10nF
> capacitors in parallel for the X+|X-|Y+|Y-, as indicated in the MX25 RM,
> Figure 44-5, chapter 44.2.2. This significantly reduced the noise.
But you should keep in mind you must also extend the settling time if you
increase the capacitive load on the lines. This will slow down conversion.
> The only problem we have left, is that we have no means of calibrating the
> pointer (still on X11 as the QT/E hasn't finished compiling in
> OpenEmbedded yet), so towards the right horizontal we can almost go to the
> limits of the touch screen, while towards the left horizontal, we have
> about 50 pixels that cannot be reached by the pointer. Any ideas
> (ts_calibrate still does not work)?
"ts_calibrate" must work if the touchdriver reports reasonable values via the
kernel's input subsystem. So, what exactly means "still does not work"?
> We have also found out why the 3.3-rc kernels introduced the washout in
> out LCD. Your hint with regard to the changes of the active state of the
> UPLL gave us the idea of fiddling with the LD[0-17], where we pin-pointed
> the problem down to LD16 and LD17. Through mere luck (as we don't fully
> understand the detailed implications of our actions) we made the following
> changes:
>
> -#define MX25_PAD_GPIO_E__LD16 IOMUX_PAD(0x400, 0x204, 0x02, 0,
> 0, NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_E__LD16 IOMUX_PAD(0x400, 0x204, 0x02, 0,
> 0, PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_MAX | PAD_CTL_SRE_FAST)
> -#define MX25_PAD_GPIO_F__LD17 IOMUX_PAD(0x400, 0x208, 0x02, 0,
> 0, NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_F__LD17 IOMUX_PAD(0x400, 0x208, 0x02, 0,
> 0, PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_MAX | PAD_CTL_SRE_FAST)
"PAD_CTL_PUS_100K_DOWN" makes less sense for an output pin. "PAD_CTL_SRE_FAST"
makes no sense, as this GPIO E group has no such bit to change (refer table
513 in the datasheet).
"PAD_CTL_DSE_MAX" makes sense if the electrical lines to your display are very
long or the capacity load is high. But this setting will increase power
consumption and also increases the EME. Keep it as low as possible to
fullfill your requirements. And: changing this value to get better visible
results may shows the wrong clock edge is in use! Fill your framebuffer with
static random data ("cat /dev/random > /dev/fb0"). If you see some pixels
flickering you are using the wrong clock edge.
> This effectively not only fixes the washout, but it gave us much better
> color "saturation" and near pixel-perfect luminance.
If you need different settings for different LCD signals lines you must check
your board layout. All these lines must be electrical equal!
> [...]
> >> Another thing is that the Y position does not seem to be reported
> >> correctly to the input system in our case, so we had to alter the
> >> following line for "inverse" reporting
> >> (arch/arm/plat-mxc/imx-ts.c:imx_create_event_for_4wire):
> >>
> >> - input_report_abs(ts->input, ABS_Y, y_pos);
> >> + input_report_abs(ts->input, ABS_Y, 0xfff - y_pos);
> >
> > The same should work if you exchange the Y+ and Y- electrical connectors.
>
> Yeah, but considering that the connection is according to the data sheets
Never trust a datasheet ;-)
> of the MX25 and the CLDC, your driver should work universally well. I try
> to have a reproducible design with the lowest overhead on maintaining
> kernel patches. The above would be a completely unnecessary patch IMHO.
> After a first re-check of all the electrical configurations for the
> X+|X-|Y+|Y- combinations, while trying to decipher the bloody Chinese data
> sheet, I suspect that we have indeed cross-wired Y+ and Y-. This would
> certainly explain the need for the above patch.
>
> > Perhaps mounted head down?
>
> Nope, the PCR and the GPIO's are now configured according to the defaults
> of the data sheets.
>
> Well, at this point, I believe a tremendous thank you is in order.
You are welcome.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
