Help needed in understanding v4l2_device_call_all

Help needed in understanding v4l2_device_call_all

[Bee Hock Goh]

Hi,

I am trying to understand how the subdev function are triggered when I
use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
tm600-video.

How am i able to link the callback from the tuner_xc2028 function?

Please help me to understand or directly me to any documentation that
I can read up?

thanks,
 Hock.

Re: Help needed in understanding v4l2_device_call_all

[Mauro Carvalho Chehab]

Bee Hock Goh wrote:
> Hi,
> 
> I am trying to understand how the subdev function are triggered when I
> use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
> tm600-video.

It calls tuner-core.c code, with g_tuner command. tuner-core
checks what's the used tuner and, in the case of tm6000, calls the corresponding
function at tuner-xc2028. This is implemented on tuner_g_tuner() function.

The function basically does some sanity checks, and some common tuner code, but
the actual implementation is handled by some callbacks that the driver needs to
define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
get_status for it:
                fe_tuner_ops->get_status(&t->fe, &tuner_status);


You will find a good example of how to implement such code at tuner-simple 
simple_get_status() function.

In the case of tuner-xc2028, we never found a way for it to properly report the
status of the tuner lock. That's why this function is not implemented on the driver.

> How am i able to link the callback from the tuner_xc2028 function?

The callback is used by tuner-xc2028 when it detects the need of changing the
firmware (or when the firmware is not loaded yet, or when you select a standard
that it is not supported by the current firmware).

Basically, xc2028 driver will use the callback that was set previously via:

	v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg);


> 
> Please help me to understand or directly me to any documentation that
> I can read up?
> 
> thanks,
>  Hock.
> --
> 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


-- 

Cheers,
Mauro

Re: Help needed in understanding v4l2_device_call_all

[Bee Hock Goh]

Mauro,

Thanks.

Previously, I have done some limited test and it seem that
xc2028_signal seem to be getting the correct registered value for the
detected a signal locked.

Since I am now able to get video working(though somewhat limited since
it still crashed if i change channel from mythtv), i will be spending
more time to look getting a lock on the signal.


Is line 139,140,155,156 needed? Its slowing down the loading of
firmware and it working for me with the additional register setting.

 138 if (addr == dev->tuner_addr << 1) {
139 tm6000_set_reg(dev, 0x32, 0,0);
140 tm6000_set_reg(dev, 0x33, 0,0);
141 }
142 if (i2c_debug >= 2)
143 for (byte = 0; byte < msgs[i].len; byte++)
144 printk(" %02x", msgs[i].buf[byte]);
145 } else {
146 /* write bytes */
147 if (i2c_debug >= 2)
148 for (byte = 0; byte < msgs[i].len; byte++)
149 printk(" %02x", msgs[i].buf[byte]);
150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
151 msgs[i].buf + 1, msgs[i].len - 1);
152
153 if (addr == dev->tuner_addr << 1) {
154 tm6000_set_reg(dev, 0x32, 0,0);
155 tm6000_set_reg(dev, 0x33, 0,0);


On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Bee Hock Goh wrote:
>> Hi,
>>
>> I am trying to understand how the subdev function are triggered when I
>> use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
>> tm600-video.
>
> It calls tuner-core.c code, with g_tuner command. tuner-core
> checks what's the used tuner and, in the case of tm6000, calls the corresponding
> function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
>
> The function basically does some sanity checks, and some common tuner code, but
> the actual implementation is handled by some callbacks that the driver needs to
> define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
> get_status for it:
>                fe_tuner_ops->get_status(&t->fe, &tuner_status);
>
>
> You will find a good example of how to implement such code at tuner-simple
> simple_get_status() function.
>
> In the case of tuner-xc2028, we never found a way for it to properly report the
> status of the tuner lock. That's why this function is not implemented on the driver.
>
>> How am i able to link the callback from the tuner_xc2028 function?
>
> The callback is used by tuner-xc2028 when it detects the need of changing the
> firmware (or when the firmware is not loaded yet, or when you select a standard
> that it is not supported by the current firmware).
>
> Basically, xc2028 driver will use the callback that was set previously via:
>
>        v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg);
>
>
>>
>> Please help me to understand or directly me to any documentation that
>> I can read up?
>>
>> thanks,
>>  Hock.
>> --
>> 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
>
>
> --
>
> Cheers,
> Mauro
>

Re: Help needed in understanding v4l2_device_call_all

[Mauro Carvalho Chehab]

Bee Hock Goh wrote:
> Mauro,
> 
> Thanks.
> 
> Previously, I have done some limited test and it seem that
> xc2028_signal seem to be getting the correct registered value for the
> detected a signal locked.

With the i2c reads working perfectly, it should be already providing the
signal strength with the current code. Dmitri submitted an interesting
patch that it is probably improving the i2c code. It is a worthy trial.

> Since I am now able to get video working(though somewhat limited since
> it still crashed if i change channel from mythtv), i will be spending
> more time to look getting a lock on the signal.

There are still troubles on video. I tested yesterday, and it still crashing.
Tested on a tm6010 device. Unfortunately, some patch broke support for my
10moons device: it is now failing when reading the firmware. Probably, the
GPIO code is wrong.

> Is line 139,140,155,156 needed? Its slowing down the loading of
> firmware and it working for me with the additional register setting.
> 
>  138 if (addr == dev->tuner_addr << 1) {
> 139 tm6000_set_reg(dev, 0x32, 0,0);
> 140 tm6000_set_reg(dev, 0x33, 0,0);

On my tests with HVR-950H, it makes no difference. Probably, Dmitri approach
should be enough, but it won't solve the slow down, as it adds some delay
on i2c operations.

Cheers,
Mauro

Re: Help needed in understanding v4l2_device_call_all

[Stefan Ringel]

Am 23.04.2010 04:20, schrieb Bee Hock Goh:
> Mauro,
>
> Thanks.
>
> Previously, I have done some limited test and it seem that
> xc2028_signal seem to be getting the correct registered value for the
> detected a signal locked.
>
> Since I am now able to get video working(though somewhat limited since
> it still crashed if i change channel from mythtv), i will be spending
> more time to look getting a lock on the signal.
>
>
> Is line 139,140,155,156 needed? Its slowing down the loading of
> firmware and it working for me with the additional register setting.
>
>  138 if (addr == dev->tuner_addr << 1) {
> 139 tm6000_set_reg(dev, 0x32, 0,0);
> 140 tm6000_set_reg(dev, 0x33, 0,0);
>   
use tm6010
> 141 }
> 142 if (i2c_debug >= 2)
> 143 for (byte = 0; byte < msgs[i].len; byte++)
> 144 printk(" %02x", msgs[i].buf[byte]);
> 145 } else {
> 146 /* write bytes */
> 147 if (i2c_debug >= 2)
> 148 for (byte = 0; byte < msgs[i].len; byte++)
> 149 printk(" %02x", msgs[i].buf[byte]);
> 150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
> 151 msgs[i].buf + 1, msgs[i].len - 1);
> 152
> 153 if (addr == dev->tuner_addr << 1) {
> 154 tm6000_set_reg(dev, 0x32, 0,0);
> 155 tm6000_set_reg(dev, 0x33, 0,0);
>   
use tm6010
>
> On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>   
>> Bee Hock Goh wrote:
>>     
>>> Hi,
>>>
>>> I am trying to understand how the subdev function are triggered when I
>>> use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
>>> tm600-video.
>>>       
>> It calls tuner-core.c code, with g_tuner command. tuner-core
>> checks what's the used tuner and, in the case of tm6000, calls the corresponding
>> function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
>>
>> The function basically does some sanity checks, and some common tuner code, but
>> the actual implementation is handled by some callbacks that the driver needs to
>> define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
>> get_status for it:
>>                fe_tuner_ops->get_status(&t->fe, &tuner_status);
>>
>>
>> You will find a good example of how to implement such code at tuner-simple
>> simple_get_status() function.
>>
>> In the case of tuner-xc2028, we never found a way for it to properly report the
>> status of the tuner lock. That's why this function is not implemented on the driver.
>>
>>     
>>> How am i able to link the callback from the tuner_xc2028 function?
>>>       
>> The callback is used by tuner-xc2028 when it detects the need of changing the
>> firmware (or when the firmware is not loaded yet, or when you select a standard
>> that it is not supported by the current firmware).
>>
>> Basically, xc2028 driver will use the callback that was set previously via:
>>
>>        v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg);
>>
>>
>>     
>>> Please help me to understand or directly me to any documentation that
>>> I can read up?
>>>
>>> thanks,
>>>  Hock.
>>> --
>>> 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
>>>       
>>
>> --
>>
>> 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
>   


-- 
Stefan Ringel <stefan.ringel@arcor.de>

Re: Help needed in understanding v4l2_device_call_all

[Bee Hock Goh]

So do you mean its required for tm6010 to set the registers?

On Fri, Apr 23, 2010 at 11:23 PM, Stefan Ringel <stefan.ringel@arcor.de> wrote:
> Am 23.04.2010 04:20, schrieb Bee Hock Goh:
>> Mauro,
>>
>> Thanks.
>>
>> Previously, I have done some limited test and it seem that
>> xc2028_signal seem to be getting the correct registered value for the
>> detected a signal locked.
>>
>> Since I am now able to get video working(though somewhat limited since
>> it still crashed if i change channel from mythtv), i will be spending
>> more time to look getting a lock on the signal.
>>
>>
>> Is line 139,140,155,156 needed? Its slowing down the loading of
>> firmware and it working for me with the additional register setting.
>>
>>  138 if (addr == dev->tuner_addr << 1) {
>> 139 tm6000_set_reg(dev, 0x32, 0,0);
>> 140 tm6000_set_reg(dev, 0x33, 0,0);
>>
> use tm6010
>> 141 }
>> 142 if (i2c_debug >= 2)
>> 143 for (byte = 0; byte < msgs[i].len; byte++)
>> 144 printk(" %02x", msgs[i].buf[byte]);
>> 145 } else {
>> 146 /* write bytes */
>> 147 if (i2c_debug >= 2)
>> 148 for (byte = 0; byte < msgs[i].len; byte++)
>> 149 printk(" %02x", msgs[i].buf[byte]);
>> 150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
>> 151 msgs[i].buf + 1, msgs[i].len - 1);
>> 152
>> 153 if (addr == dev->tuner_addr << 1) {
>> 154 tm6000_set_reg(dev, 0x32, 0,0);
>> 155 tm6000_set_reg(dev, 0x33, 0,0);
>>
> use tm6010
>>
>> On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>
>>> Bee Hock Goh wrote:
>>>
>>>> Hi,
>>>>
>>>> I am trying to understand how the subdev function are triggered when I
>>>> use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
>>>> tm600-video.
>>>>
>>> It calls tuner-core.c code, with g_tuner command. tuner-core
>>> checks what's the used tuner and, in the case of tm6000, calls the corresponding
>>> function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
>>>
>>> The function basically does some sanity checks, and some common tuner code, but
>>> the actual implementation is handled by some callbacks that the driver needs to
>>> define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
>>> get_status for it:
>>>                fe_tuner_ops->get_status(&t->fe, &tuner_status);
>>>
>>>
>>> You will find a good example of how to implement such code at tuner-simple
>>> simple_get_status() function.
>>>
>>> In the case of tuner-xc2028, we never found a way for it to properly report the
>>> status of the tuner lock. That's why this function is not implemented on the driver.
>>>
>>>
>>>> How am i able to link the callback from the tuner_xc2028 function?
>>>>
>>> The callback is used by tuner-xc2028 when it detects the need of changing the
>>> firmware (or when the firmware is not loaded yet, or when you select a standard
>>> that it is not supported by the current firmware).
>>>
>>> Basically, xc2028 driver will use the callback that was set previously via:
>>>
>>>        v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg);
>>>
>>>
>>>
>>>> Please help me to understand or directly me to any documentation that
>>>> I can read up?
>>>>
>>>> thanks,
>>>>  Hock.
>>>> --
>>>> 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
>>>>
>>>
>>> --
>>>
>>> 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
>>
>
>
> --
> Stefan Ringel <stefan.ringel@arcor.de>
>
>

Re: Help needed in understanding v4l2_device_call_all

[Stefan Ringel]

Am 23.04.2010 17:28, schrieb Bee Hock Goh:
> So do you mean its required for tm6010 to set the registers?
>   
that is not a register, please see you in lastest git, that this request
a command is (send start and send stop!).
> On Fri, Apr 23, 2010 at 11:23 PM, Stefan Ringel <stefan.ringel@arcor.de> wrote:
>   
>> Am 23.04.2010 04:20, schrieb Bee Hock Goh:
>>     
>>> Mauro,
>>>
>>> Thanks.
>>>
>>> Previously, I have done some limited test and it seem that
>>> xc2028_signal seem to be getting the correct registered value for the
>>> detected a signal locked.
>>>
>>> Since I am now able to get video working(though somewhat limited since
>>> it still crashed if i change channel from mythtv), i will be spending
>>> more time to look getting a lock on the signal.
>>>
>>>
>>> Is line 139,140,155,156 needed? Its slowing down the loading of
>>> firmware and it working for me with the additional register setting.
>>>
>>>  138 if (addr == dev->tuner_addr << 1) {
>>> 139 tm6000_set_reg(dev, 0x32, 0,0);
>>> 140 tm6000_set_reg(dev, 0x33, 0,0);
>>>
>>>       
>> use tm6010
>>     
>>> 141 }
>>> 142 if (i2c_debug >= 2)
>>> 143 for (byte = 0; byte < msgs[i].len; byte++)
>>> 144 printk(" %02x", msgs[i].buf[byte]);
>>> 145 } else {
>>> 146 /* write bytes */
>>> 147 if (i2c_debug >= 2)
>>> 148 for (byte = 0; byte < msgs[i].len; byte++)
>>> 149 printk(" %02x", msgs[i].buf[byte]);
>>> 150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
>>> 151 msgs[i].buf + 1, msgs[i].len - 1);
>>> 152
>>> 153 if (addr == dev->tuner_addr << 1) {
>>> 154 tm6000_set_reg(dev, 0x32, 0,0);
>>> 155 tm6000_set_reg(dev, 0x33, 0,0);
>>>
>>>       
>> use tm6010
>>     
>>> On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>
>>>       
>>>> Bee Hock Goh wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> I am trying to understand how the subdev function are triggered when I
>>>>> use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
>>>>> tm600-video.
>>>>>
>>>>>           
>>>> It calls tuner-core.c code, with g_tuner command. tuner-core
>>>> checks what's the used tuner and, in the case of tm6000, calls the corresponding
>>>> function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
>>>>
>>>> The function basically does some sanity checks, and some common tuner code, but
>>>> the actual implementation is handled by some callbacks that the driver needs to
>>>> define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
>>>> get_status for it:
>>>>                fe_tuner_ops->get_status(&t->fe, &tuner_status);
>>>>
>>>>
>>>> You will find a good example of how to implement such code at tuner-simple
>>>> simple_get_status() function.
>>>>
>>>> In the case of tuner-xc2028, we never found a way for it to properly report the
>>>> status of the tuner lock. That's why this function is not implemented on the driver.
>>>>
>>>>
>>>>         
>>>>> How am i able to link the callback from the tuner_xc2028 function?
>>>>>
>>>>>           
>>>> The callback is used by tuner-xc2028 when it detects the need of changing the
>>>> firmware (or when the firmware is not loaded yet, or when you select a standard
>>>> that it is not supported by the current firmware).
>>>>
>>>> Basically, xc2028 driver will use the callback that was set previously via:
>>>>
>>>>        v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg);
>>>>
>>>>
>>>>
>>>>         
>>>>> Please help me to understand or directly me to any documentation that
>>>>> I can read up?
>>>>>
>>>>> thanks,
>>>>>  Hock.
>>>>> --
>>>>> 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
>>>>>
>>>>>           
>>>> --
>>>>
>>>> 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
>>>
>>>       
>>
>> --
>> Stefan Ringel <stefan.ringel@arcor.de>
>>
>>
>>     


-- 
Stefan Ringel <stefan.ringel@arcor.de>

Re: Help needed in understanding v4l2_device_call_all

[Mauro Carvalho Chehab]

Stefan Ringel wrote:
> Am 23.04.2010 17:28, schrieb Bee Hock Goh:
>> So do you mean its required for tm6010 to set the registers?
>>   
> that is not a register, please see you in lastest git, that this request
> a command is (send start and send stop!).

It is hard to know what it really does, but I suspect that it were meant to
implement manual i2c handling, on a similar way to what other drivers do.
On the logs I have here for tm6000 and tm6010, this is not used. So, I suspect
that this is one of the i2c tricks that were used by the vendor of your board.
Other vendors seem to implement different tricks to make i2c work. We need
to figure out what would work better for the devices supported by the driver.

Cheers,
Mauro