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

[Emil Velikov]

Hi Marco,

Disclaimer: I'm mostly lurking around, barring the occasional patch so
please take my input with a grain of salt.

On 1 June 2017 at 23:46, Marco Diego Aurélio Mesquita
<marcodiegomesquita at gmail.com> wrote:
> Hi Devs!
>
> On Thu, Jun 1, 2017 at 8:59 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi All,
>>
>> This is a resend of a patch I send out a while back, rebased on top
>> of 4.12-rc3. Back then the main comment was can you try to make this
>> driver use the drm_simple_kms_helper stuff? Unfortunately I have
>> not had time yet to look into this.
>>
>> Recently I've been contacted by Marco Diego Aurélio Mesquita (in the Cc)
>> who wants to work on getting this driver ready for mainline.
>>
>> He has has some questions / ideas about how to do this, so the
>> main reason for reposting this is to give him a thread to reply to
>> which provides context for his questions / ideas.
>>
>
> Hans, thanks for citing me.
>
> I'm an owner of a c120 miniprojector and would like to have this
> driver on mainline. As far as I could test (previous versions) it
> works reasonably well. From what I've seen[1], main obstacle for this
> driver been mainlined is the duplicated code from the udl driver.
>
> I've been playing with the code of this driver for a few days and I
> think that moving the common code between the udl and gm12u320 is a
> sound idea. It would greatly simplify the code of both drivers and
> both would become much smaller.
>
> Since I'm a coder myself, I would like to do it myself. Common code
> and differences from both drivers are very easy to spot and moving
> that into a common lib is something that I think a can do without any
> problems. The only reason I still have not started it is because I
> don't know if such work would be accepted.
>
> So, my question for you devs is: do you agree in factoring out some
> code from the udl driver so that both drivers (udl and gm12u320) can
> be smaller and simpler?
>
> If the answer to this question is yes, then I'll start coding and plan
> to comeback just to ask about minor details about what is really
> specific (even if equal) for any driver and what is not.
>
As Daniel mentioned in the earlier thread, factoring out things can be
done as a follow-up.
On the other hand, I _think_ that the blocker for this driver that
it's not doing atomic mode setting.

There's some example resources in Daniel's blog [1], although you
could skim through any of the existing drivers that were converted
recently (git log -p | grep DRIVER_ATOMIC)

-Emil

[1] http://blog.ffwll.ch/