On Tue, 1 Oct 2019 at 12:05, Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote: > > On 2019-10-01 11:01, Jeffrey Hugo wrote: > > On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan > > <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote: > >> > >> > >> Haan then likely it's the firmware issue. > >> We should probably disable coresight in soc dtsi and enable only for > >> MTP. For now you can add a status=disabled for all coresight nodes in > >> msm8998.dtsi and I will send the patch doing the same in a day or > >> two(sorry I am travelling currently). > > > > This sounds sane to me (and is what I did while bisecting the issue). > > When you do create the patch, feel free to add the following tags as > > you see fit. > > > > Reported-by: Jeffrey Hugo <jeffrey.l.hugo@xxxxxxxxx> > > Tested-by: Jeffrey Hugo <jeffrey.l.hugo@xxxxxxxxx> > > Thanks Jeffrey, I will add them. > Hope Mathieu and Suzuki are OK with this. The problem here is that a debug and production device are using the same device tree, i.e msm8998.dtsi. Disabling coresight devices in the DTS file will allow the laptop to boot but completely disabled coresight blocks on the MTP board. Leaving things as is breaks the laptop but allows coresight to be used on the MTP board. One of three things can happen: 1) Nothing gets done and production board can't boot without DTS modifications. 2) Disable tags are added to the DTS file and the debug board can't use coresight without modifications. 2) The handling of the debug power domain is done properly on the MSM8998 rather than relying on the bootloader to enable it. 3) The DTS file is split or reorganised to account for debug/production devices. Which of the above ends up being the final solution is entirely up to David and Andy. Regards, Mathieu > > Thanks, > Sai
