On Thu, Jan 19, 2017 at 3:40 PM, Andrea Merello <andrea.merello@xxxxxxxxx> wrote: > On Thu, Jan 19, 2017 at 6:11 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxx> wrote: >> On Thu, Jan 19, 2017 at 05:58:10PM +0100, Ulf Hansson wrote: >>> + Russell >>> >>> On 16 January 2017 at 08:37, Andrea Merello <andrea.merello@xxxxxxxxx> wrote: >>> > The STM32F4xx family contain a SDIO IP that looks like a variant of >>> > the PL180, however, inspite it's actually attached to a APB bus, it >>> > cannot be handled by the AMBA bus code, because it lacks of the ID >>> > registers that AMBA primecell IPs have. >>> > >>> > This patch prepares for supporting the STM32 variant by letting the >>> > driver register also as a platform driver, that can be matched from >>> > the OF with specific "compatible" strings >>> >>> NAK! >> >> Also NAK. >> >>> Too much code are depending on the amba bus in the driver. I sincerely >>> hope you haven't tried this approach for other amba drivers, because >>> it will screw them up and they will become a nightmare to maintain! > > It's almost only probe/remove code.. Nothing in the core of the driver > gets involved here.. What about splitting the driver in three files > (mmci.c, mmci_amba.c and mmci_plat.c) and compile them conditionally? > > BTW This approach is not my invention; there is at least another > driver in mainline kernel that does that: amba-pl011.c > >>> Moreover, there is a way to override the use of the AMBA IDs >>> registers. I think you can use that instead! No? >> > > I'm aware of it; I used it as a quick hack to get the driver probed, > but that looked just like as an hack to me.. I did the same hackish approach and it works, but a first moment rather than changing the code I would suggest to get this ID from ST. Does not mean that as we cannot query from the IP core, it does not exist (my guess). > >> Exactly right. Nothing wrong with creating an amba device in response >> to probing a platform device - which becomes a shim which keeps the >> main driver clean and maintanable. The shim could also be used to >> create amba device for other AMBA drivers too, it doesn't have to be >> MMCI specific. > > If we ovverride the amba regs from DT (is this what you meant?) then > we just take a random number, prentend it to be an amba ID (hoping for > it to be spare), and use it to force the amba bus layer to probe our > driver. How can we make this common for other drivers/devices ? We > need it to be unique, since it's used by the amba layer to probe the > correct driver (given the generic "arm,primecell" compatible DT > property), or am I missing something ? > >> -- >> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ >> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up >> according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
