Re: [RFC 0/1] drm: Add Grain Media GM12U320 kms driver

From: Hans de Goede <hdegoede@redhat.com>
To: "Marco Diego Aurélio Mesquita" <marcodiegomesquita@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC 0/1] drm: Add Grain Media GM12U320 kms driver
Date: Sun, 11 Jun 2017 21:22:37 +0200	[thread overview]
Message-ID: <b0a4cd1c-c004-70d2-0369-f10169d053d0@redhat.com> (raw)
In-Reply-To: <CAE_m23mtTeGm8CmOu2x7HtcG56Y8Ak9dvOJQuogW_EtggfHQoA@mail.gmail.com>

Hi,

On 11-06-17 19:20, Marco Diego Aurélio Mesquita wrote:
> On Sat, Jun 10, 2017 at 3:39 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> On 10-06-17 19:14, Marco Diego Aurélio Mesquita wrote:
>>> I applied this change and now gnome monitors tool identifies it as
>>> another monitor, thanks Noralf! There are still some problems: when I
>>> activate it, gnome complains "could not set configuration for CRTC
>>> 284". I still don't know what causes this. Any idea?
>>>
>>> Other problem I get is that the device is spontaneously disconnected
>>> after some time. I'm not sure what causes this, but I think it happens
>>> because it receives no data after an amount of time.
>>
>>
>> Correct, there is no way to blank (think DPMS off) the device, but
>> it will turn itself of it does not get any data for more then x seconds,
>> I don't remember what X was.
>>
> 
> I made an initial port of the workqueue to the in-progress driver. The
> behaviour improved. I no longer get spurious
> re-connections/disconnections and the device no longer shows its logo;
> that probably means that the data is successfully really reaching the
> device, I guess.
> 
> I still have some problems. When I activate it through the gnome
> monitors tool, I get an error message: "failed to apply configuration
> %s" "timeout was reached". It doesn't complains about the crtc as
> before, but I still can't activate it. Anyone knows what is the
> problem that is causing this? Noralf, any idea?
> 
> Now, my next steps will be to move part of the recently added code to
> another file, bring back the dirty callback, detect pages flips, call
> the update work queue accordingly, enable ecomode and fix some leaks.
> After that, the only thing missing to port will be the part that moves
> the data from the framebuffer to the blocks that are sent through usb.
> Hans, any objection to this roadmap/plan?

No sounds good to me.

Regards,

Hans
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel