Re: [alsa-devel] [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
-----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 (McBSP2&3) 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 McBSP2&3 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-devel@alsa-project.org)
<<snip>>
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.
- 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.
- Sidetone feature is available only in OMAP3 (McBSP2&3) 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 McBSP2&3 devices in OMAP3.
Sounds fair enough.
- 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-devel@alsa-project.org)
<<snip>>
-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, October 06, 2010 12:47 PM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat, Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam; jhnikula@gmail.com; broonie@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.
- 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
- Sidetone feature is available only in OMAP3 (McBSP2&3) 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 McBSP2&3 devices in OMAP3.
Sounds fair enough.
Thanks.
- 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 this, as the clocks are the same for ST and mcbsp port. pm_runtime APIs are not called during ST enable/disable as clocks are already enabled while enabling mcbsp port. Hence the idle bit change cannot happen even if the oh->flags are modified runtime during ST enable/disable.
[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-devel@alsa-project.org)
<<snip>>
-- Péter
Hi Charu,
On 10/8/2010 8:20 AM, Varadarajan, Charulatha wrote:
From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, October 06, 2010 12:47 PM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat, Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam; jhnikula@gmail.com; broonie@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.
- 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:
- 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
- Sidetone feature is available only in OMAP3 (McBSP2&3) 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 McBSP2&3 devices in OMAP3.
Sounds fair enough.
Thanks.
- 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 this, as the clocks are the same for ST and mcbsp port. pm_runtime APIs are not called during ST enable/disable as clocks are already enabled while enabling mcbsp port. Hence the idle bit change cannot happen even if the oh->flags are modified runtime during ST enable/disable.
This is mainly because of the 2 hwmods for 1 device implementation, which make perfect sense in theory, but because of that bug, becomes tricky to handle it in the fmwk.
FYI, SDMA and MUSB are as well requiring some sysconfig change during runtime. So a couple of API will have to be implemented. I guess we don't have the choice. Now, it is just a matter of having the right implementation. I'll comment on that patch directly.
Benoit
[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-devel@alsa-project.org)
<<snip>>
-- Péter
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ping..
On Friday 08 October 2010 11:50 AM, Varadarajan, Charulatha wrote:
-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, October 06, 2010 12:47 PM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat, Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam; jhnikula@gmail.com; broonie@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.
- 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:
- 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
- Sidetone feature is available only in OMAP3 (McBSP2&3) 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 McBSP2&3 devices in OMAP3.
Sounds fair enough.
Thanks.
- 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 this, as the clocks are the same for ST and mcbsp port. pm_runtime APIs are not called during ST
enable/disable as clocks
are already enabled while enabling mcbsp port. Hence the idle bit
change cannot happen
even if the oh->flags are modified runtime during ST enable/disable.
[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-devel@alsa-project.org)
<<snip>>
-- Péter
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:
- 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.
- 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.
-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, October 13, 2010 2:02 PM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat, Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam; jhnikula@gmail.com; broonie@opensource.wolfsonmicro.com; ABRAHAM, KISHON VIJAY Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
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...
Thanks Peter.
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);
Agreed.
In this way we can keep the door open for other uses of McBSP if ever needed.
Okay.
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:
- 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.
Okay.
- 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?
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.
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.
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.
-- Péter
On Thu, 14 Oct 2010 20:21:15 +0530 "Varadarajan, Charulatha" charu@ti.com wrote:
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.
ASoC design allows to have other data movers (ASoC platfrom driver) also than SDMA only [1]. So tieing McBSP and DMA together means leaving out DSP<->McBSP<->Codec setup.
I think API between McBSP driver and client should deal only with port transfer setup and a layer above that should take care of data transfer setup and implement an use-case specific API. E.g. where ALSA is using continuous transmission from/to circular buffer some another use-case would need chained scatter-gather DMA transfers, PIO, etc.
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.
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.
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.
- 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.
participants (6)
-
Cousson, Benoit -
Jarkko Nikula -
kishon -
Mark Brown -
Peter Ujfalusi -
Varadarajan, Charulatha