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: 265 seconds]
PobodysNerfect has joined #armlinux
PobodysNerfect has quit [Ping timeout: 240 seconds]
alpernebbi has quit [Ping timeout: 256 seconds]
alpernebbi has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #armlinux
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cbeznea has joined #armlinux
heat has quit [Ping timeout: 240 seconds]
macromorgan has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
tachoknight has joined #armlinux
tachoknight has quit [Ping timeout: 256 seconds]
monstr has joined #armlinux
guillaume_g has joined #armlinux
frieder has joined #armlinux
iivanov1 has joined #armlinux
iivanov1 has quit [Quit: Leaving.]
PobodysNerfect has joined #armlinux
<wens>
linusw__: Have you seen any shared GPIO cases other than regulators? we're expecting to see components (TDDI, or touch w/ display driver) with shared reset pins, and are wondering what's the best fit
<geertu>
wens: On various Renesas R-Car Gen3 boards, there are GPIOs shared by LEDs and switches.
<bjdooks>
but iirc you can point the led driver at gpio controller
<wens>
bjdooks: you mean gpio hogs? but then you sort of can't control them
<geertu>
switches are active-low, LEDs are active-high.
<wens>
geertu: sounds interesting
<geertu>
When the GPIO is switched to input, the LED lights up, and pressing the switch will turn it off, as a side-ecffect
<wens>
I guess it boils down to how to let two or more device drivers share a single GPIO line to control something
<geertu>
Indeed. The LED+switch case is a bit complicated, because you can only read the switch state when the LED is on.
<wens>
for our case we could work around it by describing them as regulators, but I was curious if there were less hacky ways
<wens>
I don't recall seeing GPIO-based reset controllers in the past though
<geertu>
IIRC, linusw suggested the GPIO-based reset controller? reset controller support shared resets
<wens>
yeah, that was my second option
<linusw__>
wens: yeah I've also seen shared resets before
<linusw__>
I think I've said that it'd fine to just go and implement drivers/reset/reset-gpio.c (despite that subsystem is mostly for silicon reset) and use shared lines like regulators do.
<linusw__>
The problem is that that is not exactly easy, the reset controller may be easy but two drivers will need to cooperate to actually perform a live reset.
<linusw__>
Like a LCD and a touch screen controller will need to signal each other if one of them want reset and the other does not, so they can both bring down the reference count to 0 in cooperation.
<linusw__>
Some even say that breaks encapsulation and assumptions that all drivers make of resources being independent.
m5zs7k has quit [Ping timeout: 240 seconds]
<linusw__>
So it is pretty stupid hardware design and consequently leads to stupid software design...
headless has joined #armlinux
sszy has joined #armlinux
m5zs7k has joined #armlinux
<wens>
yeah... I was just made aware that the display part in the TDDI thing needs to trigger reset multiple times during init... (facepalm)
undeadscholar has joined #armlinux
<geertu>
Sharing saves pins (at the expense of something else)
<geertu>
My favorite is still the interrupt line shared by two PMICs, who both assert it on boot to indicate power had been lost before...
bps has joined #armlinux
bps has quit [Changing host]
bps has joined #armlinux
<wens>
I've seen those, though the PMICs I saw weren't as crazy
<mvaittin>
Well, HW designers tend to do "novel" solutions :) My favourite was the opposite of Geert's. One PMIC which provided two separate IRQ lines - but had IRQ status/ACK/MASK for both mixed in same register(s). Ultimate race-by-design.
<tmlind>
hehe also check out dave brownell's old comment "mentor saves a bit" somewhere in drivers/usb/musb :)
rockosov has joined #armlinux
PobodysNerfect_ has joined #armlinux
PobodysNerfect has quit [Ping timeout: 268 seconds]
<linusw__>
arnd: it appears the build robots are actually not complaining about my static inline work on virt_to_pfn(), I thought I would have to go on forever...
guillaume_g has quit [Quit: Konversation terminated!]
bps has quit [Ping timeout: 256 seconds]
<geertu>
linusw__: Works fine on ARAnyM. Compiles with a few warnings for Sun-3, will look into that tomorrow...
<marex>
ukleinek: hey, you around ?
<marex>
ukleinek: I have a bit of a question regarding pwm core
<marex>
ukleinek: I am looking at 546 int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
<marex>
ukleinek: there is 560 if (!pwm || !state || !state->period ||
<marex>
562 return -EINVAL;
<marex>
ukleinek: this blows up if state->enabled is false and state->period = 0 (which I think is a valid case, no?)
headless has joined #armlinux
headless_ has joined #armlinux
headless has quit [Ping timeout: 265 seconds]
headless_ has quit [Quit: Konversation terminated!]
headless has joined #armlinux
<marex>
dtor: frieder: hi, I am looking at pwm beeper and I would like to set volume (PWM duty cycle), I wonder whether I should try and extend SND_TONE somehow (but but, kernel ABI) or go the sysfs attribute way (doesnt sound quite right either)
<marex>
any hints ?
apritzel has quit [Ping timeout: 240 seconds]
<robmur01>
there would seem to be a reasonable argument for a DT property for duty cycle to match the one for frequency
<marex>
robmur01: I want this configurable at runtime