ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel_ has quit [Ping timeout: 240 seconds]
sakman has quit [Remote host closed the connection]
sakman has joined #armlinux
amitk has joined #armlinux
apritzel_ has joined #armlinux
monstr has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
guillaume_g has joined #armlinux
Crassus has joined #armlinux
apritzel_ has quit [Ping timeout: 244 seconds]
Crassus has quit [Ping timeout: 244 seconds]
frieder has joined #armlinux
tom5760 has quit [Read error: Connection reset by peer]
tom5760 has joined #armlinux
matthias_bgg has joined #armlinux
nsaenz has joined #armlinux
djrscally has joined #armlinux
viorel1 has joined #armlinux
dtor has quit [Read error: Connection reset by peer]
dtor has joined #armlinux
roxell has quit [Read error: Connection reset by peer]
mturquette has quit [Read error: Connection reset by peer]
linusw_ has quit [Read error: Connection reset by peer]
ndesaulniers has quit [Read error: Connection reset by peer]
headless has quit [Quit: Konversation terminated!]
biju has joined #armlinux
apritzel has joined #armlinux
<mwalle>
if I use a pin of a pinctrl driver as a gpio, do I explicitly have to mux it to "gpio" function in a pinctrl-0 dt property or will it be handled by the pinctrl driver?
<mwalle>
I'm not sure, there is a .gpio_request_enable but there are also device trees which set functions to gpio
alexels has joined #armlinux
<robmur01>
I believe it's considered good practice to "document" GPIOs with a pinctrl entry even when the driver does technically handle the mux automatically
<robmur01>
plus sometimes you still want it anyway to tweak pulls, drive strength, etc.
<javierm>
robmur01: and also it feels like a better description of the HW
Amit_T has joined #armlinux
<mwalle>
robmur01: ok makes sense
<mwalle>
javierm: mh, strictly speaking there is a dedicated setting for my function, but the driver "just" supports gpio
<javierm>
mwalle: yes, but that's just an implementation detail of the driver right? That is, you could mux the GPIO pin to a different function
<mwalle>
javierm: mh, i think there could be two different pinctrl settings then. one if you'd use the hardware function and one to use it as a gpio
<geertu>
mwalle: if the DT has gpio-ranges and the driver implements it, switching to GPIO is handled automatically.
<mwalle>
geertu: I know, but the question remains. should I describe it DT or not. Looks like one should do it, because you can't rely on the driver doing it, as you said ".. and the driver implements it"
torez has joined #armlinux
<geertu>
mwalle: Pin control is system integration, but highly SoC-specific. So you should be aware of the hardware, and of the driver's capabiilities.
<robmur01>
except that begs the question of what "the driver" is from the DT's perspective... U-Boot? FreeBSD? ;)
<geertu>
robmur01: good point
<CounterPillow>
ah, the classic "DT is driver/kernel independent" reminder
TheCoffeMaker has quit [Excess Flood]
TheCoffeMaker has joined #armlinux
<robmur01>
proposal: the "unstable" DTs that are really just boardfiles in disguise should all be built into the kernel, and whatever the bootloader passes is just used to match the top-level compatible :D
<javierm>
robmur01: "boardfiles in disguise" LOL
jlinton has joined #armlinux
mag has quit [Ping timeout: 276 seconds]
jlinton has quit [Quit: Client closed]
jlinton has joined #armlinux
c1728p9 has joined #armlinux
amitk_ has joined #armlinux
monstr has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 244 seconds]
jlinton has quit [Quit: Client closed]
biju has quit [Quit: Client closed]
jlinton has joined #armlinux
headless has joined #armlinux
mag_ has joined #armlinux
<ukleinek>
robmur01: there are also gpio/pinctrl drivers that don't do automuxing. For some of them it's even impossible to implement it.
<ukleinek>
robmur01: in my eyes this automuxing is a bad idea, because it makes gpios more special that would be needed.
<ukleinek>
robmur01: a pitfall is for example the case of an i2c controller that doesn't support native bus reset. In that case you have to switch the pins to GPIO mode, do the needed clocking and switch back to native i2c mode.
<ukleinek>
With a pinctrl/gpio driver that does automuxing you must request the gpio only when the bus reset should actually happen (because otherwise you switch pin modes when you don't really want it)
<ukleinek>
but conceptually requesting them at probe time is the right thing to do.
<ukleinek>
(at least for some (subjective?) definition of "right")
nsaenz has quit [Quit: Leaving]
nsaenz has joined #armlinux
Misotauros has quit [Ping timeout: 240 seconds]
alexels has quit [Quit: WeeChat 3.5]
frieder has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 264 seconds]
<geertu>
ukleinek: As wsa developed the i2c bus reset on R-Car, where pinctrl does do the muxing when the GPIO is requested, I guess i2c bus reset handles that fine?
headless has quit [Ping timeout: 240 seconds]
headless has joined #armlinux
<ukleinek>
geertu: I didn't check, but knowing wsa I assume he tested it and it works as it is.
jlinton has quit [Quit: Client closed]
Misotauros has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
matthias_bgg has quit [Ping timeout: 276 seconds]
rvalue has joined #armlinux
apritzel_ has joined #armlinux
matthias_bgg has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]