LKML Archive on
help / color / mirror / Atom feed
From: "Aggrwal Poonam" <>
To: "Kumar Gala" <>,
	"Andrew Morton" <>
Cc: "Phillips Kim" <>,
	<>, <>,
	<>, <>,
	"Barkowski Michael" <>,
	"Kalra Ashish" <>,
	"Cutler Richard" <>,
	"Suresh PV" <>
Subject: RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Date: Fri, 18 Jan 2008 17:28:41 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello All

The TDM driver just now does not have a proper framework. Probably the
interface cannot be generalised as such. Hence we could not decide
whether it would be right to think of a TDM framework. Infact the
interface this TDM driver(for MPC8323ERDB) supplies may not be usable
for some other client as such. Please suggest on this.

But you are right as far as Freescale PowerPC platforms are concerned
which have TDM devices. Like, 8315 also has a TDM driver which also
exposes similar interface as 8323 because the client it is talking to is
the same.

Following is the small description of the TDM driver along with
interface details:

The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.

The driver on the upper level can plug to more than one tdm clients
depending on the availablity  of TDM devices. At every new request of
the TDM client to bind with a TDM device, a free driver  instance is
allocated to the client.

The interface can be described as follows.

tdm_register_client(struct tdm_client *)
	This API returns a pointer to the structure tdm_client which is
of type
	struct tdm_client {
                u32 driver_handle;
                u32 (*tdm_read)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
                u32 (*tdm_write)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
                wait_queue_head_t *wakeup_event;

   It consists of:
   - driver_handle: It is basically to identify the particular TDM
device/driver instance.
   - tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data  form a particular TDM channel.
   - tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data  to a particular TDM channel.
   - wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping,  and the TDM driver wakes it up periodically.
The driver is configured to wake up the client  after every 10ms.

Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces  with the driver using tdm_read, tdm_write and

Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any  file interface for User Applications. Can be
compared to the spi driver which interfaces with  the SPI clients
through some APIs.

I need your feedback on the interface details. Some changes were
suggested by Andrew for 32 bit tdm handle which I will modify.(Thanks

Please give your ideas about a TDM framework in the kernel and the

Waiting for your feedback.

Thanks and Regards

-----Original Message-----
From: Kumar Gala [] 
Sent: Tuesday, January 15, 2008 9:01 AM
To: Andrew Morton
Cc: Phillips Kim; Aggrwal Poonam;;;;;; Barkowski Michael;
Kalra Ashish; Cutler Richard
Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms

On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote:

> On Mon, 14 Jan 2008 12:00:51 -0600
> Kim Phillips <> wrote:
>> On Thu, 10 Jan 2008 21:41:20 -0700
>> "Aggrwal Poonam" <> wrote:
>>> Hello  All
>>> I am waiting for more feedback on the patches.
>>> If there are no objections please consider them for 2.6.25.
>> if this isn't going to go through Alessandro Rubini/misc drivers, can

>> it go through the akpm/mm tree?
> That would work.  But it might be more appropriate to go Kumar-
> >paulus->Linus.

I'm ok w/taking the arch/powerpc bits, but I"m a bit concerned about  
the driver itself.  I'm wondering if we need a TDM framework in the  

I guess if Poonam could possibly describe how this driver is actually  
used that would be helpful.  I see we have 8315 with a discrete TDM  
block and I'm guessing 82xx/85xx based CPM parts of some form of TDM  
as well.

- k

  parent reply	other threads:[~2008-01-18 11:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-10 11:53 Aggrwal Poonam
2008-01-11  4:41 ` Aggrwal Poonam
2008-01-14 18:00   ` Kim Phillips
2008-01-14 21:15     ` Andrew Morton
2008-01-15  3:31       ` Kumar Gala
2008-01-15 12:05         ` Aggrwal Poonam
2008-01-16 11:47         ` Kalra Ashish
2008-01-18 11:58         ` Aggrwal Poonam [this message]
2008-01-18 12:18           ` Joakim Tjernlund
2008-01-11  4:54 ` Aggrwal Poonam
  -- strict thread matches above, loose matches on Subject: below --
2007-12-10 11:40 Aggrwal Poonam

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).