Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-08-29 16:15:02) > > We're currently facing the issue that every new platform requires the > > addition > > of a compatible to the DT binding as well as the driver. > > > > The DT binding patch to allow us to use qcom,scm for all these new platforms > > that doesn't require any clocks and the driver is reworked to make the > > qcom,scm > > still pick up specified clocks in this case but won't require them. > > > > This makes it possible to add new platforms by simply add the new > > compatible to > > the list in the DT binding, but no changes needs to be done in the driver. > > Which is what is done in patch 3. > > > > I still think it may be even simpler to move to the "get all the clks" > API and then stop caring completely. Any reason to not do that? > I love working with drivers that tells me things like "hey you forgot to add the 'core' clock", rather than having to spend hours bisecting which register access it is that's causing that reboot and then try to drill that down to a particular clock. Apart from that, the "get-all-the-clocks" would work fine as well. Does this API exist yet? Regards, Bjorn
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-08-29 16:15:02) > > We're currently facing the issue that every new platform requires the > > addition > > of a compatible to the DT binding as well as the driver. > > > > The DT binding patch to allow us to use qcom,scm for all these new platforms > > that doesn't require any clocks and the driver is reworked to make the > > qcom,scm > > still pick up specified clocks in this case but won't require them. > > > > This makes it possible to add new platforms by simply add the new > > compatible to > > the list in the DT binding, but no changes needs to be done in the driver. > > Which is what is done in patch 3. > > > > I still think it may be even simpler to move to the "get all the clks" > API and then stop caring completely. Any reason to not do that? > I love working with drivers that tells me things like "hey you forgot to add the 'core' clock", rather than having to spend hours bisecting which register access it is that's causing that reboot and then try to drill that down to a particular clock. Apart from that, the "get-all-the-clocks" would work fine as well. Does this API exist yet? Regards, Bjorn
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
Quoting Bjorn Andersson (2018-08-29 16:15:02) > We're currently facing the issue that every new platform requires the addition > of a compatible to the DT binding as well as the driver. > > The DT binding patch to allow us to use qcom,scm for all these new platforms > that doesn't require any clocks and the driver is reworked to make the > qcom,scm > still pick up specified clocks in this case but won't require them. > > This makes it possible to add new platforms by simply add the new compatible > to > the list in the DT binding, but no changes needs to be done in the driver. > Which is what is done in patch 3. > I still think it may be even simpler to move to the "get all the clks" API and then stop caring completely. Any reason to not do that?
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
Quoting Bjorn Andersson (2018-08-29 16:15:02) > We're currently facing the issue that every new platform requires the addition > of a compatible to the DT binding as well as the driver. > > The DT binding patch to allow us to use qcom,scm for all these new platforms > that doesn't require any clocks and the driver is reworked to make the > qcom,scm > still pick up specified clocks in this case but won't require them. > > This makes it possible to add new platforms by simply add the new compatible > to > the list in the DT binding, but no changes needs to be done in the driver. > Which is what is done in patch 3. > I still think it may be even simpler to move to the "get all the clks" API and then stop caring completely. Any reason to not do that?
[PATCH 0/3] firmware: qcom: scm: Improve clock handling
We're currently facing the issue that every new platform requires the addition of a compatible to the DT binding as well as the driver. The DT binding patch to allow us to use qcom,scm for all these new platforms that doesn't require any clocks and the driver is reworked to make the qcom,scm still pick up specified clocks in this case but won't require them. This makes it possible to add new platforms by simply add the new compatible to the list in the DT binding, but no changes needs to be done in the driver. Which is what is done in patch 3. Bjorn Andersson (3): dt-bindings: firmware: scm: Refactor compatibles and clocks firmware: qcom: scm: Refactor clock handling dt-bindings: firmware: scm: Add MSM8998 and SDM845 .../devicetree/bindings/firmware/qcom,scm.txt | 33 ++--- drivers/firmware/qcom_scm.c | 74 +++ 2 files changed, 63 insertions(+), 44 deletions(-) -- 2.18.0
[PATCH 0/3] firmware: qcom: scm: Improve clock handling
We're currently facing the issue that every new platform requires the addition of a compatible to the DT binding as well as the driver. The DT binding patch to allow us to use qcom,scm for all these new platforms that doesn't require any clocks and the driver is reworked to make the qcom,scm still pick up specified clocks in this case but won't require them. This makes it possible to add new platforms by simply add the new compatible to the list in the DT binding, but no changes needs to be done in the driver. Which is what is done in patch 3. Bjorn Andersson (3): dt-bindings: firmware: scm: Refactor compatibles and clocks firmware: qcom: scm: Refactor clock handling dt-bindings: firmware: scm: Add MSM8998 and SDM845 .../devicetree/bindings/firmware/qcom,scm.txt | 33 ++--- drivers/firmware/qcom_scm.c | 74 +++ 2 files changed, 63 insertions(+), 44 deletions(-) -- 2.18.0
