Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

From: Mark Brown <broonie@kernel.org>
To: dkota@codeaurora.org
Cc: Doug Anderson <dianders@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	Sagar Dharia <sdharia@codeaurora.org>,
	Karthikeyan Ramasubramanian <kramasub@codeaurora.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"Mahadevan, Girish" <girishm@codeaurora.org>
Subject: Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP
Date: Fri, 10 Aug 2018 17:46:36 +0100	[thread overview]
Message-ID: <20180810164636.GI20971@sirena.org.uk> (raw)
In-Reply-To: <c1bc416ba407b5a3cc098e78a529752e@codeaurora.org>

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Fri, Aug 10, 2018 at 09:59:46PM +0530, dkota@codeaurora.org wrote:

> Now the need is, how to communicate the SPI controller maximum frequency to
> SPI core framework?
> Is it by DTSI entry or hardcoding in the SPI controller driver?

If you've got a limit that exists in the IP the hard code it in the
driver.

> My stand is for providing the DTSI entry.
> Why because, this keeps SPI controller driver generic across the boards and
> portable.
> Also it is not against to Device tree usage because maximum frequency
> is describing the property of the hardware.

If the limit the controller has is not coming from the clock tree then
presumably it's a physical limitation of the silicon and isn't going to
vary per board.  If the limit is coming from the board then it should be
specified per slave since different slaves may have different
requirements on different boards.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]