From: Hans de Goede <hdegoede@redhat.com>
To: Dan Scally <dan.scally@ideasonboard.com>,
linux-leds@vger.kernel.org, platform-driver-x86@vger.kernel.org
Cc: pavel@ucw.cz, lee@kernel.org, markgross@kernel.org,
sboyd@kernel.org, hpa@redhat.com
Subject: Re: [PATCH 8/8] platform/x86: int3472: Define LED lookup data for MS Surface Go
Date: Thu, 23 Mar 2023 12:15:25 +0100 [thread overview]
Message-ID: <e79b18cd-2f5b-05b5-37d9-98e103330993@redhat.com> (raw)
In-Reply-To: <ebd90301-bc84-3810-3633-041978b8056d@ideasonboard.com>
Hi,
On 3/23/23 11:31, Dan Scally wrote:
> Hi Hans
>
> On 22/03/2023 17:34, Hans de Goede wrote:
>> Hi,
>>
>> On 3/22/23 17:09, Daniel Scally wrote:
>>> Add LED lookup data to tps68470_board_data.c for the Microsoft
>>> Surface Go line of devices.
>>>
>>> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
>>> ---
>>> .../x86/intel/int3472/tps68470_board_data.c | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
>>> index 0d46a238b630..e2c53319e112 100644
>>> --- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c
>>> +++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
>>> @@ -157,10 +157,27 @@ static const struct tps68470_led_platform_data surface_go_tps68470_led_pdata = {
>>> .wledctl_disled2 = false,
>>> };
>>> +static struct tps68470_led_lookups surface_go_tps68470_led_lookups = {
>>> + .n_lookups = 2,
>>> + .lookup_table = {
>>> + {
>>> + .provider = "tps68470-iled_a::indicator",
>>> + .dev_id = "i2c-INT347A:00",
>>> + .con_id = "privacy-led",
>>> + },
>>> + {
>>> + .provider = "tps68470-wled::indicator",
>>> + .dev_id = "i2c-INT347E:00",
>>> + .con_id = "privacy-led",
>>> + },
>> So this feels wrong to me in 2 ways:
>>
>> 1. It is abusing .con_id = "privacy-led" to enable the WLED
>>
>> 2. You are not activating the front privacy LED for the IR projector. I have noticed on IPU6 devices that the _DSM listing GPIOs for the discrete INT3472 device lists a privacy-LED GPIO for the IR sensor too, which I so far have been guessing activates the actual privacy-LED. As I'm typing this I'm wondering if instead this is doing the same hack as you are doing here ?
>
>
> Oh interesting; on IPU3 devices with the discrete INT3472 the IR cameras don't seem to have an LED GPIO in _DSM so we're not sure how to turn them on yet. I also have a Pro7 which is an IPU4 device, but that has the same problem as on the IPU3 ones - there's no privacy-led GPIO defined in _DSM and the _ON method for the camera's _PR0 resource just prints "PR Not Supported"...so we don't know how to use those yet. So interesting that the IPU6 ones work differently.
>
>
>>
>> Regardless I think it would be best to turn on the front privacy LED when the IR camera is used too, right ?
>
>
> That does make a certain amount of sense yes - My only thought would be that this would be difficult to replicate to platforms that use _only_ discrete versions of the INT3472, because each sensor depends on a separate INT3472, so there wouldn't be an obvious way to automatically assign the privacy LED for the user facing camera to the IR camera since we couldn't use the board data method below. It might be surmountable using the location information in DSDT to decide whether it's on the same face as another camera which DOES have a privacy LED maybe...
Right, I realize turning on the front privacy LED when the front ir-sensor is on is not always going to be (easily) doable. But IMHO we should at least do it on platforms where we can do this.
>> IMHO this should look like this (with either the media-core or the driver consuming "ir-led"):
>
>
> The general principle of moving the IR led away from being treated as a privacy LED is ok by me - I'll work on that.
Thanks.
Regards,
Hans
>
>>
>> static struct tps68470_led_lookups surface_go_tps68470_led_lookups = {
>> .n_lookups = 3,
>> .lookup_table = {
>> {
>> .provider = "tps68470-iled_a::indicator",
>> .dev_id = "i2c-INT347A:00",
>> .con_id = "privacy-led",
>> },
>> {
>> /* Use regular front-sensor privacy LED for ir-sensor too */
>> .provider = "INT33BE_00::privacy_led",
>> .dev_id = "i2c-INT347E:00",
>> .con_id = "privacy-led",
>> },
>> {
>> .provider = "tps68470-wled::indicator",
>> .dev_id = "i2c-INT347E:00",
>> .con_id = "ir-led",
>> },
>> }
>>
>> Regards,
>>
>> Hans
>>
>>
>
next prev parent reply other threads:[~2023-03-23 11:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 16:09 [PATCH 0/8] Add WLED support to TPS68470 LED driver Daniel Scally
2023-03-22 16:09 ` [PATCH 1/8] platform/x86: int3472: Add platform data for LEDs Daniel Scally
2023-03-22 17:14 ` Hans de Goede
2023-03-22 16:09 ` [PATCH 2/8] platform/x86: int3472: Init LED registers using platform data Daniel Scally
2023-03-22 17:16 ` Hans de Goede
2023-03-22 16:09 ` [PATCH 3/8] platform/x86: int3472: Add TPS68470 LED Board Data Daniel Scally
2023-03-22 17:17 ` Hans de Goede
2023-03-22 16:09 ` [PATCH 4/8] platform/x86: int3472: Add tps68470-led as clock consumer Daniel Scally
2023-03-22 17:19 ` Hans de Goede
2023-03-22 16:09 ` [PATCH 5/8] leds: tps68470: Refactor tps68470_brightness_get() Daniel Scally
2023-03-22 17:22 ` Hans de Goede
2023-03-23 7:43 ` Dan Scally
2023-03-23 9:52 ` Hans de Goede
2023-03-23 9:53 ` Dan Scally
2023-03-22 16:09 ` [PATCH 6/8] leds: tps68470: Support the WLED driver Daniel Scally
2023-03-22 17:24 ` Hans de Goede
2023-03-23 11:22 ` Pavel Machek
2023-03-23 16:25 ` Dan Scally
2023-03-27 13:23 ` Hans de Goede
2023-03-22 16:09 ` [PATCH 7/8] platform/x86: int3472: Support LED lookups in board data Daniel Scally
2023-03-22 17:25 ` Hans de Goede
2023-03-22 16:09 ` [PATCH 8/8] platform/x86: int3472: Define LED lookup data for MS Surface Go Daniel Scally
2023-03-22 17:34 ` Hans de Goede
2023-03-23 10:31 ` Dan Scally
2023-03-23 11:15 ` Hans de Goede [this message]
2023-03-22 17:40 ` [PATCH 0/8] Add WLED support to TPS68470 LED driver 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e79b18cd-2f5b-05b5-37d9-98e103330993@redhat.com \
--to=hdegoede@redhat.com \
--cc=dan.scally@ideasonboard.com \
--cc=hpa@redhat.com \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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