The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
While here, fix a typo caused by recent commit (cf53756 - ASoC: davinci:
davinci-pcm does not need to be a plaform_driver)
Note:
DMA parameters (dma fifo offset) are not updated and will be done later.
Hebbar, Gururaja (3):
ASoC: Davinci: McASP: add support new McASP IP Variant
ASoC: Davinci: pcm: add support for sram-support-less platforms
ASoC: Davinci: evm: Fix typo in cpu dai name
.../bindings/sound/davinci-mcasp-audio.txt | 1 +
include/linux/platform_data/davinci_asp.h | 1 +
sound/soc/davinci/Kconfig | 5 ++
sound/soc/davinci/davinci-evm.c | 2 +-
sound/soc/davinci/davinci-mcasp.c | 71 ++++++++++++++++----
sound/soc/davinci/davinci-pcm.c | 8 ++
6 files changed, 74 insertions(+), 14 deletions(-)
The OMAP2+ variant of McASP is different from Davinci variant w.r.to
some register offset.
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
Note:
DMA parameters (dma fifo offset) are not updated and will be done later.
Signed-off-by: Hebbar, Gururaja <redacted>
---
:100644 100644 e6148ec... 374e145... M Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
:100644 100644 79c26aa... d0c5825... M include/linux/platform_data/davinci_asp.h
:100644 100644 c3eae1d... bb6ae9d... M sound/soc/davinci/davinci-mcasp.c
.../bindings/sound/davinci-mcasp-audio.txt | 1 +
include/linux/platform_data/davinci_asp.h | 1 +
sound/soc/davinci/davinci-mcasp.c | 71 ++++++++++++++++----
3 files changed, 60 insertions(+), 13 deletions(-)
OMAP2+ platforms (like TI81xx, AM33xx) uses davinci-pcm driver. SRAM is
not needed/used in EDMA transfers for audio on such platforms. However
they do not provide generic SRAM APIs (sram_alloc() and sram_free()). In
such cases the pcm driver cannot be used directly as it results in
compilation failure on OMAP2 platforms.
Fix this by providing a config option to indicate missing SRAM API
support. This config is enabled by default on Davinci platform so as to
not break existing platforms. For OMAP2+ platforms, the config is
disabled.
Signed-off-by: Hebbar, Gururaja <redacted>
---
:100644 100644 9e11a14... 328b463... M sound/soc/davinci/Kconfig
:100644 100644 93ea3bf... 7ac5a19... M sound/soc/davinci/davinci-pcm.c
sound/soc/davinci/Kconfig | 5 +++++
sound/soc/davinci/davinci-pcm.c | 8 ++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
@@ -676,7 +680,9 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream)ppcm=(substream->stream==SNDRV_PCM_STREAM_PLAYBACK)?&pcm_hardware_playback:&pcm_hardware_capture;+#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)allocate_sram(substream,params->sram_size,ppcm);+#endifsnd_soc_set_runtime_hwparams(substream,ppcm);/* ensure that buffer size is a multiple of period size */ret=snd_pcm_hw_constraint_integer(runtime,
Fix typo caused by recent commit (cf53756 - ASoC: davinci: davinci-pcm
does not need to be a plaform_driver)
Signed-off-by: Hebbar, Gururaja <redacted>
---
:100644 100644 ca2a547... 2864f24... M sound/soc/davinci/davinci-evm.c
sound/soc/davinci/davinci-evm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This is all basically OK but it seems like it'd be better if all these
dev->version checks were switch statements. That way when the hardware
designers get bored and add version 4 of the register map it'll slot in
naturally, and it'll be more clear what the code currently handles.
This is all basically OK but it seems like it'd be better if all these
dev->version checks were switch statements. That way when the hardware
designers get bored and add version 4 of the register map it'll slot in
naturally, and it'll be more clear what the code currently handles.
Ok I will update this. Since 3/3 is already accepted & I don?t see any reviews
for 2/3, I will only resend this patch (1/3). Is it ok?
On Fri, Aug 31, 2012 at 18:20:58, Hebbar, Gururaja wrote:
OMAP2+ platforms (like TI81xx, AM33xx) uses davinci-pcm driver. SRAM is
not needed/used in EDMA transfers for audio on such platforms. However
they do not provide generic SRAM APIs (sram_alloc() and sram_free()). In
such cases the pcm driver cannot be used directly as it results in
compilation failure on OMAP2 platforms.
Fix this by providing a config option to indicate missing SRAM API
support. This config is enabled by default on Davinci platform so as to
not break existing platforms. For OMAP2+ platforms, the config is
disabled.
Gentle ping. Is there any comments/review for this patch?
If not, can this be pulled in?
@@ -676,7 +680,9 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream)ppcm=(substream->stream==SNDRV_PCM_STREAM_PLAYBACK)?&pcm_hardware_playback:&pcm_hardware_capture;+#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)allocate_sram(substream,params->sram_size,ppcm);+#endifsnd_soc_set_runtime_hwparams(substream,ppcm);/* ensure that buffer size is a multiple of period size */ret=snd_pcm_hw_constraint_integer(runtime,
From: Mark Brown <hidden> Date: 2012-09-22 15:33:14
On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
+config SND_DAVINCI_HAVE_SRAM
+ bool
+ default y if ARCH_DAVINCI=y
+ default n if ARCH_OMAP=y
+
I've been sitting on this mostly since it seems like a step back from
multi-platform kernels (which is where we're trying to get to) and I've
been trying to decide what the best approach is. I'm thinking that we
do want a generic API for allocating this stuff, it's a fairly generic
feature (there's TCMs as well).
Adding ifdefs like this does just doesn't seem good.
On Sat, Sep 22, 2012 at 21:03:14, Mark Brown wrote:
On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
quoted
+config SND_DAVINCI_HAVE_SRAM
+ bool
+ default y if ARCH_DAVINCI=y
+ default n if ARCH_OMAP=y
+
I've been sitting on this mostly since it seems like a step back from
multi-platform kernels (which is where we're trying to get to) and I've
been trying to decide what the best approach is. I'm thinking that we
do want a generic API for allocating this stuff, it's a fairly generic
feature (there's TCMs as well).
Adding ifdefs like this does just doesn't seem good.
I have no knowledge about multi-platform builds yet.
Currently this driver is shared between OMAP & DaVinci and both of them
doesn't exist in single image build.
There was a effort done for this SRAM Consolidation [1] but it didn't progress.
Hence I took this approach as a time-being/workaround. This was we can get
affected platforms (like AM335x) get going/working.
[1]. http://patchwork.ozlabs.org/patch/104059/
Regards,
Gururaja
From: Mark Brown <hidden> Date: 2012-10-01 15:54:11
On Thu, Sep 27, 2012 at 06:57:49AM +0000, Hebbar, Gururaja wrote:
I have no knowledge about multi-platform builds yet.
Currently this driver is shared between OMAP & DaVinci and both of them
doesn't exist in single image build.
...due to issues like having compile time things selecting between the
platforms. In other words what these ifdefs would do is move us further
away from that goal rather than towards it as we should be doing.
There was a effort done for this SRAM Consolidation [1] but it didn't progress.
Hence I took this approach as a time-being/workaround. This was we can get
affected platforms (like AM335x) get going/working.
Looks like it just needs more people pushing it...
From: Peter Ujfalusi <hidden> Date: 2012-10-02 07:48:53
On 09/22/2012 06:33 PM, Mark Brown wrote:
On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
quoted
+config SND_DAVINCI_HAVE_SRAM
+ bool
+ default y if ARCH_DAVINCI=y
+ default n if ARCH_OMAP=y
+
I've been sitting on this mostly since it seems like a step back from
multi-platform kernels (which is where we're trying to get to) and I've
been trying to decide what the best approach is. I'm thinking that we
do want a generic API for allocating this stuff, it's a fairly generic
feature (there's TCMs as well).
Adding ifdefs like this does just doesn't seem good.
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
--
P?ter
From: Sekhar Nori <hidden> Date: 2012-10-02 08:37:20
Hi Mark,
On 9/22/2012 9:03 PM, Mark Brown wrote:
On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
quoted
+config SND_DAVINCI_HAVE_SRAM
+ bool
+ default y if ARCH_DAVINCI=y
+ default n if ARCH_OMAP=y
+
I've been sitting on this mostly since it seems like a step back from
multi-platform kernels (which is where we're trying to get to) and I've
been trying to decide what the best approach is. I'm thinking that we
do want a generic API for allocating this stuff, it's a fairly generic
feature (there's TCMs as well).
Adding ifdefs like this does just doesn't seem good.
How about converting to use genalloc instead of the DaVinci private SRAM
API and passing the pool to be used via platform data?
Matt Porter just used this approach to make the uio PRUSS driver usable
on both DaVinci and AM335x. It suffered from the exact same problem.
https://patchwork.kernel.org/patch/1522481/
Thanks,
Sekhar
From: Mark Brown <hidden> Date: 2012-10-02 09:37:53
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
Daniel
From: Sekhar Nori <hidden> Date: 2012-10-02 11:06:54
On 10/2/2012 4:03 PM, Daniel Mack wrote:
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Thanks,
Sekhar
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
Daniel
From: Matt Porter <hidden> Date: 2012-10-02 16:28:33
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
On 09/22/2012 06:33 PM, Mark Brown wrote:
quoted
On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
quoted
+config SND_DAVINCI_HAVE_SRAM
+ bool
+ default y if ARCH_DAVINCI=y
+ default n if ARCH_OMAP=y
+
I've been sitting on this mostly since it seems like a step back from
multi-platform kernels (which is where we're trying to get to) and I've
been trying to decide what the best approach is. I'm thinking that we
do want a generic API for allocating this stuff, it's a fairly generic
feature (there's TCMs as well).
Adding ifdefs like this does just doesn't seem good.
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
The driver is going to be used by both !DT and DT only platforms for a
while so DT-centric solutions just don't make sense. There's a clean way
to do this that was used for uio_pruss.c. When davinci is further along
on DT conversion we can make use of the devicetree-based generic sram
driver that's progressing along right now [1]. It needs some minor help
to allow specifying the gen_pool allocation order, but it will work
nicely for getting access to the right sram pool.
-Matt
[1] https://patchwork.kernel.org/patch/1421961/
From: Matt Porter <hidden> Date: 2012-10-02 16:30:00
On Tue, Oct 02, 2012 at 12:33:39PM +0200, Daniel Mack wrote:
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
I already backed away from that idea since the older SoCs without a
FIFO absolutely need ping-pong buffering in SRAM.
-Matt
From: Matt Porter <hidden> Date: 2012-10-02 16:41:16
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata. Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
-Matt
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
A phandle is the cleanest way I think, yes.
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
Daniel
From: Matt Porter <hidden> Date: 2012-10-02 17:28:28
On Tue, Oct 02, 2012 at 06:50:14PM +0200, Daniel Mack wrote:
On 02.10.2012 18:41, Matt Porter wrote:
quoted
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
quoted
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
Ok. Also, as Sekhar pointed out, dmaengine itself isn't a blocker since
we can have AM33xx use the private EDMA API for ASoC until I finish
cyclic DMA support. Handling the ping-pong and normal case transparently
within the dmaengine driver will require a further look but at least
genalloc is our first step there.
-Matt
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
Thanks,
Daniel
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
quoted
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
When I started working on adding DT support to McASP driver, Matt Porter
EDMA port was not yet ready.
So
1. I took existing edma driver from AM335x Arago release [1] (driver + edma
device init).
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
3. Added DT support to McASP driver.
I tested this on AM335x EVM board.
Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.
If you need the code, I can share it as a patch (I will send the patch as a
private mail since the patch is huge).
Please do :) Or just push your entire tree somewhere.
Thanks,
Daniel
On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
On 03.10.2012 09:16, Hebbar, Gururaja wrote:
quoted
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
quoted
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
When I started working on adding DT support to McASP driver, Matt Porter
EDMA port was not yet ready.
So
1. I took existing edma driver from AM335x Arago release [1] (driver + edma
device init).
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
3. Added DT support to McASP driver.
I tested this on AM335x EVM board.
Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.
quoted
If you need the code, I can share it as a patch (I will send the patch as a
private mail since the patch is huge).
Please do :) Or just push your entire tree somewhere.
I have pushed the code at below git repo
Repo :https://github.com/hvaibhav/am335x-linux
Branch : am335x-upstream-staging-audio
This includes
1. (linux-next + AM335x patches)
2. McASP DT conversion
3. EDMA hack
4. AM335x audio specific DT blobs
5. Am335x dma DT blobs [hack]
Kindly let me know if you need any more details.
On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
quoted
On 03.10.2012 09:16, Hebbar, Gururaja wrote:
quoted
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
quoted
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
When I started working on adding DT support to McASP driver, Matt Porter
EDMA port was not yet ready.
So
1. I took existing edma driver from AM335x Arago release [1] (driver + edma
device init).
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
3. Added DT support to McASP driver.
I tested this on AM335x EVM board.
Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.
quoted
If you need the code, I can share it as a patch (I will send the patch as a
private mail since the patch is huge).
Please do :) Or just push your entire tree somewhere.
I have pushed the code at below git repo
Repo :https://github.com/hvaibhav/am335x-linux
Branch : am335x-upstream-staging-audio
This includes
1. (linux-next + AM335x patches)
2. McASP DT conversion
3. EDMA hack
4. AM335x audio specific DT blobs
5. Am335x dma DT blobs [hack]
Ha, that 5th point was what I was missing, in particular these DMA
offset matching bits. Thanks a lot! I'll get back to you soon with some
patches for the mcasp driver.
Daniel
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
quoted
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
A phandle is the cleanest way I think, yes.
quoted
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-davinci-pass-SRAM-gen_pool-to-mcasp-platform-dat.patch
Type: text/x-patch
Size: 8048 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/c5c4e92c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ALSA-ASoC-McASP-use-gen_pool-from-platform-data.patch
Type: text/x-patch
Size: 4201 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/c5c4e92c/attachment-0003.bin>
From: Porter, Matt <hidden> Date: 2012-10-04 09:38:40
On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
On 02.10.2012 18:50, Daniel Mack wrote:
quoted
On 02.10.2012 18:41, Matt Porter wrote:
quoted
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
quoted
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
A phandle is the cleanest way I think, yes.
quoted
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).
I put a series together yesterday, just ran out of time to post
last night after testing. I'm posting that now...it's on top of my
uio_pruss/genalloc series and only addresss switching davinci-pcm to
genalloc (and actually enabling ping-pon from sram).
I'll take a look a your OMAP patches.
-Matt
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
quoted
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
A phandle is the cleanest way I think, yes.
quoted
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).
I put a series together yesterday, just ran out of time to post
last night after testing. I'm posting that now...it's on top of my
uio_pruss/genalloc series and only addresss switching davinci-pcm to
genalloc (and actually enabling ping-pon from sram).
Ok, I don't care which version makes it in after all :)
I'll take a look a your OMAP patches.
The patches I just sent out are only for Davinci and change the SRAM
functions to genalloc in the mcasp driver. They work just fine on OMAP
of course, as the code is disabled in there.
Daniel
From: Matt Porter <hidden> Date: 2012-10-04 10:28:19
On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote:
On 04.10.2012 11:38, Porter, Matt wrote:
quoted
On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
quoted
On 02.10.2012 18:50, Daniel Mack wrote:
quoted
On 02.10.2012 18:41, Matt Porter wrote:
quoted
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
quoted
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
A phandle is the cleanest way I think, yes.
quoted
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).
I put a series together yesterday, just ran out of time to post
last night after testing. I'm posting that now...it's on top of my
uio_pruss/genalloc series and only addresss switching davinci-pcm to
genalloc (and actually enabling ping-pon from sram).
Ok, I don't care which version makes it in after all :)
Ok :)
quoted
I'll take a look a your OMAP patches.
The patches I just sent out are only for Davinci and change the SRAM
functions to genalloc in the mcasp driver. They work just fine on OMAP
of course, as the code is disabled in there.
Ok, same thing as I did and just sent out. These are tested on AM180x
and hook up ping-pong buffering so that there's actually one user of
all this ping-pong code. It's been sitting idle for a long time.
I didn't see your patches come by yet but will take a look to see if
we need to combine.
-Matt
On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote:
quoted
On 04.10.2012 11:38, Porter, Matt wrote:
quoted
On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
quoted
On 02.10.2012 18:50, Daniel Mack wrote:
quoted
On 02.10.2012 18:41, Matt Porter wrote:
quoted
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
quoted
On 02.10.2012 13:06, Sekhar Nori wrote:
quoted
On 10/2/2012 4:03 PM, Daniel Mack wrote:
quoted
On 02.10.2012 11:37, Mark Brown wrote:
quoted
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
quoted
I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.
That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms. The SRAM code needs to move to a standard API.
What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.
Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.
We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata.
I thought about this too, as mmp does it that way.
quoted
Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
A phandle is the cleanest way I think, yes.
quoted
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).
I put a series together yesterday, just ran out of time to post
last night after testing. I'm posting that now...it's on top of my
uio_pruss/genalloc series and only addresss switching davinci-pcm to
genalloc (and actually enabling ping-pon from sram).
Ok, I don't care which version makes it in after all :)
Ok :)
quoted
quoted
I'll take a look a your OMAP patches.
The patches I just sent out are only for Davinci and change the SRAM
functions to genalloc in the mcasp driver. They work just fine on OMAP
of course, as the code is disabled in there.
Ok, same thing as I did and just sent out. These are tested on AM180x
and hook up ping-pong buffering so that there's actually one user of
all this ping-pong code. It's been sitting idle for a long time.
I didn't see your patches come by yet but will take a look to see if
we need to combine.
I attached them to my mail for a quick review. I wanted to queue them up
to a bigger series I'll send out later ...
Daniel
From: Matt Porter <hidden> Date: 2012-10-04 19:50:26
On Wed, Oct 03, 2012 at 04:07:41PM +0200, Daniel Mack wrote:
On 03.10.2012 14:57, Hebbar, Gururaja wrote:
quoted
On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
quoted
On 03.10.2012 09:16, Hebbar, Gururaja wrote:
quoted
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
quoted
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
When I started working on adding DT support to McASP driver, Matt Porter
EDMA port was not yet ready.
So
1. I took existing edma driver from AM335x Arago release [1] (driver + edma
device init).
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
3. Added DT support to McASP driver.
I tested this on AM335x EVM board.
Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.
quoted
If you need the code, I can share it as a patch (I will send the patch as a
private mail since the patch is huge).
Please do :) Or just push your entire tree somewhere.
I have pushed the code at below git repo
Repo :https://github.com/hvaibhav/am335x-linux
Branch : am335x-upstream-staging-audio
This includes
1. (linux-next + AM335x patches)
2. McASP DT conversion
3. EDMA hack
4. AM335x audio specific DT blobs
5. Am335x dma DT blobs [hack]
Ha, that 5th point was what I was missing, in particular these DMA
offset matching bits. Thanks a lot! I'll get back to you soon with some
patches for the mcasp driver.
You should be able to replace #3 with https://lkml.org/lkml/2012/9/20/275
The intention is for McASP to use the private EDMA API on both DaVinci
and AM33xx until the dmaengine conversion of McASP is ready.
-Matt
On Wed, Oct 3, 2012 at 2:57 PM, Hebbar, Gururaja [off-list ref] wrote:
On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
quoted
On 03.10.2012 09:16, Hebbar, Gururaja wrote:
quoted
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
quoted
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
"ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.
Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?
Note that I'm using your patches together with Matt's from this series:
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
... but it doesn't work without those either.
When I started working on adding DT support to McASP driver, Matt Porter
EDMA port was not yet ready.
So
1. I took existing edma driver from AM335x Arago release [1] (driver + edma
device init).
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
3. Added DT support to McASP driver.
I tested this on AM335x EVM board.
Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.
quoted
If you need the code, I can share it as a patch (I will send the patch as a
private mail since the patch is huge).
Please do :) Or just push your entire tree somewhere.
I have pushed the code at below git repo
Repo :https://github.com/hvaibhav/am335x-linux
Branch : am335x-upstream-staging-audio
This includes
1. (linux-next + AM335x patches)
2. McASP DT conversion
3. EDMA hack
4. AM335x audio specific DT blobs
5. Am335x dma DT blobs [hack]
Kindly let me know if you need any more details.
What can be expected in 3.8? And what will have to wait for 3.9?
Yegor
Yegor,
On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote:
On Wed, Oct 3, 2012 at 2:57 PM, Hebbar, Gururaja [off-list ref] wrote:
quoted
On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
quoted
On 03.10.2012 09:16, Hebbar, Gururaja wrote:
quoted
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
quoted
On 31.08.2012 14:50, Hebbar, Gururaja wrote:
quoted
The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support
..snip..
..snip..
quoted
quoted
Please do :) Or just push your entire tree somewhere.
I have pushed the code at below git repo
Repo :https://github.com/hvaibhav/am335x-linux
Branch : am335x-upstream-staging-audio
This includes
1. (linux-next + AM335x patches)
2. McASP DT conversion
3. EDMA hack
4. AM335x audio specific DT blobs
5. Am335x dma DT blobs [hack]
Kindly let me know if you need any more details.
What can be expected in 3.8?
1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion
& McASP pinctrl support is yet to be accepted. I sent a patch recently and
waiting for feedback.
And what will have to wait for 3.9?
AFAIK
1. EDMA port for McASP driver
2. AM335x support on Davinci ASoC (Kconfig & makefile)
3. DT blobs for Audio modules on AM335x (am335x-evm.dts & am33xx.dtsi)
From: Mark Brown <hidden> Date: 2012-11-26 11:35:21
On Mon, Nov 26, 2012 at 11:32:49AM +0000, Hebbar, Gururaja wrote:
On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote:
quoted
What can be expected in 3.8?
1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion
& McASP pinctrl support is yet to be accepted. I sent a patch recently and
waiting for feedback.
On Mon, Nov 26, 2012 at 17:05:21, Mark Brown wrote:
On Mon, Nov 26, 2012 at 11:32:49AM +0000, Hebbar, Gururaja wrote:
quoted
On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote:
quoted
quoted
What can be expected in 3.8?
quoted
1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion
& McASP pinctrl support is yet to be accepted. I sent a patch recently and
waiting for feedback.
I don't have anything in my review queue, please post patches if you
want them reviewed.