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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
