<Joerg-Neo900>
any idea how to further tackle this, for that mystery to investigate?
<Joerg-Neo900>
I mean, the Nokia schematics are not sacrosanct either
<Joerg-Neo900>
they already omitted evidently existing console UART on testpoints
<Joerg-Neo900>
not to mention a few other minor errors I found
<Joerg-Neo900>
I might consider grabbing a bare PCB and solder a wire to OMAP AA3 ball pad, then see if it leads to anywhere. This is a mega pita though to do, and I'd rather follow a more software centric and less intrusive approach
xmn has joined #neo900
<Joerg-Neo900>
((mega pita)) particularly considering that a negative result never is confirmed to be correct
<Joerg-Neo900>
Pali: could we toggle GPIO_182 and see what happens? I have the instrumentation to do so
<Joerg-Neo900>
assuming it's related to ECI, we should see effects on HS-jack
<Joerg-Neo900>
sure sending a value between 0 and 4 to eci_mode *will* result in effects on HS-jack, however that's no proof for any of those effects related to GPIO_182
<Pali>
so only rx51_set_eci_switches and rx51_set_jack_bias
<Joerg-Neo900>
I'd raher use a tiny bit of c code that directly does same code as found in gpio_set_value(RX51_ECI_SWITCH_1_GPIO, input);
<Joerg-Neo900>
ideally even within an endless loop, with a usleep(2000) between toggling the GPIO, until I abort the executable with ^C
<Joerg-Neo900>
even better still would be a mode where that binary sends first value (argv[1]) then waits 2ms, then sends second value (argv[2]), then waits again 2ms, and then repeats
<Joerg-Neo900>
so `test182 0 1` would cause a square wave with 4ms period duration, and a `test182 0 0` or `test182 1 1` would output constant 0 or 1
<Joerg-Neo900>
err, why 182?
<Joerg-Neo900>
gpio-178 is the mystery GPIO
louisdk has quit [Remote host closed the connection]
<Joerg-Neo900>
sorry, I got a headache today, from not drinking any alcohol yesterday ;-)
<Joerg-Neo900>
isn't there a gpioset binary existing for OMAP?
<Joerg-Neo900>
anyway let me repeat: I *guess* the whole ECI stuff in N900 is based on that thesis written by the volunteer at Nokia. And then Nokia decided N900 doesn't need true ECI and optimized out the stuff that's not needed for 'normal' headset control
<Joerg-Neo900>
comparing kernel sourcecode and ECI* names to that paper might go a long way
<Joerg-Neo900>
the author's hw design was a tad overengineered anyway, e.g. switching from micbias power to a separate ECI power for no good reason
<Joerg-Neo900>
which is exactly what this weird comment >>/* ECI RX/TX connected to mic/bias line */ << sound like
<Joerg-Neo900>
this is cruft not needed for ECI
<Joerg-Neo900>
you can power the mic line from MICVIAS even during ECI data transmission, and you may keep RX and TX connected all the time, given your TX is a mere "pulldown"
<Joerg-Neo900>
I evebn got an idea _why_ Nokia decided N900 can't have ECI: they way they planned it, it needs a kernel driver which ideally needs knowledge about the low level protocol (timing, data frame etc), and that's copyright confidential patented info Nokia doesn't like to disclose in a mandatory FOSS kernel driver for linux
<Joerg-Neo900>
I'm sure they *could* have implemented it in a userland lib too, but only with help from the inhouse ECI experts which are a completely unrelated sub branch of Nokia and not friends of the maemo sub branch
<Joerg-Neo900>
and eventually they realized that this won't fly either way, and they simply discarded the obsolete stuff from circuit, but forgot to clean the kernel code
<Pali>
or discarded it from schemantics to not expose proprietary eci information...
<Joerg-Neo900>
so we either have undocumented hardware in N900 which is controlled by GPIO_178 (but not *really* needed for ECI to work), or GPIO_178 pin is simply N/C
<Joerg-Neo900>
yes :-)
SylvieLorxu has joined #neo900
<Joerg-Neo900>
I'd not be surprised to find a 6 signals ECI0:5 in that volunteer's ECI master thesis
<Joerg-Neo900>
and prolly ECI4:2 are very ECI specific and not needed for a headset jack that can't do ECI
<Joerg-Neo900>
in figure 2.4 we have: ECI_WAKE which can also serve as ECI_DATA_IN, and we got ECI_DATA (two pins, in + out) and SWITCH_WAKE, which make for our missing ECI2,3,4 signals
<Joerg-Neo900>
who had guessed that N4007 in N900 has a theshold of pretty exactly 0.6V ;-)
<Joerg-Neo900>
>> According to the accessory detection protocol, the ADC is used in normal operational mode only to measure voltages that are under the 0.6 V threshold level.<<
<Joerg-Neo900>
N 4008 however has a threshold of 1.9V which doesn't make much sense to me
<Pali>
Joerg-Neo900: I sent email to author of that kernel code... and added you to CC list in case we get any answer
<Joerg-Neo900>
*IF* N4008 was meant to act as ECI data RX "PHY", then the threshold is way too high, since ECI specs say "V_high >1.6V, V_low < 0.7V"
<Joerg-Neo900>
Pali: thanks!
<Joerg-Neo900>
:-)
<Joerg-Neo900>
~(1.6 + 0.7) /2
<infobot>
1.15
<Joerg-Neo900>
which is obviously far off from the actual threshold of 1.9V
<Pali>
I looked at nokia-av.ko code and it is suspicious!
<Pali>
enable mic bias, wait up to 500ms, read ECI_ADC if is between 1950mV and 2200mV
<Joerg-Neo900>
I didn't manage to finally 'decode' that code
<Joerg-Neo900>
check for "between 1950mV and 2200mV" is bogus, I don't see how that's backed by ECI specs
<Pali>
maybe those constants are not correct
<Joerg-Neo900>
yep, looks like
<Pali>
but whole code looks like it tries to initalize eci headset
<Joerg-Neo900>
actually ECI detection is not about voltage at all
<Joerg-Neo900>
an ECI accessory needs to not pull micbias below 1V6, unless it sends data. Detection if it's a ECI or a dumb headset is via a 4ms LOW on mic (N900 pulling low mic line by switching TVOUT_EN to TVOUT which has to be 0), and the ECI accy answers with a startbit (pulling mic line low for a iirc 80us)
<Joerg-Neo900>
*before* you drive that 4ms low, you need to give MICBIAS a 500ms time to stabilize
<Joerg-Neo900>
and ECI accy controller to PO-reset
<Pali>
/* Give the ECI headset sufficient time (more than 500 ms) to reset and stabilize the mic line, bail out on unplug */ (in nokia-av.c)
<Joerg-Neo900>
so you enable micbias, you check it's above a sane threshold of say - oh why not - 1.9V (actually 1V6 mandatory minimum), so you know it's no 3pin headphone or video cable, then after 500ms you pull MICBIAS low for 4ms and start to listen for an ECI accy to answer
<Joerg-Neo900>
note the "init01" "init02"... in names
<Joerg-Neo900>
Pali: so *my* heaset answered within 1ms after the 4ms low pulse
<Joerg-Neo900>
I don't know if 2 pulses as answer are mandatory or if that's just for redundancy, anyway ECI detection is like: send a 4ms low pulse, listen for 4(?)ms for a short (~80us) low pulse reply from an ECI headset
<Joerg-Neo900>
after listening times out, you may either *: repeat the whole '4ms low, then listen 4ms' for a few times, to make absolutely sure it's no ECI hs. Or *: already bail out from ECI detection with result "no ECI found"
<Joerg-Neo900>
Pali: for sending pulses (like the 4ms low pulse) you (make sure TVOUT pin is low/GND, and) pulse TVOUT_EN to switch the mic line from MICBIAS to TVOUT so it goes low voltage, then switch back to normal on TVOUT_EN after 4ms. -- For listening you can probably use N4007 ECI0 input which toggles on micbias<0,6V (not ideal for ECI but *normally* should 'just work'. Ideal would be 1.15V threshold which we don't have)
<Joerg-Neo900>
don't forget to blame me for the specs, in that code ;-) Otherwise they gonna bash you for not adhering to proper ECI specs (which we don't really have anyway)
<Joerg-Neo900>
the tricky bit is about the RX, you need an IRQ handler for ECI0 which triggers on both edges and calls a callback function in your code that checks if rather 80us or 350us passed by since last edge, so you can (later on) discern shiort from long low pulses, since they form 0 and 1 (or 1 and 0)
<Joerg-Neo900>
for ECI hs *detection* however you only need to check if there's been *any* pulse not sent by yourself. On the pright side sending pulses yourself via TVOUT_EN does _not_ trigger ECI0
<Joerg-Neo900>
s/pright/bright/
<Joerg-Neo900>
so the lazy man's detect_eci() would simply (after that 500ms waiting above line359) set TVOUT_EN, do a usleep(4000), unset TVOUT_EN, **lock interrupts**, set interrupt enable on ECI0 GPIO *hardware*, usleep(4000) [wait for any pulse to come in while device is 'frozen' for 4ms]; read out ECI0 irq register from hardware to see if a pulse happened; enable interrupts again to "unfreeze" device
<Joerg-Neo900>
the locking of interrupts is needed so no pther already set up IRQ handler for ECI0 pin gets called and clears the hw register, while we idle in a usleep(4000)
<Joerg-Neo900>
other*
<Pali>
it is not better to turn mic bias off? (instead switching TVOUT_EN)?
<Joerg-Neo900>
no, not fast enough, by far
<Pali>
when we switch TVOUT_EN from mic to tvout, then we need to turn off TVOUT (TV_OUT1 pin)
<Joerg-Neo900>
hw 'rate limited' by buffer caps etc
<Joerg-Neo900>
yes
<Pali>
but I do not know how to do that in nokia-av.c code
<Joerg-Neo900>
you want to make sure TVOUT is GND aka 0
<Pali>
tvout is controled probably by other driver
<Joerg-Neo900>
:nod:
<Pali>
first need to find which driver it is
<Joerg-Neo900>
sorry afk, bbl. In a hurry
<Joerg-Neo900>
(buffer cap) C4023
<wpwrak>
Joerg-Neo900: (eci, etc. gpios) looks consistent with iox.pdf, except gpio_178
<Pali>
wpwrak: that gpio 178 is unknown for us, all other gpios (from that grep output) are in rx51 schemantics
<wpwrak>
Pali: yup, that's where i took the information for iox.pdf from, too :)
<Pali>
what is iox.pdf?
<Pali>
ah, found on neo900.org
freemangordon has quit [Read error: No route to host]
freemangordon has joined #neo900
jonwil has joined #neo900
Pali has quit [Read error: Connection reset by peer]