lkml.org 
[lkml]   [2012]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] irq_domain: Standardise legacy/linear domain selection
From
On Thu, Jul 5, 2012 at 2:19 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> A large proportion of interrupt controllers that support legacy mappings
> do so because non-DT systems need to use fixed IRQ numbers when registering
> devices via buses but can otherwise use a linear mapping. The interrupt
> controller itself typically is not affected by the mapping used and best
> practice is to use a linear mapping where possible so drivers frequently
> select at runtime depending on if a legacy range has been allocated to
> them.
>
> Standardise this behaviour by providing irq_domain_register_simple() which
> will allocate a linear mapping unless a positive first_irq is provided in
> which case it will fall back to a legacy mapping. This helps make best
> practice for irq_domain adoption clearer.

We have a hardware which doesn't support ACPI nor DT. We had got a nice
issue with irq domains after the gpio driver has been moved to the
linear scheme.
Our internal discussion is roughly about misdesigned irq domains
concept for that
kind of hardware. In generic case we could have more than one PIC, and more than
one hardware that requires real 1:1 mapping of the irq numbers, and
kernel doesn't
know about the last mapping until real driver module is loaded (for
example a PCI
controller of something).

The issue is in plain array of the numbers that are assigned to the devices.
Somehow looks better to have real namespaces, or even hide irq number in the API
struct device, request_irq(), but keep reference between driver and PIC via some
object.

So, given solution just hides an issue, but doesn't resolve it fully
from my p.o.v.

--
With Best Regards,
Andy Shevchenko


\
 
 \ /
  Last update: 2012-07-05 14:21    [W:0.060 / U:7.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site