From: Rob Herring <robh+dt@kernel.org> To: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com>, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, scclevenger@os.amperecomputing.com, Frank Rowand <frowand.list@gmail.com>, Russell King <linux@armlinux.org.uk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus Date: Mon, 20 Mar 2023 09:05:42 -0500 [thread overview] Message-ID: <CAL_Jsq+bJJBi++tpqPMoNTVUswvwFJq=kQj5zHuf-rDphbDwkQ@mail.gmail.com> (raw) In-Reply-To: <aa4090eb-4d9a-3c3b-afab-94d7132af0c7@arm.com> On Mon, Mar 20, 2023 at 5:37 AM Suzuki K Poulose <suzuki.poulose@arm.com> wrote: > > > On 17/03/2023 20:06, Rob Herring wrote: > > On Fri, Mar 17, 2023 at 11:03 AM Suzuki K Poulose > > <suzuki.poulose@arm.com> wrote: > >> > >> Hi Rob > >> > >> Thanks for your response. > >> > >> On 17/03/2023 14:52, Rob Herring wrote: > >>> On Thu, Mar 16, 2023 at 10:06 PM Anshuman Khandual > >>> <anshuman.khandual@arm.com> wrote: > >>>> > >>>> Allow other drivers to claim a device, disregarding the "priority" of > >>>> "arm,primecell". e.g., CoreSight ETM4x devices could be accessed via MMIO > >>>> (AMBA Bus) or via CPU system instructions. > >>> > >>> The OS can pick which one, use both, or this is a system integration > >>> time decision? > >> > >> Not an OS choice. Historically, this has always been MMIO accessed but > >> with v8.4 TraceFiltering support, CPUs are encouraged to use system > >> instructions and obsolete MMIO. So, yes, MMIO is still possible but > >> something that is discouraged and have to be decided at system > >> integration time. > >> > >>> > >>>> The CoreSight ETM4x platform > >>>> driver can now handle both types of devices. In order to make sure the > >>>> driver gets to handle the "MMIO based" devices, which always had the > >>>> "arm,primecell" compatible, we have two options : > >>>> > >>>> 1) Remove the "arm,primecell" from the DTS. But this may be problematic > >>>> for an older kernel without the support. > >>>> > >>>> 2) The other option is to allow OF code to "ignore" the arm,primecell > >>>> priority for a selected list of compatibles. This would make sure that > >>>> both older kernels and the new kernels work fine without breaking > >>>> the functionality. The new DTS could always have the "arm,primecell" > >>>> removed. > >>> > >>> 3) Drop patches 6 and 7 and just register as both AMBA and platform > >>> drivers. It's just some extra boilerplate. I would also do different > >>> compatible strings for CPU system instruction version (assuming this > >>> is an integration time decision). > >> > >> The system instruction (and the reigster layouts) are all part of the > >> ETMv4/ETE architecture and specific capabilities/features are > >> discoverable, just like the Arm CPUs. Thus we don't need special > >> versions within the ETMv4x or ETE minor versions. As of now, we have > >> one for etm4x and another for ete. > > > > I just meant 2 new compatible strings. One each for ETMv4x and ETE, > > but different from the 2 existing ones. It is different h/w presented > > to the OS, so different compatible. > > > > Sorry, was not very clear here. > > Right now, we have : > > 1) arm,coresight-etm4x && arm,primecell - For AMBA based devices > 2) arm,coresight-etm4x-sysreg - For system instruction based > 3) arm,embedded-trace-extension - For ETE Ah, so we already have that... > > > >> One problem with the AMBA driver in place is having to keep on adding > >> new PIDs for the CPUs. The other option is to have a blanket mask > >> for matching the PIDs with AMBA_UCI_ID checks. > > > > But if MMIO access is discouraged, then new h/w would use the platform > > driver(s), not the amba driver, and you won't have to add PIDs. > > Yes for v8.4 onwards. Alternatively, the newer DTS could skip > arm,primecell in the entry and that would kick the platform driver > in. So, that should be fine I guess. Except that the new dts would not work with older kernels. I'm now lost as to what problem this series is trying to solve. Will reply further on cover letter... Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org> To: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com>, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, scclevenger@os.amperecomputing.com, Frank Rowand <frowand.list@gmail.com>, Russell King <linux@armlinux.org.uk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus Date: Mon, 20 Mar 2023 09:05:42 -0500 [thread overview] Message-ID: <CAL_Jsq+bJJBi++tpqPMoNTVUswvwFJq=kQj5zHuf-rDphbDwkQ@mail.gmail.com> (raw) In-Reply-To: <aa4090eb-4d9a-3c3b-afab-94d7132af0c7@arm.com> On Mon, Mar 20, 2023 at 5:37 AM Suzuki K Poulose <suzuki.poulose@arm.com> wrote: > > > On 17/03/2023 20:06, Rob Herring wrote: > > On Fri, Mar 17, 2023 at 11:03 AM Suzuki K Poulose > > <suzuki.poulose@arm.com> wrote: > >> > >> Hi Rob > >> > >> Thanks for your response. > >> > >> On 17/03/2023 14:52, Rob Herring wrote: > >>> On Thu, Mar 16, 2023 at 10:06 PM Anshuman Khandual > >>> <anshuman.khandual@arm.com> wrote: > >>>> > >>>> Allow other drivers to claim a device, disregarding the "priority" of > >>>> "arm,primecell". e.g., CoreSight ETM4x devices could be accessed via MMIO > >>>> (AMBA Bus) or via CPU system instructions. > >>> > >>> The OS can pick which one, use both, or this is a system integration > >>> time decision? > >> > >> Not an OS choice. Historically, this has always been MMIO accessed but > >> with v8.4 TraceFiltering support, CPUs are encouraged to use system > >> instructions and obsolete MMIO. So, yes, MMIO is still possible but > >> something that is discouraged and have to be decided at system > >> integration time. > >> > >>> > >>>> The CoreSight ETM4x platform > >>>> driver can now handle both types of devices. In order to make sure the > >>>> driver gets to handle the "MMIO based" devices, which always had the > >>>> "arm,primecell" compatible, we have two options : > >>>> > >>>> 1) Remove the "arm,primecell" from the DTS. But this may be problematic > >>>> for an older kernel without the support. > >>>> > >>>> 2) The other option is to allow OF code to "ignore" the arm,primecell > >>>> priority for a selected list of compatibles. This would make sure that > >>>> both older kernels and the new kernels work fine without breaking > >>>> the functionality. The new DTS could always have the "arm,primecell" > >>>> removed. > >>> > >>> 3) Drop patches 6 and 7 and just register as both AMBA and platform > >>> drivers. It's just some extra boilerplate. I would also do different > >>> compatible strings for CPU system instruction version (assuming this > >>> is an integration time decision). > >> > >> The system instruction (and the reigster layouts) are all part of the > >> ETMv4/ETE architecture and specific capabilities/features are > >> discoverable, just like the Arm CPUs. Thus we don't need special > >> versions within the ETMv4x or ETE minor versions. As of now, we have > >> one for etm4x and another for ete. > > > > I just meant 2 new compatible strings. One each for ETMv4x and ETE, > > but different from the 2 existing ones. It is different h/w presented > > to the OS, so different compatible. > > > > Sorry, was not very clear here. > > Right now, we have : > > 1) arm,coresight-etm4x && arm,primecell - For AMBA based devices > 2) arm,coresight-etm4x-sysreg - For system instruction based > 3) arm,embedded-trace-extension - For ETE Ah, so we already have that... > > > >> One problem with the AMBA driver in place is having to keep on adding > >> new PIDs for the CPUs. The other option is to have a blanket mask > >> for matching the PIDs with AMBA_UCI_ID checks. > > > > But if MMIO access is discouraged, then new h/w would use the platform > > driver(s), not the amba driver, and you won't have to add PIDs. > > Yes for v8.4 onwards. Alternatively, the newer DTS could skip > arm,primecell in the entry and that would kick the platform driver > in. So, that should be fine I guess. Except that the new dts would not work with older kernels. I'm now lost as to what problem this series is trying to solve. Will reply further on cover letter... Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-20 14:06 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-17 3:04 [PATCH 0/7] coresight: etm4x: Migrate AMBA devices to platform driver Anshuman Khandual 2023-03-17 3:04 ` Anshuman Khandual 2023-03-17 3:04 ` [PATCH 1/7] coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier Anshuman Khandual 2023-03-17 3:04 ` Anshuman Khandual 2023-03-17 3:04 ` [PATCH 2/7] coresight: etm4x: Drop iomem 'base' argument from etm4_probe() Anshuman Khandual 2023-03-17 3:04 ` Anshuman Khandual 2023-03-17 3:04 ` [PATCH 3/7] coresight: etm4x: Drop pid " Anshuman Khandual 2023-03-17 3:04 ` Anshuman Khandual 2023-03-18 8:21 ` kernel test robot 2023-03-18 8:21 ` kernel test robot 2023-03-20 2:54 ` Anshuman Khandual 2023-03-20 2:54 ` Anshuman Khandual 2023-03-17 3:04 ` [PATCH 4/7] coresight: etm4x: Change etm4_platform_driver driver for MMIO devices Anshuman Khandual 2023-03-17 3:04 ` Anshuman Khandual 2023-03-17 9:32 ` Suzuki K Poulose 2023-03-17 9:32 ` Suzuki K Poulose 2023-03-20 4:28 ` Anshuman Khandual 2023-03-20 4:28 ` Anshuman Khandual 2023-03-18 10:24 ` kernel test robot 2023-03-18 10:24 ` kernel test robot 2023-03-20 3:05 ` Anshuman Khandual 2023-03-20 3:05 ` Anshuman Khandual 2023-03-17 3:04 ` [PATCH 5/7] coresight: etm4x: Add ACPI support in platform driver Anshuman Khandual 2023-03-17 3:04 ` Anshuman Khandual 2023-03-17 9:36 ` Suzuki K Poulose 2023-03-17 9:36 ` Suzuki K Poulose 2023-03-17 3:05 ` [PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus Anshuman Khandual 2023-03-17 3:05 ` Anshuman Khandual 2023-03-17 14:52 ` Rob Herring 2023-03-17 14:52 ` Rob Herring 2023-03-17 16:03 ` Suzuki K Poulose 2023-03-17 16:03 ` Suzuki K Poulose 2023-03-17 20:06 ` Rob Herring 2023-03-17 20:06 ` Rob Herring 2023-03-20 10:37 ` Suzuki K Poulose 2023-03-20 10:37 ` Suzuki K Poulose 2023-03-20 14:05 ` Rob Herring [this message] 2023-03-20 14:05 ` Rob Herring 2023-03-20 5:37 ` Anshuman Khandual 2023-03-20 5:37 ` Anshuman Khandual 2023-03-17 3:05 ` [PATCH 7/7] coresight: etm4x: Drop the AMBA driver Anshuman Khandual 2023-03-17 3:05 ` Anshuman Khandual 2023-03-20 14:17 ` [PATCH 0/7] coresight: etm4x: Migrate AMBA devices to platform driver Rob Herring 2023-03-20 14:17 ` Rob Herring 2023-03-21 12:01 ` Suzuki K Poulose 2023-03-21 12:01 ` Suzuki K Poulose 2023-03-21 14:33 ` Sudeep Holla 2023-03-21 14:33 ` Sudeep Holla 2023-03-21 16:02 ` Rob Herring 2023-03-21 16:02 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAL_Jsq+bJJBi++tpqPMoNTVUswvwFJq=kQj5zHuf-rDphbDwkQ@mail.gmail.com' \ --to=robh+dt@kernel.org \ --cc=anshuman.khandual@arm.com \ --cc=coresight@lists.linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=lenb@kernel.org \ --cc=leo.yan@linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=lpieralisi@kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=mike.leach@linaro.org \ --cc=rafael@kernel.org \ --cc=scclevenger@os.amperecomputing.com \ --cc=sudeep.holla@arm.com \ --cc=suzuki.poulose@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.