Upstreaming DAL

[Dave Airlie]

On 24 March 2016 at 03:27, Alex Deucher <alexdeucher at gmail.com> wrote:
> Our goal is to transition to our new DAL display stack.  It is the
> path we are validating internally for both the open and hybrid stacks
> and will be the only display stack we support going forward with new
> asics.  When we initially released the patches, there were some rough
> edges and quite a few things were pointed out that need to be fixed.
> Some are relatively easy to fix, others will take time.  Our goal is
> to make those changes.  We'd like to target 4.7 for upstreaming DAL.
> To that end, I think it would be easier to review and track our
> progress if I maintained a public DAL branch and send out patches
> against that branch rather than respinning giant squashed patches
> every time we fix something.  It's much harder to track what progress
> has been made.  DAL is currently at ~400 patches.  We previously tried
> to squash that down into a bunch of larger commits, but I'm not sure
> that is particularly easy to review.  I'm also not sure it's worth
> spamming the list with 400 patches.  I've posted our current DAL tree
> here for review:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip-dal
> I can certainly send out the patches if that is preferred.  We will be
> sending out all new patches to the list as the further clean up tasks
> and new features are implemented.
>
> Our goal is to fix the following items in time for 4.7.  Additional
> fixes and re-factoring will continue as we work to address all of the
> comments and concerns.

I think people are focusing on the minor comments and concerns
and possibly deliberately ignoring the bigger concern that this
code is base is pretty much unmergeable as-is.

Cleaning this up won't be a matter of just removing some memset's,
mallocs and moving on.

This code needs redesign by someone with Linux kernel development
experience. Alex if you have any other tasks in AMD, I suggest you
apply to have them all scrapped and you take this on board.

So much of this code seems to be "architected" design. I mean
someone senior draws a bunch of powerpoint slides with nice blocks,
with what are abstraction layers between them, then a bunch of other
coders take that powerpoint slide and work on a box each until it all
comes together. However the abstractions don't survive so well and you
end up with a bunch of leaky boxes all co-dependent and joined together
but still abstracted.

So let's take a massive step back from the edge here and figure out what
we expect a modesetting codebase for a driver in the Linux kernel to look
like and write that.

Can we work out what code is actually per-GPU family and what code
you want to write per GPU bringup etc.

Because looking at this, for a new DCE variant or GPU you need to write:

DC support: (dc/dce*) lots of code 9k-20k per DCE family
DC clock gating support (dc/gpu/dce*)
BIOS support: (bios_support/dce*) (can you spot leaky abstraction
number one?) 1k lines
bandwidth_calcs : wow that file alone is impenetrable, even after coding
standards.
adapter support: dc/adapter/dce*
irq support
gpio support
asic_capability : per GPU code.

Now tell me what the abstractions bring if you end up having to poke
per-DCE holes
into each layer to get them to talk.

Maybe we should treat DAL as an example of how to drive the hardware, and evolve
the driver to support things.

Like you could start with pulling the bandwidth_calcs into the current
driver codebase,
and using it, then you could pull the bios parser into the current
driver codebase and
start cleaning up using that and iterate across things.

So my advice is to spend more time on how a Linux display driver looks
and not how
to abstract everything away.

I'm actually nearly getting to the point of realising nobody actually
understands my concerns
here and just trying to write a driver on my own.

I'm still slightly open to some sort of STAGING for this, but I think
I'm nearly at the level,
that I'd only accept that on the understanding we'd try and evolve the
driver to this level,
rather than think we can clean DAL to the kernel standards.

Dave.