non-touchscreen SKU support

[Quozl]

The TOUCH_HD# pin is to be:

• pulled high on a touchscreen SKU (as already occurs),
• pulled low on a non-touchscreen SKU.

When low, opening the touchscreen device shall fail with no touchscreen expected.

[Quozl]

Fixed in svn 3493 and git 95d0d2ce.

[pgf]

i missed this conversation. is this a repurposing of TOUCH_HD? before, i thought it was "if high, tri-state all touchscreen gpios", which wasn't implemented in the linux driver. now it simply means the controller is populated?

[Quozl]

thanks, good point.

no, TOUCH_HD# is an inverted signal, active low, and is an input to SoC, so the correct semantics are "if low, tri-state all touchscreen gpios". this is from page 3 of zForce_Communication_Interface_4_1.pdf and confirmed by observation on laptops with a touchscreen controller; the signal is high.

what we are doing on non-touchscreen SKU is (a) not populating the microcontroller, and R266, and (b) pulling the TOUCH_HD# signal low by populating R273. (R366 and R273 form the 3.3V to 1.8V level converter for the signal on the way to the SoC).

for the linux driver you might either:

• check TOUCH_HD# first, and if low, abandon device startup, or
• defer device startup until TOUCH_HD# goes high.

both will meet the goal of not providing a touchscreen software interface for a laptop that has no touchscreen controller. the latter will allow debugging where TOUCH_HD# is held low on boot. i imagine you would prefer the former.

[Quozl]

Is in Q7B09. Waiting for Quanta to confirm fix.

[pgf]

thanks. a fix (of the "former" style) applied to the zforce linux driver as well. much nicer than an apparent error in the kernel log.

[Quozl]

U16 is pulling TOUCH_HD# low, but U14 has a default pullup, leaving the voltage undefined. It looks like the signal is not active low after all.

[Quozl]

Fixed in svn 3502 which:

• treats the signal as active high, not active low,
• momentarily enables a SoC pull-down before sampling the pin,
• works with XO-4 touchscreen SKUs now,
• is designed to work with XO-4 non-touchscreen SKUs if the BOM is changed to depopulate U16, and keep R267 (3.3V pull-up on controller side of level converter), R266 (level converter high side), and R273 (level converter low side).

[pgf]

my understanding was that TOUCH_HD# is intended to be an input from the neonode debug connector that tells the SoC to tri-state its drivers, so that the msp430 can be driven from the connector. if that's the case, then we can't simply treat it as active high, unless there's an inversion being done somewhere, and i don't see that.

but as you've observed, the touchscreen controller is pulling the signal low in normal operation. i think that behavior is incorrect, and that it should be an input to the controller. but even if the controller should be driving that pin, it shouldn't be driving it low in normal operation.

[Quozl]

i agree there is a bit of ambiguity. one of the documents (2012-05-04) says the signal is active low, another later document (2012-06-25) does not say the signal is active low. both documents say the signal _on the microcontroller_ is an indicator to host processor.

i didn't want to ask for the signal to be changed, but i see you have.

if the signal is inverted by neonode in a following release, we will have to deal differently with the existing B1 and C1 population.

if the signal is left as is, we can deal with the issue using a BOM change (populate/depopulate) only.

[pgf]

why will we have to treat existing B1 and C1 differently, if they change the firmware to not drive that signal low? won't that simply make things work the way we think they should? perhaps i'm hindered by not having access to the non-TS BOM.

[Quozl]

in that we will have to deal with the population of laptops in the B1 and C1 range that have old touchscreen firmware, which behave with active high TOUCH_HD#.

the B1s can't upgrade touchscreen firmware without losing touchscreen performance, due to the different lightguide.

the C1s can upgrade, but if we treat TOUCH_HD# as active low then we can't do this upgrade automatically.

sure, it is a change that can be managed, but it seems the only reason we want the change is so that it meets neonode's documentation and lets them use their debug connector. we don't really need those two things.

i don't have the BOM either, i'm relying on memory of discussions.

[pgf]

if a laptop is a B1, we can skip the check entirely. if it's a C1, we can either skip the check, or tell the owner to do a manual firmware upgrade. doesn't seem like a big deal, and it means we're not designing around their bug. i'm tired of designing around vendor bugs. ;-)

[Quozl]

• a CForth patch to change to set the PULL_SEL bit,
• an Open Firmware patch to reverse the polarity of the TOUCH_HD# signal and include 0.0.0.10 of the touchscreen firmware,
• a test build.

Skips the test for B1. Breaks automatic upgrade of touchscreen firmware, as agreed.