GSM modem - just ERROR

[Nils Faerber]

Harald Welte schrieb:
> On Fri, Mar 16, 2007 at 03:03:13PM +0100, Nils Faerber wrote:
>> Back to the ringtone...
[...]
>> So to the question a little differently (now that I know that there is
>> only one speaker built-in ;)
>> 	Is there a way to amp the output of the internal speaker to a level
>> that is audible without holding the NEO near to my ear?
> yes, you can just use the two loud stereo speakers instead of the
> receiver speaker :)
> 
>> I am not sure how other phones do that in hardware... do they use a
>> second speaker for ringer and free speaking?
> 
> yes, we're actually having two 'second' speakers and a 1.2Watts
> amplifier for that.

Oh, nice!
But where are those located or activated?
I cannot seem to find them in the hardware pictures.
Or is this just a setting of special mixers? Then, which?

>> If there is such thing it would be great to have a (brief) document
>> describing the hardware, i.e. which parts are there, how they are
>> connected and why it was done the way it was done. This would help to
>> understand the hardware and how it can be used/programmed.
> I would love to have such a document myself.  Unfortunately even I have
> to manually 'reverse-engineer' the changes by visuall comparing
> schematics of different revisions. 

He - sounds somehow familiar ;)
We had pretty much the same situation with another project (which sadly
switched to WinCE :(

> Especially the "why it was done" a particular way is a question that I
> keep asking myself about dozens of things, without being able to come up
> with any apparent or logical reason.
> 
> The whole hardware situation is a real mess, I have to admit.
> 
> This combined with a severe lack of staff, skills and time.... => I
> don't think there will be any public document on the hardware any time
> soon. 

Maybe another Wiki page could be started for that. But please just one
page ;)
Public schematics (not PCB layout!) would also be nice...

> Also, things keep changing, and we yet have to see a hardware revision
> that completely works :(
> 
> FIC will probably not like me talking about this that openly - but
> seriously, we're not doing much else than fire-fighting hardware
> problems for half a year now.  There are lots of plans how to do it
> better with the next devices on the roadmap.  But for now, we're still
> stuck with the current situation.

Which is already quite fine...
I think everyone who has dealt with such a project can report the same
or worse.
At least from my experience I am already very happy with the current
situation. Most things do already work, there is a good deal of
documentation already existing and things that are missing are mostly
already in process.

> Let's hope GTA01Bv4 will solve all of the known bugs, and we have a
> hardware revision that we can actually produce reliably in quantity.

Let's hope that Sean's claim that FIC has a long and good history in
hardware making prooves to be correct ;)

>> And congratulations for the kernel port - having done such thing myself
>> I think you did a pretty good job abstracting the hardware properly.
>> That's good!
> thanks, I'm not entirely happy yet, but it works for the time being ;)

I have seen much much worse - we all e.g. know this MV stuff.
So lean back, you almost cannot do more wrong than them ;)

> Particularly crude is the PMU driver.  All voltage settings, etc. need
> to be put in a platform_data structure that is specific to the neo.  The
> pcf50606.c should not make any assumptions about being inside a Neo1973
> device.  It should further provide something like an 'IORESOURCE_POWER',
> which is then used by neo1973 platform devices and passed on to the
> actual drivers.

This also puzzles me but for different reasons...
I have seen that the readings that are exposed in /sys/... are quite
strange. The current is 0 but the battery is still reported as
"charging"? Shouldn't the charger be shut off when the battery is full?
I also know that the pcf50606 can be mask-programmed for the battery
type. This is quite important for the charging logic (charging curve,
thresholds, keep-alive charging, charging while application processor in
sleep mode, etc.). Is the NEO's PMIC mask programmed to the used battery
type?

> Basically, power needs to be treated equal to any otehr resource such as
> memory, GPIO, IRQ, ...

Interesting idea.
For some devices this might work or even be necessary. There are other
devices, I remember the old iPaq 36xx, that have their own charging
controller which is quite independant and simply outputs its state. On
the other hand even then the resource could provide power levels to
compare against to judge full/empty/critical levels...
Hmm...

Cheers
  nils faerber

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
--