<tmlind>
Wizzup: so the MASTER_USBHOSTHS corresponds to ohci/echi, so usbhshost in omap4-l4.dtsi, seems that on low battery mdm6600 shuts down, and the usb phy is on the mdm6600 causing invalid access to the phy, or at least that's my guess
<tmlind>
seems like usbhs_omap_remove() or similar should get called to remove the related phys at that point
<tmlind>
freemangordon: to me it seems that usb gadget framework should add/remove a vbus regulator as needed telling the max current, then chargers could try to get it and check the max current after connecting.. somehow the regulator should be drivers/phy instance specific though.. just trying to think of ideas how it could be done
joerg has quit [Killed (erbium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
n900 has quit [*.net *.split]
r3boot has quit [*.net *.split]
r3boot has joined #maemo-leste
n900 has joined #maemo-leste
Daaanct12 has joined #maemo-leste
sicelo has quit [*.net *.split]
MartijnBraam[m] has quit [*.net *.split]
mighty17[m] has quit [*.net *.split]
sicelo has joined #maemo-leste
sicelo has quit [Changing host]
sicelo has joined #maemo-leste
mighty17[m] has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 260 seconds]
mardy has joined #maemo-leste
<freemangordon>
tmlind: and what about just adding second notifier that is dedicated to chargers?
<freemangordon>
hmm, wait. don;t we already have a regulator for vbus?
<freemangordon>
so, what about gadget asking phy for the regulator and setting the max current on it>
<freemangordon>
?
<freemangordon>
phy can do as well, if needed
<freemangordon>
and ti is needed, in host mode
<freemangordon>
so, phy core can register some "usb-charger" regulator and this can be used by chargers to limit the current and gadgets or phy itself to set the current limit
<freemangordon>
do you like that?
<freemangordon>
I just wonder if it should be only one, global, regulator or per phy
<freemangordon>
ah, you said it should not e global
<freemangordon>
well, phy_create() can create a dummy regulator based on device name or some other string (phy label?)
xmn has quit [Ping timeout: 252 seconds]
norayr has left #maemo-leste [Disconnected: timeout during receiving]
xmn has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
Twig has joined #maemo-leste
<tmlind>
yeah that vbus regulator could be common to the phy framework maybe, then gadget would somehow set max value, then charger could query it..
<tmlind>
or how about add phy_set_charge_current() and phy_get_charge_current() ?
<freemangordon>
we already have that
<tmlind>
oh we do?
<freemangordon>
usb_phy_get_charger_current
<freemangordon>
and usb_phy_set_charger_current(
<freemangordon>
I was about to add regulator in usb_phy struct
<tmlind>
ok but that's specific to the old drivers/usb/phy and won't work with drivers/phy?
<freemangordon>
is it?
<tmlind>
i think so, it's a different old framework for drivers/usb/phy
<freemangordon>
cpcap phy calls usb_add_phy_dev()
<freemangordon>
is this obsolete too?
<tmlind>
oh not sure
<tmlind>
it might be legacy needed for musb still
<freemangordon>
what I see is that usb_phy is used all over the place
<freemangordon>
ok, but this is the internal supply, no?
* freemangordon
reads the docs
<tmlind>
compatible = "usb-b-connector"
<freemangordon>
hmm
<tmlind>
not sure what is handling it, but cpcap-charger could query it
<freemangordon>
I dont think anyone uses that, lemme grep
Pali has joined #maemo-leste
<tmlind>
cpcap-charger must not try to claim it on init though.. loading the phy should be optional, otherwise assume 500mA max current if regulator not available
<freemangordon>
sure
<freemangordon>
the same as in wm831x driver
<tmlind>
ok
<freemangordon>
so, if devm_usb_get_phy_by_phandle() fails, we just assume 500mA
<tmlind>
looks like we may just need to add the usb-b-connector node as a child of the usb or the phy
<Wizzup>
tmlind: I see, it clearly was proceeded by an empty battery warning, but it looks like what triggered it was the modem dropping off?
<freemangordon>
who is going to set that?
<Wizzup>
oh, you wrote that too.
<freemangordon>
tmlind: hmm, this is usb-conn-gpio.c
<freemangordon>
so this vbus-supply is specific to this driver, no?
<sicelo>
freemangordon: regarding my kernel size issue ... i build a kernel with plain omap2plus_defconfig. kernel size was exactly 5MB (i.e. 500kB less than before). the irq problem still happens. tbh, i doubt it's related to kernel size. plus, the only one with missing irq is musb. other drivers don't have the issue
<freemangordon>
hmm
<freemangordon>
I still think it is DTB related, but yeah, maybe it is not the size that bugs it
<Pali>
You can enable CONFIG_DEBUG_LL and kernel starts printing debug info prior reading attached dtb to serial console
<Pali>
serial console is available also in u-boot
<Pali>
IIRC it prints attached dtb address and size
<Pali>
so you can verify if the issue is in kernel code
<freemangordon>
sicelo: ^^^
<freemangordon>
that should help
<freemangordon>
Pali: is ther some size limit on DTB?
<sicelo>
the CONFIG_DEBUG_LL should be enabled in u-boot? or kernel?
<freemangordon>
u-boot
<Pali>
In past there was a DTB limit. And n900 dtb file triggered that limit, so it was increased
<Pali>
in kernel
<freemangordon>
maybe it triggered it again?
<Pali>
it is part of zImage wrapper
<freemangordon>
do you remember file was that limit in?
<Pali>
it was in zImage wrapper, so some in arch/arm/boot/
<freemangordon>
ok, thanks
<Pali>
Also enable CONFIG_DEBUG_OMAP3UART3
<sicelo>
unfortunately i don't have access to good/reliable serial. but let me first try with u-boot that has serial enabled, although i recall this just loses connectivity as soon as kernel starts
<Pali>
right, this would not work. kernel prints only to UART, not to usb
<Pali>
but you can test it in qemu
<Pali>
qemu has working UART nad kernel CONFIG_DEBUG_LL can print to it
<sicelo>
standard `qemu-system-arm`, or a special/n900 one?
<sicelo>
Pali: u-boot should be able to load separate zImage and separate DTB without any issue <--- how would one know which memory address to use for the dtb blob?
<Pali>
you can use any unused address
<Pali>
for example ${initrdaddr} if you are not going to use initrd