On Fri, Dec 16, 2016 at 11:00:35PM +0100, Harald Geyer wrote:
> Mark Brown writes:
> > > I was hoping, that I somehow could get the necessary coordination from
> > > the regulator framework. If the best I can get ATM is notifications, then
> > > I'll try it and see what kind of code falls out of t
Mark Brown writes:
> On Fri, Dec 16, 2016 at 02:41:42PM +0100, Harald Geyer wrote:
> > Mark Brown writes:
> > > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
>
> > > This doesn't feel like a regulator API problem exactly, a lot of what
> > > you're talking about here seems like you
On Fri, Dec 16, 2016 at 02:41:42PM +0100, Harald Geyer wrote:
> Mark Brown writes:
> > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
> > This doesn't feel like a regulator API problem exactly, a lot of what
> > you're talking about here seems like you really need the devices to
> >
Mark Brown writes:
> On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
>
> > Thus the following constraints should be met:
> > * When user space asks
> > the driver to read a device, it needs to "claim" the supply and
> > ensure that it has been up for at least 2 seconds before pro
On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
> Thus the following constraints should be met:
> * When user space asks the driver to read a device, it needs to "claim"
> the supply and ensure that it has been up for at least 2 seconds
> before proceeding to read the HW. The sup
Hi all!
I have a quite complex situation with regulator consumers, which I'm not
sure how to handle best.
Suppose there is some quirky HW that after some random time crashes - i.e.
it doesn't respond to requests anymore at all. The driver can detect this
situation and the only way to fix it is to
6 matches
Mail list logo
