On Monday 01 December 2008, Hiremath, Vaibhav wrote: > [Hiremath, Vaibhav] We are almost on same page, but you are looking > to implement this in probe function where we do have "id" straight > coming as params. Yes ... you can't initialize the device before probe() since you don't have the i2c_client handle. And you mustn't initialize it later, since you'll have registered the codec and other code will expect it to be fully functional. You could of course power the chip down, and then need to reinit it later. That should be a simple matter of making sure that the chip setup logic is packaged so it can be called from probe() and from whatever other routines need it. > But for the devices like OMAP where power management is critical > thing, I want to put the TVP to off state and bring it again whenever > required (being used). For this, we do have ioctl interface called " > ioctl_s_power" under V4L2-Int framework. Why would that be trouble though? Just do it ... > To get the sequence supported for registered chip (46/47/4xM), I need > index under the I2C_table (client->driver->id_table[index]) which will > give me the driver_data for registered chip. There I'm not following you *at all* ... is the issue that for some reason v4l2_int_dev.priv can't just hold your instance-specific structure? Remember I'm more on top of I2C stuff than V4L2, so if this is really a V4l2 question I'm not the best person to answer. In the I2C context, all the information you need can be handed to you using id->driver-data, as I sketched earlier, so the problem seems to be how to use (a) chip descriptors, e.g. 46/46m2/47/47m1 differences, from id_driver_data; plus (b) board descriptors, from i2c_client.dev.platform_data; to create (c) an instance-specific driver structure which exposes this v4l2 video decoder. I've described (a) and (b), and will defer to you and your colleagues on (c). - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
