On Wed, Oct 2, 2019 at 9:34 AM Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> wrote: > > On Wed, Oct 02, 2019 at 05:21:23PM +0200, Marc Gonzalez wrote: > > On 02/10/2019 17:03, Mathieu Poirier wrote: > > > > > 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. > > > > I believe 3) is already the de facto situation. > > > > arch/arm64/boot/dts/qcom/msm8998.dtsi is the "base" config. > > arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi for the MTP board. > > arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi for the laptops. > > "DTS file", i.e msm8998.dtsi Bjorn (the primary maintainer whom will likely be taking any DT patches) and I had a chat. We concluded on disabling the coresight components (by default) in the msm8998.dtsi, and then enabling them in the msm8998-mtp.dtsi. I think Bjorn would like to see some patches, which it sounds like Sai will post in a few days. This is probably how things should be moving forward for all qcom SoCs since its standard practice to disable the coresight components via efuse or other hardware mechanism for production products. > > > > > > Which of the above ends up being the final solution is entirely up to > > > David and Andy. > > > > 2498f8c1c668 ;-) > > Then it is even easier to make a decision. > > > > > Regards.
