On Fri, Sep 20, 2024 at 07:00:11AM GMT, Chris Lew wrote: > > > On 9/20/2024 2:02 AM, Johan Hovold wrote: > > On Fri, Sep 20, 2024 at 11:49:46AM +0300, Dmitry Baryshkov wrote: > > > On Fri, Sep 20, 2024 at 10:21:03AM GMT, Johan Hovold wrote: > > > > On Wed, Sep 18, 2024 at 04:02:39PM +0300, Dmitry Baryshkov wrote: > > > > > On X1E8 devices root ADSP domain should have tms/pdr_enabled registered. > > > > > Change the PDM domain data that is used for X1E80100 ADSP. > > > > > > > > Please expand the commit message so that it explains why this is > > > > needed and not just describes what the patch does. > > > > > > Unfortunately in this case I have no idea. It marks the domain as > > > restartable (?), this is what json files for CRD and T14s do. Maybe > > > Chris can comment more. > > > > Chris, could you help sort out if and why this change is needed? > > > > https://lore.kernel.org/all/20240918-x1e-fix-pdm-pdr-v1-1-cefc79bb33d1@xxxxxxxxxx/ > > > > I don't think this change would help with the issue reported by Johan. From > a quick glance, I couldn't find where exactly the restartable attribute is > used, but this type of change would only matter when the ChargerPD is > started or restarted. This raises a question: should we care at all about the pdr_enabled? Is it fine to drop it fromm all PD maps? > > The PMIC_GLINK channel probing in rpmsg is dependent on ChargerPD starting, > so we know ChargerPD can start with or without this change. > > I can give this change a try next week to help give a better analysis. > > > > > What is the expected impact of this and is there any chance that this is > > > > related to some of the in-kernel pd-mapper regression I've reported > > > > (e.g. audio not being registered and failing with a PDR error)? > > > > > > > > https://lore.kernel.org/all/ZthVTC8dt1kSdjMb@xxxxxxxxxxxxxxxxxxxx/ > > > > > > Still debugging this, sidetracked by OSS / LPC. > > > > Johan -- With best wishes Dmitry
