[RFC] Using DC in amdgpu for upcoming GPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 12, 2016 at 12:57:40PM +1000, Dave Airlie wrote:
> 4) Why can't we put this in staging?
> People have also mentioned staging, Daniel has called it a dead end,
> I'd have considered staging for this code base, and I still might.
> However staging has rules, and the main one is code in staging needs a
> TODO list, and agreed criteria for exiting staging, I don't think we'd
> be able to get an agreement on what the TODO list should contain and
> how we'd ever get all things on it done. If this code ended up in
> staging, it would most likely require someone dedicated to recreating
> it in the mainline driver in an incremental fashion, and I don't see
> that resource being available.

So it's not just that I think the staging experience for drivers isn't
good (e.g. imx, gma500), there's also the trouble that it's a separate
tree and the coordination becomes a pain. That was very ugly around all
the sync_file stuff imo, and for next time around we ever do that we
should just put it into drm first and clean up second. We could do staging
like with nouveau, but that's imo not really any different from just
merging if we only slap a Kconfig depends upon the entire pile. So just
don't see the benefit.

I think stagin is good for checkpatch cleanup, but we already agreed that
we're ok with ugly code if it's the stuff debugged by hw engineers. And
for anything else like real refactoring I of big pieces of code I just
don't see how staging makes sense. Maybe if it's a completely new
subsystem, but the point here is that we want DC to integrate tighter with
drm and be able to share code.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux