Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
* 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 01/25] irq_domain: add documentation and MAINTAINERS entry.
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-embeddedm=132742951211808w=2 Signed-off-by: Grant Likely grant.lik...@secretlab.ca Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Thomas Gleixner t...@linutronix.de Cc: Rob Herring rob.herr...@calxeda.com Cc: Milton Miller milt...@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 *** ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/25] irq_domain generalization and refinement
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
Re: [RFCv2 01/14] irq_domain: add documentation and MAINTAINERS entry.
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.lik...@secretlab.ca Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Thomas Gleixner t...@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 000..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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 22/25] irq_domain/x86: Convert x86 (embedded) to use common irq_domain
On Sat, Jan 28, 2012 at 5:35 PM, Grant Likely grant.lik...@secretlab.ca wrote:
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
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RTC on 2.6.36 for PowerMac 8600
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 131743 seconds after 1969 Last calibration done at 131743 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem in getting shared memory access on P1022RDK
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.c...@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_BASE0x1C00
#define SHM_SIZE0x40// 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 AddressSize
Core 0 0x, 0x1000,
Core 1 0x1000, 0x0C00,
Shared Memory0x1C00, 0x0400,
Regards,
Farrukh Arshad.
Mentor Graphics Pakistan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
