| Message ID | 20250402202510.432888-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/x86: int3472: Add handshake pin support | expand |
On Wed, Apr 2, 2025 at 11:25 PM Hans de Goede <hdegoede@redhat.com> wrote: > > New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12 > pin defined in the INT3472 sensor companion device which describes > the sensor's GPIOs. > > This pin is primarily used on designs with a Lattice FPGA chip which is > capable of running the sensor independently of the main CPU for features > like presence detection. This pin needs to be driven high to make the FPGA > run the power-on sequence of the sensor. After driving the pin high > the FPGA "firmware" needs 25ms to comlpete the power-on sequence. > > This series implements support for this by modelling the handshake GPIO > as a GPIO driven 'dvdd' regulator with an enable-time of 25 ms, also see: > > https://lore.kernel.org/platform-driver-x86/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/ > > Patch 1 Is an unrelated cleanup which I had lying around > Patches 2-7 Prepare + Implement the handshake GPIO > Patch 8 Is a small patch adding some extra debugging to GPIO remapping You meant patch 9 here, right? Offtopic: I sent you a message asking about AtomISP patch queue status, but no answer. I understand that you are kinda very busy, still it seems we missed one cycle for the patches you already have in your queue. I haven't investigated where the bottle neck happened, though. Hence just asking what's the plan with them and other patches that are already in the mailing list (I have received at least two that I was Cc'ed on).
Hi Andy, Thank you for all the reviews. On 2-Apr-25 11:02 PM, Andy Shevchenko wrote: > On Wed, Apr 2, 2025 at 11:25 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12 >> pin defined in the INT3472 sensor companion device which describes >> the sensor's GPIOs. >> >> This pin is primarily used on designs with a Lattice FPGA chip which is >> capable of running the sensor independently of the main CPU for features >> like presence detection. This pin needs to be driven high to make the FPGA >> run the power-on sequence of the sensor. After driving the pin high >> the FPGA "firmware" needs 25ms to comlpete the power-on sequence. >> >> This series implements support for this by modelling the handshake GPIO >> as a GPIO driven 'dvdd' regulator with an enable-time of 25 ms, also see: >> >> https://lore.kernel.org/platform-driver-x86/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/ >> >> Patch 1 Is an unrelated cleanup which I had lying around >> Patches 2-7 Prepare + Implement the handshake GPIO >> Patch 8 Is a small patch adding some extra debugging to GPIO remapping > > You meant patch 9 here, right? > > Offtopic: I sent you a message asking about AtomISP patch queue > status, but no answer. I understand that you are kinda very busy, > still it seems we missed one cycle for the patches you already have in > your queue. I haven't investigated where the bottle neck happened, > though. Hence just asking what's the plan with them and other patches > that are already in the mailing list (I have received at least two > that I was Cc'ed on). Yeah, I've been burried in work a bit, so this fall through the cracks. I've some more bandwidth now and I have a mailfolder with all the pending atomisp patches in there. I plan to start merging these soon and to send out an atomisp pull-request for 6.15 well in time. Regards, Hans
On Thu, Apr 03, 2025 at 12:30:29PM +0200, Hans de Goede wrote: > On 2-Apr-25 11:02 PM, Andy Shevchenko wrote: > > On Wed, Apr 2, 2025 at 11:25 PM Hans de Goede <hdegoede@redhat.com> wrote: ... > > Offtopic: I sent you a message asking about AtomISP patch queue > > status, but no answer. I understand that you are kinda very busy, > > still it seems we missed one cycle for the patches you already have in > > your queue. I haven't investigated where the bottle neck happened, > > though. Hence just asking what's the plan with them and other patches > > that are already in the mailing list (I have received at least two > > that I was Cc'ed on). > > Yeah, I've been burried in work a bit, so this fall through the cracks. > > I've some more bandwidth now and I have a mailfolder with all > the pending atomisp patches in there. I plan to start merging these > soon and to send out an atomisp pull-request for 6.15 well in time. Ah, cool! Don't hesitate to ask for a review the patches I haven't seen for AtomISP driver.
New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12 pin defined in the INT3472 sensor companion device which describes the sensor's GPIOs. This pin is primarily used on designs with a Lattice FPGA chip which is capable of running the sensor independently of the main CPU for features like presence detection. This pin needs to be driven high to make the FPGA run the power-on sequence of the sensor. After driving the pin high the FPGA "firmware" needs 25ms to comlpete the power-on sequence. This series implements support for this by modelling the handshake GPIO as a GPIO driven 'dvdd' regulator with an enable-time of 25 ms, also see: https://lore.kernel.org/platform-driver-x86/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/ Patch 1 Is an unrelated cleanup which I had lying around Patches 2-7 Prepare + Implement the handshake GPIO Patch 8 Is a small patch adding some extra debugging to GPIO remapping Changes in v2: - Add Andy's Reviewed-by to patches 1-3 - Address Andy's review remarks on patch 5 - Add 2 Tested-by tags to patch 8/9 This series applies on top of Torvald's latest master, for testing with 6.14 this patch needs to be cherry-picked first: https://web.git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?id=81b251c66bdfe263fb5e7a16838512ddaeed77df Regards, Hans Hans de Goede (9): platform/x86: int3472: Add skl_int3472_register_clock() helper platform/x86: int3472: Stop setting a supply-name for GPIO regulators platform/x86: int3472: Drop unused gpio field from struct int3472_gpio_regulator platform/x86: int3472: Rework AVDD second sensor quirk handling platform/x86: int3472: Make regulator supply name configurable platform/x86: int3472: Avoid GPIO regulator spikes platform/x86: int3472: Prepare for registering more then 1 GPIO regulator platform/x86: int3472: Add handshake pin support platform/x86: int3472: Debug log when remapping pins drivers/platform/x86/intel/int3472/Makefile | 3 +- .../x86/intel/int3472/clk_and_regulator.c | 164 ++++++------------ drivers/platform/x86/intel/int3472/common.h | 50 ++++-- drivers/platform/x86/intel/int3472/discrete.c | 39 ++++- .../x86/intel/int3472/discrete_quirks.c | 22 +++ 5 files changed, 147 insertions(+), 131 deletions(-) create mode 100644 drivers/platform/x86/intel/int3472/discrete_quirks.c