* Re: [PATCH v1 00/14] MediaTek dt-bindings sanitization (MT8173)
From: Ariel D'Alessandro @ 2025-09-11 14:29 UTC (permalink / raw)
To: Mark Brown
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, chunkuang.hu, ck.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw, jmassot,
kernel, krzk+dt, kuba, kyrie.wu, lgirdwood, linus.walleij,
louisalexis.eyraud, maarten.lankhorst, matthias.bgg, mchehab,
minghsiu.tsai, mripard, p.zabel, pabeni, robh, sean.wang, simona,
support.opensource, tiffany.lin, tzimmermann, yunfei.dong,
devicetree, dri-devel, linux-arm-kernel, linux-clk, linux-gpio,
linux-input, linux-kernel, linux-media, linux-mediatek,
linux-sound, netdev
In-Reply-To: <9401aab0-1168-4570-a0a1-1310f37142eb@sirena.org.uk>
Mark,
On 8/20/25 2:19 PM, Mark Brown wrote:
> On Wed, Aug 20, 2025 at 02:12:48PM -0300, Ariel D'Alessandro wrote:
>> This patch series continues the effort to address Device Tree validation
>> warnings for MediaTek platforms, with a focus on MT8173. It follows the initial
>> cleanup series by Angelo (https://www.spinics.net/lists/kernel/msg5780177.html)
>>
>> Similarly to the ongoing MT8183 work done by Julien Massot, this patchset
>> eliminates several of the remaining warnings by improving or converting DT
>> bindings to YAML, adding missing properties, and updating device tree files
>> accordingly.
>
> Same question as for that series, what's the story with
> interdependencies between the patches?
>
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
I'm resubmitting patchset v2 with several fixes addressing feedback on
each patch. While doing so, I've updated each subject line according to
each subsystem log.
Of course let me know if this still need some work.
Thanks for your help!
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Resolve touchpad issues on Dell systems during S4
From: Mario Limonciello @ 2025-09-11 13:58 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: jikos, linux-input
In-Reply-To: <vy4g5xpppfy3wy6c6ncjeqiywumuv2al5lowwbt3x4qtc3rpwv@2mvzwivdhhlc>
On 9/11/25 8:49 AM, Benjamin Tissoires wrote:
> Hi Mario,
>
> On Sep 09 2025, Mario Limonciello (AMD) wrote:
>> Dell systems utilize an EC-based touchpad emulation when the ACPI
>> touchpad _DSM is not invoked. This emulation acts as a secondary
>> master on the I2C bus, designed for scenarios where the I2C touchpad
>> driver is absent, such as in BIOS menus. Typically, loading the
>> i2c-hid module triggers the _DSM at initialization, disabling the
>> EC-based emulation.
>>
>> However, if the i2c-hid module is missing from the boot kernel
>> used for hibernation snapshot restoration, the _DSM remains
>> uncalled, resulting in dual masters on the I2C bus and
>> subsequent arbitration errors. This issue arises when i2c-hid
>> resides in the rootfs instead of the kernel or initramfs.
>
> In the downstream Red Hat bug it was mentioned that the kernel
> configuration had an impact though. But as I understand it now that I'm
> re-reading it for the 4th time:
> - on stock fedora kernel (i2c-hid in initramfs): works
> - on stock RHEL kernel (i2c-hid in initramfs): bug but config issue
> - on vanilla kernel without i2c-hid in initramfs: bug fixed by that
> patch
> - on vanilla kernel with i2c-hid in initramfs: works
The detail you're missing here for #4 is vanilla kernel *with Fedora
kernel config* not with a defconfig. A defconfig kernel I don't expect
enables all the config options needed for this hardware.
I've reproduced it with my own kernel config as well which is not the
Fedora or RHEL kernel config but rather a narrowed down config of
options that I normally use for testing.
>
> So that patch is needed no matter the config bug we have there and it
> will also fix that config bug. Am I correct?
Yes there are certainly circumstances it is needed if i2c-hid isn't
present in the kernel used to restore the hibernation image.
>
>>
>> To address this, switch from using the SYSTEM_SLEEP_PM_OPS()
>> macro to dedicated callbacks, introducing a specific
>> callback for restoring the S4 image. This callback ensures
>> the _DSM is invoked.
>
> I'm a little bit hesitant to include this patch without proper testing.
> Did you run this through a wider range of laptops than just the
> problematic one?
I have been including it in my (local) development and testing tree ever
since I made it about a month ago so I've thrown it at a random
assortment of hardware I boot that on. I have also been doing S4
testing explicitly because of checking that I didn't break S4 with by S4
at S5 series [1].
That hardware is all biased to be AMD hardware though.
[1]
https://lore.kernel.org/linux-usb/20250909191619.2580169-1-superm1@kernel.org/
>
> Other than that, patch looks good to me, but I would have liked to have
> another opinion on it.
>
> Cheers,
> Benjamin
>
>>
>> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
>> ---
>> drivers/hid/i2c-hid/i2c-hid-acpi.c | 8 ++++++++
>> drivers/hid/i2c-hid/i2c-hid-core.c | 28 +++++++++++++++++++++++++++-
>> drivers/hid/i2c-hid/i2c-hid.h | 2 ++
>> 3 files changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
>> index 1b49243adb16a..abd700a101f46 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
>> @@ -76,6 +76,13 @@ static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
>> return hid_descriptor_address;
>> }
>>
>> +static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
>> +{
>> + struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
>> +
>> + i2c_hid_acpi_get_descriptor(ihid_acpi);
>> +}
>> +
>> static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
>> {
>> struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
>> @@ -96,6 +103,7 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
>>
>> ihid_acpi->adev = ACPI_COMPANION(dev);
>> ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
>> + ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
>>
>> ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
>> if (ret < 0)
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
>> index d3912e3f2f13a..3257aa87be898 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>> @@ -961,6 +961,14 @@ static void i2c_hid_core_shutdown_tail(struct i2c_hid *ihid)
>> ihid->ops->shutdown_tail(ihid->ops);
>> }
>>
>> +static void i2c_hid_core_restore_sequence(struct i2c_hid *ihid)
>> +{
>> + if (!ihid->ops->restore_sequence)
>> + return;
>> +
>> + ihid->ops->restore_sequence(ihid->ops);
>> +}
>> +
>> static int i2c_hid_core_suspend(struct i2c_hid *ihid, bool force_poweroff)
>> {
>> struct i2c_client *client = ihid->client;
>> @@ -1360,8 +1368,26 @@ static int i2c_hid_core_pm_resume(struct device *dev)
>> return i2c_hid_core_resume(ihid);
>> }
>>
>> +static int i2c_hid_core_pm_restore(struct device *dev)
>> +{
>> + struct i2c_client *client = to_i2c_client(dev);
>> + struct i2c_hid *ihid = i2c_get_clientdata(client);
>> +
>> + if (ihid->is_panel_follower)
>> + return 0;
>> +
>> + i2c_hid_core_restore_sequence(ihid);
>> +
>> + return i2c_hid_core_resume(ihid);
>> +}
>> +
>> const struct dev_pm_ops i2c_hid_core_pm = {
>> - SYSTEM_SLEEP_PM_OPS(i2c_hid_core_pm_suspend, i2c_hid_core_pm_resume)
>> + .suspend = pm_sleep_ptr(i2c_hid_core_pm_suspend),
>> + .resume = pm_sleep_ptr(i2c_hid_core_pm_resume),
>> + .freeze = pm_sleep_ptr(i2c_hid_core_pm_suspend),
>> + .thaw = pm_sleep_ptr(i2c_hid_core_pm_resume),
>> + .poweroff = pm_sleep_ptr(i2c_hid_core_pm_suspend),
>> + .restore = pm_sleep_ptr(i2c_hid_core_pm_restore),
>> };
>> EXPORT_SYMBOL_GPL(i2c_hid_core_pm);
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.h b/drivers/hid/i2c-hid/i2c-hid.h
>> index 2c7b66d5caa0f..1724a435c783a 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.h
>> +++ b/drivers/hid/i2c-hid/i2c-hid.h
>> @@ -27,11 +27,13 @@ static inline u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product)
>> * @power_up: do sequencing to power up the device.
>> * @power_down: do sequencing to power down the device.
>> * @shutdown_tail: called at the end of shutdown.
>> + * @restore_sequence: hibernation restore sequence.
>> */
>> struct i2chid_ops {
>> int (*power_up)(struct i2chid_ops *ops);
>> void (*power_down)(struct i2chid_ops *ops);
>> void (*shutdown_tail)(struct i2chid_ops *ops);
>> + void (*restore_sequence)(struct i2chid_ops *ops);
>> };
>>
>> int i2c_hid_core_probe(struct i2c_client *client, struct i2chid_ops *ops,
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Resolve touchpad issues on Dell systems during S4
From: Benjamin Tissoires @ 2025-09-11 13:49 UTC (permalink / raw)
To: Mario Limonciello (AMD); +Cc: mario.limonciello, jikos, linux-input
In-Reply-To: <20250909110012.1218226-1-superm1@kernel.org>
Hi Mario,
On Sep 09 2025, Mario Limonciello (AMD) wrote:
> Dell systems utilize an EC-based touchpad emulation when the ACPI
> touchpad _DSM is not invoked. This emulation acts as a secondary
> master on the I2C bus, designed for scenarios where the I2C touchpad
> driver is absent, such as in BIOS menus. Typically, loading the
> i2c-hid module triggers the _DSM at initialization, disabling the
> EC-based emulation.
>
> However, if the i2c-hid module is missing from the boot kernel
> used for hibernation snapshot restoration, the _DSM remains
> uncalled, resulting in dual masters on the I2C bus and
> subsequent arbitration errors. This issue arises when i2c-hid
> resides in the rootfs instead of the kernel or initramfs.
In the downstream Red Hat bug it was mentioned that the kernel
configuration had an impact though. But as I understand it now that I'm
re-reading it for the 4th time:
- on stock fedora kernel (i2c-hid in initramfs): works
- on stock RHEL kernel (i2c-hid in initramfs): bug but config issue
- on vanilla kernel without i2c-hid in initramfs: bug fixed by that
patch
- on vanilla kernel with i2c-hid in initramfs: works
So that patch is needed no matter the config bug we have there and it
will also fix that config bug. Am I correct?
>
> To address this, switch from using the SYSTEM_SLEEP_PM_OPS()
> macro to dedicated callbacks, introducing a specific
> callback for restoring the S4 image. This callback ensures
> the _DSM is invoked.
I'm a little bit hesitant to include this patch without proper testing.
Did you run this through a wider range of laptops than just the
problematic one?
Other than that, patch looks good to me, but I would have liked to have
another opinion on it.
Cheers,
Benjamin
>
> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> drivers/hid/i2c-hid/i2c-hid-acpi.c | 8 ++++++++
> drivers/hid/i2c-hid/i2c-hid-core.c | 28 +++++++++++++++++++++++++++-
> drivers/hid/i2c-hid/i2c-hid.h | 2 ++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> index 1b49243adb16a..abd700a101f46 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> @@ -76,6 +76,13 @@ static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
> return hid_descriptor_address;
> }
>
> +static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
> +{
> + struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
> +
> + i2c_hid_acpi_get_descriptor(ihid_acpi);
> +}
> +
> static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
> {
> struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
> @@ -96,6 +103,7 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
>
> ihid_acpi->adev = ACPI_COMPANION(dev);
> ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
> + ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
>
> ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
> if (ret < 0)
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index d3912e3f2f13a..3257aa87be898 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -961,6 +961,14 @@ static void i2c_hid_core_shutdown_tail(struct i2c_hid *ihid)
> ihid->ops->shutdown_tail(ihid->ops);
> }
>
> +static void i2c_hid_core_restore_sequence(struct i2c_hid *ihid)
> +{
> + if (!ihid->ops->restore_sequence)
> + return;
> +
> + ihid->ops->restore_sequence(ihid->ops);
> +}
> +
> static int i2c_hid_core_suspend(struct i2c_hid *ihid, bool force_poweroff)
> {
> struct i2c_client *client = ihid->client;
> @@ -1360,8 +1368,26 @@ static int i2c_hid_core_pm_resume(struct device *dev)
> return i2c_hid_core_resume(ihid);
> }
>
> +static int i2c_hid_core_pm_restore(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct i2c_hid *ihid = i2c_get_clientdata(client);
> +
> + if (ihid->is_panel_follower)
> + return 0;
> +
> + i2c_hid_core_restore_sequence(ihid);
> +
> + return i2c_hid_core_resume(ihid);
> +}
> +
> const struct dev_pm_ops i2c_hid_core_pm = {
> - SYSTEM_SLEEP_PM_OPS(i2c_hid_core_pm_suspend, i2c_hid_core_pm_resume)
> + .suspend = pm_sleep_ptr(i2c_hid_core_pm_suspend),
> + .resume = pm_sleep_ptr(i2c_hid_core_pm_resume),
> + .freeze = pm_sleep_ptr(i2c_hid_core_pm_suspend),
> + .thaw = pm_sleep_ptr(i2c_hid_core_pm_resume),
> + .poweroff = pm_sleep_ptr(i2c_hid_core_pm_suspend),
> + .restore = pm_sleep_ptr(i2c_hid_core_pm_restore),
> };
> EXPORT_SYMBOL_GPL(i2c_hid_core_pm);
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.h b/drivers/hid/i2c-hid/i2c-hid.h
> index 2c7b66d5caa0f..1724a435c783a 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.h
> +++ b/drivers/hid/i2c-hid/i2c-hid.h
> @@ -27,11 +27,13 @@ static inline u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product)
> * @power_up: do sequencing to power up the device.
> * @power_down: do sequencing to power down the device.
> * @shutdown_tail: called at the end of shutdown.
> + * @restore_sequence: hibernation restore sequence.
> */
> struct i2chid_ops {
> int (*power_up)(struct i2chid_ops *ops);
> void (*power_down)(struct i2chid_ops *ops);
> void (*shutdown_tail)(struct i2chid_ops *ops);
> + void (*restore_sequence)(struct i2chid_ops *ops);
> };
>
> int i2c_hid_core_probe(struct i2c_client *client, struct i2chid_ops *ops,
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v1 03/14] dt-bindings: arm: mediatek: mmsys: Add assigned-clocks/rates properties
From: Ariel D'Alessandro @ 2025-09-11 13:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <898bf39e-1b34-40e9-bdfa-ec4eca1c3f7d@kernel.org>
Krzysztof,
On 9/9/25 3:29 AM, Krzysztof Kozlowski wrote:
> On 08/09/2025 21:19, Ariel D'Alessandro wrote:
>> Krzysztof,
>>
>> On 8/21/25 3:43 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Aug 20, 2025 at 02:12:51PM -0300, Ariel D'Alessandro wrote:
>>>> Current, the DT bindings for MediaTek mmsys controller is missing the
>>>> assigned-clocks and assigned-clocks-rates properties. Add these and
>>>
>>> No, they do not miss them. I don't understand why you are adding these.
>>
>> The reason I added these is due to the following check error:
>>
>> $ make -j$(nproc) CHECK_DTBS=y mediatek/mt8173-elm.dtb
>> DTC [C] arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
>> [...]
>> arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: syscon@14000000
>> (mediatek,mt8173-mmsys): 'assigned-clock-rates', 'assigned-clocks' do
>> not match any of the regexes: '^pinctrl-[0-9]+$'
>> from schema $id:
>> http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
>
> This is looking like missing clocks or other unevaluated property by the
> binding.
Agreed, the rate assignment has to be moved in other DT nodes, it's not
a binding issue.
Thanks,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 01/14] media: dt-bindings: Convert MediaTek mt8173-mdp bindings to YAML
From: Ariel D'Alessandro @ 2025-09-11 13:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <5421cfe7-dfe0-4bb8-8722-6f449cd365be@kernel.org>
Krzysztof,
On 9/9/25 3:32 AM, Krzysztof Kozlowski wrote:
> On 08/09/2025 19:52, Ariel D'Alessandro wrote:
>> Krzysztof,
>>
>> On 8/21/25 3:46 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Aug 20, 2025 at 02:12:49PM -0300, Ariel D'Alessandro wrote:
[...]
>>>> + - enum:
>>>> + - mediatek,mt8173-mdp-rdma
>>>> + - mediatek,mt8173-mdp-rsz
>>>> + - mediatek,mt8173-mdp-wdma
>>>> + - mediatek,mt8173-mdp-wrot
>>>> + - items:
>>>> + - enum:
>>>> + - mediatek,mt8173-mdp-rdma
>>>> + - mediatek,mt8173-mdp-rsz
>>>> + - mediatek,mt8173-mdp-wdma
>>>> + - mediatek,mt8173-mdp-wrot
>>>> + - const: mediatek,mt8173-mdp
>>>
>>> This makes no sense. How devices can be compatible and can not be
>>> compatible.
>>
>> According to the driver source code (and the previous txt mt8173-mdp
>> bindings), there must be a "controller node" with compatible
>> `mediatek,mt8173-mdp`. Then its sibling nodes (including itself) should
>
> But you did not define "mediatek,mt8173-mdp" here, so what are you
> talking about?
>
> I talk here about "wrot" and others, I thought it is obvious from the
> mistake in the schema.
Ack.
[...]
>>>> +
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + const: mediatek,mt8173-mdp
>>>
>>> This makes no sense either.
>>
>> Same question above about compatibles.
>
> How same question? Do you understand this code? It is nothing the same -
> you have here contains!
Ack. Will resubmit properly in v2.
Thanks,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v3 0/3] Add support for Awinic AW86927 haptic driver
From: Griffin Kroah-Hartman @ 2025-09-11 9:03 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Luca Weiss
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <20250814-aw86927-v3-0-c99434083e6a@fairphone.com>
On 8/14/25 16:31, Griffin Kroah-Hartman wrote:
> Add devicetree bindings and a driver for the AW86927 haptic driver, and
> add it to the devicetree for the Fairphone 5 smartphone.
>
> This driver does not enable all capabilities of the AW86927, features
> such as f0 detection, rtp mode, and cont mode are not included.
>
> Note: This is my first driver I have ever worked on so if there is
> anything I can do to improve it please let me know!
>
> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
> ---
> Changes in v3:
> - Removed obsolete FIXME comments
> - Adjusted Error handling to fit best practice
> - Changed formatting due to feedback
> - Removed obsolete terminology from patch subjects.
> - Properly credited reviewers
> - Link to v2: https://lore.kernel.org/r/20250811-aw86927-v2-0-64be8f3da560@fairphone.com
>
> Changes in v2:
> - Changed title and fixed license of devicetree binding
> - Fixed typo where the 'm' in 'ms' was excluded
> - Changed error handling return values in driver probe function
> - Link to v1: https://lore.kernel.org/r/20250806-aw86927-v1-0-23d8a6d0f2b2@fairphone.com
>
> ---
> Griffin Kroah-Hartman (3):
> dt-bindings: input: Add Awinic AW86927
> Input: aw86927 - add driver for Awinic AW86927
> arm64: dts: qcom: qcm6490-fairphone-fp5: Add vibrator support
>
> .../devicetree/bindings/input/awinic,aw86927.yaml | 48 ++
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 18 +-
> drivers/input/misc/Kconfig | 11 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/aw86927.c | 854 +++++++++++++++++++++
> 5 files changed, 931 insertions(+), 1 deletion(-)
> ---
> base-commit: 3624e9a34b36d64a7037946eda28ae9599363a3b
> change-id: 20250804-aw86927-9dddc32fcaec
>
> Best regards,
Hi Dmitry, did you get a chance to look at this patch series yet?
Thanks,
Griffin
^ permalink raw reply
* RE: [PATCH RESEND v2] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
From: Sun, Xinpeng @ 2025-09-11 1:21 UTC (permalink / raw)
To: srinivas pandruvada, jikos@kernel.org, bentiss@kernel.org
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhang, Rui1
In-Reply-To: <5c83a18128bbc0b8cfd6900439e7349250732659.camel@linux.intel.com>
> -----Original Message-----
> From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
> Sent: Saturday, September 6, 2025 12:55 AM
> To: Sun, Xinpeng <xinpeng.sun@intel.com>; jikos@kernel.org; bentiss@kernel.org
> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; Zhang, Rui1
> <rui1.zhang@intel.com>
> Subject: Re: [PATCH RESEND v2] hid: intel-thc-hid: intel-quicki2c: support ACPI
> config for advanced features
>
> On Fri, 2025-09-05 at 09:39 +0800, Xinpeng Sun wrote:
> > There is a new BIOS enhancement that adds the capability to configure
> > the following two features of I2C subsystem introduced in commit
> > 1ed0b48
> > ("Intel-thc: Introduce max input size control") and commit 3f2a921
> > ("Intel-thc: Introduce interrupt delay control"):
> > - Max input size control
> > - Interrupt delay control
> >
> > As BIOS is used for the configuration of these two features, change
> > driver data usage to indicate hardware capability, and add
> > corresponding ACPI configuration support in QuickI2C driver.
> >
> > Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
> > Tested-by: Rui Zhang <rui1.zhang@intel.com>
> > ---
> >
> Why the patch was resent?
>
> If maintainer didn't review, just remind them after atleast 2 weeks instead of
> sending again.
>
> For any other reason add some change log here.
Just rebase this patch because there is a conflict with latest main branch.
Thanks,
Xinpeng
>
> Thanks,
> Srinivas
>
>
>
> > .../intel-quicki2c/pci-quicki2c.c | 43 ++++++++++++++---
> > --
> > .../intel-quicki2c/quicki2c-dev.h | 24 ++++++++++-
> > 2 files changed, 55 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > index 854926b3cfd4..787c32557d24 100644
> > --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> > @@ -23,6 +23,7 @@
> >
> > static struct quicki2c_ddata ptl_ddata = {
> > .max_detect_size = MAX_RX_DETECT_SIZE_PTL,
> > + .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
> > };
> >
> > /* THC QuickI2C ACPI method to get device properties */ @@ -123,8
> > +124,8 @@ static int quicki2c_acpi_get_dsd_property(struct
> > acpi_device *adev, acpi_string
> > static int quicki2c_get_acpi_resources(struct quicki2c_device
> > *qcdev)
> > {
> > struct acpi_device *adev = ACPI_COMPANION(qcdev->dev);
> > - struct quicki2c_subip_acpi_parameter i2c_param;
> > - struct quicki2c_subip_acpi_config i2c_config;
> > + struct quicki2c_subip_acpi_parameter i2c_param = {0};
> > + struct quicki2c_subip_acpi_config i2c_config = {0};
> > u32 hid_desc_addr;
> > int ret = -EINVAL;
> >
> > @@ -200,6 +201,21 @@ static int quicki2c_get_acpi_resources(struct
> > quicki2c_device *qcdev)
> > return -EOPNOTSUPP;
> > }
> >
> > + if (qcdev->ddata) {
> > + qcdev->i2c_max_frame_size_enable = i2c_config.FSEN;
> > + qcdev->i2c_int_delay_enable = i2c_config.INDE;
> > +
> > + if (i2c_config.FSVL <= qcdev->ddata-
> > >max_detect_size)
> > + qcdev->i2c_max_frame_size = i2c_config.FSVL;
> > + else
> > + qcdev->i2c_max_frame_size = qcdev->ddata-
> > >max_detect_size;
> > +
> > + if (i2c_config.INDV <= qcdev->ddata-
> > >max_interrupt_delay)
> > + qcdev->i2c_int_delay = i2c_config.INDV;
> > + else
> > + qcdev->i2c_int_delay = qcdev->ddata-
> > >max_interrupt_delay;
> > + }
> > +
> > return 0;
> > }
> >
> > @@ -441,17 +457,24 @@ static void quicki2c_dma_adv_enable(struct
> > quicki2c_device *qcdev)
> > * max input length <= THC detect capability, enable the feature
> > with device
> > * max input length.
> > */
> > - if (qcdev->ddata->max_detect_size >=
> > - le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> > - thc_i2c_set_rx_max_size(qcdev->thc_hw,
> > - le16_to_cpu(qcdev-
> > >dev_desc.max_input_len));
> > + if (qcdev->i2c_max_frame_size_enable) {
> > + if (qcdev->i2c_max_frame_size >=
> > + le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> > + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> > + le16_to_cpu(qcdev-
> > >dev_desc.max_input_len));
> > + } else {
> > + dev_warn(qcdev->dev,
> > + "Max frame size is smaller than hid
> > max input length!");
> > + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> > + le16_to_cpu(qcdev-
> > >i2c_max_frame_size));
> > + }
> > thc_i2c_rx_max_size_enable(qcdev->thc_hw, true);
> > }
> >
> > /* If platform supports interrupt delay feature, enable it with
> > given delay */
> > - if (qcdev->ddata->interrupt_delay) {
> > + if (qcdev->i2c_int_delay_enable) {
> > thc_i2c_set_rx_int_delay(qcdev->thc_hw,
> > - qcdev->ddata-
> > >interrupt_delay);
> > + qcdev->i2c_int_delay * 10);
> > thc_i2c_rx_int_delay_enable(qcdev->thc_hw, true);
> > }
> > }
> > @@ -464,10 +487,10 @@ static void quicki2c_dma_adv_enable(struct
> > quicki2c_device *qcdev)
> > */
> > static void quicki2c_dma_adv_disable(struct quicki2c_device *qcdev)
> > {
> > - if (qcdev->ddata->max_detect_size)
> > + if (qcdev->i2c_max_frame_size_enable)
> > thc_i2c_rx_max_size_enable(qcdev->thc_hw, false);
> >
> > - if (qcdev->ddata->interrupt_delay)
> > + if (qcdev->i2c_int_delay_enable)
> > thc_i2c_rx_int_delay_enable(qcdev->thc_hw, false);
> > }
> >
> > diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> > b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> > index d412eafcf9ea..0d423d5dd7a7 100644
> > --- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> > +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> > @@ -38,6 +38,8 @@
> >
> > /* PTL Max packet size detection capability is 255 Bytes */
> > #define MAX_RX_DETECT_SIZE_PTL 255
> > +/* Max interrupt delay capability is 2.56ms */
> > +#define MAX_RX_INTERRUPT_DELAY 256
> >
> > /* Default interrupt delay is 1ms, suitable for most devices */
> > #define DEFAULT_INTERRUPT_DELAY_US (1 * USEC_PER_MSEC)
> > @@ -101,6 +103,10 @@ struct quicki2c_subip_acpi_parameter {
> > * @HMTD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line
> > Transmit HOLD Period
> > * @HMRD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line
> > Receive HOLD Period
> > * @HMSL: Maximum length (in ic_clk_cycles) of suppressed spikes in
> > High Speed Mode
> > + * @FSEN: Maximum Frame Size Feature Enable Control
> > + * @FSVL: Maximum Frame Size Value (unit in Bytes)
> > + * @INDE: Interrupt Delay Feature Enable Control
> > + * @INDV: Interrupt Delay Value (unit in 10 us)
> > *
> > * Those properties get from QUICKI2C_ACPI_METHOD_NAME_ISUB method,
> > used for
> > * I2C timing configure.
> > @@ -127,17 +133,22 @@ struct quicki2c_subip_acpi_config {
> > u64 HMTD;
> > u64 HMRD;
> > u64 HMSL;
> > +
> > + u64 FSEN;
> > + u64 FSVL;
> > + u64 INDE;
> > + u64 INDV;
> > u8 reserved;
> > };
> >
> > /**
> > * struct quicki2c_ddata - Driver specific data for quicki2c device
> > * @max_detect_size: Identify max packet size detect for rx
> > - * @interrupt_delay: Identify interrupt detect delay for rx
> > + * @interrupt_delay: Identify max interrupt detect delay for rx
> > */
> > struct quicki2c_ddata {
> > u32 max_detect_size;
> > - u32 interrupt_delay;
> > + u32 max_interrupt_delay;
> > };
> >
> > struct device;
> > @@ -170,6 +181,10 @@ struct acpi_device;
> > * @report_len: The length of input/output report packet
> > * @reset_ack_wq: Workqueue for waiting reset response from device
> > * @reset_ack: Indicate reset response received or not
> > + * @i2c_max_frame_size_enable: Indicate max frame size feature
> > enabled or not
> > + * @i2c_max_frame_size: Max RX frame size (unit in Bytes)
> > + * @i2c_int_delay_enable: Indicate interrupt delay feature enabled
> > or not
> > + * @i2c_int_delay: Interrupt detection delay value (unit in 10 us)
> > */
> > struct quicki2c_device {
> > struct device *dev;
> > @@ -200,6 +215,11 @@ struct quicki2c_device {
> >
> > wait_queue_head_t reset_ack_wq;
> > bool reset_ack;
> > +
> > + u32 i2c_max_frame_size_enable;
> > + u32 i2c_max_frame_size;
> > + u32 i2c_int_delay_enable;
> > + u32 i2c_int_delay;
> > };
> >
> > #endif /* _QUICKI2C_DEV_H_ */
^ permalink raw reply
* [PATCH 1/1] dt-bindings: touchscreen: resistive-adc-touch: change to unevaluatedProperties
From: Frank Li @ 2025-09-10 22:44 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Oleksij Rempel,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Change additionalProperties to unevaluatedProperties because it refs to
touchscreen.yaml.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-skov-revc-lt6.dtb: touchscreen (resistive-adc-touch): 'touchscreen-y-plate-ohms' does not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/input/touchscreen/resistive-adc-touch.yaml#
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../bindings/input/touchscreen/resistive-adc-touch.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml
index 7fc22a403d485..059d419f6c1c6 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml
@@ -55,7 +55,7 @@ properties:
touchscreen-min-pressure: true
touchscreen-x-plate-ohms: true
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] HID: lg-g15 - Add support for Logitech G13.
From: Hans de Goede @ 2025-09-10 19:16 UTC (permalink / raw)
To: Leo L. Schwab
Cc: Kate Hsuan, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <aMG9L2566Hh6b0Kf@ewhac.org>
Hi,
On 10-Sep-25 8:02 PM, Leo L. Schwab wrote:
> On Wed, Sep 10, 2025 at 01:09:10PM +0200, Hans de Goede wrote:
>> On 10-Sep-25 7:52 AM, Leo L. Schwab wrote:
>>> On Mon, Sep 08, 2025 at 11:08:29PM +0200, Hans de Goede wrote:
>>>> There are 2 improvements which I would like to see:
>>>>
>>>> 1. When the backlight is turned on through the button, you
>>>> should pass g15_led->brightness to the notify() call rather
>>>> then LED_FULL. GNOME will show an OSD with the new brightness
>>>> value shown as a mini progress bar similar to how it shows
>>>> speaker volume when doing mute/unmute. This mini progress
>>>> bar should show the actual brightness being restored, not
>>>> always full brightness.
>>>>
>>> If g15_led->brightness is subsequently changed, should a new
>>> notify() call also be made with that new brightness, i.e. should
>>> `hw_brightness_changed` be made to track `brightness`?
>>
>> No, hw_brightness_changed only track changes done independently
>> by the hw. sysfs writes should not call notify().
>>
> Erm... So brightness_hw_changed should only sample
> g15_led->brightness on first probe?
>
> What should happen in this case:
>
> * Driver loads, probes G13 backlight's current color, calculates
> brightness to be 50, sets both `brightness` and
> `brightness_hw_changed` sysfs values to 50.
> * User presses toggle key; backlight is now off.
> `brightness_hw_changed` now set to 0.
> `brightness` and RGB values remain unchanged.
> * User writes to `brightness` sysfs value, setting it to 255. This
> does *not* turn the backlight back on; `hw_brightness_changed`
> remains unchanged.
> * User presses toggle key; backlight is back on, showing the
> original color, but brighter.
>
> What should brightness_hw_changed be updated to, if anything?
Since the driver writes any new values to the G13 and the G13 accepts
those and remembers them even when the backlight is off,
the notify() should be passed g15_led->brightness when an
off -> on transition happens (and 0 or LED_OFF for the on -> off
transition).
Since g15_led->brightness gets initialized by reading the actual
setting from the G13 at probe time and then gets updated on
any successful completion if writing a new brightness value
to the G13, it should always reflect the value which the backlight
will be set at by the G13 after an off -> on transition.
Or am I missing something ?
In case of your example step above then the notify() should
be passed 255 as brightness and that should also be the value
in g15_led->brightness since g15_led->brightness gets set
to the brightness send to the G13 hw on a successful setting
of the report, right ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v3] HID: lg-g15 - Add support for Logitech G13.
From: Leo L. Schwab @ 2025-09-10 18:02 UTC (permalink / raw)
To: Hans de Goede
Cc: Kate Hsuan, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <a6ea0b5d-7586-4529-bf91-d8b966aa986e@kernel.org>
On Wed, Sep 10, 2025 at 01:09:10PM +0200, Hans de Goede wrote:
> On 10-Sep-25 7:52 AM, Leo L. Schwab wrote:
> > On Mon, Sep 08, 2025 at 11:08:29PM +0200, Hans de Goede wrote:
> >> There are 2 improvements which I would like to see:
> >>
> >> 1. When the backlight is turned on through the button, you
> >> should pass g15_led->brightness to the notify() call rather
> >> then LED_FULL. GNOME will show an OSD with the new brightness
> >> value shown as a mini progress bar similar to how it shows
> >> speaker volume when doing mute/unmute. This mini progress
> >> bar should show the actual brightness being restored, not
> >> always full brightness.
> >>
> > If g15_led->brightness is subsequently changed, should a new
> > notify() call also be made with that new brightness, i.e. should
> > `hw_brightness_changed` be made to track `brightness`?
>
> No, hw_brightness_changed only track changes done independently
> by the hw. sysfs writes should not call notify().
>
Erm... So brightness_hw_changed should only sample
g15_led->brightness on first probe?
What should happen in this case:
* Driver loads, probes G13 backlight's current color, calculates
brightness to be 50, sets both `brightness` and
`brightness_hw_changed` sysfs values to 50.
* User presses toggle key; backlight is now off.
`brightness_hw_changed` now set to 0.
`brightness` and RGB values remain unchanged.
* User writes to `brightness` sysfs value, setting it to 255. This
does *not* turn the backlight back on; `hw_brightness_changed`
remains unchanged.
* User presses toggle key; backlight is back on, showing the
original color, but brighter.
What should brightness_hw_changed be updated to, if anything?
> >> IMHO the best fix would be to use:
> >>
> >> hid_hw_raw_request(..., HID_INPUT_REPORT, HID_REQ_GET_REPORT);
> >> [ ... ]
> >
> > Will give this a try.
> >
Got this part working.
Schwab
^ permalink raw reply
* Re: [PATCH v1 13/14] dt-bindings: input/touchscreen: Convert MELFAS MIP4 Touchscreen to YAML
From: Ariel D'Alessandro @ 2025-09-10 16:01 UTC (permalink / raw)
To: Krzysztof Kozlowski, Linus Walleij, Dmitry Torokhov
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, edumazet, flora.fu, houlong.wei, jeesw, jmassot, kernel,
krzk+dt, kuba, kyrie.wu, lgirdwood, louisalexis.eyraud,
maarten.lankhorst, matthias.bgg, mchehab, minghsiu.tsai, mripard,
p.zabel, pabeni, robh, sean.wang, simona, support.opensource,
tiffany.lin, tzimmermann, yunfei.dong, devicetree, dri-devel,
linux-arm-kernel, linux-clk, linux-gpio, linux-input,
linux-kernel, linux-media, linux-mediatek, linux-sound, netdev
In-Reply-To: <f199fc0b-20c0-4c22-b0ed-c508514b60c6@kernel.org>
Krzysztof, all,
On 9/9/25 3:56 AM, Krzysztof Kozlowski wrote:
> On 05/09/2025 13:33, Linus Walleij wrote:
>> On Fri, Sep 5, 2025 at 12:02 PM Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>>> On Thu, Aug 21, 2025 at 01:56:24PM +0200, Linus Walleij wrote:
>>>> Hi Ariel,
>>>>
>>>> thanks for your patch!
>>>>
>>>> On Wed, Aug 20, 2025 at 7:17 PM Ariel D'Alessandro
>>>> <ariel.dalessandro@collabora.com> wrote:
>>>>
>>>>> + ce-gpios:
>>>>> + description: GPIO connected to the CE (chip enable) pin of the chip
>>>>> + maxItems: 1
>>>>
>>>> Mention that this should always have the flag GPIO_ACTIVE_HIGH
>>>> as this is required by the hardware.
>>>>
>>>> Unfortunately we have no YAML syntax for enforcing flags :/
>>>
>>> Theoretically there can be an inverter on the line, so from the AP point
>>> of view the line is active low while from the peripheral POV the pin is
>>> active high...
>>
>> Yes, I think someone even proposed adding inverters to the
>> device tree and was nixed.
>
> It's not about DT, it's about board design - you can (almost?) always
> invert the logical signal, so this should match what hardware requires
> plus any inverter on the board.
>
>
>>
>> It's a matter of phrasing I would say:
>>
>> "Mention that this should nominally have the flag GPIO_ACTIVE_HIGH
>
> No, please do not, it is wrong. If hardware requires active high, then
> just say this is active high. But the actual GPIO flag depends on the
> board design if signal is inverted.
After the discussion from this thread, will mark it a "active high" in
the property description for v2.
Thanks,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS d5ad57fc428c1e44335d25c822eb89645f425f32
From: kernel test robot @ 2025-09-10 15:55 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: d5ad57fc428c1e44335d25c822eb89645f425f32 dt-bindings: input: qcom,pm8941-pwrkey: Fix formatting of descriptions
elapsed time: 1440m
configs tested: 129
configs skipped: 8
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc axs101_defconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc randconfig-001-20250910 gcc-13.4.0
arc randconfig-002-20250910 gcc-8.5.0
arm allmodconfig gcc-15.1.0
arm allnoconfig clang-22
arm allyesconfig gcc-15.1.0
arm randconfig-001-20250910 gcc-8.5.0
arm randconfig-002-20250910 gcc-8.5.0
arm randconfig-003-20250910 clang-16
arm randconfig-004-20250910 gcc-8.5.0
arm spitz_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 randconfig-001-20250910 clang-22
arm64 randconfig-002-20250910 clang-22
arm64 randconfig-003-20250910 gcc-9.5.0
arm64 randconfig-004-20250910 gcc-13.4.0
csky allnoconfig gcc-15.1.0
csky randconfig-001-20250910 gcc-12.5.0
csky randconfig-002-20250910 gcc-15.1.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon randconfig-001-20250910 clang-22
hexagon randconfig-002-20250910 clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20250910 gcc-14
i386 buildonly-randconfig-002-20250910 gcc-13
i386 buildonly-randconfig-003-20250910 clang-20
i386 buildonly-randconfig-004-20250910 clang-20
i386 buildonly-randconfig-005-20250910 gcc-14
i386 buildonly-randconfig-006-20250910 clang-20
i386 defconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch randconfig-001-20250910 clang-18
loongarch randconfig-002-20250910 clang-18
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
m68k m5307c3_defconfig gcc-15.1.0
microblaze allmodconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20250910 gcc-11.5.0
nios2 randconfig-002-20250910 gcc-9.5.0
openrisc allnoconfig gcc-15.1.0
openrisc allyesconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc alldefconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250910 gcc-10.5.0
parisc randconfig-002-20250910 gcc-9.5.0
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig gcc-15.1.0
powerpc allyesconfig clang-22
powerpc cell_defconfig gcc-15.1.0
powerpc ge_imp3a_defconfig gcc-15.1.0
powerpc randconfig-001-20250910 gcc-8.5.0
powerpc randconfig-002-20250910 gcc-8.5.0
powerpc randconfig-003-20250910 clang-22
powerpc64 randconfig-001-20250910 gcc-12.5.0
powerpc64 randconfig-002-20250910 gcc-11.5.0
powerpc64 randconfig-003-20250910 clang-22
riscv allmodconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv randconfig-001-20250910 clang-22
riscv randconfig-002-20250910 clang-22
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 randconfig-001-20250910 clang-22
s390 randconfig-002-20250910 clang-22
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-15.1.0
sh randconfig-001-20250910 gcc-15.1.0
sh randconfig-002-20250910 gcc-12.5.0
sh sh7785lcr_defconfig gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250910 gcc-8.5.0
sparc randconfig-002-20250910 gcc-8.5.0
sparc64 defconfig clang-20
sparc64 randconfig-001-20250910 gcc-8.5.0
sparc64 randconfig-002-20250910 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-14
um defconfig clang-22
um i386_defconfig gcc-14
um randconfig-001-20250910 clang-22
um randconfig-002-20250910 clang-22
um x86_64_defconfig clang-22
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250910 gcc-14
x86_64 buildonly-randconfig-002-20250910 clang-20
x86_64 buildonly-randconfig-003-20250910 gcc-14
x86_64 buildonly-randconfig-004-20250910 clang-20
x86_64 buildonly-randconfig-005-20250910 gcc-14
x86_64 buildonly-randconfig-006-20250910 clang-20
x86_64 defconfig gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250910 gcc-8.5.0
xtensa randconfig-002-20250910 gcc-10.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 13/14] dt-bindings: input/touchscreen: Convert MELFAS MIP4 Touchscreen to YAML
From: Ariel D'Alessandro @ 2025-09-10 15:51 UTC (permalink / raw)
To: Rob Herring
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
sean.wang, simona, support.opensource, tiffany.lin, tzimmermann,
yunfei.dong, devicetree, dri-devel, linux-arm-kernel, linux-clk,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250822155257.GA3865729-robh@kernel.org>
Rob,
On 8/22/25 12:52 PM, Rob Herring wrote:
> On Wed, Aug 20, 2025 at 02:13:01PM -0300, Ariel D'Alessandro wrote:
>> Convert the existing text-based DT bindings for MELFAS MIP4 Touchscreen
>> controller to a YAML schema.
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../input/touchscreen/melfas,mip4_ts.yaml | 55 +++++++++++++++++++
>> .../input/touchscreen/melfas_mip4.txt | 20 -------
>> 2 files changed, 55 insertions(+), 20 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/melfas,mip4_ts.yaml
>> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/melfas_mip4.txt
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/melfas,mip4_ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/melfas,mip4_ts.yaml
>> new file mode 100644
>> index 0000000000000..170fd4212467e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/melfas,mip4_ts.yaml
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/input/touchscreen/melfas,mip4_ts.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: MELFAS MIP4 Touchscreen
>> +
>> +maintainers:
>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> +
>> +properties:
>> + compatible:
>> + const: "melfas,mip4_ts"
>
> Drop quotes. With that,
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Ack.
Thanks,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 07/14] dt-bindings: display: mediatek,ufoe: Add mediatek,gce-client-reg property
From: Ariel D'Alessandro @ 2025-09-10 15:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <a37db87d-c3b1-4ce4-bec0-4f496dc209b5@kernel.org>
Krzysztof,
On 9/10/25 11:21 AM, Krzysztof Kozlowski wrote:
> On 10/09/2025 16:04, Ariel D'Alessandro wrote:
>> Krzysztof,
>>
>> On 8/21/25 3:50 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Aug 20, 2025 at 02:12:55PM -0300, Ariel D'Alessandro wrote:
>>>> Current, the DT bindings for Mediatek UFOe (Unified Frame Optimization
>>>> engine) is missing the mediatek,gce-client-reg property. Add it and
>>>
>>> Why is it missing? If the binding is complete, it cannot be missing...
>>
>> Due to the following error:
>>
>> $ make -j$(nproc) CHECK_DTBS=y mediatek/mt8173-elm.dtb
>> SCHEMA Documentation/devicetree/bindings/processed-schema.json
>> DTC [C] arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
>> [...]
>> arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: ufoe@1401a000
>> (mediatek,mt8173-disp-ufoe): 'mediatek,gce-client-reg' does not match
>> any of the regexes: '^pinctrl-[0-9]+$'
>> from schema $id:
>> http://devicetree.org/schemas/display/mediatek/mediatek,ufoe.yaml#
>
> So there are users of it? Then please explain that.
Ack. Will fix in v2. Thanks.
>
>>
>>>
>>>> update the example as well.
>>>>
>>>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>>>> ---
>>>> .../bindings/display/mediatek/mediatek,ufoe.yaml | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>>>> index 61a5e22effbf2..ecb4c0359fec3 100644
>>>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>>>> @@ -64,6 +64,14 @@ properties:
>>>> - port@0
>>>> - port@1
>>>>
>>>> + mediatek,gce-client-reg:
>>>> + description: The register of client driver can be configured by gce with
>>>> + 4 arguments defined in this property, such as phandle of gce, subsys id,
>>>> + register offset and size. Each GCE subsys id is mapping to a client
>>>
>>> Don't explain what DT syntax is. We all know, so that's completely
>>> redundant description. Explain the purpose. Explain Arguments with sechema - items.
>>
>> Although I agree with your suggestions, this is exactly how the rest of
>> the Mediatek DT bindings describe this node. This patch is based on the
>> other +20 files, which describe the node in the same way.
>
>
> Last time I tried to fix something for Mediatek display I got
> condescending and useless review from Collabora, so I won't be bothering
> with fixing these bindings to make your job easier. I don't care, you
> can thank someone inside. Therefore other poor bindings are not a valid
> excuse for this patch not being correct.
I see. Will rework this properly in v2.
Thanks,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [RESEND PATCH 4/4] Input: imx6ul_tsc - use BIT, FIELD_{GET,PREP} and GENMASK macros
From: Frank Li @ 2025-09-10 15:40 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Dmitry Torokhov, Fabio Estevam,
Michael Trimarchi, Pengutronix Kernel Team, Sascha Hauer,
Shawn Guo, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250910135916.3939502-5-dario.binacchi@amarulasolutions.com>
On Wed, Sep 10, 2025 at 03:58:38PM +0200, Dario Binacchi wrote:
> Replace opencoded masking and shifting, with BIT(), GENMASK(),
> FIELD_GET() and FIELD_PREP() macros.
Add "No functional change." to help filter out if need bisect.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
This cleanup patch should follow patch1, which is typo fix.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> drivers/input/touchscreen/imx6ul_tsc.c | 88 ++++++++++++++------------
> 1 file changed, 48 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
> index a6066643bd48..e74999c5e22f 100644
> --- a/drivers/input/touchscreen/imx6ul_tsc.c
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -21,25 +21,23 @@
> #include <linux/log2.h>
>
> /* ADC configuration registers field define */
> -#define ADC_AIEN (0x1 << 7)
> +#define ADC_AIEN BIT(7)
> +#define ADC_ADCH_MASK GENMASK(4, 0)
> #define ADC_CONV_DISABLE 0x1F
> -#define ADC_AVGE (0x1 << 5)
> -#define ADC_CAL (0x1 << 7)
> -#define ADC_CALF 0x2
> -#define ADC_12BIT_MODE (0x2 << 2)
> -#define ADC_CONV_MODE_MASK (0x3 << 2)
> +#define ADC_AVGE BIT(5)
> +#define ADC_CAL BIT(7)
> +#define ADC_CALF BIT(1)
> +#define ADC_CONV_MODE_MASK GENMASK(3, 2)
> +#define ADC_12BIT_MODE 0x2
> #define ADC_IPG_CLK 0x00
> -#define ADC_INPUT_CLK_MASK 0x3
> -#define ADC_CLK_DIV_8 (0x03 << 5)
> -#define ADC_CLK_DIV_MASK (0x3 << 5)
> -#define ADC_SHORT_SAMPLE_MODE (0x0 << 4)
> -#define ADC_SAMPLE_MODE_MASK (0x1 << 4)
> -#define ADC_HARDWARE_TRIGGER (0x1 << 13)
> -#define ADC_AVGS_SHIFT 14
> -#define ADC_AVGS_MASK (0x3 << 14)
> +#define ADC_INPUT_CLK_MASK GENMASK(1, 0)
> +#define ADC_CLK_DIV_8 0x03
> +#define ADC_CLK_DIV_MASK GENMASK(6, 5)
> +#define ADC_SAMPLE_MODE BIT(4)
> +#define ADC_HARDWARE_TRIGGER BIT(13)
> +#define ADC_AVGS_MASK GENMASK(15, 14)
> #define SELECT_CHANNEL_4 0x04
> #define SELECT_CHANNEL_1 0x01
> -#define DISABLE_CONVERSION_INT (0x0 << 7)
>
> /* ADC registers */
> #define REG_ADC_HC0 0x00
> @@ -66,20 +64,26 @@
> #define REG_TSC_DEBUG_MODE 0x70
> #define REG_TSC_DEBUG_MODE2 0x80
>
> +/* TSC_MEASURE_VALUE register field define */
> +#define X_VALUE_MASK GENMASK(27, 16)
> +#define Y_VALUE_MASK GENMASK(11, 0)
> +
> /* TSC configuration registers field define */
> -#define DETECT_4_WIRE_MODE (0x0 << 4)
> -#define AUTO_MEASURE 0x1
> -#define MEASURE_SIGNAL 0x1
> -#define DETECT_SIGNAL (0x1 << 4)
> -#define VALID_SIGNAL (0x1 << 8)
> -#define MEASURE_INT_EN 0x1
> -#define MEASURE_SIG_EN 0x1
> -#define VALID_SIG_EN (0x1 << 8)
> +#define MEASURE_DELAY_TIME_MASK GENMASK(31, 8)
> +#define DETECT_5_WIRE_MODE BIT(4)
> +#define AUTO_MEASURE BIT(0)
> +#define MEASURE_SIGNAL BIT(0)
> +#define DETECT_SIGNAL BIT(4)
> +#define VALID_SIGNAL BIT(8)
> +#define MEASURE_INT_EN BIT(0)
> +#define MEASURE_SIG_EN BIT(0)
> +#define VALID_SIG_EN BIT(8)
> #define DE_GLITCH_MASK GENMASK(30, 29)
> #define DE_GLITCH_DEF 0x02
> -#define START_SENSE (0x1 << 12)
> -#define TSC_DISABLE (0x1 << 16)
> +#define START_SENSE BIT(12)
> +#define TSC_DISABLE BIT(16)
> #define DETECT_MODE 0x2
> +#define STATE_MACHINE_MASK GENMASK(22, 20)
>
> struct imx6ul_tsc {
> struct device *dev;
> @@ -115,19 +119,20 @@ static int imx6ul_adc_init(struct imx6ul_tsc *tsc)
>
> adc_cfg = readl(tsc->adc_regs + REG_ADC_CFG);
> adc_cfg &= ~(ADC_CONV_MODE_MASK | ADC_INPUT_CLK_MASK);
> - adc_cfg |= ADC_12BIT_MODE | ADC_IPG_CLK;
> - adc_cfg &= ~(ADC_CLK_DIV_MASK | ADC_SAMPLE_MODE_MASK);
> - adc_cfg |= ADC_CLK_DIV_8 | ADC_SHORT_SAMPLE_MODE;
> + adc_cfg |= FIELD_PREP(ADC_CONV_MODE_MASK, ADC_12BIT_MODE) |
> + FIELD_PREP(ADC_INPUT_CLK_MASK, ADC_IPG_CLK);
> + adc_cfg &= ~(ADC_CLK_DIV_MASK | ADC_SAMPLE_MODE);
> + adc_cfg |= FIELD_PREP(ADC_CLK_DIV_MASK, ADC_CLK_DIV_8);
> if (tsc->average_enable) {
> adc_cfg &= ~ADC_AVGS_MASK;
> - adc_cfg |= (tsc->average_select) << ADC_AVGS_SHIFT;
> + adc_cfg |= FIELD_PREP(ADC_AVGS_MASK, tsc->average_select);
> }
> adc_cfg &= ~ADC_HARDWARE_TRIGGER;
> writel(adc_cfg, tsc->adc_regs + REG_ADC_CFG);
>
> /* enable calibration interrupt */
> adc_hc |= ADC_AIEN;
> - adc_hc |= ADC_CONV_DISABLE;
> + adc_hc |= FIELD_PREP(ADC_ADCH_MASK, ADC_CONV_DISABLE);
> writel(adc_hc, tsc->adc_regs + REG_ADC_HC0);
>
> /* start ADC calibration */
> @@ -167,19 +172,21 @@ static void imx6ul_tsc_channel_config(struct imx6ul_tsc *tsc)
> {
> u32 adc_hc0, adc_hc1, adc_hc2, adc_hc3, adc_hc4;
>
> - adc_hc0 = DISABLE_CONVERSION_INT;
> + adc_hc0 = FIELD_PREP(ADC_AIEN, 0);
> writel(adc_hc0, tsc->adc_regs + REG_ADC_HC0);
>
> - adc_hc1 = DISABLE_CONVERSION_INT | SELECT_CHANNEL_4;
> + adc_hc1 = FIELD_PREP(ADC_AIEN, 0) |
> + FIELD_PREP(ADC_ADCH_MASK, SELECT_CHANNEL_4);
> writel(adc_hc1, tsc->adc_regs + REG_ADC_HC1);
>
> - adc_hc2 = DISABLE_CONVERSION_INT;
> + adc_hc2 = FIELD_PREP(ADC_AIEN, 0);
> writel(adc_hc2, tsc->adc_regs + REG_ADC_HC2);
>
> - adc_hc3 = DISABLE_CONVERSION_INT | SELECT_CHANNEL_1;
> + adc_hc3 = FIELD_PREP(ADC_AIEN, 0) |
> + FIELD_PREP(ADC_ADCH_MASK, SELECT_CHANNEL_1);
> writel(adc_hc3, tsc->adc_regs + REG_ADC_HC3);
>
> - adc_hc4 = DISABLE_CONVERSION_INT;
> + adc_hc4 = FIELD_PREP(ADC_AIEN, 0);
> writel(adc_hc4, tsc->adc_regs + REG_ADC_HC4);
> }
>
> @@ -194,8 +201,9 @@ static void imx6ul_tsc_set(struct imx6ul_tsc *tsc)
> u32 debug_mode2;
> u32 start;
>
> - basic_setting |= tsc->measure_delay_time << 8;
> - basic_setting |= DETECT_4_WIRE_MODE | AUTO_MEASURE;
> + basic_setting |= FIELD_PREP(MEASURE_DELAY_TIME_MASK,
> + tsc->measure_delay_time);
> + basic_setting |= AUTO_MEASURE;
> writel(basic_setting, tsc->tsc_regs + REG_TSC_BASIC_SETTING);
>
> debug_mode2 = FIELD_PREP(DE_GLITCH_MASK, tsc->de_glitch);
> @@ -255,7 +263,7 @@ static bool tsc_wait_detect_mode(struct imx6ul_tsc *tsc)
>
> usleep_range(200, 400);
> debug_mode2 = readl(tsc->tsc_regs + REG_TSC_DEBUG_MODE2);
> - state_machine = (debug_mode2 >> 20) & 0x7;
> + state_machine = FIELD_GET(STATE_MACHINE_MASK, debug_mode2);
> } while (state_machine != DETECT_MODE);
>
> usleep_range(200, 400);
> @@ -283,8 +291,8 @@ static irqreturn_t tsc_irq_fn(int irq, void *dev_id)
>
> if (status & MEASURE_SIGNAL) {
> value = readl(tsc->tsc_regs + REG_TSC_MEASURE_VALUE);
> - x = (value >> 16) & 0x0fff;
> - y = value & 0x0fff;
> + x = FIELD_GET(X_VALUE_MASK, value);
> + y = FIELD_GET(Y_VALUE_MASK, value);
>
> /*
> * In detect mode, we can get the xnur gpio value,
> --
> 2.43.0
>
^ permalink raw reply
* Re: [RESEND PATCH 1/4] Input: imx6ul_tsc - fix typo in register name
From: Frank Li @ 2025-09-10 15:30 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Michael Trimarchi, Dmitry Torokhov,
Fabio Estevam, Pengutronix Kernel Team, Sascha Hauer, Shawn Guo,
imx, linux-arm-kernel, linux-input
In-Reply-To: <20250910135916.3939502-2-dario.binacchi@amarulasolutions.com>
On Wed, Sep 10, 2025 at 03:58:35PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi <michael@amarulasolutions.com>
>
> Replace 'SETING' with 'SETTING'.
>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
>
> drivers/input/touchscreen/imx6ul_tsc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
> index 6ac8fa84ed9f..c2c6e50efc54 100644
> --- a/drivers/input/touchscreen/imx6ul_tsc.c
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -55,7 +55,7 @@
> #define ADC_TIMEOUT msecs_to_jiffies(100)
>
> /* TSC registers */
> -#define REG_TSC_BASIC_SETING 0x00
> +#define REG_TSC_BASIC_SETTING 0x00
> #define REG_TSC_PRE_CHARGE_TIME 0x10
> #define REG_TSC_FLOW_CONTROL 0x20
> #define REG_TSC_MEASURE_VALUE 0x30
> @@ -192,7 +192,7 @@ static void imx6ul_tsc_set(struct imx6ul_tsc *tsc)
>
> basic_setting |= tsc->measure_delay_time << 8;
> basic_setting |= DETECT_4_WIRE_MODE | AUTO_MEASURE;
> - writel(basic_setting, tsc->tsc_regs + REG_TSC_BASIC_SETING);
> + writel(basic_setting, tsc->tsc_regs + REG_TSC_BASIC_SETTING);
>
> writel(DE_GLITCH_2, tsc->tsc_regs + REG_TSC_DEBUG_MODE2);
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [RESEND PATCH 2/4] dt-bindings: input: touchscreen: fsl,imx6ul-tsc: add fsl,glitch-threshold
From: Frank Li @ 2025-09-10 15:29 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Conor Dooley, Dmitry Torokhov,
Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250910135916.3939502-3-dario.binacchi@amarulasolutions.com>
On Wed, Sep 10, 2025 at 03:58:36PM +0200, Dario Binacchi wrote:
> Add support for glitch threshold configuration. A detected signal is valid
> only if it lasts longer than the set threshold; otherwise, it is regarded
> as a glitch.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> ---
>
> .../input/touchscreen/fsl,imx6ul-tsc.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> index 678756ad0f92..2fee2940213f 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> @@ -62,6 +62,23 @@ properties:
> description: Number of data samples which are averaged for each read.
> enum: [ 1, 4, 8, 16, 32 ]
>
> + fsl,glitch-threshold:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> + enum: [ 0, 1, 2, 3 ]
> + description: |
> + Indicates the glitch threshold. The threshold is defined by number
> + of clock cycles. A detect signal is only valid if it is exist longer
> + than threshold; otherwise, it is regarded as a glitch.
> + 0: Normal function: 8191 clock cycles
> + Low power mode: 9 clock cycles
> + 1: Normal function: 4095 clock cycles
> + Low power mode: 7 clock cycles
> + 2: Normal function: 2047 clock cycles
> + Low power mode: 5 clock cycles
> + 3: Normal function: 1023 clock cycles
> + Low power mode: 3 clock cycles
> +
does any property in input/touchscreen/touchscreen.yaml use as it?
Suppose all touch screen have similar property to filiter out glitch.
Frank
> required:
> - compatible
> - reg
> @@ -94,4 +111,5 @@ examples:
> measure-delay-time = <0xfff>;
> pre-charge-time = <0xffff>;
> touchscreen-average-samples = <32>;
> + fsl,glitch-threshold = <2>;
> };
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v1 14/14] dt-bindings: media: mediatek,jpeg: Fix jpeg encoder/decoder ranges
From: Ariel D'Alessandro @ 2025-09-10 15:02 UTC (permalink / raw)
To: Rob Herring
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
sean.wang, simona, support.opensource, tiffany.lin, tzimmermann,
yunfei.dong, devicetree, dri-devel, linux-arm-kernel, linux-clk,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250820185508.GA273751-robh@kernel.org>
Rob,
On 8/20/25 3:55 PM, Rob Herring wrote:
> On Wed, Aug 20, 2025 at 02:13:02PM -0300, Ariel D'Alessandro wrote:
>> Commit 14176e94bb35d ("arm64: dts: mediatek: mt8195: Fix ranges for jpeg
>
> That commit is not in any upstream tree.
Ugh, indeed. Dropping this patch.
>
>> enc/decoder nodes") redefined jpeg encoder/decoder children node ranges.
>> Update the related device tree binding yaml definition to match
>> mediatek/mt8195.dtsi, as this is currently the only one using it.
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../media/mediatek,mt8195-jpegdec.yaml | 31 ++++++++++---------
>> .../media/mediatek,mt8195-jpegenc.yaml | 15 ++++-----
>> 2 files changed, 24 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
>> index e5448c60e3eb5..b1f3df258dc87 100644
>> --- a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
>> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
>> @@ -36,7 +36,7 @@ properties:
>>
>> # Required child node:
>> patternProperties:
>> - "^jpgdec@[0-9a-f]+$":
>> + "^jpgdec@[0-9],[0-9a-f]+$":
>
> This is wrong unless 0-9 is a separate, distinct address (like a chip
> select #).
Ack.
Thanks for the feedback.
Regards,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 10/14] regulator: dt-bindings: Convert Dialog Semiconductor DA9211 Regulators to YAML
From: Ariel D'Alessandro @ 2025-09-10 14:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250821-practical-coyote-of-hail-d2fddb@kuoka>
Krzysztof,
On 8/21/25 3:53 AM, Krzysztof Kozlowski wrote:
> On Wed, Aug 20, 2025 at 02:12:58PM -0300, Ariel D'Alessandro wrote:
>> Convert the existing text-based DT bindings for Dialog Semiconductor DA9211
>> Voltage Regulators family to a YAML schema. Examples are simplified, as
>> these are all equal.
>
> Also not wrapped... fix your editor to recognize how commits are
> written.
Ack.
>
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>
> ...
>
>> +---
>> +$id: http://devicetree.org/schemas/regulator/dlg,da9211.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: |
>
> Drop |
Ack.
>
>> + Dialog Semiconductor DA9211/DA9212/DA9213/DA9223/DA9214/DA9224/DA9215/DA9225
>> + Voltage Regulator
>> +
>> +maintainers:
>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - "dlg,da9211"
>> + - "dlg,da9212"
>> + - "dlg,da9213"
>> + - "dlg,da9223"
>> + - "dlg,da9214"
>> + - "dlg,da9224"
>> + - "dlg,da9215"
>> + - "dlg,da9225"
>
> No quotes. I don't think this was ever tested.
Ack.
>
> Also, keep it properly ordered
Good catch, thanks.
>
>
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + regulators:
>> + type: object
>> + additionalProperties: false
>> + description: |
>
> Drop |
Ack.
>
>> + List of regulators provided by the device
>> +
>> + patternProperties:
>> + "^BUCK([A-B])$":
>
> [AB]
Ack.
>
>> + type: object
>> + $ref: regulator.yaml#
>> + description: |
>> + Properties for a single BUCK regulator
>> +
>> + properties:
>> + regulator-initial-mode:
>> + items:
>> + enum: [ 1, 2, 3 ]
>> + description: Defined in include/dt-bindings/regulator/dlg,da9211-regulator.h
>> +
>> + regulator-allowed-modes:
>> + items:
>> + enum: [ 1, 2, 3 ]
>> + description: Defined in include/dt-bindings/regulator/dlg,da9211-regulator.h
>> +
>> + enable-gpios:
>> + maxItems: 1
>> + description: Specify a valid GPIO for platform control of the regulator
>
> Drop description, obvious.
Ack.
>
>> +
>> + unevaluatedProperties: false
>
> For nested blocks this goes after $ref: regulator.
Ack.
>
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> + - regulators
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/regulator/dlg,da9211-regulator.h>
>> +
>> + i2c1 {
>
> i2c
Ack.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + da9212: da9212@68 {
>
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
Ack, thanks a lot for your help.
Regards,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* [PATCH] MAINTAINERS: Input: Drop melfas-mip4 section
From: Krzysztof Kozlowski @ 2025-09-10 14:25 UTC (permalink / raw)
To: Dmitry Torokhov, Krzysztof Kozlowski, linux-input, linux-kernel
Emails to the sole melfas-mip4 driver maintainer bounce:
550 <jeesw@melfas.com> No such user here (connected from melfas.com)
so clearly this is not a supported driver anymore.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
MAINTAINERS | 7 -------
1 file changed, 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 135c03ac1bb0..f8e45e0ad5e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15863,13 +15863,6 @@ S: Supported
W: http://www.melexis.com
F: drivers/iio/temperature/mlx90635.c
-MELFAS MIP4 TOUCHSCREEN DRIVER
-M: Sangwon Jee <jeesw@melfas.com>
-S: Supported
-W: http://www.melfas.com
-F: Documentation/devicetree/bindings/input/touchscreen/melfas_mip4.txt
-F: drivers/input/touchscreen/melfas_mip4.c
-
MELLANOX BLUEFIELD I2C DRIVER
M: Khalil Blaiech <kblaiech@nvidia.com>
M: Asmaa Mnebhi <asmaa@nvidia.com>
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v1 07/14] dt-bindings: display: mediatek,ufoe: Add mediatek,gce-client-reg property
From: Krzysztof Kozlowski @ 2025-09-10 14:21 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <28049fe0-0ae7-4b40-9f95-1513e317547f@collabora.com>
On 10/09/2025 16:04, Ariel D'Alessandro wrote:
> Krzysztof,
>
> On 8/21/25 3:50 AM, Krzysztof Kozlowski wrote:
>> On Wed, Aug 20, 2025 at 02:12:55PM -0300, Ariel D'Alessandro wrote:
>>> Current, the DT bindings for Mediatek UFOe (Unified Frame Optimization
>>> engine) is missing the mediatek,gce-client-reg property. Add it and
>>
>> Why is it missing? If the binding is complete, it cannot be missing...
>
> Due to the following error:
>
> $ make -j$(nproc) CHECK_DTBS=y mediatek/mt8173-elm.dtb
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> DTC [C] arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
> [...]
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: ufoe@1401a000
> (mediatek,mt8173-disp-ufoe): 'mediatek,gce-client-reg' does not match
> any of the regexes: '^pinctrl-[0-9]+$'
> from schema $id:
> http://devicetree.org/schemas/display/mediatek/mediatek,ufoe.yaml#
So there are users of it? Then please explain that.
>
>>
>>> update the example as well.
>>>
>>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>>> ---
>>> .../bindings/display/mediatek/mediatek,ufoe.yaml | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>>> index 61a5e22effbf2..ecb4c0359fec3 100644
>>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>>> @@ -64,6 +64,14 @@ properties:
>>> - port@0
>>> - port@1
>>>
>>> + mediatek,gce-client-reg:
>>> + description: The register of client driver can be configured by gce with
>>> + 4 arguments defined in this property, such as phandle of gce, subsys id,
>>> + register offset and size. Each GCE subsys id is mapping to a client
>>
>> Don't explain what DT syntax is. We all know, so that's completely
>> redundant description. Explain the purpose. Explain Arguments with sechema - items.
>
> Although I agree with your suggestions, this is exactly how the rest of
> the Mediatek DT bindings describe this node. This patch is based on the
> other +20 files, which describe the node in the same way.
Last time I tried to fix something for Mediatek display I got
condescending and useless review from Collabora, so I won't be bothering
with fixing these bindings to make your job easier. I don't care, you
can thank someone inside. Therefore other poor bindings are not a valid
excuse for this patch not being correct.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 07/14] dt-bindings: display: mediatek,ufoe: Add mediatek,gce-client-reg property
From: Ariel D'Alessandro @ 2025-09-10 14:04 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250821-wandering-vermilion-pigeon-b8c9f0@kuoka>
Krzysztof,
On 8/21/25 3:50 AM, Krzysztof Kozlowski wrote:
> On Wed, Aug 20, 2025 at 02:12:55PM -0300, Ariel D'Alessandro wrote:
>> Current, the DT bindings for Mediatek UFOe (Unified Frame Optimization
>> engine) is missing the mediatek,gce-client-reg property. Add it and
>
> Why is it missing? If the binding is complete, it cannot be missing...
Due to the following error:
$ make -j$(nproc) CHECK_DTBS=y mediatek/mt8173-elm.dtb
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC [C] arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
[...]
arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: ufoe@1401a000
(mediatek,mt8173-disp-ufoe): 'mediatek,gce-client-reg' does not match
any of the regexes: '^pinctrl-[0-9]+$'
from schema $id:
http://devicetree.org/schemas/display/mediatek/mediatek,ufoe.yaml#
>
>> update the example as well.
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../bindings/display/mediatek/mediatek,ufoe.yaml | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>> index 61a5e22effbf2..ecb4c0359fec3 100644
>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
>> @@ -64,6 +64,14 @@ properties:
>> - port@0
>> - port@1
>>
>> + mediatek,gce-client-reg:
>> + description: The register of client driver can be configured by gce with
>> + 4 arguments defined in this property, such as phandle of gce, subsys id,
>> + register offset and size. Each GCE subsys id is mapping to a client
>
> Don't explain what DT syntax is. We all know, so that's completely
> redundant description. Explain the purpose. Explain Arguments with sechema - items.
Although I agree with your suggestions, this is exactly how the rest of
the Mediatek DT bindings describe this node. This patch is based on the
other +20 files, which describe the node in the same way.
Regards,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* [RESEND PATCH 4/4] Input: imx6ul_tsc - use BIT, FIELD_{GET,PREP} and GENMASK macros
From: Dario Binacchi @ 2025-09-10 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi, Dmitry Torokhov, Fabio Estevam,
Michael Trimarchi, Pengutronix Kernel Team, Sascha Hauer,
Shawn Guo, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250910135916.3939502-1-dario.binacchi@amarulasolutions.com>
Replace opencoded masking and shifting, with BIT(), GENMASK(),
FIELD_GET() and FIELD_PREP() macros.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
drivers/input/touchscreen/imx6ul_tsc.c | 88 ++++++++++++++------------
1 file changed, 48 insertions(+), 40 deletions(-)
diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
index a6066643bd48..e74999c5e22f 100644
--- a/drivers/input/touchscreen/imx6ul_tsc.c
+++ b/drivers/input/touchscreen/imx6ul_tsc.c
@@ -21,25 +21,23 @@
#include <linux/log2.h>
/* ADC configuration registers field define */
-#define ADC_AIEN (0x1 << 7)
+#define ADC_AIEN BIT(7)
+#define ADC_ADCH_MASK GENMASK(4, 0)
#define ADC_CONV_DISABLE 0x1F
-#define ADC_AVGE (0x1 << 5)
-#define ADC_CAL (0x1 << 7)
-#define ADC_CALF 0x2
-#define ADC_12BIT_MODE (0x2 << 2)
-#define ADC_CONV_MODE_MASK (0x3 << 2)
+#define ADC_AVGE BIT(5)
+#define ADC_CAL BIT(7)
+#define ADC_CALF BIT(1)
+#define ADC_CONV_MODE_MASK GENMASK(3, 2)
+#define ADC_12BIT_MODE 0x2
#define ADC_IPG_CLK 0x00
-#define ADC_INPUT_CLK_MASK 0x3
-#define ADC_CLK_DIV_8 (0x03 << 5)
-#define ADC_CLK_DIV_MASK (0x3 << 5)
-#define ADC_SHORT_SAMPLE_MODE (0x0 << 4)
-#define ADC_SAMPLE_MODE_MASK (0x1 << 4)
-#define ADC_HARDWARE_TRIGGER (0x1 << 13)
-#define ADC_AVGS_SHIFT 14
-#define ADC_AVGS_MASK (0x3 << 14)
+#define ADC_INPUT_CLK_MASK GENMASK(1, 0)
+#define ADC_CLK_DIV_8 0x03
+#define ADC_CLK_DIV_MASK GENMASK(6, 5)
+#define ADC_SAMPLE_MODE BIT(4)
+#define ADC_HARDWARE_TRIGGER BIT(13)
+#define ADC_AVGS_MASK GENMASK(15, 14)
#define SELECT_CHANNEL_4 0x04
#define SELECT_CHANNEL_1 0x01
-#define DISABLE_CONVERSION_INT (0x0 << 7)
/* ADC registers */
#define REG_ADC_HC0 0x00
@@ -66,20 +64,26 @@
#define REG_TSC_DEBUG_MODE 0x70
#define REG_TSC_DEBUG_MODE2 0x80
+/* TSC_MEASURE_VALUE register field define */
+#define X_VALUE_MASK GENMASK(27, 16)
+#define Y_VALUE_MASK GENMASK(11, 0)
+
/* TSC configuration registers field define */
-#define DETECT_4_WIRE_MODE (0x0 << 4)
-#define AUTO_MEASURE 0x1
-#define MEASURE_SIGNAL 0x1
-#define DETECT_SIGNAL (0x1 << 4)
-#define VALID_SIGNAL (0x1 << 8)
-#define MEASURE_INT_EN 0x1
-#define MEASURE_SIG_EN 0x1
-#define VALID_SIG_EN (0x1 << 8)
+#define MEASURE_DELAY_TIME_MASK GENMASK(31, 8)
+#define DETECT_5_WIRE_MODE BIT(4)
+#define AUTO_MEASURE BIT(0)
+#define MEASURE_SIGNAL BIT(0)
+#define DETECT_SIGNAL BIT(4)
+#define VALID_SIGNAL BIT(8)
+#define MEASURE_INT_EN BIT(0)
+#define MEASURE_SIG_EN BIT(0)
+#define VALID_SIG_EN BIT(8)
#define DE_GLITCH_MASK GENMASK(30, 29)
#define DE_GLITCH_DEF 0x02
-#define START_SENSE (0x1 << 12)
-#define TSC_DISABLE (0x1 << 16)
+#define START_SENSE BIT(12)
+#define TSC_DISABLE BIT(16)
#define DETECT_MODE 0x2
+#define STATE_MACHINE_MASK GENMASK(22, 20)
struct imx6ul_tsc {
struct device *dev;
@@ -115,19 +119,20 @@ static int imx6ul_adc_init(struct imx6ul_tsc *tsc)
adc_cfg = readl(tsc->adc_regs + REG_ADC_CFG);
adc_cfg &= ~(ADC_CONV_MODE_MASK | ADC_INPUT_CLK_MASK);
- adc_cfg |= ADC_12BIT_MODE | ADC_IPG_CLK;
- adc_cfg &= ~(ADC_CLK_DIV_MASK | ADC_SAMPLE_MODE_MASK);
- adc_cfg |= ADC_CLK_DIV_8 | ADC_SHORT_SAMPLE_MODE;
+ adc_cfg |= FIELD_PREP(ADC_CONV_MODE_MASK, ADC_12BIT_MODE) |
+ FIELD_PREP(ADC_INPUT_CLK_MASK, ADC_IPG_CLK);
+ adc_cfg &= ~(ADC_CLK_DIV_MASK | ADC_SAMPLE_MODE);
+ adc_cfg |= FIELD_PREP(ADC_CLK_DIV_MASK, ADC_CLK_DIV_8);
if (tsc->average_enable) {
adc_cfg &= ~ADC_AVGS_MASK;
- adc_cfg |= (tsc->average_select) << ADC_AVGS_SHIFT;
+ adc_cfg |= FIELD_PREP(ADC_AVGS_MASK, tsc->average_select);
}
adc_cfg &= ~ADC_HARDWARE_TRIGGER;
writel(adc_cfg, tsc->adc_regs + REG_ADC_CFG);
/* enable calibration interrupt */
adc_hc |= ADC_AIEN;
- adc_hc |= ADC_CONV_DISABLE;
+ adc_hc |= FIELD_PREP(ADC_ADCH_MASK, ADC_CONV_DISABLE);
writel(adc_hc, tsc->adc_regs + REG_ADC_HC0);
/* start ADC calibration */
@@ -167,19 +172,21 @@ static void imx6ul_tsc_channel_config(struct imx6ul_tsc *tsc)
{
u32 adc_hc0, adc_hc1, adc_hc2, adc_hc3, adc_hc4;
- adc_hc0 = DISABLE_CONVERSION_INT;
+ adc_hc0 = FIELD_PREP(ADC_AIEN, 0);
writel(adc_hc0, tsc->adc_regs + REG_ADC_HC0);
- adc_hc1 = DISABLE_CONVERSION_INT | SELECT_CHANNEL_4;
+ adc_hc1 = FIELD_PREP(ADC_AIEN, 0) |
+ FIELD_PREP(ADC_ADCH_MASK, SELECT_CHANNEL_4);
writel(adc_hc1, tsc->adc_regs + REG_ADC_HC1);
- adc_hc2 = DISABLE_CONVERSION_INT;
+ adc_hc2 = FIELD_PREP(ADC_AIEN, 0);
writel(adc_hc2, tsc->adc_regs + REG_ADC_HC2);
- adc_hc3 = DISABLE_CONVERSION_INT | SELECT_CHANNEL_1;
+ adc_hc3 = FIELD_PREP(ADC_AIEN, 0) |
+ FIELD_PREP(ADC_ADCH_MASK, SELECT_CHANNEL_1);
writel(adc_hc3, tsc->adc_regs + REG_ADC_HC3);
- adc_hc4 = DISABLE_CONVERSION_INT;
+ adc_hc4 = FIELD_PREP(ADC_AIEN, 0);
writel(adc_hc4, tsc->adc_regs + REG_ADC_HC4);
}
@@ -194,8 +201,9 @@ static void imx6ul_tsc_set(struct imx6ul_tsc *tsc)
u32 debug_mode2;
u32 start;
- basic_setting |= tsc->measure_delay_time << 8;
- basic_setting |= DETECT_4_WIRE_MODE | AUTO_MEASURE;
+ basic_setting |= FIELD_PREP(MEASURE_DELAY_TIME_MASK,
+ tsc->measure_delay_time);
+ basic_setting |= AUTO_MEASURE;
writel(basic_setting, tsc->tsc_regs + REG_TSC_BASIC_SETTING);
debug_mode2 = FIELD_PREP(DE_GLITCH_MASK, tsc->de_glitch);
@@ -255,7 +263,7 @@ static bool tsc_wait_detect_mode(struct imx6ul_tsc *tsc)
usleep_range(200, 400);
debug_mode2 = readl(tsc->tsc_regs + REG_TSC_DEBUG_MODE2);
- state_machine = (debug_mode2 >> 20) & 0x7;
+ state_machine = FIELD_GET(STATE_MACHINE_MASK, debug_mode2);
} while (state_machine != DETECT_MODE);
usleep_range(200, 400);
@@ -283,8 +291,8 @@ static irqreturn_t tsc_irq_fn(int irq, void *dev_id)
if (status & MEASURE_SIGNAL) {
value = readl(tsc->tsc_regs + REG_TSC_MEASURE_VALUE);
- x = (value >> 16) & 0x0fff;
- y = value & 0x0fff;
+ x = FIELD_GET(X_VALUE_MASK, value);
+ y = FIELD_GET(Y_VALUE_MASK, value);
/*
* In detect mode, we can get the xnur gpio value,
--
2.43.0
^ permalink raw reply related
* [RESEND PATCH 3/4] Input: imx6ul_tsc - set glitch threshold by DTS property
From: Dario Binacchi @ 2025-09-10 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi, Dmitry Torokhov, Fabio Estevam,
Michael Trimarchi, Pengutronix Kernel Team, Sascha Hauer,
Shawn Guo, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250910135916.3939502-1-dario.binacchi@amarulasolutions.com>
Set the glitch threshold previously hardcoded in the driver. The change
is backward compatible.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
drivers/input/touchscreen/imx6ul_tsc.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
index c2c6e50efc54..a6066643bd48 100644
--- a/drivers/input/touchscreen/imx6ul_tsc.c
+++ b/drivers/input/touchscreen/imx6ul_tsc.c
@@ -7,6 +7,7 @@
#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/bitfield.h>
#include <linux/gpio/consumer.h>
#include <linux/input.h>
#include <linux/slab.h>
@@ -74,7 +75,8 @@
#define MEASURE_INT_EN 0x1
#define MEASURE_SIG_EN 0x1
#define VALID_SIG_EN (0x1 << 8)
-#define DE_GLITCH_2 (0x2 << 29)
+#define DE_GLITCH_MASK GENMASK(30, 29)
+#define DE_GLITCH_DEF 0x02
#define START_SENSE (0x1 << 12)
#define TSC_DISABLE (0x1 << 16)
#define DETECT_MODE 0x2
@@ -92,6 +94,7 @@ struct imx6ul_tsc {
u32 pre_charge_time;
bool average_enable;
u32 average_select;
+ u32 de_glitch;
struct completion completion;
};
@@ -188,13 +191,15 @@ static void imx6ul_tsc_channel_config(struct imx6ul_tsc *tsc)
static void imx6ul_tsc_set(struct imx6ul_tsc *tsc)
{
u32 basic_setting = 0;
+ u32 debug_mode2;
u32 start;
basic_setting |= tsc->measure_delay_time << 8;
basic_setting |= DETECT_4_WIRE_MODE | AUTO_MEASURE;
writel(basic_setting, tsc->tsc_regs + REG_TSC_BASIC_SETTING);
- writel(DE_GLITCH_2, tsc->tsc_regs + REG_TSC_DEBUG_MODE2);
+ debug_mode2 = FIELD_PREP(DE_GLITCH_MASK, tsc->de_glitch);
+ writel(debug_mode2, tsc->tsc_regs + REG_TSC_DEBUG_MODE2);
writel(tsc->pre_charge_time, tsc->tsc_regs + REG_TSC_PRE_CHARGE_TIME);
writel(MEASURE_INT_EN, tsc->tsc_regs + REG_TSC_INT_EN);
@@ -501,6 +506,17 @@ static int imx6ul_tsc_probe(struct platform_device *pdev)
return -EINVAL;
}
+ err = of_property_read_u32(np, "fsl,glitch-threshold", &tsc->de_glitch);
+ if (err)
+ tsc->de_glitch = DE_GLITCH_DEF;
+
+ if (tsc->de_glitch > FIELD_MAX(DE_GLITCH_MASK)) {
+ dev_err(&pdev->dev,
+ "fsl,glitch-threshold (%u) must be less or equal to %lu\n",
+ tsc->de_glitch, FIELD_MAX(DE_GLITCH_MASK));
+ return -EINVAL;
+ }
+
err = input_register_device(tsc->input);
if (err) {
dev_err(&pdev->dev,
--
2.43.0
^ permalink raw reply related
* [RESEND PATCH 2/4] dt-bindings: input: touchscreen: fsl,imx6ul-tsc: add fsl,glitch-threshold
From: Dario Binacchi @ 2025-09-10 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi, Conor Dooley, Dmitry Torokhov,
Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250910135916.3939502-1-dario.binacchi@amarulasolutions.com>
Add support for glitch threshold configuration. A detected signal is valid
only if it lasts longer than the set threshold; otherwise, it is regarded
as a glitch.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
.../input/touchscreen/fsl,imx6ul-tsc.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
index 678756ad0f92..2fee2940213f 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
@@ -62,6 +62,23 @@ properties:
description: Number of data samples which are averaged for each read.
enum: [ 1, 4, 8, 16, 32 ]
+ fsl,glitch-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ Indicates the glitch threshold. The threshold is defined by number
+ of clock cycles. A detect signal is only valid if it is exist longer
+ than threshold; otherwise, it is regarded as a glitch.
+ 0: Normal function: 8191 clock cycles
+ Low power mode: 9 clock cycles
+ 1: Normal function: 4095 clock cycles
+ Low power mode: 7 clock cycles
+ 2: Normal function: 2047 clock cycles
+ Low power mode: 5 clock cycles
+ 3: Normal function: 1023 clock cycles
+ Low power mode: 3 clock cycles
+
required:
- compatible
- reg
@@ -94,4 +111,5 @@ examples:
measure-delay-time = <0xfff>;
pre-charge-time = <0xffff>;
touchscreen-average-samples = <32>;
+ fsl,glitch-threshold = <2>;
};
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox