Re: [PATCH 3/3] platform/x86: int3472: Add ov13b10 (09B13) sensor module support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi both

On 25/05/2023 19:40, Hans de Goede wrote:
Hi all,

On 5/24/23 05:51, bingbu.cao@xxxxxxxxx wrote:
From: Hao Yao <hao.yao@xxxxxxxxx>

Add a new sensor support in INT3472 driver which module name is '09B13'.

Signed-off-by: Hao Yao <hao.yao@xxxxxxxxx>
Signed-off-by: Bingbu Cao <bingbu.cao@xxxxxxxxx>
---
  drivers/platform/x86/intel/int3472/discrete.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index d5d5c650d6d2..63acb48bf8df 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -60,6 +60,8 @@ static const struct int3472_sensor_config int3472_sensor_configs[] = {
  	{ "GEFF150023R", REGULATOR_SUPPLY("avdd", NULL), NULL },
  	/* Surface Go 1&2 - OV5693, Front */
  	{ "YHCU", REGULATOR_SUPPLY("avdd", NULL), NULL },
+	/* OV13B10 */
+	{ "09B13", REGULATOR_SUPPLY("vcc", NULL), NULL },
"vcc" is not really a useful supply name. All the existing sensor drivers in drivers/media/i2c typically check for both "avdd" and "dvdd". Can you verify if this is supplying digital or analog power using the schematics of the laptop ?

And then use one of the standard "avdd" or "dvdd" supply names ?

I would like to try and get rid of this table and sofar all the sensors which have a regulator GPIO are listed as sing it for "avdd" so I was hoping to be able to just always use "avdd".


I agree this is quite unsatisfactory in its current form, but I'm hoping to add the ov7251 in the near future; the driver for which uses "vdda" instead, so unfortunately not in line with that.


At least I would like us to come up with some default fallback for the supply-name in case a sensor-module is not listed in this table and "avdd" seems to be the best fallback.


I wonder if it'd be better to simply support regulator_get() calls without a supply name in the event that the device only has a single supply associated with it? Then we needn't pick a default at all.



Note that if your current sensor driver expects "vcc" that that is not a good reason to go with "vcc" here. It would be better to adjust the sensor driver to use the standard "avdd" and "dvdd" supply names (using the bulk regulator api), like all the other sensor drivers do.

Regards,

Hans




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux