Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <06e71bb8-370d-4b66-bedb-3041d6e3b2c6@gmail.com>
Date:   Thu, 28 Sep 2023 23:22:42 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] input: generalize the Imagis touchscreen driver
To:     Karel Balej <karelb@gimli.ms.mff.cuni.cz>,
        Karel Balej <balejk@matfyz.cz>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        linux-input@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        =?UTF-8?Q?Duje_Mihanovi=C4=87?= <duje.mihanovic@skole.hr>,
        ~postmarketos/upstreaming@lists.sr.ht,
        Jeff LaBundy <jeff@labundy.com>, linmengbo0689@protonmail.com
References: <7b9864bf-2aa6-4510-ad98-276fbfaadc30@gmail.com>
 <72e02837-9a82-4007-8ba2-fa05f3c17670@gmail.com>
 <CVUR18U9FUME.XSF1MML0B1QN@gimli.ms.mff.cuni.cz>
Content-Language: en-US
From:   Markuss Broks <markuss.broks@gmail.com>
In-Reply-To: <CVUR18U9FUME.XSF1MML0B1QN@gimli.ms.mff.cuni.cz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Karel,

On 9/28/23 21:07, Karel Balej wrote:
> Hello, Markuss,
>
> thank you for your response and please forgive that my original emails
> didn't reach you - I am trying to see if I can get the SMTP server I use
> for my primary address officially authorized to send emails in its name
> so that Google does not reject them.
Yeah, I have not received your first series, only knew of it when the 
replies came. It's fine though :)
>
>> To be fair, this driver should work with all Imagis3 chips, which could
>> be a better name for it. However, I agree with Jeff here: the driver
>> doesn't necessarily need renaming.
> I will be sure to drop the renaming for v2.
>
>> Additionally, there used to be my series [1] that generalized the
>> driver, but it never got applied. I will re-send it. It introduces
>> `struct imagis_properties`, which contains register addresses for the
>> registers that we use to read the touch input. In your specific case, I
>> believe it should be:
>>
>> static const struct imagis_properties imagis_3032c_data =
>> {
>> 	.interrupt_msg_cmd = IST3038C_REG_INTR_MESSAGE,
>> 	.touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
>> 	.whoami_cmd = IST3038C_REG_CHIPID,
>> 	.whoami_val = IST3032C_WHOAMI, /* change it to your whoami */
>> };
> I have come across your patch series and in fact my original experiments
> were based on it. However I thought it was abandoned and decided not to
> try to make any further generalizations to the driver for now, except
> making it work with IST3032C. Should I then perhaps wait before your
> series gets applied before sending v2 of my changes? Or should I send
> you a patch on top of your series, where I would add the `struct
> imagis_properties` for the IST3032C (which you surely could do yourself,
> but I can at least test it with my device). Please let me know if and
> how we should coordinate.

If you don't mind the extra hassle, I'm all in for my generalization 
thing going together with your series.

Alternatively, I can resend it myself, but I believe it would be better 
if they go in bulk since they need to be applied together.

>
>> As for the voltage set, I believe this does not belong in a kernel
>> driver. You should set it in device-tree with `regulator-max-microvolt`
>> and `regulator-min-microvolt`.
> Please see my response to Jeff regarding this. I will be happy to hear
> your thoughts on what I propose.

Actually, the regulator values belong to the device-tree, because the 
device-tree for the board is what describes the board's regulators, and 
since you know what components are installed on that specific board you 
can know which regulator values are supposed to be set for it. This 
manual voltage setting can cause conflicts with other drivers for 
example. Also some device can use a variable wide voltage range, and 
some only specific narrow one, and e.g. the driver with wide range would 
set it to voltage that isn't suitable for the narrow range device, so 
it's much better to just specify it manually than have it resolved.

The actual min/max values for regulators or its voltage table is 
provided by the regulator driver itself, so there's not much point in 
specifying those again in the device-tree.

>
> Kind regards,
> K. B.
- Markuss