Re: Nokia N900 sound driver and ECI GPIOs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 04 January 2017 23:27:49 Aaro Koskinen wrote:
> Hi,
> 
> On Mon, Jan 02, 2017 at 10:05:39PM +0100, joerg Reisenweber wrote:
> > On Mon 02 January 2017 21:01:01 Pali Rohár wrote:
> > > On Monday 02 January 2017 19:49:45 Aaro Koskinen wrote:
> > > > The schematic shows ECI(5:0), but only 3 are connected/used.
> > > > There were 3 other GPIOs reserved but not used in the final
> > > > product.
> > > 
> > > Are you sure that this is truth (maybe you have some
> > > information)? Or you just looked at schematic and deduced this
> > > observation (as other people too)?
> > > 
> > > Joerg already told us that RX51 schematic does not 100% match
> > > production N900 and e.g. there is missing UART3 pins...
> > 
> > We found this, see https://irclog.whitequark.org/neo900/2017-01-01
> > (has a lot of possibly useful references/links)
> > The question is if pin AA3 aka GPIO_178 is actually NotConnected in
> > N900 or it's just an omission in schematics and there's actually
> > some more 'stealth hardware' in N900 that doesn't show up in docs,
> > just like the testpoint UART console
> > http://wiki.maemo.org/N900_Hardware_Hacking#Debug_ports which also
> > are missing in schematics.
> > 
> > > What we know that gpio 178 is *already* controlled and changed by
> > > production Nokia kernel running on production N900 devices (as I
> > > wrote in first email).
> > 
> > I could use one of the unpopulated N900 PCB and solder a wire to
> > the OMAP AA3 pad, then try to make sure it's not connected to
> > anything, or if it is then find out about the details of this.
> > But I'm reluctant to do this, since it's an error prone and (in
> > case of N/C) not verifiable procedure, so I'd appreciate any
> > further info, whether from historical anecdote or from sourcecode
> > review and conclusions, regarding that.
> 
> Even if the published production kernel source controls GPIO 178, it
> does not mean the production device has it connected, as the same
> kernel also supported many older in-house prototype versions of the
> hardware (and some of those had it connected).

Yes, seems reasonable. Also in production kernel source there is on some 
places check for prototype hw revision and acts differently...

> Probably the easiest test would be to take the final published
> source, and then comment out all the GPIO 178 related code and build
> and run the kernel on the production device. Then see if you can
> observe any difference in behaviour.

Current mainline kernel does not control GPIO 178, so looks like audio 
somehow working... Jarkko sent driver to mainline so I asked in this 
thread if does not know something... But A/V cable detection is not in 
mainline (yet).

We can do that test to verify if production Maemo system is working as 
before. But result "nothing visible" does not prove that GPIO does not 
control anything. With this test we can just prove if system stops 
working as before.

-- 
Pali Rohár
pali.rohar@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux