Hi Tony,
I have copied this discussion to our pyra-kernel mailing list, because it may be interesting for others as well.
Am 12.02.2016 um 17:02 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160212 05:04]:
Am 11.02.2016 um 21:47 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160211 12:13]:
Am 11.02.2016 um 20:27 schrieb Tony Lindgren tony@atomide.com:
The main blocking point is a hardware problem which needs that I currently have to boot with SMP disabled, i.e. run only one core. If both cores are running or I have high load there is a risk that Linux gets stuck (or shows spurious segfaults and page faults). It is not software related (same kernel binary works on the EVM) but power supply stability. OMAP5 can draw much more energy than OMAP3...
Ouch OK yeah that sounds like power supply issue. Maybe check the values for components used on omap5-uevm as the schematics may not be up to date?
Well, it looks to be more on the part that makes 3.7V from the USB input. I.e. our charger chip and USB cable etc. Or it is missing just some big capacitor.
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.
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).
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.
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.
There is one current issue where 4.5-rc3 gets stuck for ~200 seconds during boot. Looks like some problem with modprobe but I don't know yet if it is mainline our our extension's fault. Or even the user space for testing.
Hmm there's the MMC PM runtime regression issue.
We have fixed it using your initial patch (I have not checked if there is a newer one now).
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?
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.
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...
BR, Nikolaus
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
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.
Am 15.02.2016 um 20:28 schrieb H. Nikolaus Schaller hns@goldelico.com:
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.
Here a log if someone can help to decipher.
[ 5.586922] driver_register 'pwm-backlight' [ 5.591702] backlight supply power not found, using dummy regulator [ 5.599205] ------------[ cut here ]------------ [ 5.604038] WARNING: CPU: 0 PID: 962 at drivers/bus/omap_l3_noc.c:147 l3_handle_target+0x1b0/0x204() [ 5.613602] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle): Data Access in Supervisor mode during Functional access [ 5.625885] Modules linked in: pwm_bl(+) pwm_omap_dmtimer ehci_omap(+) dwc3_omap wlcore_sdio leds_is31fl319x tsc2007 leds_tca6507 bq2429x_charger(+) ina2xx as5013 tca8418_keypad twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc palmas_pwrbutton usb3503 bmp280(+) bma150(+) bmg160_i2c bmg160_core input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine [ 5.661207] CPU: 0 PID: 962 Comm: udevd Tainted: G W 4.5.0-rc4-letux+ #1987 [ 5.669671] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.675961] [<c0014518>] (unwind_backtrace) from [<c0012700>] (show_stack+0x10/0x14) [ 5.684065] [<c0012700>] (show_stack) from [<c003776c>] (warn_slowpath_common+0x84/0xac) [ 5.692530] [<c003776c>] (warn_slowpath_common) from [<c0037814>] (warn_slowpath_fmt+0x2c/0x3c) [ 5.701638] [<c0037814>] (warn_slowpath_fmt) from [<c02ccb5c>] (l3_handle_target+0x1b0/0x204) [ 5.710560] [<c02ccb5c>] (l3_handle_target) from [<c02ccc38>] (l3_interrupt_handler+0x88/0x150) [ 5.719669] [<c02ccc38>] (l3_interrupt_handler) from [<c0075c8c>] (handle_irq_event_percpu+0x80/0x1f0) [ 5.729408] [<c0075c8c>] (handle_irq_event_percpu) from [<c0075e34>] (handle_irq_event+0x38/0x5c) [ 5.738694] [<c0075e34>] (handle_irq_event) from [<c0078824>] (handle_fasteoi_irq+0xa0/0x11c) [ 5.747618] [<c0078824>] (handle_fasteoi_irq) from [<c0075660>] (generic_handle_irq+0x18/0x28) [ 5.756632] [<c0075660>] (generic_handle_irq) from [<c0075780>] (__handle_domain_irq+0x7c/0xa4) [ 5.765732] [<c0075780>] (__handle_domain_irq) from [<c00094ac>] (gic_handle_irq+0x50/0x84) [ 5.774478] [<c00094ac>] (gic_handle_irq) from [<c057a838>] (__irq_svc+0x58/0x78) [ 5.782307] Exception stack(0xed06fc78 to 0xed06fcc0) [ 5.787594] fc60: 00000001 ee7c88f8 [ 5.796151] fc80: 00000000 ee7c83c0 60000113 ee232ca0 60000113 00000014 00000002 00000000 [ 5.804713] fca0: eeff6e7c 0005a830 0dc16000 ed06fcc8 c006cfa8 c057a2f0 20000113 ffffffff [ 5.813271] [<c057a838>] (__irq_svc) from [<c057a2f0>] (_raw_spin_unlock_irqrestore+0x40/0x44) [ 5.822279] [<c057a2f0>] (_raw_spin_unlock_irqrestore) from [<c033bbe0>] (__pm_runtime_idle+0x68/0x70) [ 5.832017] [<c033bbe0>] (__pm_runtime_idle) from [<c0034390>] (omap_dm_timer_set_pwm+0x7c/0x90) [ 5.841224] [<c0034390>] (omap_dm_timer_set_pwm) from [<bf0b71b8>] (pwm_omap_dmtimer_set_polarity+0x40/0x50 [pwm_omap_dmtimer]) [ 5.853259] [<bf0b71b8>] (pwm_omap_dmtimer_set_polarity [pwm_omap_dmtimer]) from [<c02dcbec>] (pwm_set_polarity+0x68/0x88) [ 5.864807] [<c02dcbec>] (pwm_set_polarity) from [<c02dd634>] (of_pwm_xlate_with_flags+0x54/0x64) [ 5.874101] [<c02dd634>] (of_pwm_xlate_with_flags) from [<c02dce0c>] (of_pwm_get+0xe8/0x154) [ 5.882933] [<c02dce0c>] (of_pwm_get) from [<c02dd554>] (devm_pwm_get+0x38/0x70) [ 5.890678] [<c02dd554>] (devm_pwm_get) from [<bf0bf354>] (pwm_backlight_probe+0x1fc/0x3e8 [pwm_bl]) [ 5.900241] [<bf0bf354>] (pwm_backlight_probe [pwm_bl]) from [<c03344b0>] (platform_drv_probe+0x50/0x98) [ 5.910161] [<c03344b0>] (platform_drv_probe) from [<c0332b7c>] (really_probe+0xf8/0x250) [ 5.918717] [<c0332b7c>] (really_probe) from [<c0332e78>] (driver_probe_device+0x44/0x70) [ 5.927274] [<c0332e78>] (driver_probe_device) from [<c0332f0c>] (__driver_attach+0x68/0x8c) [ 5.936106] [<c0332f0c>] (__driver_attach) from [<c0331604>] (bus_for_each_dev+0x50/0x84) [ 5.944668] [<c0331604>] (bus_for_each_dev) from [<c03323d4>] (bus_add_driver+0xcc/0x1e4) [ 5.953227] [<c03323d4>] (bus_add_driver) from [<c03338a4>] (driver_register+0xac/0xf4) [ 5.961598] [<c03338a4>] (driver_register) from [<c0009728>] (do_one_initcall+0x100/0x1bc) [ 5.970249] [<c0009728>] (do_one_initcall) from [<c009880c>] (do_init_module+0x58/0x1b4) [ 5.978720] [<c009880c>] (do_init_module) from [<c00994d0>] (SyS_finit_module+0x60/0x68) [ 5.987185] [<c00994d0>] (SyS_finit_module) from [<c000eea0>] (ret_fast_syscall+0x0/0x1c) [ 5.995740] ---[ end trace cb88537fdc8fa202 ]--- [ 6.001669] ------------[ cut here ]------------
On 02/15/2016 11:38 PM, H. Nikolaus Schaller wrote:
<snip> Here a log if someone can help to decipher.
[ 5.586922] driver_register 'pwm-backlight' [ 5.591702] backlight supply power not found, using dummy regulator [ 5.599205] ------------[ cut here ]------------ [ 5.604038] WARNING: CPU: 0 PID: 962 at drivers/bus/omap_l3_noc.c:147 l3_handle_target+0x1b0/0x204() [ 5.613602] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle): Data Access in Supervisor mode during Functional access
This looks like OMAP5 is being unhappy about dmtimer clock disable, supposedly some L3 interconnect access still in progress?
Maybe something like this would help (untested in any way):
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7a327bd..af38614 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -670,6 +670,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, l |= OMAP_TIMER_CTRL_PT; l |= trigger << 10; omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
/* Save the context */ timer->context.tclr = l;
... or maybe adding some udelay() there instead. It that doesn't help, perhaps dmtimer clock can't be disabled while pwm is in use? I'm talking about omap_dm_timer_disable() in omap_dm_timer_set_pwm().
Grazvydas
Hi Notaz,
Am 15.02.2016 um 23:40 schrieb Grazvydas Ignotas grazvydas.ignotas@openpandora.org:
On 02/15/2016 11:38 PM, H. Nikolaus Schaller wrote:
<snip> Here a log if someone can help to decipher.
[ 5.586922] driver_register 'pwm-backlight' [ 5.591702] backlight supply power not found, using dummy regulator [ 5.599205] ------------[ cut here ]------------ [ 5.604038] WARNING: CPU: 0 PID: 962 at drivers/bus/omap_l3_noc.c:147 l3_handle_target+0x1b0/0x204() [ 5.613602] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle): Data Access in Supervisor mode during Functional access
This looks like OMAP5 is being unhappy about dmtimer clock disable, supposedly some L3 interconnect access still in progress?
Maybe something like this would help (untested in any way):
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7a327bd..af38614 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -670,6 +670,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, l |= OMAP_TIMER_CTRL_PT; l |= trigger << 10; omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
__omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
brilliant!
That made this error go away and reappear somewhere else. After applying the same fix to several other locations where timer registers are written I could make them all go away.
But IMHO there is a deeper issue. The third parameter of __omap_dm_timer_read() is called "posted" and setting it to 1 makes the driver wait for some activity to finish.
There is also a comment in omap_dm_timer_read_reg() which says:
"The posted mode bit is encoded in reg."
But the code does not "decode" it depending on the register number. Rather there is a timer->posted flag which is set or reset globally depending on how the driver is initialized or if __omap_dm_timer_enable_posted() is called.
This appears to be hooked up from the wrong end. Either the SoC (L3 interconnect) needs this posting mechanism or it does not. How can the code using the driver know better than the driver itself.
And maybe on OMAP5 we need it. While on OMAP3 we don't (because the A8 is slower but L3 might have similar speed). So it does not depend on what the user of the dmtimer wants to have.
BTW: there was also some "cleanup" proposed a while ago, but did not find it into mainline:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/117682....
which also shows the "wrong" approach. Why should it be possible to "configure" the whole timer to posted mode. IMHO it is sort of transaction processing, i.e. grouping register writes and then committing them. So it depends on the sequence of write commands.
Well, for the moment we have a fix to silence these kernel messages which is sufficient for my hardware validation, i.e. we can leave this open for future improvements as soon as we have stable OMAP5 dual core operation.
/* Save the context */ timer->context.tclr = l;
... or maybe adding some udelay() there instead. It that doesn't help, perhaps dmtimer clock can't be disabled while pwm is in use? I'm talking about omap_dm_timer_disable() in omap_dm_timer_set_pwm().
Grazvydas
BR and thanks for the help, Nikolaus
PS: Now I have a login: after ca. 20 seconds and X11+LCD after ~30 seconds.
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7a327bd..bdc549d 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -476,6 +476,7 @@ int omap_dm_timer_start(struct omap_dm_timer *timer) if (!(l & OMAP_TIMER_CTRL_ST)) { l |= OMAP_TIMER_CTRL_ST; omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1); }
/* Save the context */ @@ -589,6 +590,8 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload, omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1); + /* Save the context */ timer->context.tclr = l; timer->context.tldr = load; @@ -605,7 +608,7 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
if (unlikely(!timer)) return -EINVAL; - +printk("dmtimer posted=%d\n", timer->posted); omap_dm_timer_enable(timer);
l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG); @@ -643,6 +646,7 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable, l &= ~OMAP_TIMER_CTRL_CE; omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG, match); omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
/* Save the context */ timer->context.tclr = l; @@ -670,6 +674,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, l |= OMAP_TIMER_CTRL_PT; l |= trigger << 10; omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
/* Save the context */ timer->context.tclr = l; @@ -794,6 +799,7 @@ int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value) }
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, value); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
/* Save the context */ timer->context.tcrr = value;
* H. Nikolaus Schaller hns@goldelico.com [160216 02:48]:
Am 15.02.2016 um 23:40 schrieb Grazvydas Ignotas grazvydas.ignotas@openpandora.org:
Maybe something like this would help (untested in any way):
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7a327bd..af38614 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -670,6 +670,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, l |= OMAP_TIMER_CTRL_PT; l |= trigger << 10; omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
__omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, 1);
brilliant!
That made this error go away and reappear somewhere else. After applying the same fix to several other locations where timer registers are written I could make them all go away.
Hmm, I don't think I've seen this one either.
But IMHO there is a deeper issue. The third parameter of __omap_dm_timer_read() is called "posted" and setting it to 1 makes the driver wait for some activity to finish.
There is also a comment in omap_dm_timer_read_reg() which says:
"The posted mode bit is encoded in reg."
But the code does not "decode" it depending on the register number. Rather there is a timer->posted flag which is set or reset globally depending on how the driver is initialized or if __omap_dm_timer_enable_posted() is called.
This appears to be hooked up from the wrong end. Either the SoC (L3 interconnect) needs this posting mechanism or it does not. How can the code using the driver know better than the driver itself.
Sounds like we have a bug somewhere though. Are using the new drivers/pwm/pwm-omap-dmtimer.c?
And maybe on OMAP5 we need it. While on OMAP3 we don't (because the A8 is slower but L3 might have similar speed). So it does not depend on what the user of the dmtimer wants to have.
BTW: there was also some "cleanup" proposed a while ago, but did not find it into mainline:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/117682....
Jon was planning to improve that patch further to optimize the code for clocksource as noted later on in the thread here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/119241....
which also shows the "wrong" approach. Why should it be possible to "configure" the whole timer to posted mode. IMHO it is sort of transaction processing, i.e. grouping register writes and then committing them. So it depends on the sequence of write commands.
That was needed earlier to optimize the code for system timers as the clockevent write without posted mode can take a while, and for clocksource read we want to optimize it out.
Regards,
Tony
New result on the mmc4/SD-Slot issue.
Am 15.02.2016 um 22:38 schrieb H. Nikolaus Schaller hns@goldelico.com:
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.
With that addition to our DT, mmc4 is being polled. But I still get the -110 errors. I can see by scope that clock and CMD are enabled. So it is something else. Maybe pinmux.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160215 11:30]:
Am 15.02.2016 um 19:20 schrieb Tony Lindgren tony@atomide.com: 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.
OK, only some bq24* chips have I2C control.
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...
Sorry I guess I don't follow without seeing what you patched here..
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.
That sounds broken if that's the case :)
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.
Heh OK :)
Regards,
Tony