From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Date: Wed, 01 Oct 2014 11:31:49 +0000 Subject: Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code Message-Id: <20141001113149.GS4273@sirena.org.uk> MIME-Version: 1 Content-Type: multipart/mixed; boundary="v6YRErhBvjoBjrPV" List-Id: References: <20140927235601.19023.31593@quantum> <20140929080637.GB12506@ulmo> <20140929092301.GC4388@lukather> <20140929101805.GB26008@ulmo> <20140929114643.GB4081@lukather> <20140929134708.GB30998@ulmo> <20140929155517.GR16977@sirena.org.uk> <20140930050923.GB29874@ulmo> <20140930173928.GH4273@sirena.org.uk> <20141001074139.GB18463@ulmo> In-Reply-To: <20141001074139.GB18463@ulmo> To: linux-arm-kernel@lists.infradead.org --v6YRErhBvjoBjrPV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 01, 2014 at 09:41:40AM +0200, Thierry Reding wrote: > On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote: > > No, you don't. It's only if you start describing the regulators in the > > PMIC in DT that you run into problems. Unconfigured regulators won't be > > touched. > Okay, that's what I meant. It seems rather odd to add a PMIC DT node but > omit the description of the regulators that it exposes. Unless the > regulators are truly unused, as in not connected to any peripherals. Well, if one does decide to add a description of a regulator which is in use but which hasn't yet been hooked up to users for some reason then it needs to be marked as always on. > > > So unless firmware is updated at the same time, regulators will get > > > disabled because they are unused. > > That won't happen unless the regulators are explicitly described, if > > they are described as unused then this will of course happen. > With described as unused you mean they have a node in DT, so constraints > are applied and all that, but no driver actually uses them? Yes. > The fundamental issue is that if we start describing simplefb nodes with > an incomplete set of resources then we're bound to run into problems > where it'll break once these new resources are described in the DTS. If > the simplefb node was described in the DTS then this would be less of a > problem because the resources could be added to the simplefb node at the > same time. I'm not sure I follow this. If we add descriptions of new resources then it shouldn't be hard to also add information about their use (or that their description is incomplete) at the same time. > However given that simplefb is supposed to be generated by firmware this > is no longer possible. It will inevitably break unless you upgrade the > DTB and the firmware at the same time. And it was already decided long > ago that upgrading the firmware should never be a requirement for > keeping things working. > I don't see any way to prevent that other than ignoring the resources in > simplefb completely. One of the approaches that was being talked about was having a placeholder in DT that the firmware fills in rather than having to create the node from whole cloth each time, that makes life a lot easier. --v6YRErhBvjoBjrPV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUK+YkAAoJECTWi3JdVIfQNEUIAICpikul9F6uHd2MwmX/Fnhp AQHk/ztCDF7X9qfE41510+SDQCfUxfLk2s9+JDqTxTB09QaOxZlLc38yXCrl9L48 +BHEMhMwR2GVd0j9y6gVmmsVF8hxh5kPYOgzWRPWYIaXuwnsqVQANGhIrg8dJpAp FWZz7N99IE67iUFUDirI6aZMrhBgBdycnT/zSt3R6bhjiCfuUJaffkpKsLkNwvWv PvQCqb/jAcnfYX8zh/Y9Jsc6NUozebvKCheNWuBH6rgzSw7fdvaB7aTemuRUZIRf iIExEux88Kd3wn2UlwJqp8zeY5cXsL1AlJsJxn/eXSDVhpNHbQiL8o+IPA1eLso= =Bm1X -----END PGP SIGNATURE----- --v6YRErhBvjoBjrPV-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@kernel.org (Mark Brown) Date: Wed, 1 Oct 2014 12:31:49 +0100 Subject: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code In-Reply-To: <20141001074139.GB18463@ulmo> References: <20140927235601.19023.31593@quantum> <20140929080637.GB12506@ulmo> <20140929092301.GC4388@lukather> <20140929101805.GB26008@ulmo> <20140929114643.GB4081@lukather> <20140929134708.GB30998@ulmo> <20140929155517.GR16977@sirena.org.uk> <20140930050923.GB29874@ulmo> <20140930173928.GH4273@sirena.org.uk> <20141001074139.GB18463@ulmo> Message-ID: <20141001113149.GS4273@sirena.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Oct 01, 2014 at 09:41:40AM +0200, Thierry Reding wrote: > On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote: > > No, you don't. It's only if you start describing the regulators in the > > PMIC in DT that you run into problems. Unconfigured regulators won't be > > touched. > Okay, that's what I meant. It seems rather odd to add a PMIC DT node but > omit the description of the regulators that it exposes. Unless the > regulators are truly unused, as in not connected to any peripherals. Well, if one does decide to add a description of a regulator which is in use but which hasn't yet been hooked up to users for some reason then it needs to be marked as always on. > > > So unless firmware is updated at the same time, regulators will get > > > disabled because they are unused. > > That won't happen unless the regulators are explicitly described, if > > they are described as unused then this will of course happen. > With described as unused you mean they have a node in DT, so constraints > are applied and all that, but no driver actually uses them? Yes. > The fundamental issue is that if we start describing simplefb nodes with > an incomplete set of resources then we're bound to run into problems > where it'll break once these new resources are described in the DTS. If > the simplefb node was described in the DTS then this would be less of a > problem because the resources could be added to the simplefb node at the > same time. I'm not sure I follow this. If we add descriptions of new resources then it shouldn't be hard to also add information about their use (or that their description is incomplete) at the same time. > However given that simplefb is supposed to be generated by firmware this > is no longer possible. It will inevitably break unless you upgrade the > DTB and the firmware at the same time. And it was already decided long > ago that upgrading the firmware should never be a requirement for > keeping things working. > I don't see any way to prevent that other than ignoring the resources in > simplefb completely. One of the approaches that was being talked about was having a placeholder in DT that the firmware fills in rather than having to create the node from whole cloth each time, that makes life a lot easier. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: