GSM modem - just ERROR

[Nils Faerber]

Harald Welte schrieb:
> On Fri, Mar 16, 2007 at 04:44:57PM +0100, Nils Faerber wrote:
>>> 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.
> 
> http://wiki.openmoko.org/wiki/Disassembling_Neo1973#Empty_case_frame
> note the comment below the picture about those speakers.

Ooops, I just looked at:
http://wiki.openmoko.org/wiki/Neo1973_Hardware

Which has not mention of speakers ;)

>> Or is this just a setting of special mixers? Then, which?
> please just look at the asound.state files in /etc/alsa.   One of them
> is for sound playback via those speakers.

Ah, OK.
I took this to enable the stereo headset output, which worked, but was
not aware that it would also enable the speakers (did not try that
without headphone inserted ;)

>>> 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 ;)
> well, just keep adding to the 'Neo1973 Hardware' page.

OK, when I hit new poblems and information to solve them I will do so ;)

>>> 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?
> that sounds like a software bug, if nothing else.

OK.

>> I also know that the pcf50606 can be mask-programmed for the battery
>> type. 
> I have never heared about this. 

Well, page 61 first paragraph talks about it.
If I read tha datasheet correctly you could mask program almost all
operation parameters so that you would almost not need any
initialisation of the PMIC. It would simply do the right thing including
charging the battery and generating the right voltages. On some systems
the reset state might also become crucial when other than the normal
reset voltages would be needed to get the system out of reset.

>> 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?
> The charge controller inside the PCF50606 (see data sheet linked from
> neo1973 hardware page) is software-programmed to CC_CV charging with
> 4.2V li-ion cell.  

Great!

>>> 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...
> 
> I'm not talking about charging here.  It's about any peripheral unit.
> The bluetooth chip doesn't only have IO and IRQ resources, but it also has a
> power resource.  If the device is suspending/resuming or whatever, the
> driver for that component needs to be able to tell the PMU supplying
> that power what it wants - in a way independent from whatever kind of
> PMU the specific device might be using.
> 
> If a driver doesn't want anything special, the 'power bus'
> implementation would then just do the default: power-up to the voltage
> specified in the platform_resource of mach-neo1973.c before
> probing/using and before resuming the devicer, and power-down on
> suspend/power-off, after the driver detached from the device.
> 
> The same goes for the GSM, GPS, etc.

Ah, now I see, thanks.
Yes, that sounds reasonable. That would help unclutter the driver code
to a large extend, removing some platform dependant stuff from the
driver itself.

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
--