Peter Robinson wrote:
On Wed, Sep 26, 2012 at 10:32 PM, David Marlin <dmarlin@xxxxxxxxxx> 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
--- linux-3.6.0-0.rc4.git2.1.fc17.armv7hl/drivers/dma/virt-dma.c.arm 2012-09-11 14:27:20.124130826 -0500
+++ linux-3.6.0-0.rc4.git2.1.fc17.armv7hl/drivers/dma/virt-dma.c 2012-09-18 09:23:27.762953790 -0500
@@ -32,7 +32,7 @@
list_add_tail(&vd->node, &vc->desc_submitted);
spin_unlock_irqrestore(&vc->lock, flags);
- dev_dbg(vc->chan.device->dev, "vchan %p: txd %p[%x]: submitted\n",
+ dev_vdbg(vc->chan.device->dev, "vchan %p: txd %p[%x]: submitted\n",
vc, vd, cookie);
return cookie;
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
