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

Linus Walleij linus.walleij at linaro.org
Sat Feb 16 07:34:14 EST 2013


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.

Typical prototype-glue-ASIC-to-this-very-board design
pattern. Generic GPIO was not thought of at the time,
it was introduced in later ARM reference designs.

Yours,
Linus Walleij


More information about the devicetree-discuss mailing list