All of lore.kernel.org
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] ASoC: split pxa ssp for reusing code
Date: Mon, 22 Mar 2010 13:06:04 +0000	[thread overview]
Message-ID: <20100322130604.GA1379@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <771cded01003220458i5a2c6860i278dd8edf72d1150@mail.gmail.com>

On Mon, Mar 22, 2010 at 07:58:49AM -0400, Haojian Zhuang wrote:
> On Sat, Mar 20, 2010 at 1:00 PM, Mark Brown

> > Like I keep saying the SSP port configuration is really rather fragile
> > (in part due to the documentation issues) so forking this code seems
> > like it's going to be painful in the long run.

> I don't want to merge hw_params() between pxa2xx and pxa168 together.
> Because I won't change pxa2xx function code. In my zylonite platform,

Why not?  Like I say, this seems like a really retrograde step for long
term support - it means having more drivers to maintain.  The existing
PXA2xx code is very much a work in progress as it is and having to deal
with two copies of it doesn't fill me with great joy.

If there were some substantial difference in the hardware it'd be worth
forking but I'm just not seeing any such difference showing up in the
code for the actual port (as opposed to the clocks behind it).

> sound can't work with 2.6.34-rc1 kernel. If I change pxa2xx
> functionality code, I can not verify it. I need to check why sound
> can't work on zylonite first. I'm planning to follow this after this
> change set.

I'd test but unfortunately my Zylonite doesn't boot with mainline and
the patch I used to apply to get it to do so has bitrotted :(  In any
case, the key audio there is the AC97 which should be independant of the
SSP port anyway.

> >> +/*
> >> + * pxa2xx-ssp.c ?-- ?ALSA Soc Audio Layer
> >> + *

> > I'm not a big fan of the naming here since this also covers PXA3xx
> > devices. ?Is there some general term for the non-MMP processors which
> > could be used - I'm not aware of one but I might've missed something?

> pxa2xx is enough. Actually there's no general term for the non-MMP
> processors. The silicon behavior on SSP is defferent one by one. In
> PXA910, we will use SQU as DMA. In PXA168, we will use another clock
> system. In PXA968, we will use ABU in SSP. The difference between
> pxa2xx and pxa3xx is so small. PXA168 and PXA910 is MMP processors.
> PXA968 is non-MMP processors.

Feh, I guess.  Get your marketing department to make up some shiny
names for the different device classes :)

      reply	other threads:[~2010-03-22 13:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19 15:51 [PATCH 1/6] ASoC: split pxa ssp for reusing code Haojian Zhuang
2010-03-20 17:00 ` Mark Brown
2010-03-22 11:58   ` Haojian Zhuang
2010-03-22 13:06     ` Mark Brown [this message]

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=20100322130604.GA1379@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.