[Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

[Tomi Valkeinen]

On 09/04/18 11:41, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 09:10:43AM +0300, Tomi Valkeinen wrote:
>> On 05/04/18 19:50, Daniel Vetter wrote:
>>> On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote:
>>>> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>>>
>>>> omap_framebuffer_get_next_connector() uses plane->fb which we want to
>>>> deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
>>>> is unused just nuke the entire function.
>>>>
>>>> Cc: Tomi Valkeinen <tomi.valkeinen at ti.com>
>>>> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>>
>>> Yeah was slightly worried how to fix up this one, but we're lucky!
>>>
>>> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>>
>> I tried to remove it just a week ago, but Sebastian said that it's used
>> by a unmerged series about DSI command mode displays, so I dropped the
>> patch.
>>
>> In the unmerged series, it's used by omap_framebuffer_dirty() ([PATCHv3
>> 3/8] drm/omap: add support for manually updated displays). So we have a
>> framebuffer, and we want to know which crtcs need to be flushed.
> 
> You can't do that in atomic drivers.
> 
> You need to take appropriate locks and do the full ->state->fb deref.
> Also, there's a gazillion of copies for generic framebuffer_dirty
> implementations floating around, pleas try to coordinate with those.

Ok. In that case we need to refresh the manual update series to do
things differently. For this patch:

Reviewed-by: Tomi Valkeinen <tomi.valkeinen at ti.com>

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki