Re: [PATCH 0/7] coresight: etm4x: Migrate AMBA devices to platform driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/03/2023 14:17, Rob Herring wrote:
On Thu, Mar 16, 2023 at 10:05 PM Anshuman Khandual
<anshuman.khandual@xxxxxxx> 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.

Yes, it would eventually go away. As for adding the PIDs, the
fundamental issue is, unlike other drivers, except for the "PIDs"
everything else is architected and each CPU has this PID alone
different and we have plenty of CPUs implementaions out there.

But all that said, since we added this as an AMBA driver in the first
place (all for simply getting the apb_clk management), I am happy to
choose the "Add PIDs to stable kernel approach" for this problem.


   - 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.

This was mainly due to (1), given we have a platform driver anyway for
ACPI. As mentioned above, we could leave the DT 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.

This alone wouldn't be sufficient. We need a platform driver anyway to
handle the two different modes in  ACPI for ETMs. But this will be a
an option for the other CoreSight components which are always MMIO.

Thanks
Suzuki



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux