[PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sat, Jun 15, 2013 at 12:15 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
>> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > If you're happy with the patch I supplied, that's probably the minimal fix
>> > which should go to stable kernels (I'm using 3.9 here) - this also counts
>> > as a "user visible bug".  It's something I've tripped over which causes
>> > exhausts memory and can prevent the X server from starting up.
>> >
>> > If you want me to package the patch up with a commit message and sign-off..
>>
>> Your patch doesn't fix drm/i915 (since we don't use the crtc helpers
>> any more). And I don't think it's good to have the refcounting
>> partially in the drm core and partially in drivers.
>
> Let me check what you mean by that.  I hope you mean that the drm core,
> drm helpers and drivers are individually responsible for dropping any
> refcount that they obtain on any object.
>
> In other words, if the drm core takes a refcount on object X, then the
> DRM core must be the code base which drops that refcount.

Yeah, that's the idea. But since with the currently quirky drm core
->set_config callback the drivers need to drop the reference if any
other crtc loses all its connectors. My patch also drops the ref for
that fb in the drm core functions. The reason for that is that we want
to switch to a global ->set_config function anyway (usually called
atomic modeset) to push the configuration for all the crtcs into the
hw in one step (or fail it completely ofc). The current approach leads
to too much flickering and some funny hacks in drivers ...

Of course such gradual transitions over mutliple kernel release (we're
shuffling backend code in drm/i915 since about 3.7 for this) leaves a
few ugly intermediat states. But I prefer to move into the overall
right direction with a bit of ugliness than doing such big transitions
in one big swoop.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch