* Re: [RFCv2 00/14]
From: Benjamin Herrenschmidt @ 2012-01-27 22:08 UTC (permalink / raw)
To: Grant Likely
Cc: Cousson, Benoit, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Shawn Guo, linuxppc-dev
In-Reply-To: <CACxGe6vA6CSCAU82uuMaycqDBt+JG3KvXzAURDWQ0Deyeg13Ow@mail.gmail.com>
On Thu, 2012-01-26 at 14:33 -0700, Grant Likely wrote:
> I've got the x86 fix in my tree now. It will be part of the next
> merge. MIPS, Microblaze and OpenRISC cannot turn on CONFIG_IRQ_DOMAIN
> without rework. I just hacked together the microblaze version, but
> Michal will have to verify that it is correct. I just posted it. It
> will be similar for the other two.
>
> The real problem is sparc which does something entirely different for
> irqs. Rather than resolving irqs on-demand, it calculates the Linux
> irq numbers at boot time for every node in the tree. The irq_domains
> will need to be set up for all interrupt controllers before sparc
> begins it's big walk of the tree to resolve interrupts. I haven't dug
> into everything that needs to be done to support this.
>
> I don't think you can count on turning on IRQ_DOMAIN on all
> architectures just yet. Adding irq_domain support directly to
> irq_generic_chip is going to be difficult for that reason. However,
> it would be useful to have an irq_domain+irq_generic_chip wrapper that
> can be enabled only when IRQ_DOMAIN is enabled.
Beware also that there are plenty of cases where 1 irq domain != 1 irq
chip, for example on cell or xics where a single domain can encompass
multiple chips. I don't know whether x86 APICs are the same, they could
be tho :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFCv2 00/14]
From: Grant Likely @ 2012-01-27 22:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cousson, Benoit, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Shawn Guo, linuxppc-dev
In-Reply-To: <1327702113.24487.19.camel@pasglop>
On Fri, Jan 27, 2012 at 3:08 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Thu, 2012-01-26 at 14:33 -0700, Grant Likely wrote:
>
>> I've got the x86 fix in my tree now. =A0It will be part of the next
>> merge. =A0MIPS, Microblaze and OpenRISC cannot turn on CONFIG_IRQ_DOMAIN
>> without rework. =A0I just hacked together the microblaze version, but
>> Michal will have to verify that it is correct. =A0I just posted it. =A0I=
t
>> will be similar for the other two.
>>
>> The real problem is sparc which does something entirely different for
>> irqs. =A0Rather than resolving irqs on-demand, it calculates the Linux
>> irq numbers at boot time for every node in the tree. =A0The irq_domains
>> will need to be set up for all interrupt controllers before sparc
>> begins it's big walk of the tree to resolve interrupts. =A0I haven't dug
>> into everything that needs to be done to support this.
>>
>> I don't think you can count on turning on IRQ_DOMAIN on all
>> architectures just yet. =A0Adding irq_domain support directly to
>> irq_generic_chip is going to be difficult for that reason. =A0However,
>> it would be useful to have an irq_domain+irq_generic_chip wrapper that
>> can be enabled only when IRQ_DOMAIN is enabled.
>
> Beware also that there are plenty of cases where 1 irq domain !=3D 1 irq
> chip, for example on cell or xics where a single domain can encompass
> multiple chips. I don't know whether x86 APICs are the same, they could
> be tho :-)
Right, there will be some controllers using multiple irq_generic_chip
instances for a single irq_domain. Anything with banks of irq
registers is a candidate here.
g.
^ permalink raw reply
* [PATCH 06/13] PCI, powerpc: Register busn_res for root buses
From: Yinghai Lu @ 2012-01-28 2:49 UTC (permalink / raw)
To: Jesse Barnes, Benjamin Herrenschmidt, Tony Luck
Cc: linux-arch, linux-pci, linuxppc-dev, linux-kernel, Linus Torvalds,
Paul Mackerras, Bjorn Helgaas, Yinghai Lu
In-Reply-To: <1327718971-9598-1-git-send-email-yinghai@kernel.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index cce98d7..501f29b 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1732,6 +1732,8 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
bus->secondary = hose->first_busno;
hose->bus = bus;
+ pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_busno);
+
/* Get probe mode and perform scan */
mode = PCI_PROBE_NORMAL;
if (node && ppc_md.pci_probe_mode)
@@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
of_scan_bus(node, bus);
}
- if (mode == PCI_PROBE_NORMAL)
+ if (mode == PCI_PROBE_NORMAL) {
+ pci_bus_update_busn_res_end(bus, 255);
hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
+ pci_bus_update_busn_res_end(bus, bus->subordinate);
+ }
/* Platform gets a chance to do some global fixups before
* we proceed to resource allocation
--
1.7.7
^ permalink raw reply related
* Re: [RFCv2 01/14] irq_domain: add documentation and MAINTAINERS entry.
From: Grant Likely @ 2012-01-28 17:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev
In-Reply-To: <4F1F02E5.3000605@xenotime.net>
On Tue, Jan 24, 2012 at 11:13:41AM -0800, Randy Dunlap wrote:
> On 01/23/2012 01:07 PM, Grant Likely wrote:
> > Documentation for irq_domain library which will be created in subsequent
> > patches.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > Documentation/IRQ-domain.txt | 113 ++++++++++++++++++++++++++++++++++++++++++
> > MAINTAINERS | 9 +++
> > 2 files changed, 122 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/IRQ-domain.txt
> >
> > diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
> > new file mode 100644
> > index 0000000..247f32a
> > --- /dev/null
> > +++ b/Documentation/IRQ-domain.txt
> > @@ -0,0 +1,113 @@
> > +irq_domain interrupt number mapping library
> > +
> > +The current design of the Linux kernel uses a single large number
> > +space where each separate IRQ source is assigned a different number.
> > +This is simple when there is only one interrupt controller, but in
> > +systems with controllers the kernel must ensure that each one does not
>
> with multiple interrupt controllers,
Hi Randy. Thanks for the comments. I've made the changes and they'll appear
in v4 of the series.
g.
^ permalink raw reply
* Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
From: Sebastian Andrzej Siewior @ 2012-01-28 16:44 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1327700179-17454-23-git-send-email-grant.likely@secretlab.ca>
* Grant Likely | 2012-01-27 14:36:16 [-0700]:
>This patch removes the x86-specific definition of irq_domain and replaces
>it with the common implementation.
I pulled your devicetree/next tree. After this patch I get:
|Hierarchical RCU implementation.
|NR_IRQS:2304 nr_irqs:256 16
|------------[ cut here ]------------
|WARNING: at /home/bigeasy/work/shiva/git/linux-2.6-tip/kernel/irq/irqdomain.c:114 irq_domain_add_legacy+0x75/0x150()
|Modules linked in:
|Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1+ #65
|Call Trace:
| [<c15044e0>] ? printk+0x18/0x1a
| [<c102cdbd>] warn_slowpath_common+0x6d/0xa0
| [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
| [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
| [<c102ce0d>] warn_slowpath_null+0x1d/0x20
| [<c1095575>] irq_domain_add_legacy+0x75/0x150
| [<c1714824>] x86_add_irq_domains+0x96/0xd6
| [<c1708df2>] init_IRQ+0x8/0x33
| [<c170557f>] start_kernel+0x191/0x2e1
| [<c170517f>] ? loglevel+0x2b/0x2b
| [<c1705081>] i386_start_kernel+0x81/0x86
|---[ end trace 4eaa2a86a8e2da22 ]---
|------------[ cut here ]------------
|kernel BUG at /home/bigeasy/work/shiva/git/linux-2.6-tip/arch/x86/kernel/devicetree.c:367!
The warning is comming from this piece in irq_domain_add_legacy()
|for (i = 0; i < size; i++) {
| int irq = first_irq + i;
| struct irq_data *irq_data = irq_get_irq_data(irq);
|
| if (WARN_ON(!irq_data || irq_data->domain)) {
irq_data is NULL here.
| mutex_unlock(&irq_domain_mutex);
| of_node_put(domain->of_node);
| kfree(domain);
| return NULL;
| }
| }
|
This is not always the case. arch_early_irq_init() in [0] sets up the
first 16 entries. The reminaing few (there is a toal of 24 irqs for
first ioapic and a second ioapic) are not initialized. This happens
later via ->xlate, ioapic_xlate() => io_apic_setup_irq_pin() =>
alloc_irq_and_cfg_at() calls irq_set_chip_data() on demand.
[0] arch/x86/kernel/apic/io_apic.c
Sebastian
^ permalink raw reply
* Re: [PATCH v3 01/25] irq_domain: add documentation and MAINTAINERS entry.
From: Randy Dunlap @ 2012-01-28 18:23 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1327700179-17454-2-git-send-email-grant.likely@secretlab.ca>
On 01/27/2012 01:35 PM, Grant Likely wrote:
> Documentation for irq_domain library which will be created in subsequent
> patches.
I posted a lot of comments to v2 on Jan. 24.
Looks like they were ignored.
Please see http://marc.info/?l=linuxppc-embedded&m=132742951211808&w=2
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Milton Miller <miltonm@bga.com>
> ---
> Documentation/IRQ-domain.txt | 113 ++++++++++++++++++++++++++++++++++++++++++
> MAINTAINERS | 9 +++
> 2 files changed, 122 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/IRQ-domain.txt
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH v3 00/25] irq_domain generalization and refinement
From: Rob Herring @ 2012-01-28 18:38 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1327700179-17454-1-git-send-email-grant.likely@secretlab.ca>
On 01/27/2012 03:35 PM, Grant Likely wrote:
> Hey everyone,
>
> This patch series is ready for much wider consumption now. I'd like
> to get it into linux-next ASAP because there will be ARM board support
> depending on it. I'll wait a few days before I ask Stephen to pull
> this in.
>
> Stephen/Milton/Ben, any testing you can help with here would be
> appreciated since you've got access to a wider variety of Power
> machines than I do.
>
> Thomas, I think it makes sense to maintain this in a separate branch
> from other irq changes until the next merge window. If you prefer,
> I'm happy to maintain this branch until then.
>
I picked up your irqdomain/next branch and it doesn't compile:
CC kernel/irq/irqdomain.o
kernel/irq/irqdomain.c: In function ‘irq_create_mapping’:
kernel/irq/irqdomain.c:403:47: error: ‘irq’ undeclared (first use in
this function)
kernel/irq/irqdomain.c:403:47: note: each undeclared identifier is
reported only once for each function it app
Rob
> Cheers,
> g.
>
> The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
>
> Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)
>
> are available in the git repository at:
> git://git.secretlab.ca/git/linux-2.6 irqdomain/next
>
> Grant Likely (24):
> irq_domain: add documentation and MAINTAINERS entry.
> dt: Make irqdomain less verbose
> irq_domain: Make irq_domain structure match powerpc's irq_host
> irq_domain: convert microblaze from irq_host to irq_domain
> irq_domain/powerpc: Use common irq_domain structure instead of irq_host
> irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
> irq_domain/powerpc: Eliminate virq_is_host()
> irq_domain: Move irq_domain code from powerpc to kernel/irq
> irqdomain: remove NO_IRQ from irq domain code
> irq_domain: Remove references to old irq_host names
> irq_domain: Replace irq_alloc_host() with revmap-specific initializers
> irq_domain: Add support for base irq and hwirq in legacy mappings
> irq_domain: Remove 'new' irq_domain in favour of the ppc one
> irq_domain: Remove irq_domain_add_simple()
> irq_domain: Create common xlate functions that device drivers can use
> irq_domain: constify irq_domain_ops
> irq_domain/c6x: constify irq_domain structures
> irq_domain/c6x: Use library of xlate functions
> irq_domain/powerpc: constify irq_domain_ops
> irqdomain/powerpc: Replace custom xlate functions with library functions
> irq_domain/x86: Convert x86 (embedded) to use common irq_domain
> irq_domain: Include hwirq number in /proc/interrupts
> irq_domain: remove "hint" when allocating irq numbers
> irq_domain: mostly eliminate slow-path revmap lookups
>
> Mark Salter (1):
> irq_domain/c6x: Convert c6x to use generic irq_domain support.
>
> Documentation/IRQ-domain.txt | 113 +++
> MAINTAINERS | 9 +
> arch/arm/common/gic.c | 95 ++--
> arch/arm/common/vic.c | 16 +-
> arch/arm/include/asm/hardware/gic.h | 4 +-
> arch/arm/include/asm/hardware/vic.h | 2 +
> arch/arm/mach-exynos/common.c | 2 +-
> arch/arm/mach-imx/mach-imx6q.c | 3 +-
> arch/arm/mach-msm/board-msm8x60.c | 8 +-
> arch/arm/mach-mx5/imx51-dt.c | 4 +-
> arch/arm/mach-mx5/imx53-dt.c | 4 +-
> arch/arm/mach-omap2/board-generic.c | 2 +-
> arch/arm/mach-prima2/irq.c | 2 +-
> arch/arm/mach-versatile/core.c | 5 +-
> arch/c6x/Kconfig | 1 +
> arch/c6x/include/asm/irq.h | 245 +-------
> arch/c6x/kernel/irq.c | 612 +----------------
> arch/c6x/platforms/megamod-pic.c | 25 +-
> arch/microblaze/include/asm/irq.h | 4 +-
> arch/microblaze/kernel/irq.c | 2 +-
> arch/microblaze/kernel/setup.c | 2 -
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/ehv_pic.h | 2 +-
> arch/powerpc/include/asm/i8259.h | 2 +-
> arch/powerpc/include/asm/irq.h | 247 +-------
> arch/powerpc/include/asm/mpic.h | 2 +-
> arch/powerpc/include/asm/xics.h | 2 +-
> arch/powerpc/kernel/irq.c | 617 +----------------
> arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 12 +-
> arch/powerpc/platforms/52xx/media5200.c | 15 +-
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 16 +-
> arch/powerpc/platforms/52xx/mpc52xx_pic.c | 12 +-
> arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 14 +-
> arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 15 +-
> arch/powerpc/platforms/86xx/gef_pic.c | 15 +-
> arch/powerpc/platforms/cell/axon_msi.c | 29 +-
> arch/powerpc/platforms/cell/beat_interrupt.c | 16 +-
> arch/powerpc/platforms/cell/interrupt.c | 16 +-
> arch/powerpc/platforms/cell/spider-pic.c | 14 +-
> arch/powerpc/platforms/embedded6xx/flipper-pic.c | 30 +-
> arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 35 +-
> arch/powerpc/platforms/iseries/irq.c | 11 +-
> arch/powerpc/platforms/powermac/pic.c | 26 +-
> arch/powerpc/platforms/powermac/smp.c | 9 +-
> arch/powerpc/platforms/ps3/interrupt.c | 11 +-
> arch/powerpc/platforms/wsp/opb_pic.c | 26 +-
> arch/powerpc/sysdev/cpm1.c | 9 +-
> arch/powerpc/sysdev/cpm2_pic.c | 23 +-
> arch/powerpc/sysdev/ehv_pic.c | 14 +-
> arch/powerpc/sysdev/fsl_msi.c | 10 +-
> arch/powerpc/sysdev/fsl_msi.h | 2 +-
> arch/powerpc/sysdev/i8259.c | 15 +-
> arch/powerpc/sysdev/ipic.c | 31 +-
> arch/powerpc/sysdev/ipic.h | 2 +-
> arch/powerpc/sysdev/mpc8xx_pic.c | 11 +-
> arch/powerpc/sysdev/mpic.c | 17 +-
> arch/powerpc/sysdev/mpic_msi.c | 2 +-
> arch/powerpc/sysdev/mv64x60_pic.c | 11 +-
> arch/powerpc/sysdev/qe_lib/qe_ic.c | 26 +-
> arch/powerpc/sysdev/qe_lib/qe_ic.h | 2 +-
> arch/powerpc/sysdev/tsi108_pci.c | 22 +-
> arch/powerpc/sysdev/uic.c | 26 +-
> arch/powerpc/sysdev/xics/xics-common.c | 28 +-
> arch/powerpc/sysdev/xilinx_intc.c | 19 +-
> arch/x86/Kconfig | 2 +
> arch/x86/include/asm/irq_controller.h | 12 -
> arch/x86/include/asm/prom.h | 10 -
> arch/x86/kernel/devicetree.c | 101 +--
> drivers/gpio/gpio-mpc8xxx.c | 30 +-
> drivers/mfd/twl-core.c | 12 +-
> drivers/net/phy/mdio-gpio.c | 4 +-
> include/linux/irqdomain.h | 190 ++++--
> kernel/irq/irqdomain.c | 816 +++++++++++++++++++---
> kernel/irq/proc.c | 3 +
> 74 files changed, 1334 insertions(+), 2471 deletions(-)
> create mode 100644 Documentation/IRQ-domain.txt
> delete mode 100644 arch/x86/include/asm/irq_controller.h
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH v3 00/25] irq_domain generalization and refinement
From: Grant Likely @ 2012-01-28 19:10 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F2440A2.5080601@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8608 bytes --]
On Jan 28, 2012 11:38 AM, "Rob Herring" <robherring2@gmail.com> wrote:
>
> On 01/27/2012 03:35 PM, Grant Likely wrote:
> > Hey everyone,
> >
> > This patch series is ready for much wider consumption now. I'd like
> > to get it into linux-next ASAP because there will be ARM board support
> > depending on it. I'll wait a few days before I ask Stephen to pull
> > this in.
> >
> > Stephen/Milton/Ben, any testing you can help with here would be
> > appreciated since you've got access to a wider variety of Power
> > machines than I do.
> >
> > Thomas, I think it makes sense to maintain this in a separate branch
> > from other irq changes until the next merge window. If you prefer,
> > I'm happy to maintain this branch until then.
> >
>
> I picked up your irqdomain/next branch and it doesn't compile:
>
> CC kernel/irq/irqdomain.o
> kernel/irq/irqdomain.c: In function ‘irq_create_mapping’:
> kernel/irq/irqdomain.c:403:47: error: ‘irq’ undeclared (first use in
> this function)
> kernel/irq/irqdomain.c:403:47: note: each undeclared identifier is
> reported only once for each function it app
Oops, I had fixed that but didn't refresh the patch. Change the references
in that function from irq to virq, or pop off the top patch to fix.
I'll push out a fixed tree when I get home.
g.
>
> Rob
>
> > Cheers,
> > g.
> >
> > The following changes since commit
dcd6c92267155e70a94b3927bce681ce74b80d1f:
> >
> > Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)
> >
> > are available in the git repository at:
> > git://git.secretlab.ca/git/linux-2.6 irqdomain/next
> >
> > Grant Likely (24):
> > irq_domain: add documentation and MAINTAINERS entry.
> > dt: Make irqdomain less verbose
> > irq_domain: Make irq_domain structure match powerpc's irq_host
> > irq_domain: convert microblaze from irq_host to irq_domain
> > irq_domain/powerpc: Use common irq_domain structure instead of
irq_host
> > irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc()
instead
> > irq_domain/powerpc: Eliminate virq_is_host()
> > irq_domain: Move irq_domain code from powerpc to kernel/irq
> > irqdomain: remove NO_IRQ from irq domain code
> > irq_domain: Remove references to old irq_host names
> > irq_domain: Replace irq_alloc_host() with revmap-specific
initializers
> > irq_domain: Add support for base irq and hwirq in legacy mappings
> > irq_domain: Remove 'new' irq_domain in favour of the ppc one
> > irq_domain: Remove irq_domain_add_simple()
> > irq_domain: Create common xlate functions that device drivers can
use
> > irq_domain: constify irq_domain_ops
> > irq_domain/c6x: constify irq_domain structures
> > irq_domain/c6x: Use library of xlate functions
> > irq_domain/powerpc: constify irq_domain_ops
> > irqdomain/powerpc: Replace custom xlate functions with library
functions
> > irq_domain/x86: Convert x86 (embedded) to use common irq_domain
> > irq_domain: Include hwirq number in /proc/interrupts
> > irq_domain: remove "hint" when allocating irq numbers
> > irq_domain: mostly eliminate slow-path revmap lookups
> >
> > Mark Salter (1):
> > irq_domain/c6x: Convert c6x to use generic irq_domain support.
> >
> > Documentation/IRQ-domain.txt | 113 +++
> > MAINTAINERS | 9 +
> > arch/arm/common/gic.c | 95 ++--
> > arch/arm/common/vic.c | 16 +-
> > arch/arm/include/asm/hardware/gic.h | 4 +-
> > arch/arm/include/asm/hardware/vic.h | 2 +
> > arch/arm/mach-exynos/common.c | 2 +-
> > arch/arm/mach-imx/mach-imx6q.c | 3 +-
> > arch/arm/mach-msm/board-msm8x60.c | 8 +-
> > arch/arm/mach-mx5/imx51-dt.c | 4 +-
> > arch/arm/mach-mx5/imx53-dt.c | 4 +-
> > arch/arm/mach-omap2/board-generic.c | 2 +-
> > arch/arm/mach-prima2/irq.c | 2 +-
> > arch/arm/mach-versatile/core.c | 5 +-
> > arch/c6x/Kconfig | 1 +
> > arch/c6x/include/asm/irq.h | 245 +-------
> > arch/c6x/kernel/irq.c | 612
+----------------
> > arch/c6x/platforms/megamod-pic.c | 25 +-
> > arch/microblaze/include/asm/irq.h | 4 +-
> > arch/microblaze/kernel/irq.c | 2 +-
> > arch/microblaze/kernel/setup.c | 2 -
> > arch/powerpc/Kconfig | 1 +
> > arch/powerpc/include/asm/ehv_pic.h | 2 +-
> > arch/powerpc/include/asm/i8259.h | 2 +-
> > arch/powerpc/include/asm/irq.h | 247 +-------
> > arch/powerpc/include/asm/mpic.h | 2 +-
> > arch/powerpc/include/asm/xics.h | 2 +-
> > arch/powerpc/kernel/irq.c | 617
+----------------
> > arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 12 +-
> > arch/powerpc/platforms/52xx/media5200.c | 15 +-
> > arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 16 +-
> > arch/powerpc/platforms/52xx/mpc52xx_pic.c | 12 +-
> > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 14 +-
> > arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 15 +-
> > arch/powerpc/platforms/86xx/gef_pic.c | 15 +-
> > arch/powerpc/platforms/cell/axon_msi.c | 29 +-
> > arch/powerpc/platforms/cell/beat_interrupt.c | 16 +-
> > arch/powerpc/platforms/cell/interrupt.c | 16 +-
> > arch/powerpc/platforms/cell/spider-pic.c | 14 +-
> > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 30 +-
> > arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 35 +-
> > arch/powerpc/platforms/iseries/irq.c | 11 +-
> > arch/powerpc/platforms/powermac/pic.c | 26 +-
> > arch/powerpc/platforms/powermac/smp.c | 9 +-
> > arch/powerpc/platforms/ps3/interrupt.c | 11 +-
> > arch/powerpc/platforms/wsp/opb_pic.c | 26 +-
> > arch/powerpc/sysdev/cpm1.c | 9 +-
> > arch/powerpc/sysdev/cpm2_pic.c | 23 +-
> > arch/powerpc/sysdev/ehv_pic.c | 14 +-
> > arch/powerpc/sysdev/fsl_msi.c | 10 +-
> > arch/powerpc/sysdev/fsl_msi.h | 2 +-
> > arch/powerpc/sysdev/i8259.c | 15 +-
> > arch/powerpc/sysdev/ipic.c | 31 +-
> > arch/powerpc/sysdev/ipic.h | 2 +-
> > arch/powerpc/sysdev/mpc8xx_pic.c | 11 +-
> > arch/powerpc/sysdev/mpic.c | 17 +-
> > arch/powerpc/sysdev/mpic_msi.c | 2 +-
> > arch/powerpc/sysdev/mv64x60_pic.c | 11 +-
> > arch/powerpc/sysdev/qe_lib/qe_ic.c | 26 +-
> > arch/powerpc/sysdev/qe_lib/qe_ic.h | 2 +-
> > arch/powerpc/sysdev/tsi108_pci.c | 22 +-
> > arch/powerpc/sysdev/uic.c | 26 +-
> > arch/powerpc/sysdev/xics/xics-common.c | 28 +-
> > arch/powerpc/sysdev/xilinx_intc.c | 19 +-
> > arch/x86/Kconfig | 2 +
> > arch/x86/include/asm/irq_controller.h | 12 -
> > arch/x86/include/asm/prom.h | 10 -
> > arch/x86/kernel/devicetree.c | 101 +--
> > drivers/gpio/gpio-mpc8xxx.c | 30 +-
> > drivers/mfd/twl-core.c | 12 +-
> > drivers/net/phy/mdio-gpio.c | 4 +-
> > include/linux/irqdomain.h | 190 ++++--
> > kernel/irq/irqdomain.c | 816
+++++++++++++++++++---
> > kernel/irq/proc.c | 3 +
> > 74 files changed, 1334 insertions(+), 2471 deletions(-)
> > create mode 100644 Documentation/IRQ-domain.txt
> > delete mode 100644 arch/x86/include/asm/irq_controller.h
> >
> > _______________________________________________
> > devicetree-discuss mailing list
> > devicetree-discuss@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/devicetree-discuss
>
[-- Attachment #2: Type: text/html, Size: 10383 bytes --]
^ permalink raw reply
* Re: [PATCH v3 01/25] irq_domain: add documentation and MAINTAINERS entry.
From: Grant Likely @ 2012-01-28 19:59 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F243D2C.7040709@xenotime.net>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Jan 28, 2012 10:25 AM, "Randy Dunlap" <rdunlap@xenotime.net> wrote:
>
> On 01/27/2012 01:35 PM, Grant Likely wrote:
> > Documentation for irq_domain library which will be created in subsequent
> > patches.
>
> I posted a lot of comments to v2 on Jan. 24.
> Looks like they were ignored.
I just hadn't gotten to them. I've made the changes since and they will be
part of v4.
g.
[-- Attachment #2: Type: text/html, Size: 527 bytes --]
^ permalink raw reply
* Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
From: Kevin Cernekee @ 2012-01-28 22:38 UTC (permalink / raw)
To: Ralf Baechle, Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64, linux-sh,
linux, linux-pci, Jesse Barnes, Chen Liqin, Paul Mackerras,
H. Peter Anvin, sparclinux, Guan Xuetao, Lennox Wu, Jonas Bonn,
Jesper Nilsson, Russell King, linux-hexagon, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven, linux-arch,
Arend van Spriel, Matt Turner, Fenghua Yu, Lasse Collin,
Arnd Bergmann, Lucas De Marchi, microblaze-uclinux, Paul Bolle,
Rob Herring, Mikael Starvik, Ivan Kokshaysky, Franky Lin,
Thomas Gleixner, Fabio Baltieri, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Michal Simek, Tony Luck,
linux-parisc, linux-cris-kernel, Paul Gortmaker, linux-kernel,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <66457f7750d7d14229fcf8d0b011aba63185a75d.1322163031.git.mst@redhat.com>
On Thu, Nov 24, 2011 at 12:18 PM, Michael S. Tsirkin <mst@redhat.com> wrote=
:
> mips copied pci_iomap from generic code, probably to avoid
> pulling the rest of iomap.c in. =C2=A0Since that's in
> a separate file now, we can reuse the common implementation.
[snip]
> - =C2=A0 =C2=A0 =C2=A0 if (flags & IORESOURCE_IO)
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ioport_map_pci(=
dev, start, len);
While investigating a new warning on the 3.3-rc1 MIPS build (unused
static function ioport_map_pci()), I noticed that this patch has shown
up in Linus' tree as commit eab90291d35438bcebf7c3dc85be66d0f24e3002.
I am not completely clear on the implications it has on mapping PCI I/O reg=
ions:
Prior to this change, the MIPS version of pci_iomap() called a
MIPS-specific function, ioport_map_pci(), which tried to use the PCI
controller's io_map_base field to determine the base address of the
PCI I/O space. It also had a fallback mechanism to deal with the case
where io_map_base is unset.
Now, in 3.3-rc1, the generic version of pci_iomap() is used instead.
This code just calls arch/mips/lib/iomap.c:ioport_map() on these
regions. ioport_map() falls through to ioport_map_legacy(), which
always uses mips_io_port_base (not the PCI controller's io_map_base)
as the base address. But on MIPS, it is still permissible to use
different I/O port bases for PCI devices and for legacy (ISA?)
devices.
Is this new behavior desirable, or are there any supported platforms
on which adverse effects might be seen?
As for my part, I don't use PCI I/O regions at all - just memory
regions. I'm more worried about making sure my tree builds with 0
warnings.
If we do want to move ahead with the switch to GENERIC_PCI_IOMAP now,
I have patches to scrap iomap-pci.c entirely and squash the unused
function warning.
If we still want to support the case where io_map_base !=3D
mips_io_port_base, maybe it would be better to revert commit eab90291
for 3.3.
Might also want to take a look at SH since it also appears to have an
orphaned ioport_map_pci() function.
What are your thoughts?
^ permalink raw reply
* Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
From: Grant Likely @ 2012-01-29 0:35 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120128164405.GA20763@linutronix.de>
On Sat, Jan 28, 2012 at 05:44:05PM +0100, Sebastian Andrzej Siewior wrote:
> * Grant Likely | 2012-01-27 14:36:16 [-0700]:
>
> >This patch removes the x86-specific definition of irq_domain and replaces
> >it with the common implementation.
>
> I pulled your devicetree/next tree. After this patch I get:
>
> |Hierarchical RCU implementation.
> |NR_IRQS:2304 nr_irqs:256 16
> |------------[ cut here ]------------
> |WARNING: at /home/bigeasy/work/shiva/git/linux-2.6-tip/kernel/irq/irqdomain.c:114 irq_domain_add_legacy+0x75/0x150()
> |Modules linked in:
> |Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1+ #65
> |Call Trace:
> | [<c15044e0>] ? printk+0x18/0x1a
> | [<c102cdbd>] warn_slowpath_common+0x6d/0xa0
> | [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
> | [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
> | [<c102ce0d>] warn_slowpath_null+0x1d/0x20
> | [<c1095575>] irq_domain_add_legacy+0x75/0x150
> | [<c1714824>] x86_add_irq_domains+0x96/0xd6
> | [<c1708df2>] init_IRQ+0x8/0x33
> | [<c170557f>] start_kernel+0x191/0x2e1
> | [<c170517f>] ? loglevel+0x2b/0x2b
> | [<c1705081>] i386_start_kernel+0x81/0x86
> |---[ end trace 4eaa2a86a8e2da22 ]---
> |------------[ cut here ]------------
> |kernel BUG at /home/bigeasy/work/shiva/git/linux-2.6-tip/arch/x86/kernel/devicetree.c:367!
>
> The warning is comming from this piece in irq_domain_add_legacy()
> |for (i = 0; i < size; i++) {
> | int irq = first_irq + i;
> | struct irq_data *irq_data = irq_get_irq_data(irq);
> |
> | if (WARN_ON(!irq_data || irq_data->domain)) {
>
> irq_data is NULL here.
>
> | mutex_unlock(&irq_domain_mutex);
> | of_node_put(domain->of_node);
> | kfree(domain);
> | return NULL;
> | }
> | }
> |
>
> This is not always the case. arch_early_irq_init() in [0] sets up the
> first 16 entries. The reminaing few (there is a toal of 24 irqs for
> first ioapic and a second ioapic) are not initialized. This happens
> later via ->xlate, ioapic_xlate() => io_apic_setup_irq_pin() =>
> alloc_irq_and_cfg_at() calls irq_set_chip_data() on demand.
>
> [0] arch/x86/kernel/apic/io_apic.c
That's not going to work then. The irqs must not be set up in ->xlate.
They need to be set up either before creating the irq_domain, or in the
.map hook. Inside the map hook is preferred, but having some
configured and some not at initialization time does make it difficult
g.
^ permalink raw reply
* Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
From: Grant Likely @ 2012-01-29 0:39 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120129003550.GA21385@ponder.secretlab.ca>
On Sat, Jan 28, 2012 at 5:35 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Sat, Jan 28, 2012 at 05:44:05PM +0100, Sebastian Andrzej Siewior wrote=
:
>> * Grant Likely | 2012-01-27 14:36:16 [-0700]:
>>
>> >This patch removes the x86-specific definition of irq_domain and replac=
es
>> >it with the common implementation.
>>
>> I pulled your devicetree/next tree. After this patch I get:
>>
>> |Hierarchical RCU implementation.
>> |NR_IRQS:2304 nr_irqs:256 16
>> |------------[ cut here ]------------
>> |WARNING: at /home/bigeasy/work/shiva/git/linux-2.6-tip/kernel/irq/irqdo=
main.c:114 irq_domain_add_legacy+0x75/0x150()
>> |Modules linked in:
>> |Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1+ #65
>> |Call Trace:
>> | [<c15044e0>] ? printk+0x18/0x1a
>> | [<c102cdbd>] warn_slowpath_common+0x6d/0xa0
>> | [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
>> | [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
>> | [<c102ce0d>] warn_slowpath_null+0x1d/0x20
>> | [<c1095575>] irq_domain_add_legacy+0x75/0x150
>> | [<c1714824>] x86_add_irq_domains+0x96/0xd6
>> | [<c1708df2>] init_IRQ+0x8/0x33
>> | [<c170557f>] start_kernel+0x191/0x2e1
>> | [<c170517f>] ? loglevel+0x2b/0x2b
>> | [<c1705081>] i386_start_kernel+0x81/0x86
>> |---[ end trace 4eaa2a86a8e2da22 ]---
>> |------------[ cut here ]------------
>> |kernel BUG at /home/bigeasy/work/shiva/git/linux-2.6-tip/arch/x86/kerne=
l/devicetree.c:367!
>>
>> The warning is comming from this piece in irq_domain_add_legacy()
>> |for (i =3D 0; i < size; i++) {
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int irq =3D first_irq + i;
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct irq_data *irq_data =3D irq_get_=
irq_data(irq);
>> |
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (WARN_ON(!irq_data || irq_data->dom=
ain)) {
>>
>> irq_data is NULL here.
>>
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&irq_doma=
in_mutex);
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(domain->of=
_node);
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kfree(domain);
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL;
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> | =A0 =A0 =A0 =A0 }
>> |
>>
>> This is not always the case. arch_early_irq_init() in [0] sets up the
>> first 16 entries. The reminaing few (there is a toal of 24 irqs for
>> first ioapic and a second ioapic) are not initialized. This happens
>> later via ->xlate, ioapic_xlate() =3D> io_apic_setup_irq_pin() =3D>
>> alloc_irq_and_cfg_at() calls irq_set_chip_data() on demand.
>>
>> [0] arch/x86/kernel/apic/io_apic.c
>
> That's not going to work then. =A0The irqs must not be set up in ->xlate.
> They need to be set up either before creating the irq_domain, or in the
> .map hook. =A0Inside the map hook is preferred, but having some
> configured and some not at initialization time does make it difficult
Actually, that's still not right. irq_set_chip_data() (sets
desc->irq_data.chip_data) has nothing to do with irq_get_irq_data()
(which returns desc->irq_data). It's the allocation of the irq_desc
that is at issue here. Where does the allocation occur? (I haven't
dug in to find it yet)
g.
^ permalink raw reply
* RTC on 2.6.36 for PowerMac 8600
From: kevin diggs @ 2012-01-29 3:08 UTC (permalink / raw)
To: Linux PPC Development
Hi,
What will give me access to the RTC hardware on an old PowerMac 8600?
I modload rtc-generic. /proc/devices has:
254 rtc
and ls -l /dev/rtc*:
crw-r--r-- 2 root root 254, 0 Sep 2 2010 /dev/rtc
crw-r--r-- 2 root root 254, 0 Sep 2 2010 /dev/rtc0
crw-r--r-- 1 root root 10, 135 Aug 10 2004 /dev/rtc.old
Trying to run hwclock gives:
[root@PowerMac8600B root]# hwclock --debug
hwclock from util-linux-2.12pre
Using /dev/rtc interface to clock.
Last drift adjustment done at 1317444443 seconds after 1969
Last calibration done at 1317444443 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
RTC_RD_TIME: Invalid argument
ioctl() to /dev/rtc to read the time failed.
I could have sworn this used to work on this system???
What am I forgetting?
gzip -dc /proc/config.gz|grep -i rtc lists:
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m
# RTC interfaces
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# Platform RTC drivers
CONFIG_RTC_DRV_CMOS=m
# on-CPU RTC drivers
CONFIG_RTC_DRV_GENERIC=m
Thanks!
kevin
^ permalink raw reply
* Re: Problem in getting shared memory access on P1022RDK
From: tiejun.chen @ 2012-01-29 3:15 UTC (permalink / raw)
To: Arshad, Farrukh; +Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <93CD5F41FDBC6042A6B449764F3B35CC050CE2CD@EU-MBX-03.mgc.mentorg.com>
Arshad, Farrukh wrote:
> I have dumped TLB entries while mapping shared memory. On both cores M-Bit (MAS2[61]) is set in TLB0 entries. On both cores M-Bit is set for all valid TLB1 entries. TLB1 does contains some invalid entries which has M-Bit cleared. So I believe at this time the coherency is not the issue. Any further thoughts on the issue ?
>
Did you check all associated TLBx VPN/RPN and attribute setting are same between
two scenarios: W -> Core0 & R <- Core1 and W -> Core1 & R <- Core0?
Can you send me your TLB dump log separately if possible?
And did you try this flag 'O_SYNC'?
Tiejun
> I have modified dump_tlb_book3e function (found in arch/powerpc/xmon/xmon.c) function for BookE MMU to dump TLB entries.
>
> Regards,
> Farrukh Arshad
>
>
> -----Original Message-----
> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
> Sent: Thursday, January 12, 2012 1:09 PM
> To: Arshad, Farrukh
> Cc: Scott Wood; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Problem in getting shared memory access on P1022RDK
>
> Arshad, Farrukh wrote:
>> Adding more it,
>>
>> I have removed the shared memory kernel driver dependency just to narrow down the problem area and I have written a small piece of code in user space. A writer & a reader application which access the shared memory and I got the same behavior as with the shared memory kernel driver. Interestingly, my user space application work fine on P1022DS but not on P1022RDK however both using the same CPU modules.
>>
>> When I write a simple string on shared memory from Core 1 it is read
>> at Core 0 properly When I write a simple string on shared memory from Core 0 it is not read at Core 1.
>>
>
> Did you dump TLB entry to check page memory coherence attribute for a shared memory as I mentioned previously? This should be consistent on both sides.
>
>> With this test now I am sure the problem lies in the kernel itself. Any pointers to look for the troubled area ?
>>
>> My application code is (error checking and other code is omitted)
>>
>> #define SHM_BASE 0x1C000000
>> #define SHM_SIZE 0x400000 // 4 MB of Shared Memory
>> #define PAGE_SIZE (4*1024)
>>
>> fd = open(device, O_RDWR);
>
> You may need to add with 'O_SYNC'.
>
> Tiejun
>
>> shm = malloc(SHM_SIZE + (PAGE_SIZE - 1)); if ( (unsigned long) shm %
>> PAGE_SIZE) {
>> shm += PAGE_SIZE - ((unsigned long)shm % PAGE_SIZE); }
>>
>> shm = mmap(shm, SHM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED |
>> MAP_FIXED, fd, SHM_BASE); ......
>> ...... write some string at shm.
>>
>> My memory partitioning for both systems is
>>
>> Core Base Address Size
>> Core 0 0x0000,0000 0x1000,0000
>> Core 1 0x1000,0000 0x0C00,0000
>> Shared Memory 0x1C00,0000 0x0400,0000
>>
>> Regards,
>> Farrukh Arshad.
>> Mentor Graphics Pakistan
>
^ permalink raw reply
* Re: RTC on 2.6.36 for PowerMac 8600
From: Andreas Schwab @ 2012-01-29 8:29 UTC (permalink / raw)
To: kevin diggs; +Cc: Linux PPC Development
In-Reply-To: <CAKTLLVQTt8aRFb2QpXkUUikTJshnV_ytTWJ778MZ1ACyoD8aOw__43210.997261531$1327806577$gmane$org@mail.gmail.com>
kevin diggs <diggskevin38@gmail.com> writes:
> [root@PowerMac8600B root]# hwclock --debug
> hwclock from util-linux-2.12pre
> Using /dev/rtc interface to clock.
> Last drift adjustment done at 1317444443 seconds after 1969
> Last calibration done at 1317444443 seconds after 1969
> Hardware clock is on local time
> Assuming hardware clock is kept in local time.
> Waiting for clock tick...
> /dev/rtc does not have interrupt functions. Waiting in loop for time
> from /dev/rtc to change
> RTC_RD_TIME: Invalid argument
Perhaps the RTC was reset due to battery running out? That would set
the year to 1900, but the kernel RTC interface cannot represent dates
before 1970. Unfortunately hwclock insists on reading the RTC even when
you just want to write to it, so you cannot fix that with hwclock -w.
When the battery of my iBook has run out I'm using the following to
reset RTC to current time so that it is usable again.
Andreas.
#include <time.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/rtc.h>
int
main (void)
{
time_t now;
struct tm gmt;
struct rtc_time rtc;
int fd;
now = time (0);
gmt = *gmtime (&now);
rtc.tm_sec = gmt.tm_sec;
rtc.tm_min = gmt.tm_min;
rtc.tm_hour = gmt.tm_hour;
rtc.tm_mday = gmt.tm_mday;
rtc.tm_mon = gmt.tm_mon;
rtc.tm_year = gmt.tm_year;
rtc.tm_wday = gmt.tm_wday;
rtc.tm_yday = gmt.tm_yday;
rtc.tm_isdst = gmt.tm_isdst;
fd = open ("/dev/rtc", O_RDONLY);
if (fd < 0)
fd = open ("/dev/rtc0", O_RDONLY);
if (fd < 0)
{
perror ("/dev/rtc");
return 1;
}
if (ioctl (fd, RTC_SET_TIME, &rtc) < 0)
{
perror ("RTC_SET_TIME");
return 1;
}
return 0;
}
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2012-01-29 22:45 UTC (permalink / raw)
To: Kevin Cernekee
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64, linux-sh,
linux, linux-pci, Jesse Barnes, Chen Liqin, Paul Mackerras,
H. Peter Anvin, sparclinux, Guan Xuetao, Lennox Wu, Jonas Bonn,
Jesper Nilsson, Russell King, linux-hexagon, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven, linux-arch,
Arend van Spriel, Matt Turner, Fenghua Yu, Lasse Collin,
Arnd Bergmann, Lucas De Marchi, microblaze-uclinux, Paul Bolle,
Rob Herring, Mikael Starvik, Ivan Kokshaysky, Franky Lin,
Thomas Gleixner, Fabio Baltieri, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Michal Simek, Tony Luck,
linux-parisc, linux-cris-kernel, Paul Gortmaker, linux-kernel,
Ralf Baechle, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <CAJiQ=7BPzhWWzU3_nDv3j=ZB4f=iOzeyLyd2L0_3UFaMiLujpw@mail.gmail.com>
On Sat, Jan 28, 2012 at 02:38:10PM -0800, Kevin Cernekee wrote:
> On Thu, Nov 24, 2011 at 12:18 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > mips copied pci_iomap from generic code, probably to avoid
> > pulling the rest of iomap.c in. Since that's in
> > a separate file now, we can reuse the common implementation.
>
> [snip]
>
> > - if (flags & IORESOURCE_IO)
> > - return ioport_map_pci(dev, start, len);
>
> While investigating a new warning on the 3.3-rc1 MIPS build (unused
> static function ioport_map_pci()), I noticed that this patch has shown
> up in Linus' tree as commit eab90291d35438bcebf7c3dc85be66d0f24e3002.
>
> I am not completely clear on the implications it has on mapping PCI I/O regions:
Yes, my bad, I missed the difference between ioport_map_pci
and ioport_map for both MIPS and SH.
I'll post a patch to fix this, which is probably preferable
to reintroducing the code duplication where it might
trip us up again.
--
MST
^ permalink raw reply
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Florian Tobias Schandinat @ 2012-01-30 5:14 UTC (permalink / raw)
To: Michael Neuling
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
Tabi Timur-B04825
In-Reply-To: <21370.1326683320@neuling.org>
On 01/16/2012 03:08 AM, Michael Neuling wrote:
[...]
> From: Michael Neuling <mikey@neuling.org>
>
> [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
>
> Fix a compiler errors introduced in:
> commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
> Author: Timur Tabi <timur@freescale.com>
> drivers/video: fsl-diu-fb: merge all allocated data into one block
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Applied.
Thanks,
Florian Tobias Schandinat
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index acf292b..6af3f16 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -1432,7 +1432,7 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
> struct fsl_diu_data *data;
>
> data = dev_get_drvdata(&ofdev->dev);
> - disable_lcdc(data->fsl_diu_info[0]);
> + disable_lcdc(data->fsl_diu_info);
>
> return 0;
> }
> @@ -1442,7 +1442,7 @@ static int fsl_diu_resume(struct platform_device *ofdev)
> struct fsl_diu_data *data;
>
> data = dev_get_drvdata(&ofdev->dev);
> - enable_lcdc(data->fsl_diu_info[0]);
> + enable_lcdc(data->fsl_diu_info);
>
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
From: fanzc @ 2012-01-30 5:40 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: McClintock Matthew-B29882, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVw2zPb-arZ_JbanwAk0eguezxzZ301fBXG_JoFgcPLWQ@mail.gmail.com>
On 01/26/2012 04:55 AM, Tabi Timur-B04825 wrote:
> On Thu, Jan 19, 2012 at 11:00 PM, Zhicheng Fan<B32736@freescale.com> wrote:
>
>> Signed-off-by: Fanzc<b32736@freeescale.com>
> Please fix this. There are only two e's in freescale. In addition,
> please use your full name.
>
Hi Timur,
You mean that need to remove the define to other file or create
new file?
Zhicheng Fan
^ permalink raw reply
* Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Vinod Koul @ 2012-01-30 9:30 UTC (permalink / raw)
To: Alexandre Bounine
Cc: linux-kernel, Jassi Brar, akpm, linuxppc-dev, dan.j.williams,
Russell King
In-Reply-To: <1327612946-29397-1-git-send-email-alexandre.bounine@idt.com>
On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote:
> As we agreed during our discussion about adding DMA Engine support for RapidIO
> subsystem, RapidIO and similar clients may benefit from adding an extra context
> parameter to device_prep_slave_sg() callback.
> See https://lkml.org/lkml/2011/10/24/275 for more details.
>
> Adding the context parameter will allow to pass client/target specific
> information associated with an individual data transfer request.
>
> In the case of RapidIO support this additional information consists of target
> destination ID and its buffer address (which is not mapped into the local CPU
> memory space). Because a single RapidIO-capable DMA channel may queue data
> transfer requests to different target devices, the per-request configuration
> is required.
>
> The proposed change eliminates need for new subsystem-specific API.
> Existing DMA_SLAVE clients will ignore the new parameter.
>
> This RFC only demonstrates the API change and does not include corresponding
> changes to existing DMA_SLAVE clients. Complete set of patches will be provided
> after (if) this API change is accepted.
This looks good to me. But was thinking if we need to add this new
parameter for other slave calls (circular, interleaved, memcpy...)
>
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> Cc: Jassi Brar <jaswinder.singh@linaro.org>
> Cc: Russell King <rmk@arm.linux.org.uk>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Matt Porter <mporter@kernel.crashing.org>
> Cc: Li Yang <leoli@freescale.com>
> ---
> include/linux/dmaengine.h | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 679b349..79d71bb 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -575,7 +575,7 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> - unsigned long flags);
> + unsigned long flags, void *context);
> struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
> struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
> size_t period_len, enum dma_transfer_direction direction);
> @@ -607,12 +607,13 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,
>
> static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
> struct dma_chan *chan, void *buf, size_t len,
> - enum dma_transfer_direction dir, unsigned long flags)
> + enum dma_transfer_direction dir, unsigned long flags, void *context)
> {
> struct scatterlist sg;
> sg_init_one(&sg, buf, len);
>
> - return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags);
> + return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags,
> + context);
> }
>
> static inline int dmaengine_terminate_all(struct dma_chan *chan)
--
~Vinod
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
From: Tabi Timur-B04825 @ 2012-01-30 12:32 UTC (permalink / raw)
To: Fan Zhicheng-B32736
Cc: McClintock Matthew-B29882, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F262D4D.8070306@freescale.com>
fanzc wrote:
>>
>>> Signed-off-by: Fanzc<b32736@freeescale.com>
>> Please fix this. There are only two e's in freescale. In addition,
>> please use your full name.
>>
> Hi Timur,
>
> You mean that need to remove the define to other file or create ne=
w
> file?
No, I mean you're signed-off-by should be this:
Signed-off-by: Zhicheng Fan <b32736@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 06/13] PCI, powerpc: Register busn_res for root buses
From: Bjorn Helgaas @ 2012-01-30 15:44 UTC (permalink / raw)
To: Yinghai Lu
Cc: linux-arch, Tony Luck, linuxppc-dev, linux-kernel, Jesse Barnes,
Paul Mackerras, linux-pci, Linus Torvalds
In-Reply-To: <1327718971-9598-7-git-send-email-yinghai@kernel.org>
On Fri, Jan 27, 2012 at 6:49 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> =A0arch/powerpc/kernel/pci-common.c | =A0 =A07 ++++++-
> =A01 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-c=
ommon.c
> index cce98d7..501f29b 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1732,6 +1732,8 @@ void __devinit pcibios_scan_phb(struct pci_controll=
er *hose)
> =A0 =A0 =A0 =A0bus->secondary =3D hose->first_busno;
> =A0 =A0 =A0 =A0hose->bus =3D bus;
>
> + =A0 =A0 =A0 pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_=
busno);
The pci_create_root_bus() call is a few lines above this. So this is
a case of "create the root bus" followed by "fix something that's
wrong with the bus we just created." I'm trying to get rid of that
pattern because it's just an opportunity for bugs. I'd rather create
the root bus with all the information it needs up front.
And pci_bus_insert_busn_res() is not really architecture-specific, so
I'd like this better if that call were done in the PCI core somewhere.
> =A0 =A0 =A0 =A0/* Get probe mode and perform scan */
> =A0 =A0 =A0 =A0mode =3D PCI_PROBE_NORMAL;
> =A0 =A0 =A0 =A0if (node && ppc_md.pci_probe_mode)
> @@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_control=
ler *hose)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of_scan_bus(node, bus);
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 if (mode =3D=3D PCI_PROBE_NORMAL)
> + =A0 =A0 =A0 if (mode =3D=3D PCI_PROBE_NORMAL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pci_bus_update_busn_res_end(bus, 255);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hose->last_busno =3D bus->subordinate =3D =
pci_scan_child_bus(bus);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pci_bus_update_busn_res_end(bus, bus->subor=
dinate);
> + =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0/* Platform gets a chance to do some global fixups before
> =A0 =A0 =A0 =A0 * we proceed to resource allocation
> --
> 1.7.7
>
^ permalink raw reply
* RE: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Bounine, Alexandre @ 2012-01-30 16:55 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-kernel, Jassi Brar, akpm, linuxppc-dev, dan.j.williams,
Russell King
In-Reply-To: <1327915849.1527.17.camel@vkoul-udesk3>
T24gTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDEyIGF0IDQ6MzEgQU0sIFZpbm9kIEtvdWwgd3JvdGU6
DQo+IA0KPiBPbiBUaHUsIDIwMTItMDEtMjYgYXQgMTY6MjIgLTA1MDAsIEFsZXhhbmRyZSBCb3Vu
aW5lIHdyb3RlOg0KPiA+IEFzIHdlIGFncmVlZCBkdXJpbmcgb3VyIGRpc2N1c3Npb24gYWJvdXQg
YWRkaW5nIERNQSBFbmdpbmUgc3VwcG9ydCBmb3IgUmFwaWRJTw0KPiA+IHN1YnN5c3RlbSwgUmFw
aWRJTyBhbmQgc2ltaWxhciBjbGllbnRzIG1heSBiZW5lZml0IGZyb20gYWRkaW5nIGFuIGV4dHJh
IGNvbnRleHQNCj4gPiBwYXJhbWV0ZXIgdG8gZGV2aWNlX3ByZXBfc2xhdmVfc2coKSBjYWxsYmFj
ay4NCj4gPiBTZWUgaHR0cHM6Ly9sa21sLm9yZy9sa21sLzIwMTEvMTAvMjQvMjc1IGZvciBtb3Jl
IGRldGFpbHMuDQo+ID4NCj4gPiBBZGRpbmcgdGhlIGNvbnRleHQgcGFyYW1ldGVyIHdpbGwgYWxs
b3cgdG8gcGFzcyBjbGllbnQvdGFyZ2V0IHNwZWNpZmljDQo+ID4gaW5mb3JtYXRpb24gYXNzb2Np
YXRlZCB3aXRoIGFuIGluZGl2aWR1YWwgZGF0YSB0cmFuc2ZlciByZXF1ZXN0Lg0KPiA+DQo+ID4g
SW4gdGhlIGNhc2Ugb2YgUmFwaWRJTyBzdXBwb3J0IHRoaXMgYWRkaXRpb25hbCBpbmZvcm1hdGlv
biBjb25zaXN0cyBvZiB0YXJnZXQNCj4gPiBkZXN0aW5hdGlvbiBJRCBhbmQgaXRzIGJ1ZmZlciBh
ZGRyZXNzICh3aGljaCBpcyBub3QgbWFwcGVkIGludG8gdGhlIGxvY2FsIENQVQ0KPiA+IG1lbW9y
eSBzcGFjZSkuIEJlY2F1c2UgYSBzaW5nbGUgUmFwaWRJTy1jYXBhYmxlIERNQSBjaGFubmVsIG1h
eSBxdWV1ZSBkYXRhDQo+ID4gdHJhbnNmZXIgcmVxdWVzdHMgdG8gZGlmZmVyZW50IHRhcmdldCBk
ZXZpY2VzLCB0aGUgcGVyLXJlcXVlc3QgY29uZmlndXJhdGlvbg0KPiA+IGlzIHJlcXVpcmVkLg0K
PiA+DQo+ID4gVGhlIHByb3Bvc2VkIGNoYW5nZSBlbGltaW5hdGVzIG5lZWQgZm9yIG5ldyBzdWJz
eXN0ZW0tc3BlY2lmaWMgQVBJLg0KPiA+IEV4aXN0aW5nIERNQV9TTEFWRSBjbGllbnRzIHdpbGwg
aWdub3JlIHRoZSBuZXcgcGFyYW1ldGVyLg0KPiA+DQo+ID4gVGhpcyBSRkMgb25seSBkZW1vbnN0
cmF0ZXMgdGhlIEFQSSBjaGFuZ2UgYW5kIGRvZXMgbm90IGluY2x1ZGUgY29ycmVzcG9uZGluZw0K
PiA+IGNoYW5nZXMgdG8gZXhpc3RpbmcgRE1BX1NMQVZFIGNsaWVudHMuIENvbXBsZXRlIHNldCBv
ZiBwYXRjaGVzIHdpbGwgYmUgcHJvdmlkZWQNCj4gPiBhZnRlciAoaWYpIHRoaXMgQVBJIGNoYW5n
ZSBpcyBhY2NlcHRlZC4NCj4NCj4gVGhpcyBsb29rcyBnb29kIHRvIG1lLiBCdXQgd2FzIHRoaW5r
aW5nIGlmIHdlIG5lZWQgdG8gYWRkIHRoaXMgbmV3DQo+IHBhcmFtZXRlciBmb3Igb3RoZXIgc2xh
dmUgY2FsbHMgKGNpcmN1bGFyLCBpbnRlcmxlYXZlZCwgbWVtY3B5Li4uKQ0KPiANCg0KSSBhZ3Jl
ZSB0aGF0IGN5Y2xpYyBhbmQgaW50ZXJsZWF2ZWQgY2FsbHMgbWF5IGJlbmVmaXQgZnJvbSBhZGRp
bmcgdGhhdCBwYXJhbWV0ZXIgYXMgd2VsbC4NCkJlbmVmaXRzIHRvIHRoZSBjeWNsaWMgY2FsbCBh
cmUgc3RyYWlnaHRmb3J3YXJkIC0gc2FtZSBhcyBkbWFfc2xhdmUuDQpBZGRpbmcgYSBjb250ZXh0
IHBhcmFtZXRlciB0byB0aGUgaW50ZXJsZWF2ZWQgdHJhbnNmZXJzIG1heSBiZSBtb3JlIGZ1dHVy
ZSBwcm9vZmluZyBvcHRpb24NCnRoYW4gYW4gaW1tZWRpYXRlIG5lZWQuIE1lbWNvcHkgYW5kIG90
aGVyIGNhbGxzIHRoYXQgZGVhbCB3aXRoIGxvY2FsIG1lbW9yeSB0cmFuc2ZlcnMNCnByb2JhYmx5
IHNob3VsZCBiZSBsZWZ0IHVudG91Y2hlZC4NCg0KV2hhdCBpZiB3ZSBsaW1pdCBtb2RpZmljYXRp
b25zIHRvOg0KMSkgdGhyZWUgY2FsbHMgKHNsYXZlLCBjeWNsaWMgYW5kIGludGVybGVhdmVkKSBP
Ug0KMikgdHdvIChzbGF2ZSBhbmQgY3ljbGljKSBhdCB0aGlzIG1vbWVudD8NCg0KSSBhbSBqdXN0
IG1vcmUgZm9jdXNlZCBvbiBkbWFfc2xhdmUganVzdCBiZWNhdXNlIGl0IGZpdHMgd2VsbCB0byBw
cm92aWRlIFJETUENCm92ZXIgUmFwaWRJTyBmYWJyaWMuDQoNCklmIGV2ZXJ5Ym9keSBhZ3JlZXMs
IEkgY2FuIGdvIGFoZWFkIGFuZCBtYWtlIGNoYW5nZXMgdG8gYWxsIHRocmVlIGF0IG9uY2UuDQoN
CkFsZXguDQoNCg0K
^ permalink raw reply
* Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
From: Grant Likely @ 2012-01-30 19:58 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120128164405.GA20763@linutronix.de>
On Sat, Jan 28, 2012 at 05:44:05PM +0100, Sebastian Andrzej Siewior wrote:
> * Grant Likely | 2012-01-27 14:36:16 [-0700]:
>
> >This patch removes the x86-specific definition of irq_domain and replaces
> >it with the common implementation.
>
> I pulled your devicetree/next tree. After this patch I get:
>
> |Hierarchical RCU implementation.
> |NR_IRQS:2304 nr_irqs:256 16
> |------------[ cut here ]------------
> |WARNING: at /home/bigeasy/work/shiva/git/linux-2.6-tip/kernel/irq/irqdomain.c:114 irq_domain_add_legacy+0x75/0x150()
> |Modules linked in:
> |Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1+ #65
> |Call Trace:
> | [<c15044e0>] ? printk+0x18/0x1a
> | [<c102cdbd>] warn_slowpath_common+0x6d/0xa0
> | [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
> | [<c1095575>] ? irq_domain_add_legacy+0x75/0x150
> | [<c102ce0d>] warn_slowpath_null+0x1d/0x20
> | [<c1095575>] irq_domain_add_legacy+0x75/0x150
> | [<c1714824>] x86_add_irq_domains+0x96/0xd6
> | [<c1708df2>] init_IRQ+0x8/0x33
> | [<c170557f>] start_kernel+0x191/0x2e1
> | [<c170517f>] ? loglevel+0x2b/0x2b
> | [<c1705081>] i386_start_kernel+0x81/0x86
> |---[ end trace 4eaa2a86a8e2da22 ]---
> |------------[ cut here ]------------
> |kernel BUG at /home/bigeasy/work/shiva/git/linux-2.6-tip/arch/x86/kernel/devicetree.c:367!
>
> The warning is comming from this piece in irq_domain_add_legacy()
> |for (i = 0; i < size; i++) {
> | int irq = first_irq + i;
> | struct irq_data *irq_data = irq_get_irq_data(irq);
> |
> | if (WARN_ON(!irq_data || irq_data->domain)) {
>
> irq_data is NULL here.
>
> | mutex_unlock(&irq_domain_mutex);
> | of_node_put(domain->of_node);
> | kfree(domain);
> | return NULL;
> | }
> | }
> |
>
> This is not always the case. arch_early_irq_init() in [0] sets up the
> first 16 entries. The reminaing few (there is a toal of 24 irqs for
> first ioapic and a second ioapic) are not initialized. This happens
> later via ->xlate, ioapic_xlate() => io_apic_setup_irq_pin() =>
> alloc_irq_and_cfg_at() calls irq_set_chip_data() on demand.
>
> [0] arch/x86/kernel/apic/io_apic.c
Ugh. This isn't easy. The legacy mapping really needs all the
irq_desc structures to be allocated. You could call irq_alloc_descs()
before calling irq_domain_add_legacy(), but that causes all the
irq_descs to be allocated (regardless of whether they are used), and
it will break io_apic_setup_irq_pin() which also wants to call
irq_alloc_desc().
Ideally irq_domain support would be rolled directly into ioapic.
That's more work though, and a greater change of breaking x86 on
non-embedded. Looking at the ioapic code, it seems to me that it
could be simplified quite a bit by switching to irq_domain instead of
using the custom irq_cfg linked list. Faster too since it could use
the irq_data->hwirq to go from linux irq to the hw irq number. It
doesn't look like it would be even that hard, but of course the devil
is in the details and I don't have sufficient time right now to dig
into the guts of the ioapic. Maybe after connect, but it would help
if you can find time to look at it.
If integrated into the ioapic code, then the irq_domain linear map is
probably the type of irq_domain to use.
g.
^ permalink raw reply
* [RFC] powerpc: Make SPARSE_IRQ required
From: Grant Likely @ 2012-01-30 18:02 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev; +Cc: Thomas Gleixner, Rob Herring
All IRQs on powerpc are managed via irq_domain anyway, there isn't really
any advantage to turning SPARSE_IRQ off, and it's the direction we want
to take the kernel design anyway. This patch makes powerpc always use
SPARSE_IRQ.
On pseries_defconfig, SPARSE_IRQ adds only about 0x300 bytes to the
.text sections, and removes about 0x20000 from the data section for the
static irq_desc table.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/kernel/irq.c | 4 ----
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 303703d..1aa840d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -133,7 +133,7 @@ config PPC
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
+ select SPARSE_IRQ
select IRQ_PER_CPU
select IRQ_DOMAIN
select GENERIC_IRQ_SHOW
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index e3673ff..282fb39 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -93,10 +93,6 @@ extern int tau_interrupts(int);
#ifdef CONFIG_PPC64
-#ifndef CONFIG_SPARSE_IRQ
-EXPORT_SYMBOL(irq_desc);
-#endif
-
int distribute_irqs = 1;
static inline notrace unsigned long get_hard_enabled(void)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] powerpc/booke64: Configurable lazy interrupt disabling
From: Scott Wood @ 2012-01-30 21:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Laurentiu Tudor, linuxppc-dev, Stuart Yoder
In-Reply-To: <1327351831.19850.9.camel@pasglop>
On 01/23/2012 02:50 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-01-23 at 13:21 -0600, Scott Wood wrote:
>> Perhaps the issues with a higher priority interrupt intervening can be
>> addressed by messing around with current task priority at the MPIC (with
>> an hcall introduced for the hv case, since currently task priority is
>> not exposed to the guest). I haven't had time to revisit this, and
>> don't expect to soon. If someone else wants to try, fine. In the
>> meantime, lazy EE is causing problems.
>
> Or by storing pending interrupts in an array.
Only the first one will happen in a context where we want to store. The
issue is if we get another higher priority interrupt when we enable, and
that enables interrupts and we get the doorbell that wants to run the
saved irq. If we get priorities out of order we'll EOI the wrong interrupt.
IIRC we now never enable interrupts while servicing one (are individual
handlers banned from doing this too?), in which case it shouldn't be an
issue. I'm a bit hesitant to rely on that, but oh well. Beats having
to add CTPR support to the hypervisor just for this. We could throw a
WARN_ONCE if we see a stored interrupt when we take an external
interrupt exception.
>> and book3s decrementers
>
> Book3s decrementer is level sensitive based on the sign bit of the
> decrementer (a bit odd but heh....) at least on 64-bit processors.
So what's up with "On server, re-trigger the decrementer if it went
negative since some processors only trigger on edge transitions of the
sign bit" in arch_local_irq_restore()?
>> and other hypervisors...
>
> I wouldn't take the PS3 HV and legacy iseries HV as good design
> examples :-) The later was working around limited HW functionality at
> the time as well.
Just pointing out we're not the first. :-)
>> and you force
>> all functions that enable interrupts to create a stack frame to deal
>> with this.
>
> Right, but overall this is still more efficient performance wise on most
> processors than whacking the MSR.
Laurentiu ran lmbench on e5500 with/without lazy EE and the results were
mixed. No large differences either way, but probably at least as many
tests were slower with lazy EE as were faster with lazy EE. Or possibly
there was no significant difference and it was just noise from one run
to another (I'm not sure how many times he ran it or what the variation
was).
He did claim a noticeable increase in networking performance with
external proxy enabled.
I guess hard-EE is worse on some other chips?
> However the main thing is that this significantly improves the quality
> of the samples obtained from performance interrupts which can now act as
> pseudo-NMI up to a certain point.
Which is compensation for the hardware not doing it right with a proper
critical interrupt or equivalent, but yeah, that's a benefit.
>> What is the compelling reason for forcing lazy EE on us? Why is it tied
>> to 64-bit?
>
> Because that's where we historically implemented it and because iSeries
> more/less required to begin with. And I don't want to have a split
> scheme, especially not a compile time one.
We can probably live with it in this case -- the patch to disable lazy
EE was largely an artifact of my not having time to try a new approach,
and other people here wanting some fix sooner.
In general, though, I hope that the history of previously having 64-bit
to yourself doesn't mean that our 64-bit chips are treated second class
citizens, having to live with design decisions oriented around the chips
that got there first, with a mandate that there be no special kernel
builds, even just for optimization[1]. No, I don't want to go back to
one kernel per board, but some build-time configuration is reasonable on
embedded IMHO, as long as the possibilities are limited. We're already
running a different build from book3s.
If the issue is just that you think making this particular feature
configurable would be a mess, fine (though I think it would have been
managable).
-Scott
[1] The hypervisor's issues with guest IACK should be fixable with an
hv-internal CTPR hack if anyone cares enough, but there would be a
performance cost to not using external proxy.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox