On Tue, Jun 25, 2013 at 5:40 AM, Felipe Balbi <[email protected]> wrote: > On Mon, Jun 24, 2013 at 11:49:44PM -0700, Tony Lindgren wrote: >> * Joel A Fernandes <[email protected]> [130624 15:33]: >> > Hi Tony, >> > >> > Following branch breaks MMC for me on am33xx (beaglebone): >> > http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.11/cleanup >> > >> > I tried to work around it by specifying interrupt and reg property in DT: >> > mmc1: mmc@48060000 { >> > compatible = "ti,omap3-hsmmc"; >> > ti,hwmods = "mmc1"; >> > ti,dual-volt; >> > ti,needs-special-reset; >> > dmas = <&edma 24 >> > &edma 25>; >> > dma-names = "tx", "rx"; >> > interrupts = <64>; >> > interrupt-parent = <&intc>; >> > reg = <0x48060000 0x1000>; >> > status = "disabled"; >> > }; >> > >> > The probe succeeds but I still get a "Waiting for root device >> > /dev/mmcblk0p2" when booting over MMC. >> > >> > If you're planning to push the cleanup branch, can we temporarily add >> > the hwmod data back while we work on this issue so that upstream MMC >> > is kept working. >> >> Yes the cleanup branch is queued up. Can you please send a patch >> reverting the MMC parts of the hwmod change for am33xx for now, >> then try to find the real cause for the breakage? > > I had mentioned that Joel should *not* depend on hwmod data and if > adding interrupts to DTS caused issues, that issue should be resolved. > > http://marc.info/?l=linux-omap&m=137124891908957&w=2
Ofcourse, that is what we are talking about too. hwmod data is being added only as a temporary fix to keep upstream working while we work on a resolution. Maybe you missed the "add the hwmod data back while we work on this issue so that upstream MMC is kept working." in my post? Please read, http://www.mail-archive.com/[email protected]/msg91130.html Thanks, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
