Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-15 Thread Peter Ujfalusi 
On Thursday 14 October 2010 17:51:15 ext Varadarajan, Charulatha wrote:

  Yes, this need to be fixed, but it can be done later, it does
  not need to be
  part of the hwmod series.
 
 Okay.

This problem there for a long time, and so far no one complained, or fixed it.
Probably there are no users for pollread/write at all, but I would not remove 
the functionality. It is better to fix them later.
 
   2. DMA transfers would also not work as it requires a patch
  
  similar to [y].
  
  Well, this patch was sent in 2008. nowdays we moved the OMAP
  audio support to
  ASoC, and there are no 'legacy' ALSA arm/omap drivers anymore.
  In ASoC the cpu_dai and the platform drivers are separate things.
  This allows us to use the same platform driver (omap-pcm) for
  McBSp, McPDM (and
  in theory we could have OMAP2 EAC) cpu_dai drivers without
  duplicating code.
  As a note: most of the features this patch was trying to
  implement is already
  done for the ASoC implementation, but if there is need for
  new features, it has
  to be done using the ASoC framework.
 
 If we do this, would it not contradict the idea of keeping the door
 open for others to use the McBSP ports?

Why? If you add support for different sample formats to ASoC, it will not 
change 
anything.
 
 If other users should be allowed to use McBSP ports, it is good to
 have DMA support in plat-omap/mcbsp.c itself and modify the asoc
 implementation to take advantage of the proposed new mcbsp
 design. If agreed, this shall be addressed later. Please let
 me know your thoughts on this.

What I mean is that later we could add DMA transfer functionality if there is a 
need, but at the moment I don't see any reason to do that.
Also moving the DMA functionality to plat-omap/mcbsp.c would require quite a 
big 
change in there, and as well in the ASoC code. On top of that we will broke the 
sound/soc/omap/omap-pcm.c to be McBSP independent, and that is one of the main 
points here. We are using omap-pcm.c with McBSP and McPDM dai drivers. That has 
to remain the same.
In the future we can implement DMA transfer capabilities to mcbsp.
I would not do this as part of hwmod either.
I think such an extension to the current McBSP code is only needed if/when we 
have other users for McBSP than audio.

   Coming back to the original question. Either we need to fix
  
  the broken
  
   legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
   layer. What do you say?
  
  I would keep the partitioning same as it is now.
 
 Okay.
 
  If there is a reason we can add bus driver functionality to
  McBSP,
 
 Can you elaborate? mcbsp driver is already following platform bus
 device model.

I meant adding DMA functionality to McBSP. I would not worry about this at this 
time.

 
  but at the
  moment there is no need for that.
 
 For testing any changes in mcbsp driver (including hwmod), we are
 relying on internal patches (dma/pollmode patches). Instead, if
 mcbsp dma support is available in the driver itself, it would be
 useful for bug fixing/development activities.

You should use audio (ASoC) for verification, for example Beagle, or other 
board. I would say that the audio support is solid on OMAP platforms, and that 
is the main thing which must work after hwmod conversion.

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-15 Thread Mark Brown 
On Fri, Oct 15, 2010 at 09:51:09AM +0300, Jarkko Nikula wrote:

 So things can get complicated if trying to implement generic transfer
 API to general purpose block like McBSP compared to some dedicated
 block where transfer setup is always more or less the same.

I tend to agree.  Experience with some of the other platforms suggests
that doing the abstracted API for data transfers doesn't save you that
much unless the hardware is really hard to manage and so needs lots of
code that can be factored out from the leaf drivers.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-13 Thread Peter Ujfalusi 
Hi,

On Friday 08 October 2010 09:20:19 ext Varadarajan, Charulatha wrote:
 Sorry I am confused.
 
 With hwmod implementation, there is a device register code for mcbsp
 devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
 address, dma info are not part of pdata and are available to the driver
 only after probe. I do not understand how the multi-component design in
 ASOC can avoid the new API.
 
 Also with this multi-component approach in ASOC, two device
 registrations happens for a single mcbsp device with two different
 rames (omap-mcbsp-dai.id  omap-mcbsp.id). Please explain if this
 what is expected?

I have given myself some time to think this over...
I think the best way forward is to provide an API from plat-omap/mcbsp.c for 
client drivers (like ASoC audio) to ask for the needed configuration (the 
things 
that is 'hard wired' in soc/omap/omap-mcbsp.c at the monent).
Something like omap-mcbsp-get-config(id, config);

In this way we can keep the door open for other uses of McBSP if ever needed.

  We still need to modify the ASoC drivers to make use of this platform
  data, but
  at least we are going to keep the door open for others to use the McBSP
  ports
  for other than audio.
 
 Agreed. But the current omap-mcbsp driver cannot work standalone for
 OMAP3/4 due to the issues stated below:
 1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
 registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
 are limited to 32-bit data accesses and hence poll mode would not work [x].

Yes, this need to be fixed, but it can be done later, it does not need to be 
part of the hwmod series.

 2. DMA transfers would also not work as it requires a patch similar to [y].

Well, this patch was sent in 2008. nowdays we moved the OMAP audio support to 
ASoC, and there are no 'legacy' ALSA arm/omap drivers anymore.
In ASoC the cpu_dai and the platform drivers are separate things.
This allows us to use the same platform driver (omap-pcm) for McBSp, McPDM (and 
in theory we could have OMAP2 EAC) cpu_dai drivers without duplicating code.
As a note: most of the features this patch was trying to implement is already 
done for the ASoC implementation, but if there is need for new features, it has 
to be done using the ASoC framework.

 Coming back to the original question. Either we need to fix the broken
 legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
 layer. What do you say?

I would keep the partitioning same as it is now.
If there is a reason we can add bus driver functionality to McBSP, but at the 
moment there is no need for that.
 
-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-12 Thread kishon 

ping..

On Friday 08 October 2010 11:50 AM, Varadarajan, Charulatha wrote:




-Original Message-
From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com]
Sent: Wednesday, October 06, 2010 12:47 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; Kamat,
Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam;
jhnik...@gmail.com; broo...@opensource.wolfsonmicro.com; ABRAHAM, KISHON
VIJAY
Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx
devices

Hello,


Thanks for the quick response.



On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:

This patch series is targeted to implement mcbsp driver in
hwmod way and to make use of pm_runtime APIs.

This patch series is tested on OMAP3  4 and yet to be tested
on OMAP2.

There are few clarifications required so that the next patch series
can be implemented after aligning.

1. Audio layer is making use of mcbsp and it's dma base addresses and
is closely coupled with omap-mcbsp.
This can be handled either by
a. providing an API with which Audio layer can get these addresses.
(or)
b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
[1]

Option (a) would only be a workaround to handle the situation. As
audio is the only user for mcbsp, option (b) is better. If option(b)
is agreed upon, the same can be addressed on top of the mcbsp hwmod
series.


it is true that at the moment only audio is using the McBSP ports, but
McBSP is
really flexible, it can run for example in SPI mode, and it can be
configured to
use other serial protocols.


Yes.


I would go with option c.
Since ASoC is moving to multi-component (the conversion is already in
linux-
next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are
platform drivers.
So if the plat-omap/mcbsp would register the platform device for McBSP
clients
(we have only ASoC client at the moment), and use platform data to pass
the
needed information to the McBSP client driver, than we do not need new API.


Sorry I am confused.

With hwmod implementation, there is a device register code for mcbsp
devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
address, dma info are not part of pdata and are available to the driver
only after probe. I do not understand how the multi-component design in
ASOC can avoid the new API.

Also with this multi-component approach in ASOC, two device
registrations happens for a single mcbsp device with two different
rames (omap-mcbsp-dai.id  omap-mcbsp.id). Please explain if this
what is expected?


We still need to modify the ASoC drivers to make use of this platform data,
but
at least we are going to keep the door open for others to use the McBSP
ports
for other than audio.


Agreed. But the current omap-mcbsp driver cannot work standalone for
OMAP3/4 due to the issues stated below:
1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
are limited to 32-bit data accesses and hence poll mode would not work [x].
2. DMA transfers would also not work as it requires a patch similar to [y].

Patches [x]  [y] were rejected as there are no users other than asoc.
If it is not agreed to move omap-mcbsp driver to asoc layer, we need to
get the omap-mcbsp driver working as a standalone driver. Otherwise it
is of no use keeping the mcbsp driver in plat-omap.

Once [x]  [y] patches are upstreamed, audio layer needs to be modified
to make use of omap-mcbsp APIs rather than Audio layer calling dma
APIs directly to transfer data.

Coming back to the original question. Either we need to fix the broken
legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
layer. What do you say?

[x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19531.html
[y] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg04085.html



2. Sidetone feature is available only in OMAP3 (McBSP23) which has
different base address and sys configs compared to it's mcbsp port.
Hence the mcbsp is considered as a single device with two hwmods
for McBSP23 devices in OMAP3.


Sounds fair enough.


Thanks.




3. Autoidle needs to be disabled for sidetone before enabling the

sidetone

feature. There was a design proposed by Kishon [2] to add an API in

hwmod

to modify the autoidle bit but was not agreed upon. How do we handle

this

situation where the device has to disable or enable the autoidle bit at
runtime?


Yeah, this is really annoying problem. The McBSP ST should block autoidle
from
McBSP side, but it does not.
If you can not get through the proposed API, we should consider to switch
the
corresponding McBSP port to NoIdle, when the ST is in use (and restore the
idle
mode, when the ST has been disabled).
When McBSP is in NoIdle the interface clock is not going to be gated, so
ST
block will be running without a problem (ST needs the iface clock for
operation)

What do you think?


I

RE: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-08 Thread Varadarajan, Charulatha 


 -Original Message-
 From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com]
 Sent: Wednesday, October 06, 2010 12:47 PM
 To: Varadarajan, Charulatha
 Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; Kamat,
 Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam;
 jhnik...@gmail.com; broo...@opensource.wolfsonmicro.com; ABRAHAM, KISHON
 VIJAY
 Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx
 devices
 
 Hello,

Thanks for the quick response.

 
 On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:
  This patch series is targeted to implement mcbsp driver in
  hwmod way and to make use of pm_runtime APIs.
 
  This patch series is tested on OMAP3  4 and yet to be tested
  on OMAP2.
 
  There are few clarifications required so that the next patch series
  can be implemented after aligning.
 
  1. Audio layer is making use of mcbsp and it's dma base addresses and
  is closely coupled with omap-mcbsp.
  This can be handled either by
  a. providing an API with which Audio layer can get these addresses.
  (or)
  b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
  [1]
 
  Option (a) would only be a workaround to handle the situation. As
  audio is the only user for mcbsp, option (b) is better. If option(b)
  is agreed upon, the same can be addressed on top of the mcbsp hwmod
  series.
 
 it is true that at the moment only audio is using the McBSP ports, but
 McBSP is
 really flexible, it can run for example in SPI mode, and it can be
 configured to
 use other serial protocols.

Yes.

 I would go with option c.
 Since ASoC is moving to multi-component (the conversion is already in
 linux-
 next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are
 platform drivers.
 So if the plat-omap/mcbsp would register the platform device for McBSP
 clients
 (we have only ASoC client at the moment), and use platform data to pass
 the
 needed information to the McBSP client driver, than we do not need new API.

Sorry I am confused.

With hwmod implementation, there is a device register code for mcbsp
devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
address, dma info are not part of pdata and are available to the driver
only after probe. I do not understand how the multi-component design in
ASOC can avoid the new API.

Also with this multi-component approach in ASOC, two device
registrations happens for a single mcbsp device with two different
rames (omap-mcbsp-dai.id  omap-mcbsp.id). Please explain if this
what is expected?

 We still need to modify the ASoC drivers to make use of this platform data,
 but
 at least we are going to keep the door open for others to use the McBSP
 ports
 for other than audio.

Agreed. But the current omap-mcbsp driver cannot work standalone for
OMAP3/4 due to the issues stated below:
1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
are limited to 32-bit data accesses and hence poll mode would not work [x].
2. DMA transfers would also not work as it requires a patch similar to [y].

Patches [x]  [y] were rejected as there are no users other than asoc.
If it is not agreed to move omap-mcbsp driver to asoc layer, we need to
get the omap-mcbsp driver working as a standalone driver. Otherwise it
is of no use keeping the mcbsp driver in plat-omap.

Once [x]  [y] patches are upstreamed, audio layer needs to be modified
to make use of omap-mcbsp APIs rather than Audio layer calling dma
APIs directly to transfer data.

Coming back to the original question. Either we need to fix the broken
legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
layer. What do you say?

[x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19531.html
[y] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg04085.html
 
  2. Sidetone feature is available only in OMAP3 (McBSP23) which has
  different base address and sys configs compared to it's mcbsp port.
  Hence the mcbsp is considered as a single device with two hwmods
  for McBSP23 devices in OMAP3.
 
 Sounds fair enough.

Thanks.

 
  3. Autoidle needs to be disabled for sidetone before enabling the
 sidetone
  feature. There was a design proposed by Kishon [2] to add an API in
 hwmod
  to modify the autoidle bit but was not agreed upon. How do we handle
 this
  situation where the device has to disable or enable the autoidle bit at
  runtime?
 
 Yeah, this is really annoying problem. The McBSP ST should block autoidle
 from
 McBSP side, but it does not.
 If you can not get through the proposed API, we should consider to switch
 the
 corresponding McBSP port to NoIdle, when the ST is in use (and restore the
 idle
 mode, when the ST has been disabled).
 When McBSP is in NoIdle the interface clock is not going to be gated, so
 ST
 block will be running without a problem (ST needs the iface clock for
 operation)
 
 What do you

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-08 Thread Cousson, Benoit 

Hi Charu,

On 10/8/2010 8:20 AM, Varadarajan, Charulatha wrote:




From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com]
Sent: Wednesday, October 06, 2010 12:47 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; Kamat,
Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam;
jhnik...@gmail.com; broo...@opensource.wolfsonmicro.com; ABRAHAM, KISHON
VIJAY
Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx
devices

Hello,


Thanks for the quick response.



On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:

This patch series is targeted to implement mcbsp driver in
hwmod way and to make use of pm_runtime APIs.

This patch series is tested on OMAP3  4 and yet to be tested
on OMAP2.

There are few clarifications required so that the next patch series
can be implemented after aligning.

1. Audio layer is making use of mcbsp and it's dma base addresses and
is closely coupled with omap-mcbsp.
This can be handled either by
a. providing an API with which Audio layer can get these addresses.
(or)
b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
[1]

Option (a) would only be a workaround to handle the situation. As
audio is the only user for mcbsp, option (b) is better. If option(b)
is agreed upon, the same can be addressed on top of the mcbsp hwmod
series.


it is true that at the moment only audio is using the McBSP ports, but
McBSP is
really flexible, it can run for example in SPI mode, and it can be
configured to
use other serial protocols.


Yes.


I would go with option c.
Since ASoC is moving to multi-component (the conversion is already in
linux-
next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are
platform drivers.
So if the plat-omap/mcbsp would register the platform device for McBSP
clients
(we have only ASoC client at the moment), and use platform data to pass
the
needed information to the McBSP client driver, than we do not need new API.


Sorry I am confused.

With hwmod implementation, there is a device register code for mcbsp
devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
address, dma info are not part of pdata and are available to the driver
only after probe. I do not understand how the multi-component design in
ASOC can avoid the new API.

Also with this multi-component approach in ASOC, two device
registrations happens for a single mcbsp device with two different
rames (omap-mcbsp-dai.id  omap-mcbsp.id). Please explain if this
what is expected?


We still need to modify the ASoC drivers to make use of this platform data,
but
at least we are going to keep the door open for others to use the McBSP
ports
for other than audio.


Agreed. But the current omap-mcbsp driver cannot work standalone for
OMAP3/4 due to the issues stated below:
1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
are limited to 32-bit data accesses and hence poll mode would not work [x].
2. DMA transfers would also not work as it requires a patch similar to [y].

Patches [x]  [y] were rejected as there are no users other than asoc.
If it is not agreed to move omap-mcbsp driver to asoc layer, we need to
get the omap-mcbsp driver working as a standalone driver. Otherwise it
is of no use keeping the mcbsp driver in plat-omap.

Once [x]  [y] patches are upstreamed, audio layer needs to be modified
to make use of omap-mcbsp APIs rather than Audio layer calling dma
APIs directly to transfer data.

Coming back to the original question. Either we need to fix the broken
legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
layer. What do you say?

[x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19531.html
[y] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg04085.html



2. Sidetone feature is available only in OMAP3 (McBSP23) which has
different base address and sys configs compared to it's mcbsp port.
Hence the mcbsp is considered as a single device with two hwmods
for McBSP23 devices in OMAP3.


Sounds fair enough.


Thanks.




3. Autoidle needs to be disabled for sidetone before enabling the

sidetone

feature. There was a design proposed by Kishon [2] to add an API in

hwmod

to modify the autoidle bit but was not agreed upon. How do we handle

this

situation where the device has to disable or enable the autoidle bit at
runtime?


Yeah, this is really annoying problem. The McBSP ST should block autoidle
from
McBSP side, but it does not.
If you can not get through the proposed API, we should consider to switch
the
corresponding McBSP port to NoIdle, when the ST is in use (and restore the
idle
mode, when the ST has been disabled).
When McBSP is in NoIdle the interface clock is not going to be gated, so
ST
block will be running without a problem (ST needs the iface clock for
operation)

What do you think?


I think it might not be possible to handle

RE: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-06 Thread Varadarajan, Charulatha 
 

 -Original Message-
 From: ABRAHAM, KISHON VIJAY 
 Sent: Tuesday, October 05, 2010 10:08 PM
 To: linux-omap@vger.kernel.org
 Cc: Kamat, Nishant; Varadarajan, Charulatha; ABRAHAM, KISHON 
 VIJAY; Datta, Shubhrajyoti; Basak, Partha
 Subject: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 
 2xxx devices
 

This patch series is targeted to implement mcbsp driver in
hwmod way and to make use of pm_runtime APIs.

This patch series is tested on OMAP3  4 and yet to be tested
on OMAP2.

There are few clarifications required so that the next patch series
can be implemented after aligning.

1. Audio layer is making use of mcbsp and it's dma base addresses and
is closely coupled with omap-mcbsp.
This can be handled either by
a. providing an API with which Audio layer can get these addresses.
(or)
b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
[1]

Option (a) would only be a workaround to handle the situation. As
audio is the only user for mcbsp, option (b) is better. If option(b)
is agreed upon, the same can be addressed on top of the mcbsp hwmod
series.

2. Sidetone feature is available only in OMAP3 (McBSP23) which has
different base address and sys configs compared to it's mcbsp port.
Hence the mcbsp is considered as a single device with two hwmods
for McBSP23 devices in OMAP3.

3. Autoidle needs to be disabled for sidetone before enabling the sidetone
feature. There was a design proposed by Kishon [2] to add an API in hwmod
to modify the autoidle bit but was not agreed upon. How do we handle this
situation where the device has to disable or enable the autoidle bit at
runtime?

[1] https://patchwork.kernel.org/patch/225582/
[2] https://patchwork.kernel.org/patch/134371/

We would resend the same patch series by including alsa mailing list
(alsa-de...@alsa-project.org)

snip--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-06 Thread Peter Ujfalusi 
Hello,

On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:
 This patch series is targeted to implement mcbsp driver in
 hwmod way and to make use of pm_runtime APIs.
 
 This patch series is tested on OMAP3  4 and yet to be tested
 on OMAP2.
 
 There are few clarifications required so that the next patch series
 can be implemented after aligning.
 
 1. Audio layer is making use of mcbsp and it's dma base addresses and
 is closely coupled with omap-mcbsp.
 This can be handled either by
 a. providing an API with which Audio layer can get these addresses.
 (or)
 b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
 [1]
 
 Option (a) would only be a workaround to handle the situation. As
 audio is the only user for mcbsp, option (b) is better. If option(b)
 is agreed upon, the same can be addressed on top of the mcbsp hwmod
 series.

it is true that at the moment only audio is using the McBSP ports, but McBSP is 
really flexible, it can run for example in SPI mode, and it can be configured 
to 
use other serial protocols.
I would go with option c.
Since ASoC is moving to multi-component (the conversion is already in linux-
next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are 
platform drivers.
So if the plat-omap/mcbsp would register the platform device for McBSP clients 
(we have only ASoC client at the moment), and use platform data to pass the 
needed information to the McBSP client driver, than we do not need new API.
We still need to modify the ASoC drivers to make use of this platform data, but 
at least we are going to keep the door open for others to use the McBSP ports 
for other than audio.

 2. Sidetone feature is available only in OMAP3 (McBSP23) which has
 different base address and sys configs compared to it's mcbsp port.
 Hence the mcbsp is considered as a single device with two hwmods
 for McBSP23 devices in OMAP3.

Sounds fair enough.
 
 3. Autoidle needs to be disabled for sidetone before enabling the sidetone
 feature. There was a design proposed by Kishon [2] to add an API in hwmod
 to modify the autoidle bit but was not agreed upon. How do we handle this
 situation where the device has to disable or enable the autoidle bit at
 runtime?

Yeah, this is really annoying problem. The McBSP ST should block autoidle from 
McBSP side, but it does not.
If you can not get through the proposed API, we should consider to switch the 
corresponding McBSP port to NoIdle, when the ST is in use (and restore the idle 
mode, when the ST has been disabled).
When McBSP is in NoIdle the interface clock is not going to be gated, so ST 
block will be running without a problem (ST needs the iface clock for operation)

What do you think?
 
 [1] https://patchwork.kernel.org/patch/225582/
 [2] https://patchwork.kernel.org/patch/134371/
 
 We would resend the same patch series by including alsa mailing list
 (alsa-de...@alsa-project.org)
 
 snip

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-06 Thread kishon 

Hi,

Next version of this patch series will have proper subject in it.

-Kishon

On Tuesday 05 October 2010 10:07 PM, ABRAHAM, KISHON VIJAY wrote:

From: Charulatha Vch...@ti.com

Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Cc: Partha Basakp-bas...@ti.com
---
  arch/arm/mach-omap2/omap_hwmod_2420_data.c |  125 +++
  arch/arm/mach-omap2/omap_hwmod_2430_data.c |  313 
  2 files changed, 438 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index adf6e36..289ef86 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -36,6 +36,8 @@ static struct omap_hwmod omap2420_iva_hwmod;
  static struct omap_hwmod omap2420_l3_main_hwmod;
  static struct omap_hwmod omap2420_l4_core_hwmod;
  static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_mcbsp1_hwmod;
+static struct omap_hwmod omap2420_mcbsp2_hwmod;

  /* L3 -  L4_CORE interface */
  static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -418,6 +420,127 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
 .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
  };

+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class omap2420_mcbsp_hwmod_class = {
+   .name = mcbsp,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2420_mcbsp1_irqs[] = {
+   { .name = tx, .irq = 59 },
+   { .name = rx, .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp1_sdma_chs[] = {
+   { .name = rx, .dma_req = 31 },
+   { .name = tx, .dma_req = 30 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp1_addrs[] = {
+   {
+   .pa_start   = 0x48074000,
+   .pa_end = 0x480740ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core -  mcbsp1 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp1 = {
+   .master =omap2420_l4_core_hwmod,
+   .slave  =omap2420_mcbsp1_hwmod,
+   .clk= mcbsp1_ick,
+   .addr   = omap2420_mcbsp1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_mcbsp1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp1_slaves[] = {
+omap2420_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap2420_mcbsp1_hwmod = {
+   .name   = mcbsp1,
+   .class  =omap2420_mcbsp_hwmod_class,
+   .mpu_irqs   = omap2420_mcbsp1_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_mcbsp1_irqs),
+   .sdma_reqs  = omap2420_mcbsp1_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap2420_mcbsp1_sdma_chs),
+   .main_clk   = mcbsp1_fck,
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+   },
+   },
+   .slaves = omap2420_mcbsp1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_mcbsp1_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2420_mcbsp2_irqs[] = {
+   { .name = tx, .irq = 62 },
+   { .name = rx, .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp2_sdma_chs[] = {
+   { .name = rx, .dma_req = 33 },
+   { .name = tx, .dma_req = 32 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp2_addrs[] = {
+   {
+   .pa_start   = 0x48076000,
+   .pa_end = 0x480760ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core -  mcbsp2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 = {
+   .master =omap2420_l4_core_hwmod,
+   .slave  =omap2420_mcbsp2_hwmod,
+   .clk= mcbsp2_ick,
+   .addr   = omap2420_mcbsp2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_mcbsp2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp2 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp2_slaves[] = {
+omap2420_l4_core__mcbsp2,
+};
+
+static struct omap_hwmod omap2420_mcbsp2_hwmod = {
+   .name   = mcbsp2,
+   .class  =omap2420_mcbsp_hwmod_class,
+   .mpu_irqs   = omap2420_mcbsp2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_mcbsp2_irqs),
+   .sdma_reqs  = omap2420_mcbsp2_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap2420_mcbsp2_sdma_chs),
+   .main_clk   = mcbsp2_fck,
+   .prcm   = {
+   .omap2 = {
+

[PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-05 Thread Kishon Vijay Abraham I 
From: Charulatha V ch...@ti.com

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Cc: Partha Basak p-bas...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  125 +++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  313 
 2 files changed, 438 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index adf6e36..289ef86 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -36,6 +36,8 @@ static struct omap_hwmod omap2420_iva_hwmod;
 static struct omap_hwmod omap2420_l3_main_hwmod;
 static struct omap_hwmod omap2420_l4_core_hwmod;
 static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_mcbsp1_hwmod;
+static struct omap_hwmod omap2420_mcbsp2_hwmod;
 
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -418,6 +420,127 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
 };
 
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class omap2420_mcbsp_hwmod_class = {
+   .name = mcbsp,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2420_mcbsp1_irqs[] = {
+   { .name = tx, .irq = 59 },
+   { .name = rx, .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp1_sdma_chs[] = {
+   { .name = rx, .dma_req = 31 },
+   { .name = tx, .dma_req = 30 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp1_addrs[] = {
+   {
+   .pa_start   = 0x48074000,
+   .pa_end = 0x480740ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp1 = {
+   .master = omap2420_l4_core_hwmod,
+   .slave  = omap2420_mcbsp1_hwmod,
+   .clk= mcbsp1_ick,
+   .addr   = omap2420_mcbsp1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_mcbsp1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp1_slaves[] = {
+   omap2420_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap2420_mcbsp1_hwmod = {
+   .name   = mcbsp1,
+   .class  = omap2420_mcbsp_hwmod_class,
+   .mpu_irqs   = omap2420_mcbsp1_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_mcbsp1_irqs),
+   .sdma_reqs  = omap2420_mcbsp1_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap2420_mcbsp1_sdma_chs),
+   .main_clk   = mcbsp1_fck,
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+   },
+   },
+   .slaves = omap2420_mcbsp1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_mcbsp1_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2420_mcbsp2_irqs[] = {
+   { .name = tx, .irq = 62 },
+   { .name = rx, .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp2_sdma_chs[] = {
+   { .name = rx, .dma_req = 33 },
+   { .name = tx, .dma_req = 32 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp2_addrs[] = {
+   {
+   .pa_start   = 0x48076000,
+   .pa_end = 0x480760ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core - mcbsp2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 = {
+   .master = omap2420_l4_core_hwmod,
+   .slave  = omap2420_mcbsp2_hwmod,
+   .clk= mcbsp2_ick,
+   .addr   = omap2420_mcbsp2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_mcbsp2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp2 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp2_slaves[] = {
+   omap2420_l4_core__mcbsp2,
+};
+
+static struct omap_hwmod omap2420_mcbsp2_hwmod = {
+   .name   = mcbsp2,
+   .class  = omap2420_mcbsp_hwmod_class,
+   .mpu_irqs   = omap2420_mcbsp2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_mcbsp2_irqs),
+   .sdma_reqs  = omap2420_mcbsp2_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap2420_mcbsp2_sdma_chs),
+   .main_clk   = mcbsp2_fck,
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_MCBSP2_SHIFT,
+