Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On 6/26/09 2:19 PM, Andy Walls wrote: On Fri, 2009-06-26 at 12:25 -0400, Steven Toth wrote: On 6/26/09 12:12 PM, Andy Walls wrote: My plan was to add the necessary support to the cx25840 module for setting up the cx23885 pin control multiplexers (subdev config time), the GPIO 23-19 directions (subdev config time), and the GPIO 23-19 output states (dynamically as needed via subdev's .s_gpio call). Ahh. I'm already working on this, the code is partially merged for the GPIO overhaul (a few weeks ago). I'm currently on the next stage. You should see some todo comments in the current cx23885 driver. Doesn't the cx23885 driver already configure the multiplexer pins at config time for the cx25840? Check the -cards.c for the HVR1800 entry. I'm not talking about the AFE Mux, I was refering to things like, as an example, if an external pin could be configured as either GPIO[n] pin or an audio sample clock. The mux setting that handles that. Regards, Andy Ahh, fair enough, thanks Andy. Give me a little while to resolve some of the missing GPIO pieces then lets review. If I still don't have what you need then we can review again and I'd be happy to implement any ideas we think make sense. Some HVR1800 ioctl work is stuck in the queue prior to this, so it could be a couple of weeks before I get back to it. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On 6/25/09 7:15 AM, Andy Walls wrote: On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote: On Thursday 25 June 2009 04:40:11 Andy Walls wrote: On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: There is already an s_gpio in the core ops. It would be simple to add a g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Well, the group of GPIO pins in question for the CX23885 are all multiplexed with other functions. We could just initialize the CX23885 to have those pins set as GPIOs, but I have to check the cx23885 driver to make sure that's safe. I'm in the process of rationalizing the GPIO handing inside the cx23885 driver, largely because of the cx23417. The current encoder driver has a hardcoded GPIO used on GPIO 15. (legacy from the first HVR1800 implementation, which I'm cleaning up). I would add this to the conversation, the product I'm working on now HVR1850 needs to switch GPIO's on the fly to enable and disable parts (the ATSC demod) via an encoder GPIO pin, depending on the cards operating mode. This isn't a one-time operation, it needs to be dynamic. In effect we have to tri-state / float certain parts depending whether we're in analog or digital mode, and depending on which tuner is being used. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Fri, 2009-06-26 at 12:25 -0400, Steven Toth wrote: On 6/26/09 12:12 PM, Andy Walls wrote: On Fri, 2009-06-26 at 10:37 -0400, Steven Toth wrote: On 6/25/09 7:15 AM, Andy Walls wrote: On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote: On Thursday 25 June 2009 04:40:11 Andy Walls wrote: On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: There is already an s_gpio in the core ops. It would be simple to add a g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Well, the group of GPIO pins in question for the CX23885 are all multiplexed with other functions. We could just initialize the CX23885 to have those pins set as GPIOs, but I have to check the cx23885 driver to make sure that's safe. I'm in the process of rationalizing the GPIO handing inside the cx23885 driver, largely because of the cx23417. The current encoder driver has a hardcoded GPIO used on GPIO 15. (legacy from the first HVR1800 implementation, which I'm cleaning up). I would add this to the conversation, the product I'm working on now HVR1850 needs to switch GPIO's on the fly to enable and disable parts (the ATSC demod) via an encoder GPIO pin, depending on the cards operating mode. This isn't a one-time operation, it needs to be dynamic. In effect we have to tri-state / float certain parts depending whether we're in analog or digital mode, and depending on which tuner is being used. Steve, The setting of GPIO's is (or will be) dynamic via the .s_gpio() v4l2_subdev operation. Just to clarify some things above: 1. I assume setting of GPIO direction is not required to be done the fly. Is that correct? No, incorrect. We have cases where we need to float the GPIO (HVR1300, HVR1850) we hack around this at the moment for various encoders and demods. Generally we need this functionality across a number of drivers. 2. I assume switching of the internal routing of signals to chip pins is not required to be done on the fly. Is that correct? No, incorrect. Same as above. My plan was to add the necessary support to the cx25840 module for setting up the cx23885 pin control multiplexers (subdev config time), the GPIO 23-19 directions (subdev config time), and the GPIO 23-19 output states (dynamically as needed via subdev's .s_gpio call). Ahh. I'm already working on this, the code is partially merged for the GPIO overhaul (a few weeks ago). I'm currently on the next stage. You should see some todo comments in the current cx23885 driver. Doesn't the cx23885 driver already configure the multiplexer pins at config time for the cx25840? Check the -cards.c for the HVR1800 entry. Is this a bad plan for your needs? It sounds like in some respects were working on the same thing, perhaps from different approaches. Although my needs are not to modify the 25840 driver as such, but have the cx23885 bridge be intelligent enough to be able to flip all 32 GPIO's regardless of whether they're in the avcore (embedded 25840), or the encoder or on the bridge itself. If I'm late to the party and I've missed something obvious then I apologize in advance. Nope. I'll spin down my effort which is at 5 lines of code so far. :) I was just going to handle part of the cx25840 module changes needed to add/fix GPIO settings for cx23885 since the cx23885 bridge essentailly is treating it's A/V core as a v4l2_subdevice (and
Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Thursday 25 June 2009 04:40:11 Andy Walls wrote: On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: There is already an s_gpio in the core ops. It would be simple to add a g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Adding unused code is a bad idea in general. In addition, such information should only be needed at initialization time, and since we now have the new v4l2_i2c_new_subdev_cfg function I think that that is the right way to do this. The same approach can be used for setting the gpio pin directions. That too is something you setup at config time. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote: On Thursday 25 June 2009 04:40:11 Andy Walls wrote: On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: There is already an s_gpio in the core ops. It would be simple to add a g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Well, the group of GPIO pins in question for the CX23885 are all multiplexed with other functions. We could just initialize the CX23885 to have those pins set as GPIOs, but I have to check the cx23885 driver to make sure that's safe. Adding unused code is a bad idea in general. Yes. In addition, such information should only be needed at initialization time, and since we now have the new v4l2_i2c_new_subdev_cfg function I think that that is the right way to do this. The same approach can be used for setting the gpio pin directions. That too is something you setup at config time. Yup. OK, thanks. Regards, Andy Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
