All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrice CHOTARD <patrice.chotard@foss.st.com>
To: <dillon.minfei@gmail.com>, <pierre-yves.mordret@foss.st.com>,
	<alain.volmat@foss.st.com>, <mcoquelin.stm32@gmail.com>,
	<alexandre.torgue@foss.st.com>, <sumit.semwal@linaro.org>,
	<christian.koenig@amd.com>, <mturquette@baylibre.com>
Cc: <sboyd@kernel.org>, <linux-i2c@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-clk@vger.kernel.org>
Subject: Re: [PATCH 2/4] i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
Date: Tue, 1 Jun 2021 13:43:00 +0200	[thread overview]
Message-ID: <f30d5a1d-5acc-e756-5883-6c3d0173d643@foss.st.com> (raw)
In-Reply-To: <1620990152-19255-3-git-send-email-dillon.minfei@gmail.com>

Hi Dillon

On 5/14/21 1:02 PM, dillon.minfei@gmail.com wrote:
> From: Dillon Min <dillon.minfei@gmail.com>
> 
> As stm32f429's internal flash is 2Mbytes and compiled kernel
> image bigger than 2Mbytes, so we have to load kernel image
> to sdram on stm32f429-disco board which has 8Mbytes sdram space.
> 
> based on above context, as you knows kernel running on external
> sdram is more slower than internal flash. besides, we need read 4
> bytes to get touch screen xyz(x, y, pressure) coordinate data in
> stmpe811 interrupt.
> 
> so, in stm32f4_i2c_handle_rx_done, as i2c read slower than running
> in xip mode, have to adjust 'STOP/START bit set position' from last
> two bytes to last one bytes. else, will get i2c timeout in reading
> touch screen coordinate.
> 
> to not bring in side effect, introduce IIC_LAST_BYTE_POS to support xip
> kernel or zImage.
> 
> Fixes: 62817fc8d282 ("i2c: stm32f4: add driver")
> Link: https://lore.kernel.org/lkml/1591709203-12106-5-git-send-email-dillon.minfei@gmail.com/
> Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
> ---
>  drivers/i2c/busses/i2c-stm32f4.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
> index 4933fc8ce3fd..2e41231b9037 100644
> --- a/drivers/i2c/busses/i2c-stm32f4.c
> +++ b/drivers/i2c/busses/i2c-stm32f4.c
> @@ -93,6 +93,12 @@
>  #define STM32F4_I2C_MAX_FREQ		46U
>  #define HZ_TO_MHZ			1000000
>  
> +#if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
> +#define IIC_LAST_BYTE_POS 1
> +#else
> +#define IIC_LAST_BYTE_POS 2
> +#endif
> +
>  /**
>   * struct stm32f4_i2c_msg - client specific data
>   * @addr: 8-bit slave addr, including r/w bit
> @@ -439,7 +445,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  	int i;
>  
>  	switch (msg->count) {
> -	case 2:
> +	case IIC_LAST_BYTE_POS:
>  		/*
>  		 * In order to correctly send the Stop or Repeated Start
>  		 * condition on the I2C bus, the STOP/START bit has to be set
> @@ -454,7 +460,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  		else
>  			stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
>  
> -		for (i = 2; i > 0; i--)
> +		for (i = IIC_LAST_BYTE_POS; i > 0; i--)
>  			stm32f4_i2c_read_msg(i2c_dev);
>  
>  		reg = i2c_dev->base + STM32F4_I2C_CR2;
> @@ -463,7 +469,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  
>  		complete(&i2c_dev->complete);
>  		break;
> -	case 3:
> +	case (IIC_LAST_BYTE_POS+1):
>  		/*
>  		 * In order to correctly generate the NACK pulse after the last
>  		 * received data byte, we have to enable NACK before reading N-2
> 

I tested this patch on STM32F429-Disco, it fixes the issue described by Dillon.
But i think it's not a good idea to make usage of #if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
inside the driver code.

Pierre-Yves, Alain, as i am not I2C expert, can you have a look at this patch and propose another solution 
to fix the original issue described by Dillon ?

Thanks
Patrice

WARNING: multiple messages have this Message-ID (diff)
From: Patrice CHOTARD <patrice.chotard@foss.st.com>
To: <dillon.minfei@gmail.com>, <pierre-yves.mordret@foss.st.com>,
	<alain.volmat@foss.st.com>, <mcoquelin.stm32@gmail.com>,
	<alexandre.torgue@foss.st.com>, <sumit.semwal@linaro.org>,
	<christian.koenig@amd.com>, <mturquette@baylibre.com>
Cc: <sboyd@kernel.org>, <linux-i2c@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-clk@vger.kernel.org>
Subject: Re: [PATCH 2/4] i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
Date: Tue, 1 Jun 2021 13:43:00 +0200	[thread overview]
Message-ID: <f30d5a1d-5acc-e756-5883-6c3d0173d643@foss.st.com> (raw)
In-Reply-To: <1620990152-19255-3-git-send-email-dillon.minfei@gmail.com>

Hi Dillon

On 5/14/21 1:02 PM, dillon.minfei@gmail.com wrote:
> From: Dillon Min <dillon.minfei@gmail.com>
> 
> As stm32f429's internal flash is 2Mbytes and compiled kernel
> image bigger than 2Mbytes, so we have to load kernel image
> to sdram on stm32f429-disco board which has 8Mbytes sdram space.
> 
> based on above context, as you knows kernel running on external
> sdram is more slower than internal flash. besides, we need read 4
> bytes to get touch screen xyz(x, y, pressure) coordinate data in
> stmpe811 interrupt.
> 
> so, in stm32f4_i2c_handle_rx_done, as i2c read slower than running
> in xip mode, have to adjust 'STOP/START bit set position' from last
> two bytes to last one bytes. else, will get i2c timeout in reading
> touch screen coordinate.
> 
> to not bring in side effect, introduce IIC_LAST_BYTE_POS to support xip
> kernel or zImage.
> 
> Fixes: 62817fc8d282 ("i2c: stm32f4: add driver")
> Link: https://lore.kernel.org/lkml/1591709203-12106-5-git-send-email-dillon.minfei@gmail.com/
> Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
> ---
>  drivers/i2c/busses/i2c-stm32f4.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
> index 4933fc8ce3fd..2e41231b9037 100644
> --- a/drivers/i2c/busses/i2c-stm32f4.c
> +++ b/drivers/i2c/busses/i2c-stm32f4.c
> @@ -93,6 +93,12 @@
>  #define STM32F4_I2C_MAX_FREQ		46U
>  #define HZ_TO_MHZ			1000000
>  
> +#if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
> +#define IIC_LAST_BYTE_POS 1
> +#else
> +#define IIC_LAST_BYTE_POS 2
> +#endif
> +
>  /**
>   * struct stm32f4_i2c_msg - client specific data
>   * @addr: 8-bit slave addr, including r/w bit
> @@ -439,7 +445,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  	int i;
>  
>  	switch (msg->count) {
> -	case 2:
> +	case IIC_LAST_BYTE_POS:
>  		/*
>  		 * In order to correctly send the Stop or Repeated Start
>  		 * condition on the I2C bus, the STOP/START bit has to be set
> @@ -454,7 +460,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  		else
>  			stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
>  
> -		for (i = 2; i > 0; i--)
> +		for (i = IIC_LAST_BYTE_POS; i > 0; i--)
>  			stm32f4_i2c_read_msg(i2c_dev);
>  
>  		reg = i2c_dev->base + STM32F4_I2C_CR2;
> @@ -463,7 +469,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  
>  		complete(&i2c_dev->complete);
>  		break;
> -	case 3:
> +	case (IIC_LAST_BYTE_POS+1):
>  		/*
>  		 * In order to correctly generate the NACK pulse after the last
>  		 * received data byte, we have to enable NACK before reading N-2
> 

I tested this patch on STM32F429-Disco, it fixes the issue described by Dillon.
But i think it's not a good idea to make usage of #if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
inside the driver code.

Pierre-Yves, Alain, as i am not I2C expert, can you have a look at this patch and propose another solution 
to fix the original issue described by Dillon ?

Thanks
Patrice

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Patrice CHOTARD <patrice.chotard@foss.st.com>
To: <dillon.minfei@gmail.com>, <pierre-yves.mordret@foss.st.com>,
	<alain.volmat@foss.st.com>, <mcoquelin.stm32@gmail.com>,
	<alexandre.torgue@foss.st.com>, <sumit.semwal@linaro.org>,
	<christian.koenig@amd.com>, <mturquette@baylibre.com>
Cc: sboyd@kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, linux-i2c@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 2/4] i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
Date: Tue, 1 Jun 2021 13:43:00 +0200	[thread overview]
Message-ID: <f30d5a1d-5acc-e756-5883-6c3d0173d643@foss.st.com> (raw)
In-Reply-To: <1620990152-19255-3-git-send-email-dillon.minfei@gmail.com>

Hi Dillon

On 5/14/21 1:02 PM, dillon.minfei@gmail.com wrote:
> From: Dillon Min <dillon.minfei@gmail.com>
> 
> As stm32f429's internal flash is 2Mbytes and compiled kernel
> image bigger than 2Mbytes, so we have to load kernel image
> to sdram on stm32f429-disco board which has 8Mbytes sdram space.
> 
> based on above context, as you knows kernel running on external
> sdram is more slower than internal flash. besides, we need read 4
> bytes to get touch screen xyz(x, y, pressure) coordinate data in
> stmpe811 interrupt.
> 
> so, in stm32f4_i2c_handle_rx_done, as i2c read slower than running
> in xip mode, have to adjust 'STOP/START bit set position' from last
> two bytes to last one bytes. else, will get i2c timeout in reading
> touch screen coordinate.
> 
> to not bring in side effect, introduce IIC_LAST_BYTE_POS to support xip
> kernel or zImage.
> 
> Fixes: 62817fc8d282 ("i2c: stm32f4: add driver")
> Link: https://lore.kernel.org/lkml/1591709203-12106-5-git-send-email-dillon.minfei@gmail.com/
> Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
> ---
>  drivers/i2c/busses/i2c-stm32f4.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
> index 4933fc8ce3fd..2e41231b9037 100644
> --- a/drivers/i2c/busses/i2c-stm32f4.c
> +++ b/drivers/i2c/busses/i2c-stm32f4.c
> @@ -93,6 +93,12 @@
>  #define STM32F4_I2C_MAX_FREQ		46U
>  #define HZ_TO_MHZ			1000000
>  
> +#if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
> +#define IIC_LAST_BYTE_POS 1
> +#else
> +#define IIC_LAST_BYTE_POS 2
> +#endif
> +
>  /**
>   * struct stm32f4_i2c_msg - client specific data
>   * @addr: 8-bit slave addr, including r/w bit
> @@ -439,7 +445,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  	int i;
>  
>  	switch (msg->count) {
> -	case 2:
> +	case IIC_LAST_BYTE_POS:
>  		/*
>  		 * In order to correctly send the Stop or Repeated Start
>  		 * condition on the I2C bus, the STOP/START bit has to be set
> @@ -454,7 +460,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  		else
>  			stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
>  
> -		for (i = 2; i > 0; i--)
> +		for (i = IIC_LAST_BYTE_POS; i > 0; i--)
>  			stm32f4_i2c_read_msg(i2c_dev);
>  
>  		reg = i2c_dev->base + STM32F4_I2C_CR2;
> @@ -463,7 +469,7 @@ static void stm32f4_i2c_handle_rx_done(struct stm32f4_i2c_dev *i2c_dev)
>  
>  		complete(&i2c_dev->complete);
>  		break;
> -	case 3:
> +	case (IIC_LAST_BYTE_POS+1):
>  		/*
>  		 * In order to correctly generate the NACK pulse after the last
>  		 * received data byte, we have to enable NACK before reading N-2
> 

I tested this patch on STM32F429-Disco, it fixes the issue described by Dillon.
But i think it's not a good idea to make usage of #if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
inside the driver code.

Pierre-Yves, Alain, as i am not I2C expert, can you have a look at this patch and propose another solution 
to fix the original issue described by Dillon ?

Thanks
Patrice

  reply	other threads:[~2021-06-01 11:43 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 11:02 [PATCH 0/4] Fix the i2c/clk bug of stm32 mcu platform dillon.minfei
2021-05-14 11:02 ` dillon.minfei
2021-05-14 11:02 ` dillon.minfei
2021-05-14 11:02 ` [PATCH 1/4] drm/panel: Add ilitek ili9341 panel driver dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-05-31 13:15   ` Patrice CHOTARD
2021-05-31 13:15     ` Patrice CHOTARD
2021-05-31 13:15     ` Patrice CHOTARD
2021-05-31 13:39     ` Dillon Min
2021-05-31 13:39       ` Dillon Min
2021-05-31 13:39       ` Dillon Min
2021-06-01  2:31       ` Dillon Min
2021-06-01  2:31         ` Dillon Min
2021-06-01  2:31         ` Dillon Min
2021-05-14 11:02 ` [PATCH 2/4] i2c: stm32f4: Fix stmpe811 get xyz data timeout issue dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-06-01 11:43   ` Patrice CHOTARD [this message]
2021-06-01 11:43     ` Patrice CHOTARD
2021-06-01 11:43     ` Patrice CHOTARD
2021-06-01 11:58     ` Dillon Min
2021-06-01 11:58       ` Dillon Min
2021-06-01 11:58       ` Dillon Min
2021-05-14 11:02 ` [PATCH 3/4] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-06-01 12:48   ` Patrice CHOTARD
2021-06-01 12:48     ` Patrice CHOTARD
2021-06-01 12:48     ` Patrice CHOTARD
2021-05-14 11:02 ` [PATCH 4/4] clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after kernel startup dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-05-14 11:02   ` dillon.minfei
2021-06-01 12:51   ` Patrice CHOTARD
2021-06-01 12:51     ` Patrice CHOTARD
2021-06-01 12:51     ` Patrice CHOTARD
2021-05-28  6:01 ` [PATCH 0/4] Fix the i2c/clk bug of stm32 mcu platform Dillon Min
2021-05-28  6:01   ` Dillon Min
2021-05-28  6:01   ` Dillon Min
2021-05-31 13:20 ` Patrice CHOTARD
2021-05-31 13:20   ` Patrice CHOTARD
2021-05-31 13:20   ` Patrice CHOTARD
2021-05-31 13:38   ` Dillon Min
2021-05-31 13:38     ` Dillon Min
2021-05-31 13:38     ` Dillon Min
2021-05-31 13:50     ` Patrice CHOTARD
2021-05-31 13:50       ` Patrice CHOTARD
2021-05-31 13:50       ` Patrice CHOTARD
2021-05-31 14:29       ` Dillon Min
2021-05-31 14:29         ` Dillon Min
2021-05-31 14:29         ` Dillon Min
2021-05-31 14:58         ` Patrice CHOTARD
2021-05-31 14:58           ` Patrice CHOTARD
2021-05-31 14:58           ` Patrice CHOTARD
2021-06-01  3:28           ` Dillon Min
2021-06-01  3:28             ` Dillon Min
2021-06-01  3:28             ` Dillon Min
2021-06-01  8:00             ` Patrice CHOTARD
2021-06-01  8:00               ` Patrice CHOTARD

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=f30d5a1d-5acc-e756-5883-6c3d0173d643@foss.st.com \
    --to=patrice.chotard@foss.st.com \
    --cc=alain.volmat@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=christian.koenig@amd.com \
    --cc=dillon.minfei@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=pierre-yves.mordret@foss.st.com \
    --cc=sboyd@kernel.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.