Re: [alsa-devel] WL1273 FM Radio driver...
Hello.
Mark Brown wrote:
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.
I've been away for two and a half weeks so I haven't been able to comment...
But before I start to make changes, I'd still like to ask for a comment on my original plan, which was to have the I/O functions in the MFD driver and also have there things like interrupt handling etc.
My vision was that the MFD part would have the application logic and the child drivers would be just true interfaces to the core functionality, because I kind of saw the children to be of equal importance and because the codec and the v4l2 driver share some controls like for example the volume control.
If you'd care to take a look an earlier version of the MFD driver here:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/2360...
So the question is if I put only the I/O stuff into the MFD driver or can I have the other application logic there as well?
Thanks, Matti
Em 07-02-2011 08:52, Matti J. Aaltonen escreveu:
Hello.
Mark Brown wrote:
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.
I've been away for two and a half weeks so I haven't been able to comment...
But before I start to make changes, I'd still like to ask for a comment on my original plan, which was to have the I/O functions in the MFD driver and also have there things like interrupt handling etc.
My vision was that the MFD part would have the application logic and the child drivers would be just true interfaces to the core functionality, because I kind of saw the children to be of equal importance and because the codec and the v4l2 driver share some controls like for example the volume control.
If you'd care to take a look an earlier version of the MFD driver here:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/2360...
So the question is if I put only the I/O stuff into the MFD driver or can I have the other application logic there as well?
Matti,
Things that are required in order to access the device via MFD should be at the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
One example that you could as reference for the mfd/media is the Timeberdale driver. The MFD-specific part is at: drivers/mfd/timberdale.c
The media part is at: drivers/media/video/timblogiw.c
All you'll see at the MFD part is the logic to access the MFD bus and a description of the devices that will be coupled into it (in this case, it is a multi-function board). In other words, I/O control and the needed glue to access the I2C devices. All logic required to control the media driver is at timblogiw.c.
I hope that helps.
Thanks, Mauro
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Em 07-02-2011 10:02, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Not sure if I understood your comments. Several media drivers have alsa drivers: saa7134, em28xx, cx231xx, etc. The audio drivers for them are also under /drivers/media, as it is not easy to de-couple audio and video/radio part on those devices. For bttv and some USB boards (that use snd-usb-audio), the audio part is at /sound, as the audio part on them are independent and don't need to share anything, as audio is provided by a completely independent group of registers.
I suggest to use the same logic for wl1273.
Cheers, Mauro.
On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 10:02, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Not sure if I understood your comments. Several media drivers have alsa drivers:
There is an audio driver for this chip and it is using those functions.
Em 07-02-2011 11:10, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 10:02, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Not sure if I understood your comments. Several media drivers have alsa drivers:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
Mauro
On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 11:10, Mark Brown escreveu:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?).
Note that due to the decomposed nature of embedded audio hardware the audio part of the chip needs to be represended within the audio subsystem even if the control were all in the media side - this isn't an isolated bit of hardware on an expansion card, it's fairly tightly coupled into the rest of the system.
On Mon, 2011-02-07 at 13:52 +0000, ext Mark Brown wrote:
On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 11:10, Mark Brown escreveu:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?).
Yes, nothing's been merged yet. There are only dependencies between the parts of this driver... I cannot comment on upcoming boards, I just hope we could agree on a sensible structure for this thing.
Matti.
Em 07-02-2011 12:17, Matti J. Aaltonen escreveu:
On Mon, 2011-02-07 at 13:52 +0000, ext Mark Brown wrote:
On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 11:10, Mark Brown escreveu:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?).
Yes, nothing's been merged yet. There are only dependencies between the parts of this driver... I cannot comment on upcoming boards, I just hope we could agree on a sensible structure for this thing.
We don't need any brand names or specific details, but it would be good to have an overview, in general lines, about the architecture, in order to help you to map how this would fit. In particular, the architecturre of things that are tightly coupled and can't be splitted by some bus abstraction.
Mauro.
Hi,
On 02/07/11 18:00, ext Mauro Carvalho Chehab wrote:
We don't need any brand names or specific details, but it would be good to have an overview, in general lines, about the architecture, in order to help you to map how this would fit. In particular, the architecturre of things that are tightly coupled and can't be splitted by some bus abstraction.
The wl1273 as such is designed for embedded systems. It can be connected in several ways to the system: - analog only In this way the RX/TX is connected to some codec's Line IN/OUT For this to work, we don't need any audio driver for the FM chip (basically the same configuration as rx51 has in regards of FM radio)
- Digital interfaces The I2S lines are connected to the main processor. In this way the wl1273 acts as a codec. In order to provide platform independent driver we need to use ASoC framework. ASoC have broad main processor side support, and it is easy to switch the arch, if we have proper ASoC codec driver for the wl1273. It is also better to keep the codec implementation under sound/soc/codecs.
I have not looked deeply into the wl1273 datasheets, but I'm sure there's a way to nicely divide the parts between the MFD, V4L, and ASoC.
The wl1273 as such is designed for embedded systems. It can be connected in several ways to the system:
- analog only
In this way the RX/TX is connected to some codec's Line IN/OUT For this to work, we don't need any audio driver for the FM chip (basically the same configuration as rx51 has in regards of FM radio)
- Digital interfaces
The I2S lines are connected to the main processor. In this way the wl1273 acts as a codec. In order to provide platform independent driver we need to use ASoC framework. ASoC have broad main processor side support, and it is easy to switch the arch, if we have proper ASoC codec driver for the wl1273. It is also better to keep the codec implementation under sound/soc/codecs.
2 Digital interfaces are possible for FM WL1273: - the external connection: the I2S lines are used for the FM PCM samples - the internal connection: the BT PCM interface is used for the FM PCM samples For both configuration we have a set of HCI commands to configure the FM audio path and one of my concerns is to know if the wl1273_codec should handle the audio path configuration and the switch between FM and BT SCO?
I have not looked deeply into the wl1273 datasheets, but I'm sure there's a way to nicely divide the parts between the MFD, V4L, and ASoC.
-- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On 02/08/11 12:09, ext Bensaid, Selma wrote:
2 Digital interfaces are possible for FM WL1273:
- the external connection: the I2S lines are used for the FM PCM samples
- the internal connection: the BT PCM interface is used for the FM PCM samples
Yes, that is correct, I just did not wanted to go into details. Currently the ASoC codec driver only supports the BT/FM PCM interface. Adding the dedicated I2S interface for the FM radio should not be a big effort, we just need to add another dai to the codec driver, and connect that to the host processor. As I said before, we only implemented the BT/FM PCM interface support, since we do not have HW, where we could verify the dedicated FM I2S lines. But adding the support should not be a big deal IMHO (and can be done even without any means of testing it).
For both configuration we have a set of HCI commands to configure the FM audio path and one of my concerns is to know if the wl1273_codec should handle the audio path configuration and the switch between FM and BT SCO?
It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way.
For both configuration we have a set of HCI commands to configure the FM
audio
path and one of my concerns is to know if the wl1273_codec should handle the
audio path configuration
and the switch between FM and BT SCO?
It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way.
If we use the Combined Interface Mode (host controls both the BT and FM radio via BT HCI) this could be possible. However, you use the Separate Interface (FM controlled vi I2C). Is there a plan to handle also the Combined Interface Mode for WL1273 FM Radio driver?
Selma.
-- Péter
--------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Tue, 2011-02-08 at 13:47 +0000, ext Bensaid, Selma wrote:
For both configuration we have a set of HCI commands to configure the FM
audio
path and one of my concerns is to know if the wl1273_codec should handle the
audio path configuration
and the switch between FM and BT SCO?
It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way.
If we use the Combined Interface Mode (host controls both the BT and FM radio via BT HCI) this could be possible. However, you use the Separate Interface (FM controlled vi I2C). Is there a plan to handle also the Combined Interface Mode for WL1273 FM Radio driver?
We haven't yet had need for the UART interface but it has been the idea to have them both eventually...
Cheers, Matti
Selma.
-- Péter
Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Tue, 2011-02-08 at 13:02 +0200, Peter Ujfalusi wrote:
For both configuration we have a set of HCI commands to configure the FM audio path and one of my concerns is to know if the wl1273_codec should handle the audio path configuration and the switch between FM and BT SCO?
It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way.
Yes, I would have done just that - and we talked a lot about it locally - if I had known how to do it. I started to work on it and also talked to some BT people but it didn't seem feasible at the time. Advice welcome of course...
Cheers, Matti
On Tue, 2011-02-08 at 13:02 +0200, Peter Ujfalusi wrote:
For both configuration we have a set of HCI commands to configure the FM
audio
path and one of my concerns is to know if the wl1273_codec should handle
the audio path configuration
and the switch between FM and BT SCO?
It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way.
Yes, I would have done just that - and we talked a lot about it locally
- if I had known how to do it. I started to work on it and also talked
to some BT people but it didn't seem feasible at the time. Advice welcome of course...
Cheers, Matti
Hi, Below the set of HCI commands that we have identified to configure the FM and BT SCO audio paths: - External Audio Connection o START BT SCO Connection # BT audio Path PCM & FM audio Path I2S > hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 02 FF 00 00 00 00 # BT AUDIO Codec Configuration: MASTER > hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00
o STOP BT SCO Connection # BT AUDIO Codec Configuration: SLAVE > hcitool cmd 0x3F 0X106 00 03 01 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00
- Internal Audio Connection o START BT SCO Connection # BT audio Path PCM # FM audio Path None > hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 00 FF 00 00 00 00 # BT AUDIO Codec Configuration: MASTER > hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00
o STOP BT SCO Connection # BT audio Path None & FM audio Path None > hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 00 FF 00 00 00 00
o FM Audio Path configuration # BT audio Path None & FM audio Path PCM > hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 01 FF 00 00 00 00
Please note that the BT SCO Codec settings are platform specific. Selma.
--------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hello.
On Thu, 2011-02-10 at 09:35 +0000, ext Bensaid, Selma wrote:
On Tue, 2011-02-08 at 13:02 +0200, Peter Ujfalusi wrote:
For both configuration we have a set of HCI commands to configure the FM
audio
path and one of my concerns is to know if the wl1273_codec should handle
the audio path configuration
and the switch between FM and BT SCO?
It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way.
Yes, I would have done just that - and we talked a lot about it locally
- if I had known how to do it. I started to work on it and also talked
to some BT people but it didn't seem feasible at the time. Advice welcome of course...
Cheers, Matti
Hi, Below the set of HCI commands that we have identified to configure the FM and BT SCO audio paths:
External Audio Connection o START BT SCO Connection # BT audio Path PCM & FM audio Path I2S
hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 02 FF 00 00 00 00
# BT AUDIO Codec Configuration: MASTER
hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00
o STOP BT SCO Connection # BT AUDIO Codec Configuration: SLAVE
hcitool cmd 0x3F 0X106 00 03 01 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00
Internal Audio Connection o START BT SCO Connection # BT audio Path PCM # FM audio Path None
hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 00 FF 00 00 00 00
# BT AUDIO Codec Configuration: MASTER
hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00
o STOP BT SCO Connection # BT audio Path None & FM audio Path None
hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 00 FF 00 00 00 00
o FM Audio Path configuration # BT audio Path None & FM audio Path PCM
hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 01 FF 00 00 00 00
Please note that the BT SCO Codec settings are platform specific. Selma.
We know these messages, they are mentioned in the documentation and we use them already, but we send them from the user space. The problem is how to send the messages from the driver within the kernel.
Thanks, Matti
Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Thu, Feb 10, 2011 at 12:03:43PM +0200, Matti J. Aaltonen wrote:
We know these messages, they are mentioned in the documentation and we use them already, but we send them from the user space. The problem is how to send the messages from the driver within the kernel.
Set up a line discipline - it's not in principle that much different to what something like PPP is doing.
On Thu, 2011-02-10 at 11:02 +0000, ext Mark Brown wrote:
On Thu, Feb 10, 2011 at 12:03:43PM +0200, Matti J. Aaltonen wrote:
We know these messages, they are mentioned in the documentation and we use them already, but we send them from the user space. The problem is how to send the messages from the driver within the kernel.
Set up a line discipline - it's not in principle that much different to what something like PPP is doing.
I'll look into it.
But I got the following quick comment from a local BT expert: "No you cannot change line discipline if bt is already in use. And it's not uart interface but hci interface. uart can be replaced with sdio for example and you still have the same hci interface."
Thanks, Matti
On Thu, Feb 10, 2011 at 02:10:40PM +0200, Matti J. Aaltonen wrote:
But I got the following quick comment from a local BT expert: "No you cannot change line discipline if bt is already in use. And it's not uart interface but hci interface. uart can be replaced with sdio for example and you still have the same hci interface."
Yes, it only works when the device is idle - if your device needs to be shared with other bits of the system while doing this you'd need to present a virtual interface up the way.
On Thu, 2011-02-10 at 12:28 +0000, ext Mark Brown wrote:
On Thu, Feb 10, 2011 at 02:10:40PM +0200, Matti J. Aaltonen wrote:
But I got the following quick comment from a local BT expert: "No you cannot change line discipline if bt is already in use. And it's not uart interface but hci interface. uart can be replaced with sdio for example and you still have the same hci interface."
Yes, it only works when the device is idle - if your device needs to be shared with other bits of the system while doing this you'd need to present a virtual interface up the way.
And a comment to the above from the earlier mentioned local BT expert: "It would need some hack to generic hci code. Or maybe some kind of management api extension. That should be a few line only.. but getting it to upstream sounds like mission impossible."
On Thu, Feb 10, 2011 at 02:57:47PM +0200, Matti J. Aaltonen wrote:
And a comment to the above from the earlier mentioned local BT expert: "It would need some hack to generic hci code. Or maybe some kind of management api extension. That should be a few line only.. but getting it to upstream sounds like mission impossible."
I don't see any particular problem getting something like that upstream if it works over multiple devices; we've already got stuff like that for the Amstrad Delta platform.
On Tue, 2011-02-08 at 11:15 +0200, Peter Ujfalusi
I have not looked deeply into the wl1273 datasheets, but I'm sure there's a way to nicely divide the parts between the MFD, V4L, and ASoC.
I don't think there's much to be moved between the sub-systems after moving the I2C communication to the MFD driver (which has almost been agreed on).
Cheers, Matti
On Mon, 2011-02-07 at 14:00 -0200, ext Mauro Carvalho Chehab wrote:
Em 07-02-2011 12:17, Matti J. Aaltonen escreveu:
On Mon, 2011-02-07 at 13:52 +0000, ext Mark Brown wrote:
On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 11:10, Mark Brown escreveu:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?).
Yes, nothing's been merged yet. There are only dependencies between the parts of this driver... I cannot comment on upcoming boards, I just hope we could agree on a sensible structure for this thing.
We don't need any brand names or specific details, but it would be good to have an overview, in general lines, about the architecture, in order to help you to map how this would fit. In particular, the architecturre of things that are tightly coupled and can't be splitted by some bus abstraction.
I understand what you are saying but obviously I cannot think like a sub-system maintainer:-) What I see here is a piece of hardware with lots of capabilities: FM RX and TX with analog and digital audio, I2C and UART control...
I would have thought that the goal is to make a driver that's as "general" as possible and to make it possible to use the chip in all kinds of architectures and scenarios.
But we have been using the driver in principle in its current form. But if the interface to the users has to be split in a different way, I don't see that as a major problem. But on the other hand I can't see the ASoC / V4L2 division going away completely. The users won't probably care if we have MFD or not.
Cheers, Matti
Mauro.
On Mon, 2011-02-07 at 11:48 -0200, ext Mauro Carvalho Chehab wrote:
Em 07-02-2011 11:10, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 10:02, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Not sure if I understood your comments. Several media drivers have alsa drivers:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
There's the MFD driver driver/mfd/wl1273-core.c, which is to offer the (I2C) I/O functions to the child drivers: drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.
Both children depend on the MFD driver for I/O and the codec also depends on the presence of the radio-wl1273 driver because without the v4l2 part nothing can be done...
Matti
Mauro
Em 07-02-2011 12:09, Matti J. Aaltonen escreveu:
On Mon, 2011-02-07 at 11:48 -0200, ext Mauro Carvalho Chehab wrote:
Em 07-02-2011 11:10, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 10:02, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Not sure if I understood your comments. Several media drivers have alsa drivers:
There is an audio driver for this chip and it is using those functions.
Where are the other drivers that depend on it?
There's the MFD driver driver/mfd/wl1273-core.c, which is to offer the (I2C) I/O functions to the child drivers: drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.
Both children depend on the MFD driver for I/O and the codec also depends on the presence of the radio-wl1273 driver because without the v4l2 part nothing can be done...
I think that the better would be to move the audio part (sound/soc/codecs/wl1273.c) as drivers/media/radio/wl1273/wl1273-alsa.c. Is there any problem on moving it, or the alsa driver is also tightly coupled on the rest of the sound/soc stuff?
I remember that, in the past, there were someone that proposed to move /sound into /media/sound, and move some common stuff between them into /media/common.
Btw, there are(where?) some problems between -alsa and -media subsystems: basically, the audio core needs to be initialized before the drivers. However, this sometimes don't happen (I can't remember the exact situation - perhaps builtin compilations?), but we ended by needing to explicitly delaying the init of some drivers with: late_initcall(saa7134_alsa_init); To avoid some OOPS conditions.
Matti
Mauro
On Mon, Feb 07, 2011 at 01:57:10PM -0200, Mauro Carvalho Chehab wrote:
Em 07-02-2011 12:09, Matti J. Aaltonen escreveu:
Both children depend on the MFD driver for I/O and the codec also depends on the presence of the radio-wl1273 driver because without the v4l2 part nothing can be done...
I think that the better would be to move the audio part (sound/soc/codecs/wl1273.c) as drivers/media/radio/wl1273/wl1273-alsa.c. Is there any problem on moving it, or the alsa driver is also tightly coupled on the rest of the sound/soc stuff?
As I said in my previous e-mail it's tightly coupled.
I remember that, in the past, there were someone that proposed to move /sound into /media/sound, and move some common stuff between them into /media/common.
This is the first embedded audio driver that's had interface with media stuff, the driver situation for embedded audio is very different to that for PCs. Embedded audio subsystems are tightly coupled integrations of many different devices, the sound card userspace sees is produced by coordinating the actions of several different drivers.
Btw, there are(where?) some problems between -alsa and -media subsystems: basically, the audio core needs to be initialized before the drivers. However, this sometimes don't happen (I can't remember the exact situation - perhaps builtin compilations?), but we ended by needing to explicitly delaying the init of some drivers with: late_initcall(saa7134_alsa_init); To avoid some OOPS conditions.
This isn't a problem for embedded audio, instantiation of the cards is deferred until all the components for the card have registered with the core so nothing will happen until dependencies are satisfied, though it is a problem with the wl1273 driver as it currently stands due to the lack of a functional MFD.
On Mon, 2011-02-07 at 10:48 -0200, ext Mauro Carvalho Chehab wrote:
Em 07-02-2011 10:02, Mark Brown escreveu:
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote:
the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong.
Those functions are being used by the audio driver.
Not sure if I understood your comments. Several media drivers have alsa drivers: saa7134, em28xx, cx231xx, etc. The audio drivers for them are also under /drivers/media, as it is not easy to de-couple audio and video/radio part on those devices. For bttv and some USB boards (that use snd-usb-audio), the audio part is at /sound, as the audio part on them are independent and don't need to share anything, as audio is provided by a completely independent group of registers.
I suggest to use the same logic for wl1273.
So you are suggesting a more or less complete rewrite, so that I'd create a directory like media/radio/wl1273 and then place there all of the driver files: wl1273-radio.c, wl1273-alsa.c and maybe wl1273-core.c?
Cheers, Matti
Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 07, 2011 at 03:27:12PM +0200, Matti J. Aaltonen wrote:
So you are suggesting a more or less complete rewrite, so that I'd create a directory like media/radio/wl1273 and then place there all of the driver files: wl1273-radio.c, wl1273-alsa.c and maybe wl1273-core.c?
Don't move the ASoC driver out of the ASoC code, it's a complete pain for maintaining it and only makes the problems with having to build v4l worse.
On Mon, 2011-02-07 at 13:28 +0000, ext Mark Brown wrote:
On Mon, Feb 07, 2011 at 03:27:12PM +0200, Matti J. Aaltonen wrote:
So you are suggesting a more or less complete rewrite, so that I'd create a directory like media/radio/wl1273 and then place there all of the driver files: wl1273-radio.c, wl1273-alsa.c and maybe wl1273-core.c?
Don't move the ASoC driver out of the ASoC code, it's a complete pain for maintaining it and only makes the problems with having to build v4l worse.
I won't do anything before we have some kind of consensus :-)
Cheers, Matti
participants (5)
-
Bensaid, Selma -
Mark Brown -
Matti J. Aaltonen -
Mauro Carvalho Chehab -
Peter Ujfalusi