linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Manuel Lauss <manuel.lauss@googlemail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Manuel Lauss <manuel.lauss@gmail.com>,
	alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] [PATCH 4/7] Alchemy: DB1200 AC97+I2S audio support.
Date: Mon, 8 Jun 2009 12:53:36 +0100	[thread overview]
Message-ID: <20090608115336.GA25827@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <f861ec6f0906080425i388a99a1kb89667c749a815c8@mail.gmail.com>

On Mon, Jun 08, 2009 at 01:25:57PM +0200, Manuel Lauss wrote:
> On Mon, Jun 8, 2009 at 12:20 PM, Mark
> Brown<broonie@opensource.wolfsonmicro.com> wrote:

> > Well, like I say if it's going via MIPS I'd really prefer it to go in
> > this merge window.  If not then I'd expect that splitting out the
> > architecture parts from the machine driver as I suggested ought to deal
> > with the merge issues.

> I'll split it in two:  pure ASoC part and pure board part.  Agreed?

Yes, that's fine for me.

> how to pass DAI private data to the ac97 callbacks), and I also don't see how
> to handle for instance 2 I2S machines with a WM8731 attached to each
> (i.e. how do I tell ASoC that wm8731 at bus0/0x1b belongs to machine A
>  and wm8731 at bus0/0x1c belongs to machine B?)

When multiple cards are supported the struct device for the CODEC will
be used to distinguish between instances of the same device - this is
why the DAI registration functions are being encouraged to use to
provide a struct device, once the multi-card support is in place it will
become much more important to have this information.

> > If you move the selection of the switch position to the architecture
> > code then it can arrange to register only the device that is in use in
> > the current configuration.  If the DMA and DAI drivers both need the
> > same resources they can cooperate with each other - the system will only
> > bring the card on-line once both the DMA and DAI driver are present.

> I think you misuderstood me.  Could you point out an in-kernel machine which
> already implements what you suggested?
> The AC97/I2S dai drivers (psc-ac97/psc-i2s) extract the base address of the PSC
> they're supposed to drive from the platform_device passed via the probe()
> callbacks, these in turn are called when a "soc_audio" platform device
> is called.

Sure, that's exactly what I see you doing and what I'm suggesting that
you change.

> I need to set either the ac97 or I2S platform data for soc_audio based on the
> switch setting.  I can't register a "db1200_audio" platform device in the board
> code which in turn registers the "soc_audio" device and have them share
> the PSC mmio/irq/dma resources.

You should convert the DAI drivers to probe as normal platform devices
and attach the resources used by the CPU to those devices rather than
attaching the data to soc-audio.  pxa2xx-ac97 does this, as do the
PowerPC drivers and the s3c64xx-i2s driver.  The DaVinci drivers
currently on the davinci branch of my git for merge after the merge
window do this too.

  reply	other threads:[~2009-06-08 11:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-07 18:38 [PATCH 0/7] Alchemy: core and platform updates v2 Manuel Lauss
2009-06-07 18:38 ` [PATCH 1/7] Alchemy: prioritize timer and usb irqs Manuel Lauss
2009-06-07 18:38   ` [PATCH 2/7] Alchemy: get rid of allow_au1k_wait Manuel Lauss
2009-06-07 18:39     ` [PATCH 3/7] Alchemy: extended DB1200 board support Manuel Lauss
2009-06-07 18:39       ` [PATCH 4/7] Alchemy: DB1200 AC97+I2S audio support Manuel Lauss
2009-06-07 18:39         ` [PATCH 5/7] Alchemy: new PCMCIA socket driver for devboards Manuel Lauss
2009-06-07 18:39           ` [PATCH 6/7] Alchemy: convert to physmap flash Manuel Lauss
2009-06-07 18:39             ` [PATCH 7/7] Alchemy: db1200 defconfig update Manuel Lauss
2009-06-08  9:25         ` [alsa-devel] [PATCH 4/7] Alchemy: DB1200 AC97+I2S audio support Mark Brown
2009-06-08  9:43           ` Manuel Lauss
2009-06-08 10:20             ` Mark Brown
2009-06-08 11:25               ` Manuel Lauss
2009-06-08 11:53                 ` Mark Brown [this message]
2009-06-08 12:21                   ` Manuel Lauss
2009-06-08 12:44                     ` Mark Brown
2009-06-08 13:11                       ` Manuel Lauss
2009-06-08 13:45                         ` Mark Brown

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=20090608115336.GA25827@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=linux-mips@linux-mips.org \
    --cc=manuel.lauss@gmail.com \
    --cc=manuel.lauss@googlemail.com \
    --cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).