On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote: > "Jon Arne Jørgensen" <jonarne@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > >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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
