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
oldgalileo has quit [Ping timeout: 256 seconds]
oldgalileo has joined #armlinux
Lockesmith has quit [Remote host closed the connection]
Lockesmith has joined #armlinux
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
oldgalileo has quit [Ping timeout: 268 seconds]
<pinchartl>
linusw__: should GPIO drivers serialize access ? is concurrent access considered a bug in the caller, or should the GPIO driver handle that ?
<pinchartl>
I suppose I should handle it in the GPIO driver, as multiple GPIOs are handled in the same hardware register
apritzel has quit [Ping timeout: 264 seconds]
jclsn has quit [Ping timeout: 260 seconds]
misanthropos has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
jclsn has joined #armlinux
misanthropos has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
amitk has joined #armlinux
<linusw__>
pinchartl: since s GPIO can only be requested by one consumer I don't see how there can ever be two concurrent calls?
<linusw__>
But concurrency toward a single register is another thing indeed, there you need a spinlock or mutex.
<linusw__>
As far as there are several GPIOs controlled by the same register.
<linusw__>
If a consumer (device driver) has multiple threads running then I guess concurrency could happen, then the consumer needs to serialize access to the GPIO descriptor.
oldgalileo has joined #armlinux
amitk has quit [Ping timeout: 260 seconds]
Lockesmith has quit [Ping timeout: 260 seconds]
Lockesmith has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
apritzel has joined #armlinux
headless has joined #armlinux
apritzel has quit [Ping timeout: 264 seconds]
headless has quit [Quit: Konversation terminated!]
System_Error has quit [Remote host closed the connection]