saa7115/gm7113c - device specific initialization

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 46 lines · 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

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 17 lines · Andy Walls

Quoted 15 lines · 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.

Quoted 3 lines

Quoted 3 lines

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.

Quoted 3 lines

Quoted 3 lines

To have the device behave correctly.

Both the change for the smi2021 driver and the changes for the

Terratec

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

surface, these devices might also have different needs for the setup

of

Quoted 15 lines

Quoted 15 lines

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?

Quoted 7 lines

Quoted 7 lines

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"

Quoted 5 lines

Quoted 3 lines

in
the body of a message to [email protected]
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?

Quoted 2 lines

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.

Quoted 2 lines

The V flag probably means a line in the vertical blanking interval

(VBI), but I can't recall.

Quoted 1 line

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.

Quoted 4 lines

Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe

linux-media" in

Quoted 2 lines

the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 87 lines · Jon Arne Jørgensen

Quoted 17 lines · Andy Walls

Quoted 15 lines · 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.

Quoted 3 lines

Quoted 3 lines

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.

Quoted 3 lines

Quoted 3 lines

To have the device behave correctly.

Both the change for the smi2021 driver and the changes for the

Terratec

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

surface, these devices might also have different needs for the setup

of

Quoted 15 lines

Quoted 15 lines

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?

Quoted 7 lines

Quoted 7 lines

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"

Quoted 5 lines

Quoted 3 lines

in
the body of a message to [email protected]
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?

Quoted 2 lines

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.

Quoted 2 lines

The V flag probably means a line in the vertical blanking interval

(VBI), but I can't recall.

Quoted 1 line

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.

Quoted 4 lines

Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe

Quoted 8 lines

linux-media" in

Quoted 2 lines

the body of a message to [email protected]
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 [email protected]
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 54 lines

Quoted 51 lines · 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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 1 line

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?

Em Mon, 20 May 2013 18:20:44 +0200
Jon Arne Jørgensen <[email protected]> escreveu:

Quoted 55 lines · Andy Walls

Quoted 54 lines

Quoted 51 lines · 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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines

Quoted 1 line

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.

Signature · 2 lines

Cheers,
Mauro