Hi David,
On 7/31/20 9:16 AM, Grzegorz Jaszczyk wrote:
On Fri, 31 Jul 2020 at 16:09, David Lechner <david@xxxxxxxxxxxxxx> wrote:
On 7/31/20 6:48 AM, Grzegorz Jaszczyk wrote:
On Wed, 29 Jul 2020 at 19:34, David Lechner <david@xxxxxxxxxxxxxx> wrote:
It is not clear what the meaning of each cell is. Looking at later patches, it
looks like the first cell is the PRU system event number, the second cell is the
channel and the third cell is the host event number.
Ok, how about updating above description like this:
Client users shall use the PRU System event number (the interrupt source
that the client is interested in) [cell 1], PRU channel [cell 2] and PRU
host_intr (target) [cell 3] as the value of the interrupts property in their
node. The system events can be mapped to some output host interrupts through 2
levels of many-to-one mapping i.e. events to channel mapping and channels to
host interrupts so through this property entire mapping is provided.
Cell 3 is host_intr0-7? How would we map to other host events?
Again this is due to misleading TRM nomenclature: host_intr vs host
interrupts (one that we discuss in patch #2). I will use "and PRU host
event (target) [cell 3]...". Sorry for my mistake.
Idea is to do the event mapping for other host interrupts using the
irq_create_fwspec_mapping() function from the PRU remoteproc driver. We
can't use DT to represent them, or atleast can't use "interrupts"
property for them since they are not targeted towards the Linux host
processor.
regards
Suman
