| Message ID | 20220128025513.97188-1-bjorn.andersson@linaro.org |
|---|---|
| Headers | show |
| Series | soc: qcom: mdt_loader: Support Qualcomm SM8450 | expand |
On Thu 03 Feb 07:11 PST 2022, Dmitry Baryshkov wrote: > On 28/01/2022 05:55, Bjorn Andersson wrote: > > The Qualcomm SM8450 platform comes with both some smaller changes in the > > firmware packaging and a new requirement to hold onto the metadata buffer until > > PAS auth_and_reset has been completed. > > > > Extend the PAS api and rework the mdt_loader to meet these new requirements, > > then wire this up with the PAS remoteproc driver and finally add the SM8450 > > remoteproc instances. > > > > Bjorn Andersson (13): > > firmware: qcom: scm: Introduce pas_metadata context > > soc: qcom: mdt_loader: Split out split-file-loader > > soc: qcom: mdt_loader: Allow hash segment to be split out > > soc: qcom: mdt_loader: Allow hash to reside in any segment > > soc: qcom: mdt_loader: Extend check for split firmware > > soc: qcom: mdt_loader: Reorder parts of __qcom_mdt_load() > > soc: qcom: mdt_loader: Always invoke PAS mem_setup > > soc: qcom: mdt_loader: Extract PAS operations > > remoteproc: qcom: pas: Carry PAS metadata context > > dt-bindings: remoteproc: qcom: pas: Add SM8450 PAS compatibles > > remoteproc: qcom: pas: Add SM8450 remoteproc support > > arm64: dts: qcom: sm8450: Add remoteproc enablers and instances > > arm64: dts: qcom: sm8450-qrd: Enable remoteproc instances > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Thanks. > Minor nitpicks: > - I'd reorder the series by moving patch 1 (pas_metadata) closer to patch > 8&9 (pas metadata usage) For a while the design where such that I would merge the first patch into a immutable branch and then merge the soc/qcom and remoteproc changes separately. But as you can see, in the end the remoteproc patch ended up depending on the mdt_loader changes. I like your suggestion, so I can move the scm change down to keep things together. > - I would have added pas_metadata as an argument to qcom_mdt_load(). > However I see, why you didn't want to add another argument to the list. > I looked at that, but I was already unhappy with the argument explosion in that function prototype. By splitting out the difference between qcom_mdt_load() and qcom_mdt_load_no_init() into a separate function will allow some cleanup and better reuse in the client drivers. As we bring up the various clients on SM8450 we will need to perform the same modifications that was done to the remoteproc driver, by doing it like this we don't need to change the prototype twice. Regards, Bjorn > > > > .../bindings/remoteproc/qcom,adsp.yaml | 16 + > > arch/arm64/boot/dts/qcom/sm8450-qrd.dts | 20 ++ > > arch/arm64/boot/dts/qcom/sm8450.dtsi | 297 ++++++++++++++++++ > > drivers/firmware/qcom_scm.c | 39 ++- > > drivers/remoteproc/qcom_q6v5_mss.c | 7 +- > > drivers/remoteproc/qcom_q6v5_pas.c | 36 ++- > > drivers/soc/qcom/mdt_loader.c | 232 +++++++++----- > > include/linux/qcom_scm.h | 10 +- > > include/linux/soc/qcom/mdt_loader.h | 17 +- > > 9 files changed, 579 insertions(+), 95 deletions(-) > > > > > -- > With best wishes > Dmitry