[alsa-devel] ASoC: SAMSUNG: About I2S_v4 support
Hello,
Could we please reach some agreement about the support of I2Sv4 block of S3C64XX and newer SoCs? Kindly express your opinion.
Otherwise, I am planning to re-factor(as and if needed) s3c-i2s-v2.c, s3c2412-i2s.c and s3c64xx-i2s.c and add a new s3c-i2s-v4.c to handle I2S_v4 controllers. Kindly ACK/NAK this idea if you are busy with other stuff and I am to start working on the issue.
Thanks.
On Wed, Mar 03, 2010 at 05:32:13PM +0900, jassi brar wrote:
Otherwise, I am planning to re-factor(as and if needed) s3c-i2s-v2.c, s3c2412-i2s.c and s3c64xx-i2s.c and add a new s3c-i2s-v4.c to handle I2S_v4 controllers.
As I've said when you've mentioned this in the past I'd prefer an explicit IISv4 driver (sharing most of the actual code with the core) since none of the Samsung documentation covers the IISv4 and IISv2 blocks as completely independant blocks. This would make it easier for people to find what they need to use.
Kindly ACK/NAK this idea if you are busy with other stuff and I am to start working on the issue.
Please also remember that we need to get the clock API changes to allow the driver to start. I've been chasing patches for these for the past couple of kernel releases but it's not ideal that I need to do this.
On Wed, Mar 3, 2010 at 6:54 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Mar 03, 2010 at 05:32:13PM +0900, jassi brar wrote:
Otherwise, I am planning to re-factor(as and if needed) s3c-i2s-v2.c, s3c2412-i2s.c and s3c64xx-i2s.c and add a new s3c-i2s-v4.c to handle I2S_v4 controllers.
As I've said when you've mentioned this in the past I'd prefer an explicit IISv4 driver (sharing most of the actual code with the core)
Of course, and that's what I intend to do while 're-factoring'.
Kindly ACK/NAK this idea if you are busy with other stuff and I am to start working on the issue.
Please also remember that we need to get the clock API changes to allow the driver to start. I've been chasing patches for these for the past couple of kernel releases but it's not ideal that I need to do this.
I guess whatever needs to be done for the release version, will be done. Though I am not sure if I should get into modifying s3c-clock support for the sake of s3c-audio.
On Wed, Mar 03, 2010 at 08:10:32PM +0900, jassi brar wrote:
On Wed, Mar 3, 2010 at 6:54 PM, Mark Brown
Please also remember that we need to get the clock API changes to allow the driver to start. I've been chasing patches for these for the past couple of kernel releases but it's not ideal that I need to do this.
I guess whatever needs to be done for the release version, will be done. Though I am not sure if I should get into modifying s3c-clock support for the sake of s3c-audio.
The stuff that needs doing is the really basic stuff like registering CLKAUDIO2 so the driver can request it, not any substantial refactoring of the clocking code.
On Wed, Mar 3, 2010 at 8:21 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Mar 03, 2010 at 08:10:32PM +0900, jassi brar wrote:
On Wed, Mar 3, 2010 at 6:54 PM, Mark Brown
Please also remember that we need to get the clock API changes to allow the driver to start. I've been chasing patches for these for the past couple of kernel releases but it's not ideal that I need to do this.
I guess whatever needs to be done for the release version, will be done. Though I am not sure if I should get into modifying s3c-clock support for the sake of s3c-audio.
The stuff that needs doing is the really basic stuff like registering CLKAUDIO2 so the driver can request it, not any substantial refactoring of the clocking code.
yeah, that's fine.
participants (2)
-
jassi brar -
Mark Brown