[PATCH 00/29] Enabling new DAL display driver for amdgpu on Carrizo and Tonga

[Harry Wentland]

Hi Jerome,

some of the kernel API is abstracted to allow testing of this driver in 
user space for pre- and post-silicon validation. An alternative that 
we've considered is implementing the kernel functions in user space. 
That's definitely an option.

We're definitely open to push things into drm and help develop common 
functionality, such as MST and others. The DC abstraction is necessary, 
however, to handle current and future hardware requirements agnostically.

Cheers,
Harry

On 2016-02-14 06:22 AM, Jerome Glisse wrote:
> On Sat, Feb 13, 2016 at 12:05:48AM +0000, Wentland, Harry wrote:
>> Hi Dave, Daniel, others,
> [...]
>
>> There's still a bunch of legacy stuff in these patches that's on our list of things to refactor. Some of that is
>> - dc/adapter
>> - dc/asic_capability
>> - dc/audio
>> - dc/bios
>> - dc/gpio
>>
>> We should be able to cut the size of this code to about 1/3 of what it is now.
>>
>> As for the LOC we have about
>> 22k for HW programming
>> 30k legacy stuff
>> 6k  dc/calcs - autogenerated from formulas provided by HW team
>> 15k includes
>> 6k  amdgpu_dm
>> 8k  dc/core
>>
>> About 14k of those are blank lines (we have a habit of leaving lots of blank space) and 16k are comments.
> Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c,
> or similar, is a no go. If the current drm infrastructure does not suit your
> need then you need to work on improving it to suit your need. You can not
> redevelop a whole drm layer inside your code and expect to upstream it.
>
> Linux device driver are about sharing infrastructure and trying to expose
> it through common API to userspace.
>
> So i strongly suggest that you start thinking on how to change the drm API
> to suit your need and to start discussions about those changes. If you need
> them then they will likely be usefull to others down the road.
>
> Cheers,
> Jérôme