saa7115/gm7113c - device specific initialization

saa7115/gm7113c - device specific initialization

[Jon Arne Jørgensen]

Hi,
I've recently discovered that the smi2021 device have some pretty specific
needs for the setup of the gm7113c chip.

Both the smi2021 driver and the stk1160 driver needs registers
0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
chip to the saa7115 driver in the first place.

Then Timo reported that the Terratec Grabby hwrev2 needs some of the
initial register settings to be changed for the device to work.
He posted a small list of required changes.
One of these changes is a change to register 0x12 which sets
up what to output on the RTS0 pin on the chip.

Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
to be generated by VREF - whatever that means :).
That is, I need bit 7 to be clear and bit 6 to be set in register 0x10.
To have the device behave correctly.

Both the change for the smi2021 driver and the changes for the Terratec
device are pretty hardware specific.
They should probably not be part of the generic gm7113c setup.

I would also guess that if other devices with the gm7113c chip should
surface, these devices might also have different needs for the setup of
the chip.

I'm not sure what would be the correct way to handle these
differences.
The only sollution I'we tried is to bypass the saa7115
driver, and push the needed changes directly over usb to the device,
after the initial setup is sent by the saa7115 driver.
This is a major hack, and the changes should probably go through
the saa7115 driver.

Should the saa7115 driver be extended with an interface to change random
register settings, or does the i2c subsystem already have a way to handle this?

Any idea about what might could be a better sollution?

Best regards
Jon Arne Jørgensen

Re: saa7115/gm7113c - device specific initialization

[Andy Walls]

"Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:

>Hi,
>I've recently discovered that the smi2021 device have some pretty
>specific
>needs for the setup of the gm7113c chip.
>
>Both the smi2021 driver and the stk1160 driver needs registers
>0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
>chip to the saa7115 driver in the first place.
>
>Then Timo reported that the Terratec Grabby hwrev2 needs some of the
>initial register settings to be changed for the device to work.
>He posted a small list of required changes.
>One of these changes is a change to register 0x12 which sets
>up what to output on the RTS0 pin on the chip.
>
>Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
>to be generated by VREF - whatever that means :).
>That is, I need bit 7 to be clear and bit 6 to be set in register 0x10.
>To have the device behave correctly.
>
>Both the change for the smi2021 driver and the changes for the Terratec
>device are pretty hardware specific.
>They should probably not be part of the generic gm7113c setup.
>
>I would also guess that if other devices with the gm7113c chip should
>surface, these devices might also have different needs for the setup of
>the chip.
>
>I'm not sure what would be the correct way to handle these
>differences.
>The only sollution I'we tried is to bypass the saa7115
>driver, and push the needed changes directly over usb to the device,
>after the initial setup is sent by the saa7115 driver.
>This is a major hack, and the changes should probably go through
>the saa7115 driver.
>
>Should the saa7115 driver be extended with an interface to change
>random
>register settings, or does the i2c subsystem already have a way to
>handle this?
>
>Any idea about what might could be a better sollution?
>
>Best regards
>Jon Arne Jørgensen
>
>--
>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

For v4l2_subdev's there is a way to pass in platform/bridge device specific data so initialization can be different than the default, based on the needs of the bridge driver.

As for the meaning of the V (Vertical) flag in Start Active Video (SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard explains that.  Basically they are codes embedded in digitized video rasters horizontal blanking interval that describe the current video line and delimit their start and end.

The V flag probably means a line in the vertical blanking interval (VBI), but I can't recall.

Regards,
Andy

Re: saa7115/gm7113c - device specific initialization

[Jon Arne Jørgensen]

On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote:
> "Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:
> 
> >Hi,
> >I've recently discovered that the smi2021 device have some pretty
> >specific
> >needs for the setup of the gm7113c chip.
> >
> >Both the smi2021 driver and the stk1160 driver needs registers
> >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
> >chip to the saa7115 driver in the first place.
> >
> >Then Timo reported that the Terratec Grabby hwrev2 needs some of the
> >initial register settings to be changed for the device to work.
> >He posted a small list of required changes.
> >One of these changes is a change to register 0x12 which sets
> >up what to output on the RTS0 pin on the chip.
> >
> >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
> >to be generated by VREF - whatever that means :).
> >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10.
> >To have the device behave correctly.
> >
> >Both the change for the smi2021 driver and the changes for the Terratec
> >device are pretty hardware specific.
> >They should probably not be part of the generic gm7113c setup.
> >
> >I would also guess that if other devices with the gm7113c chip should
> >surface, these devices might also have different needs for the setup of
> >the chip.
> >
> >I'm not sure what would be the correct way to handle these
> >differences.
> >The only sollution I'we tried is to bypass the saa7115
> >driver, and push the needed changes directly over usb to the device,
> >after the initial setup is sent by the saa7115 driver.
> >This is a major hack, and the changes should probably go through
> >the saa7115 driver.
> >
> >Should the saa7115 driver be extended with an interface to change
> >random
> >register settings, or does the i2c subsystem already have a way to
> >handle this?
> >
> >Any idea about what might could be a better sollution?
> >
> >Best regards
> >Jon Arne Jørgensen
> >
> >--
> >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
> 
> For v4l2_subdev's there is a way to pass in platform/bridge device specific data so initialization can be different than the default, based on the needs of the bridge driver.

Ok, can you give any pointers to any documentation/source files I can
look at for this?

> 
> As for the meaning of the V (Vertical) flag in Start Active Video (SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard explains that.  Basically they are codes embedded in digitized video rasters horizontal blanking interval that describe the current video line and delimit their start and end.
> 
> The V flag probably means a line in the vertical blanking interval (VBI), but I can't recall.
> 

I'm sorry, I was a bit quick with that comment.
I know what the SAV/EAV and V-flag is. I just don't know what it means that the V-flag is
generated by VREF.

> Regards,
> Andy
> --
> 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: saa7115/gm7113c - device specific initialization

[Andy Walls]

"Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:

>On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote:
>> "Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:
>> 
>> >Hi,
>> >I've recently discovered that the smi2021 device have some pretty
>> >specific
>> >needs for the setup of the gm7113c chip.
>> >
>> >Both the smi2021 driver and the stk1160 driver needs registers
>> >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
>> >chip to the saa7115 driver in the first place.
>> >
>> >Then Timo reported that the Terratec Grabby hwrev2 needs some of the
>> >initial register settings to be changed for the device to work.
>> >He posted a small list of required changes.
>> >One of these changes is a change to register 0x12 which sets
>> >up what to output on the RTS0 pin on the chip.
>> >
>> >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
>> >to be generated by VREF - whatever that means :).
>> >That is, I need bit 7 to be clear and bit 6 to be set in register
>0x10.
>> >To have the device behave correctly.
>> >
>> >Both the change for the smi2021 driver and the changes for the
>Terratec
>> >device are pretty hardware specific.
>> >They should probably not be part of the generic gm7113c setup.
>> >
>> >I would also guess that if other devices with the gm7113c chip
>should
>> >surface, these devices might also have different needs for the setup
>of
>> >the chip.
>> >
>> >I'm not sure what would be the correct way to handle these
>> >differences.
>> >The only sollution I'we tried is to bypass the saa7115
>> >driver, and push the needed changes directly over usb to the device,
>> >after the initial setup is sent by the saa7115 driver.
>> >This is a major hack, and the changes should probably go through
>> >the saa7115 driver.
>> >
>> >Should the saa7115 driver be extended with an interface to change
>> >random
>> >register settings, or does the i2c subsystem already have a way to
>> >handle this?
>> >
>> >Any idea about what might could be a better sollution?
>> >
>> >Best regards
>> >Jon Arne Jørgensen
>> >
>> >--
>> >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
>> 
>> For v4l2_subdev's there is a way to pass in platform/bridge device
>specific data so initialization can be different than the default,
>based on the needs of the bridge driver.
>
>Ok, can you give any pointers to any documentation/source files I can
>look at for this?
>
>> 
>> As for the meaning of the V (Vertical) flag in Start Active Video
>(SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard
>explains that.  Basically they are codes embedded in digitized video
>rasters horizontal blanking interval that describe the current video
>line and delimit their start and end.
>> 
>> The V flag probably means a line in the vertical blanking interval
>(VBI), but I can't recall.
>> 
>
>I'm sorry, I was a bit quick with that comment.
>I know what the SAV/EAV and V-flag is. I just don't know what it means
>that the V-flag is
>generated by VREF.
>
>> Regards,
>> Andy
>> --
>> 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
>--
>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

http://lxr.free-electrons.com/source/drivers/media/i2c/wm8775.c#L232

The bttv driver, IIRC, has the wm8775 driver initialize differently for the Nova S card.  FWIW, the defaults for the wm8775 driver are generally those needed by the ivtv driver.

Regards,
Andy

Re: saa7115/gm7113c - device specific initialization

[Mauro Carvalho Chehab]

Em Mon, 20 May 2013 18:20:44 +0200
Jon Arne Jørgensen <jonarne@jonarne.no> escreveu:

> On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote:
> > "Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:
> > 
> > >Hi,
> > >I've recently discovered that the smi2021 device have some pretty
> > >specific
> > >needs for the setup of the gm7113c chip.
> > >
> > >Both the smi2021 driver and the stk1160 driver needs registers
> > >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
> > >chip to the saa7115 driver in the first place.
> > >
> > >Then Timo reported that the Terratec Grabby hwrev2 needs some of the
> > >initial register settings to be changed for the device to work.
> > >He posted a small list of required changes.
> > >One of these changes is a change to register 0x12 which sets
> > >up what to output on the RTS0 pin on the chip.
> > >
> > >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
> > >to be generated by VREF - whatever that means :).
> > >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10.
> > >To have the device behave correctly.
> > >
> > >Both the change for the smi2021 driver and the changes for the Terratec
> > >device are pretty hardware specific.
> > >They should probably not be part of the generic gm7113c setup.
> > >
> > >I would also guess that if other devices with the gm7113c chip should
> > >surface, these devices might also have different needs for the setup of
> > >the chip.
> > >
> > >I'm not sure what would be the correct way to handle these
> > >differences.
> > >The only sollution I'we tried is to bypass the saa7115
> > >driver, and push the needed changes directly over usb to the device,
> > >after the initial setup is sent by the saa7115 driver.
> > >This is a major hack, and the changes should probably go through
> > >the saa7115 driver.
> > >
> > >Should the saa7115 driver be extended with an interface to change
> > >random
> > >register settings, or does the i2c subsystem already have a way to
> > >handle this?
> > >
> > >Any idea about what might could be a better sollution?
> > >
> > >Best regards
> > >Jon Arne Jørgensen
> > >
> > >--
> > >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
> > 
> > For v4l2_subdev's there is a way to pass in platform/bridge device specific data so initialization can be different than the default, based on the needs of the bridge driver.
> 
> Ok, can you give any pointers to any documentation/source files I can
> look at for this?

Look, for example, at drivers/media/i2c/mt9v011.c. At mt9v011_probe, it
checks if c->dev.platform_data exists. If so, it changes the xtal frequency
to the one specified by the driver.

-- 

Cheers,
Mauro

Re: saa7115/gm7113c - device specific initialization

[Jon Arne Jørgensen]

On Mon, May 20, 2013 at 12:42:58PM -0400, Andy Walls wrote:
> "Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:
> 
> >On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote:
> >> "Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:
> >> 
> >> >Hi,
> >> >I've recently discovered that the smi2021 device have some pretty
> >> >specific
> >> >needs for the setup of the gm7113c chip.
> >> >
> >> >Both the smi2021 driver and the stk1160 driver needs registers
> >> >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
> >> >chip to the saa7115 driver in the first place.
> >> >
> >> >Then Timo reported that the Terratec Grabby hwrev2 needs some of the
> >> >initial register settings to be changed for the device to work.
> >> >He posted a small list of required changes.
> >> >One of these changes is a change to register 0x12 which sets
> >> >up what to output on the RTS0 pin on the chip.
> >> >
> >> >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
> >> >to be generated by VREF - whatever that means :).
> >> >That is, I need bit 7 to be clear and bit 6 to be set in register
> >0x10.
> >> >To have the device behave correctly.
> >> >
> >> >Both the change for the smi2021 driver and the changes for the
> >Terratec
> >> >device are pretty hardware specific.
> >> >They should probably not be part of the generic gm7113c setup.
> >> >
> >> >I would also guess that if other devices with the gm7113c chip
> >should
> >> >surface, these devices might also have different needs for the setup
> >of
> >> >the chip.
> >> >
> >> >I'm not sure what would be the correct way to handle these
> >> >differences.
> >> >The only sollution I'we tried is to bypass the saa7115
> >> >driver, and push the needed changes directly over usb to the device,
> >> >after the initial setup is sent by the saa7115 driver.
> >> >This is a major hack, and the changes should probably go through
> >> >the saa7115 driver.
> >> >
> >> >Should the saa7115 driver be extended with an interface to change
> >> >random
> >> >register settings, or does the i2c subsystem already have a way to
> >> >handle this?
> >> >
> >> >Any idea about what might could be a better sollution?
> >> >
> >> >Best regards
> >> >Jon Arne Jørgensen
> >> >
> >> >--
> >> >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
> >> 
> >> For v4l2_subdev's there is a way to pass in platform/bridge device
> >specific data so initialization can be different than the default,
> >based on the needs of the bridge driver.
> >
> >Ok, can you give any pointers to any documentation/source files I can
> >look at for this?
> >
> >> 
> >> As for the meaning of the V (Vertical) flag in Start Active Video
> >(SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard
> >explains that.  Basically they are codes embedded in digitized video
> >rasters horizontal blanking interval that describe the current video
> >line and delimit their start and end.
> >> 
> >> The V flag probably means a line in the vertical blanking interval
> >(VBI), but I can't recall.
> >> 
> >
> >I'm sorry, I was a bit quick with that comment.
> >I know what the SAV/EAV and V-flag is. I just don't know what it means
> >that the V-flag is
> >generated by VREF.
> >
> >> Regards,
> >> Andy
> >> --
> >> 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
> >--
> >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
> 
> http://lxr.free-electrons.com/source/drivers/media/i2c/wm8775.c#L232
> 
> The bttv driver, IIRC, has the wm8775 driver initialize differently for the Nova S card.  FWIW, the defaults for the wm8775 driver are generally those needed by the ivtv driver.

Cool,
that looks like the sollution I'm looking for.

Thanks.

Best regards
Jon Arne

> 
> Regards,
> Andy
> --
> 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: saa7115/gm7113c - device specific initialization

[Jon Arne Jørgensen]

On Mon, May 20, 2013 at 06:00:29PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 20 May 2013 18:20:44 +0200
> Jon Arne Jørgensen <jonarne@jonarne.no> escreveu:
> 
> > On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote:
> > > "Jon Arne Jørgensen" <jonarne@jonarne.no> wrote:
> > > 
> > > >Hi,
> > > >I've recently discovered that the smi2021 device have some pretty
> > > >specific
> > > >needs for the setup of the gm7113c chip.
> > > >
> > > >Both the smi2021 driver and the stk1160 driver needs registers
> > > >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c
> > > >chip to the saa7115 driver in the first place.
> > > >
> > > >Then Timo reported that the Terratec Grabby hwrev2 needs some of the
> > > >initial register settings to be changed for the device to work.
> > > >He posted a small list of required changes.
> > > >One of these changes is a change to register 0x12 which sets
> > > >up what to output on the RTS0 pin on the chip.
> > > >
> > > >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
> > > >to be generated by VREF - whatever that means :).
> > > >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10.
> > > >To have the device behave correctly.
> > > >
> > > >Both the change for the smi2021 driver and the changes for the Terratec
> > > >device are pretty hardware specific.
> > > >They should probably not be part of the generic gm7113c setup.
> > > >
> > > >I would also guess that if other devices with the gm7113c chip should
> > > >surface, these devices might also have different needs for the setup of
> > > >the chip.
> > > >
> > > >I'm not sure what would be the correct way to handle these
> > > >differences.
> > > >The only sollution I'we tried is to bypass the saa7115
> > > >driver, and push the needed changes directly over usb to the device,
> > > >after the initial setup is sent by the saa7115 driver.
> > > >This is a major hack, and the changes should probably go through
> > > >the saa7115 driver.
> > > >
> > > >Should the saa7115 driver be extended with an interface to change
> > > >random
> > > >register settings, or does the i2c subsystem already have a way to
> > > >handle this?
> > > >
> > > >Any idea about what might could be a better sollution?
> > > >
> > > >Best regards
> > > >Jon Arne Jørgensen
> > > >
> > > >--
> > > >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
> > > 
> > > For v4l2_subdev's there is a way to pass in platform/bridge device specific data so initialization can be different than the default, based on the needs of the bridge driver.
> > 
> > Ok, can you give any pointers to any documentation/source files I can
> > look at for this?
> 
> Look, for example, at drivers/media/i2c/mt9v011.c. At mt9v011_probe, it
> checks if c->dev.platform_data exists. If so, it changes the xtal frequency
> to the one specified by the driver.
> 

Thanks.
Exactly what I need.

Best regards,
Jon Arne

> -- 
> 
> Cheers,
> Mauro