public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Qais Yousef <qais.yousef@imgtec.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	<linux-kernel@vger.kernel.org>, <marc.zyngier@arm.com>,
	<jason@lakedaemon.net>, <linux-mips@linux-mips.org>
Subject: Re: [PATCH 0/6] Implement generic IPI support mechanism
Date: Wed, 30 Sep 2015 14:34:43 +0100	[thread overview]
Message-ID: <560BE4F3.7060607@imgtec.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1509292101420.4500@nanos>

On 09/29/2015 09:48 PM, Thomas Gleixner wrote:
>
> 	 Now how these hwirqs are allocated is a domain/architecture
> 	 specific issue.
>
> 	 x86 will just find a vector which is available on all target
> 	 cpus and mark it as used. That's a single hw irq number.
>
> 	 mips and others, which implement IPIs as regular hw interrupt
> 	 numbers, will allocate a these (consecutive) hw interrupt
> 	 numbers either from a reserved region or just from the
> 	 regular space. That's a bunch of hw irq numbers and we need
> 	 to come up with a proper storage format in the irqdata for
> 	 that. That might be
>
> 	       struct ipi_mapping {
> 		      unsigned int	nr_hwirqs;
> 		      unsigned int	cpumap[NR_CPUS];
> 	       };

Can we use NR_CPUS here? If we run in UP configuration for instance, 
this will be one. The coprocessor could be outside the NR_CPUS range in 
general, no?

How about

                         struct ipi_mapping {
                                 unsigned int        nr_hwirqs;
                                 unsigned int        nr_cpus;
                                 unsigned int        *cpumap;
                         }

where cpumap is dynamically allocated by the controller which has better 
knowledge about the supported cpu range it can talk to?

This made me realise another problem. struct cpumask is dependent on 
NR_CPUS. I can use the generic BITMAP I suppose?

> 	 or some other appropriate storage format like:
>
> 	       struct ipi_mapping {
> 	       	      unsigned int	hwirq_base;
> 		      unsigned int	cpu_offset;
> 		      unsigned int	nr_hwirqs;
> 	       };
>
> 	 which is less space consuming, but restricted to consecutive
> 	 hwirqs which can be mapped to the cpu number linearly:
>
> 	 	hwirq = hwirq_base + cpu - cpu_offset;
> 	
>


This could work without worrying about NR_CPUS but it would be nice not 
to restrict the controller to consecutive hwirqs.

Thanks a lot for the comprehensive pointers!

Thanks,
Qais

  reply	other threads:[~2015-09-30 13:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 14:49 [PATCH 0/6] Implement generic IPI support mechanism Qais Yousef
2015-09-23 14:49 ` [PATCH 1/6] irqdomain: add new IRQ_DOMAIN_FLAGS_IPI Qais Yousef
2015-09-23 14:49 ` [PATCH 2/6] irqdomain: add a new send_ipi() to irq_domain_ops Qais Yousef
2015-09-23 16:44   ` Jiang Liu
2015-09-24  8:12     ` Qais Yousef
2015-09-23 14:49 ` [PATCH 3/6] irqdomain: add struct irq_hwcfg and helper functions Qais Yousef
2015-09-23 14:49 ` [PATCH 4/6] irq: add a new generic IPI handling code to irq core Qais Yousef
2015-09-23 16:50   ` Jiang Liu
2015-09-24  8:26     ` Qais Yousef
2015-09-29 16:15       ` Thomas Gleixner
2015-09-23 14:49 ` [PATCH 5/6] irqchip: mips-gic: add a IPI hierarchy domain Qais Yousef
2015-09-23 14:49 ` [PATCH 6/6] irqchip: mips-gic: use the new generic IPI API Qais Yousef
2015-09-23 16:54 ` [PATCH 0/6] Implement generic IPI support mechanism Jiang Liu
2015-09-24  8:39   ` Qais Yousef
2015-09-29 20:48     ` Thomas Gleixner
2015-09-30 13:34       ` Qais Yousef [this message]
2015-09-30 14:03         ` Thomas Gleixner
2015-09-30 14:08           ` Qais Yousef

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=560BE4F3.7060607@imgtec.com \
    --to=qais.yousef@imgtec.com \
    --cc=jason@lakedaemon.net \
    --cc=jiang.liu@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=marc.zyngier@arm.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox