On Tue, Sep 06, 2016 at 11:04:38AM +0800, Chen-Yu Tsai wrote: > On Tue, Sep 6, 2016 at 3:31 AM, Maxime Ripard > <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > > Hi Jorik, > > > > On Sat, Sep 03, 2016 at 02:09:32PM +0200, Jorik Jonker wrote: > >> On Fri, Sep 02, 2016 at 09:04:25AM +0200, Maxime Ripard wrote: > >> >Unfortunately, these pins can be used for other purposes as well, so > >> >we cannot make force that decision down to our users. > >> > >> Yes, but since the associated peripheral is disabled, the users are free to > >> configure other functions/peripherals, right? I mean something like this in > >> pseudo-DT: > >> > >> /soc/pio: pinctrl@01c20800/uart1_pins: > >> allwinner,pins = "PG6, PG7"; > >> /soc/pio: pinctrl@01c20800/foo0_pins: > >> allwinner,pins = "PG6, PG7"; > >> .. > >> /soc/uart1: serial@serial@01c28400: > >> pinctrl-0 = <&uart1_pins>; > >> status = "disabled"; > >> /soc/bar: > >> pinctrl-0 = <&uart1_pins>; > >> status = "disabled"; > >> > >> Assuming Linux/DT allows this, this would force nothing, only offer choice > >> and ease of use. > > > > Hmm, sorry, I went over your patches too quickly... > > > > That's a great compromise I think. Chen-Yu, any opinion on this? > > In short, I'm ok with it. But please put an explicit > > status = "disabled"; > > and probably a comment about how/where the peripheral can be > used in the board dts. > > I intended to do this for the Banana Pis. Though my original plan > was to enable Raspberry Pi compatible peripherals by default, and > list the other peripherals that are defined by the vendor as > "disabled". > > "Defined by the vendor" means that the vendor has some sort of > document associating the gpio header pins with the peripherals, > as shown in: > > http://www.orangepi.org/Docs/Pindefinition.html#CON3_Definition > > This should make it easier for the average user to enable the > peripherals. I'm not sure we should list _all_ possible ones > though. That would make the list very large, and some might > end up never being used. Having a clear limit on what we can put and what we can't isn't very easy to do though. Any suggestion on how we can solve that? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
