On Tue, Apr 15, 2014 at 3:30 PM, Tomi Valkeinen
wrote:
>
> It looks to me like drm_mode_setplane() doesn't really presume that the
> update_plane would set plane->fb or plane->crtc, as it does that itself
> (and only if update_plane has succeeded).
Yeah that's a bit of historical hilarity. ->set
On Tue, Apr 15, 2014 at 12:10 PM, Rob Clark wrote:
> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes. But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
That shouldn're really matter - if we have the fb assigned as
On 15/04/14 15:24, Rob Clark wrote:
> probably split out omap_plane_mode_set_internal(), call that directly
> from update_plane() for plane operations. And then do the refcnt
> dance in the new omap_plane_mode_set() which calls _internal()..
We don't actually need that. This did the trick:
diff
On 15/04/14 13:10, Rob Clark wrote:
> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes. But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
>
> I suspect there is some way in omap_crtc that I must have assumed the
>
On 15/04/14 13:29, Andrzej Hajda wrote:
> I have experienced similar problem with exynos_drm. I have found that
> in exynos_drm_crtc_mode_set there is line:
>
> plane->fb = crtc->primary->fb;
>
> without drm_framebuffer_reference.
> In result drm_framebuffer_remove dereferences it twice:
>
On 04/15/2014 12:10 PM, Rob Clark wrote:
> On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen
> wrote:
>> On 14/04/14 11:43, Tomi Valkeinen wrote:
>>> On 11/04/14 14:50, Ville Syrj?l? wrote:
>>>
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't fig
On 14/04/14 11:43, Tomi Valkeinen wrote:
> On 11/04/14 14:50, Ville Syrj?l? wrote:
>
>>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>>> of place. I can't figure out which drm_framebuffer_reference() would be
>>> the matching one for the unref done by drm_plane_force_di
On Tue, Apr 15, 2014 at 6:44 AM, Tomi Valkeinen
wrote:
> On 15/04/14 13:29, Andrzej Hajda wrote:
>
>> I have experienced similar problem with exynos_drm. I have found that
>> in exynos_drm_crtc_mode_set there is line:
>>
>> plane->fb = crtc->primary->fb;
>>
>> without drm_framebuffer_refere
On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen
wrote:
> On 14/04/14 11:43, Tomi Valkeinen wrote:
>> On 11/04/14 14:50, Ville Syrj?l? wrote:
>>
So the explicit unref done by drm_plane_force_disable() seems a bit out
of place. I can't figure out which drm_framebuffer_reference() would be
On 11/04/14 14:50, Ville Syrj?l? wrote:
>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>> of place. I can't figure out which drm_framebuffer_reference() would be
>> the matching one for the unref done by drm_plane_force_disable().
>>
>> Any ideas what ref is that? Or is
On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, jus
On Friday 11 April 2014 12:10 PM, Tomi Valkeinen wrote:
>> Does drm_framebuffer_remove get called when we abort the application, or
>> unload omapdrm, or both?
>
> Both. When we abort an app, drm_framebuffer_remove gets called for the
> fb that the app created. When we unload omapdrm, it gets ca
Hi,
On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, just a
On 11/04/14 09:57, Archit Taneja wrote:
> Yes, I meant our driver should call drm_framebuffer_remove() only when
> we are know that the fb reference omapdrm had taken(the one in
> update_pin), has a corresponding fb unref called(in unpin_worker).
>
> Isn't that something omapdrm should take care
On 11/04/14 09:31, Archit Taneja wrote:
> Hi,
>
> On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
>> Hi,
>>
>> I've been debugging omapdrm issues on top of the latest drm mainline
>> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
>> a drm application, or unloadi
On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, jus
Hi,
I've been debugging omapdrm issues on top of the latest drm mainline
changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
a drm application, or unloading the modules.
The setup is very basic, just a single crtc with the crtc's primary plane.
What seems to happen is:
- Ap
17 matches
Mail list logo
