| freemangordon | uvos: well, it seems that batd always starts with 1800 mA when a charger is detected | 08:27 |
|---|---|---|
| freemangordon | this is logcat for a Nokia wall charger (AC 10E) https://pastebin.com/9wRX7kfH | 08:29 |
| 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 | 10:09 |
| uvos | the greater problem from a safty perspective is that on a smart port | 10:09 |
| uvos | d4 dosent negotiate for power, either via usb2.0 spec to get 500mA or using one of the qc specs for more | 10:10 |
| uvos | (In leste here, the d4 negotiates for power in android via 2.0 spec) | 10:10 |
| uvos | atm for instance pluging in a d4 into my xt1602 make it resett it because it can only output 30mA | 10:11 |
| uvos | could cause damage alos | 10:11 |
| 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? | 10:22 |
| Wizzup | rather what to dump/analyse | 10:22 |
| Wizzup | btw: got a mail from a happy d4 user | 11:17 |
| Wizzup | something about the modem in the US, but also: | 11:17 |
| 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! | 11:17 |
| uvos__ | Wizzup: so we need: full cpcap dumps, while loaded and while idle | 11:22 |
| uvos__ | we need a dump of the emif registers (see omap4 trm) | 11:22 |
| uvos__ | also loaded and idle | 11:22 |
| uvos__ | we need dumps of the led cpcap registers at different keyboard and display brightnesses | 11:22 |
| 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 | 11:23 |
| uvos__ | that should be a start | 11:23 |
| uvos__ | nice @ user | 11:25 |
| uvos__ | probubly a d3 would be good for him, being in us | 11:25 |
| uvos__ | or bionic | 11:25 |
| Wizzup | I did mention the bionic | 11:33 |
| Wizzup | check @ data | 11:43 |
| freemangordon | uvos__: detecting usb/charger should be easy | 11:43 |
| freemangordon | detecting the type of USB I am not sure | 11:46 |
| uvos__ | right unfortinatly dumb chargers are getting a bit rare, usally you get qc implementing smat ports these days | 11:46 |
| uvos__ | *smart | 11:46 |
| uvos__ | but detecting tied usb data pins is a start | 11:46 |
| uvos__ | no doubt | 11:46 |
| freemangordon | are you sure d4 ever draws more than 500mA from USB port? | 11:47 |
| uvos__ | you cant draw 500mA from a usb port is the problem | 11:47 |
| uvos__ | you have to ask the port | 11:47 |
| uvos__ | 500mA is just the max you could ask for in usb2.0 | 11:47 |
| freemangordon | I see | 11:47 |
| freemangordon | does d4 android fullows that? | 11:47 |
| uvos__ | yes | 11:47 |
| freemangordon | ok | 11:48 |
| freemangordon | still, I will start with dumb/fast charger detection | 11:48 |
| uvos__ | also no android dosent implement usb qc | 11:49 |
| uvos__ | that wasent around at the time | 11:49 |
| uvos__ | it could tho | 11:49 |
| freemangordon | do you know how wall charger (d+d- short) can be distinguished from 2.4 A charger? | 11:49 |
| uvos__ | but this is soemthing for later | 11:49 |
| freemangordon | like, is there some difference in resistance, or ID pi or something? | 11:49 |
| uvos__ | not sure what you mean, the dumb chargers cant be identified | 11:50 |
| uvos__ | you just have to assume something | 11:50 |
| uvos__ | this was a huge issue | 11:50 |
| uvos__ | and is the reason why usb qc exists | 11:50 |
| uvos__ | its usualy safe to assume 2a | 11:50 |
| uvos__ | this seams to have been most common practivce | 11:51 |
| uvos__ | *practice | 11:51 |
| freemangordon | I am not sure 2.4A charger I have here is a dumb one | 11:51 |
| uvos__ | it might implement usb qc | 11:51 |
| uvos__ | of some kind | 11:51 |
| freemangordon | because it has 2 outputs, one marker as "1A", which is wallcharger for sure | 11:51 |
| uvos__ | this allows you to negotate up to 65W or so | 11:51 |
| freemangordon | *marked | 11:51 |
| freemangordon | isn;t that USB C? | 11:52 |
| uvos__ | no thats usb pd | 11:52 |
| freemangordon | BC1.2? | 11:52 |
| uvos__ | yes 65w might be over usb c only not sure | 11:52 |
| uvos__ | anyhow you can negotiate more than 500mA after usb2.0 | 11:52 |
| uvos__ | 3.0 base spec supports 1a allready i think and then theres more extensions | 11:53 |
| uvos__ | it gets pretty complicated ;) | 11:53 |
| freemangordon | something with d lines resistance? | 11:53 |
| uvos__ | no, same protocoll as used in 2.0 to negotiate for 500mA | 11:53 |
| uvos__ | at least for 3.0 base | 11:53 |
| uvos__ | idk how the more advance stuff works | 11:53 |
| uvos__ | where you can ask for different voltages too etc | 11:54 |
| freemangordon | ah, this is something that is out of control of SW, I guess | 11:54 |
| uvos__ | no idea | 11:54 |
| uvos__ | i pretty much checked out after usb 3.0 | 11:54 |
| uvos__ | :P | 11:54 |
| uvos__ | usb spec: USB devices shall limit the power they consume from VBUS to one unit load or less until configured. | 11:57 |
| uvos__ | thats 100uA | 11:57 |
| freemangordon | right | 11:57 |
| freemangordon | but, this is what musb shall already do, no? | 11:58 |
| 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 | 11:58 |
| freemangordon | sicelo: I call it "wall charger" :) | 11:59 |
| freemangordon | and yes, we can detect d lines shortened | 11:59 |
| sicelo | i'd call it that too :-) | 11:59 |
| uvos__ | sicelo: dumb charges cant be idenfied in terms of capapbiliy | 11:59 |
| uvos__ | there are 1A devices with pins shorted and 3A | 11:59 |
| freemangordon | right | 12:00 |
| freemangordon | I think originally it was 1A | 12:00 |
| sicelo | okay. that's a different statement now | 12:00 |
| freemangordon | I wonder how android managed to correctly identify 1200 mA | 12:00 |
| freemangordon | this is what nokia charger is capable of | 12:01 |
| freemangordon | still I am not sure that cpcap-charger is responsible for any USB negotiation | 12:02 |
| freemangordon | IIUC it shall ask usb driver for remote port parameters and adhere to it, no? | 12:02 |
| uvos__ | no | 12:02 |
| uvos__ | the slave supplies the host with a series of configurations | 12:03 |
| uvos__ | and the host chooses one | 12:03 |
| freemangordon | ok | 12:03 |
| freemangordon | but this is not that charger driver job to do it | 12:03 |
| freemangordon | but usb driver | 12:03 |
| uvos__ | sure but they must communicate somehow obv | 12:04 |
| freemangordon | right | 12:04 |
| freemangordon | lemme see what gets negotiated here | 12:04 |
| freemangordon | but usb driver | 12:04 |
| freemangordon | *by | 12:04 |
| sicelo | freemangordon: just wild guess ... i see 11-10 09:26:00.633 177 177 I BATTD : set_charge_current=1300 | 12:05 |
| sicelo | 11-10 09:26:01.642 177 177 I BATTD : set_charge_current=1200 | 12:05 |
| uvos__ | so on some usb chips | 12:05 |
| uvos__ | just takling form expieriance working embedded stuff | 12:05 |
| sicelo | so maybe it just adjusts what it can pull vs what it can get ... and thus ends up at 1200 | 12:05 |
| uvos__ | the usb chip dose everything in hw/fw | 12:05 |
| uvos__ | wrt negotation with host | 12:05 |
| uvos__ | dont know how typical this is on smartphones | 12:06 |
| sicelo | at least on N900 it is | 12:06 |
| sicelo | the negotiation is done by the phy (isp1707) | 12:06 |
| freemangordon | sicelo: ok, but how does it know that it can't draw 1800? | 12:06 |
| sicelo | does it ever do 1800 (assuming an 1800-capable charger)? | 12:08 |
| freemangordon | I guess yes | 12:08 |
| uvos__ | eh 1800 is aufully close to 1c | 12:08 |
| uvos__ | the reccomended speed to charge a lipo.... | 12:09 |
| uvos__ | since the d4 has 1750mah batt 1800 is esentally 1c | 12:09 |
| freemangordon | uvos__: this is the current drawn from the charger, not charging current ;) | 12:09 |
| uvos__ | right | 12:09 |
| uvos__ | still they may have done this to ensure charging speed never exceeds 1c | 12:09 |
| uvos__ | possibly | 12:09 |
| 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 | 12:09 |
| freemangordon | no | 12:10 |
| freemangordon | I doubt it can load to 1800mA by will | 12:10 |
| uvos__ | on dumb chargers i dont | 12:10 |
| uvos__ | phones breaking weak dumb chargers was common and the reason for better specs with usb 3+ | 12:11 |
| uvos__ | it might really be just monitoring votlage drop | 12:11 |
| uvos__ | if a dumb charger is detected | 12:11 |
| uvos__ | on a smart port however, yes, no it negotiates | 12:11 |
| freemangordon | voltage drop? | 12:11 |
| uvos__ | if vbus drops below a threshold cpcap generates an irq | 12:12 |
| freemangordon | hmm, hmm | 12:12 |
| freemangordon | but still, we need to load | 12:12 |
| freemangordon | or, it sets to max, if irq comes , it reduces max current, etc | 12:12 |
| freemangordon | do you think it wokrs like that? | 12:13 |
| uvos__ | i hope it goes the other way | 12:13 |
| uvos__ | but yes this might be what it dose on a dumb charger | 12:13 |
| freemangordon | not really, by looking at batd code and logcat | 12:13 |
| uvos__ | ok | 12:13 |
| freemangordon | it seems to always set ititial max to 1800 | 12:14 |
| freemangordon | *initial | 12:14 |
| uvos__ | are you using a motorola charger btw | 12:15 |
| uvos__ | or a random one | 12:15 |
| uvos__ | its possible motorola did soemthing totaly cusom on stock chargers | 12:15 |
| uvos__ | samsung for sure did | 12:15 |
| uvos__ | (some codeing with voltage deviders on data pins) | 12:15 |
| uvos__ | but this was not wide spread | 12:15 |
| freemangordon | samsung/iqos/nokia/cellularline/asus battery pack :) | 12:16 |
| uvos__ | ok what vintage are we talking here? | 12:16 |
| sicelo | tbh it's interesting for this one to start with 1800 and work its way down. N900/bq24150 starts with 100mA, then 500, and finally 1800 | 12:16 |
| freemangordon | sicelo: it starts with 1800 when it detects wall charger | 12:17 |
| freemangordon | uvos__: what do you mean "vintage". only Nokia one is really old | 12:17 |
| freemangordon | I am testing with different ones to see how it works | 12:17 |
| uvos__ | ie before usb 3.0 and qc specs | 12:17 |
| uvos__ | ie is just a dumb charger with pins tied | 12:18 |
| freemangordon | I bet most of the charger I have here are qc ones | 12:18 |
| freemangordon | *chargers | 12:18 |
| freemangordon | for sure cellularline and battery pack are | 12:18 |
| uvos__ | ok | 12:18 |
| freemangordon | not that they are detected by d4 though | 12:19 |
| freemangordon | they are treated like wall chargers if you ask me | 12:19 |
| uvos__ | not sure how it knows to do that | 12:19 |
| freemangordon | cpcap does it | 12:19 |
| freemangordon | there are several interrupts | 12:19 |
| uvos__ | sure but how it knows that a qc port is not a normal usb port | 12:19 |
| uvos__ | ie is to be handled like a dumb charger | 12:20 |
| freemangordon | ah | 12:20 |
| freemangordon | well, seems some kind of handshake happens | 12:20 |
| uvos__ | hmm have to look at specs | 12:20 |
| freemangordon | look at MC13783UG.pdf | 12:21 |
| freemangordon | chapter 8 | 12:21 |
| uvos__ | ok | 12:21 |
| freemangordon | uvos__: seems 200k on ID pin means "Type 1 charger" and 442k "Type 2 Charger" | 12:38 |
| uvos__ | non universal extension | 12:40 |
| uvos__ | since you dont even have the id pin | 12:40 |
| uvos__ | on most chargers | 12:40 |
| freemangordon | the point is that ID pin can be used to detect carkit accessories | 12:41 |
| uvos__ | sure | 12:41 |
| freemangordon | and there are 2 types of carckit chargers it seems | 12:41 |
| freemangordon | *carkit | 12:41 |
| uvos__ | also lapdock is special probubly | 12:41 |
| uvos__ | but most chargers have just a usba so the id pin dosent help there | 12:41 |
| freemangordon | hmm, right | 12:41 |
| freemangordon | ok, so, lets assume d4 cannot detect anything but wall charger and move on | 12:42 |
| uvos__ | well and usb 2.0 power | 12:42 |
| freemangordon | right | 12:42 |
| freemangordon | though, I wonder where is that data available (max port current) | 12:43 |
| uvos__ | the usb driver must send a (or list) of configureattions supported | 12:44 |
| uvos__ | this incl power draw | 12:44 |
| uvos__ | and if the host reqjects the configureation the device dosent charge, this works ok if i connect d4 to xt1602 while running | 12:44 |
| freemangordon | yeah, maybe, I just have to find where it sends that data | 12:44 |
| uvos__ | while running android | 12:44 |
| freemangordon | ok | 12:44 |
| freemangordon | but still, max port current should be available somewhere | 12:45 |
| uvos__ | sure you can query for it too | 12:45 |
| uvos__ | i dosent seam like android dose this tho | 12:45 |
| freemangordon | where? | 12:45 |
| uvos__ | from the host i mean | 12:45 |
| uvos__ | android dosent seam to obay anything but the host rejecting the configuration tho | 12:46 |
| freemangordon | ah | 12:46 |
| uvos__ | since it just dosent charge | 12:46 |
| uvos__ | instead of taking less | 12:46 |
| uvos__ | then again maybe 30mA is just to little for it to bother with | 12:46 |
| uvos__ | it might when offered 100mA | 12:46 |
| freemangordon | ok, but I wonder how cpcap-charger can get that info | 12:47 |
| uvos__ | no idea | 12:48 |
| uvos__ | maybe its just cpcap-uc's doing | 12:48 |
| uvos__ | i would make some sense to put this safty critical feature (dont charge if host rejects) into fw | 12:48 |
| freemangordon | I doubt we cannot get USB port max current draw | 12:48 |
| uvos__ | sure but maybe the motorola driver dosent | 12:49 |
| uvos__ | (idk just speculateing) | 12:49 |
| uvos__ | if you cant find it | 12:49 |
| freemangordon | well, I don't know where it is supposed to be, to start with :) | 12:49 |
| freemangordon | tmlind: ping | 12:51 |
| freemangordon | hmm, I think configurations are done via gadgetfs | 13:01 |
| freemangordon | right now we ahve only one configuration with maxPower of 2mA, IIUC | 13:01 |
| freemangordon | uvos__: so, in order to do what android does, I think we shall set CONFIG_USB_GADGET_VBUS_DRAW=500 | 13:03 |
| freemangordon | that way your XT_whatever will reject the configuration | 13:04 |
| freemangordon | at least you can try it | 13:04 |
| freemangordon | but I am almost sure this will fix we breaking the specs | 13:05 |
| uvos__ | how would cpcap-charger (mainline) here know to not acctivate charging when the configuration is rejected | 13:05 |
| freemangordon | I think if configuration is rejected, there will be no USB interrupt | 13:06 |
| uvos__ | the device has to avoid taking current when rejected the host dosent turn off power or anything like that | 13:06 |
| uvos__ | freemangordon: ok | 13:06 |
| freemangordon | still, wild guess, but we can at least try | 13:07 |
| freemangordon | hmm, lemme check what is the max port current of the hubs I have around | 13:07 |
| uvos__ | aside from otg ports and some laptops | 13:07 |
| uvos__ | i think <500mA ports are pretty rare | 13:08 |
| uvos__ | you could use another mapphone as the host | 13:08 |
| uvos__ | its also dose 30mA max i think | 13:08 |
| uvos__ | or something like that | 13:08 |
| freemangordon | well, 4 ports non-powered hub should not report 500 mA/port, no? | 13:09 |
| uvos__ | it can | 13:09 |
| freemangordon | I know | 13:09 |
| uvos__ | if just one slave is connected | 13:09 |
| freemangordon | but it should not | 13:09 |
| uvos__ | ok | 13:09 |
| freemangordon | I am checking what my reports | 13:09 |
| freemangordon | MaxPower 100mA | 13:12 |
| freemangordon | :) | 13:12 |
| freemangordon | also, I am sure I hade some tool around that I was able to switch individual ports o/off | 13:13 |
| uvos__ | some fancy hubs can do that | 13:14 |
| uvos__ | yeah | 13:14 |
| freemangordon | ID 05e3:0608 Genesys Logic, Inc. Hub | 13:14 |
| uvos__ | no idea :P | 13:14 |
| freemangordon | a couple of years ago I was playing with it | 13:15 |
| freemangordon | just have to remember what I did back then | 13:15 |
| freemangordon | IIRC I was also able to control max power | 13:15 |
| freemangordon | uhubctrl ;) | 13:16 |
| freemangordon | uvos__: ok, so far I was able to find this: https://elixir.bootlin.com/linux/v5.18.19/source/drivers/usb/musb/musb_gadget.c#L1624 | 17:09 |
| freemangordon | printk() there shows that it is called, with correct mA | 17:09 |
| freemangordon | ant it turn it calls usb_phy_set_power() | 17:10 |
| freemangordon | *and | 17:10 |
| 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) | 17:12 |
| freemangordon | not sure I understand the question | 17:13 |
| freemangordon | printk is like printf, more or less | 17:13 |
| 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? | 17:13 |
| freemangordon | just dereference the structure | 17:13 |
| freemangordon | gadget->struct_member | 17:13 |
| freemangordon | for example: | 17:14 |
| freemangordon | printk("%s %s\n", __FUNCTION__, gadget->name); | 17:15 |
| sicelo | alright. thanks. i guess i was doing it correctly then ... but i suppose i must spend more time with the struct | 17:17 |
| sicelo | basically i wanted to see what *dev really contains in https://elixir.bootlin.com/linux/v5.18.19/source/drivers/base/platform.c#L435 | 17:17 |
| freemangordon | if you expect things like js "console.log(JSON.stringify(object))" | 17:17 |
| freemangordon | there is no such thing :) | 17:17 |
| freemangordon | you must print meber by member | 17:17 |
| freemangordon | *member | 17:17 |
| uvos__ | THIS IS C | 17:17 |
| freemangordon | mhm | 17:17 |
| uvos__ | :P | 17:17 |
| uvos__ | you could run a debugger on the kernel and have gdb print the struct | 17:18 |
| uvos__ | but not on d4 | 17:18 |
| 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 | 17:19 |
| uvos__ | dose the n900 debug kit have jtag? | 17:19 |
| uvos__ | btw | 17:19 |
| uvos__ | just curious | 17:20 |
| freemangordon | sicelo: something is missing in the DTS | 17:20 |
| 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 | 17:20 |
| sicelo | freemangordon: the mc interrupt is there in dts, and it's correct. | 17:20 |
| freemangordon | could it be that DTB is too big? | 17:21 |
| freemangordon | I remember there were some issues with attached DTBs | 17:21 |
| freemangordon | also, do you see that irq in /sys/firmware where it is expected? | 17:21 |
| sicelo | https://elixir.bootlin.com/linux/v5.18.19/source/arch/arm/boot/dts/omap3.dtsi#L903 | 17:24 |
| freemangordon | ok, but do you see the same on the device | 17:24 |
| freemangordon | in /sys/firmware/... | 17:24 |
| sicelo | sys firmware? mmm, i can check. | 17:25 |
| freemangordon | yes, you have DTB there visible on a booted system | 17:25 |
| freemangordon | also, if you decompile the DTB, doo you see that interrupt there? | 17:26 |
| sicelo | at least with decompiled dtb, it's there | 17:31 |
| sicelo | interrupts = <0x5c 0x5d>; | 17:31 |
| sicelo | interrupt-names = "mc\0dma"; | 17:31 |
| freemangordon | check on the device | 17:32 |
| freemangordon | could be broken attached DTB | 17:32 |
| buZz | sicelo: mc\0dma might be wrong? | 17:33 |
| buZz | shouldnt it be just 'mc' | 17:34 |
| freemangordon | uvos__: ugh, this is what is bugging us, for start https://elixir.bootlin.com/linux/v5.18.19/source/drivers/usb/musb/musb_gadget.c#L1628 | 17:34 |
| freemangordon | buZz: there are 2 interrupts, see dts | 17:34 |
| buZz | oh, right, but \0 as seperator? | 17:35 |
| freemangordon | yep, that | 17:35 |
| freemangordon | 's fine | 17:35 |
| buZz | i see stuff like ; interrupt-names = "rx", "tx"; | 17:36 |
| uvos__ | freemangordon: and who shal support that? omap phy? | 17:36 |
| buZz | on https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/resource-names.txt | 17:36 |
| freemangordon | uvos__: the point is that this function must not check for set_power() | 17:36 |
| freemangordon | see https://elixir.bootlin.com/linux/v5.18.19/source/include/linux/usb/phy.h#L288 | 17:37 |
| freemangordon | the check is there, but after usb_phy_set_charger_current() is called | 17:37 |
| freemangordon | usb_phy_set_charger_current() calls notifiers | 17:38 |
| freemangordon | (in theory) | 17:38 |
| freemangordon | I registered in cpcap_charger, but callback is not called, besides for VBUS | 17:38 |
| buZz | we cant set the constant charging voltage above 4.2v yet, can we? | 17:39 |
| freemangordon | yes, we can | 17:39 |
| buZz | i only succeeded in setting it below, not above | 17:39 |
| buZz | without kernel mods? | 17:39 |
| freemangordon | yes | 17:39 |
| freemangordon | but you have to set ti in /usb, not in /battery | 17:39 |
| freemangordon | some bug I guess | 17:39 |
| buZz | :O what am i doing wrong then, shouldnt it be > 1651429464 <uvos> echo 4300000 > constant_charge_voltage | 17:39 |
| buZz | well, if i set it above 4200000 it doesnt stick , but 4100000 works | 17:40 |
| * buZz tries again :P | 17:40 | |
| sicelo | " but you have to set ti in /usb, not in /battery" .. isn't it correct? /usb is the charger | 17:42 |
| buZz | freemangordon: see; http://space.nurdspace.nl/~buzz/maemo/2022-11-10-174316_960x540_scrot.png | 17:44 |
| buZz | its not taking | 17:44 |
| freemangordon | no idea then, maybe there is some hard limit to be fixed | 17:44 |
| buZz | yeah i guess, should i check my diff for my 'explosive droid4' kernel? :P | 17:45 |
| uvos__ | yes it being in usb makes perfect sense | 17:46 |
| uvos__ | that is the charger | 17:46 |
| uvos__ | it should work, it worked on my device before | 17:47 |
| uvos__ | its possible you also have to ajust something in battery | 17:47 |
| buZz | does it currently on the latest -devel ? | 17:47 |
| uvos__ | cant check rn | 17:47 |
| buZz | ah ok | 17:47 |
| uvos__ | i dont have a battery it would detect as 4.35 | 17:47 |
| buZz | AHA! | 17:49 |
| buZz | i need to do '4300000' > /sys/class/power_supply/battery/constant_charge_voltage -first- | 17:49 |
| uvos__ | right | 17:49 |
| uvos__ | thats expected | 17:49 |
| buZz | -then- '4300000' > /sys/class/power_supply/usb/constant_charge_voltage works :D | 17:49 |
| uvos__ | the charger and the battery have to agnolage | 17:50 |
| uvos__ | er acknowledge | 17:50 |
| uvos__ | atho maybe we should make that sync automaticly | 17:51 |
| buZz | hmmm, it doesnt take '4349000' as my battery reports, limits to 4330000 in /usb | 17:51 |
| buZz | but, i guess fine for now | 17:51 |
| uvos__ | not sure how the kernel interfaces expect this to happen | 17:51 |
| freemangordon | there is code to do that, but it seems to be broken | 17:51 |
| * buZz charges | 17:51 | |
| uvos__ | buZz: cpcap has limited register resolution | 17:52 |
| uvos__ | id have to check if its that | 17:52 |
| uvos__ | or if there is a < check where there should be <= | 17:52 |
| buZz | ah, possibly yeah | 17:52 |
| sicelo | freemangordon: in /sys/firmware, the interrupt numbers are not there. but interrupt names is there. | 17:54 |
| freemangordon | not good | 17:54 |
| freemangordon | how big is DTB? | 17:54 |
| freemangordon | you may try to enable thumb2 kernel, to see if reduced size is going to help | 17:55 |
| sicelo | it's thumb2 | 17:58 |
| freemangordon | hmm | 17:59 |
| freemangordon | well | 17:59 |
| freemangordon | move something out of the kernel, into a module | 17:59 |
| freemangordon | or, change the compression | 17:59 |
| freemangordon | can't think of anything better | 17:59 |
| uvos__ | if we are significantly space limited on n900 we might have to start building a special kernel for it again | 18:00 |
| sicelo | dtb is 78632 bytes | 18:00 |
| uvos__ | since rn theres lots of stuff built in we really only need on mapphones/omap4 | 18:00 |
| freemangordon | ugh | 18:00 |
| sicelo | i'm quite sure the dtb didn't change size | 18:00 |
| freemangordon | how big is kernel+dtb? | 18:00 |
| sicelo | 5517960 Nov 5 00:04 zImage | 18:01 |
| freemangordon | ugh | 18:01 |
| freemangordon | why so big? | 18:02 |
| freemangordon | move some stuff to modules | 18:02 |
| uvos__ | really why so big | 18:02 |
| uvos__ | current kernel on my d4 is 4982776 | 18:03 |
| uvos__ | why is it 500kb bigger | 18:03 |
| freemangordon | mhm | 18:03 |
| sicelo | majority of stuff is in modules actually | 18:05 |
| freemangordon | gnome crashed :( | 18:09 |
| freemangordon | uvos__: so, after the fix, I see usb_phy_set_charger_current() called, but usb_phy->chg_type is UNKNOWN_TYPE, as expected | 18:11 |
| freemangordon | TBH, I have no idea which exactly phy it is about, maybe I shall trace it | 18:12 |
| freemangordon | also, I am not sure where shall charger detection be implemented | 18:12 |
| freemangordon | it seems extcon driver is the correct option | 18:13 |
| freemangordon | but, I think we need tmlind here to help | 18:13 |
| sicelo | for completeness, here's the kernel config (extracted from /proc/config.gz) | 18:52 |
| sicelo | http://li.nux.co.za/6.1.0-rc3 | 18:58 |
| sicelo | freemangordon: uvos: https://paste.debian.net/1260284/ ... this makes it all work just fine | 22:44 |
| sicelo | of course it's a super ugly hack | 22:44 |
| 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 | 22:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
