Re: Coresight causes synchronous external abort on msm8916

From: Stephan Gerhold <stephan@gerhold.net>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	david.brown@linaro.org, agross@kernel.org,
	linux-arm-kernel@lists.infradead.org, mathieu.poirier@linaro.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: Coresight causes synchronous external abort on msm8916
Date: Fri, 21 Jun 2019 18:10:51 +0200	[thread overview]
Message-ID: <20190621161051.GB34922@gerhold.net> (raw)
In-Reply-To: <20190620093530.GE1248@e107155-lin>

On Thu, Jun 20, 2019 at 10:35:30AM +0100, Sudeep Holla wrote:
> On Wed, Jun 19, 2019 at 08:39:04PM +0200, Stephan Gerhold wrote:
> > Hi,
> >
> > On Wed, Jun 19, 2019 at 09:49:03AM +0100, Suzuki K Poulose wrote:
> > > Hi Stephan,
> > >
> > > On 18/06/2019 21:26, Stephan Gerhold wrote:
> > > > Hi,
> > > >
> > > > I'm trying to run mainline Linux on a smartphone with MSM8916 SoC.
> > > > It works surprisingly well, but the coresight devices seem to cause the
> > > > following crash shortly after userspace starts:
> > > >
> > > >      Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP
> > >
> > > ...
> > >
> > >
> > > >
> > > > In this case I'm using a simple device tree similar to apq8016-sbc,
> > > > but it also happens using something as simple as msm8916-mtp.dts
> > > > on this particular device.
> > > >    (Attached: dmesg log with msm8916-mtp.dts and arm64 defconfig)
> > > >
> > > > I can avoid the crash and boot without any further problems by disabling
> > > > every coresight device defined in msm8916.dtsi, e.g.:
> > > >
> > > > 	tpiu@820000 { status = "disabled"; };
> > >
> > > ...
> > >
> > > >
> > > > I don't have any use for coresight at the moment,
> > > > but it seems somewhat odd to put this in the device specific dts.
> > > >
> > > > Any idea what could be causing this crash?
> > >
> > > This is mostly due to the missing power domain support. The CoreSight
> > > components are usually in a debug power domain. So unless that is turned on,
> > > (either by specifying proper power domain ids for power management protocol
> > > supported by the firmware OR via other hacks - e.g, connecting a DS-5 to
> > > keep the debug power domain turned on , this works on Juno -).
> >
> > Interesting, thanks a lot!
> >
> > In this case I'm wondering how it works on the Dragonboard 410c.
> > Does it enable these power domains in the firmware?
> >   (Assuming it boots without this error...)
> >
> > If coresight is not working properly on all/most msm8916 devices,
> > shouldn't coresight be disabled by default in msm8916.dtsi?
> > At least until those power domains can be set up by the kernel.
> >
> 
> Why do you want to disable in DTS if it's issue with some incomplete
> kernel configuration. If power domains are disabled in the kernel, then
> the pm_runtime might ignore and proceed assuming the firmware enables
> all power domains ON on boot.
> 

At the moment, disabling it in DTS is the only way I have found to make
the kernel boot successfully.

I have tried booting with clk_ignore_unused and pd_ignore_unused but it
does not make any difference. If the debug power domain is the problem,
then I suspect it is not turned on by the firmware on this production
device.

Also see my other reply:
https://lore.kernel.org/linux-arm-msm/20190621160631.GA34922@gerhold.net/