| Message ID | 20240320111058.601156-1-marge.yang@tw.synaptics.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [V1] Input: synaptics-rmi4 - Supports to query DPM value. | expand |
Hi Dmitry, Please help to check the comment. Thanks Marge Yang -----Original Message----- From: dmitry.torokhov@gmail.com <dmitry.torokhov@gmail.com> Sent: Thursday, August 1, 2024 2:54 AM To: Kevin Chu <kevin.chu@tw.synaptics.com> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; Marge Yang <Marge.Yang@tw.synaptics.com>; Derek Cheng <derek.cheng@tw.synaptics.com>; David Chiu <David.Chiu@tw.synaptics.com>; Vincent Huang <Vincent.huang@tw.synaptics.com>; Sam Tsai <Sam.Tsai@synaptics.com>; Vincent Tang <Vincent.Tang@synaptics.com> Subject: Re: [PATCH V1] Input: synaptics-rmi4 - Supports to query DPM value. CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Kevin, On Wed, Jul 31, 2024 at 09:17:56AM +0000, Kevin Chu wrote: > Hi Dmitry and the Linux Input/Kernel Team, > > I hope this email finds you well. I'm reaching out regarding our > kernel code that has been awaiting review for over a quarter now. > > Given the extended period without review, it's likely that some gaps > or inconsistencies have developed in our code base. To ensure a > smooth and productive review process, we'd like to address any > potential issues proactively. > > Could you please provide some guidance or hints on areas we should > focus on before submitting for formal review? Your expertise would > be invaluable in helping us prepare effectively. > There was nothing wrong with patch submission. If you see something stuck please do not hesitate poking me. A couple of questions about the patch below though: > Thanks > Kevin > > -----Original Message----- > From: Marge Yang <marge.yang@tw.synaptics.com> > Sent: Wednesday, March 20, 2024 7:11 PM > To: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; > linux-kernel@vger.kernel.org; Marge Yang <Marge.Yang@tw.synaptics.com> > Cc: David Chiu <David.Chiu@tw.synaptics.com>; Derek Cheng > <derek.cheng@tw.synaptics.com>; Sam Tsai <Sam.Tsai@synaptics.com>; > Vincent Huang <Vincent.huang@tw.synaptics.com>; Vincent Huang > <Vincent.huang@tw.synaptics.com> > Subject: [PATCH V1] Input: synaptics-rmi4 - Supports to query DPM value. > > RMI4 F12 will support to query DPM value on Touchpad. > When TP firmware doesn't support to report logical and physical value within the Touchpad's HID report, We can directly query the DPM value through RMI. It seems to me the logic is inverted, if there is resolution register the new code will query it directly, otherwise it will try to get it from the subpacket data. Is it intentional? Or did I parse it incorrectly? [Marge 08/01] Previously, we obtained this information by querying subpacket data. However, when the "Query DPM" feature is present, querying subpacket data may become unreliable, leading to inconsistencies in the pointing speed. This also does not appear to be tied to the HID transport but rather generic RMI4 code. Did I miss the connection? [Marge 08/01] This change applies to generic RMI4 code and is not related to HID transport. > > Signed-off-by: Marge Yang <marge.yang@tw.synaptics.com> > Signed-off-by: Vincent Huang <Vincent.Huang@tw.synaptics.com> > --- > drivers/input/rmi4/rmi_f12.c | 41 > +++++++++++++++++++++++++++++++---------- > 1 file changed, 31 insertions(+), 10 deletions(-) > > diff --git a/drivers/input/rmi4/rmi_f12.c > b/drivers/input/rmi4/rmi_f12.c index 7e97944..6a7a17d 100644 > --- a/drivers/input/rmi4/rmi_f12.c > +++ b/drivers/input/rmi4/rmi_f12.c > @@ -24,6 +24,7 @@ enum rmi_f12_object_type { }; > > #define F12_DATA1_BYTES_PER_OBJ 8 > +#define RMI_QUERY_DPM_IN_PRESENSE_BIT 29 Why "BIT"? Should it be called RMI_F12_RESOLUTION_REG or similar? [Marge 08/01] The "QUERY DPM" feature is the 29th bit in the F12 2D QUERY Presence register. By checking this bit, we can determine whether certain features are supported. I will rename it from "RMI_QUERY_DPM_IN_PRESENCE_BIT" to "RMI_F12_QUERY_RESOLUTION_REG". > > struct f12_data { > struct rmi_2d_sensor sensor; > @@ -73,6 +74,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12) > int pitch_y = 0; > int rx_receivers = 0; > int tx_receivers = 0; > + u16 query_dpm_addr = 0; > + int dpm_resolution = 0; > > item = rmi_get_register_desc_item(&f12->control_reg_desc, 8); > if (!item) { > @@ -122,18 +125,36 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12) > offset += 4; > } > > - if (rmi_register_desc_has_subpacket(item, 3)) { > - rx_receivers = buf[offset]; > - tx_receivers = buf[offset + 1]; > - offset += 2; > - } > + // Only supports to query DPM value on RMI F12. I am unsure what this comment means... We are in F12 code, so what does "only" mean here? [Marge 08/01] The main point is to emphasize the new approach that applies when the "query DPM" feature is present. New comment: Use the Query DPM feature when the "query resolution register" exists. > + item = rmi_get_register_desc_item(&f12->query_reg_desc, RMI_QUERY_DPM_IN_PRESENSE_BIT); > + if (item) { > + offset = rmi_register_desc_calc_reg_offset(&f12->query_reg_desc, > + RMI_QUERY_DPM_IN_PRESENSE_BIT); > + query_dpm_addr = fn->fd.query_base_addr + offset; > + ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf); > + if (ret < 0) { > + dev_err(&fn->dev, "Failed to read DPM value: %d\n", ret); > + return -ENODEV; > + } > + dpm_resolution = buf[0]; > + > + sensor->x_mm = sensor->max_x / dpm_resolution; > + sensor->y_mm = sensor->max_y / dpm_resolution; > + } else { > + if (rmi_register_desc_has_subpacket(item, 3)) { > + rx_receivers = buf[offset]; > + tx_receivers = buf[offset + 1]; > + offset += 2; > + } > > - /* Skip over sensor flags */ > - if (rmi_register_desc_has_subpacket(item, 4)) > - offset += 1; > + /* Skip over sensor flags */ > + if (rmi_register_desc_has_subpacket(item, 4)) > + offset += 1; > + > + sensor->x_mm = (pitch_x * rx_receivers) >> 12; > + sensor->y_mm = (pitch_y * tx_receivers) >> 12; > + } > > - sensor->x_mm = (pitch_x * rx_receivers) >> 12; > - sensor->y_mm = (pitch_y * tx_receivers) >> 12; > > rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: x_mm: %d y_mm: %d\n", __func__, > sensor->x_mm, sensor->y_mm); > -- > 2.7.4 > Thanks. -- Dmitry
Hi Marge, On Thu, Aug 01, 2024 at 09:52:48AM +0000, Marge Yang wrote: > > > > RMI4 F12 will support to query DPM value on Touchpad. > > When TP firmware doesn't support to report logical and physical value within the Touchpad's HID report, We can directly query the DPM value through RMI. > > It seems to me the logic is inverted, if there is resolution register the new code will query it directly, otherwise it will try to get it from the subpacket data. Is it intentional? Or did I parse it incorrectly? > [Marge 08/01] > Previously, we obtained this information by querying subpacket data. However, when the "Query DPM" feature is present, querying subpacket data may become unreliable, leading to inconsistencies in the pointing speed. > > This also does not appear to be tied to the HID transport but rather generic RMI4 code. Did I miss the connection? > [Marge 08/01] > This change applies to generic RMI4 code and is not related to HID transport. OK, so how about this patch description then: "Newer firmware allows to query touchpad resolution information by reading from resolution register. Presence of resolution register is signalled via bit 29 of the "register presence" register. On devices that lack this resolution register we fall back to using pitch and number of receivers data to calculate size of the sensor." > > > > Signed-off-by: Marge Yang <marge.yang@tw.synaptics.com> > > Signed-off-by: Vincent Huang <Vincent.Huang@tw.synaptics.com> > > --- > > drivers/input/rmi4/rmi_f12.c | 41 > > +++++++++++++++++++++++++++++++---------- > > 1 file changed, 31 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/input/rmi4/rmi_f12.c > > b/drivers/input/rmi4/rmi_f12.c index 7e97944..6a7a17d 100644 > > --- a/drivers/input/rmi4/rmi_f12.c > > +++ b/drivers/input/rmi4/rmi_f12.c > > @@ -24,6 +24,7 @@ enum rmi_f12_object_type { }; > > > > #define F12_DATA1_BYTES_PER_OBJ 8 > > +#define RMI_QUERY_DPM_IN_PRESENSE_BIT 29 > > Why "BIT"? Should it be called RMI_F12_RESOLUTION_REG or similar? > [Marge 08/01] > The "QUERY DPM" feature is the 29th bit in the F12 2D QUERY Presence register. > By checking this bit, we can determine whether certain features are supported. > I will rename it from "RMI_QUERY_DPM_IN_PRESENCE_BIT" to "RMI_F12_QUERY_RESOLUTION_REG". OK, I see. I think since you are checking presence of a register either RMI_F12_QUERY_RESOLUTION_REG or simply RMI_F12_QUERY_RESOLUTION is better than "_BIT" variant. > > > > > struct f12_data { > > struct rmi_2d_sensor sensor; > > @@ -73,6 +74,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12) > > int pitch_y = 0; > > int rx_receivers = 0; > > int tx_receivers = 0; > > + u16 query_dpm_addr = 0; > > + int dpm_resolution = 0; > > > > item = rmi_get_register_desc_item(&f12->control_reg_desc, 8); > > if (!item) { > > @@ -122,18 +125,36 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12) > > offset += 4; > > } > > > > - if (rmi_register_desc_has_subpacket(item, 3)) { > > - rx_receivers = buf[offset]; > > - tx_receivers = buf[offset + 1]; > > - offset += 2; > > - } > > + // Only supports to query DPM value on RMI F12. > > I am unsure what this comment means... We are in F12 code, so what does "only" mean here? > [Marge 08/01] > The main point is to emphasize the new approach that applies when the "query DPM" feature is present. > New comment: > Use the Query DPM feature when the "query resolution register" exists. Sounds good to me. Thanks.
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c index 7e97944..6a7a17d 100644 --- a/drivers/input/rmi4/rmi_f12.c +++ b/drivers/input/rmi4/rmi_f12.c @@ -24,6 +24,7 @@ enum rmi_f12_object_type { }; #define F12_DATA1_BYTES_PER_OBJ 8 +#define RMI_QUERY_DPM_IN_PRESENSE_BIT 29 struct f12_data { struct rmi_2d_sensor sensor; @@ -73,6 +74,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12) int pitch_y = 0; int rx_receivers = 0; int tx_receivers = 0; + u16 query_dpm_addr = 0; + int dpm_resolution = 0; item = rmi_get_register_desc_item(&f12->control_reg_desc, 8); if (!item) { @@ -122,18 +125,36 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12) offset += 4; } - if (rmi_register_desc_has_subpacket(item, 3)) { - rx_receivers = buf[offset]; - tx_receivers = buf[offset + 1]; - offset += 2; - } + // Only supports to query DPM value on RMI F12. + item = rmi_get_register_desc_item(&f12->query_reg_desc, RMI_QUERY_DPM_IN_PRESENSE_BIT); + if (item) { + offset = rmi_register_desc_calc_reg_offset(&f12->query_reg_desc, + RMI_QUERY_DPM_IN_PRESENSE_BIT); + query_dpm_addr = fn->fd.query_base_addr + offset; + ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf); + if (ret < 0) { + dev_err(&fn->dev, "Failed to read DPM value: %d\n", ret); + return -ENODEV; + } + dpm_resolution = buf[0]; + + sensor->x_mm = sensor->max_x / dpm_resolution; + sensor->y_mm = sensor->max_y / dpm_resolution; + } else { + if (rmi_register_desc_has_subpacket(item, 3)) { + rx_receivers = buf[offset]; + tx_receivers = buf[offset + 1]; + offset += 2; + } - /* Skip over sensor flags */ - if (rmi_register_desc_has_subpacket(item, 4)) - offset += 1; + /* Skip over sensor flags */ + if (rmi_register_desc_has_subpacket(item, 4)) + offset += 1; + + sensor->x_mm = (pitch_x * rx_receivers) >> 12; + sensor->y_mm = (pitch_y * tx_receivers) >> 12; + } - sensor->x_mm = (pitch_x * rx_receivers) >> 12; - sensor->y_mm = (pitch_y * tx_receivers) >> 12; rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: x_mm: %d y_mm: %d\n", __func__, sensor->x_mm, sensor->y_mm);