Re: Right amount of info in the DT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 05/07/2017 12:26 PM, Linus Walleij wrote:
> Does all of these really have gpio controller functionality?
> You do not have to compulsively add that. Just make it
> a pin controller.

Most of them have pin controller functionalities, because the pins
can be muxed between GPIO and another function. Only the first group
is GPIO only (dedicated pins). But apart from the choosing of the
current function, the other properties (direction, value) are handled
the same way.
Regarding that, I was wondering what's the recommended approach to
mutualize code:
1. Having a driver under drivers/gpio and another on drivers/pinctrl
   which depends on the first one.
2. Having both drivers in the same file under drivers/pinctrl.
3. Having only one pinctrl driver.
For now I've taken approach 3, but isn't it strange to have pins
dedicated to GPIO like this first group I mentioned controlled
for a pinctrl driver?
What is your opinion on this?

> But I was not meaning you should collect them all under a
> "pins" node like this, but inside each peripheral.

OK, I will do that. Although not all alternate functions currently
have a driver, nor a node in the device tree. I guess the best way
to handle that is to declare the pins as GPIO only and not to worry
about the alternate function; which brings me back to the question
above. Do they need a separate GPIO driver?

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux