HI,
Am 15.02.2016 um 19:20 schrieb Tony Lindgren tony@atomide.com:
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.
Indeed. It seems to be the irq registration which was inherited and not properly translated to DT #interrupt. I have simply commented out the interrupt initialization, because the driver does not even do something with the interrupt. And now it works.
So my key learning is that interrupt init in probe functions is very critical. If done wrongly it may have strange side-effects. Like modules that modprobe tries to load twice or "poweroff" not working.
Well, it is still a big hack:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
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.
Ok.
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?
I have not the impression that I2C plays a role.
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.
This is the key problem I have at the moment.
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..
I have done (see above) and enable/idle is working well. It is just not used by some higher level...
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.
yes as it appears to be on a higher level.
Maybe I just misread
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mmc/m...
that I have to explicitly specify
&mmc4 { broken-cd; } and omitting the cd-gpio is not sufficient to enable the polling mechanism...
Will try that asap.
Another, new topic is the twl6040 which I have done experiments today. The chip is now found and responding and basically initialized because it is listed by aplay -l.
But twl6040-vibra.c seems to have at least 3 significant bugs. One even a NULL pointer dereference which I could trace back to a patch from 3.8 to 3.9... I have fixes but the motor still does not move. Well, Rome wasn't built in a day.
And when trying to aplay or run a rumble effect, I get interrupt and lock problem warnings from the kernel.
That could also be a hardware effect of our board since we have almost exactly copied the connection scheme of the twl6040 from the evm. But there may be a hidden mistake since we are just starting the hardware validation of this area.
BR, Nikolaus
Just for the records: there are also spurious kernel messages for the dmtimer based pwm which I have not seen on OMAP3 boards. We use it in both systems for backlight PWM.