On Thu, Jun 6, 2013 at 9:49 AM, Chris Wilson
wrote:
> On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
>> On some chipset we try to avoid possibly invasive output detection
>> methods (like load detect which can cause flickering elsewhere) in the
>> output poll work. Drivers could h
On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
> On some chipset we try to avoid possibly invasive output detection
> methods (like load detect which can cause flickering elsewhere) in the
> output poll work. Drivers could hence return unknown when a previous
> full ->detect call re
On Thu, Jun 6, 2013 at 3:49 AM, Chris Wilson
wrote:
> On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
>> On some chipset we try to avoid possibly invasive output detection
>> methods (like load detect which can cause flickering elsewhere) in the
>> output poll work. Drivers could h
On Thu, Jun 6, 2013 at 3:49 AM, Chris Wilson wrote:
> On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
>> On some chipset we try to avoid possibly invasive output detection
>> methods (like load detect which can cause flickering elsewhere) in the
>> output poll work. Drivers could he
On Thu, Jun 6, 2013 at 9:49 AM, Chris Wilson wrote:
> On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
>> On some chipset we try to avoid possibly invasive output detection
>> methods (like load detect which can cause flickering elsewhere) in the
>> output poll work. Drivers could he
On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote:
> On some chipset we try to avoid possibly invasive output detection
> methods (like load detect which can cause flickering elsewhere) in the
> output poll work. Drivers could hence return unknown when a previous
> full ->detect call re
On some chipset we try to avoid possibly invasive output detection
methods (like load detect which can cause flickering elsewhere) in the
output poll work. Drivers could hence return unknown when a previous
full ->detect call returned a different state.
This change will generate a hotplug event, f
On some chipset we try to avoid possibly invasive output detection
methods (like load detect which can cause flickering elsewhere) in the
output poll work. Drivers could hence return unknown when a previous
full ->detect call returned a different state.
This change will generate a hotplug event, f