Re: ichsmb - correct locking strategy?
On Tue, Feb 22, 2011 at 3:37 PM, John Baldwin wrote: > On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: >> Hi, >> >> I try to figure out locking strategy in FreeBSD and found 'ichsmb' >> device. There is a mutex which protects smb bus (ichsmb device). For >> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is >> locked and a command is written to bus, then unbounded (but with >> timeout) sleep is done (mutex is unlocked during sleep). After sleep a >> word is read from bus and the mutex is unlocked. >> >> 1. If an use of the device IS NOT serialized by layers around then >> more calls to this function (or others) can be started or even done >> before the first one is finished. The mutex don't protect sms bus. >> >> 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> Am I right? Or did I miss something? > > Hmm, the mutex could be useful if you have an smb controller with an interrupt > handler (I think ichsmb or maybe intpm can support an interrupt handler) to > prevent concurrent access to device registers. That is the purpose of the > mutex at least. There is a separate locking layer in smbus itself in (see > smbus_request_bus(), etc.). > > -- > John Baldwin > I see. So, multiple accesses to bus are protected by upper smbus layer itself. And the mutex encloses each single access in respect of interrupt. I.e., an interrupt can be assigned to a command (bus is either command processing or idle) and a wait to command result can be done atomically (no wakeup is missed). Am I right? BTW, a mutex priority propagation isn't too much exploited here. Maybe, it will be better for me to not take this feature into account when thinking about locking strategy and just take a mutex in most cases as a low level locking primitive which is indeed. Well, it seems that things become more clear. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ichsmb - correct locking strategy?
On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: > Hi, > > I try to figure out locking strategy in FreeBSD and found 'ichsmb' > device. There is a mutex which protects smb bus (ichsmb device). For > example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is > locked and a command is written to bus, then unbounded (but with > timeout) sleep is done (mutex is unlocked during sleep). After sleep a > word is read from bus and the mutex is unlocked. > > 1. If an use of the device IS NOT serialized by layers around then > more calls to this function (or others) can be started or even done > before the first one is finished. The mutex don't protect sms bus. > > 2. If an use of the device IS serialized by layers around then the > mutex is useless. > > Moreover, I don't mension interrupt routine which uses the mutex and > smb bus too. > > Am I right? Or did I miss something? Hmm, the mutex could be useful if you have an smb controller with an interrupt handler (I think ichsmb or maybe intpm can support an interrupt handler) to prevent concurrent access to device registers. That is the purpose of the mutex at least. There is a separate locking layer in smbus itself in (see smbus_request_bus(), etc.). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ichsmb - correct locking strategy?
On Fri, Feb 18, 2011 at 4:09 PM, Hans Petter Selasky wrote: > On Friday 18 February 2011 15:10:47 Svatopluk Kraus wrote: >> Hi, >> >> I try to figure out locking strategy in FreeBSD and found 'ichsmb' >> device. There is a mutex which protects smb bus (ichsmb device). For >> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is >> locked and a command is written to bus, then unbounded (but with >> timeout) sleep is done (mutex is unlocked during sleep). After sleep a >> word is read from bus and the mutex is unlocked. >> >> 1. If an use of the device IS NOT serialized by layers around then >> more calls to this function (or others) can be started or even done >> before the first one is finished. The mutex don't protect sms bus. >> >> 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> Am I right? Or did I miss something? > > man sx ? > > struct sx ? > > --HPS > Thanks for your reply. It seems that everybody knows that ichsmb driver is not in good shape but nobody cares for ... Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ichsmb - correct locking strategy?
On Friday 18 February 2011 15:10:47 Svatopluk Kraus wrote: > Hi, > > I try to figure out locking strategy in FreeBSD and found 'ichsmb' > device. There is a mutex which protects smb bus (ichsmb device). For > example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is > locked and a command is written to bus, then unbounded (but with > timeout) sleep is done (mutex is unlocked during sleep). After sleep a > word is read from bus and the mutex is unlocked. > > 1. If an use of the device IS NOT serialized by layers around then > more calls to this function (or others) can be started or even done > before the first one is finished. The mutex don't protect sms bus. > > 2. If an use of the device IS serialized by layers around then the > mutex is useless. > > Moreover, I don't mension interrupt routine which uses the mutex and > smb bus too. > > Am I right? Or did I miss something? man sx ? struct sx ? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ichsmb - correct locking strategy?
Hi, I try to figure out locking strategy in FreeBSD and found 'ichsmb' device. There is a mutex which protects smb bus (ichsmb device). For example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is locked and a command is written to bus, then unbounded (but with timeout) sleep is done (mutex is unlocked during sleep). After sleep a word is read from bus and the mutex is unlocked. 1. If an use of the device IS NOT serialized by layers around then more calls to this function (or others) can be started or even done before the first one is finished. The mutex don't protect sms bus. 2. If an use of the device IS serialized by layers around then the mutex is useless. Moreover, I don't mension interrupt routine which uses the mutex and smb bus too. Am I right? Or did I miss something? Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
