<uvos>
freemangordon: thats correct a "dumb" charger (ie data pins tied) is assumed to be able to handle at least 2A this isent a spec but was common practice when the d4 was designed. this we can implement fairly easy
<uvos>
the greater problem from a safty perspective is that on a smart port
<uvos>
d4 dosent negotiate for power, either via usb2.0 spec to get 500mA or using one of the qc specs for more
<uvos>
(In leste here, the d4 negotiates for power in android via 2.0 spec)
<uvos>
atm for instance pluging in a d4 into my xt1602 make it resett it because it can only output 30mA
<uvos>
could cause damage alos
meridion has quit [Ping timeout: 246 seconds]
meridion has joined #maemo-leste
<Wizzup>
uvos: this week or weekend I'll have time for droid 3 tests, do you have a refresher on what you needed me to do?
<Wizzup>
rather what to dump/analyse
uvos has quit [Ping timeout: 252 seconds]
akossh has quit [Read error: Connection reset by peer]
mardy has quit [Read error: Connection reset by peer]
mardy has joined #maemo-leste
akossh has joined #maemo-leste
rafael2k has joined #maemo-leste
<Wizzup>
btw: got a mail from a happy d4 user
<Wizzup>
something about the modem in the US, but also:
<Wizzup>
So i have a week testing the Motorola Moserati and Mameo Leste then i really like how so good feeling. Thank you for the work!
uvos__ has joined #maemo-leste
<uvos__>
Wizzup: so we need: full cpcap dumps, while loaded and while idle
<uvos__>
we need a dump of the emif registers (see omap4 trm)
<uvos__>
also loaded and idle
<uvos__>
we need dumps of the led cpcap registers at different keyboard and display brightnesses
<uvos__>
we require a dump of the lm i forget the number led controller too but that might be hard to pull off on android
<uvos__>
that should be a start
<uvos__>
nice @ user
<uvos__>
probubly a d3 would be good for him, being in us
<uvos__>
or bionic
<Wizzup>
I did mention the bionic
<Wizzup>
check @ data
<freemangordon>
uvos__: detecting usb/charger should be easy
<freemangordon>
detecting the type of USB I am not sure
<uvos__>
right unfortinatly dumb chargers are getting a bit rare, usally you get qc implementing smat ports these days
<uvos__>
*smart
<uvos__>
but detecting tied usb data pins is a start
<uvos__>
no doubt
<freemangordon>
are you sure d4 ever draws more than 500mA from USB port?
<uvos__>
you cant draw 500mA from a usb port is the problem
<uvos__>
you have to ask the port
<uvos__>
500mA is just the max you could ask for in usb2.0
<freemangordon>
I see
<freemangordon>
does d4 android fullows that?
<uvos__>
yes
<freemangordon>
ok
<freemangordon>
still, I will start with dumb/fast charger detection
<uvos__>
also no android dosent implement usb qc
<uvos__>
that wasent around at the time
<uvos__>
it could tho
<freemangordon>
do you know how wall charger (d+d- short) can be distinguished from 2.4 A charger?
<uvos__>
but this is soemthing for later
<freemangordon>
like, is there some difference in resistance, or ID pi or something?
<uvos__>
not sure what you mean, the dumb chargers cant be identified
<uvos__>
you just have to assume something
<uvos__>
this was a huge issue
<uvos__>
and is the reason why usb qc exists
<uvos__>
its usualy safe to assume 2a
<uvos__>
this seams to have been most common practivce
<uvos__>
*practice
<freemangordon>
I am not sure 2.4A charger I have here is a dumb one
<uvos__>
it might implement usb qc
<uvos__>
of some kind
<freemangordon>
because it has 2 outputs, one marker as "1A", which is wallcharger for sure
<uvos__>
this allows you to negotate up to 65W or so
<freemangordon>
*marked
<freemangordon>
isn;t that USB C?
<uvos__>
no thats usb pd
<freemangordon>
BC1.2?
<uvos__>
yes 65w might be over usb c only not sure
<uvos__>
anyhow you can negotiate more than 500mA after usb2.0
<uvos__>
3.0 base spec supports 1a allready i think and then theres more extensions
<uvos__>
it gets pretty complicated ;)
<freemangordon>
something with d lines resistance?
<uvos__>
no, same protocoll as used in 2.0 to negotiate for 500mA
<uvos__>
at least for 3.0 base
<uvos__>
idk how the more advance stuff works
<uvos__>
where you can ask for different voltages too etc
<freemangordon>
ah, this is something that is out of control of SW, I guess
<uvos__>
no idea
<uvos__>
i pretty much checked out after usb 3.0
<uvos__>
:P
<uvos__>
usb spec: USB devices shall limit the power they consume from VBUS to one unit load or less until configured.
<uvos__>
thats 100uA
<freemangordon>
right
<freemangordon>
but, this is what musb shall already do, no?
<sicelo>
uvos__: freemangordon: you call the chargers dumb? anyway "the dumb chargers cant be identified" ... can't be exactly correct. in some cases at least, the identification of the 'dumb charger' as you call it happens in the pmic. there's no assumption. it knows when the d-pins are shorted
<freemangordon>
sicelo: I call it "wall charger" :)
<freemangordon>
and yes, we can detect d lines shortened
<sicelo>
i'd call it that too :-)
<uvos__>
sicelo: dumb charges cant be idenfied in terms of capapbiliy
<uvos__>
there are 1A devices with pins shorted and 3A
<freemangordon>
right
<freemangordon>
I think originally it was 1A
<sicelo>
okay. that's a different statement now
<freemangordon>
I wonder how android managed to correctly identify 1200 mA
<freemangordon>
this is what nokia charger is capable of
<freemangordon>
still I am not sure that cpcap-charger is responsible for any USB negotiation
<freemangordon>
IIUC it shall ask usb driver for remote port parameters and adhere to it, no?
<uvos__>
no
<uvos__>
the slave supplies the host with a series of configurations
<uvos__>
and the host chooses one
<freemangordon>
ok
<freemangordon>
but this is not that charger driver job to do it
Twig has quit [Remote host closed the connection]
<freemangordon>
but usb driver
<uvos__>
sure but they must communicate somehow obv
<freemangordon>
right
<freemangordon>
lemme see what gets negotiated here
<freemangordon>
but usb driver
<freemangordon>
*by
<sicelo>
freemangordon: just wild guess ... i see 11-10 09:26:00.633 177 177 I BATTD : set_charge_current=1300
<sicelo>
11-10 09:26:01.642 177 177 I BATTD : set_charge_current=1200
<uvos__>
so on some usb chips
<uvos__>
just takling form expieriance working embedded stuff
<sicelo>
so maybe it just adjusts what it can pull vs what it can get ... and thus ends up at 1200
<uvos__>
the usb chip dose everything in hw/fw
<uvos__>
wrt negotation with host
<uvos__>
dont know how typical this is on smartphones
<sicelo>
at least on N900 it is
<sicelo>
the negotiation is done by the phy (isp1707)
<freemangordon>
sicelo: ok, but how does it know that it can't draw 1800?
<sicelo>
does it ever do 1800 (assuming an 1800-capable charger)?
<freemangordon>
I guess yes
<uvos__>
eh 1800 is aufully close to 1c
<uvos__>
the reccomended speed to charge a lipo....
<uvos__>
since the d4 has 1750mah batt 1800 is esentally 1c
<freemangordon>
uvos__: this is the current drawn from the charger, not charging current ;)
<uvos__>
right
<uvos__>
still they may have done this to ensure charging speed never exceeds 1c
<uvos__>
possibly
Twig has joined #maemo-leste
<sicelo>
freemangordon: so yes, as you stated, it starts by attempting to pull 1800. evidently it notices this fails, then switches to 1300, etc. until it lands on the highest that it can really pull
<freemangordon>
no
<freemangordon>
I doubt it can load to 1800mA by will
<uvos__>
on dumb chargers i dont
<uvos__>
phones breaking weak dumb chargers was common and the reason for better specs with usb 3+
<uvos__>
it might really be just monitoring votlage drop
<uvos__>
if a dumb charger is detected
<uvos__>
on a smart port however, yes, no it negotiates
<freemangordon>
voltage drop?
<uvos__>
if vbus drops below a threshold cpcap generates an irq
<freemangordon>
hmm, hmm
<freemangordon>
but still, we need to load
<freemangordon>
or, it sets to max, if irq comes , it reduces max current, etc
<freemangordon>
do you think it wokrs like that?
<uvos__>
i hope it goes the other way
<uvos__>
but yes this might be what it dose on a dumb charger
<freemangordon>
not really, by looking at batd code and logcat
<uvos__>
ok
<freemangordon>
it seems to always set ititial max to 1800
<freemangordon>
*initial
<uvos__>
are you using a motorola charger btw
<uvos__>
or a random one
<uvos__>
its possible motorola did soemthing totaly cusom on stock chargers
<uvos__>
samsung for sure did
<uvos__>
(some codeing with voltage deviders on data pins)
<freemangordon>
printk() there shows that it is called, with correct mA
<freemangordon>
ant it turn it calls usb_phy_set_power()
<freemangordon>
*and
rafael2k has quit [Ping timeout: 255 seconds]
<sicelo>
freemangordon: while there, how would one use printk (or some other facility) to see if *gadget contains correct parameters (using that function as an example)
<freemangordon>
not sure I understand the question
<freemangordon>
printk is like printf, more or less
alex1216 has quit [Quit: WeeChat 2.3]
<sicelo>
i guess in that function, you can see the mA is correct because it's passed as an int already. how would you inspect *gadget, since that's a struct?
<freemangordon>
if you expect things like js "console.log(JSON.stringify(object))"
<freemangordon>
there is no such thing :)
<freemangordon>
you must print meber by member
<freemangordon>
*member
<uvos__>
THIS IS C
<freemangordon>
mhm
<uvos__>
:P
<uvos__>
you could run a debugger on the kernel and have gdb print the struct
<uvos__>
but not on d4
<sicelo>
freemangordon: because the error is "[ 1.389648] musb-hdrc musb-hdrc.0.auto: error -ENXIO: IRQ mc not found" ... it's that function which should find this 'mc' IRQ
<uvos__>
dose the n900 debug kit have jtag?
<uvos__>
btw
<uvos__>
just curious
<freemangordon>
sicelo: something is missing in the DTS
<sicelo>
if i hardcore the IRQ from DTS in musb/musb_core.c, it works, so i think this is what i should follow until i find out why the function can't get it correctly
<sicelo>
freemangordon: the mc interrupt is there in dts, and it's correct.
<freemangordon>
could it be that DTB is too big?
<freemangordon>
I remember there were some issues with attached DTBs
<freemangordon>
also, do you see that irq in /sys/firmware where it is expected?
<sicelo>
< freemangordon> I remember there were some issues with attached DTBs ... <-- would you remember the source of this info? i would like to investigate further
akossh has quit [Ping timeout: 246 seconds]
Langoor has quit [Ping timeout: 248 seconds]
nohit has quit [Read error: Software caused connection abort]