[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-19 Thread Laurent Pinchart
Hi Chris, On Saturday 08 June 2013 08:53:30 Chris Wilson wrote: > On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote: > > Could you please also update Documentation/DocBook/drm.tmpl ? > > It looks out of context there, as nothing explains the hotplug -> > fill_modes -> probe -> dete

Re: [PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-18 Thread Laurent Pinchart
Hi Chris, On Saturday 08 June 2013 08:53:30 Chris Wilson wrote: > On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote: > > Could you please also update Documentation/DocBook/drm.tmpl ? > > It looks out of context there, as nothing explains the hotplug -> > fill_modes -> probe -> dete

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-08 Thread Daniel Vetter
On Wed, Jun 5, 2013 at 5:50 PM, Chris Wilson wrote: > The typical procedure after a hotplug event is then to enumerate all the > new modes. In the existing code, this is achieved by performing a forced > detection cycle over all connectors. Ideally, we should just be able to > use the current det

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-08 Thread Laurent Pinchart
Hi Chris, Thanks for the patch. On Wednesday 05 June 2013 16:50:14 Chris Wilson wrote: > The typical procedure after a hotplug event is then to enumerate all the > new modes. In the existing code, this is achieved by performing a forced > detection cycle over all connectors. Ideally, we should ju

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-08 Thread Chris Wilson
On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote: > Could you please also update Documentation/DocBook/drm.tmpl ? It looks out of context there, as nothing explains the hotplug -> fill_modes -> probe -> detect loop... How about: Modes int (*fill_modes)(struct drm_connector *c

Re: [PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-08 Thread Daniel Vetter
On Wed, Jun 5, 2013 at 5:50 PM, Chris Wilson wrote: > The typical procedure after a hotplug event is then to enumerate all the > new modes. In the existing code, this is achieved by performing a forced > detection cycle over all connectors. Ideally, we should just be able to > use the current dete

Re: [PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-08 Thread Chris Wilson
On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote: > Could you please also update Documentation/DocBook/drm.tmpl ? It looks out of context there, as nothing explains the hotplug -> fill_modes -> probe -> detect loop... How about: Modes int (*fill_modes)(struct drm_connector *c

Re: [PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-08 Thread Laurent Pinchart
Hi Chris, Thanks for the patch. On Wednesday 05 June 2013 16:50:14 Chris Wilson wrote: > The typical procedure after a hotplug event is then to enumerate all the > new modes. In the existing code, this is achieved by performing a forced > detection cycle over all connectors. Ideally, we should ju

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-05 Thread Chris Wilson
The typical procedure after a hotplug event is then to enumerate all the new modes. In the existing code, this is achieved by performing a forced detection cycle over all connectors. Ideally, we should just be able to use the current detection status and only enumerate the modes on the connectors t

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

2013-06-05 Thread Chris Wilson
The typical procedure after a hotplug event is then to enumerate all the new modes. In the existing code, this is achieved by performing a forced detection cycle over all connectors. Ideally, we should just be able to use the current detection status and only enumerate the modes on the connectors t