GPIO hint meanings
Warner Losh
imp at bsdimp.com
Fri Sep 6 22:57:06 UTC 2013
On Sep 6, 2013, at 4:27 PM, Ian Lepore wrote:
> On Fri, 2013-09-06 at 16:13 -0600, Warner Losh wrote:
>> On Sep 6, 2013, at 4:00 PM, Ian Lepore wrote:
>>
>>> On Fri, 2013-09-06 at 13:42 -0600, Warner Losh wrote:
>>>> On Sep 6, 2013, at 12:31 PM, Luiz Otavio O Souza wrote:
>>>>
>>>>> On 6 September 2013 14:22, Sean Bruno <sean_bruno at yahoo.com> wrote:
>>>>>
>>>>>> I think I have a fairly firm grasp on what some of the mips/gpio hints
>>>>>> mean, e.g.:
>>>>>>
>>>>>> hint.gpio.0.pinmask
>>>>>> hint.gpioled.0.at
>>>>>> hint.gpioled.0.name
>>>>>> hint.gpioled.0.pins
>>>>>>
>>>>>> Fairly straightforward.
>>>>>>
>>>>>> Now, what do these mean/do:
>>>>>>
>>>>>> hint.gpio.0.function_set
>>>>>> hint.gpio.0.function_clear
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>> p.s. I think I'll take this and thrash together a gpioled(4) and gpio(4)
>>>>>> man page if I can understand better.
>>>>>>
>>>>>
>>>>>
>>>>> Hi Sean,
>>>>>
>>>>> Some of the GPIO pins on this SoC family (ar724x, ar71xx and ar9xxx) can be
>>>>> set between GPIO and an alternate function. So adding a pin to function_set
>>>>> enables this alternate function and the function_clear disables it
>>>>> (sometimes the bootloader doesn't initialize properly those pins).
>>>>>
>>>>> Each SoC has its own set of pins and functions.
>>>>>
>>>>> For ar71xx the pins 0 and 1 can be used as additional SPI chip select
>>>>> outputs, pins 9 and 10 are used for UART and there are also reserved pins
>>>>> for a SLIC/I2S interface.
>>>>
>>>>
>>>> We really need a pinmux/pinctl type interface for this which is standard across drivers/platforms.
>>>>
>>>
>>> The more ARM SoCs I look at, the less I think we could design a single
>>> pinmux api that works for all of them. The number of things that can be
>>> controlled varies from almost-nothing to chips that let you select from
>>> one of a dozen different resistor strengths for pullup or pulldown per
>>> pin. And that's not to mention really crazy things like daisy-chaining
>>> pins so the signal also goes to another pin which can be forced as an
>>> input even though it's normally a device output.
>>
>> Linux is able to have one, although I'm not sure how they handle the daisy-chain... that's a new one on me...
>>
>
> Maybe they just don't, since it's a weird enough thing that probably
> nothing uses it. I only discovered it because the datasheet said it was
> a potential workaround for an erratum that had to do with a device not
> handling a pin properly.
Yea, I think that linux doesn't implement that level...
> The semi-related thing I've been pondering lately is clock and power
> management. I don't even care about dynamic stuff, just a simple common
> way for a driver to figure out what clock(s) and/or power need to be on
> for it to run, and a common api for turning them on would be nice.
> (Whether clocks and power should be two separate APIs or not is a basic
> question.)
I think the two are interrelated enough they need to at lest be co-releated. But I'd love to see that...
Warner
More information about the freebsd-embedded
mailing list