[0/4] platform/x86: int3472: discrete: Regulator rework / Lenovo Miix 510 support

  Hi Dan, Hao Yao and Bingbu Cao,

Patches 1/2 drop the sensor-config stuff since I thought we should be
able to make things work without any board specific fixups.

This is the result of my working on getting IPU6 to work on Jasper Lake
for $dayjob and then tonight I switched to trying to get the ov2680
on the Lenovo Miix 510 to work and it turns out that does require some
board specific workarounds after all :|

With this series together with my recent ov2680 sensor driver series:
https://lore.kernel.org/linux-media/20230607164712.63579-1-hdegoede@redhat.com/
I can get the ov2680 driver to load and successfully read the id register:

[   11.365319] ipu3-cio2 0000:00:14.3: Found supported sensor OVTI2680:00
[   11.431595] ov2680 i2c-OVTI2680:00: supply DOVDD not found, using dummy regulator
[   11.433125] ov2680 i2c-OVTI2680:00: supply DVDD not found, using dummy regulator
[   11.454698] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0

Dan, currently the DMI match used only matches the 12IKB version of
the Miix 510 I think you have a 12ISK version. Can you verify this
works there too?  I guess we can just drop the KB part of the DMI
match if this works on the 12ISK version too.

Hao Yao and Bingbu Cao I think that the way the issue with how different
drivers may expect different regulator supply-ids is of interest to you
too. Note I see that the mainline version of ov13b10.c does not have
regulator support at all yet. So when adding this please just use
one of the existing set of supply-names + the bulk API like how
the ov5693.c driver is doing. In this case no int3472 driver changes
will be necessary at all.

Regards,

Hans


Hans de Goede (4):
  platform/x86: int3472: discrete: Drop GPIO remapping support
  platform/x86: int3472: discrete: Remove sensor_config-s
  platform/x86: int3472: discrete: Add support for 1 GPIO regulator
    shared between 2 sensors
  platform/x86: int3472: discrete: Add alternative "AVDD" regulator
    supply name

 .../x86/intel/int3472/clk_and_regulator.c     | 72 ++++++++++++++----
 drivers/platform/x86/intel/int3472/common.h   | 14 +---
 drivers/platform/x86/intel/int3472/discrete.c | 76 ++-----------------
 3 files changed, 66 insertions(+), 96 deletions(-)
  

Hi All,

On 6/9/23 22:42, Hans de Goede wrote:
> Hi Dan, Hao Yao and Bingbu Cao,
> 
> Patches 1/2 drop the sensor-config stuff since I thought we should be
> able to make things work without any board specific fixups.
> 
> This is the result of my working on getting IPU6 to work on Jasper Lake
> for $dayjob and then tonight I switched to trying to get the ov2680
> on the Lenovo Miix 510 to work and it turns out that does require some
> board specific workarounds after all :|
> 
> With this series together with my recent ov2680 sensor driver series:
> https://lore.kernel.org/linux-media/20230607164712.63579-1-hdegoede@redhat.com/
> I can get the ov2680 driver to load and successfully read the id register:
> 
> [   11.365319] ipu3-cio2 0000:00:14.3: Found supported sensor OVTI2680:00
> [   11.431595] ov2680 i2c-OVTI2680:00: supply DOVDD not found, using dummy regulator
> [   11.433125] ov2680 i2c-OVTI2680:00: supply DVDD not found, using dummy regulator
> [   11.454698] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
> 
> Dan, currently the DMI match used only matches the 12IKB version of
> the Miix 510 I think you have a 12ISK version. Can you verify this
> works there too?  I guess we can just drop the KB part of the DMI
> match if this works on the 12ISK version too.
> 
> Hao Yao and Bingbu Cao I think that the way the issue with how different
> drivers may expect different regulator supply-ids is of interest to you
> too. Note I see that the mainline version of ov13b10.c does not have
> regulator support at all yet. So when adding this please just use
> one of the existing set of supply-names + the bulk API like how
> the ov5693.c driver is doing. In this case no int3472 driver changes
> will be necessary at all.

I've added this to my review-hans (soon to be for-next) branch now.

Regards,

Hans




> Hans de Goede (4):
>   platform/x86: int3472: discrete: Drop GPIO remapping support
>   platform/x86: int3472: discrete: Remove sensor_config-s
>   platform/x86: int3472: discrete: Add support for 1 GPIO regulator
>     shared between 2 sensors
>   platform/x86: int3472: discrete: Add alternative "AVDD" regulator
>     supply name
> 
>  .../x86/intel/int3472/clk_and_regulator.c     | 72 ++++++++++++++----
>  drivers/platform/x86/intel/int3472/common.h   | 14 +---
>  drivers/platform/x86/intel/int3472/discrete.c | 76 ++-----------------
>  3 files changed, 66 insertions(+), 96 deletions(-)
>
  

Hi Hans,

On 2023/6/15 20:38, Hans de Goede wrote:
> Hi All,
> 
> On 6/9/23 22:42, Hans de Goede wrote:
>> Hi Dan, Hao Yao and Bingbu Cao,
>>
>> Patches 1/2 drop the sensor-config stuff since I thought we should be
>> able to make things work without any board specific fixups.
>>
>> This is the result of my working on getting IPU6 to work on Jasper Lake
>> for $dayjob and then tonight I switched to trying to get the ov2680
>> on the Lenovo Miix 510 to work and it turns out that does require some
>> board specific workarounds after all :|
>>
>> With this series together with my recent ov2680 sensor driver series:
>> https://lore.kernel.org/linux-media/20230607164712.63579-1-hdegoede@redhat.com/
>> I can get the ov2680 driver to load and successfully read the id register:
>>
>> [   11.365319] ipu3-cio2 0000:00:14.3: Found supported sensor OVTI2680:00
>> [   11.431595] ov2680 i2c-OVTI2680:00: supply DOVDD not found, using dummy regulator
>> [   11.433125] ov2680 i2c-OVTI2680:00: supply DVDD not found, using dummy regulator
>> [   11.454698] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
>>
>> Dan, currently the DMI match used only matches the 12IKB version of
>> the Miix 510 I think you have a 12ISK version. Can you verify this
>> works there too?  I guess we can just drop the KB part of the DMI
>> match if this works on the 12ISK version too.
>>
>> Hao Yao and Bingbu Cao I think that the way the issue with how different
>> drivers may expect different regulator supply-ids is of interest to you
>> too. Note I see that the mainline version of ov13b10.c does not have
>> regulator support at all yet. So when adding this please just use
>> one of the existing set of supply-names + the bulk API like how
>> the ov5693.c driver is doing. In this case no int3472 driver changes
>> will be necessary at all.
> 
> I've added this to my review-hans (soon to be for-next) branch now.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
>> Hans de Goede (4):
>>    platform/x86: int3472: discrete: Drop GPIO remapping support
>>    platform/x86: int3472: discrete: Remove sensor_config-s
>>    platform/x86: int3472: discrete: Add support for 1 GPIO regulator
>>      shared between 2 sensors
>>    platform/x86: int3472: discrete: Add alternative "AVDD" regulator
>>      supply name
>>
>>   .../x86/intel/int3472/clk_and_regulator.c     | 72 ++++++++++++++----
>>   drivers/platform/x86/intel/int3472/common.h   | 14 +---
>>   drivers/platform/x86/intel/int3472/discrete.c | 76 ++-----------------
>>   3 files changed, 66 insertions(+), 96 deletions(-)
>>
> 

Thanks for your patches.

I tested them on my devices using int3472 regulator, including Lenovo 
Thinkpad X1 and testing platforms with ov13b10 camera sensor.

Tested-By: Hao Yao <hao.yao@intel.com>


Best Regards,
Hao Yao