On Thu, Dec 31, 2020 at 11:23:37AM +0800, Xu Yilun wrote:
> On Wed, Dec 30, 2020 at 01:46:44PM +, Mark Brown wrote:
> > > BTW, Could we keep the spi->max_speed_hz if no controller->max_speed_hz?
> > > Always clamp the spi->max_speed_hz to 0 makes no sense.
> > Right, that's the fix.
> Seems
On Wed, Dec 30, 2020 at 01:46:44PM +, Mark Brown wrote:
> On Wed, Dec 30, 2020 at 10:24:20AM +0800, Xu Yilun wrote:
> > On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote:
>
> > > Does this still apply with current code? There have been some fixes in
> > > this area which I think shou
On Wed, Dec 30, 2020 at 10:24:20AM +0800, Xu Yilun wrote:
> On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote:
> > Does this still apply with current code? There have been some fixes in
> > this area which I think should ensure that we don't turn the speed down
> > to 0 if the controller
On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 01:27:42PM +0800, Xu Yilun wrote:
> > The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
> > when the following patch is merged,
> >
> > commit 9326e4f1e5dd ("spi: Limit the spi device max spe
On Tue, Dec 29, 2020 at 01:27:42PM +0800, Xu Yilun wrote:
> The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
> when the following patch is merged,
>
> commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max
> speed")
>
> the xfer->speed_hz may always b
The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
when the following patch is merged,
commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max
speed")
the xfer->speed_hz may always be clamped to 0 if the controller doesn't
provide its max_speed_hz. There
6 matches
Mail list logo
