[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZTvhnGCLKVNUpqLT@finisterre.sirena.org.uk>
Date: Fri, 27 Oct 2023 17:13:16 +0100
From: Mark Brown <broonie@...nel.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: "Stoll, Eberhard" <eberhard.stoll@...tron.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Eberhard Stoll <estl@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"Schrempf, Frieder" <frieder.schrempf@...tron.de>,
Amit Kumar Mahapatra <amit.kumar-mahapatra@....com>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Krishna Yarlagadda <kyarlagadda@...dia.com>,
Leonard Göhrs <l.goehrs@...gutronix.de>,
Yang Yingliang <yangyingliang@...wei.com>
Subject: Re: [PATCH 1/4] spi: Add parameter for clock to rx delay
On Fri, Oct 27, 2023 at 02:46:46PM +0200, Miquel Raynal wrote:
> Yes, if the information is discoverable, we should propagate it to the
> spi layer so that the relevant action is taken, from the most desirable
> to the less desirable:
> - adapting the sampling point
> - lowering the bus frequency
> - refusing the probe if none of these solutions are possible
> Can you update your patchset with this in mind?
Yes, this sounds exactly like what I'd expect the SPI core to be doing.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists