On Fri, Jan 17, 2014 at 06:14:50PM -0200, Paulo Zanoni wrote:
> 2014/1/16 Daniel Vetter :
> > Currently we're doing the reset handling a bit late, and we're doing
> > it both in the driver load code and on resume. This makes it unusable
> > for e.g. resetting the panel power sequence state like Pau
2014/1/16 Daniel Vetter :
> Currently we're doing the reset handling a bit late, and we're doing
> it both in the driver load code and on resume. This makes it unusable
> for e.g. resetting the panel power sequence state like Paulo wants to.
>
> Instead of adding yet another single-use callback shu
Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.
Instead of adding yet another single-use callback shuffle things
around:
- Output handli
2014/1/16 Daniel Vetter :
> On Thu, Jan 16, 2014 at 4:24 PM, Daniel Vetter wrote:
>> Currently we're doing the reset handling a bit late, and we're doing
>> it both in the driver load code and on resume. This makes it unusable
>> for e.g. resetting the panel power sequence state like Paulo wants t
On Thu, Jan 16, 2014 at 4:24 PM, Daniel Vetter wrote:
> Currently we're doing the reset handling a bit late, and we're doing
> it both in the driver load code and on resume. This makes it unusable
> for e.g. resetting the panel power sequence state like Paulo wants to.
>
> Instead of adding yet an
Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.
Instead of adding yet another single-use callback shuffle things
around:
- Output handli
