Date:	Mon, 5 Mar 2012 10:24:14 -0600
From:	halli manjunatha <hallimanju@...il.com>
To:	Hans Verkuil <hverkuil@...all.nl>
Cc:	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	Manjunatha Halli <x0130808@...com>, shahed@...com
Subject: Re: [PATCH 3/3] wl128x: Add sysfs based support for FM features

On Fri, Mar 2, 2012 at 3:22 AM, Hans Verkuil <hverkuil@...all.nl> wrote:
> On Wednesday, February 29, 2012 18:19:27 halli manjunatha wrote:
>> On Wed, Feb 29, 2012 at 5:25 AM, Hans Verkuil <hverkuil@...all.nl> wrote:
>> > On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote:
>> >> On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil <hverkuil@...all.nl> wrote:
>> >> > On Monday, February 27, 2012 17:29:18 halli manjunatha wrote:
>> >> >> Hi Hans,
>> >> >>
>> >> >> Agreed I don't mind to create new controls for below things
>> >> >>
>> >> >> 1) FM RX Band selection (US/Europe, Japan and Russian bands)
>> >> >> 2) FM RX RDS AF turn ON/OFF
>> >> >> 3) FM RX RSSI level set/get
>> >> >> 4) FM TX Alternate Frequency set/get
>> >> >> 5) FM RX De-Emphasis mode set/get
>> >> >>
>> >> >> However, previously you have suggested me to hide few controls (like
>> >> >> band selection) from the user but few of our application wanted
>> >> >> controls like above and that is why I have created the sysfs entries.
>> >> >>
>> >> >> Please suggest me how can I move forward with new controls or with sysfs?
>> >> >
>> >> > The first question is which of these controls are general to FM receivers or
>> >> > transmitters, and which are specific to this chipset. The chipset specific
>> >> > controls should be private controls (look at V4L2_CID_MPEG_CX2341X_BASE in
>> >> > videodev2.h how those are defined). The others should be defined as new
>> >> > controls of the FM_TX class or the FM_RX class. The FM_RX class should be
>> >> > defined as a new class as it doesn't exist at the moment. Don't forget to
>> >> > document these controls clearly.
>> >> >
>> >> > With regards to the band selection: I remember that there was a discussion,
>> >> > but not the details. Do you have a link to that discussion? I can't find it
>> >> > (at least not quickly :-) ).
>> >>
>> >> Below features are generic to all FM receivers so we can add new CID's
>> >> for below features
>> >> 1) FM RX RDS AF turn ON/OFF
>> >> 2) FM TX Alternate Frequency set/get
>> >>
>> >> About other 3 features its different issue,
>> >>     1) FM RX Band selection (US/Europe, Japan and Russian bands)
>> >>     2) FM RX RSSI level set/get
>> >>     3) FM RX De-Emphasis mode set/get
>> >>
>> >> All these 3 features are generic to any FM receiver, only question is
>> >> does all FM receivers wants to expose these controls to application
>> >> writer?
>> >
>> > Good question, and there is no good answer at the moment. See e.g. this
>> > IRC discussion:
>> >
>> > http://www.spinics.net/lists/linux-media/msg44023.html
>> >
>> > In the absence of a good solution to this problem I am inclined to make
>> > these controls driver specific but marked experimental. The experimental
>> > tag allows us to eventually make it a generic control without too much
>> > hassle.
>>
>> Agreed, I will make them driver specific and mark them as experimental.
>>
>> >
>> >> Example Band selection, every FM receiver at the minimum supports both
>> >> Europe and Japan band, now the question is should we add a CID to
>> >> switch between these two bands?
>> >
>> > If we decide to add a band selection control, then that would be a menu
>> > control (since there are up to three bands) and it would only be implemented
>> > by drivers that need it.
>> >
>> > What I am still not clear on is *why* you would want this control. What
>> > is the reason your customers want this? What does it allow you to do that
>> > can't be done today?
>>
>> There are 2 reasons for this,
>>
>> First, our chip supports weather band, unlike other bands (Europe,
>> Japan and Russian) user may wants to
>> switch to weather band and wants to listen to weather report and again
>> switches back to normal band.
>
> OK, that makes sense. Are the RX and TX independent with regards to
> band selection?

Yes - RX and TX are independent of band selection

> Make sure that when the band is changed the rangelow and rangehigh values
> are also changed. If the current frequency is out of that range, then the
> frequency should be clamped to the closest value frequency. Although an
> alternative strategy might be to remember the last used frequency for each
> band. That might make more sense in the case of switching between a normal
> band and the weather band. We need to define and document which strategy
> should be used here.

As of now when I switch to new band I just set the frequency to lowest
of the new band.
In this way user can seek and tune to what ever channel he wants.

> BTW, is the receiver for the weather band implemented as a separate receiver?
> I read that some devices can listen to the normal band and interrupt that
> when a weather report is broadcast on the weather band. That implies two
> receivers and it would require a rethink.
>
> Also, is this feature really implemented as separate frequency ranges in
> hardware? Or is the receiver able to receive on the whole range of frequencies
> from 65.8 (OIRT) to approx. 165 (weather band range)?

Our chip wont have 2 receivers, it has only 1 receiver which can
receive on whole frequency range from 65 MHz to 165 MHz.

> Is the datasheet of this device available somewhere?

Sorry our newest chipset supports this feature so yet now we don't
have any datasheet available on net.

>
>> Second,  for FM TX, our chip supports band selection for FM
>> transmitter, so if the same phone is used in different
>> regions of world then user can switch to the actual band and start
>> transmitting by choosing a blank frequency in that band.
>
> Isn't this something that can be equally easily done in userspace?

you wants me to do this from driver itself without hinting the
application about the band ?

>
> Regards,
>
>        Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards
Halli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists