| Message ID | 1395020870-18107-1-git-send-email-linux@roeck-us.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. 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. Regards, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Mar 16, 2014 at 08:53:09PM -0700, Guenter Roeck wrote: > On 03/16/2014 07:07 PM, Axel Lin wrote: > >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. That's what I'd expect, take the maximum possible given the available constraints.
On Sun, Mar 16, 2014 at 06:47:50PM -0700, Guenter Roeck wrote: > 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. Given this description I'd expect to see a change in the core not a driver - like the other fork of the thread said I'd expect to deal with the issue by improving the constraint handling code. > master->transfer_one_message = sc18is602_transfer_one; > master->dev.of_node = np; > master->min_speed_hz = hw->freq / 128; > - master->max_speed_hz = hw->freq / 4; > + master->max_speed_hz = hw->freq / 2; That said, if this is something that the hardware can support it makes sense to do it anyway - is there an actual spec constraint available?
On 03/17/2014 04:52 AM, Mark Brown wrote: > On Sun, Mar 16, 2014 at 06:47:50PM -0700, Guenter Roeck wrote: >> 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. > > Given this description I'd expect to see a change in the core not a > driver - like the other fork of the thread said I'd expect to deal with > the issue by improving the constraint handling code. > Agreed. >> master->transfer_one_message = sc18is602_transfer_one; >> master->dev.of_node = np; >> master->min_speed_hz = hw->freq / 128; >> - master->max_speed_hz = hw->freq / 4; >> + master->max_speed_hz = hw->freq / 2; > > That said, if this is something that the hardware can support it makes > sense to do it anyway - is there an actual spec constraint available? > No, the technical fastest transfer speed is hz / 4, so this would be just an arbitrary limit to be less restrictive. Axel's patch for the spi core works perfectly, so I would suggest to go with it if that is acceptable for you. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/spi/spi-sc18is602.c b/drivers/spi/spi-sc18is602.c index 237f2e7..f0e55aa 100644 --- a/drivers/spi/spi-sc18is602.c +++ b/drivers/spi/spi-sc18is602.c @@ -297,7 +297,7 @@ static int sc18is602_probe(struct i2c_client *client, master->transfer_one_message = sc18is602_transfer_one; master->dev.of_node = np; master->min_speed_hz = hw->freq / 128; - master->max_speed_hz = hw->freq / 4; + master->max_speed_hz = hw->freq / 2; error = devm_spi_register_master(dev, master); if (error)
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. Cc: Axel Lin <axel.lin@ingics.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> --- This patch applies to the tip of linux-next. drivers/spi/spi-sc18is602.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)