Hi Andy On 08/01/2021 12:17, Andy Shevchenko wrote: > On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally <djrscally@xxxxxxxxx> wrote: >> On 30/11/2020 20:07, Andy Shevchenko wrote: >>> On Mon, Nov 30, 2020 at 01:31:29PM +0000, Daniel Scally wrote: > ... > >>> It's solely Windows driver design... >>> Luckily I found some information and can clarify above table: >>> >>> 0x00 Reset >>> 0x01 Power down >>> 0x0b Power enable >>> 0x0c Clock enable >>> 0x0d LED (active high) >>> >>> The above text perhaps should go somewhere under Documentation. >> Coming back to this; there's a bit of an anomaly with the 0x01 Power >> Down pin for at least one platform. As listed above, the OV2680 on one >> of my platforms has 3 GPIOs defined, and the table above gives them as >> type Reset, Power down and Clock enable. I'd assumed from this table >> that "power down" meant a powerdown GPIO (I.E. the one usually called >> PWDNB in Omnivision datasheets and "powerdown" in drivers), but the >> datasheet for the OV2680 doesn't list a separate reset and powerdown >> pin, but rather a single pin that performs both functions. > All of them are GPIOs, the question here is how they are actually > connected on PCB level and I have no answer to that. You have to find > schematics somewhere. Yeah; I've been trying to get those but so far, no dice. > >> Am I wrong to treat that as something that ought to be mapped as a >> powerdown GPIO to the sensors? Or do you know of any other way to >> reconcile that discrepancy? > The GPIOs can go directly to the sensors or be a control pin for > separate discrete power gates. > So, we can do one of the following: > a) present PD GPIO as fixed regulator; > b) present PD & Reset GPIOs as regulator; > c) provide them as is to the sensor and sensor driver must do what it > considers right. > > Since we don't have schematics (yet?) and we have plenty of variations > of sensors, I would go to c) and update the driver of the affected > sensor as needed. Because even if you have separate discrete PD for > one sensor on one platform there is no guarantee that it will be the > same on another. Providing a "virtual" PD in a sensor that doesn't > support it is the best choice I think. Let's hear what Sakari and > other experienced camera sensor developers say. > > My vision is purely based on electrical engineering background, > experience with existing (not exactly camera) sensor drivers and > generic cases. Alright; thanks. I'm happy with C being the answer, so unless someone thinks differently I'll work on that basis. >> Failing that; the only way I can think to handle this is to register >> proxy GPIO pins assigned to the sensors as you suggested previously, and >> have them toggle the GPIO's assigned to the INT3472 based on platform >> specific mapping data (I.E. we register a pin called "reset", which on >> most platforms just toggles the 0x00 pin, but on this specific platform >> would drive both 0x00 and 0x01 together. We're already heading that way >> for the regulator consumer supplies so it's sort of nothing new, but I'd >> still rather not if it can be avoided. >
