Re: saa7115/gm7113c - device specific initialization

[Mauro Carvalho Chehab <mchehab@redhat.com>]

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