All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
	suzuki.poulose@arm.com, 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 0/7] coresight: etm4x: Migrate AMBA devices to platform driver
Date: Mon, 20 Mar 2023 09:17:16 -0500	[thread overview]
Message-ID: <CAL_JsqKsnq0d-x3m3xQe8m0pnk_Jeh9J1oFBtPAn3LV8-MFH0w@mail.gmail.com> (raw)
In-Reply-To: <20230317030501.1811905-1-anshuman.khandual@arm.com>

On Thu, Mar 16, 2023 at 10:05 PM Anshuman Khandual
<anshuman.khandual@arm.com> wrote:
>
> CoreSight ETM4x devices could be accessed either via MMIO (handled via
> amba_driver) or CPU system instructions (handled via platform driver). But
> this has the following issues :
>
>   - Each new CPU comes up with its own PID and thus we need to keep on
>     adding the "known" PIDs to get it working with AMBA driver. While
>     the ETM4 architecture (and CoreSight architecture) defines way to
>     identify a device as ETM4. Thus older kernels  won't be able to
>     "discover" a newer CPU, unless we add the PIDs.

But v8.4 discourages MMIO access, so this problem will go away on its
own. Even if not, adding IDs to stable kernels is standard practice
whether it is PCI VID/PID, compatible string or AMBA PID.

>   - With ACPI, the ETM4x devices have the same HID to identify the device
>     irrespective of the mode of access. This creates a problem where two
>     different drivers (both AMBA based driver and platform driver) would
>     hook into the "HID" and could conflict. e.g., if AMBA driver gets
>     hold of a non-MMIO device, the probe fails. If we have single driver
>     hooked into the given "HID", we could handle them seamlessly,
>     irrespective of the mode of access.

Why are we changing DT for ACPI? Just always use the platform driver
for ACPI and leave DT systems alone.

>   - CoreSight is heavily dependent on the runtime power management. With
>     ACPI, amba_driver doesn't get us anywhere with handling the power
>     and thus one need to always turn the power ON to use them. Moving to
>     platform driver gives us the power management for free.

This sounds like an issue for any amba driver. If this is an issue,
solve it for everyone, not just work around it in one driver.

When someone puts another primecell device into an ACPI system, are we
going to go do the same one-off change in that driver too? (We kind of
already did with SBSA UART...)

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
	 suzuki.poulose@arm.com, 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 0/7] coresight: etm4x: Migrate AMBA devices to platform driver
Date: Mon, 20 Mar 2023 09:17:16 -0500	[thread overview]
Message-ID: <CAL_JsqKsnq0d-x3m3xQe8m0pnk_Jeh9J1oFBtPAn3LV8-MFH0w@mail.gmail.com> (raw)
In-Reply-To: <20230317030501.1811905-1-anshuman.khandual@arm.com>

On Thu, Mar 16, 2023 at 10:05 PM Anshuman Khandual
<anshuman.khandual@arm.com> wrote:
>
> CoreSight ETM4x devices could be accessed either via MMIO (handled via
> amba_driver) or CPU system instructions (handled via platform driver). But
> this has the following issues :
>
>   - Each new CPU comes up with its own PID and thus we need to keep on
>     adding the "known" PIDs to get it working with AMBA driver. While
>     the ETM4 architecture (and CoreSight architecture) defines way to
>     identify a device as ETM4. Thus older kernels  won't be able to
>     "discover" a newer CPU, unless we add the PIDs.

But v8.4 discourages MMIO access, so this problem will go away on its
own. Even if not, adding IDs to stable kernels is standard practice
whether it is PCI VID/PID, compatible string or AMBA PID.

>   - With ACPI, the ETM4x devices have the same HID to identify the device
>     irrespective of the mode of access. This creates a problem where two
>     different drivers (both AMBA based driver and platform driver) would
>     hook into the "HID" and could conflict. e.g., if AMBA driver gets
>     hold of a non-MMIO device, the probe fails. If we have single driver
>     hooked into the given "HID", we could handle them seamlessly,
>     irrespective of the mode of access.

Why are we changing DT for ACPI? Just always use the platform driver
for ACPI and leave DT systems alone.

>   - CoreSight is heavily dependent on the runtime power management. With
>     ACPI, amba_driver doesn't get us anywhere with handling the power
>     and thus one need to always turn the power ON to use them. Moving to
>     platform driver gives us the power management for free.

This sounds like an issue for any amba driver. If this is an issue,
solve it for everyone, not just work around it in one driver.

When someone puts another primecell device into an ACPI system, are we
going to go do the same one-off change in that driver too? (We kind of
already did with SBSA UART...)

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-03-20 14:17 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
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 ` Rob Herring [this message]
2023-03-20 14:17   ` [PATCH 0/7] coresight: etm4x: Migrate AMBA devices to platform driver 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_JsqKsnq0d-x3m3xQe8m0pnk_Jeh9J1oFBtPAn3LV8-MFH0w@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: link
Be 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.