Active low GPIOs (was [PATCH v1 1/4] i2c: mux: Add i2c-arbitrator 'mux' driver)

[Stephen Warren]

On 02/15/2013 01:34 PM, Linus Walleij wrote:
> On Fri, Feb 15, 2013 at 1:19 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 02/14/2013 05:02 PM, Linus Walleij wrote:
>>> On Thu, Feb 14, 2013 at 6:05 PM, Doug Anderson <dianders at chromium.org> 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.