[alsa-devel] WL1273 FM Radio driver...
Hello
I have been trying to get the WL1273 FM radio driver into the kernel for some time. It has been kind of difficult, one of the reasons is that I didn't realize I should have tried to involve all relevant maintainers to the discussion form the beginning (AsoC, Media and MFD). At Mark's suggestion I'm trying to reopen the discussion now.
The driver consists of an MFD core and two child drivers (the audio codec and the V4L2 driver). And the question is mainly about the role of the MFD driver: the original design had the IO functions in the core. Currently the core is practically empty mainly because Mauro very strongly wanted to have “everything” in the V4L2 driver.
I liked the original design because it didn't have the bug that the current MFD has: the codec can be initialized before the V4L2 part sets the IO function pointers. Having in principle equally capable interface drivers is symmetrical and esthetically pleasing:-) Also somebody could easily leave out the existing interfaces and create a completely new one based for example to sysfs or something... Having the IO in the core would also conveniently hide the physical communication layer and make it easy to change I2C to UART, which is also supported by the chip.
Thanks, Matti
On Tue, Jan 18, 2011 at 05:04:23PM +0200, Matti J. Aaltonen wrote:
The driver consists of an MFD core and two child drivers (the audio codec and the V4L2 driver). And the question is mainly about the role of the MFD driver: the original design had the IO functions in the core. Currently the core is practically empty mainly because Mauro very strongly wanted to have “everything” in the V4L2 driver.
I liked the original design because it didn't have the bug that the current MFD has: the codec can be initialized before the V4L2 part sets the IO function pointers. Having in principle equally capable interface drivers is symmetrical and esthetically pleasing:-) Also somebody could easily leave out the existing interfaces and create a completely new one based for example to sysfs or something... Having the IO in the core would also conveniently hide the physical communication layer and make it easy to change I2C to UART, which is also supported by the chip.
The above pattern with the core taking responsibility for register I/O is used by all the other MFD drivers in part because it's much less fragile against initialisation ordering issues. It ensures that before any subdevices can instantiate and try to do register I/O all the infrastructure required to do that is present. Is there any great reason for following a different pattern, and if we are going to do so how do we deal with the init ordering?
Hi Matti,
On Tue, Jan 18, 2011 at 05:04:23PM +0200, Matti J. Aaltonen wrote:
Hello
I have been trying to get the WL1273 FM radio driver into the kernel for some time. It has been kind of difficult, one of the reasons is that I didn't realize I should have tried to involve all relevant maintainers to the discussion form the beginning (AsoC, Media and MFD). At Mark's suggestion I'm trying to reopen the discussion now.
The driver consists of an MFD core and two child drivers (the audio codec and the V4L2 driver). And the question is mainly about the role of the MFD driver: the original design had the IO functions in the core. Currently the core is practically empty mainly because Mauro very strongly wanted to have “everything” in the V4L2 driver.
What was Mauro main concerns with having the IO part in the core ? A lot of MFD drivers are going that path already.
Cheers, Samuel.
Em 30-01-2011 21:23, Samuel Ortiz escreveu:
Hi Matti,
On Tue, Jan 18, 2011 at 05:04:23PM +0200, Matti J. Aaltonen wrote:
Hello
I have been trying to get the WL1273 FM radio driver into the kernel for some time. It has been kind of difficult, one of the reasons is that I didn't realize I should have tried to involve all relevant maintainers to the discussion form the beginning (AsoC, Media and MFD). At Mark's suggestion I'm trying to reopen the discussion now.
The driver consists of an MFD core and two child drivers (the audio codec and the V4L2 driver). And the question is mainly about the role of the MFD driver: the original design had the IO functions in the core. Currently the core is practically empty mainly because Mauro very strongly wanted to have “everything” in the V4L2 driver.
What was Mauro main concerns with having the IO part in the core ? A lot of MFD drivers are going that path already.
My concerns is that the V4L2-specific part of the code should be at drivers/media. I prefer that the specific MFD I/O part to be at drivers/mfd, just like the other drivers.
Cheers, Mauro
On Wed, Feb 02, 2011 at 01:35:01PM -0200, Mauro Carvalho Chehab wrote:
[Reflowed into 80 columns.]
My concerns is that the V4L2-specific part of the code should be at drivers/media. I prefer that the specific MFD I/O part to be at drivers/mfd, just like the other drivers.
Currently that's not the case - the I/O functionality is not in any meaningful sense included in the MFD, it's provided by the V4L portion.
Hi Mauro,
On Wed, Feb 02, 2011 at 01:35:01PM -0200, Mauro Carvalho Chehab wrote:
Em 30-01-2011 21:23, Samuel Ortiz escreveu:
Hi Matti,
On Tue, Jan 18, 2011 at 05:04:23PM +0200, Matti J. Aaltonen wrote:
Hello
I have been trying to get the WL1273 FM radio driver into the kernel for some time. It has been kind of difficult, one of the reasons is that I didn't realize I should have tried to involve all relevant maintainers to the discussion form the beginning (AsoC, Media and MFD). At Mark's suggestion I'm trying to reopen the discussion now.
The driver consists of an MFD core and two child drivers (the audio codec and the V4L2 driver). And the question is mainly about the role of the MFD driver: the original design had the IO functions in the core. Currently the core is practically empty mainly because Mauro very strongly wanted to have “everything” in the V4L2 driver.
What was Mauro main concerns with having the IO part in the core ? A lot of MFD drivers are going that path already.
My concerns is that the V4L2-specific part of the code should be at drivers/media. I prefer that the specific MFD I/O part to be at drivers/mfd, just like the other drivers.
Agreed, but it seems that's not the case currently. Would you be ok with Matti refactoring those 2 drivers a bit so that the actual core I/O parts should be handled by the MFD driver ?
Cheers, Samuel.
participants (4)
-
Mark Brown -
Matti J. Aaltonen -
Mauro Carvalho Chehab -
Samuel Ortiz