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(a)atomide.com>:
> * H. Nikolaus Schaller <hns(a)goldelico.com> [160212 05:04]:
>> Am 11.02.2016 um 21:47 schrieb Tony Lindgren <tony(a)atomide.com>:
>>> * H. Nikolaus Schaller <hns(a)goldelico.com> [160211 12:13]:
>>>> Am 11.02.2016 um 20:27 schrieb Tony Lindgren <tony(a)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