archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <>
To: Mark Gross <>,
	Andy Shevchenko <>,
	Daniel Scally <>
Cc: Hans de Goede <>,,
	Sakari Ailus <>,
	Kate Hsuan <>,
Subject: [PATCH 0/3] platform/x86: int3472/discrete: Make it work with IPU6
Date: Thu, 24 Nov 2022 21:00:04 +0100	[thread overview]
Message-ID: <> (raw)

Hi All,

Here is a small set of patches to make the int3472/discrete code
work with the sensor drivers bundled with the (unfortunately out of tree)
IPU6 driver.

There are parts of the out of tree IPU6 code, like the sensor drivers,
which can be moved to the mainline and I do plan to work on this at some
point and then some of this might need to change. But for now the goal is
to make the out of tree driver work with standard mainline distro kernels
through e.g. dkms. Otherwise users need to run a patched kernel just for
a couple of small differences.

This is basically a rewrite of this patch:

Wich users who want to use the IPU6 driver so far have had to manually
apply to their kernels which is quite inconvenient.

This rewrite makes 2 significant changes:

1. Don't break things on IPU3 platforms

2. Instead of extending the int3472_sensor_configs[] quirks table for each
model which needs "clken" and "pled" GPIOs, do this based on matching
the ACPI HID of the ACPI device describing the sensor.

The need for these GPIOs is a property of the specific sensor driver which
binds using this same HID, so by using this we avoid having to extend the
int3472_sensor_configs[] quirks table all the time.

This allows roling back the behavior to at least use a clk-framework
clk instead of clken GPIO on a per sensor(-driver) basis as we mainline
the sensor drivers, assuming that the drivers are switched over to the
clk framework as part of their mainlining.

A bigger question is what to do with the privacy-led GPIO on IPU3
we so far have turned the LED on/off at the same as te clock,
but at least on some IPU6 models this won't work, because they only
have a privacy-led GPIO and no clk_en GPIO (there is no sensor
clk-control at all on some models).

I think we should maybe move all models, including IPU3 based
models over to using a normal GPIO for controlling the privacy-led
to make things consistent.

And likewise (eventually) completely drop the "clken" GPIO this
patch series introduces (with some sensors) and instead always model
this through the clk-framework.



Hans de Goede (3):
  platform/x86: int3472/discrete: Refactor GPIO to sensor mapping
  platform/x86: int3472/discrete: Get the polarity from the _DSM entry
  platform/x86: int3472/discrete: Add support for sensor-drivers which
    expect clken + pled GPIOs

 drivers/platform/x86/intel/int3472/common.h   |  2 +-
 drivers/platform/x86/intel/int3472/discrete.c | 92 ++++++++++++++++---
 2 files changed, 78 insertions(+), 16 deletions(-)


             reply	other threads:[~2022-11-24 20:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24 20:00 Hans de Goede [this message]
2022-11-24 20:00 ` [PATCH 1/3] platform/x86: int3472/discrete: Refactor GPIO to sensor mapping Hans de Goede
2022-11-24 20:09   ` Andy Shevchenko
2022-11-24 20:20     ` Hans de Goede
2022-11-24 22:19       ` Andy Shevchenko
2022-11-25 16:00   ` Dan Scally
2022-11-28 10:56     ` Hans de Goede
2022-11-24 20:00 ` [PATCH 2/3] platform/x86: int3472/discrete: Get the polarity from the _DSM entry Hans de Goede
2022-11-24 20:13   ` Andy Shevchenko
2022-11-24 20:26     ` Hans de Goede
2022-11-25 10:42       ` Dan Scally
2022-11-25 16:01   ` Dan Scally
2022-11-29 21:56   ` Hans de Goede
2022-11-24 20:00 ` [PATCH 3/3] platform/x86: int3472/discrete: Add support for sensor-drivers which expect clken + pled GPIOs Hans de Goede
2022-11-25 14:36   ` Laurent Pinchart
2022-11-25 16:07   ` Dan Scally
2022-11-25 18:38     ` Hans de Goede
2022-11-28  7:39       ` Dan Scally
2022-11-28 10:04         ` Hans de Goede
2022-11-25 10:17 ` [PATCH 0/3] platform/x86: int3472/discrete: Make it work with IPU6 Dan Scally
2022-11-25 10:58   ` Laurent Pinchart
2022-11-25 11:03     ` Dan Scally
2022-11-25 11:06     ` Andy Shevchenko
2022-11-25 11:11       ` Dan Scally
2022-11-25 11:23         ` Hans de Goede
2022-11-25 11:42           ` Dan Scally
2022-11-25 12:00             ` Hans de Goede
2022-11-25 11:15     ` Hans de Goede
2022-11-25 14:46       ` Laurent Pinchart
2022-11-28 16:11         ` Hans de Goede
2022-11-28 18:22           ` Laurent Pinchart
2022-11-25 11:02   ` Hans de Goede
2022-11-25 14:40 ` Laurent Pinchart
2022-11-28 11:28   ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).