From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757116AbcG1Tvf (ORCPT ); Thu, 28 Jul 2016 15:51:35 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:46026 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751368AbcG1Tvd (ORCPT ); Thu, 28 Jul 2016 15:51:33 -0400 Date: Thu, 28 Jul 2016 20:51:25 +0100 From: Mark Brown To: Rich Felker Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, linux-sh@vger.kernel.org, Rob Herring , Mark Rutland Message-ID: <20160728195125.GN11806@sirena.org.uk> References: <2a46090a5a7c177b7eca83f68406650844423e7f.1469686300.git.dalias@libc.org> <20160728191153.GL11806@sirena.org.uk> <20160728194045.GK15995@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KsSkVHHhotaZRe1D" Content-Disposition: inline In-Reply-To: <20160728194045.GK15995@brightrain.aerifal.cx> X-Cookie: Are you still an ALCOHOLIC? User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH v4 2/2] spi: add driver for J-Core SPI controller X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --KsSkVHHhotaZRe1D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 28, 2016 at 03:40:45PM -0400, Rich Felker wrote: > On Thu, Jul 28, 2016 at 08:11:53PM +0100, Mark Brown wrote: > > An architecture or SoC dependency with || COMPILE_TEST would be useful > > for avoiding cluttering Kconfig for other users. Though as this is in a > > FPGA it's perhaps likely people will pick this up for other FPGAs so > > perhaps a comment to that effect if it seems likely. > Unlike some of the other SoC hardware (interrupt controller) that's > more closely tied to the SH cpu trap behavior, the SPI master seems > like something that would be nice and easy to reuse elsewhere. I don't > feel strongly about it either way though; I can add the arch dep if > you want. I guess it depends if anyone is actually doing that or not, if nobody is the dependency would be better. > > Why are you not using the clock API for this? Just require a clock and > > use clk_get_rate() to find out what rate it is. > I thought about that but I'm not familiar with it. I can try to figure > it out quickly and test that approach; don't see any reason it > shouldn't work. Would you insist on having full support for > enabling/disabling the clk when it's in use, or would you be happy > with treating it as a fixed clock that's always-on for now and > possibly extending it with more functionality later if there's ever > hardware where that's relevant/helpful? It's fine to just enable it at startup and leave it on, though the runtime PM ops are trivial and you can set auto_runtime_pm to have the core do the gets and puts. --KsSkVHHhotaZRe1D Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXmmI8AAoJECTWi3JdVIfQcUsH/24azC7orxSkRAiAbOE2fiDY s9reR3nHmds+Lv+jCtXgAf23W3KXVivaBAd8tNz5jXQyMDBeoqA1pgp5iDyL+/7C WICMdYwkuZ3dWzsuPZB85Yu/1SN+pia9NkJDS4+m4ODJA/nmIA0/5G1ZR6dj5Hxr L1uWF2pH2685PskB+AhGAqNn3SIJqeOSjy2O178uMKvY99s2Bp2sVFTUW4fk3K/c T961zPilop0+csiYDyYD9OzGKN9RUlwSb1Me1dIDbJk7Cj49SMR6ZMqcWL8bkHbA 8rzsFQ0sbSc0GALjQKtK0VPHcPHLEgMRwnuUfTAdOjr6//3AlcHZiUeA1nxZkOo= =6WQn -----END PGP SIGNATURE----- --KsSkVHHhotaZRe1D--