Re: [PATCH v2 2/2] irqchip/ti-sci-inta: Add support for unmapped event handling

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

 



On 2020-09-30 11:01, Peter Ujfalusi wrote:
On 30/09/2020 11.33, Marc Zyngier wrote:
On 2020-09-30 08:45, Peter Ujfalusi wrote:
The DMA (BCDMA/PKTDMA and their rings/flows) events are under the INTA's
supervision as unmapped events in AM64.

What does "unmapped event" mean? An event that doesn't require a mapping?
Or an internally generated event? Or a proxy event?


In order to keep the current SW stack working, the INTA driver must
replace
the dev_id with it's own when a request comes for BCDMA or PKTDMA
resources.

This seems to support my second option. Please clarify what you mean
exactly.

In previous devices with NAVSS we had event registers in UDMAP and in rings.
In AM64 with DMSS these event registers have been removed from the DMAs
(rings are part of the DMAs).
The event configuration registers in DMSS are part of the INTA and they
under 'unmapped events'.

Is "unmapped events" an official TI wording, described as such in the TRM?


In essence the difference boils down to the fact that we do not
configure event numbers (to be consumed by INTA) for the events coming
from DMAs, but they already have their specific offsets within INTA's
unmapped region.

OK, so they are not "unmapped". They are just permanently mapped, aren't they?

With this change in hardware we can not use the DMA's ti_sci device
identification number to configure these events to produce interrupts,
they are under INTA.

The only difference in ti_sci API is that for DMA related
interrupts/events we need to use the INTA's ti_sci device identification
number in place of the DMA component's.

I would say that I would describe the unmapped events with your first
option. They kind of not require mapping from the source to INTA. The
source of the event (DMA, ring) is pre-configured to send specific
events to target the unmapped event area at specific offsets.

If they truly don't require a mapping, why is this patch actually mapping
them with the INTA as a source? Your explanation doesn't make much sense
to me.


But in the unmapped event register one can still define either:
- to send a global event (to be used as trigger or for other purposes)
- to generate interrupt (in a similar way as the IMAP registers were
doing in NAVSS).

I'm not sure if this answers your question...

I still believe the term "unmapped event" doesn't describe what we have
here. These events seems, at least from what the patch does, internally
generated by the INTA.

Irrespective of this, my other comments still stand.

        M.
--
Jazz is not dead. It just smells funny...



[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