[PATCH] drm: refcnt drm_display_mode

[Rob Clark]

On Sun, Jul 27, 2014 at 1:38 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Sun, Jul 27, 2014 at 6:20 PM, Rob Clark <robdclark at gmail.com> wrote:
>> On Sun, Jul 27, 2014 at 11:17 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>> On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark <robdclark at gmail.com> wrote:
>>>> We're going to need this for atomic.
>>>>
>>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>>
>>> I disagree. Iiui correctly Rob's concern is that the additional stuff
>>> to keep track of mode lists (list_head and the idr stuff) could
>>> confuse driver writers into doing stupid stuff when they embed
>>> drm_display_mode into some other stuff. Imo the right fix would be to
>>> just remove them (but that's fairly invasive to the mode list code).
>>
>> bleh, all the deep copies seem ugly either way, I still think
>> refcnt'ing and shallow copies is the better idea
>
> Until people start screaming at me I'm not really concerned with cpu
> overhead in the modeset code. We need to do piles of uncached register
> writes (at least in most drivers) and it's run about 60 times per
> second. Imo we can and should optimize programmer time over cpu time
> here. So if deep copies allow us to avoid refcounting, them I'm all
> for it.

oh, I'm sure it would be hard to measure a difference.. just seems
pointlessly stupid not to do refcnt'ing ;-)

>>> Now wrt atomic we only need refcounting because currently
>>> drm_atomic_state is refcounted. And we don't need that afaics (and I'm
>>> working on the draft code to show how). So without a clear need for
>>> refcounting I really prefer we don't add this complexity - doing
>>> refcounting for fbs wasn't fun at all ;-)
>>
>> Well, that was somewhat different, because there were some side-effects of rmfb
>
> That's not the part I've meant since that's just a gross hack - the
> rmfb stuff isn't done on the final unref, only on the final unref from
> userspace. And the hack was required to avoid undoing all the benefits
> of the finer-grained locking. I'm meaning the inherent auditing we
> need to do when adding refcounting, and the potential complexity going
> forward.

we use refcnt'ing in enough other places, it isn't like it is a new
and foreign concept..

if needed, we can back it up w/ some debugfs to simplify checking for leaks..

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch