[fedora-arm] BZ regarding 3.6.x kernel boot from MMC issue

[David A. Marlin]

Peter Robinson wrote:
> On Wed, Sep 26, 2012 at 10:32 PM, David Marlin <dmarlin at redhat.com> wrote:
>   
>> As discussed in our meeting today, I have submitted a BZ for the kernel boot
>> from MMC issue:
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=860855
>>
>> A patch that includes the config changes we tested is attached to the BZ.
>> They are based on the last known-good (booting) kernel for OMAP and Tegra.
>>
>> If these are acceptable, will someone with commit privileges please apply
>> the changes and push it out.  If you prefer to submit a scratch build of the
>> changes first (which I recommend), Paul Whalen and I will be happy to test
>> the resulting images to confirm they work as expected.
>>
>> Please reply with any questions or comments.
>>     
>
> I have some issues with it. For example why do you enable these:
>   
I did not do a complete analysis of all options.  I simply compared 
(diff) with the MMC settings from last known-good config and reverted 
the changes, plus I added the DMA changes from the email list.

>
> +CONFIG_MMC_SPI=m
> +CONFIG_MMC_USHC=m
>   
Although I don't have the link, at least one message board was 
discussing this, and MMC_SPI was recommended to be included, but I did 
not specifically test that is was required.  MMC_USHC was just an option 
from the previous (working) config.

> when they're not used by OMAP, similarly the following aren't even
> part of a tegra platform
>
> +CONFIG_MMC_SDHCI_PXAV3=m
> +CONFIG_MMC_SDHCI_PXAV2=m
>   
Ok, I questioned these too, but they were in the previous (working) 
config, and since it takes many hours to build the kernels, I just put 
them in to see if it would boot.  I have no objection to removing them 
(and others) if not required.

> What's more dgilmore and I were discussing the following change:
>
> +CONFIG_DMADEVICES=y
> +CONFIG_DMA_OMAP=m
>
> Which resulted in a booting system as can be seen here:
>
> http://fpaste.org/BJLj/
>   
Did that actually boot to a login prompt.  The last thing I see in the 
paste is:

-----------------

[   11.973571] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
[   11.980590] dmaengine: __dma_request_channel: fail ((null))
[   11.987426] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
[   11.995666] omap_hsmmc omap_hsmmc.4: Failed to get debounce clk
[   12.002319] dmaengine: __dma_request_channel: fail ((null))
[   12.008209] omap_hsmmc omap_hsmmc.4: unable to obtain RX DMA engine channel 60

-----------------

which appear to be DMA errors.

We also found that verbose debugging on DMA was far too noisy to be 
useful on the serial console (constant stream of messages), which is why 
we included:

# CONFIG_DMADEVICES_VDEBUG is not set

There was one remaining message that streamed to the console, so I added 
the attached patch to make the debug message a 'verbose debug' message.  
I think this patch might be appropriate to push upstream (as that 
message, at least on OMAP, is quite verbose).

> I'm building a scratch kernel now for OMAP to see if it works (it also
> has some other OMAP changes) and once has been tested we can move onto
> the likely similar fix for tegra.
>
> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1156419
>   

Ok, please let us know how it goes, and when we can test on both Panda 
and Trim Slice.


d.marlin
=========
> Peter
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-omap-dma-verbose-dbg.patch
Type: text/x-patch
Size: 497 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/arm/attachments/20120927/48cd9aef/attachment.bin>