lkml.org 
[lkml]   [2020]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 2/5] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts
[ Dropping afd@ti.com from the Cc list, as this address bounces]

On 2020-09-15 12:00, Grzegorz Jaszczyk wrote:
> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
> interrupt controller (INTC) that can handle various system input events
> and post interrupts back to the device-level initiators. The INTC can
> support upto 64 input events with individual control configuration and
> hardware prioritization. These events are mapped onto 10 output
> interrupt
> lines through two levels of many-to-one mapping support. Different
> interrupt lines are routed to the individual PRU cores or to the host
> CPU, or to other devices on the SoC. Some of these events are sourced
> from peripherals or other sub-modules within that PRUSS, while a few
> others are sourced from SoC-level peripherals/devices.
>
> The PRUSS INTC platform driver manages this PRUSS interrupt controller
> and implements an irqchip driver to provide a Linux standard way for
> the PRU client users to enable/disable/ack/re-trigger a PRUSS system
> event. The system events to interrupt channels and output interrupts
> relies on the mapping configuration provided either through the PRU
> firmware blob (for interrupts routed to PRU cores) or via the PRU
> application's device tree node (for interrupt routed to the main CPU).
> In the first case the mappings will be programmed on PRU remoteproc
> driver demand (via irq_create_fwspec_mapping) during the boot of a PRU
> core and cleaned up after the PRU core is stopped.
>
> Reference counting is used to allow multiple system events to share a
> single channel and to allow multiple channels to share a single host
> event.
>
> The PRUSS INTC module is reference counted during the interrupt
> setup phase through the irqchip's irq_request_resources() and
> irq_release_resources() ops. This restricts the module from being
> removed as long as there are active interrupt users.
>
> The driver currently supports and can be built for OMAP architecture
> based AM335x, AM437x and AM57xx SoCs; Keystone2 architecture based
> 66AK2G SoCs and Davinci architecture based OMAP-L13x/AM18x/DA850 SoCs.
> All of these SoCs support 64 system events, 10 interrupt channels and
> 10 output interrupt lines per PRUSS INTC with a few SoC integration
> differences.
>
> NOTE:
> Each PRU-ICSS's INTC on AM57xx SoCs is preceded by a Crossbar that
> enables multiple external events to be routed to a specific number
> of input interrupt events. Any non-default external interrupt event
> directed towards PRUSS needs this crossbar to be setup properly.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Signed-off-by: David Lechner <david@lechnology.com>
> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>

Please see the use of the Co-developed-by: tag.

> ---
> v5->v6:
> 1) Address Marc Zyngier comments:
> - Use unsigned types for variables used to compute masks/shifts (ch,
> evt, host).
> - Move part responsible for enabling global interrupt from
> pruss_intc_map to pruss_intc_init.
> - Improve coding style in pruss_intc_init with regards to variable
> assignments.
> - Align the '=' signs vertically in pruss_irqchip structure.
> - Change the irq type in xlate handler from IRQ_TYPE_NONE to
> IRQ_TYPE_LEVEL_MASK

Gruik? (yes, that's approximately the noise I made reading this)

[...]

> +static void pruss_intc_init(struct pruss_intc *intc)
> +{
> + const struct pruss_intc_match_data *soc_config = intc->soc_config;
> + int num_chnl_map_regs, num_host_intr_regs, num_event_type_regs, i;
> +
> + num_chnl_map_regs = DIV_ROUND_UP(soc_config->num_system_events,
> + CMR_EVT_PER_REG);
> + num_host_intr_regs = DIV_ROUND_UP(soc_config->num_host_events,
> + HMR_CH_PER_REG);
> + num_event_type_regs = DIV_ROUND_UP(soc_config->num_system_events,
> 32);
> +
> + /*
> + * configure polarity (SIPR register) to active high and
> + * type (SITR register) to level interrupt for all system events
> + */

So I read this...

[...]

> +static int
> +pruss_intc_irq_domain_xlate(struct irq_domain *d, struct device_node
> *node,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq, unsigned int *out_type)
> +{
> + struct pruss_intc *intc = d->host_data;
> + struct device *dev = intc->dev;
> + int ret, sys_event, channel, host;
> +
> + if (intsize < 3)
> + return -EINVAL;
> +
> + sys_event = intspec[0];
> + if (sys_event < 0 || sys_event >=
> intc->soc_config->num_system_events) {
> + dev_err(dev, "%d is not valid event number\n", sys_event);
> + return -EINVAL;
> + }
> +
> + channel = intspec[1];
> + if (channel < 0 || channel >= intc->soc_config->num_host_events) {
> + dev_err(dev, "%d is not valid channel number", channel);
> + return -EINVAL;
> + }
> +
> + host = intspec[2];
> + if (host < 0 || host >= intc->soc_config->num_host_events) {
> + dev_err(dev, "%d is not valid host irq number\n", host);
> + return -EINVAL;
> + }
> +
> + /* check if requested sys_event was already mapped, if so validate it
> */
> + ret = pruss_intc_validate_mapping(intc, sys_event, channel, host);
> + if (ret)
> + return ret;
> +
> + *out_hwirq = sys_event;
> + *out_type = IRQ_TYPE_LEVEL_MASK;

... and then I see that.

What does IRQ_TYPE_LEVEL_MASK even mean? Can the interrupt be triggered
as
level high and low *at the same time*? (this is a rhetorical question).

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

\
 
 \ /
  Last update: 2020-09-15 18:07    [W:0.068 / U:6.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site