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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
