All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Barry Song <21cnbao@gmail.com>
Cc: uclinux-dist-devel@blackfin.uclinux.org,
	alsa-devel@alsa-project.org, lrg@slimlogic.co.uk
Subject: Re: [PATCH 1/2] blackfin I2S(TDM mode) CPU DAI driver
Date: Mon, 27 Jul 2009 15:40:52 +0100	[thread overview]
Message-ID: <20090727144052.GA8900@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <3c17e3570907270300u7ccc47b5q9d0fd9039080deb3@mail.gmail.com>

On Mon, Jul 27, 2009 at 06:00:48PM +0800, Barry Song wrote:
> 2009/7/25 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> > Looking at the code it appears that the main difference is that your TDM
> > mode always configures the DMA layout for 8 channel blocks.  This

> I2S is not a special case of TDM with only left and right two slots
> for SPORT interface. I2S coordinates with TDM in SPORT, but not a part
> of TDM. TDM require different hardware configuration with I2S, not
> only different slot number.
> One is "Stereo Serial Operation" mode of SPORT, the other one is
> "Multichannel Operation" mode. They are incompatible at the same time.

Right, but that's something I'd expect to be handleable at run time -
and in any case, the multi-channel varaint can drop down to only two
channels.

> Mainly due to hardware, it's really difficult for us to control the
> memory layout on the fly. That causes much trouble in hardware and
> driver reliability. Datasheet claims DMA buffer should be fixed while
> SPORT is enabled, but also claims the layout may be changed while
> SPORT is disabled. So it's maybe possible for us to change the SPORT
> api to support the configuration on the fly with a SPORT shutdown,
> then i2s, tdm even ac97 can all use them to reduce the amount of code
> duplication. But it need much work on debugging and testing to make it
> work and reliable. So how about to patch it later as an individual
> project since the changes will involve sport, i2s, ac97 and tdm?

OK, if the hardware is as difficult to use as that I guess the current
situation is adequate.  I'll check over your patch later but the code
was almost ready last time so I don't anticipate any problems.
However...

> >> On the other hand, hardware board connection decides the I2S/TDM mode
> >> directly. It's needless to switch between I2S and TDM dynamically. For
> >> TDM mode, board driver can refer to the TDM instance, for I2S mode,
> >
> > Are you saying that a physically different SPORT or other hardware
> > configuration on the CPU is required to use TDM mode?  The impression
> > given by the drivers has always been that this is some kind of generic
> > synchronous serial port and the way the SPORT number is set up seems to
> > support that.  Could you go into more detail here, please - this would
> > be a very unusual implementation decision for a CPU.

> Here I means the different hardware configuration, and the semantic of
> pins has some differences too for I2S and TDM.

...are you sure there's a different meaning for the external pins - what
are these differences?  If they're not just related to the number of bit
clock cycles per frame clock then are you sure it will interoperate with
other DSP mode devices?

  reply	other threads:[~2009-07-27 14:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-22 18:10 [PATCH 0/2]blackfin TDM dai and blackfin-ad1938 machine driver Barry Song
2009-07-22 18:10 ` [PATCH 1/2] blackfin I2S(TDM mode) CPU DAI driver Barry Song
2009-07-25 12:49   ` Mark Brown
2009-07-27 10:00     ` Barry Song
2009-07-27 14:40       ` Mark Brown [this message]
2009-07-27 16:32         ` Barry Song
2009-07-27 16:35           ` Mark Brown
2009-07-22 18:10 ` [PATCH 2/2] board driver to connect bf5xx with ad1938 Barry Song
2009-07-25 12:49   ` Mark Brown
2009-07-28 21:16   ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2009-07-27 10:06 [PATCH 1/2] blackfin I2S(TDM mode) CPU DAI driver Barry Song
2009-07-28 21:14 ` 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=20090727144052.GA8900@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=21cnbao@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=uclinux-dist-devel@blackfin.uclinux.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.