On Thu, Feb 11, 2016 at 04:17:55PM -0800, Stephen Boyd wrote: > On 02/11, Georgi Djakov wrote: > > 8064 uses SSBI instead of SPMI and we currently do not have any > > existing regulator support upstream yet. So this driver is not > > duplicating any existing regulator. We should decide whether to > > keep this driver or to replace it with a new ssbi-regulator driver > > and bindings instead, where we can avoid the split-bus fun at > > least to some extent. Maybe the latter is the better option? > Yes I think having an ssbi/spmi regulator driver may be a better > approach. The SAW code can monitor the regulator for voltage > changes with a notifier and then stick the restore voltage into > the SAW registers. There's only one sticking point below. So this is sounding like we want to drop this driver? > modifies the SAW registers to set the voltage on the CPU that is > using the regulator, thereby preventing the CPU from going idle > or hitting suspend when the voltage is changed. If we were to use > the SSBI/SPMI regulator driver we would need to do something > similar so that the SPM is guaranteed to not be running during > the voltage switch. So I guess schedule a work on the CPU that's > affected by the voltage switch and hope that the CPU doesn't go > offline during that time? "Hope" doesn't sound like this is going to be a safe long term solution, either something more integrated with the offline code that explicitly blocks offlining (which I don't off the top of my head know if we can do easily) or something where we start something on the CPU and then explicitly handshake with it (but then what if the CPU has real work to do?) seems better.
Attachment:
signature.asc
Description: PGP signature
