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
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
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
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
5 matches
Mail list logo