From mboxrd@z Thu Jan 1 00:00:00 1970 From: maxime.ripard@free-electrons.com (Maxime Ripard) Date: Thu, 27 Nov 2014 20:05:09 +0100 Subject: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver In-Reply-To: <5476F8AB.2000601@redhat.com> References: <20141126211318.GN25249@lukather> <5476E3A5.4000708@redhat.com> <5476F8AB.2000601@redhat.com> Message-ID: <20141127190509.GR25249@lukather> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, On Thu, Nov 27, 2014 at 11:10:51AM +0100, Hans de Goede wrote: > Hi, > > On 11/27/2014 10:28 AM, Chen-Yu Tsai wrote: > >Hi, > > > >On Thu, Nov 27, 2014 at 4:41 PM, Hans de Goede wrote: > > > > >>I notice that you've not responded to my proposal to simple make the clock > >>node a child node of the clocks node in the dt, that should work nicely, and > >>avoid the need for any kernel level changes to support it, I'm beginning to > >>think that that is probably the best solution. > > > >Would that not cause an overlap of the io regions, and cause one of them > >to fail? AFAIK the OF subsystem doesn't like overlapping resources. > > No the overlap check is done by the platform dev resource code, and of_clk_declare > does not use that. So the overlap would be there, but not an issue (in theory > I did not test this). An overlap is always an issue. > Thinking more about this, I believe that using the MFD framework for the prcm seems > like a mistake to me. It gains us nothing, since we have no irq to de-multiplex or > some such. We're not using MFD for the CMU, why use it for CMU2 (which the prcm > effectively is) ? Because the PRCM is much more than that. It also handles the power domains for example. And also because the 1 node per clock is no longer the current trend and that Mike discourages to use that model nowadays. > So I think it would be best to remove the prcm node from the dt, and simply put the > different blocks inside it directly under the soc node, this will work fine with > current kernels, since as said we do not use any MFD features, we use it to > create platform devs and assign resources, something which will happen automatically > if we put the nodes directly under the soc node, since then simple-bus will do the > work for us. > > And then in a release or 2 we can remove the mfd prcm driver from the kernel, and we > have the same functionality we have now with less code. > > We could then also chose to move the existing prcm clock nodes to of_clk_declare > (this will work once they are nodes directly under soc with a proper reg property). > and the ir-clk can use allwinner,sun4i-a10-mod0-clk compatible and can live under > either clocks or soc, depending on what we want to do with the other prcm clocks. Have you considered the SMP code in that smooth plan? The one that is in neither a platform driver, nor a clock, nor does it have a compatible of its own, but still needs to access some of the PRCM registers? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver Date: Thu, 27 Nov 2014 20:05:09 +0100 Message-ID: <20141127190509.GR25249@lukather> References: <20141126211318.GN25249@lukather> <5476E3A5.4000708@redhat.com> <5476F8AB.2000601@redhat.com> Reply-To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TDVcAd+kFgbLxwBe" Return-path: Content-Disposition: inline In-Reply-To: <5476F8AB.2000601-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Hans de Goede Cc: Chen-Yu Tsai , Boris Brezillon , Mike Turquette , Emilio Lopez , Linux Media Mailing List , linux-arm-kernel , devicetree , linux-sunxi List-Id: devicetree@vger.kernel.org --TDVcAd+kFgbLxwBe Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Hi, On Thu, Nov 27, 2014 at 11:10:51AM +0100, Hans de Goede wrote: > Hi, > > On 11/27/2014 10:28 AM, Chen-Yu Tsai wrote: > >Hi, > > > >On Thu, Nov 27, 2014 at 4:41 PM, Hans de Goede wrote: > > > > >>I notice that you've not responded to my proposal to simple make the clock > >>node a child node of the clocks node in the dt, that should work nicely, and > >>avoid the need for any kernel level changes to support it, I'm beginning to > >>think that that is probably the best solution. > > > >Would that not cause an overlap of the io regions, and cause one of them > >to fail? AFAIK the OF subsystem doesn't like overlapping resources. > > No the overlap check is done by the platform dev resource code, and of_clk_declare > does not use that. So the overlap would be there, but not an issue (in theory > I did not test this). An overlap is always an issue. > Thinking more about this, I believe that using the MFD framework for the prcm seems > like a mistake to me. It gains us nothing, since we have no irq to de-multiplex or > some such. We're not using MFD for the CMU, why use it for CMU2 (which the prcm > effectively is) ? Because the PRCM is much more than that. It also handles the power domains for example. And also because the 1 node per clock is no longer the current trend and that Mike discourages to use that model nowadays. > So I think it would be best to remove the prcm node from the dt, and simply put the > different blocks inside it directly under the soc node, this will work fine with > current kernels, since as said we do not use any MFD features, we use it to > create platform devs and assign resources, something which will happen automatically > if we put the nodes directly under the soc node, since then simple-bus will do the > work for us. > > And then in a release or 2 we can remove the mfd prcm driver from the kernel, and we > have the same functionality we have now with less code. > > We could then also chose to move the existing prcm clock nodes to of_clk_declare > (this will work once they are nodes directly under soc with a proper reg property). > and the ir-clk can use allwinner,sun4i-a10-mod0-clk compatible and can live under > either clocks or soc, depending on what we want to do with the other prcm clocks. Have you considered the SMP code in that smooth plan? The one that is in neither a platform driver, nor a clock, nor does it have a compatible of its own, but still needs to access some of the PRCM registers? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --TDVcAd+kFgbLxwBe-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from down.free-electrons.com ([37.187.137.238]:34948 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750729AbaK0TKN (ORCPT ); Thu, 27 Nov 2014 14:10:13 -0500 Date: Thu, 27 Nov 2014 20:05:09 +0100 From: Maxime Ripard To: Hans de Goede Cc: Chen-Yu Tsai , Boris Brezillon , Mike Turquette , Emilio Lopez , Linux Media Mailing List , linux-arm-kernel , devicetree , linux-sunxi Subject: Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver Message-ID: <20141127190509.GR25249@lukather> References: <20141126211318.GN25249@lukather> <5476E3A5.4000708@redhat.com> <5476F8AB.2000601@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TDVcAd+kFgbLxwBe" Content-Disposition: inline In-Reply-To: <5476F8AB.2000601@redhat.com> Sender: linux-media-owner@vger.kernel.org List-ID: --TDVcAd+kFgbLxwBe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 27, 2014 at 11:10:51AM +0100, Hans de Goede wrote: > Hi, >=20 > On 11/27/2014 10:28 AM, Chen-Yu Tsai wrote: > >Hi, > > > >On Thu, Nov 27, 2014 at 4:41 PM, Hans de Goede wro= te: >=20 > >=20 > >>I notice that you've not responded to my proposal to simple make the cl= ock > >>node a child node of the clocks node in the dt, that should work nicely= , and > >>avoid the need for any kernel level changes to support it, I'm beginnin= g to > >>think that that is probably the best solution. > > > >Would that not cause an overlap of the io regions, and cause one of them > >to fail? AFAIK the OF subsystem doesn't like overlapping resources. >=20 > No the overlap check is done by the platform dev resource code, and of_cl= k_declare > does not use that. So the overlap would be there, but not an issue (in th= eory > I did not test this). An overlap is always an issue. > Thinking more about this, I believe that using the MFD framework for the = prcm seems > like a mistake to me. It gains us nothing, since we have no irq to de-mul= tiplex or > some such. We're not using MFD for the CMU, why use it for CMU2 (which th= e prcm > effectively is) ? Because the PRCM is much more than that. It also handles the power domains for example. And also because the 1 node per clock is no longer the current trend and that Mike discourages to use that model nowadays. > So I think it would be best to remove the prcm node from the dt, and simp= ly put the > different blocks inside it directly under the soc node, this will work fi= ne with > current kernels, since as said we do not use any MFD features, we use it = to > create platform devs and assign resources, something which will happen au= tomatically > if we put the nodes directly under the soc node, since then simple-bus wi= ll do the > work for us. >=20 > And then in a release or 2 we can remove the mfd prcm driver from the ker= nel, and we > have the same functionality we have now with less code. >=20 > We could then also chose to move the existing prcm clock nodes to of_clk_= declare > (this will work once they are nodes directly under soc with a proper reg = property). > and the ir-clk can use allwinner,sun4i-a10-mod0-clk compatible and can li= ve under > either clocks or soc, depending on what we want to do with the other prcm= clocks. Have you considered the SMP code in that smooth plan? The one that is in neither a platform driver, nor a clock, nor does it have a compatible of its own, but still needs to access some of the PRCM registers? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --TDVcAd+kFgbLxwBe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUd3XlAAoJEBx+YmzsjxAgvNgP/jWzd7vK8Hmu9MssNzLvCwOh B7bPBEBhRzwBAZbXEI2wtyZ7BlBzd0jZ0MnoJsezMq5ZasI/no//E99TY4HysnN6 vIfhJcChVdE4wMjJv5d9z/5GIWrWtz4+DSN9OSvNDUuw7wpI5B6a3Ud5H4oTd+Z5 ytmUCVHaQfoQULBUQR07DvieNkb8MP5TlukRzkro2AdAm71USbQFbqkNtujg/gFn Juxl6aX9sQtWQQnr11RgJjaN5ADtk20A8XNbawCxYPmtAuAfaqOmHUTxVSb7bEhF AyE6+2mg6sltRTPnGNT+dj4Z6CiFuIMgoMVP4V3iz16ujd+g2Tq+UQ1k1WxUG4oQ q3zWzOi9e9ygg7oOR1P4vF+FN0AlBalslg8EtjtxEAW1OS5pyBvAC92BUa0gs0GW IAV5sGIoCINeTlPzOmoRqQpZIzqqegOyB2Gpxc9K4uEbpVSxKbo7xwpVqdgzOBUm wXLCpHYIsASBZySi9Ww2xTz1P28pj4iJpqqdtU7o5UDJYVdpEbui4Tww72qebqAP UCEX9Xx7vzyEOk/ShGm7IFfQQz8vlY3Apj7HQ9Bde3+cLXAP+sxj6YRrZzqNxecK sQ/mUqSHbaNPP6hhltleH5+IzvGYI4WdhulvnUzdLNqfN1fBg+fm0k267ZfSm76D Th6jTRVfaUSWv2kuaZtw =M1sl -----END PGP SIGNATURE----- --TDVcAd+kFgbLxwBe--