public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andres Salomon <dilinger@queued.net>
To: Jeremy Katz <katzj@redhat.com>
Cc: jordan@cosmicpenguin.net, Pavel Machek <pavel@suse.cz>,
	Takashi Iwai <tiwai@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jordan Crouse <jordan.crouse@amd.com>,
	linux-kernel@vger.kernel.org, dsaxena@laptop.org
Subject: Re: [PATCH] ALSA: cs5535audio: only build OLPC support if MGEODE_LX is defined
Date: Fri, 14 Nov 2008 16:10:35 -0500	[thread overview]
Message-ID: <20081114161035.786f89ba@ephemeral> (raw)
In-Reply-To: <1226688350.13086.61.camel@aglarond.local>

On Fri, 14 Nov 2008 13:45:50 -0500
Jeremy Katz <katzj@redhat.com> wrote:

> On Fri, 2008-11-14 at 10:34 -0700, Jordan Crouse wrote:
> > Pavel Machek wrote:
> > >>>> i've zapped this patch meanwhile:
> > >>>>
> > >>>>  1355c96: x86/olpc: make CONFIG_OLPC dependent on
> > >>>> CONFIG_MGEODE_LX
> > >>>>
> > >>>> because it cripples the ability to run distribution kernels on
> > >>>> the OLPC.
> > >>> OK, I reverted also all relevant changes for cs5535audio driver
> > >>> now. The patches are saved in topic/cs5535audio branch, though.
> > >>>
> > >>> Let's fix OLPC-geode coupling first.
> > >> Hm, I'd really rather prefer this to be upstream.  The patch I
> > >> sent adds no regressions, allows the driver to happily coexist
> > >> with existing stuff, and *does* add support if you configure
> > >> OLPC with MGEODE_LX (generic kernels don't get the additional
> > >> benefits, but those configured specifically for OLPC do).
> > > 
> > > Yes, but the patch is also not a good way of going forward, so it
> > > should not be in mainline.
> > 
> > For the moment, this is a reasonable intermediate solution.  I
> > think the way forward will involve a great deal more work.
> 
> It's the work that should have been done from the beginning.  And once
> code is upstream, the motivation to make things "correct" drops

Wow.  You have it so backwards, it's not even funny.

When stuff is upstream, there is pressure from lots of people to make
things "correct".  When stuff isn't upstream, there's very little pressure;
that's how the ALSA stuff has managed to sit outside of the upstream
kernel for ages.  It's a tiny bit of code, easy to port to new kernels,
and therefore can happily be forgotten about in an out-of-tree kernel.

You say "it's work that should have been done from the beginning", and
yet this is the first time that I've heard anyone request it.  If
the geode code had remained out of mainline, I wouldn't have heard the
request at all.

I *really* don't want this to turn into OFW/promfs mess; attempts at
mainline inclusion fail, relevant parties who we contact ignore us
regarding the "correct" way forward, and therefore things sit outside
of mainline for ages with no progress whatsoever.


[...]
> > Also, while we are at it, we should be more specific and rename the 
> > hooks from geode_ to cs5536_, since there will soon be a system in
> > the wild with a MIPS processor and a CS5536.
> > 
> > But needless to say, this will be a goodly amount of work and churn
> > that will need some heavy testing in the OLPC kernel.  In the
> > meantime, Andres' fix will make the upstream kernel happier.
> 
> It is work, but I'm not sure it's huge amounts.  And by doing it
> *upstream first*, you benefit from the feedback and testing of the
> wider community.  Development of things in a silo is what tends to
> lead to these sorts of threads :/
> 

It is huge amounts, because it's API work.  If we were just twiddling
hardware bits, that would be easy.  However, we're trying to come up
with an interface that works not only with existing upstream drivers, but
also the remaining out-of-mainline drivers that we maintain.  I also
expressed interest in perhaps using the generic GPIO API for geode,
but that's something that requires a good deal of thinking about.  I
don't want to rush through it just to get the ALSA driver upstream.

The DCON driver has not gone upstream exactly because the GPIO API
does not work well for it right now (and out of tree, we were banging
on GPIO pins directly).  Obviously, any changes to the API should also
take the DCON into account; I'd rather fix this all the *right* way
than to just write a quick patch that munges the API to make you happy,
and then have to have even more code churn later to completely redo
the API.


  parent reply	other threads:[~2008-11-14 21:11 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-11 12:23 [PATCH] x86 - Make CONFIG_OLPC dependent on CONFIG_MGEODE_LX Takashi Iwai
2008-11-11 12:54 ` Ingo Molnar
2008-11-11 13:45   ` Takashi Iwai
2008-11-11 13:53     ` Ingo Molnar
2008-11-11 13:58       ` Takashi Iwai
2008-11-11 14:04         ` Ingo Molnar
2008-11-10  4:17           ` Andres Salomon
2008-11-12 10:53             ` Takashi Iwai
2008-11-12 17:04               ` Andres Salomon
2008-11-12 13:54             ` Jeremy Katz
2008-11-12 14:29               ` Takashi Iwai
2008-11-13  3:44                 ` Jeremy Katz
2008-11-13  6:54                   ` Takashi Iwai
2008-11-13 15:37                     ` Pavel Machek
2008-11-13 15:54                       ` Takashi Iwai
2008-11-13 16:14                         ` [PATCH] ALSA: cs5535audio: only build OLPC support if MGEODE_LX is defined Andres Salomon
2008-11-13 16:31                           ` Takashi Iwai
2008-11-13 17:12                             ` Takashi Iwai
2008-11-13 16:38                           ` Pavel Machek
2008-11-13 16:42                             ` Takashi Iwai
2008-11-13 17:01                             ` Andres Salomon
2008-11-13 19:03                               ` Ingo Molnar
2008-11-13 23:30                                 ` Takashi Iwai
2008-11-14  2:38                                   ` Andres Salomon
2008-11-14  6:54                                     ` Takashi Iwai
2008-11-14  7:52                                     ` Pavel Machek
2008-11-14 17:34                                       ` Jordan Crouse
2008-11-14 18:45                                         ` Jeremy Katz
2008-11-14 19:24                                           ` Jordan Crouse
2008-11-14 21:10                                           ` Andres Salomon [this message]
2008-12-10 16:49                                             ` Takashi Iwai
2008-12-10 18:41                                               ` Andres Salomon
2008-12-11  7:08                                                 ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081114161035.786f89ba@ephemeral \
    --to=dilinger@queued.net \
    --cc=dsaxena@laptop.org \
    --cc=jordan.crouse@amd.com \
    --cc=jordan@cosmicpenguin.net \
    --cc=katzj@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@suse.cz \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox