On 02/15/2013 01:34 PM, Linus Walleij wrote: > On Fri, Feb 15, 2013 at 1:19 AM, Stephen Warren <[email protected]> wrote: >> On 02/14/2013 05:02 PM, Linus Walleij wrote: >>> On Thu, Feb 14, 2013 at 6:05 PM, Doug Anderson <[email protected]> >>> wrote: >> ... >>>> One argument for keeping "cd-inverted" too is >>>> for controllers that don't use a GPIO for card detect. >>>> In this case >>>> you could imagine a MMC controller that has a "card detect" on >>>> special-purpose pin and accessible via a status register. >>> >>> This is actually the case with Integrator/CP and Versatile/AB. >> >> In this case, I assume that the driver for the HW has custom code to >> read the MMC controller's CD register bit, and hence it knows whether >> the HW inverts it, and hence we don't need a property in DT to say so; >> the driver will simply read the bit, invert it, and return it all >> transparently? After all, the inversion isn't board-specific but IP >> block specific. > > No that's not how it works ... heh. > > It calls back to the platform: > > include/linux/amba/mmci.h > * @status: if no GPIO read function was given to the block in > * gpio_wp (below) this function will be called to determine > * whether a card is present in the MMC slot or not > (...) > struct mmci_platform_data { > (...) > unsigned int (*status)(struct device *); > (...) > bool cd_invert; > > So the flag tells whether that signal should be interpreted > as inverted or not. The same flag is used for GPIO > insertion detection. > > The code reading the status will read a certain register > like this (arch/arm/mach-integrator_cp.c): > > static unsigned int mmc_status(struct device *dev) > { > unsigned int status = readl(__io_address(0xca000000 + 4)); > writel(8, intcp_con_base + 8); > > return status & 8; > } > > 0xca000000 + 4 is just the second 32bit word in the system > controller. This address range and that very word is used > for various stuff, so it's not like a general-purpose GPIO > or anything, it's just that one pin being readable throgh that > very bit.
Surely a GPIO is exactly what that is... It might be annoying to create a GPIO controller driver for just that, but that seems like the simplest way to implement that HW from a device tree perspective. With DT, it'd be painful to plug in that board callback into the platform data there. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
