On Mon, Jun 19, 2017 at 11:48:05AM +0200, Ulf Hansson wrote:
> [...]
>
> >> >
> >> > Unlike the MMC design, there is no dts entry to indicate whether this
> >> > device needs pwrseq or not at this design, it will only carry out power
> >> > on sequence after matching. So, return -EPROBE_DEFER may
[...]
>> >
>> > Unlike the MMC design, there is no dts entry to indicate whether this
>> > device needs pwrseq or not at this design, it will only carry out power
>> > on sequence after matching. So, return -EPROBE_DEFER may not work since
>> > this device may never need pwrseq.
>>
>> Then, how
On Mon, Jun 19, 2017 at 10:09:58AM +0200, Ulf Hansson wrote:
> On 15 June 2017 at 12:06, Peter Chen wrote:
> > On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
> >> On 15 June 2017 at 11:11, Peter Chen wrote:
> >> > On Thu, Jun 15, 2017
On 15 June 2017 at 12:06, Peter Chen wrote:
> On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
>> On 15 June 2017 at 11:11, Peter Chen wrote:
>> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
>> >> > Yes, you are right.
On Thu, Jun 15, 2017 at 06:06:04PM +0800, Peter Chen wrote:
> On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
> > On 15 June 2017 at 11:11, Peter Chen wrote:
> > > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
> > >> > Yes, you are right. This is
On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
> On 15 June 2017 at 11:11, Peter Chen wrote:
> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
> >> > Yes, you are right. This is the limitation for this power sequence
> >> > library, the
On 15 June 2017 at 11:11, Peter Chen wrote:
> On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
>> > Yes, you are right. This is the limitation for this power sequence
>> > library, the registration for the 1st power sequence instance must
>> > be finished before
On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
> > Yes, you are right. This is the limitation for this power sequence
> > library, the registration for the 1st power sequence instance must
> > be finished before device driver uses it. I am appreciated that
> > you can supply some
On 15 June 2017 at 08:58, Peter Chen wrote:
> On Wed, Jun 14, 2017 at 10:53:29AM +0200, Ulf Hansson wrote:
>> On 14 June 2017 at 03:53, Peter Chen wrote:
>> > On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
>> >> [...]
>> >>
>> >> > +
>>
On Wed, Jun 14, 2017 at 10:53:29AM +0200, Ulf Hansson wrote:
> On 14 June 2017 at 03:53, Peter Chen wrote:
> > On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
> >> [...]
> >>
> >> > +
> >> > +/**
> >> > + * of_pwrseq_on - Carry out power sequence on for device
On 14 June 2017 at 03:53, Peter Chen wrote:
> On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
>> [...]
>>
>> > +
>> > +/**
>> > + * of_pwrseq_on - Carry out power sequence on for device node
>> > + *
>> > + * @np: the device node would like to power on
>> > + *
On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
> [...]
>
> > +
> > +/**
> > + * of_pwrseq_on - Carry out power sequence on for device node
> > + *
> > + * @np: the device node would like to power on
> > + *
> > + * Carry out a single device power on. If multiple devices
> > + *
[...]
> +
> +/**
> + * of_pwrseq_on - Carry out power sequence on for device node
> + *
> + * @np: the device node would like to power on
> + *
> + * Carry out a single device power on. If multiple devices
> + * need to be handled, use of_pwrseq_on_list() instead.
> + *
> + * Return a pointer to
We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.
This power sequence is hard to be described at device tree and handled by
related host driver, so we have
14 matches
Mail list logo