Re: [PATCH] Tracing events with GPIOs

[Jean-Jacques Hiblot]

2013/12/20 Alexandre Courbot <gnurou@xxxxxxxxx>:
> On Thu, Dec 19, 2013 at 8:38 PM, Jean-Jacques Hiblot
> <jjhiblot@xxxxxxxxxxxxxxx> wrote:
>> 2013/12/19 Alexandre Courbot <gnurou@xxxxxxxxx>:
>>> The problems I can see so far:
>>>
>>> - Using gpiod, GPIOs are not specified as integers, but are typically
>>> mapped to a given (device, function) pair (device can be NULL) using
>>> device tree/platform data/ACPI and obtained by the corresponding
>>> device driver through gpiod_get(). You would need to find a different
>>> way to specify GPIOs, maybe using the gpio_chip's label and the GPIO
>>> hardware number.
>>>
>>> - Even if you do so, there is currently no way to arbitrarily obtain a
>>> GPIO that has not been explicitly mapped to a (device, function), and
>>> IIUC you need to specify the tracing GPIO freely from user-space. This
>>> hints that we will need to add a function that is sensibly the same as
>>> gpio_request_one() to the gpiod API, but I wonder if that does not
>>> defeats the purpose somehow.
>>
>> This is something I was wondering about for another reason. In many
>> cases the GPIOs that are physically available for probing will be
>> limited to the GPIOs already assigned a function (backlight control
>> for example), others are usually not routed except in eval boards or
>> early prototypes. And consequently those GPIOs will be requested by a
>> driver long before a probe is set.
>> It would be nice not to have to remove the driver to be able to use
>> this GPIO  as a probe. Maybe a gpiod_steal() interface and a flag
>> indicating that the GPIO can be safely stolen?
>
> Mmm an explicit way to hijack a GPIO does not sound very safe. Do you
> have concrete cases where you need to do so? I guess most boards you
> may want to use this patch with would have at least some spare GPIOs
> with pins somewhere on the board for this kind of purpose.
It's not always true. There are quite a few platforms where GPIOs is a
scarce resource (ppc for example). For example, the board I'm working
on at the moment is built around a APM powerpc which has only 16
GPIOs. Of those 16 GPIOS, some are not routed and most of the others
are hidden by the shielding so that I can probe only those that go to
external connectors.
IMHO it's probably the case for most of the boards that go into a
final product where EMI and space constraints are tight.
But I agree that's not safe. I thought that maybe a flag indicating
when it is safe would help (on my board that would be : ok to use the
GPIO that turns on or off the backlight, not ok to use the GPIO that
controls the power supply)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/