* Re: advice on reading a call trace
From: Benjamin Herrenschmidt @ 2010-10-08 1:29 UTC (permalink / raw)
To: Jean-Mickael Guerin; +Cc: linuxppc-dev
In-Reply-To: <4CAAB5F4.9030002@6wind.com>
On Tue, 2010-10-05 at 07:21 +0200, Jean-Mickael Guerin wrote:
> SLUB is turned on, and the oops does not seem to happen when SLAB replaces SLUB.
> I just got lucky with SLAB, or does it sound familiar on ppc?
Nope, they should both work fine. Try enabling SLAB_DEBUG or SLUB_DEBUG
maybe ? You might be having some memory corruption (bad driver ?)
Cheers,
Ben.
> Regards,
> Jean-Mickael
>
> On 10/4/2010 1:24 PM, Jean-Mickael Guerin wrote:
> > Hello,
> > I'm stepping into ppc world and I'd like to know how to read this call trace,
> > I enabled debug options but I'm not able to track the origin of this bug, I mean
> > what happens before handle_page_fault():
> >
> > Unable to handle kernel paging request for data at address 0x00000008
> > Faulting instruction address: 0xc00abcd8
> >
> > [c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
> > [c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
> > [c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
> > [c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
> > Instruction dump:
> > 80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
> > 387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
> > Kernel panic - not syncing: Fatal exception
> >
> > Another one:
> > NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
> > REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
> > MSR: 10029002 CR: 24004442 XER: 00000000
> > DEAR: 00000008, ESR: 00000000
> > TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
> > GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
> > GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
> > GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
> > GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
> > NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
> > LR [c00b6978] valid_swaphandles+0x194/0x1d0
> > Call Trace:
> > [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
> > [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> > [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> > [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> > [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> > Instruction dump:
> > 38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
> > 7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
> > Kernel panic - not syncing: Fatal exception
> > Call Trace:
> > [d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
> > [d6a9dbd0] [c053b780] panic+0x94/0x118
> > [d6a9dc20] [c000d630] die+0x15c/0x1bc
> > [d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
> > [d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
> > [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
> > [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> > [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> > [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> > [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> > Rebooting in 5 seconds..
> >
> > Thanks,
> > Jean-Mickael
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: advice on reading a call trace
From: Benjamin Herrenschmidt @ 2010-10-08 1:28 UTC (permalink / raw)
To: Jean-Mickael Guerin; +Cc: linuxppc-dev
In-Reply-To: <4CA9B967.9060907@6wind.com>
On Mon, 2010-10-04 at 13:24 +0200, Jean-Mickael Guerin wrote:
> Hello,
> I'm stepping into ppc world and I'd like to know how to read this call trace,
> I enabled debug options but I'm not able to track the origin of this bug, I mean
> what happens before handle_page_fault():
>
> Unable to handle kernel paging request for data at address 0x00000008
That's a NULL dereference
> Faulting instruction address: 0xc00abcd8
>
> [c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
> [c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
> [c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
> [c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
I suspect it's userspace before handle_page_fault(). It died with a NULL
deref in the swap code (which is strange... which kernel is this ? Do
you have out of tree patches applied ?)
Cheers,
Ben.
> Instruction dump:
> 80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
> 387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
> Kernel panic - not syncing: Fatal exception
>
> Another one:
> NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
> REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
> MSR: 10029002 CR: 24004442 XER: 00000000
> DEAR: 00000008, ESR: 00000000
> TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
> GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
> GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
> GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
> GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
> NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
> LR [c00b6978] valid_swaphandles+0x194/0x1d0
> Call Trace:
> [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
> [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> Instruction dump:
> 38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
> 7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
> Kernel panic - not syncing: Fatal exception
> Call Trace:
> [d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
> [d6a9dbd0] [c053b780] panic+0x94/0x118
> [d6a9dc20] [c000d630] die+0x15c/0x1bc
> [d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
> [d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
> [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
> [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> Rebooting in 5 seconds..
>
> Thanks,
> Jean-Mickael
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MSI-X vector allocation failure in upstream kernel
From: Benjamin Herrenschmidt @ 2010-10-08 1:26 UTC (permalink / raw)
To: Anirban Chakraborty; +Cc: linuxppc-dev, Michael Ellerman, Ameen Rahman
In-Reply-To: <9101728E-3FFC-457E-AF5B-87B2037FEC32@qlogic.com>
On Tue, 2010-10-05 at 10:18 -0700, Anirban Chakraborty wrote:
> Hi All,
>
> I am trying to test qlcnic driver (for 10Gb QLogic network adapter) on a Power 6 system
> (IBM P 520, System type 8203) with upstream kernel and I do see that the kernel is
> not able to allocate any MSI-X vectors. The driver requests for 4 vectors in pci_enable_msix,
> which returns 2. The driver again attempts, this time for 2 vectors but the kernel can't allocate
> and it returns a value of 0xfffffffd. I upgraded the system FW to 01EL350 (from 01EL340)
> just to make sure if MSI-X is enabled in the system. Is there anything that I am missing?
>
> Any pointers will be highly appreciated.
I think the people who can help you at the moment are on vacation :-)
Can you make sure kernel debug is enabled and you have "debug" on the
kernel command line, and send the full dmesg log of what's going on ?
Hopefully, Michael will be back next week and will be able to have a
look at it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: Michal Simek, Greg Kroah-Hartman, devicetree-discuss,
Sean MacLennan, linux-kernel, Stefan Weil, paulus, Jiri Kosina,
linuxppc-dev, David S. Miller
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-10-07 22:10 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, Rina Kagan, linuxppc-dev, Mark Miesfeld,
Ted Chan, Fushen Chen
In-Reply-To: <AANLkTinzG_g2--E5SwzEK6qK8NR+ewWJJU0UXsoWveP6@mail.gmail.com>
On Thu, Oct 07, 2010 at 03:01:33PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We have obtained GPL 2 only header from Synopsis. We have also identified all
> parties that contributed to the code base and contacted them regarding
> license change.
> Any party that we could not reach, we will remove the patch from the submission.
> Let me know if this is sufficient for resubmission.
Yes, that sounds fine, thanks for doing that work.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-10-07 22:01 UTC (permalink / raw)
To: Greg KH, Rina Kagan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730033632.GB27275@suse.de>
Hi Greg:
We have obtained GPL 2 only header from Synopsis. We have also identified a=
ll
parties that contributed to the code base and contacted them regarding
license change.
Any party that we could not reach, we will remove the patch from the submis=
sion.
Let me know if this is sufficient for resubmission.
Thanks
Feng
On Thu, Jul 29, 2010 at 8:36 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
>> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> >> Hi Greg:
>> >> >>
>> >> >> We will change to a BSD 3 clause license header. Our legal counsel=
is
>> >> >> talking to Synopsis to make this change.
>> >> >
>> >> > Why BSD? ??You do realize what that means when combined within the =
body
>> >> > of the kernel, right?
>> >> >
>> >>
>> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the=
HP
>> >> ?? ?? ?? ?? ?? ??Hil driver.
>> >
>> > What specific driver is this?
>>
>> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> Ok, thanks.
>
> Are you _sure_ that you didn't take any existing GPL code and put it
> into this driver when making it? =C2=A0Did all contributors to the code
> release their contributions under both licenses?
>
>> > And are you sure that all of the contributors to the code agree with
>> > this licensing change? ??Are you going to require contributors to
>> > dual-license their changes?
>> >
>> > If so, why keep it BSD, what does that get you?
>>
>> FKAN: for one thing, to make it future proof on other submissions.
>
> What do you mean by this? =C2=A0What can you do with this code other than=
use
> it on a Linux system? =C2=A0You can't put it into any other operating sys=
tem
> with a different license, can you?
>
>> >> > Are you going to be expecting others to contribute back to the code
>> >> > under this license, or will you accept the fact that future
>> >> > contributions from the community will cause the license to change?
>> >
>> >
>> > You didn't answer this question, which is a very important one before =
I
>> > can accept this driver.
>>
>> FKAN: Yes, all of the above. Our legal is working on that. I thought by =
default
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPL defines the above statement=
.
>
> The GPL does, but as you are trying to dual-license the code, you have
> to be careful about how you accept changes, and under what license.
> It's a lot more work than I think you realize. =C2=A0What process do you =
have
> in place to handle this?
>
>> >> >> We will resubmit once this is in place. Please let me know if you =
have
>> >> >> any additional concerns.
>> >> >
>> >> > My main concern is that you, and everyone else involved in the driv=
er,
>> >> > never considered the license of the code in the first place and exp=
ected
>> >> > the kernel community to accept it as-is, placing the problem on us.
>> >>
>> >> FKAN: Please don't think this is the case, we gone through this exerc=
ise
>> >> ?? ?? ?? ?? ?? with Denx.
>> >
>> > What is "Denx"?
>>
>> FKAN: U-Boot Denx.de
>
> Ah, thanks.
>
>> >> We had legal looking into the header before submission
>> >> ?? ?? ?? ?? ?? to them and the kernel.
>> >
>> > Then what happened here? ??Just curious as to how the driver was publi=
c
>> > for so long before someone realized this.
>> >
>>
>> FKAN: =C2=A0this was few years back. At the time we had the header chang=
ed
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0so it was BSD like to be accept=
ed by Denx.
>>
>> >> > What will be done in the future to prevent this from happening agai=
n?
>> >>
>> >> FKAN: agreed, once bitten .... :)
>> >
>> > That didn't answer the question :)
>>
>> FKAN: we have a system of checks for every patch that goes out. I will s=
end
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out a guideline to all reviewer=
to make sure the header
>> follow kernel precedence.
>
> But you took this code from a different vendor, are you able to properly
> identify the code contributions to this base and what license it is
> under and where they got it from?
>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Legal is quite aware of the iss=
ue now too.
>
> As they should be :)
>
> Please reconsider the dual licensing unless you really are ready to
> handle the implications of it.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-07 21:01 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101007152626.4e834d43@udp111988uds.am.freescale.net>
> On Thu, 7 Oct 2010 15:12:26 -0500.
>
> BTW, the MSIs are already described in an msi node in the device tree.
As far as I can tell, ONLY in root complex mode, not in endpoint mode,
which is what I am working with.
What I want is a means by which the system root complex can generate one
or more interrupts INTO the 8641 when it is operating in endpoint mode.
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-07 20:26 UTC (permalink / raw)
To: david.hagood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fe4c3e4086132d746b79670f236302f1.squirrel@localhost>
On Thu, 7 Oct 2010 15:12:26 -0500
<david.hagood@gmail.com> wrote:
> > On Tue, 21 Sep 2010 17:37:15 -0400
> > The MPIC interrupt numberspace in the device tree (which is not
> > virtual; it is a private numberspace to MPIC) is based on the offset of
> > the registers for that interrupt source. External interrupts start at
> > zero (which is valid), internal at 16, and special things like MSIs at
> > higher numbers (I don't think it's quite 256).
>
> OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
> sending this information to the folks doing the Linux Device Drivers
> books? They are just a bit x86 centric right now...).
>
> As I understand, what I have to do is somehow get a device_node *, then
> make a call to irq_of_parse_and_map() to convert that into a system IRQ.
>
> What I am doing right now is:
> device_node *mpic = of_find_node_by_type(0,"open-pic");
> irq = irq_of_parse_and_map(mpic,256);
This is asking for the 256th specifier in the interrupts property in
the mpic node -- not what you want.
Ideally you would have a node for your device with an interrupt
specifier that you could look up with irq_of_parse_and_map(). But if
not, you can use irq_create_mapping() to directly convert an MPIC IRQ
number to a virtual IRQ.
What interrupt are you trying to select with 256? That doesn't look
like a valid MPIC interrupt number.
> 2) How do I know for certain that 256 is the right value for the first MSI
> signaled via MSIR0?
It isn't. The vector/priority register (MSIVPR0) is at offset
0x51c00. Each interrupt source is 32 bytes. The first interrupt
source is at 0x50000.
So the interrupt number is (0x51c00 - 0x50000) / 32 = 224.
BTW, the MSIs are already described in an msi node in the device tree.
Are you trying to do something different with them than PCI MSIs? If
not, is the existing MSI driver not working? If you are trying to do
something different, you should bind to that node yourself and use
irq_of_parse_and_map() on it.
-Scott
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-07 20:12 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood@gmail.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100921170700.53a99e56@udp111988uds.am.freescale.net>
> On Tue, 21 Sep 2010 17:37:15 -0400
> The MPIC interrupt numberspace in the device tree (which is not
> virtual; it is a private numberspace to MPIC) is based on the offset of
> the registers for that interrupt source. External interrupts start at
> zero (which is valid), internal at 16, and special things like MSIs at
> higher numbers (I don't think it's quite 256).
OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
sending this information to the folks doing the Linux Device Drivers
books? They are just a bit x86 centric right now...).
As I understand, what I have to do is somehow get a device_node *, then
make a call to irq_of_parse_and_map() to convert that into a system IRQ.
What I am doing right now is:
device_node *mpic = of_find_node_by_type(0,"open-pic");
irq = irq_of_parse_and_map(mpic,256);
While I get a pointer from of_find_node_by_type, when I try to map IRQ
#256 via the irq_of_parse_and_map function, I get a zero back from it.
So I guess my questions would be:
1) should I be frobbing the PIC for this, or should I be looking up some
other device?
2) How do I know for certain that 256 is the right value for the first MSI
signaled via MSIR0?
^ permalink raw reply
* [PATCH 1/3] Powerpc/4xx: Add suspend and idle support
From: Victor Gallardo @ 2010-10-07 19:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo
Add suspend/resume support for all 4xx compatible CPUs.
See /sys/power/state for available power states configured in.
Add two different idle states (idle-wait and idle-doze)
controlled via sysfs. Default is idle-wait.
cat /sys/devices/system/cpu/cpu0/idle
[wait] doze
To save additional power, use idle-doze.
echo doze > /sys/devices/system/cpu/cpu0/idle
cat /sys/devices/system/cpu/cpu0/idle
wait [doze]
Signed-off-by: Victor Gallardo <vgallardo@apm.com>
---
Documentation/powerpc/dts-bindings/4xx/cpm.txt | 43 +++
arch/powerpc/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 5 +-
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_cpm.c | 339 ++++++++++++++++++++++++
5 files changed, 397 insertions(+), 4 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/4xx/cpm.txt
create mode 100644 arch/powerpc/sysdev/ppc4xx_cpm.c
diff --git a/Documentation/powerpc/dts-bindings/4xx/cpm.txt b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
new file mode 100644
index 0000000..9635df8
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
@@ -0,0 +1,43 @@
+PPC4xx Clock Power Management (CPM) node
+
+Required properties:
+ - compatible : compatible list, currently only "ibm,cpm"
+ - dcr-access-method : "native"
+ - dcr-reg : < DCR register range >
+
+Optional properties:
+ - er-offset : All 4xx SoCs with a CPM controller have
+ one of two different order for the CPM
+ registers. Some have the CPM registers
+ in the following order (ER,FR,SR). The
+ others have them in the following order
+ (SR,ER,FR). For the second case set
+ er-offset = <1>.
+ - unused-units : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set to turn off unused
+ devices.
+ - idle-doze : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set to turn off unused
+ devices. This is usually just CPM[CPU].
+ - standby : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set on standby and
+ restored on resume.
+ - suspend : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set on suspend (mem) and
+ restored on resume.
+
+Example:
+ CPM0: cpm {
+ compatible = "ibm,cpm";
+ dcr-access-method = "native";
+ dcr-reg = <0x160 0x003>;
+ er-offset = <0>;
+ unused-units = <0x00000100>;
+ idle-doze = <0x02000000>;
+ standby = <0xfeff0000>;
+ standby = <0xfeff791d>;
+ };
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 631e5a0..10b2f15 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -210,7 +210,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
- PPC_85xx || PPC_86xx || PPC_PSERIES
+ PPC_85xx || PPC_86xx || PPC_PSERIES || 44x || 40x
config PPC_DCR_NATIVE
bool
@@ -596,13 +596,11 @@ config EXTRA_TARGETS
If unsure, leave blank
-if !44x || BROKEN
config ARCH_WANTS_FREEZER_CONTROL
def_bool y
depends on ADB_PMU
source kernel/power/Kconfig
-endif
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
@@ -683,6 +681,15 @@ config FSL_PMC
Freescale MPC85xx/MPC86xx power management controller support
(suspend/resume). For MPC83xx see platforms/83xx/suspend.c
+config PPC4xx_CPM
+ bool
+ default y
+ depends on SUSPEND && (44x || 40x)
+ help
+ PPC4xx Clock Power Management (CPM) support (suspend/resume).
+ It also enables support for two different idle states (idle-wait
+ and idle-doze).
+
config 4xx_SOC
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..c04d16d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,7 @@
-obj-$(CONFIG_44x) := misc_44x.o idle.o
+obj-$(CONFIG_44x) += misc_44x.o
+ifneq ($(CONFIG_PPC4xx_CPM),y)
+obj-$(CONFIG_44x) += idle.o
+endif
obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5642924..a9728d1 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
+obj-$(CONFIG_PPC4xx_CPM) += ppc4xx_cpm.o
obj-$(CONFIG_PPC4xx_GPIO) += ppc4xx_gpio.o
obj-$(CONFIG_CPM) += cpm_common.o
diff --git a/arch/powerpc/sysdev/ppc4xx_cpm.c b/arch/powerpc/sysdev/ppc4xx_cpm.c
new file mode 100644
index 0000000..d47a7ed
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_cpm.c
@@ -0,0 +1,339 @@
+/*
+ * PowerPC 4xx Clock and Power Management
+ *
+ * Copyright (C) 2010, Applied Micro Circuits Corporation
+ * Victor Gallardo (vgallardo@apm.com)
+ *
+ * Based on arch/powerpc/platforms/44x/idle.c:
+ * Jerone Young <jyoung5@us.ibm.com>
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/sysdev/fsl_pmc.c:
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ * Copyright 2009 MontaVista Software, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <linux/sysfs.h>
+#include <linux/cpu.h>
+#include <linux/suspend.h>
+#include <asm/dcr.h>
+#include <asm/dcr-native.h>
+#include <asm/machdep.h>
+
+#define CPM_ER 0
+#define CPM_FR 1
+#define CPM_SR 2
+
+#define CPM_IDLE_WAIT 0
+#define CPM_IDLE_DOZE 1
+
+struct cpm {
+ dcr_host_t dcr_host;
+ unsigned int dcr_offset[3];
+ unsigned int powersave_off;
+ unsigned int unused;
+ unsigned int idle_doze;
+ unsigned int standby;
+ unsigned int suspend;
+};
+
+static struct cpm cpm;
+
+struct cpm_idle_mode {
+ unsigned int enabled;
+ const char *name;
+};
+
+static struct cpm_idle_mode idle_mode[] = {
+ [CPM_IDLE_WAIT] = { 1, "wait" }, /* default */
+ [CPM_IDLE_DOZE] = { 0, "doze" },
+};
+
+static void cpm_set(unsigned int cpm_reg, unsigned int mask)
+{
+ unsigned int value;
+
+ value = dcr_read(cpm.dcr_host, cpm.dcr_offset[cpm_reg]);
+ value |= mask;
+ dcr_write(cpm.dcr_host, cpm.dcr_offset[cpm_reg], value);
+}
+
+static void cpm_idle_wait(void)
+{
+ unsigned long msr_save;
+
+ /* save off initial state */
+ msr_save = mfmsr();
+ /* sync required when CPM0_ER[CPU] is set */
+ mb();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static void cpm_idle_sleep(unsigned int mask)
+{
+ unsigned int er_save;
+
+ /* update CPM_ER state */
+ er_save = dcr_read(cpm.dcr_host, cpm.dcr_offset[CPM_ER]);
+ dcr_write(cpm.dcr_host, cpm.dcr_offset[CPM_ER],
+ er_save | mask);
+
+ /* go to wait state */
+ cpm_idle_wait();
+
+ /* restore CPM_ER state */
+ dcr_write(cpm.dcr_host, cpm.dcr_offset[CPM_ER], er_save);
+}
+
+static void cpm_idle_doze(void)
+{
+ cpm_idle_sleep(cpm.idle_doze);
+}
+
+static void cpm_idle_config(int mode)
+{
+ int i;
+
+ if (idle_mode[mode].enabled)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(idle_mode); i++)
+ idle_mode[i].enabled = 0;
+
+ idle_mode[mode].enabled = 1;
+}
+
+static ssize_t cpm_idle_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ char *s = buf;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(idle_mode); i++) {
+ if (idle_mode[i].enabled)
+ s += sprintf(s, "[%s] ", idle_mode[i].name);
+ else
+ s += sprintf(s, "%s ", idle_mode[i].name);
+ }
+
+ *(s-1) = '\n'; /* convert the last space to a newline */
+
+ return s - buf;
+}
+
+static ssize_t cpm_idle_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ int i;
+ char *p;
+ int len;
+
+ p = memchr(buf, '\n', n);
+ len = p ? p - buf : n;
+
+ for (i = 0; i < ARRAY_SIZE(idle_mode); i++) {
+ if (strncmp(buf, idle_mode[i].name, len) == 0) {
+ cpm_idle_config(i);
+ return n;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static struct kobj_attribute cpm_idle_attr =
+ __ATTR(idle, 0644, cpm_idle_show, cpm_idle_store);
+
+static void cpm_idle_config_sysfs(void)
+{
+ struct sys_device *sys_dev;
+ unsigned long ret;
+
+ sys_dev = get_cpu_sysdev(0);
+
+ ret = sysfs_create_file(&sys_dev->kobj,
+ &cpm_idle_attr.attr);
+ if (ret)
+ printk(KERN_WARNING
+ "cpm: failed to create idle sysfs entry\n");
+}
+
+static void cpm_idle(void)
+{
+ if (idle_mode[CPM_IDLE_DOZE].enabled)
+ cpm_idle_doze();
+ else
+ cpm_idle_wait();
+}
+
+static int cpm_suspend_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ return !!cpm.standby;
+ case PM_SUSPEND_MEM:
+ return !!cpm.suspend;
+ default:
+ return 0;
+ }
+}
+
+static void cpm_suspend_standby(unsigned int mask)
+{
+ unsigned long tcr_save;
+
+ /* disable decrement interrupt */
+ tcr_save = mfspr(SPRN_TCR);
+ mtspr(SPRN_TCR, tcr_save & ~TCR_DIE);
+
+ /* go to sleep state */
+ cpm_idle_sleep(mask);
+
+ /* restore decrement interrupt */
+ mtspr(SPRN_TCR, tcr_save);
+}
+
+static int cpm_suspend_enter(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ cpm_suspend_standby(cpm.standby);
+ break;
+ case PM_SUSPEND_MEM:
+ cpm_suspend_standby(cpm.suspend);
+ break;
+ }
+
+ return 0;
+}
+
+static struct platform_suspend_ops cpm_suspend_ops = {
+ .valid = cpm_suspend_valid,
+ .enter = cpm_suspend_enter,
+};
+
+static int cpm_get_uint_property(struct device_node *np,
+ const char *name)
+{
+ int len;
+ const unsigned int *prop = of_get_property(np, name, &len);
+
+ if (prop == NULL || len < sizeof(u32))
+ return 0;
+
+ return *prop;
+}
+
+static int __init cpm_init(void)
+{
+ struct device_node *np;
+ int dcr_base, dcr_len;
+ int ret = 0;
+
+ if (!cpm.powersave_off) {
+ cpm_idle_config(CPM_IDLE_WAIT);
+ ppc_md.power_save = &cpm_idle;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,cpm");
+ if (!np) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ dcr_base = dcr_resource_start(np, 0);
+ dcr_len = dcr_resource_len(np, 0);
+
+ if (dcr_base == 0 || dcr_len == 0) {
+ printk(KERN_ERR "cpm: could not parse dcr property for %s\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ cpm.dcr_host = dcr_map(np, dcr_base, dcr_len);
+
+ if (!DCR_MAP_OK(cpm.dcr_host)) {
+ printk(KERN_ERR "cpm: failed to map dcr property for %s\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* All 4xx SoCs with a CPM controller have one of two
+ * different order for the CPM registers. Some have the
+ * CPM registers in the following order (ER,FR,SR). The
+ * others have them in the following order (SR,ER,FR).
+ */
+
+ if (cpm_get_uint_property(np, "er-offset") == 0) {
+ cpm.dcr_offset[CPM_ER] = 0;
+ cpm.dcr_offset[CPM_FR] = 1;
+ cpm.dcr_offset[CPM_SR] = 2;
+ } else {
+ cpm.dcr_offset[CPM_ER] = 1;
+ cpm.dcr_offset[CPM_FR] = 2;
+ cpm.dcr_offset[CPM_SR] = 0;
+ }
+
+ /* Now let's see what IPs to turn off for the following modes */
+
+ cpm.unused = cpm_get_uint_property(np, "unused-units");
+ cpm.idle_doze = cpm_get_uint_property(np, "idle-doze");
+ cpm.standby = cpm_get_uint_property(np, "standby");
+ cpm.suspend = cpm_get_uint_property(np, "suspend");
+
+ /* If some IPs are unused let's turn them off now */
+
+ if (cpm.unused) {
+ cpm_set(CPM_ER, cpm.unused);
+ cpm_set(CPM_FR, cpm.unused);
+ }
+
+ /* Now let's export interfaces */
+
+ if (!cpm.powersave_off && cpm.idle_doze)
+ cpm_idle_config_sysfs();
+
+ if (cpm.standby || cpm.suspend)
+ suspend_set_ops(&cpm_suspend_ops);
+out:
+ if (np)
+ of_node_put(np);
+ return ret;
+}
+
+late_initcall(cpm_init);
+
+static int __init cpm_powersave_off(char *arg)
+{
+ cpm.powersave_off = 1;
+ return 0;
+}
+__setup("powersave=off", cpm_powersave_off);
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH 2/3] powerpc/4xx: Add Canyonlands suspend and idle support
From: Victor Gallardo @ 2010-10-07 19:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo
- Add Clock Power Management (CPM) node to dts tree
- Add idle-doze entry in CPM node
- Add standby entry in CPM node
- Add PM and SUSPEND support by default in defconfig
- Remove UART2 and UART3 as they are unused, this will
CPM to put unused-units (UART2 and UART3) to sleep.
Signed-off-by: Victor Gallardo <vgallardo@apm.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 31 +++++++-----------------
arch/powerpc/configs/44x/canyonlands_defconfig | 3 ++
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..5b27a4b 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -105,6 +105,15 @@
dcr-reg = <0x00c 0x002>;
};
+ CPM0: cpm {
+ compatible = "ibm,cpm";
+ dcr-access-method = "native";
+ dcr-reg = <0x160 0x003>;
+ unused-units = <0x00000100>;
+ idle-doze = <0x02000000>;
+ standby = <0xfeff791d>;
+ };
+
L2C0: l2c {
compatible = "ibm,l2-cache-460ex", "ibm,l2-cache";
dcr-reg = <0x020 0x008 /* Internal SRAM DCR's */
@@ -270,28 +279,6 @@
interrupts = <0x1 0x4>;
};
- UART2: serial@ef600500 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600500 0x00000008>;
- virtual-reg = <0xef600500>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <&UIC1>;
- interrupts = <28 0x4>;
- };
-
- UART3: serial@ef600600 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600600 0x00000008>;
- virtual-reg = <0xef600600>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <&UIC1>;
- interrupts = <29 0x4>;
- };
-
IIC0: i2c@ef600700 {
compatible = "ibm,iic-460ex", "ibm,iic";
reg = <0xef600700 0x00000014>;
diff --git a/arch/powerpc/configs/44x/canyonlands_defconfig b/arch/powerpc/configs/44x/canyonlands_defconfig
index 45c64d8..17e4dd9 100644
--- a/arch/powerpc/configs/44x/canyonlands_defconfig
+++ b/arch/powerpc/configs/44x/canyonlands_defconfig
@@ -42,6 +42,9 @@ CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_NDFC=y
CONFIG_PROC_DEVICETREE=y
+CONFIG_PM=y
+CONFIG_SUSPEND=y
+CONFIG_PPC4xx_CPM=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=35000
# CONFIG_MISC_DEVICES is not set
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH 3/3] powerpc/4xx: Add Kilauea suspend and idle support
From: Victor Gallardo @ 2010-10-07 19:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo
- Add Clock Power Management (CPM) node to dts tree
- Add idle-doze entry in CPM node
- Add standby entry in CPM node
- Add PM and SUSPEND support by default in defconfig
- Add NO_HZ and CONFIG_HIGH_RES_TIMERS support by
default in defconfig
Signed-off-by: Victor Gallardo <vgallardo@apm.com>
---
arch/powerpc/boot/dts/kilauea.dts | 9 +++++++++
arch/powerpc/configs/40x/kilauea_defconfig | 5 +++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 083e68e..89edb16 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -82,6 +82,15 @@
interrupt-parent = <&UIC0>;
};
+ CPM0: cpm {
+ compatible = "ibm,cpm";
+ dcr-access-method = "native";
+ dcr-reg = <0x0b0 0x003>;
+ unused-units = <0x00000000>;
+ idle-doze = <0x02000000>;
+ standby = <0xe3e74800>;
+ };
+
plb {
compatible = "ibm,plb-405ex", "ibm,plb4";
#address-cells = <1>;
diff --git a/arch/powerpc/configs/40x/kilauea_defconfig b/arch/powerpc/configs/40x/kilauea_defconfig
index 4e19ee7..34b8c1a 100644
--- a/arch/powerpc/configs/40x/kilauea_defconfig
+++ b/arch/powerpc/configs/40x/kilauea_defconfig
@@ -12,6 +12,8 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_KILAUEA=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
# CONFIG_WALNUT is not set
CONFIG_SPARSE_IRQ=y
CONFIG_PCI=y
@@ -42,6 +44,9 @@ CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_NDFC=y
CONFIG_PROC_DEVICETREE=y
+CONFIG_PM=y
+CONFIG_SUSPEND=y
+CONFIG_PPC4xx_CPM=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=35000
# CONFIG_MISC_DEVICES is not set
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH 1/2] [v2] powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
From: Timur Tabi @ 2010-10-07 19:36 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
The device tree for Freescale's P1022DS reference board is missing the node
for the ngPIXIS FPGA.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/p1022ds.dts | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
index 8bcb10b..2bbecbb 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -148,6 +148,17 @@
label = "reserved-nand";
};
};
+
+ board-control@3,0 {
+ compatible = "fsl,p1022ds-pixis";
+ reg = <3 0 0x30>;
+ interrupt-parent = <&mpic>;
+ /*
+ * IRQ8 is generated if the "EVENT" switch is pressed
+ * and PX_CTL[EVESEL] is set to 00.
+ */
+ interrupts = <8 8>;
+ };
};
soc@fffe00000 {
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Timur Tabi @ 2010-10-07 19:36 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1286480203-28227-1-git-send-email-timur@freescale.com>
The Freescale P1022DS has an on-chip video controller called the DIU, and a
driver for this device already exists. Update the platform file for the
P1022DS reference board to enable the driver, and update the defconfig for
Freescale MPC85xx boards to add the driver.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/mpc85xx_defconfig | 3 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
arch/powerpc/platforms/85xx/p1022_ds.c | 213 +++++++++++++++++++++++++++-
3 files changed, 217 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index c3b113b..3aeb594 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -124,6 +124,9 @@ CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_FB_FSL_DIU=y
+# CONFIG_VGA_CONSOLE is not set
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index a075da2..d62c801 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -126,6 +126,9 @@ CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_FB_FSL_DIU=y
+# CONFIG_VGA_CONSOLE is not set
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 2b390d1..bee247d 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -8,7 +8,6 @@
* Copyright 2010 Freescale Semiconductor, Inc.
*
* This file is taken from the Freescale P1022DS BSP, with modifications:
- * 1) No DIU support (pending rewrite of DIU code)
* 2) No AMP support
* 3) No PCI endpoint support
*
@@ -17,15 +16,216 @@
* kind, whether express or implied.
*/
+#define DEBUG
+
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <linux/memblock.h>
-
+#include <asm/div64.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
+#include <asm/fsl_guts.h>
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/*
+ * Board-specific initialization of the DIU. This code should probably be
+ * executed when the DIU is opened, rather than in arch code, but the DIU
+ * driver does not have a mechanism for this (yet).
+ *
+ * This is especially problematic on the P1022DS because the local bus (eLBC)
+ * and the DIU video signals share the same pins, which means that enabling the
+ * DIU will disable access to NOR flash.
+ */
+
+/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */
+#define CLKDVDR_PXCKEN 0x80000000
+#define CLKDVDR_PXCKINV 0x10000000
+#define CLKDVDR_PXCKDLY 0x06000000
+#define CLKDVDR_PXCLK_MASK 0x00FF0000
+
+/* Some ngPIXIS register definitions */
+#define PX_BRDCFG1_DVIEN 0x80
+#define PX_BRDCFG1_DFPEN 0x40
+#define PX_BRDCFG1_BACKLIGHT 0x20
+#define PX_BRDCFG1_DDCEN 0x10
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x10000000
+#define AD_ALPHA_C_MASK 0x0E000000
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_MASK 0x01800000
+#define AD_BLUE_C_SHIFT 23
+#define AD_GREEN_C_MASK 0x00600000
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_MASK 0x00180000
+#define AD_RED_C_SHIFT 19
+#define AD_PALETTE 0x00040000
+#define AD_PIXEL_S_MASK 0x00030000
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_MASK 0x0000F000
+#define AD_COMP_3_SHIFT 12
+#define AD_COMP_2_MASK 0x00000F00
+#define AD_COMP_2_SHIFT 8
+#define AD_COMP_1_MASK 0x000000F0
+#define AD_COMP_1_SHIFT 4
+#define AD_COMP_0_MASK 0x0000000F
+#define AD_COMP_0_SHIFT 0
+
+#define MAKE_AD(alpha, red, blue, green, size, c0, c1, c2, c3) \
+ cpu_to_le32(AD_BYTE_F | (alpha << AD_ALPHA_C_SHIFT) | \
+ (blue << AD_BLUE_C_SHIFT) | (green << AD_GREEN_C_SHIFT) | \
+ (red << AD_RED_C_SHIFT) | (c3 << AD_COMP_3_SHIFT) | \
+ (c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
+ (c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
+
+/**
+ * p1022ds_get_pixel_format: return the Area Descriptor for a given pixel depth
+ *
+ * The Area Descriptor is a 32-bit value that determine which bits in each
+ * pixel are to be used for each color.
+ */
+static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
+ int monitor_port)
+{
+ switch (bits_per_pixel) {
+ case 32:
+ /* 0x88883316 */
+ return MAKE_AD(3, 2, 0, 1, 3, 8, 8, 8, 8);
+ case 24:
+ /* 0x88082219 */
+ return MAKE_AD(4, 0, 1, 2, 2, 0, 8, 8, 8);
+ case 16:
+ /* 0x65053118 */
+ return MAKE_AD(4, 2, 1, 0, 1, 5, 6, 5, 0);
+ default:
+ pr_err("fsl-diu: unsupported pixel depth %u\n", bits_per_pixel);
+ return 0;
+ }
+}
+
+/**
+ * p1022ds_set_gamma_table: update the gamma table, if necessary
+ *
+ * On some boards, the gamma table for some ports may need to be modified.
+ * This is not the case on the P1022DS, so we do nothing.
+*/
+static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+{
+}
+
+/**
+ * p1022ds_set_monitor_port: switch the output to a different monitor port
+ *
+ */
+static void p1022ds_set_monitor_port(int monitor_port)
+{
+ struct device_node *pixis_node;
+ u8 __iomem *brdcfg1;
+
+ pixis_node = of_find_compatible_node(NULL, NULL, "fsl,p1022ds-pixis");
+ if (!pixis_node) {
+ pr_err("p1022ds: missing ngPIXIS node\n");
+ return;
+ }
+
+ brdcfg1 = of_iomap(pixis_node, 0);
+ if (!brdcfg1) {
+ pr_err("p1022ds: could not map ngPIXIS registers\n");
+ return;
+ }
+ brdcfg1 += 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
+
+ switch (monitor_port) {
+ case 0: /* DVI */
+ /* Enable the DVI port, disable the DFP and the backlight */
+ clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
+ PX_BRDCFG1_DVIEN);
+ break;
+ case 1: /* Single link LVDS */
+ /* Enable the DFP port, disable the DVI and the backlight */
+ clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
+ PX_BRDCFG1_DFPEN);
+ break;
+ default:
+ pr_err("p1022ds: unsupported monitor port %i\n", monitor_port);
+ }
+}
+
+/**
+ * p1022ds_set_pixel_clock: program the DIU's clock
+ *
+ * @pixclock: the wavelength, in picoseconds, of the clock
+ */
+void p1022ds_set_pixel_clock(unsigned int pixclock)
+{
+ struct device_node *guts_np = NULL;
+ struct ccsr_guts_85xx __iomem *guts;
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
+ if (!guts_np) {
+ pr_err("p1022ds: missing global utilties device node\n");
+ return;
+ }
+
+ guts = of_iomap(guts_np, 0);
+ of_node_put(guts_np);
+ if (!guts) {
+ pr_err("p1022ds: could not map global utilties device\n");
+ return;
+ }
+
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ /* pixclk is the ratio of the platform clock to the pixel clock */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+
+ /* Disable the pixel clock, and set it to non-inverted and no delay */
+ clrbits32(&guts->clkdvdr,
+ CLKDVDR_PXCKEN | CLKDVDR_PXCKDLY | CLKDVDR_PXCLK_MASK);
+
+ /* Enable the clock and set the pxclk */
+ setbits32(&guts->clkdvdr, CLKDVDR_PXCKEN | (pxclk << 16));
+}
+
+/**
+ * p1022ds_show_monitor_port: show the current monitor
+ *
+ * This function returns a string indicating whether the current monitor is
+ * set to DVI or LVDS.
+ */
+ssize_t p1022ds_show_monitor_port(int monitor_port, char *buf)
+{
+ return sprintf(buf, "%c0 - DVI\n%c1 - Single link LVDS\n",
+ monitor_port == 0 ? '*' : ' ', monitor_port == 1 ? '*' : ' ');
+}
+
+/**
+ * p1022ds_set_sysfs_monitor_port: set the monitor port for sysfs
+ */
+int p1022ds_set_sysfs_monitor_port(int val)
+{
+ return val < 2 ? val : 0;
+}
+
+#endif
void __init p1022_ds_pic_init(void)
{
@@ -92,6 +292,15 @@ static void __init p1022_ds_setup_arch(void)
}
#endif
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+ diu_ops.get_pixel_format = p1022ds_get_pixel_format;
+ diu_ops.set_gamma_table = p1022ds_set_gamma_table;
+ diu_ops.set_monitor_port = p1022ds_set_monitor_port;
+ diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
+ diu_ops.show_monitor_port = p1022ds_show_monitor_port;
+ diu_ops.set_sysfs_monitor_port = p1022ds_set_sysfs_monitor_port;
+#endif
+
#ifdef CONFIG_SMP
mpc85xx_smp_init();
#endif
--
1.7.2.3
^ permalink raw reply related
* Re: PPC: Possible bug in prom_parse.c:of_irq_map_raw?
From: Grant Likely @ 2010-10-07 18:34 UTC (permalink / raw)
To: John Williams
Cc: linuxppc-dev, devicetree-discuss, Linux Kernel list, Michal Simek
In-Reply-To: <1d3f23371002091921m7f47a1fbt1cf7fd2ef0a927fa@mail.gmail.com>
Reaching way back into the past....
John, did you ever solve your issue here? Comments below.
On Tue, Feb 9, 2010 at 8:21 PM, John Williams
<john.williams@petalogix.com> wrote:
> Hi,
>
> Perhaps this is my misunderstanding, but I'm looking at the bit of
> code in of_irq_map_raw() that iterates the interrupt-map DTS node,
> which I am seeing to behave strangely when handling the interrupt-map
> property on a PCI bridge node.
>
> Early in the function, we get the #address-cells value from the node -
> in this case the PCI bridge, and store it in local var addrsize:
>
> =A0 =A0 =A0 =A0/* Look for this #address-cells. We have to implement the =
old linux
> =A0 =A0 =A0 =A0 * trick of looking for the parent here as some device-tre=
es rely on it
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0old =3D of_node_get(ipar);
> =A0 =A0 =A0 =A0do {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(old, "#address-cel=
ls", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tnode =3D of_get_parent(old);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of_node_put(old);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0old =3D tnode;
> =A0 =A0 =A0 =A0} while(old && tmp =3D=3D NULL);
> =A0 =A0 =A0 =A0of_node_put(old);
> =A0 =A0 =A0 =A0old =3D NULL;
> =A0 =A0 =A0 =A0addrsize =3D (tmp =3D=3D NULL) ? 2 : *tmp;
>
> =A0 =A0 =A0 =A0DBG(" -> addrsize=3D%d\n", addrsize);
>
>
> Later, once we've found the interrupt-map and are iterating over it
> attempting to match on PCI device addresses, there is this little
> fragment:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Get the interrupt paren=
t */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (of_irq_workarounds & O=
F_IMAP_NO_PHANDLE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newpar =3D=
of_node_get(of_irq_dflt_pic);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newpar =3D
> of_find_node_by_phandle((phandle)*imap);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0imap++;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--imaplen;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check if not found */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (newpar =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBG(" -> i=
map parent not found !\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Get #interrupt-cells an=
d #address-cells of new
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * parent
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#interrupt-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tmp =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBG(" -> p=
arent lacks #interrupt-cells !\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newintsize =3D *tmp;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#address-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newaddrsize =3D (tmp =3D=
=3D NULL) ? 0 : *tmp;
>
> Finally, later in the loop we update addrsize=3Dnewaddrsize
>
> As I read this code, and the behaviour I'm seeing, is that if the
> interrupt controller parent device doesn't have an #address-cells
> entry, then this get_property will return fail, therefore setting
> newaddrsize =A0to zero. =A0This then means that subsequent match attempts
> when iterating the interrupt-map always fail, because the match length
> (addrsize) is 0.
Correct. The interrupt-map property contains the following fields:
child-unit-address child-irq irq-controller irq-parent-unit-address parent-=
irq
In the *vast majority* of cases, the irq-parent-unit-address is a
zero-length field because #address-cells isn't present on the
interrupt controller parent. So effectively interrupt-map becomes:
child-unit-address child-irq irq-controller parent-irq
See epapr 1.0 for a full discussion
>
> Maybe I'm missing something here, but shouldn't this last bit of code
> instead be:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#address-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newaddrsize =3D (tmp =3D=
=3D NULL) ? addrsize : *tmp;
>
> =A0^^^^^^^^^
> ?
>
> In other words, if the parent node has an #address-cells value, then
> use it, otherwise stick to the #address-cells value we picked up for
> the actual node in question (ie the PCI bridge).
No, because at this point we absolutely do want to know how big the
parent #address-cells is, and if it is missing, we need to use 0. If
the child's addrsize continued to be used, then the interrupt-map
parsing would get unaligned.
The inner loop is over the entries in interrupt-map. addrsize and
intsize are only updated in the case where a match is found in the
table. If a match isn't found, then it should bail out to the 'fail'
label.
> The way this is manifesting itself in the system I'm looking at is
> that only the PCI device matching the first entry in the PCI bridge
> interrupt-map property is correctly matching. For PCI devices that
> require more than one pass through the interrupt-map loop, addrsize
> goes to zero and no further match is possible.
Something sounds fishy. If you're still having problems, can you
enable #define DEBUG in drivers/of/irq.c and post the output?
> I might be able to hack around this in the device-tree by setting
> #address-cells=3D<3> in the interrupt controller node, but that doesn't
> smell right either - it's only true for PCI devices for a start,
> whereas this controller handles interrupts from many sources on the
> 32-bit PLB bus as well. =A0I looked at the ML510 DTS in boot/dts and
> it's not doing anything like this.
Yeah, that's not right, and it would mess up the interrupt-map
parsing. You'd end up with more hard to debug problems.
g.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Kumar Gala @ 2010-10-07 17:19 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-2-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
> to reflect the actual cpu we are running on otherwise
> smp_processor_id() and related functions will return the default
> initialization value of the struct or 0.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
> arch/powerpc/kernel/setup_32.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
applied
- k
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Hollis Blanchard @ 2010-10-07 16:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev, Ian Munsie, linux-kernel
In-Reply-To: <20101001220343.GA10494@lixom.net>
On Fri, Oct 1, 2010 at 3:03 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
>> > I'm not against it, and I agree some of the patches seem like good
>> > clean up. =A0I'm concerned about this bit rotting pretty quickly.
>>
>> Maybe. Most of it doesn't seem to be that bit-rottable.
>>
>> The changes to the asm stuff in misc_32.S for example are functions we
>> never ever touch once written (libgcc replacements) so I don't see them
>> rotting more with LE support than they did with BE :-)
>
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :)
Surprisingly, qemu has very poor support for the concept of
endianness. The fact that BE PowerPC works on both BE and LE hosts in
Qemu today is more accidental than anything else (the special curse of
endianness is that two wrongs make a right). Supporting LE PowerPC
guests would be a dramatic effort, and I'm pretty sure it would impact
other qemu architectures as well.
-Hollis
^ permalink raw reply
* Re: Freescale P2020 / 85xx PCIe and Advance Error Reporting (AER) service problem
From: Kumar Gala @ 2010-10-07 14:42 UTC (permalink / raw)
To: Eran Liberty
Cc: Xianghua Xiao, linuxppc-dev, linux-pci, Tony Li, Linas Vepstas,
ZHANG WEI
In-Reply-To: <4CADBD7B.3000506@extricom.com>
On Oct 7, 2010, at 7:30 AM, Eran Liberty wrote:
> Dear Penguins,
>=20
> SHORT:
> There is a BUG in the current code design / Freescale P2020/85xx PCIe =
design that prevent it from registering to the PCIe AER... or that I =
have missed something :) ..
>=20
> LESS SHORT:
> I am in the process of a Freescale P2020 based board bring up. P2020 =
is basically two 85xx processors and their peripherals share most =
features.
>=20
> PCIe has a very extensive error reporting section and the Kernel =
already has a very nice looking Advanced Error Reporting driver.
>=20
> I encounter difficulties trying to connect the P2020/85xx PCIe device =
to this AER service driver.
>=20
> My technical findings follows:
>=20
> - pcie_portdrv_probe() will be called for every BRIDGE class PCI =
device. P2020 PCIe is a PCI-PCI BRIDGE class so no problem here. - The =
code will continue to check that we have PCI_CAP_ID_EXP capability, =
which we have and continue to pcie_port_device_register().
> - Now ,the function pcie_port_device_register() will FAIL. It will =
fail because it will call assign_interrupt_mode(), return with =
PCIE_PORT_NO_IRQ, and giveup with a reasonable remark in the code
> "/*
> * Don't use service devices that require interrupts if there is
> * no way to generate them.
> */"
>=20
> So now the question is why calling assign_interrupt_mode() with the =
P2020 PCIe ROOT device return empty? Well...
> - First assign_interrupt_mode() will test for PCIE_PORT_MSIX_MODE. =
Freescale PCIe does not support this...
> - Second attampt is made to discover PCIE_PORT_MSI_MODE, which =
Freescale should support but the PCIe PCI_CAP_ID_MSI capability is =
published on the device side of the bridge and NOT on the PCIe ROOT =
device, which is the one probed and thus fails.
> - Last it attempts to look at "dev->pin" in order to set =
PCIE_PORT_INTx_MODE. On top of being the less recommended way (the old =
way), The Freescale PCIE ROOT device pin is not set anywhere.
>=20
> Failing all those the probe fails and the AER service is not activated =
for the PCIE device.
>=20
> QUESTION:
> 1. What am I missing?
> 2. Has anyone enabled the AER PCIe service for P2020/MPC85xx?
> 3. Should the PCIe ROOT end report MSI capabilities or should the =
device end report itself as bridge ???
>=20
> -- Liberty
Do you have some code that enables AER on P2020. If so it might be =
easier to see what's going on.
- k
^ permalink raw reply
* Re: Serial RapidIO Maintaintance read causes lock up
From: Micha Nelissen @ 2010-10-07 14:21 UTC (permalink / raw)
To: Bastiaan Nijkamp; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimFgrRbRfsQqN9d9GOZhth072F9TKGXunaqJNVB@mail.gmail.com>
Hi Bastian,
Bastiaan Nijkamp wrote:
> It seems i forgot to include the relevant TLB entries in U-Boot and the
> Device Tree in the e-mail, so here they are:
>
> The TLB entries in U-Boot:
The kernel maintains the TLB, you must not set those in U-boot. It might
cause conflicts when the kernel chooses its virtual memory space. You
should only configure LAWs in U-boot as the kernel does not do that.
That's the physical address you pass in the DTB (which seems to work,
reading your kernel log).
Do you access RapidIO space in U-boot also?
Do you have a logic analyser, then you can see whether the read is
actually coming out.
Check whether the time-to-live, packet and link timeouts have been set
to sane values to prevent deadlocks (especially time-to-live). At least
then your kernel will crash instead of lock up.
Micha
^ permalink raw reply
* P1020RDB PCI-E Interrupt problem
From: Fabian Bertholm @ 2010-10-07 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I try to run ath9k on a P1020RDB Freescale board.
I run into the problem similar to the Bug/Patch here:
http://patchwork.ozlabs.org/patch/52137/
I get irq 16: nobody cared....
I tried to fix the dts file in the same manner but this does not help.
Currently I am using 2.6.33.7
Any hints? Anybody?
The modified pci section from my dts:
pci0: pcie@ffe09000 {
cell-index = <1>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc30000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x4 0x2
0000 0x0 0x0 0x2 &mpic 0x5 0x2
0000 0x0 0x0 0x3 &mpic 0x6 0x2
0000 0x0 0x0 0x4 &mpic 0x7 0x2
>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xa0000000
0x2000000 0x0 0xa0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
pci1: pcie@ffe0a000 {
cell-index = <2>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x0 0x1
0000 0x0 0x0 0x2 &mpic 0x1 0x1
0000 0x0 0x0 0x3 &mpic 0x2 0x1
0000 0x0 0x0 0x4 &mpic 0x3 0x1
>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xc0000000
0x2000000 0x0 0xc0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
Best Regards,
Fabian
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 13:21 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20101007071226.GA32189@oksana.dev.rtsoft.ru>
On Oct 7, 2010, at 2:12 AM, Anton Vorontsov wrote:
> On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>>=20
>> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>>=20
>>>> @ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
>>>> { .compatible =3D "fsl,mpc8569-memory-controller", },
>>>> { .compatible =3D "fsl,mpc8572-memory-controller", },
>>>> { .compatible =3D "fsl,mpc8349-memory-controller", },
>>>> + { .compatible =3D "fsl,p1020-memory-controller", },
>>>> + { .compatible =3D "fsl,p1021-memory-controller", },
>>>> { .compatible =3D "fsl,p2020-memory-controller", },
>>>> + { .compatible =3D "fsl,p4080-memory-controller", },
>>>=20
>>> This line should be here ;)
>>=20
>> should NOT be here.
>=20
> Hm. Are you sure? I thought that only L2 cache controller is
> not applicable (and based on Scott's comment I removed
> the l2 cache compatible entry for p4080). But I guess
> memory-controller is somewhat similar to all other 85xx?
>=20
> If it's not, I can surely prepare a patch that removes
> p4080 entry.
>=20
> Thanks,
Your correct, late night and looking at the wrong line. It was the L2 =
that should have been removed. Ignore me.
- k=
^ permalink raw reply
* Freescale P2020 / 85xx PCIe and Advance Error Reporting (AER) service problem
From: Eran Liberty @ 2010-10-07 12:30 UTC (permalink / raw)
To: Xianghua Xiao, ZHANG WEI, Roy Zang, Tony Li, Linas Vepstas,
linux-pci, linuxppc-dev
Dear Penguins,
SHORT:
There is a BUG in the current code design / Freescale P2020/85xx PCIe design that prevent it from registering to the PCIe AER... or that I have missed something :) ..
LESS SHORT:
I am in the process of a Freescale P2020 based board bring up. P2020 is basically two 85xx processors and their peripherals share most features.
PCIe has a very extensive error reporting section and the Kernel already has a very nice looking Advanced Error Reporting driver.
I encounter difficulties trying to connect the P2020/85xx PCIe device to this AER service driver.
My technical findings follows:
- pcie_portdrv_probe() will be called for every BRIDGE class PCI device. P2020 PCIe is a PCI-PCI BRIDGE class so no problem here.
- The code will continue to check that we have PCI_CAP_ID_EXP capability, which we have and continue to pcie_port_device_register().
- Now ,the function pcie_port_device_register() will FAIL. It will fail because it will call assign_interrupt_mode(), return with PCIE_PORT_NO_IRQ, and giveup with a reasonable remark in the code
"/*
* Don't use service devices that require interrupts if there is
* no way to generate them.
*/"
So now the question is why calling assign_interrupt_mode() with the P2020 PCIe ROOT device return empty? Well...
- First assign_interrupt_mode() will test for PCIE_PORT_MSIX_MODE. Freescale PCIe does not support this...
- Second attampt is made to discover PCIE_PORT_MSI_MODE, which Freescale should support but the PCIe PCI_CAP_ID_MSI capability is published on the device side of the bridge and NOT on the PCIe ROOT device, which is the one probed and thus fails.
- Last it attempts to look at "dev->pin" in order to set PCIE_PORT_INTx_MODE. On top of being the less recommended way (the old way), The Freescale PCIE ROOT device pin is not set anywhere.
Failing all those the probe fails and the AER service is not activated for the PCIE device.
QUESTION:
1. What am I missing?
2. Has anyone enabled the AER PCIe service for P2020/MPC85xx?
3. Should the PCIe ROOT end report MSI capabilities or should the device end report itself as bridge ???
-- Liberty
^ permalink raw reply
* Re: Linux on ppc440gp
From: Benjamin Herrenschmidt @ 2010-10-07 8:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Gorelik, Jacob (335F)
In-Reply-To: <201010070932.56438.sr@denx.de>
On Thu, 2010-10-07 at 09:32 +0200, Stefan Roese wrote:
> On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> > On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > > UIC0 (32 IRQ sources) at DCR 0xc0
> > > UIC1 (32 IRQ sources) at DCR 0xd0
> >
> > That looks bad. Your device-tree probably. Check the DCR bindings.
>
> Why does this look bad? On 440EPx this looks like this:
Because of the shit in my eyes :-) I misread 0x00 for some reason...
> UIC0 (32 IRQ sources) at DCR 0xc0
> UIC1 (32 IRQ sources) at DCR 0xd0
> UIC2 (32 IRQ sources) at DCR 0xe0
>
> So I don't see a problem with the output above.
Right, me neither now that I had a shower !
Cheers,
Ben.
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Benjamin Herrenschmidt @ 2010-10-07 8:00 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikH-f7MCxVyWr_mrfzeooQwRqTf4pGVEFSLO4Zy@mail.gmail.com>
On Wed, 2010-10-06 at 22:05 -0400, Albert Cahalan wrote:
> On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>
> > An OS shouldn't expect to have more than its own program image
> > RAM mapped, in general.
>
> Linux actually makes calls to allocate more. I'm thankful
> that Linux always specifies an address, so I was able to
> get away with simply returning success. I wonder how this
> works for a firmware implementation that resides in RAM,
> using the memory that Linux demands. Must the firmware
> move itself out of the way?
No, Linux will retry somewhere else :-)
> >> Of course that faults immediately, so I have a handler that
> >> loads IBAT0 with a 128 KiB mapping. I treat the BAT like a
> >> direct-mapped software-loaded TLB. (like MIPS arch MMU)
> >
> > Just map the first 256MB and don't worry about anything else?
> > Seems a lot simpler to me ;-)
>
> I was expecting that Linux would demand plenty of mappings,
> including small ones and ones for IO. I was preparing myself
> for that.
No, not during prom_init. It's really just a trampoline code that sucks
out the device-tree and does a few other things. Once that's complete,
Linux takes over the MMU and from that point on, your FW is dead.
> >> Note that Linux can fail even with a firmware that doesn't touch
> >> the BAT registers. The MMU is on,
> >
> > You can boot Linux with the MMU off as well.
>
> That wasn't obvious for the prom_init path. IEEE docs seemed
> to suggest that the firmware must provide MMU handling.
1275 powerpc binding specifies both mode of operations. Linux doesn't
care which one is active
> >> and 0xc0000000 may be
> >> where the firmware expects to have... MMIO for the console,
> >> the client interface entry point, a forth stack, whatever.
> >> The BAT takes priority, and thus the firmware splatters stuff
> >> right onto the kernel or dies trying to read something it left there.
> >
> > Like I said, you're supposed to swap OS BATs with firmware BATs
> > in your client interface entry and exit. You have to switch
> > a lot of other registers there as well already, so that's no
> > big deal.
>
> Well no. This isn't real hardware. My prom entry point looks
> something like this:
>
> eciwx r0,r0,r0
> blr
>
> My ISI and DSI handlers look something like this:
>
> ecowx r0,r0,r0
> rfi
>
> The firmware doesn't need **any** registers. It's magic. I was
> just using the BAT registers to map what Linux wanted mapped.
Which is really just what any client program wants: You start with the
program ELF sections, and whatever it allocates with claim() calls.
> Anyway, I'm no longer able to reproduce the problem. I think
> something unrelated was causing strange behavior. This is a
> bit of a surprise since I would've expected a crash. Oh well.
Hard to tell from my side :-) But as I said, Linux doesn't rely on any
mapping at c0000000 or any BAT at this point. By the time it sets up
BATs the firmware is long gone and Linux is fully in control of the MMU.
Cheers,
Ben.
^ permalink raw reply
* Re: Linux on ppc440gp
From: Stefan Roese @ 2010-10-07 7:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gorelik, Jacob (335F)
In-Reply-To: <1286409104.2463.373.camel@pasglop>
On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > UIC0 (32 IRQ sources) at DCR 0xc0
> > UIC1 (32 IRQ sources) at DCR 0xd0
>
> That looks bad. Your device-tree probably. Check the DCR bindings.
Why does this look bad? On 440EPx this looks like this:
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
So I don't see a problem with the output above.
Cheers,
Stefan
^ 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