On 09/01/2021 09:17, Andy Shevchenko wrote: > On Saturday, January 9, 2021, Daniel Scally <djrscally@xxxxxxxxx> wrote: > >> 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. >> >> > Can you share the exact name / model of the hardware in question here? I > would try to search for the schematics. Lenovo Miix 510-12ISK 80U1 - I also tried asking Lenovo for them but that didn't really go anywhere; but of course I'm just contacting their usual support line and explaining what I'm after, so I didn't really expect it to. > > >>>> 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. >> >> > Laurent answered that it is not the best choice from camera sensor driver > perspective. Yep, seen - no problem. I will look at doing it via the method he suggests.
