[PATCH] drm: refcnt drm_display_mode
Daniel Vetter
daniel at ffwll.ch
Sun Jul 27 10:38:51 PDT 2014
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.
>> 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.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list