On 03/16/2014 07:07 PM, Axel Lin wrote:
2014-03-17 9:47 GMT+08:00 Guenter Roeck <linux@xxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
