All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Axel Lin <axel.lin@ingics.com>
Cc: linux-spi@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] spi: sc18is602: Don't be that restrictive with the maximum transfer speed
Date: Sun, 16 Mar 2014 20:53:09 -0700	[thread overview]
Message-ID: <532671A5.5070302@roeck-us.net> (raw)
In-Reply-To: <CAFRkauDEBe+XStLJSiMzvNOxpFZ2iBGD36-Brq9oHN2RRa+rog@mail.gmail.com>

On 03/16/2014 07:07 PM, Axel Lin wrote:
> 2014-03-17 9:47 GMT+08:00 Guenter Roeck <linux@roeck-us.net>:
>> Commit 09e99bca8 (spi: sc18is602: Convert to let spi core validate
>> transfer speed) made the maximum transfer speed much more restrictive
>> than before. The transfer speed used to be adjusted to 1/4 of the chip
>> clock rate if a higher transfer speed was requested. Now such transfers are
>> simply rejected. With default settings, this causes, for example, a transfer
>> request at 2 mbps to be rejected because the maximum speed with the default
>> chip clock is 1.843 mbps.
>>
>> This is unnecessarily restrictive and causes unnecessary failures. Loosen
>> the limit to accept transfers up to 50% of the clock rate and adjust
>> the speed as needed when setting up the actualt transfer.
>
> I suppose this controller can only set to SC18IS602_MODE_CLOCK_DIV_4 for the
> highest transfer speed. If this is the case, master->max_speed_hz should be
> hw->freq / 4.
>

That really depends on one's point of view. The chip does not support a transfer
speed of, say, hw->freq / 5 or hw->freq / 6 either, but adjusts it to the next
available speed. Following your logic, every non-exact speed should be rejected,
which would make it a pain for a user to find a working speed.

> Now I'm thinking if it is ok to use master->max_speed_hz as transfer speed when
> xfer->speed_hz > master->max_speed_hz. And it should be handled in spi core.
> I'm sending a RFC patch now.
>
That is an acceptable alternate solution for me.

Guenter


WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
To: Axel Lin <axel.lin-8E1dMatC8ynQT0dZR+AlfA@public.gmane.org>
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] spi: sc18is602: Don't be that restrictive with the maximum transfer speed
Date: Sun, 16 Mar 2014 20:53:09 -0700	[thread overview]
Message-ID: <532671A5.5070302@roeck-us.net> (raw)
In-Reply-To: <CAFRkauDEBe+XStLJSiMzvNOxpFZ2iBGD36-Brq9oHN2RRa+rog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 03/16/2014 07:07 PM, Axel Lin wrote:
> 2014-03-17 9:47 GMT+08:00 Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>:
>> Commit 09e99bca8 (spi: sc18is602: Convert to let spi core validate
>> transfer speed) made the maximum transfer speed much more restrictive
>> than before. The transfer speed used to be adjusted to 1/4 of the chip
>> clock rate if a higher transfer speed was requested. Now such transfers are
>> simply rejected. With default settings, this causes, for example, a transfer
>> request at 2 mbps to be rejected because the maximum speed with the default
>> chip clock is 1.843 mbps.
>>
>> This is unnecessarily restrictive and causes unnecessary failures. Loosen
>> the limit to accept transfers up to 50% of the clock rate and adjust
>> the speed as needed when setting up the actualt transfer.
>
> I suppose this controller can only set to SC18IS602_MODE_CLOCK_DIV_4 for the
> highest transfer speed. If this is the case, master->max_speed_hz should be
> hw->freq / 4.
>

That really depends on one's point of view. The chip does not support a transfer
speed of, say, hw->freq / 5 or hw->freq / 6 either, but adjusts it to the next
available speed. Following your logic, every non-exact speed should be rejected,
which would make it a pain for a user to find a working speed.

> Now I'm thinking if it is ok to use master->max_speed_hz as transfer speed when
> xfer->speed_hz > master->max_speed_hz. And it should be handled in spi core.
> I'm sending a RFC patch now.
>
That is an acceptable alternate solution for me.

Guenter

--
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:[~2014-03-17  3:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-17  1:47 [PATCH] spi: sc18is602: Don't be that restrictive with the maximum transfer speed Guenter Roeck
2014-03-17  1:47 ` Guenter Roeck
2014-03-17  2:07 ` Axel Lin
2014-03-17  2:07   ` Axel Lin
2014-03-17  3:53   ` Guenter Roeck [this message]
2014-03-17  3:53     ` Guenter Roeck
2014-03-17 11:27     ` Mark Brown
2014-03-17 11:27       ` Mark Brown
2014-03-17 11:52 ` Mark Brown
2014-03-17 11:52   ` Mark Brown
2014-03-17 13:25   ` Guenter Roeck
2014-03-17 13:25     ` Guenter Roeck

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=532671A5.5070302@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=axel.lin@ingics.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.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.