All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiada Wang <jiada_wang@mentor.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: <broonie@kernel.org>, <linux-spi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <festevam@gmail.com>
Subject: Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode
Date: Thu, 8 Jun 2017 22:09:07 -0700	[thread overview]
Message-ID: <593A2D73.4070800@mentor.com> (raw)
In-Reply-To: <20170602053852.7w4c35tn5daq7omy@pengutronix.de>

On 06/01/2017 10:38 PM, Sascha Hauer wrote:
> On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote:
>> Hi Sascha
>>
>> On 05/29/2017 02:50 AM, Sascha Hauer wrote:
>>> Hi,
>>>
>>> On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_wang@mentor.com wrote:
>>>> From: Jiada Wang<jiada_wang@mentor.com>
>>>>
>>>> previously burst length (BURST_LENGTH) is always set to equal
>>>> to bits_per_word, causes a 10us gap between each word in
>>>> transfer, which significantly affects performance.
>>>>
>>>> This patch uses 32 bits transfer to simulate lower bits transfer,
>>>> and adjusts burst length runtimely to use biggeest burst length
>>>> as possible to reduce the gaps in transfer for PIO mode.
>>>>
>>> First let me say that I'm not really looking forward to have this patch
>>> in the driver. It adds quite some code to already hairy code pathes in
>>> the imx-spi driver and I saw you have the same patch for DMA mode
>>> aswell.
>>>
>>> The driver has different function hooks for the different controllers.
>>> This patch breaks that. In some places it assumes that dynamic burst
>>> is only possible on i.MX51 type controllers and also that in case
>>> dynamic burst is enabled it must be an i.MX51 type controller.
>>>
>>> We should really see how this patch can be better integrated into the
>>> driver, or, how the driver can be changed to better support the dynamic
>>> burst usecase.
>>   Yes, I can understand your concern, as this patch brings in a bunch of
>> change,
>> and changes the behaviour of data transfer.
>> how about introduce a new DTS property like "fsl,spi-dynamic-burst",
>> and only enables dynamic burst when this property is added.
> This will only reduce the testing coverage of the feature, not a good
> option.
As an improvement, I am thinking about the following
1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before
2. remove all change in specific functions hooks, for example 
"mx51_ecspi_config"
3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle 
actual swapped data transfer,
     and burst length adjustment.


What do you think ?
> Sascha
>

WARNING: multiple messages have this Message-ID (diff)
From: Jiada Wang <jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode
Date: Thu, 8 Jun 2017 22:09:07 -0700	[thread overview]
Message-ID: <593A2D73.4070800@mentor.com> (raw)
In-Reply-To: <20170602053852.7w4c35tn5daq7omy-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On 06/01/2017 10:38 PM, Sascha Hauer wrote:
> On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote:
>> Hi Sascha
>>
>> On 05/29/2017 02:50 AM, Sascha Hauer wrote:
>>> Hi,
>>>
>>> On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org wrote:
>>>> From: Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>>
>>>> previously burst length (BURST_LENGTH) is always set to equal
>>>> to bits_per_word, causes a 10us gap between each word in
>>>> transfer, which significantly affects performance.
>>>>
>>>> This patch uses 32 bits transfer to simulate lower bits transfer,
>>>> and adjusts burst length runtimely to use biggeest burst length
>>>> as possible to reduce the gaps in transfer for PIO mode.
>>>>
>>> First let me say that I'm not really looking forward to have this patch
>>> in the driver. It adds quite some code to already hairy code pathes in
>>> the imx-spi driver and I saw you have the same patch for DMA mode
>>> aswell.
>>>
>>> The driver has different function hooks for the different controllers.
>>> This patch breaks that. In some places it assumes that dynamic burst
>>> is only possible on i.MX51 type controllers and also that in case
>>> dynamic burst is enabled it must be an i.MX51 type controller.
>>>
>>> We should really see how this patch can be better integrated into the
>>> driver, or, how the driver can be changed to better support the dynamic
>>> burst usecase.
>>   Yes, I can understand your concern, as this patch brings in a bunch of
>> change,
>> and changes the behaviour of data transfer.
>> how about introduce a new DTS property like "fsl,spi-dynamic-burst",
>> and only enables dynamic burst when this property is added.
> This will only reduce the testing coverage of the feature, not a good
> option.
As an improvement, I am thinking about the following
1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before
2. remove all change in specific functions hooks, for example 
"mx51_ecspi_config"
3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle 
actual swapped data transfer,
     and burst length adjustment.


What do you think ?
> Sascha
>

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-06-09  5:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26  5:02 [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode jiada_wang
2017-05-26  5:02 ` jiada_wang-nmGgyN9QBj3QT0dZR+AlfA
2017-05-29  9:50 ` Sascha Hauer
2017-05-29  9:50   ` Sascha Hauer
2017-06-01 11:58   ` Jiada Wang
2017-06-01 11:58     ` Jiada Wang
2017-06-02  5:38     ` Sascha Hauer
2017-06-02  5:38       ` Sascha Hauer
2017-06-09  5:09       ` Jiada Wang [this message]
2017-06-09  5:09         ` Jiada Wang
2017-06-09  5:46         ` Sascha Hauer
2017-06-09  5:46           ` Sascha Hauer
2017-05-29 11:07 ` Fabio Estevam
2017-05-29 11:07   ` Fabio Estevam
2017-06-01  7:55   ` Jiada Wang

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=593A2D73.4070800@mentor.com \
    --to=jiada_wang@mentor.com \
    --cc=broonie@kernel.org \
    --cc=festevam@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    /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.