Hi,
* H. Nikolaus Schaller hns@goldelico.com [160214 10:33]:
Hi Tony,
I have copied this discussion to our pyra-kernel mailing list, because it may be interesting for others as well.
OK yup.
Am 12.02.2016 um 17:02 schrieb Tony Lindgren tony@atomide.com:
Hmm is is a bq24* part by any chance?
Yes, a bq24297.
If so, check if it has "OTG" pin, that should be GPIO controlled and needs to be set high after USB has been enumerated with a host to enable higher charge rates. It's a bit unclear for the OTG pin.. I think the "OTG" pin was originally supposed to be automatically toggled by something on those chips but it seems that in reality it needs to be toggled with a GPIO..
Not necessarily. It can be pulled up to REGN and is used only if the USB charger detection does not detect anything. Then it can decide between 100mA and 500mA.
Hmm yeah I guess that's OK as the bootrom has enumerated on the USB at that point.
500mA is enough for BootROM and MLO and to start U-Boot.
We have a patch in our U-Boot to enable higher current from USB (only if no battery is detected) by writing through I2C to the control register. This works.
This all was required that we could boot at all (without battery, which is important for a lab situation).
OK
The problematic high load scenario seems somehow to be influenced by our tps2505 DC/DC converter for the USB host ports but it is not yet a clear picture.
OK
Finally, I have now fixed the "long-boot-delay issue" I had mentioned. It is a modprobe problem. Trying to reload our bq2429x driver made modprobe/insmod hang (again) - although the module is already loaded and reported by lsmod...
I have now removed all EXPORT_SYMBOL and replaced the subsys_initcall() with module_i2c_driver(). And disabled the irq registration. With these changes, the modprobe hang seems to have disappeared. Well, this driver (I have found the code from some Android platform) is really a hack and far from being upstreamable. But that is not an OMAP5 related issue.
Hmm that does not sounds right to me.. Probably a sign of something being wrong somewhere.
OK, Ulf has now applied the MMC fix to set pm_runtime_dont_use_autoidle() to his fixes tree.
Great!
Do you know to which tree?
That's now in Linux next, commit 5bed76445c22 ("mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit"), hopefully will hit the mainline tree within next few days.
For your charger issue, see also thread "tvp5150 regression after commit 9f924169c035". Maybe reverting commit 9f924169c035 ("i2c: always enable RuntimePM for the adapter device") also helps with the charger issue?
One thing where I already had planned to contact you is that I have tried to enable mmc4 for a second SD slot. It is working in U-Boot after adding the controller's base addresses, configuring the board file and enabling the functional clock by writing CM_L4PER_MMC4_CLKCTRL = 0x4A009128.
Oh never heard of that one either.
That are the functional clock registers which enable the hsmmc port inside the OMAP5.
In our U-Boot I have added:
writel(0x02, 0x4A009120); /* enable MMC3 module */
writel(0x02, 0x4A009128); /* enable MMC4 module */
to our board_mmc_init.
I have found these register addresses deeply inside the ti,hwmod = "mmc4" processing.
So the ti,hwmods = "mmc4" entry in omap5.dtsi
mmc4: mmc@480d1000 { compatible = "ti,omap4-hsmmc"; reg = <0x480d1000 0x400>; interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; ti,hwmods = "mmc4"; ti,needs-special-reset; dmas = <&sdma 57>, <&sdma 58>; dma-names = "tx", "rx"; };
should suffice.
But when using devmem2 it tells me that the clock of the hsmmc of mmc4 is disabled while for mmc3 (wlan) it is enabled.
I do have the following untested patch I did while debugging why WLAN did not work on omap5-uevm. I did not end up needing it, but maybe that's because those are configured by u-boot?
Well, our patched U-Boot enables mmc4 and we can read the SD card. But in Linux the clock it becomes disabled although we have
&mmc4 { /* enable second (ยต)SD slot (SDIO capable) */ status = "okay"; };
The interface is then visible and probed but the card returns error -110.
Some reset occurring in between? Some bug in hwmod which disables the clock instead of enabling it?
mmc1,2,3 appear to work fine with mainline DT and w/o your patch.
Ah, I think mmc3 clock is not enabled by default in U-Boot. Only mmc1 and mmc2 are (since they are the default mmc devices known to mmc list).
Yeah it sounds like we're missing the clock handling in kernel.
Ok, I have finally found out how the hwmod code works.
Then, I have added some simple printk() to omap_hwmod_enable/idle/disable in arch/arm/mach-omap2/omap_hwmod.c to see what is going on.
The result is that the "mmc4" hwmod is enabled and then idled. But will not awake again. There is also no polling for the MMC4 insertion (I still have to configure the CD/WP gpios).
With no SD card during boot:
[ 2.756867] omap_hwmod_enable(mmc4) [ 2.761376] omap_hwmod_idle(mmc4)
with SD card (log is mixed with mmc3 = wlan detection):
[ 3.506649] omap_hwmod_enable(mmc4) [ 3.515866] omap_hsmmc 480ad000.mmc: card claims to support voltages below defined range [ 3.538856] mmc2: new high speed SDIO card at address 0001 [ 3.546051] omap_hwmod_idle(mmc1) [ 3.646093] omap_hwmod_idle(mmc3) [ 3.802625] mmc3: error -110 whilst initialising SD card [ 3.906228] omap_hwmod_idle(mmc4)
(here mmc's are counted 0...4). So this means the hwmod looks ok. And some other component thinks that the hsmmc can idle forever.
For mmc1 I get a lot of enable/idle notifications. And if I ifconfig wlan0 up, the same for mmc3. Only mmc4 remains silent.
Under Linux the fclk is not (or no longer) enabled (if I look into 0x4A009128 through devmem2), although I think the ti,hwmod = "mmc4" should do that and everything is there (incl. &mmc4 { status = "okay"; };.
The value in CM_L4PER_MMC3_CLKCTRL looks fine and we have a WL1837MOD running with WLAN and Bluetooth.
How can I easily debug this? Where in the hwmod framework should CM_L4PER_MMC4_CLKCTRL be written?
Well maybe the attached patch helps then.. The whole patch needs to be checked for sure though.
It is a good question, why you need to set them at all. IMHO they should be enabled if the interface is activated. But I may be wrong how it is implemented.
And AFAIK the 32kHz is only needed for the WLAN/BT module but not for the hsmmc controller.
After a little more research I found that they are indeed translated into the register addresses I am looking for. Only "32kHz" is misleading because they are the functional clocks (~200 MHz) and not the 32kHz clock required for the Palmas, RTC, twl6040, wlan module etc.
OK I think there may be some typos in the TRM then, or I misunderstood something. Anyways as I did not need that patch I stopped work on it as I realized I did not know how to test it. Good to hear that it might have some usable pieces though :)
And only mmc1, i.e. CM_L3INIT_MMC1_CLKCTRL, has an "optional" OPTFCLKEN_32KHZ_CLK field. So there is no bit pattern for the other mmc clocks and your patch should have no effect.
Oh OK.
So it appears to do what ti,hwmod = "mmc4" should also do if I understand correctly... This is why I am wondering where the hwmod registers are really written. I would try to add a printk to see if they are. Or are not.
Sounds like you need to debug that one further..
OK. FYI, Tero is working on a patch that allows moving the clkctrl register bit handling to the clock framework. He is also working on making a reset driver. After that we can do further work on the hwmod code :)
I hope the reset driver will be compatible to what is needed for the PVR/SGX drivers...
The clkctrl related changes are in the "[RFC 0/9] ARM: OMAP4: hwmod clkctrl conversion to DT + clock driver" thread. It will probably be a while before we have the clkctrl clock driver and reset drivers working. I doubt they will help with the MMC issue at this point.
Regards,
Tony