On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote: > "Jon Arne Jørgensen" <[email protected]> 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 [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? > > 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 [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
