Re: WL1273 FM Radio driver...

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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/23602/match=aaltonen

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

Re: WL1273 FM Radio driver...

[Mauro Carvalho Chehab]

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/23602/match=aaltonen
> 
> 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

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Mauro Carvalho Chehab]

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.

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Mauro Carvalho Chehab]

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

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.

Re: WL1273 FM Radio driver...

[Mauro Carvalho Chehab]

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.

Re: [alsa-devel] WL1273 FM Radio driver...

[Peter Ujfalusi]

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.

-- 
Péter

Re: WL1273 FM Radio driver...

[Peter Ujfalusi]

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.

-- 
Péter

RE: [alsa-devel] WL1273 FM Radio driver...

[Bensaid, Selma]

> 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.

Re: [alsa-devel] WL1273 FM Radio driver...

[Peter Ujfalusi]

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.

-- 
Péter

Re: WL1273 FM Radio driver...

[Peter Ujfalusi]

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.

-- 
Péter

RE: [alsa-devel] WL1273 FM Radio driver...

[Bensaid, Selma]

> > 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.

RE: [alsa-devel] WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.
> 

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.
> 


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

RE: [alsa-devel] WL1273 FM Radio driver...

[Bensaid, Selma]

> 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.

Re: WL1273 FM Radio driver...

[Bensaid, Selma]

> 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.

RE: [alsa-devel] WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.

Re: [alsa-devel] WL1273 FM Radio driver...

[Mark Brown]

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.

Re: [alsa-devel] WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: [alsa-devel] WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: [alsa-devel] WL1273 FM Radio driver...

[Matti J. Aaltonen]

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."

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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."

Re: [alsa-devel] WL1273 FM Radio driver...

[Mark Brown]

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.

Re: [alsa-devel] WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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
> 

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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
> 

Re: WL1273 FM Radio driver...

[Mauro Carvalho Chehab]

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
>>
> 
> 

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

Re: WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

WL1273 FM Radio driver...

[Matti J. Aaltonen]

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

WL1273 FM Radio driver...

[Matti J. Aaltonen]

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


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: WL1273 FM Radio driver...

[Mark Brown]

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?

Re: WL1273 FM Radio driver...

[Samuel Ortiz]

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.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: WL1273 FM Radio driver...

[Mauro Carvalho Chehab]

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

Re: WL1273 FM Radio driver...

[Mark Brown]

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.

Re: WL1273 FM Radio driver...

[Samuel Ortiz]

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.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/