On Sun, Jul 06, 2025 at 02:32:26PM +0200, Luca Weiss wrote: > On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote: > > On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote: > > > On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote: > > > > On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote: > > > > > MSM8974 requires the CX power domain, so use the msm8996_adsp_resource > > > > > which has cx under proxy_pd_names and is otherwise equivalent. > > > > > > > > > > Signed-off-by: Luca Weiss <[email protected]> > > > > > --- > > > > > drivers/remoteproc/qcom_q6v5_pas.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > Hmm. You are modifying the ADSP configuration in the driver, but at the > > > > same time you've dropped CX supply from the MSS remoteproc. > > > > > > The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, > > > which > > > are used in case the power domain is not specified. > > > > > > So no driver change is necessary in the mss driver for both old and new > > > devicetrees, but the adsp driver does not have this fallback, so that's > > > why > > > the adsp config is updated. > > > > > > Does that make it clear? > > > > Yes. Would it make sense to implement fallback_proxy_supply for ADSP > > too? > > Definitely would be possible, but I don't see the point in doing the work to > implement this, to then carry around a bunch of legacy compatibility code > that (very likely) won't really be used in practice. > I don't think any platform apart from msm8974 are going to be affected by > this anyways. > > Still same argument from my side, I think breaking compatibility here for > this one driver outweighs the effort/code of implementing compatibility.
Ack. You have my r-b for the series anyways. -- With best wishes Dmitry
