Re: Standalone SRIO Driver for Linux
Hi , Thanks for the reply . i will try to share some of my code later . Looking forward to ur ideas. Regards, S.Saravanan On Fri, Jul 13, 2012 at 6:18 PM, Bounine, Alexandre < alexandre.boun...@idt.com> wrote: > This should work. We use similar approach to test our mport HW drivers.** > ** > > ** ** > > Alex. > > ** ** > > *From:* Linuxppc-dev [mailto:linuxppc-dev-bounces+alexandre.bounine= > idt@lists.ozlabs.org] *On Behalf Of *Saravanan S > *Sent:* Friday, July 13, 2012 2:16 AM > *To:* linuxppc-dev@lists.ozlabs.org > *Subject:* Standalone SRIO Driver for Linux > > ** ** > > Hi , > > Iam currently working on the GE make DSP230 board consisting of Quad > PowerPC8640 nodes interconnected by SRIO with Linux 2.6.34 . However the > only way to access the SRIO is through rionet facility . Our requirement is > to use the SRIO interconnect without the Ethernet overheads. This would > definitely enable higher speeds (though I cant find any throughput figures > for SRIO in Linux on the net ??? ). My query is that whether any attempt > has been made to develop a standalone driver and API to access the > messaging and doorbell services of SRIO . If no then request you to please > provide inputs on the same. From my study I have the following thoughts for > the driver : > > a) Have a character device interface for user . > b) Basically use the rio support functions provided in rio.c like > rio_add_inb_buffer , rio_add_outb_message to transfer and receive messages > and add buffers . > c) Maintain a dedicated ring of buffers in the driver and transfer data > to and from the buffer to user space . > > > Is this the right direction . Would really appreciate any inputs . thanks > in advance. > > Regards, > > S.Saravanan > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: remove P1020RDB and P2020RDB CAMP device trees
We only need two examples of CAMP device trees in the upstream kernel.
Co-operative Asymmetric Multi-Processing (CAMP) is a technique where two
or more operating systems (typically multiple copies of the same Linux kernel)
are loaded into memory, and each kernel is given a subset of the available
cores to execute on. For example, on a four-core system, one kernel runs on
cores 0 and 1, and the other runs on cores 2 and 3.
The devices are also partitioned among the operating systems, and this is
done with customized device trees. Each kernel gets its own device tree
that has only the devices that it should know about.
Unfortunately, this approach is very hackish. The kernels are trusted to
only access devices in their respective device trees, and the partitioning
only works for devices that can be handled. Crafting the device trees is a
tricky process, and getting U-Boot to load and start all kernels is cumbersome.
But most importantly, each CAMP setup is very application-specific, since
the actual partitioning of resources is done in the DTS by the system
designer. Therefore, it doesn't make a lot of sense to have a lot of CAMP
device trees, since we only expect them to be used as examples.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts | 63 ---
arch/powerpc/boot/dts/p1020rdb_camp_core1.dts | 141 -
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 67
arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 125 --
4 files changed, 0 insertions(+), 396 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
delete mode 100644 arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
delete mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
delete mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
deleted file mode 100644
index 41b4585..000
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * P1020 RDB Core0 Device Tree Source in CAMP mode.
- *
- * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
- * can be shared, all the other devices must be assigned to one core only.
- * This dts file allows core0 to have memory, l2, i2c, spi, gpio, tdm, dma,
usb,
- * eth1, eth2, sdhc, crypto, global-util, message, pci0, pci1, msi.
- *
- * Please note to add "-b 0" for core0's dts compiling.
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * 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.
- */
-
-/include/ "p1020rdb.dts"
-
-/ {
- model = "fsl,P1020RDB";
- compatible = "fsl,P1020RDB", "fsl,MPC85XXRDB-CAMP";
-
- aliases {
- ethernet1 = &enet1;
- ethernet2 = &enet2;
- serial0 = &serial0;
- pci0 = &pci0;
- pci1 = &pci1;
- };
-
- cpus {
- PowerPC,P1020@1 {
- status = "disabled";
- };
- };
-
- memory {
- device_type = "memory";
- };
-
- localbus@ffe05000 {
- status = "disabled";
- };
-
- soc@ffe0 {
- serial1: serial@4600 {
- status = "disabled";
- };
-
- enet0: ethernet@b {
- status = "disabled";
- };
-
- mpic: pic@4 {
- protected-sources = <
- 42 29 30 34 /* serial1, enet0-queue-group0 */
- 17 18 24 45 /* enet0-queue-group1, crypto */
- >;
- };
- };
-};
diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
b/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
deleted file mode 100644
index 5174538..000
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
+++ /dev/null
@@ -1,141 +0,0 @@
-/*
- * P1020 RDB Core1 Device Tree Source in CAMP mode.
- *
- * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
- * can be shared, all the other devices must be assigned to one core only.
- * This dts allows core1 to have l2, eth0, crypto.
- *
- * Please note to add "-b 1" for core1's dts compiling.
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * 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.
- */
-
-/include/ "p1020rdb.dts"
-
-/ {
- model = "fsl,P1020RDB";
- compatible = "fsl,P1020RDB", "fsl,MPC85XXRDB-CAMP";
-
-
Re: [PATCH 5/7] pci: minimal alignment for bars of P2P bridges
On Fri, Jun 29, 2012 at 02:47:48PM +0800, Gavin Shan wrote:
> On some powerpc platforms, device BARs need to be assigned to separate
> "segments" of the address space in order for the error isolation and HW
> virtualization mechanisms (EEH) to work properly. Those "segments" have
> a minimum size that can be fairly large (16M). In order to be able to
> use the generic resource assignment code rather than re-inventing our
> own, we chose to group devices by bus. That way, a simple change of the
> minimum alignment requirements of resources assigned to PCI to PCI (P2P)
> bridges is enough to ensure that all BARs for devices below those bridges
> will fit into contiguous sets of segments and there will be no overlap.
If I understand correctly, you might have something like this:
PCI host bridge to bus :00
pci_bus :00: root bus resource [mem 0xc000-0xcfff]
:00:01.0: PCI bridge to [bus 10-1f]
:00:01.0: bridge window [mem 0xc100-0xc1ff]
:00:02.0: PCI bridge to [bus 20-2f]
:00:02.0: bridge window [mem 0xc200-0xc2ff]
where everything under bridge 00:01.0 is in one EEH segment, and
everything under 00:02.0 is in another. In this case, each EEH
segment is 16MB.
I think your proposal is basically that when we add up resources required
below the P2P bridges, we round up to the default 1MB (the minimum P2P
bridge memory aperture size per spec) *or* to a larger value, e.g., 16MB,
if the architecture requires it.
That makes sense to me, but I have some implementation questions.
Your patches make the required alignment a property of the host bridge.
But don't you want to do this rounding up only at certain levels of the
hierarchy? For example, what if you had another P2P bridge:
:10:01.0: PCI bridge to [bus 18-1f]
I assume the devices on bus :18 would still be in the first EEH
segment, and you wouldn't necessarily want to round up the 10:01.0
apertures to 16MB.
Maybe there should be an interface like this:
resource_size_t __weak pcibios_window_alignment(struct pci_bus *bus,
unsigned long type)
{
if (type & IORESOURCE_MEM)
return 1024*1024; /* mem windows must be 1MB aligned */
if (bus->self->io_window_1k)
return 1024;
return 4*1024; /* I/O windows default to 4K alignment */
}
that the arch could override? Then you could return the 16MB alignment
for the top-level P2P bridge leading to an EEH segment, and use the
default alignment for P2P bridges *inside* the segment.
> This patch provides a way for the host bridge to override the default
> alignment values used by the resource allocation code for that purpose.
>
> Signed-off-by: Gavin Shan
> Reviewed-by: Ram Pai
> Reviewed-by: Richard Yang
> ---
> drivers/pci/probe.c |5 +
> include/linux/pci.h |8
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 658ac97..a196529 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -431,6 +431,11 @@ static struct pci_host_bridge
> *pci_alloc_host_bridge(struct pci_bus *b)
> if (bridge) {
> INIT_LIST_HEAD(&bridge->windows);
> bridge->bus = b;
> +
> + /* Set minimal alignment shift of P2P bridges */
> + bridge->io_align_shift = PCI_DEFAULT_IO_ALIGN_SHIFT;
> + bridge->mem_align_shift = PCI_DEFAULT_MEM_ALIGN_SHIFT;
> + bridge->pmem_align_shift = PCI_DEFAULT_PMEM_ALIGN_SHIFT;
> }
>
> return bridge;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e66f4b2..2b2b38d 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -376,9 +376,17 @@ struct pci_host_bridge_window {
> resource_size_t offset; /* bus address + offset = CPU address */
> };
>
> +/* Default shits for P2P I/O and MMIO bar minimal alignment shifts */
> +#define PCI_DEFAULT_IO_ALIGN_SHIFT 12 /* 4KB */
> +#define PCI_DEFAULT_MEM_ALIGN_SHIFT 20 /* 1MB */
> +#define PCI_DEFAULT_PMEM_ALIGN_SHIFT 20 /* 1MB */
> +
> struct pci_host_bridge {
> struct device dev;
> struct pci_bus *bus;/* root bus */
> + int io_align_shift; /* P2P I/O bar minimal alignment shift
> */
> + int mem_align_shift;/* P2P MMIO bar minimal alignment shift
> */
> + int pmem_align_shift; /* P2P prefetchable MMIO bar minimal
> alignment shift */
> struct list_head windows; /* pci_host_bridge_windows */
> void (*release_fn)(struct pci_host_bridge *);
> void *release_data;
> --
> 1.7.9.5
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: p1022ds: disable the NAND flash node if video is enabled
The Freescale P1022 has a unique pin muxing "feature" where the DIU video
controller's video signals are muxed with 24 of the local bus address signals.
When the DIU is enabled, the bulk of the local bus is disabled, preventing
access to memory-mapped devices like NAND flash and the pixis FPGA.
Therefore, if the DIU is going to be enabled, then memory-mapped devices on
the localbus, like NAND flash, need to be disabled.
This patch is similar to "powerpc/85xx: p1022ds: disable the NOR flash node
if video is enabled", except that it disables the NAND flash node instead.
This PIXIS node needs to remain enabled because it is used by platform code
to switch into indirect mode.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c | 58 +---
1 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 89ee02c..5ca2823a 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -419,18 +419,6 @@ void __init p1022_ds_pic_init(void)
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
-/*
- * Disables a node in the device tree.
- *
- * This function is called before kmalloc() is available, so the 'new' object
- * should be allocated in the global area. The easiest way is to do that is
- * to allocate one static local variable for each call to this function.
- */
-static void __init disable_one_node(struct device_node *np, struct property
*new)
-{
- prom_update_property(np, new);
-}
-
/* TRUE if there is a "video=fslfb" command-line parameter. */
static bool fslfb;
@@ -493,28 +481,58 @@ static void __init p1022_ds_setup_arch(void)
diu_ops.valid_monitor_port = p1022ds_valid_monitor_port;
/*
-* Disable the NOR flash node if there is video=fslfb... command-line
-* parameter. When the DIU is active, NOR flash is unavailable, so we
-* have to disable the node before the MTD driver loads.
+* Disable the NOR and NAND flash nodes if there is video=fslfb...
+* command-line parameter. When the DIU is active, the localbus is
+* unavailable, so we have to disable these nodes before the MTD
+* driver loads.
*/
if (fslfb) {
struct device_node *np =
of_find_compatible_node(NULL, NULL, "fsl,p1022-elbc");
if (np) {
- np = of_find_compatible_node(np, NULL, "cfi-flash");
- if (np) {
+ struct device_node *np2;
+
+ of_node_get(np);
+ np2 = of_find_compatible_node(np, NULL, "cfi-flash");
+ if (np2) {
static struct property nor_status = {
.name = "status",
.value = "disabled",
.length = sizeof("disabled"),
};
+ /*
+* prom_update_property() is called before
+* kmalloc() is available, so the 'new' object
+* should be allocated in the global area.
+* The easiest way is to do that is to
+* allocate one static local variable for each
+* call to this function.
+*/
+ pr_info("p1022ds: disabling %s node",
+ np2->full_name);
+ prom_update_property(np2, &nor_status);
+ of_node_put(np2);
+ }
+
+ of_node_get(np);
+ np2 = of_find_compatible_node(np, NULL,
+ "fsl,elbc-fcm-nand");
+ if (np2) {
+ static struct property nand_status = {
+ .name = "status",
+ .value = "disabled",
+ .length = sizeof("disabled"),
+ };
+
pr_info("p1022ds: disabling %s node",
- np->full_name);
- disable_one_node(np, &nor_status);
- of_node_put(np);
+ np2->full_name);
+ prom_update_property(np2, &nand_status);
+ of_node_put(np2);
}
+
+ of_node_put(np);
}
}
--
1.7.3.4
___
Linuxppc-d
Re: [PATCH] powerpc/85xx: Fix pci base address error for p2020rdb-pc in dts
On Jul 12, 2012, at 9:27 PM, wrote: > From: Tang Yuantian > > Signed-off-by: Tang Yuantian > --- > arch/powerpc/boot/dts/p2020rdb-pc_32b.dts |4 ++-- > arch/powerpc/boot/dts/p2020rdb-pc_36b.dts |4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: L2sram: Add compatible string to the device id list
On Jul 12, 2012, at 9:27 PM, wrote: > From: Tang Yuantian > > The following platforms are supported: > mpc8544, mpc8572, mpc8536, p1021, p1025, p1024, p1010. > > Signed-off-by: Tang Yuantian > --- > arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 10 ++ > 1 files changed, 10 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Standalone SRIO Driver for Linux
This should work. We use similar approach to test our mport HW drivers. Alex. From: Linuxppc-dev [mailto:linuxppc-dev-bounces+alexandre.bounine=idt@lists.ozlabs.org] On Behalf Of Saravanan S Sent: Friday, July 13, 2012 2:16 AM To: linuxppc-dev@lists.ozlabs.org Subject: Standalone SRIO Driver for Linux Hi , Iam currently working on the GE make DSP230 board consisting of Quad PowerPC8640 nodes interconnected by SRIO with Linux 2.6.34 . However the only way to access the SRIO is through rionet facility . Our requirement is to use the SRIO interconnect without the Ethernet overheads. This would definitely enable higher speeds (though I cant find any throughput figures for SRIO in Linux on the net ??? ). My query is that whether any attempt has been made to develop a standalone driver and API to access the messaging and doorbell services of SRIO . If no then request you to please provide inputs on the same. From my study I have the following thoughts for the driver : a) Have a character device interface for user . b) Basically use the rio support functions provided in rio.c like rio_add_inb_buffer , rio_add_outb_message to transfer and receive messages and add buffers . c) Maintain a dedicated ring of buffers in the driver and transfer data to and from the buffer to user space . Is this the right direction . Would really appreciate any inputs . thanks in advance. Regards, S.Saravanan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: P1022DS board support upstream?
On Jul 13, 2012, at 8:01 AM, Kumar Gala wrote: > Is the functionality of all of these SDK patches upstream now? > > [ ignore commit id's ] > > b257909 powerpc/85xx: p1022ds: disable the NAND flash node if video is enabled > ee260f4 powerpc/mpc85xx: p1022ds support the MTD for NOR and NAND flash > 4be8bb6 powerpc/mpc85xx: 32bit address support for p1022ds > 25f9408 powerpc/85xx: fix PCI and localbus properties in p1022ds.dts > 1bcb442 powerpc/p1022ds/DTS: Add RTC support > 05e5bc8 powerpc/85xx: create 32-bit DTS for the P1022DS > 79111f3 powerpc/85xx: p1022ds: disable the NOR flash node if video is enabled > > - k Please ignore, this was meant for out internal list. Sorry for the noise. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
P1022DS board support upstream?
Is the functionality of all of these SDK patches upstream now? [ ignore commit id's ] b257909 powerpc/85xx: p1022ds: disable the NAND flash node if video is enabled ee260f4 powerpc/mpc85xx: p1022ds support the MTD for NOR and NAND flash 4be8bb6 powerpc/mpc85xx: 32bit address support for p1022ds 25f9408 powerpc/85xx: fix PCI and localbus properties in p1022ds.dts 1bcb442 powerpc/p1022ds/DTS: Add RTC support 05e5bc8 powerpc/85xx: create 32-bit DTS for the P1022DS 79111f3 powerpc/85xx: p1022ds: disable the NOR flash node if video is enabled - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Jul 13, 2012, at 7:25 AM, Josh Boyer wrote: > On Fri, Jul 13, 2012 at 7:50 AM, Kumar Gala wrote: >> >> On Jul 12, 2012, at 9:44 PM, Jiang Lu wrote: >> >>> On PPC44x core, the WRC(Watchdog-timer Reset Control) field of TCR >>> of timer can not reset by software after set to a non-zero value. >>> Which means software can not reset the timeout behaviour of watchdog timer. >>> >>> This patch selects WATCHDOG_NOWAYOUT option for 44x platforms to >>> indicate the watchdog timer can not be disabled once fired. >>> >>> Signed-off-by: Jiang Lu >>> --- >>> drivers/watchdog/Kconfig |1 + >>> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> I believe this is not 44x specific, but how Book-E watchdog is architected. > > That is my understanding as well. > >>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>> index 3709624..41f3dff 100644 >>> --- a/drivers/watchdog/Kconfig >>> +++ b/drivers/watchdog/Kconfig >>> @@ -1084,6 +1084,7 @@ config PIKA_WDT >>> config BOOKE_WDT >>> tristate "PowerPC Book-E Watchdog Timer" >>> depends on BOOKE || 4xx >>> + select WATCHDOG_NOWAYOUT if 44x >> >> This should probably be 'select WATCHDOG_NOWAYOUT if BOOKE' > > I kind of disagree with this change. It's a user selectable option for > a reason. > > Right now, if the option is not set we call booke_wdt_disable which > indeed does not actually _disable_ the WDT, but it does set the timer > period to the maxium value. We could go one step further and implement > a simple timer that pops and calls booke_wdt_ping if WATCHDOG_NOWAYOUT > is not set, then rearms itself. That would leave the user with the > ability to perform recovery of the userspace process that exited or > died and was responsible for pinging the watchdog. > > josh My only care was about it being Book-E and not 44x. Otherwise I'm happy to defer to your take on this. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/5] powerpc/85xx: add sleep and deep sleep support
On Jun 26, 2012, at 5:25 AM, Zhao Chenhui wrote: > From: Li Yang > > In sleep PM mode, the clocks of e500 core and unused IP blocks is > turned off. IP blocks which are allowed to wake up the processor > are still running. > > Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode > in addtion to the sleep PM mode. > > While in deep sleep PM mode, additionally, the power supply is > removed from e500 core and most IP blocks. Only the blocks needed > to wake up the chip out of deep sleep are ON. > > This patch supports 32-bit and 36-bit address space. > > The sleep mode is equal to the Standby state in Linux. The deep sleep > mode is equal to the Suspend-to-RAM state of Linux Power Management. > > Command to enter sleep mode. > echo standby > /sys/power/state > Command to enter deep sleep mode. > echo mem > /sys/power/state > > Signed-off-by: Dave Liu > Signed-off-by: Li Yang > Signed-off-by: Jin Qing > Signed-off-by: Jerry Huang > Cc: Scott Wood > Signed-off-by: Zhao Chenhui > --- > Changes for v6: > * changed the declaration of flush_dcache_L1() > * some minor changes > > arch/powerpc/Kconfig |2 +- > arch/powerpc/include/asm/cacheflush.h |2 + > arch/powerpc/kernel/Makefile |3 + > arch/powerpc/kernel/l2cache_85xx.S| 53 +++ > arch/powerpc/platforms/85xx/Makefile |2 +- > arch/powerpc/platforms/85xx/sleep.S | 609 + > arch/powerpc/sysdev/fsl_pmc.c | 98 +- > arch/powerpc/sysdev/fsl_soc.h |5 + > 8 files changed, 754 insertions(+), 20 deletions(-) > create mode 100644 arch/powerpc/kernel/l2cache_85xx.S > create mode 100644 arch/powerpc/platforms/85xx/sleep.S > > diff --git a/arch/powerpc/kernel/l2cache_85xx.S > b/arch/powerpc/kernel/l2cache_85xx.S > new file mode 100644 > index 000..b0b7d1c > --- /dev/null > +++ b/arch/powerpc/kernel/l2cache_85xx.S > @@ -0,0 +1,53 @@ > +/* > + * Copyright (C) 2009-2012 Freescale Semiconductor, Inc. All rights reserved. > + * Scott Wood > + * Dave Liu > + * implement the L2 cache operations of e500 based L2 controller > + * > + * 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. > + */ > + > +#include > +#include > +#include > +#include > + > + .section .text > + > + /* r3 = virtual address of L2 controller, WIMG = 01xx */ > +_GLOBAL(flush_disable_L2) > + /* It's a write-through cache, so only invalidation is needed. */ > + mbar > + isync > + lwz r4, 0(r3) > + li r5, 1 > + rlwimi r4, r5, 30, 0xc000 Can 0xc000 be a #define for what I'm guessing is L2E and L2I? > + stw r4, 0(r3) > + > + /* Wait for the invalidate to finish */ > +1: lwz r4, 0(r3) > + andis. r4, r4, 0x4000 #define for 0x4000 -> L2I@h > + bne 1b > + mbar > + > + blr > + > + /* r3 = virtual address of L2 controller, WIMG = 01xx */ > +_GLOBAL(invalidate_enable_L2) > + mbar > + isync > + lwz r4, 0(r3) > + li r5, 3 > + rlwimi r4, r5, 30, 0xc000 > + stw r4, 0(r3) > + > + /* Wait for the invalidate to finish */ > +1: lwz r4, 0(r3) > + andis. r4, r4, 0x4000 same comments as above about #defines. > + bne 1b > + mbar > + > + blr > diff --git a/arch/powerpc/platforms/85xx/Makefile > b/arch/powerpc/platforms/85xx/Makefile > index 2125d4c..d154e39 100644 > --- a/arch/powerpc/platforms/85xx/Makefile > +++ b/arch/powerpc/platforms/85xx/Makefile > @@ -3,7 +3,7 @@ > # > obj-$(CONFIG_SMP) += smp.o > > -obj-y += common.o > +obj-y += common.o sleep.o > > obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o > obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o > diff --git a/arch/powerpc/platforms/85xx/sleep.S > b/arch/powerpc/platforms/85xx/sleep.S > new file mode 100644 > index 000..b272f0c > --- /dev/null > +++ b/arch/powerpc/platforms/85xx/sleep.S > @@ -0,0 +1,609 @@ > +/* > + * Enter and leave deep sleep/sleep state on MPC85xx > + * > + * Author: Scott Wood > + * > + * Copyright (C) 2006-2012 Freescale Semiconductor, Inc. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > + * by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > + > +#define SS_TB0x00 > +#define SS_HID 0x08 /* 2 HIDs */ > +#define SS_IAC 0x10 /* 2 IACs */ > +#define SS_DAC 0x18 /* 2 DACs */ > +#define SS_DBCR 0x20 /* 3 DBCRs */ > +#define SS_PID 0x2c /* 3 PIDs */ > +#define SS_SPRG 0x38 /* 8 SPRGs */ > +#define SS_IVOR 0x58 /* 20 interrupt vectors */ > +#define SS
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Fri, Jul 13, 2012 at 7:50 AM, Kumar Gala wrote: > > On Jul 12, 2012, at 9:44 PM, Jiang Lu wrote: > >> On PPC44x core, the WRC(Watchdog-timer Reset Control) field of TCR >> of timer can not reset by software after set to a non-zero value. >> Which means software can not reset the timeout behaviour of watchdog timer. >> >> This patch selects WATCHDOG_NOWAYOUT option for 44x platforms to >> indicate the watchdog timer can not be disabled once fired. >> >> Signed-off-by: Jiang Lu >> --- >> drivers/watchdog/Kconfig |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) > > I believe this is not 44x specific, but how Book-E watchdog is architected. That is my understanding as well. >> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >> index 3709624..41f3dff 100644 >> --- a/drivers/watchdog/Kconfig >> +++ b/drivers/watchdog/Kconfig >> @@ -1084,6 +1084,7 @@ config PIKA_WDT >> config BOOKE_WDT >> tristate "PowerPC Book-E Watchdog Timer" >> depends on BOOKE || 4xx >> + select WATCHDOG_NOWAYOUT if 44x > > This should probably be 'select WATCHDOG_NOWAYOUT if BOOKE' I kind of disagree with this change. It's a user selectable option for a reason. Right now, if the option is not set we call booke_wdt_disable which indeed does not actually _disable_ the WDT, but it does set the timer period to the maxium value. We could go one step further and implement a simple timer that pops and calls booke_wdt_ping if WATCHDOG_NOWAYOUT is not set, then rearms itself. That would leave the user with the ability to perform recovery of the userspace process that exited or died and was responsible for pinging the watchdog. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/5] powerpc/85xx: add HOTPLUG_CPU support
On Jul 3, 2012, at 5:21 AM, Zhao Chenhui wrote:
> From: Li Yang
>
> Add support to disable and re-enable individual cores at runtime
> on MPC85xx/QorIQ SMP machines. Currently support e500v1/e500v2 core.
>
> MPC85xx machines use ePAPR spin-table in boot page for CPU kick-off.
> This patch uses the boot page from bootloader to boot core at runtime.
> It supports 32-bit and 36-bit physical address.
>
> Add generic_set_cpu_up() to set cpu_state as CPU_UP_PREPARE in kick_cpu().
Shouldn't the generic_setup_cpu_up() be a separate patch, and refactor
smp_generic_kick_cpu() to use it.
Also, we should pull the conversion of the spintable from #defines to struct
into a separate patch before this one.
>
> Signed-off-by: Li Yang
> Signed-off-by: Jin Qing
> Signed-off-by: Zhao Chenhui
> ---
> v7:
> * removed CONFIG_85xx_TB_SYNC
> no change to the rest of the patch set
>
> arch/powerpc/Kconfig |6 +-
> arch/powerpc/include/asm/cacheflush.h |2 +
> arch/powerpc/include/asm/smp.h|2 +
> arch/powerpc/kernel/head_fsl_booke.S | 28 +++
> arch/powerpc/kernel/smp.c | 10 +++
> arch/powerpc/platforms/85xx/smp.c | 137 -
> 6 files changed, 146 insertions(+), 39 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 38786c8..d6bacbe 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -220,7 +220,8 @@ config ARCH_HIBERNATION_POSSIBLE
> config ARCH_SUSPEND_POSSIBLE
> def_bool y
> depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
> -(PPC_85xx && !SMP) || PPC_86xx || PPC_PSERIES || 44x || 40x
> +(PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
> +|| 44x || 40x
>
> config PPC_DCR_NATIVE
> bool
> @@ -331,7 +332,8 @@ config SWIOTLB
>
> config HOTPLUG_CPU
> bool "Support for enabling/disabling CPUs"
> - depends on SMP && HOTPLUG && EXPERIMENTAL && (PPC_PSERIES || PPC_PMAC
> || PPC_POWERNV)
> + depends on SMP && HOTPLUG && EXPERIMENTAL && (PPC_PSERIES || \
> + PPC_PMAC || PPC_POWERNV || (PPC_85xx && !PPC_E500MC))
> ---help---
> Say Y here to be able to disable and re-enable individual
> CPUs at runtime on SMP machines.
> diff --git a/arch/powerpc/include/asm/cacheflush.h
> b/arch/powerpc/include/asm/cacheflush.h
> index ab9e402..b843e35 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -30,6 +30,8 @@ extern void flush_dcache_page(struct page *page);
> #define flush_dcache_mmap_lock(mapping) do { } while (0)
> #define flush_dcache_mmap_unlock(mapping) do { } while (0)
>
> +extern void __flush_disable_L1(void);
> +
> extern void __flush_icache_range(unsigned long, unsigned long);
> static inline void flush_icache_range(unsigned long start, unsigned long stop)
> {
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index ebc24dc..e807e9d 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -65,6 +65,7 @@ int generic_cpu_disable(void);
> void generic_cpu_die(unsigned int cpu);
> void generic_mach_cpu_die(void);
> void generic_set_cpu_dead(unsigned int cpu);
> +void generic_set_cpu_up(unsigned int cpu);
> int generic_check_cpu_restart(unsigned int cpu);
> #endif
>
> @@ -190,6 +191,7 @@ extern unsigned long __secondary_hold_spinloop;
> extern unsigned long __secondary_hold_acknowledge;
> extern char __secondary_hold;
>
> +extern void __early_start(void);
> #endif /* __ASSEMBLY__ */
>
> #endif /* __KERNEL__ */
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S
> b/arch/powerpc/kernel/head_fsl_booke.S
> index de80e0f..be0261b 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -996,6 +996,34 @@ _GLOBAL(flush_dcache_L1)
>
> blr
>
> +/* Flush L1 d-cache, invalidate and disable d-cache and i-cache */
> +_GLOBAL(__flush_disable_L1)
> + mflrr10
> + bl flush_dcache_L1 /* Flush L1 d-cache */
> + mtlrr10
> +
> + mfspr r4, SPRN_L1CSR0 /* Invalidate and disable d-cache */
> + li r5, 2
> + rlwimi r4, r5, 0, 3
> +
> + msync
> + isync
> + mtspr SPRN_L1CSR0, r4
> + isync
> +
> +1: mfspr r4, SPRN_L1CSR0 /* Wait for the invalidate to finish */
> + andi. r4, r4, 2
> + bne 1b
> +
> + mfspr r4, SPRN_L1CSR1 /* Invalidate and disable i-cache */
> + li r5, 2
> + rlwimi r4, r5, 0, 3
> +
> + mtspr SPRN_L1CSR1, r4
> + isync
> +
> + blr
> +
> #ifdef CONFIG_SMP
> /* When we get here, r24 needs to hold the CPU # */
> .globl __secondary_start
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index d9f9441..e0ffe03 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -423,6 +423,16 @@ void generic_set_cpu_dead(unsigned int cpu)
>
Re: Using gpio in MPC8309
On 2012-07-12 18:08, Gal Afel wrote: Hello, I just got a TWR-MPC8309 from Freescale running Embedded Linux OS. The kernel version is Linux 2.6.11+pq3 patches and the kernel preconfig file is linux_2.6.11_mpc8548_cds_def.config. That's a really OLD kernel, plus it doesn't seem to match your hardware. MPC8309 is a very different beast from the MPC8548. I'm new to processors running Linux and I'm having a hard time trying to understand how can I program the GPIO and use them. Is there a tutorial or any documentation you could provide me to get started on accessing the processor pins please? I'm using CodeWarrior Development Studio for Power Architecture version 10.0.2 and I haven't found a library that includes the functions to access the pins functionality. Is there any documentation you could suggest me to do that please? Try looking at the Linux kernel source file 'Documentation/gpio.txt' -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Jul 12, 2012, at 9:44 PM, Jiang Lu wrote: > On PPC44x core, the WRC(Watchdog-timer Reset Control) field of TCR > of timer can not reset by software after set to a non-zero value. > Which means software can not reset the timeout behaviour of watchdog timer. > > This patch selects WATCHDOG_NOWAYOUT option for 44x platforms to > indicate the watchdog timer can not be disabled once fired. > > Signed-off-by: Jiang Lu > --- > drivers/watchdog/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) I believe this is not 44x specific, but how Book-E watchdog is architected. > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 3709624..41f3dff 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -1084,6 +1084,7 @@ config PIKA_WDT > config BOOKE_WDT > tristate "PowerPC Book-E Watchdog Timer" > depends on BOOKE || 4xx > + select WATCHDOG_NOWAYOUT if 44x This should probably be 'select WATCHDOG_NOWAYOUT if BOOKE' > ---help--- > Watchdog driver for PowerPC Book-E chips, such as the Freescale > MPC85xx SOCs and the IBM PowerPC 440. > -- > 1.7.7 > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
> - offline memory
> - remove physical memory (only return -EBUSY)
> - free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39 +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
acpi_get_node() may return -1, and you should call memory_add_physaddr_to_nid()
to get the node id.
Thanks
Wen Congyang
> +
> + list_for_each_entry_safe(info, tmp, &mem_device->res_list, list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length)) {
> + result = offline_memory(info->start_addr, info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr, info->length);
> + if (result)
> + return result;
> +
> + list_del(&info->list);
> + kfree(info);
> + }
> +
> kfree(mem_device);
>
> return 0;
> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
> ===
> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
> 18:08:29.955888542 +0900
> +++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
> 18:08:43.471719518 +0900
> @@ -233,6 +233,7 @@ static inline int is_mem_section_removab
> extern int mem_online_node(int nid);
> extern int add_memory(int nid, u64 start, u64 size);
> extern int arch_add_memory(int nid, u64 start, u64 size);
> +extern int remove_memory(int nid, u64 start, u64 size);
> extern int offline_memory(u64 start, u64 size);
> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
> int nr_pages);
> Index: linux-3.5-rc6/mm/memory_hotplug.c
> ===
> --- linux-3.5-rc6.orig/mm/memory_hotplug.c2012-07-09 18:08:29.953888567
> +0900
> +++ linux-3.5-rc6/mm/memory_hotplug.c 2012-07-09 18:08:43.476719455 +0900
> @@ -659,6 +659,14 @@ out:
> }
> EXPORT_SYMBOL_GPL(add_memory);
>
> +int remove_memory(int nid, u64 start, u64 size)
> +{
> + return -EBUSY;
> +
> +}
> +EXPORT_SYMBOL_GPL(remove_memory);
> +
> +
> #ifdef CONFIG_MEMORY_HOTREMOVE
> /*
> * A free page on the buddy free lists (not the per-cpu lists) has PageBuddy
> Index: linux-3.5-rc6/drivers/base/memory.c
> ===
> --- linux-3.5-rc6.orig/drivers/base/memory.c 2012-07-09 18:08:29.947888640
> +0900
> +++ linux-3.5-rc6/drivers/base/memory.c 2012-07-09 18:10:54.880076739
> +0900
> @@ -70,6 +70,45 @@ void unregister_memory_isolate_notifier(
> }
> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>
> +bool is_memblk_offline(unsigned long start, unsigned long size)
> +{
> + struct memory_block *mem = NULL;
> + struct mem_section *section;
> + unsigned long start_pfn, end_pfn;
> + unsigned long pfn, section_nr;
> +
> + start_pfn = PFN_DOWN(start);
> + end_pfn = start_pfn + PFN_DOWN(start);
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + section_nr = pfn_to_section_nr(pfn);
> + if (!present_section_nr
[RFC] Configure GPIO settings via the device tree
Hello,
I am looking for a way to configure GPIO initial settings and exports to the
userspace via Sysfs in a generic way via a device tree.
The purpose would be to have the same features as when initializing and
exporting pins via platform code, eg.
static struct gpio leds_gpios[] = {
{ 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */
{ 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* default to OFF */
{ 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* default to OFF */
{ 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* default to OFF */
{ ... },
};
,however, with no need for the kernel to know anything more about those pins
and their later handling by simple userpsace drivers than the setup information
provided in the device tree.
This should also attack the problem of unstable GPIO numbers in the case of
daughtercards on different base boards and would help provide a defined API
to the userspace based on pin labels with the board specifics hidden in one
place in the device tree.
Is there already a way for realizing such a scenario ?
Regards,
Christian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
At 07/09/2012 06:26 PM, Yasuaki Ishimatsu Wrote:
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
>
> Note : The code does not free firmware_map_entry since there is no way to free
>memory which is allocated by bootmem.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/firmware/memmap.c| 78
> ++-
> include/linux/firmware-map.h |6 +++
> mm/memory_hotplug.c |6 ++-
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> Index: linux-3.5-rc6/mm/memory_hotplug.c
> ===
> --- linux-3.5-rc6.orig/mm/memory_hotplug.c2012-07-09 18:23:13.323844923
> +0900
> +++ linux-3.5-rc6/mm/memory_hotplug.c 2012-07-09 18:23:19.522767424 +0900
> @@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
>
> int remove_memory(int nid, u64 start, u64 size)
> {
> - return -EBUSY;
> + lock_memory_hotplug();
> + /* remove memmap entry */
> + firmware_map_remove(start, start + size - 1, "System RAM");
firmware_map_remove() is in meminit section, so remove_memory() should be in
ref section.
Thanks
Wen Congyang
> + unlock_memory_hotplug();
> + return 0;
>
> }
> EXPORT_SYMBOL_GPL(remove_memory);
> Index: linux-3.5-rc6/include/linux/firmware-map.h
> ===
> --- linux-3.5-rc6.orig/include/linux/firmware-map.h 2012-07-09
> 18:23:09.532892314 +0900
> +++ linux-3.5-rc6/include/linux/firmware-map.h2012-07-09
> 18:23:19.523767412 +0900
> @@ -25,6 +25,7 @@
>
> int firmware_map_add_early(u64 start, u64 end, const char *type);
> int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
> +int firmware_map_remove(u64 start, u64 end, const char *type);
>
> #else /* CONFIG_FIRMWARE_MEMMAP */
>
> @@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
> return 0;
> }
>
> +static inline int firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> + return 0;
> +}
> +
> #endif /* CONFIG_FIRMWARE_MEMMAP */
>
> #endif /* _LINUX_FIRMWARE_MAP_H */
> Index: linux-3.5-rc6/drivers/firmware/memmap.c
> ===
> --- linux-3.5-rc6.orig/drivers/firmware/memmap.c 2012-07-09
> 18:23:09.532892314 +0900
> +++ linux-3.5-rc6/drivers/firmware/memmap.c 2012-07-09 18:25:46.371931554
> +0900
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Data types
> --
> @@ -79,7 +80,22 @@ static const struct sysfs_ops memmap_att
> .show = memmap_attr_show,
> };
>
> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry,
> kobj)
> +
> +static void release_firmware_map_entry(struct kobject *kobj)
> +{
> + struct firmware_map_entry *entry = to_memmap_entry(kobj);
> + struct page *head_page;
> +
> + head_page = virt_to_head_page(entry);
> + if (PageSlab(head_page))
> + kfree(entry);
> +
> + /* There is no way to free memory allocated from bootmem*/
> +}
> +
> static struct kobj_type memmap_ktype = {
> + .release= release_firmware_map_entry,
> .sysfs_ops = &memmap_attr_ops,
> .default_attrs = def_attrs,
> };
> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 st
> return 0;
> }
>
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry
> *entry)
> +{
> + list_del(&entry->list);
> +}
> +
> /*
> * Add memmap entry on sysfs
> */
> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct
> return 0;
> }
>
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry
> *entry)
> +{
> + kobject_put(&entry->kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)
> +{
> + struct firmware_map_entry *entry;
> +
> + list_for_each_entry(entry, &map_entries, list)
> + if ((entry->start == start) && (entry->end == end) &&
> + (!strcmp(entry->type, type)))
> + return entry;
> +
> + return NULL;
> +}
> +
> /**
> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
> * memory hotplug.
> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 st
>
[PATCH] powerpc/iommu: Fix iommu pool initialization
The iommu pool patch has a bug where it would cause a crash when using
only one pool (based on the size of the DMA window).
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index fbefe72..ff5a6ce 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -676,9 +676,9 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
tbl->nr_pools = 1;
/* We reserve the top 1/4 of the table for large allocations */
- tbl->poolsize = (tbl->it_size * 3 / 4) / IOMMU_NR_POOLS;
+ tbl->poolsize = (tbl->it_size * 3 / 4) / tbl->nr_pools;
- for (i = 0; i < IOMMU_NR_POOLS; i++) {
+ for (i = 0; i < tbl->nr_pools; i++) {
p = &tbl->pools[i];
spin_lock_init(&(p->lock));
p->start = tbl->poolsize * i;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] power: Define PV_POWER7P
On Thu, Jul 12, 2012 at 04:59:12PM -0700, Sukadev Bhattiprolu wrote: > From: Sukadev Bhattiprolu > Date: Tue, 3 Jul 2012 13:32:46 -0700 > Subject: [PATCH 1/2] power: Define PV_POWER7P > > This change is based on the patch that Carl Love posted to LKML > > https://lkml.org/lkml/2012/6/22/309 > > It is included here for completeness and to enable building. When > the above patch is merged, this patch can be ignored. > > Signed-off-by: Sukadev Bhattiprolu > --- > arch/powerpc/include/asm/reg.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h > index f0cb7f4..b3fc2c1 100644 > --- a/arch/powerpc/include/asm/reg.h > +++ b/arch/powerpc/include/asm/reg.h > @@ -1014,6 +1014,7 @@ > #define PV_970FX 0x003C > #define PV_POWER60x003E > #define PV_POWER70x003F > +#define PV_POWER7P 0x004A > #define PV_630 0x0040 > #define PV_630p 0x0041 > #define PV_970MP 0x0044 Hmm, before this patch the PVR definitions were sorted in ascending numerical order, at least for the list of 64 bit processors. Your patch breaks this, which is not a good idea IMHO. For example, the 970* processors are already interspersed with other processors to maintain numerical order, therefore I don't see why the POWER7P could not be between 970GX and BE. Another inconsistency is that all other "plus" variants seem to use a lower case "p" suffix. So it would be better to use POWER7p. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
