Hi Dave,

I think this is part of the reason a lot of people get fed up with
working upstream in Linux.  I can respect your technical points and if
you kept it to that, I'd be fine with it and we could have a technical
discussion starting there.  But attacking us or our corporate culture is
not cool.  I think perhaps you have been in the RH silo for too long.
Our corporate culture is not like RH's.  Like it or not, we have
historically been a windows centric company.  We have a few small Linux
team that has been engaged with the community for a long time, but the
rest of the company has not.  We are working to improve it, but we can
only do so many things at one time.  GPU cycles are fast.  There's only
so much time in the day; we'd like to make our code perfect, but we
also want to get it out to customers while the hw is still relevant.
We are finally at a point where our AMD Linux drivers are almost feature
complete compared to windows and we have support upstream well before hw
launch and we get shit on for trying to do the right thing.  It doesn't
exactly make us want to continue contributing.  That's the problem
with Linux.  Unless you are part time hacker who is part of the "in"
crowd can spend all of his days tinkering with making the code perfect,
a vendor with massive resources who can just through more people at it,
or a throw it over the wall and forget it vendor (hey, my code can just
live in staging), there's no room for you.

You love to tell the exynos story about how crappy the code was and then
after it was cleaned up how glorious it was. Except the vendor didn't
do that.  Another vendor paid another vendor to do it.  We don't happen
to have the resources to pay someone else to do that for us.  Moreover,
doing so would negate all of the advantages to bringing up the code
along with the hw team in the lab when the asics come back from the fab.
Additionally, the original argument against the exynos code was that it
was just thrown over the wall and largely ignored by the vendor once
it was upstream.  We've been consistently involved in upstream (heck,
I've been at AMD almost 10 years now maintaining our drivers).  You talk
about trust.  I think there's something to cutting a trusted partner
some slack as they work to further improve their support vs. taking
a hard line because you got burned once by a throw it over the wall
vendor who was not engaged.  Even if you want to take a hard line,
let's discuss it on technical merits, not mud-slinging.

I realize you care about code quality and style, but do you care about
stable functionality?  Would you really merge a bunch of huge cleanups
that would potentially break tons of stuff in subtle ways because coding
style is that important?  I'm done with that myself.  I've merged too
many half-baked cleanups and new features in the past and ended up
spending way more time fixing them than I would have otherwise for
relatively little gain.  The hw is just too complicated these days.
At some point people what support for the hw they have and they want it
to work.  If code trumps all, then why do we have staging?

I understand forward progress on APIs, but frankly from my perspective,
atomic has been a disaster for stability of both atomic and pre-atomic
code.  Every kernel cycle manages to break several drivers.  What happened
to figuring out how to do in right in a couple of drivers and then moving
that to the core.  We seem to have lost that in favor of starting in
the core first.  I feel like we constantly refactor the core to deal
with that or that quirk or requirement of someone's hardware and then
deal with tons of fallout.  Is all we care about android?  I constantly
hear the argument, if we don't do all of this android will do their own
thing and then that will be the end.  Right now we are all suffering and
android barely even using this yet.  If Linux will carry on without AMD
contributing maybe Linux will carry on ok without bending over backwards
for android.  Are you basically telling us that you'd rather we water
down our driver and limit the features and capabilities and stability
we can support so that others can refactor our code constantly for hazy
goals to support some supposed glorious future that never seems to come?
What about right now?  Maybe we could try and support some features
right now.  Maybe we'll finally see Linux on the desktop.

Alex