* [PATCH net-next v4 3/4] can: cc770: add platform bus driver for the CC770 and AN82527
From: Wolfgang Grandegger @ 2011-11-29 9:11 UTC (permalink / raw)
To: netdev
Cc: Stanislav Yelenskiy, Devicetree-discuss, linux-can, linuxppc-dev,
IreneV, socketcan-users, Wolfgang Zarre
In-Reply-To: <1322557890-6363-1-git-send-email-wg@grandegger.com>
This driver works with both, static platform data and device tree
bindings. It has been tested on a TQM855L board with two AN82527
CAN controllers on the local bus.
CC: Devicetree-discuss@lists.ozlabs.org
CC: linuxppc-dev@ozlabs.org
CC: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
.../devicetree/bindings/net/can/cc770.txt | 56 ++++
drivers/net/can/cc770/Kconfig | 7 +
drivers/net/can/cc770/Makefile | 1 +
drivers/net/can/cc770/cc770_platform.c | 273 ++++++++++++++++++++
4 files changed, 337 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/cc770.txt
create mode 100644 drivers/net/can/cc770/cc770_platform.c
diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt
new file mode 100644
index 0000000..01e282d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/cc770.txt
@@ -0,0 +1,56 @@
+Memory mapped Bosch CC770 and Intel AN82527 CAN controller
+
+Note: The CC770 is a CAN controller from Bosch, which is 100%
+compatible with the old AN82527 from Intel, but with "bugs" being fixed.
+
+Required properties:
+
+- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
+ for the AN82527.
+
+- reg : should specify the chip select, address offset and size required
+ to map the registers of the controller. The size is usually 0x80.
+
+- interrupts : property with a value describing the interrupt source
+ (number and sensitivity) required for the controller.
+
+Optional properties:
+
+- bosch,external-clock-frequency : frequency of the external oscillator
+ clock in Hz. Note that the internal clock frequency used by the
+ controller is half of that value. If not specified, a default
+ value of 16000000 (16 MHz) is used.
+
+- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
+ If not specified or if the specified value is 0, the CLKOUT pin
+ will be disabled.
+
+- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
+ a resonable value will be calculated.
+
+- bosch,disconnect-rx0-input : see data sheet.
+
+- bosch,disconnect-rx1-input : see data sheet.
+
+- bosch,disconnect-tx1-output : see data sheet.
+
+- bosch,polarity-dominant : see data sheet.
+
+- bosch,divide-memory-clock : see data sheet.
+
+- bosch,iso-low-speed-mux : see data sheet.
+
+For further information, please have a look to the CC770 or AN82527.
+
+Examples:
+
+can@3,100 {
+ compatible = "bosch,cc770";
+ reg = <3 0x100 0x80>;
+ interrupts = <2 0>;
+ interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+};
+
+
+
diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
index 28e4d48..22c07a8 100644
--- a/drivers/net/can/cc770/Kconfig
+++ b/drivers/net/can/cc770/Kconfig
@@ -11,4 +11,11 @@ config CAN_CC770_ISA
connected to the ISA bus using I/O port, memory mapped or
indirect access.
+config CAN_CC770_PLATFORM
+ tristate "Generic Platform Bus based CC770 driver"
+ ---help---
+ This driver adds support for the CC770 and AN82527 chips
+ connected to the "platform bus" (Linux abstraction for directly
+ to the processor attached devices).
+
endif
diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
index 872ecff..9fb8321 100644
--- a/drivers/net/can/cc770/Makefile
+++ b/drivers/net/can/cc770/Makefile
@@ -4,5 +4,6 @@
obj-$(CONFIG_CAN_CC770) += cc770.o
obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
+obj-$(CONFIG_CAN_CC770_PLATFORM) += cc770_platform.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/cc770/cc770_platform.c b/drivers/net/can/cc770/cc770_platform.c
new file mode 100644
index 0000000..fb87b22
--- /dev/null
+++ b/drivers/net/can/cc770/cc770_platform.c
@@ -0,0 +1,273 @@
+/*
+ * Driver for CC770 and AN82527 CAN controllers on the platform bus
+ *
+ * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * 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.
+ */
+
+/*
+ * If platform data are used you should have similar definitions
+ * in your board-specific code:
+ *
+ * static struct cc770_platform_data myboard_cc770_pdata = {
+ * .osc_freq = 16000000,
+ * .cir = 0x41,
+ * .cor = 0x20,
+ * .bcr = 0x40,
+ * };
+ *
+ * Please see include/linux/can/platform/cc770.h for description of
+ * above fields.
+ *
+ * If the device tree is used, you need a CAN node definition in your
+ * DTS file similar to:
+ *
+ * can@3,100 {
+ * compatible = "bosch,cc770";
+ * reg = <3 0x100 0x80>;
+ * interrupts = <2 0>;
+ * interrupt-parent = <&mpic>;
+ * bosch,external-clock-frequency = <16000000>;
+ * };
+ *
+ * See "Documentation/devicetree/bindings/net/can/cc770.txt" for further
+ * information.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/delay.h>
+#include <linux/can.h>
+#include <linux/can/dev.h>
+#include <linux/can/platform/cc770.h>
+
+#include <linux/of_platform.h>
+
+#include "cc770.h"
+
+#define DRV_NAME "cc770_platform"
+
+MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
+MODULE_DESCRIPTION("Socket-CAN driver for CC770 on the platform bus");
+MODULE_LICENSE("GPL v2");
+
+#define CC770_PLATFORM_CAN_CLOCK 16000000
+
+static u8 cc770_platform_read_reg(const struct cc770_priv *priv, int reg)
+{
+ return in_8(priv->reg_base + reg);
+}
+
+static void cc770_platform_write_reg(const struct cc770_priv *priv, int reg,
+ u8 val)
+{
+ out_8(priv->reg_base + reg, val);
+}
+
+static int __devinit cc770_get_of_node_data(struct platform_device *pdev,
+ struct cc770_priv *priv)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const u32 *prop;
+ int prop_size;
+ u32 clkext;
+
+ prop = of_get_property(np, "bosch,external-clock-frequency",
+ &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ clkext = *prop;
+ else
+ clkext = CC770_PLATFORM_CAN_CLOCK; /* default */
+ priv->can.clock.freq = clkext;
+
+ /* The system clock may not exceed 10 MHz */
+ if (priv->can.clock.freq > 10000000) {
+ priv->cpu_interface |= CPUIF_DSC;
+ priv->can.clock.freq /= 2;
+ }
+
+ /* The memory clock may not exceed 8 MHz */
+ if (priv->can.clock.freq > 8000000)
+ priv->cpu_interface |= CPUIF_DMC;
+
+ if (of_get_property(np, "bosch,divide-memory-clock", NULL))
+ priv->cpu_interface |= CPUIF_DMC;
+ if (of_get_property(np, "bosch,iso-low-speed-mux", NULL))
+ priv->cpu_interface |= CPUIF_MUX;
+
+ if (!of_get_property(np, "bosch,no-comperator-bypass", NULL))
+ priv->bus_config |= BUSCFG_CBY;
+ if (of_get_property(np, "bosch,disconnect-rx0-input", NULL))
+ priv->bus_config |= BUSCFG_DR0;
+ if (of_get_property(np, "bosch,disconnect-rx1-input", NULL))
+ priv->bus_config |= BUSCFG_DR1;
+ if (of_get_property(np, "bosch,disconnect-tx1-output", NULL))
+ priv->bus_config |= BUSCFG_DT1;
+ if (of_get_property(np, "bosch,polarity-dominant", NULL))
+ priv->bus_config |= BUSCFG_POL;
+
+ prop = of_get_property(np, "bosch,clock-out-frequency", &prop_size);
+ if (prop && (prop_size == sizeof(u32)) && *prop > 0) {
+ u32 cdv = clkext / *prop;
+ int slew;
+
+ if (cdv > 0 && cdv < 16) {
+ priv->cpu_interface |= CPUIF_CEN;
+ priv->clkout |= (cdv - 1) & CLKOUT_CD_MASK;
+
+ prop = of_get_property(np, "bosch,slew-rate",
+ &prop_size);
+ if (prop && (prop_size == sizeof(u32))) {
+ slew = *prop;
+ } else {
+ /* Determine default slew rate */
+ slew = (CLKOUT_SL_MASK >>
+ CLKOUT_SL_SHIFT) -
+ ((cdv * clkext - 1) / 8000000);
+ if (slew < 0)
+ slew = 0;
+ }
+ priv->clkout |= (slew << CLKOUT_SL_SHIFT) &
+ CLKOUT_SL_MASK;
+ } else {
+ dev_dbg(&pdev->dev, "invalid clock-out-frequency\n");
+ }
+ }
+
+ return 0;
+}
+
+static int __devinit cc770_get_platform_data(struct platform_device *pdev,
+ struct cc770_priv *priv)
+{
+
+ struct cc770_platform_data *pdata = pdev->dev.platform_data;
+
+ priv->can.clock.freq = pdata->osc_freq;
+ if (priv->cpu_interface | CPUIF_DSC)
+ priv->can.clock.freq /= 2;
+ priv->clkout = pdata->cor;
+ priv->bus_config = pdata->bcr;
+ priv->cpu_interface = pdata->cir;
+
+ return 0;
+}
+
+static int __devinit cc770_platform_probe(struct platform_device *pdev)
+{
+ struct net_device *dev;
+ struct cc770_priv *priv;
+ struct resource *mem;
+ resource_size_t mem_size;
+ void __iomem *base;
+ int err, irq;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ irq = platform_get_irq(pdev, 0);
+ if (!mem || irq <= 0)
+ return -ENODEV;
+
+ mem_size = resource_size(mem);
+ if (!request_mem_region(mem->start, mem_size, pdev->name))
+ return -EBUSY;
+
+ base = ioremap(mem->start, mem_size);
+ if (!base) {
+ err = -ENOMEM;
+ goto exit_release_mem;
+ }
+
+ dev = alloc_cc770dev(0);
+ if (!dev) {
+ err = -ENOMEM;
+ goto exit_unmap_mem;
+ }
+
+ dev->irq = irq;
+ priv = netdev_priv(dev);
+ priv->read_reg = cc770_platform_read_reg;
+ priv->write_reg = cc770_platform_write_reg;
+ priv->irq_flags = IRQF_SHARED;
+ priv->reg_base = base;
+
+ if (pdev->dev.of_node)
+ err = cc770_get_of_node_data(pdev, priv);
+ else if (pdev->dev.platform_data)
+ err = cc770_get_platform_data(pdev, priv);
+ else
+ err = -ENODEV;
+ if (err)
+ goto exit_free_cc770;
+
+ dev_dbg(&pdev->dev,
+ "reg_base=0x%p irq=%d clock=%d cpu_interface=0x%02x "
+ "bus_config=0x%02x clkout=0x%02x\n",
+ priv->reg_base, dev->irq, priv->can.clock.freq,
+ priv->cpu_interface, priv->bus_config, priv->clkout);
+
+ dev_set_drvdata(&pdev->dev, dev);
+ SET_NETDEV_DEV(dev, &pdev->dev);
+
+ err = register_cc770dev(dev);
+ if (err) {
+ dev_err(&pdev->dev,
+ "couldn't register CC700 device (err=%d)\n", err);
+ goto exit_free_cc770;
+ }
+
+ return 0;
+
+exit_free_cc770:
+ free_cc770dev(dev);
+exit_unmap_mem:
+ iounmap(base);
+exit_release_mem:
+ release_mem_region(mem->start, mem_size);
+
+ return err;
+}
+
+static int __devexit cc770_platform_remove(struct platform_device *pdev)
+{
+ struct net_device *dev = dev_get_drvdata(&pdev->dev);
+ struct cc770_priv *priv = netdev_priv(dev);
+ struct resource *mem;
+
+ unregister_cc770dev(dev);
+ iounmap(priv->reg_base);
+ free_cc770dev(dev);
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ release_mem_region(mem->start, resource_size(mem));
+
+ return 0;
+}
+
+static struct of_device_id __devinitdata cc770_platform_table[] = {
+ {.compatible = "bosch,cc770"}, /* CC770 from Bosch */
+ {.compatible = "intc,82527"}, /* AN82527 from Intel CP */
+ {},
+};
+
+static struct platform_driver cc770_platform_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = cc770_platform_table,
+ },
+ .probe = cc770_platform_probe,
+ .remove = __devexit_p(cc770_platform_remove),
+};
+
+module_platform_driver(cc770_platform_driver);
+
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next v4 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Wolfgang Grandegger @ 2011-11-29 9:11 UTC (permalink / raw)
To: netdev
Cc: Stanislav Yelenskiy, devicetree-discuss, linux-can, linuxppc-dev,
IreneV, socketcan-users, Wolfgang Zarre
In-Reply-To: <1322557890-6363-1-git-send-email-wg@grandegger.com>
This patch enables or updates support for the CC770 and AN82527
CAN controller on the TQM8548 and TQM8xx boards.
CC: devicetree-discuss@lists.ozlabs.org
CC: linuxppc-dev@ozlabs.org
CC: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 ++++++++++++++-----
arch/powerpc/boot/dts/tqm8548.dts | 19 ++++++++++++++-----
arch/powerpc/boot/dts/tqm8xx.dts | 25 +++++++++++++++++++++++++
3 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index 9452c3c..d918752 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
- 2 0x0 0xa3000000 0x00008000 // CAN (2 x i82527)
+ 2 0x0 0xa3000000 0x00008000 // CAN (2 x CC770)
3 0x0 0xa3010000 0x00008000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 619776f..988d887 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
- 2 0x0 0xe3000000 0x00008000 // CAN (2 x i82527)
+ 2 0x0 0xe3000000 0x00008000 // CAN (2 x CC770)
3 0x0 0xe3010000 0x00008000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
index f6da7ec..c3dba25 100644
--- a/arch/powerpc/boot/dts/tqm8xx.dts
+++ b/arch/powerpc/boot/dts/tqm8xx.dts
@@ -57,6 +57,7 @@
ranges = <
0x0 0x0 0x40000000 0x800000
+ 0x3 0x0 0xc0000000 0x200
>;
flash@0,0 {
@@ -67,6 +68,30 @@
bank-width = <4>;
device-width = <2>;
};
+
+ /* Note: CAN support needs be enabled in U-Boot */
+ can@3,0 {
+ compatible = "intc,82527";
+ reg = <3 0x0 0x80>;
+ interrupts = <8 1>;
+ interrupt-parent = <&PIC>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
+ };
+
+ can@3,100 {
+ compatible = "intc,82527";
+ reg = <3 0x100 0x80>;
+ interrupts = <8 1>;
+ interrupt-parent = <&PIC>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ };
};
soc@fff00000 {
--
1.7.4.1
^ permalink raw reply related
* Re: [RFC PATCH v2 1/4] cpuidle: (powerpc) Add cpu_idle_wait() to allow switching of idle routines
From: Deepthi Dharwar @ 2011-11-29 7:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-pm, linux-kernel, linux-pm
In-Reply-To: <1322550115.23348.72.camel@pasglop>
On 11/29/2011 12:31 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-11-29 at 12:12 +0530, Deepthi Dharwar wrote:
>>
>> Yes, this could be problematic as there is small window for the
>> race condition to occur . Otherwise we need to manually schedule
>> it by running a kernel thread but this would definitely have a
>> overhead and would be an overkill.
>
> Depends what this "window" is. IE. What are you trying to protect
> yourself against ? What's the risk ?
>
> If it's just module unload, then stop_machine is probably your
> friend :-)
>
> Cheers,
> Ben.
>
>
Yup, it is the module unload that I am worried about. Otherwise
manually doing it using kernel thread would be an overkill -:(
Regards,
Deepthi
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] cpuidle: (powerpc) Add cpu_idle_wait() to allow switching of idle routines
From: Benjamin Herrenschmidt @ 2011-11-29 7:01 UTC (permalink / raw)
To: Deepthi Dharwar; +Cc: linuxppc-dev, linux-pm, linux-kernel, linux-pm
In-Reply-To: <4ED47EC2.2090802@linux.vnet.ibm.com>
On Tue, 2011-11-29 at 12:12 +0530, Deepthi Dharwar wrote:
>
> Yes, this could be problematic as there is small window for the
> race condition to occur . Otherwise we need to manually schedule
> it by running a kernel thread but this would definitely have a
> overhead and would be an overkill.
Depends what this "window" is. IE. What are you trying to protect
yourself against ? What's the risk ?
If it's just module unload, then stop_machine is probably your
friend :-)
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2] powerpc/40x: Add APM8018X SOC support
From: Tanmay Inamdar @ 2011-11-29 7:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, Tanmay Inamdar
The AppliedMicro APM8018X embedded processor targets embedded applications that
require low power and a small footprint. It features a PowerPC 405 processor
core built in a 65nm low-power CMOS process with a five-stage pipeline executing
up to one instruction per cycle. The family has 128-kbytes of on-chip memory,
a 128-bit local bus and on-chip DDR2 SDRAM controller with 16-bit interface.
Features:
*CPU speed (frequency): up to 600 MHz
*Five-stage pipeline, executes up to one instruction per cycle
*16 KB-I/16 KB-D L1 caches, two-way set-associative
*128 KB on-chip memory
*128-bit processor local bus (PLB)
*Separate 128-bit read and 128-bit write data bus
*Up to 6.4 GBps of peak on-chip bandwidth at 200 MHz
*On-chip DDR2 SDRAM controller with 16-bit interface
*Support for one rank of DDR2 SDRAM up to 512 MB
*One Gen 1 single-lane PCI Express interface
*One Gen 1 single lane miniPCIe interface
*Configurable as root or endpoint
*One SATA controller operating at up to 3.0 Gbps with integrated SerDes
*Two Ethernet 10/100/1000 Mbps, full-duplex MACs (RGMII/TMII/MII)
*TCP/IP acceleration hardware, QoS, and jumbo frame support
*IEEE 1588 V1 and V2 support
*On-chip IPsec acceleration with header/trailer processing
*Supports DES, 3DES, and AES encryption
*Operates at 1.5/12/480 Mbps bus speeds
version 2:
1. compressed defconfig.
2. cleaned dts.
3. cputable with single cpu entry instead of 4 similar entries.
4. removed uart specific changes.
Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
---
arch/powerpc/boot/dts/klondike.dts | 227 +++++++++++++++++++++++++++
arch/powerpc/configs/40x/klondike_defconfig | 55 +++++++
arch/powerpc/kernel/cputable.c | 13 ++
arch/powerpc/platforms/40x/Kconfig | 11 ++
arch/powerpc/platforms/40x/ppc40x_simple.c | 1 +
5 files changed, 307 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/klondike.dts
create mode 100644 arch/powerpc/configs/40x/klondike_defconfig
diff --git a/arch/powerpc/boot/dts/klondike.dts b/arch/powerpc/boot/dts/klondike.dts
new file mode 100644
index 0000000..8c94290
--- /dev/null
+++ b/arch/powerpc/boot/dts/klondike.dts
@@ -0,0 +1,227 @@
+/*
+ * Device Tree for Klondike (APM8018X) board.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Tanmay Inamdar <tinamdar@apm.com>
+ *
+ * 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
+ *
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "apm,klondike";
+ compatible = "apm,klondike";
+ dcr-parent = <&{/cpus/cpu@0}>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,apm8018x";
+ reg = <0x00000000>;
+ clock-frequency = <300000000>; /* Filled in by U-Boot */
+ timebase-frequency = <300000000>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <16384>; /* 16 kB */
+ d-cache-size = <16384>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x010>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x010>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x010>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x0a 0x4 0x0b 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x010>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-apm8018x";
+ dcr-reg = <0x010 0x002>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal2";
+ dcr-reg = <0x180 0x062>;
+ num-tx-chans = <2>;
+ num-rx-chans = <16>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC1>;
+ interrupts = </*TXEOB*/ 0x6 0x4
+ /*RXEOB*/ 0x7 0x4
+ /*SERR*/ 0x1 0x4
+ /*TXDE*/ 0x2 0x4
+ /*RXDE*/ 0x3 0x4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x20000000 0x20000000 0x30000000
+ 0x50000000 0x50000000 0x10000000
+ 0x60000000 0x60000000 0x10000000
+ 0xFE000000 0xFE000000 0x00010000>;
+ dcr-reg = <0x100 0x020>;
+ clock-frequency = <300000000>; /* Filled in by U-Boot */
+
+ RGMII0: emac-rgmii@400a2000 {
+ compatible = "ibm,rgmii";
+ reg = <0x400a2000 0x00000010>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@400a3000 {
+ compatible = "ibm,tah";
+ reg = <0x400a3000 0x100>;
+ };
+
+ TAH1: emac-tah@400a4000 {
+ compatible = "ibm,tah";
+ reg = <0x400a4000 0x100>;
+ };
+
+ EMAC0: ethernet@400a0000 {
+ compatible = "ibm,emac4", "ibm-emac4sync";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0x0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0x0 &UIC0 0x13 0x4>;
+ reg = <0x400a0000 0x00000100>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0x0>;
+ mal-rx-channel = <0x0>;
+ cell-index = <0>;
+ max-frame-size = <9000>;
+ rx-fifo-size = <4096>;
+ tx-fifo-size = <2048>;
+ phy-mode = "rgmii";
+ phy-address = <0x2>;
+ turbo = "no";
+ phy-map = <0x00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@400a1000 {
+ compatible = "ibm,emac4", "ibm-emac4sync";
+ status = "disabled";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0x0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0x0 &UIC0 0x14 0x4>;
+ reg = <0x400a1000 0x00000100>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <9000>;
+ rx-fifo-size = <4096>;
+ tx-fifo-size = <2048>;
+ phy-mode = "rgmii";
+ phy-address = <0x3>;
+ turbo = "no";
+ phy-map = <0x00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/plb/opb/serial@50001000";
+ };
+};
diff --git a/arch/powerpc/configs/40x/klondike_defconfig b/arch/powerpc/configs/40x/klondike_defconfig
new file mode 100644
index 0000000..c0d228d
--- /dev/null
+++ b/arch/powerpc/configs/40x/klondike_defconfig
@@ -0,0 +1,55 @@
+CONFIG_40x=y
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_WALNUT is not set
+CONFIG_APM8018X=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_MATH_EMULATION=y
+# CONFIG_MIGRATION is not set
+# CONFIG_SUSPEND is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=35000
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_SAS_ATTRS=y
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_EXT4_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_CRAMFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_AVERAGE=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+CONFIG_SYSCTL_SYSCALL_CHECK=y
+# CONFIG_FTRACE is not set
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index edae5bb..ce59693 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1505,6 +1505,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_4xx,
.platform = "ppc405",
},
+ { /* APM8018X */
+ .pvr_mask = 0xffff0000,
+ .pvr_value = 0x7ff11432,
+ .cpu_name = "APM8018X",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .mmu_features = MMU_FTR_TYPE_40x,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc405",
+ },
{ /* default match */
.pvr_mask = 0x00000000,
.pvr_value = 0x00000000,
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index 1530229..8883f2c 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -186,3 +186,14 @@ config IBM405_ERR51
# bool
# depends on !STB03xxx && PPC4xx_DMA
# default y
+#
+
+config APM8018X
+ bool "APM8018X"
+ depends on 40x
+ default n
+ select PPC40x_SIMPLE
+ help
+ This option enables support for the AppliedMicro APM8018X evaluation
+ board.
+
diff --git a/arch/powerpc/platforms/40x/ppc40x_simple.c b/arch/powerpc/platforms/40x/ppc40x_simple.c
index e8dd5c5..2f8fde6 100644
--- a/arch/powerpc/platforms/40x/ppc40x_simple.c
+++ b/arch/powerpc/platforms/40x/ppc40x_simple.c
@@ -55,6 +55,7 @@ static const char *board[] __initdata = {
"amcc,haleakala",
"amcc,kilauea",
"amcc,makalu",
+ "apm,klondike",
"est,hotfoot"
};
--
1.6.1.rc3
^ permalink raw reply related
* Re: [RFC PATCH v2 4/4] cpuidle: (POWER) Handle power_save=off
From: Deepthi Dharwar @ 2011-11-29 6:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-pm, linux-kernel, linux-pm
In-Reply-To: <1322512771.23348.45.camel@pasglop>
On 11/29/2011 02:09 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-11-28 at 16:33 +0530, Deepthi Dharwar wrote:
>
>> On an LPAR if cpuidle is disabled, ppc_md.power_save is still set to
>> cpuidle_idle_call by default here. This would result in calling of
>> cpuidle_idle_call repeatedly, only for the call to return -ENODEV. The
>> default idle is never executed.
>> This would be a major design flaw. No fallback idle routine.
>>
>> We propose to fix this by checking the return value of
>> ppc_md.power_save() call from void to int.
>> Right now return value is void, but if we change this to int, this
>> would solve two problems. One being removing the cast to a function
>> pointer in the prev patch and this design flaw stated above.
>>
>> So by checking the return value of ppc_md.power_save(), we can invoke
>> the default idle on failure. But my only concern is about the effects of
>> changing the ppc_md.power_save() to return int on other powerpc
>> architectures. Would it be a good idea to change the return type to int
>> which would help us flag an error and fallback to default idle?
>
> I would have preferred an approach where the cpuidle module sets
> ppc_md.power_save when loaded and restores it when unloaded ... but that
> would have to go into the cpuidle core as a powerpc specific tweak and
> might not be generally well received.
>
> So go for it, add the return value, but you'll have to update all the
> idle functions (grep for power_save in arch/powerpc to find them).
>
Thanks Ben. Yes, I will update all the idle functions under powerpc.
I will re-work these patches with the discussed changes.
Regards,
Deepthi
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] cpuidle: (powerpc) Add cpu_idle_wait() to allow switching of idle routines
From: Deepthi Dharwar @ 2011-11-29 6:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-pm, linux-kernel, linux-pm
In-Reply-To: <1322512522.23348.43.camel@pasglop>
On 11/29/2011 02:05 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-11-28 at 16:32 +0530, Deepthi Dharwar wrote:
>
>>> Additionally, I'm a bit worried (but maybe we already discussed that a
>>> while back, I don't know) but cpu_idle_wait() has "wait" in the name,
>>> which makes me think it might need to actually -wait- for all cpus to
>>> have come out of the function.
>>
>> cpu_idle_wait is used to ensure that all the CPUs discard old idle
>> handler and update to new one. Required while changing idle
>> handler on SMP systems.
>>
>>> Now your implementation doesn't provide that guarantee. It might be
>>> fine, I don't know, but if it is, you'd better document it well in the
>>> comments surrounding the code, because as it is, all you do is shoot an
>>> interrupt which will cause the target CPU to eventually come out of idle
>>> some time in the future.
>>
>>
>> I was hoping that sending an explicit reschedule to the cpus would
>> do the trick but sure we can add some documentation around the code.
>
> Well, the question is what guarantee do you expect. Sending a reschedule
> IPI will take the other CPUs out of the actual sleep mode, but it will
> be some time from there back to getting out of the handler function
> (first back out of hypervisor etc...).
>
> The code as you implemented it doesn't wait for that to happen. It might
> be fine ... or not. I don't know what semantics you are after precisely.
>
> Cheers,
> Ben.
>
>
Yes, this could be problematic as there is small window for the
race condition to occur . Otherwise we need to manually schedule
it by running a kernel thread but this would definitely have a
overhead and would be an overkill.
Regards,
Deepthi
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Add APM8018X SOC support
From: Tanmay Inamdar @ 2011-11-29 6:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel, Arnd Bergmann
In-Reply-To: <1322435957.23348.23.camel@pasglop>
On Mon, Nov 28, 2011 at 4:49 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2011-11-25 at 17:49 +0530, Tanmay Inamdar wrote:
>
>>
>> =A0 =A0 =A0 =A0 >
>> =A0 =A0 =A0 =A0 > +#if defined(CONFIG_APM8018X)
>> =A0 =A0 =A0 =A0 > +/* CPR */
>> =A0 =A0 =A0 =A0 > +#define DCRN_CPR0_CONFIG_ADDR =A0 =A0 =A0 =A00xa
>> =A0 =A0 =A0 =A0 > +#define DCRN_CPR1_CONFIG_DATA =A0 =A0 =A0 =A00xb
>> =A0 =A0 =A0 =A0 > +/* AHB */
>> =A0 =A0 =A0 =A0 > +#define DCRN_SDR1_CONFIG_ADDR =A0 =A0 =A0 =A00xc
>> =A0 =A0 =A0 =A0 > +#define DCRN_SDR1_CONFIG_DATA =A0 =A0 =A0 =A00xd
>> =A0 =A0 =A0 =A0 > +#else
>> =A0 =A0 =A0 =A0 > =A0/* CPRs (440GX and 440SP/440SPe) */
>> =A0 =A0 =A0 =A0 > =A0#define DCRN_CPR0_CONFIG_ADDR =A0 =A0 =A0 =A00xc
>> =A0 =A0 =A0 =A0 > =A0#define DCRN_CPR0_CONFIG_DATA =A0 =A0 =A0 =A00xd
>> =A0 =A0 =A0 =A0 > +#endif /* CONFIG_APM8018X */
>>
>>
>> =A0 =A0 =A0 =A0 same comment as above.
>>
>> Some existing drivers use these macros. If I change the names, I will
>> have to update the
>> driver code.
>
> Right, the best approach is to create a small wrapper that provides cpr
> and sdr accesses using helpers. That way you can:
>
> =A0- Properly lock since it's all indirect
>
> =A0- Obtain the right DCRs at boot time, stick them in variables
> =A0 and use them at runtime, avoiding the hard coded constants completely
>
> =A0- Make the code generally look much better
>
> Ie. Provide something like read_sdr1() and write_sdr1() accessors and
> change the drivers to use them.
Ok.
There are 'mfdcri' and 'mtdcri' macros in
"arch/powerpc/include/asm/dcr-native.h" file.
They internally use '__mfdcri' and '__mtdcri' functions which can be
used for the same
purpose as mentioned above.
Instead of putting this change in current patch, I will make separate
patch for this purpose.
>
>> =A0 =A0 =A0 =A0 > diff --git a/arch/powerpc/kernel/cputable.c
>> =A0 =A0 =A0 =A0 b/arch/powerpc/kernel/cputable.c
>> =A0 =A0 =A0 =A0 > index edae5bb..e5c51a6 100644
>> =A0 =A0 =A0 =A0 > --- a/arch/powerpc/kernel/cputable.c
>> =A0 =A0 =A0 =A0 > +++ b/arch/powerpc/kernel/cputable.c
>> =A0 =A0 =A0 =A0 > @@ -1505,6 +1505,58 @@ static struct cpu_spec __initda=
ta
>> =A0 =A0 =A0 =A0 cpu_specs[] =3D {
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 .machine_check =A0 =A0 =A0=
=A0 =A0=3D machine_check_4xx,
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 .platform =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =3D "ppc405",
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 },
>> =A0 =A0 =A0 =A0 > + =A0 =A0 { =A0 =A0 =A0 /* APM80186-SK */
>> =A0 =A0 =A0 =A0 > + =A0 =A0 =A0 =A0 =A0 =A0 .pvr_mask =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =3D 0xffffffff,
>> =A0 =A0 =A0 =A0 > + =A0 =A0 =A0 =A0 =A0 =A0 .pvr_value =A0 =A0 =A0 =A0 =
=A0 =A0 =A0=3D 0x7ff11432,
>>
>>
>> =A0 =A0 =A0 =A0 If you mask out the lower bits, you only need a single e=
ntry
>> =A0 =A0 =A0 =A0 instead of
>> =A0 =A0 =A0 =A0 four identical ones.
>>
>> You are right. But each PVR represent different version of SOC. If I
>> create single entry, then I will have to give generic cpu_name which I
>> don't want.
>
> Note that you should really tell you designers to move away from using
> the PVR to identify the SoC's. This is BAD and isn't sustainable long
> run. Stick to representing the core itself in the PVR and provide a
> different mechanism to identify the SoC (different SPR would do, or even
> a DCR).
>
>> =A0 =A0 =A0 =A0 > --- a/arch/powerpc/kernel/udbg_16550.c
>> =A0 =A0 =A0 =A0 > +++ b/arch/powerpc/kernel/udbg_16550.c
>> =A0 =A0 =A0 =A0 > @@ -18,6 +18,19 @@ extern void real_writeb(u8 data, vo=
latile
>> =A0 =A0 =A0 =A0 u8 __iomem *addr);
>> =A0 =A0 =A0 =A0 > =A0extern u8 real_205_readb(volatile u8 __iomem =A0*ad=
dr);
>> =A0 =A0 =A0 =A0 > =A0extern void real_205_writeb(u8 data, volatile u8 __=
iomem
>> =A0 =A0 =A0 =A0 *addr);
>> =A0 =A0 =A0 =A0 >
>> =A0 =A0 =A0 =A0 > +#ifdef CONFIG_UART_16550_WORD_ADDRESSABLE
>> =A0 =A0 =A0 =A0 > +struct NS16550 {
>> =A0 =A0 =A0 =A0 > + =A0 =A0 /* this struct must be packed */
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char rbr; =A0/* 0 */ u8 s0[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char ier; =A0/* 1 */ u8 s1[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char fcr; =A0/* 2 */ u8 s2[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char lcr; =A0/* 3 */ u8 s3[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char mcr; =A0/* 4 */ u8 s4[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char lsr; =A0/* 5 */ u8 s5[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char msr; =A0/* 6 */ u8 s6[3];
>> =A0 =A0 =A0 =A0 > + =A0 =A0 unsigned char scr; =A0/* 7 */ u8 s7[3];
>> =A0 =A0 =A0 =A0 > +};
>> =A0 =A0 =A0 =A0 > +#else
>> =A0 =A0 =A0 =A0 > =A0struct NS16550 {
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 /* this struct must be packed */
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 unsigned char rbr; =A0/* 0 */
>> =A0 =A0 =A0 =A0 > @@ -29,6 +42,7 @@ struct NS16550 {
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 unsigned char msr; =A0/* 6 */
>> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 unsigned char scr; =A0/* 7 */
>> =A0 =A0 =A0 =A0 > =A0};
>> =A0 =A0 =A0 =A0 > +#endif /* CONFIG_UART_16550_WORD_ADDRESSABLE */
>> =A0 =A0 =A0 =A0 >
>>
>>
>> =A0 =A0 =A0 =A0 Same things as with the register definitions. Please mak=
e this
>> =A0 =A0 =A0 =A0 run-time selectable to allow build-time configurations t=
hat
>> =A0 =A0 =A0 =A0 support both layouts.
>>
>> Yes. I will try to find better solution.
>
> Cheers,
> Ben.
>
>
>
Regards,
Tanmay
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains information=
=A0
that is confidential and proprietary to AppliedMicro Corporation or its s=
ubsidiaries. =
It is to be used solely for the purpose of furthering the parties' busine=
ss relationship. =
All unauthorized review, use, disclosure or distribution is prohibited. =
If you are not the intended recipient, please contact the sender by reply=
e-mail =
and destroy all copies of the original message.
=0D
^ permalink raw reply
* Re: [PATCH 04/13] powerpc: Update hugetlb huge_pte_alloc and tablewalk code for FSL BOOKE
From: Benjamin Herrenschmidt @ 2011-11-29 5:25 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <1318279870278-git-send-email-beckyb@kernel.crashing.org>
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>
> This updates the hugetlb page table code to handle 64-bit FSL_BOOKE.
> The previous 32-bit work counted on the inner levels of the page table
> collapsing.
Seriously, my brain hurts !!!
So I've tried to understand that code and so far, what I came up with is
this, please reply and let me know if I'm full of crack or what ...
- David's code has entire levels "branching off" into hugepd's which
are hugetlb specific page dirs. That requires address space constrainst.
- The hack you do with HUGEPD_PGD_SHIFT defined to PGDIR_SHIFT and
HUGEPD_PUD_SHIFT to PUD_SHIFT consists of collasping that back into the
normal levels.
- I really don't understand what you are doing in __hugepte_alloc(). It
seems to me that you are trying to make things still point to some kind
of separate hugepd dir with the hugeptes in it and have the page tables
point to that but I don't quite get it.
- Couldn't we just instead ditch the whole hugepd concept alltogether
and simply have the huge ptes in the page table at the right level,
using possibly multiple consecutive of them for a single page when
needed ?
Example: 4K base page size. PMD maps 2M. a 16M page could be
representing by having 8 consecutive hugeptes pointing to the same huge
page in the PMD directory.
I believe we always "know" when accessing a PTE whether it's going to be
huge or not and if it's huge, the page size. IE. All the functions we
care about either get the vma (which gets you everything you need) or
the size (huge_pte_alloc).
This should be much simpler than what we have today.
That way, we have a completely generic accross-the-board way to store
huge pte's in our page tables, which is totally disconnected from the
slices. The later remains a purely server-only thing which only affects
the SLB code and get_unmapped_area().
That means that we'll have to find another option for PowerEN giant
indirects but that's a non issue at the moment. I think we can keep the
complexity local to the PowerEN code by doing shadows there if we need
to.
What do you think ?
Ben.
^ permalink raw reply
* [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Matthew McClintock @ 2011-11-29 4:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala
In-Reply-To: <1322192477.32635.15.camel@pasglop>
boot_cpuid and init_thread_info.cpu are redundant, just use the
var that stays around longer and add a define to make boot_cpuid
point at the correct value
boot_cpudid_phys is not needed and can completly go away from the
SMP case, we leave it there for the non-SMP case since the paca
struct is not around to store this info
This patch also has the effect of having the logical cpu number
of the boot cpu be updated correctly independently of the ordering
of the cpu nodes in the device tree.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
v2: Fix compile issue for peries
Remove '-1' initial value
arch/powerpc/include/asm/smp.h | 2 +-
arch/powerpc/kernel/setup_32.c | 5 +++--
arch/powerpc/kernel/setup_64.c | 1 -
arch/powerpc/sysdev/xics/xics-common.c | 1 +
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index adba970..f26c554 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -29,7 +29,7 @@
#endif
#include <asm/percpu.h>
-extern int boot_cpuid;
+#define boot_cpuid (init_thread_info.cpu)
extern int spinning_secondaries;
extern void cpu_die(void);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index ac76108..8d4df4c 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -46,10 +46,11 @@
extern void bootx_init(unsigned long r4, unsigned long phys);
-int boot_cpuid = -1;
-EXPORT_SYMBOL_GPL(boot_cpuid);
+/* we need a place to store phys cpu for non-SMP case */
+#ifndef CONFIG_SMP
int boot_cpuid_phys;
EXPORT_SYMBOL_GPL(boot_cpuid_phys);
+#endif
int smp_hw_index[NR_CPUS];
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index fb9bb46..6d0f00f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -73,7 +73,6 @@
#define DBG(fmt...)
#endif
-int boot_cpuid = 0;
int __initdata spinning_secondaries;
u64 ppc64_pft_size;
diff --git a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
index d72eda6..8998b7a 100644
--- a/arch/powerpc/sysdev/xics/xics-common.c
+++ b/arch/powerpc/sysdev/xics/xics-common.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/sched.h>
#include <asm/prom.h>
#include <asm/io.h>
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH 02/13] powerpc: hugetlb: fix huge_ptep_set_access_flags return value
From: Benjamin Herrenschmidt @ 2011-11-29 3:58 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798643553-git-send-email-beckyb@kernel.crashing.org>
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
> diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h
> index 8600493..70f9885 100644
> --- a/arch/powerpc/include/asm/hugetlb.h
> +++ b/arch/powerpc/include/asm/hugetlb.h
> @@ -124,7 +124,18 @@ static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep,
> pte_t pte, int dirty)
> {
> +#if defined(CONFIG_PPC_MMU_NOHASH) && \
> + !(defined(CONFIG_PPC_FSL_BOOK3E) && defined(CONFIG_PPC32))
The above conditional makes my brain hurt. Can you change that to
instead
#ifdef HUGETLB_NEED_PRELOAD
... or something like that, which you then #define in the right
mmu-xxxx.h header ?
Cheers,
Ben.
> + /*
> + * The "return 1" forces a call of update_mmu_cache, which will write a
> + * TLB entry. Without this, platforms that don't do a write of the TLB
> + * entry in the TLB miss handler asm will fault ad infinitum.
> + */
> + ptep_set_access_flags(vma, addr, ptep, pte, dirty);
> + return 1;
> +#else
> return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
> +#endif
> }
>
> static inline pte_t huge_ptep_get(pte_t *ptep)
^ permalink raw reply
* RE: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use.
From: Shi Xuelin-B29237 @ 2011-11-29 3:41 UTC (permalink / raw)
To: Ira W. Snyder
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
linux-kernel@vger.kernel.org
In-Reply-To: <20111128163814.GA10919@ovro.caltech.edu>
SGkgSXJhLCANCg0Kc2VlIG15IGNvbW1lbnRzIGJlbG93Lg0KDQpUaGFua3MsDQpGb3JyZXN0DQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJcmEgVy4gU255ZGVyIFttYWlsdG86
aXdzQG92cm8uY2FsdGVjaC5lZHVdIA0KU2VudDogMjAxMeW5tDEx5pyIMjnml6UgMDozOA0KVG86
IFNoaSBYdWVsaW4tQjI5MjM3DQpDYzogdmlub2Qua291bEBpbnRlbC5jb207IGRhbi5qLndpbGxp
YW1zQGludGVsLmNvbTsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IExpIFlhbmctUjU4
NDcyOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQpTdWJqZWN0OiBSZTogW1BBVENIXVtS
RkNdIGZzbGRtYTogZml4IHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uIGJ5IG9wdGltaXppbmcgc3Bp
bmxvY2sgdXNlLg0KDQpPbiBUaHUsIE5vdiAyNCwgMjAxMSBhdCAwODoxMjoyNUFNICswMDAwLCBT
aGkgWHVlbGluLUIyOTIzNyB3cm90ZToNCj4gSGkgSXJhLA0KPiANCj4gVGhhbmtzIGZvciB5b3Vy
IHJldmlldy4NCj4gDQo+IEFmdGVyIHNlY29uZCB0aG91Z2h0LCBJIHRoaW5rIHlvdXIgc2NlbmFy
aW8gbWF5IG5vdCBvY2N1ci4NCj4gQmVjYXVzZSB0aGUgY29va2llIDIwIHdlIHF1ZXJ5IG11c3Qg
YmUgcmV0dXJuZWQgYnkgZnNsX2RtYV90eF9zdWJtaXQoLi4uKSBpbiBwcmFjdGljZS4gDQo+IFdl
IG5ldmVyIHF1ZXJ5IGEgY29va2llIG5vdCByZXR1cm5lZCBieSBmc2xfZG1hX3R4X3N1Ym1pdCgu
Li4pLg0KPiANCg0KSSBhZ3JlZSBhYm91dCB0aGlzIHBhcnQuDQoNCj4gV2hlbiB3ZSBjYWxsIGZz
bF90eF9zdGF0dXMoMjApLCB0aGUgY2hhbi0+Y29tbW9uLmNvb2tpZSBpcyBkZWZpbml0ZWx5IHdy
b3RlIGFzIDIwIGFuZCBjcHUyIGNvdWxkIG5vdCByZWFkIGFzIDE5Lg0KPiANCg0KVGhpcyBpcyB3
aGF0IEkgZG9uJ3QgYWdyZWUgYWJvdXQuIEhvd2V2ZXIsIEknbSBub3QgYW4gZXhwZXJ0IG9uIENQ
VSBjYWNoZSB2cy4gbWVtb3J5IGFjY2Vzc2VzIGluIGFuIG11bHRpLXByb2Nlc3NvciBzeXN0ZW0u
IFRoZSBzZWN0aW9uIHRpdGxlZCAiQ0FDSEUgQ09IRVJFTkNZIiBpbiBEb2N1bWVudGF0aW9uL21l
bW9yeS1iYXJyaWVycy50eHQgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IHRoZSBzY2VuYXJpbyBJ
IGRlc2NyaWJlZCBpcyBwb3NzaWJsZS4NCg0KIA0KW1NoaSBYdWVsaW4tQjI5MjM3XSBJZiBxdWVy
eSBpcyB1c2VkIHdpdGhvdXQgcnVsZXMsIHlvdXIgc2NlbmFyaW8gbWF5IGhhcHBlbi4gQnV0IGlu
IERNQSB1c2FnZSBoZXJlLCB0aGUgcXVlcnkgaXMgdXNlZCBzb21ldGhpbmcgbGlrZSBzZXF1ZW50
aWFsbHkuIE9ubHkgYWZ0ZXIgY2hhbi0+Y29tbW9uLmNvb2tpZSBpcyB1cGRhdGVkIGluIGZzbF9k
bWFfdHhfc3VibWl0KC4uLikgYW5kIHJldHVybmVkLCB0aGVuIGl0IGNvdWxkIGJlIHF1ZXJpZWQu
IFNvIHlvdSBzY2VuYXJpbyB3aWxsIG5vdCBoYXBwZW4uDQoNCldoYXQgaGFwcGVucyBpZiBDUFUx
J3Mgd3JpdGUgb2YgY2hhbi0+Y29tbW9uLmNvb2tpZSBvbmx5IGdvZXMgaW50byBDUFUxJ3MgY2Fj
aGUuIEl0IG5ldmVyIG1ha2VzIGl0IHRvIG1haW4gbWVtb3J5IGJlZm9yZSBDUFUyIGZldGNoZXMg
dGhlIG9sZCB2YWx1ZSBvZiAxOS4NCiANCltTaGkgWHVlbGluLUIyOTIzN10gQXMgeW91IHNlZSwg
Y2hhbi0+Y29tbW9uLmNvb2tpZSBpcyB1cGRhdGVkIGluIGZzbF9kbWFfdHhfc3VibWl0KC4uLikg
YW5kIGVuY2xvc2VkIGJ5IHNwaW5sb2NrLiBUaGUgc3BpbmxvY2sgaW1wbGVtZW50YXRpb24gaW4g
UFBDIHdpbGwgZ3VhcmFudGVlIHRoZSBjYWNoZSBjb2hlcmVuY2UgYW1vbmcgY29yZXMsIHNvbWV0
aGluZyBsaWtlIHlvdSBjYWxsZWQgaW1wbGljaXQgc21wX21iLg0KDQpJIGRvbid0IHRoaW5rIHlv
dSBzaG91bGQgc2VlIGFueSBwZXJmb3JtYW5jZSBpbXBhY3QgZnJvbSB0aGUgc21wX21iKCkgb3Bl
cmF0aW9uLg0KDQpbU2hpIFh1ZWxpbi1CMjkyMzddIE9ubHkgYWRkIHNtcF9tYigpIGRvZXNuJ3Qg
d29yay4gSXQgb25seSBzeW5jIG9uIHRoaXMgc3RlcCwgYnV0IG5leHQgc3RlcCBpcyB0aGUgc2Ft
ZSBhcyBqdXN0IGdldHRpbmcgaW50byB0aGlzIGZ1bmN0aW9uIHdpdGhvdXQgc21wX21iIG9wZXJh
dGlvbi4NCg0KVGhhbmtzLA0KSXJhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogSXJhIFcuIFNueWRlciBbbWFpbHRvOml3c0BvdnJvLmNhbHRlY2guZWR1XQ0KPiBTZW50
OiAyMDEx5bm0MTHmnIgyM+aXpSAyOjU5DQo+IFRvOiBTaGkgWHVlbGluLUIyOTIzNw0KPiBDYzog
ZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tOyBMaSBZYW5nLVI1ODQ3MjsgendAemgta2VybmVsLm9y
ZzsgDQo+IHZpbm9kLmtvdWxAaW50ZWwuY29tOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9y
ZzsgDQo+IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRD
SF1bUkZDXSBmc2xkbWE6IGZpeCBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiBieSBvcHRpbWl6aW5n
IHNwaW5sb2NrIHVzZS4NCj4gDQo+IE9uIFR1ZSwgTm92IDIyLCAyMDExIGF0IDEyOjU1OjA1UE0g
KzA4MDAsIGIyOTIzN0BmcmVlc2NhbGUuY29tIHdyb3RlOg0KPiA+IEZyb206IEZvcnJlc3QgU2hp
IDxiMjkyMzdAZnJlZXNjYWxlLmNvbT4NCj4gPiANCj4gPiAgICAgZG1hIHN0YXR1cyBjaGVjayBm
dW5jdGlvbiBmc2xfdHhfc3RhdHVzIGlzIGhlYXZpbHkgY2FsbGVkIGluDQo+ID4gICAgIGEgdGln
aHQgbG9vcCBhbmQgdGhlIGRlc2MgbG9jayBpbiBmc2xfdHhfc3RhdHVzIGNvbnRlbmRlZCBieQ0K
PiA+ICAgICB0aGUgZG1hIHN0YXR1cyB1cGRhdGUgZnVuY3Rpb24uIHRoaXMgY2F1c2VkIHRoZSBk
bWEgcGVyZm9ybWFuY2UNCj4gPiAgICAgZGVncmFkZXMgbXVjaC4NCj4gPiANCj4gPiAgICAgdGhp
cyBwYXRjaCByZWxlYXNlcyB0aGUgbG9jayBpbiB0aGUgZnNsX3R4X3N0YXR1cyBmdW5jdGlvbi4N
Cj4gPiAgICAgSSBiZWxpZXZlIGl0IGhhcyBubyBuZWdsZWN0IGltcGFjdCBvbiB0aGUgZm9sbG93
aW5nIGNhbGwgb2YNCj4gPiAgICAgZG1hX2FzeW5jX2lzX2NvbXBsZXRlKC4uLikuDQo+ID4gDQo+
ID4gICAgIHdlIGNhbiBzZWUgYmVsb3cgdGhyZWUgY29uZGl0aW9ucyB3aWxsIGJlIGlkZW50aWZp
ZWQgYXMgc3VjY2Vzcw0KPiA+ICAgICBhKSAgeCA8IGNvbXBsZXRlIDwgdXNlDQo+ID4gICAgIGIp
ICB4IDwgY29tcGxldGUrTiA8IHVzZStODQo+ID4gICAgIGMpICB4IDwgY29tcGxldGUgPCB1c2Ur
Tg0KPiA+ICAgICBoZXJlIGNvbXBsZXRlIGlzIHRoZSBjb21wbGV0ZWRfY29va2llLCB1c2UgaXMg
dGhlIGxhc3RfdXNlZA0KPiA+ICAgICBjb29raWUsIHggaXMgdGhlIHF1ZXJ5aW5nIGNvb2tpZSwg
TiBpcyBNQVggY29va2llDQo+ID4gDQo+ID4gICAgIHdoZW4gY2hhbi0+Y29tcGxldGVkX2Nvb2tp
ZSBpcyBiZWluZyByZWFkLCB0aGUgbGFzdF91c2VkIG1heQ0KPiA+ICAgICBiZSBpbmNyZXNlZC4g
QW55d2F5IGl0IGhhcyBubyBuZWdsZWN0IGltcGFjdCBvbiB0aGUgZG1hIHN0YXR1cw0KPiA+ICAg
ICBkZWNpc2lvbi4NCj4gPiANCj4gPiAgICAgU2lnbmVkLW9mZi1ieTogRm9ycmVzdCBTaGkgPHh1
ZWxpbi5zaGlAZnJlZXNjYWxlLmNvbT4NCj4gPiAtLS0NCj4gPiAgZHJpdmVycy9kbWEvZnNsZG1h
LmMgfCAgICA1IC0tLS0tDQo+ID4gIDEgZmlsZXMgY2hhbmdlZCwgMCBpbnNlcnRpb25zKCspLCA1
IGRlbGV0aW9ucygtKQ0KPiA+IA0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2RtYS9mc2xkbWEu
YyBiL2RyaXZlcnMvZG1hL2ZzbGRtYS5jIGluZGV4IA0KPiA+IDhhNzgxNTQuLjFkY2E1NmYgMTAw
NjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9kbWEvZnNsZG1hLmMNCj4gPiArKysgYi9kcml2ZXJzL2Rt
YS9mc2xkbWEuYw0KPiA+IEBAIC05ODYsMTUgKzk4NiwxMCBAQCBzdGF0aWMgZW51bSBkbWFfc3Rh
dHVzIGZzbF90eF9zdGF0dXMoc3RydWN0IGRtYV9jaGFuICpkY2hhbiwNCj4gPiAgCXN0cnVjdCBm
c2xkbWFfY2hhbiAqY2hhbiA9IHRvX2ZzbF9jaGFuKGRjaGFuKTsNCj4gPiAgCWRtYV9jb29raWVf
dCBsYXN0X2NvbXBsZXRlOw0KPiA+ICAJZG1hX2Nvb2tpZV90IGxhc3RfdXNlZDsNCj4gPiAtCXVu
c2lnbmVkIGxvbmcgZmxhZ3M7DQo+ID4gLQ0KPiA+IC0Jc3Bpbl9sb2NrX2lycXNhdmUoJmNoYW4t
PmRlc2NfbG9jaywgZmxhZ3MpOw0KPiA+ICANCj4gDQo+IFRoaXMgd2lsbCBjYXVzZSBhIGJ1Zy4g
U2VlIGJlbG93IGZvciBhIGRldGFpbGVkIGV4cGxhbmF0aW9uLiBZb3UgbmVlZCB0aGlzIGluc3Rl
YWQ6DQo+IA0KPiAJLyoNCj4gCSAqIE9uIGFuIFNNUCBzeXN0ZW0sIHdlIG11c3QgZW5zdXJlIHRo
YXQgdGhpcyBDUFUgaGFzIHNlZW4gdGhlDQo+IAkgKiBtZW1vcnkgYWNjZXNzZXMgcGVyZm9ybWVk
IGJ5IGFub3RoZXIgQ1BVIHVuZGVyIHRoZQ0KPiAJICogY2hhbi0+ZGVzY19sb2NrIHNwaW5sb2Nr
Lg0KPiAJICovDQo+IAlzbXBfbWIoKTsNCj4gPiAgCWxhc3RfY29tcGxldGUgPSBjaGFuLT5jb21w
bGV0ZWRfY29va2llOw0KPiA+ICAJbGFzdF91c2VkID0gZGNoYW4tPmNvb2tpZTsNCj4gPiAgDQo+
ID4gLQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZjaGFuLT5kZXNjX2xvY2ssIGZsYWdzKTsNCj4g
PiAtDQo+ID4gIAlkbWFfc2V0X3R4X3N0YXRlKHR4c3RhdGUsIGxhc3RfY29tcGxldGUsIGxhc3Rf
dXNlZCwgMCk7DQo+ID4gIAlyZXR1cm4gZG1hX2FzeW5jX2lzX2NvbXBsZXRlKGNvb2tpZSwgbGFz
dF9jb21wbGV0ZSwgbGFzdF91c2VkKTsgIH0NCj4gDQo+IEZhY3RzOg0KPiAtIGRjaGFuLT5jb29r
aWUgaXMgdGhlIHNhbWUgbWVtYmVyIGFzIGNoYW4tPmNvbW1vbi5jb29raWUgKHNhbWUgbWVtb3J5
IA0KPiBsb2NhdGlvbikNCj4gLSBjaGFuLT5jb21tb24uY29va2llIGlzIHRoZSAibGFzdCBhbGxv
Y2F0ZWQgY29va2llIGZvciBhIHBlbmRpbmcgdHJhbnNhY3Rpb24iDQo+IC0gY2hhbi0+Y29tcGxl
dGVkX2Nvb2tpZSBpcyB0aGUgImxhc3QgY29tcGxldGVkIHRyYW5zYWN0aW9uIg0KPiANCj4gSSBo
YXZlIHJlcGxhY2VkICJkY2hhbi0+Y29va2llIiB3aXRoICJjaGFuLT5jb21tb24uY29va2llIiBp
biB0aGUgYmVsb3cgZXhwbGFuYXRpb24sIHRvIGtlZXAgZXZlcnl0aGluZyByZWZlcmVuY2VkIGZy
b20gdGhlIHNhbWUgc3RydWN0dXJlLg0KPiANCj4gVmFyaWFibGUgdXNhZ2UgYmVmb3JlIHlvdXIg
Y2hhbmdlLiBFdmVyeXRoaW5nIGlzIHVzZWQgbG9ja2VkLg0KPiAtIFJXIGNoYW4tPmNvbW1vbi5j
b29raWUJCShmc2xfZG1hX3R4X3N1Ym1pdCkNCj4gLSBSICBjaGFuLT5jb21tb24uY29va2llCQko
ZnNsX3R4X3N0YXR1cykNCj4gLSBSICBjaGFuLT5jb21wbGV0ZWRfY29va2llCQkoZnNsX3R4X3N0
YXR1cykNCj4gLSBXICBjaGFuLT5jb21wbGV0ZWRfY29va2llCQkoZG1hX2RvX3Rhc2tsZXQpDQo+
IA0KPiBWYXJpYWJsZSB1c2FnZSBhZnRlciB5b3VyIGNoYW5nZToNCj4gLSBSVyBjaGFuLT5jb21t
b24uY29va2llCQlMT0NLRUQNCj4gLSBSICBjaGFuLT5jb21tb24uY29va2llCQlOTyBMT0NLDQo+
IC0gUiAgY2hhbi0+Y29tcGxldGVkX2Nvb2tpZQkJTk8gTE9DSw0KPiAtIFcgIGNoYW4tPmNvbXBs
ZXRlZF9jb29raWUgICAgICAgICAgICAgTE9DS0VEDQo+IA0KPiBXaGF0IGlmIHdlIGFzc3VtZSB0
aGF0IHlvdSBoYXZlIGEgMiBDUFUgc3lzdGVtIChzdWNoIGFzIGEgUDIwMjApLiBBZnRlciB5b3Vy
IGNoYW5nZXMsIG9uZSBwb3NzaWJsZSBzZXF1ZW5jZSBpczoNCj4gDQo+ID09PSBDUFUxIC0gYWxs
b2NhdGUgKyBzdWJtaXQgZGVzY3JpcHRvcjogZnNsX2RtYV90eF9zdWJtaXQoKSA9PT0gDQo+IHNw
aW5fbG9ja19pcnFzYXZlDQo+IGRlc2NyaXB0b3ItPmNvb2tpZSA9IDIwCQkoeCBpbiB5b3VyIGV4
YW1wbGUpDQo+IGNoYW4tPmNvbW1vbi5jb29raWUgPSAyMAkodXNlZCBpbiB5b3VyIGV4YW1wbGUp
DQo+IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUNCj4gDQo+ID09PSBDUFUyIC0gaW1tZWRpYXRlbHkg
Y2FsbHMgZnNsX3R4X3N0YXR1cygpID09PQ0KPiBjaGFuLT5jb21tb24uY29va2llID09IDE5DQo+
IGNoYW4tPmNvbXBsZXRlZF9jb29raWUgPT0gMTkNCj4gZGVzY3JpcHRvci0+Y29va2llID09IDIw
DQo+IA0KPiBTaW5jZSB3ZSBkb24ndCBoYXZlIGxvY2tzIGFueW1vcmUsIENQVTIgbWF5IG5vdCBo
YXZlIHNlZW4gdGhlIHdyaXRlIHRvDQo+IGNoYW4tPmNvbW1vbi5jb29raWUgeWV0Lg0KPiANCj4g
QWxzbyBhc3N1bWUgdGhhdCB0aGUgRE1BIGhhcmR3YXJlIGhhcyBub3Qgc3RhcnRlZCBwcm9jZXNz
aW5nIHRoZSANCj4gdHJhbnNhY3Rpb24geWV0LiBUaGVyZWZvcmUgZG1hX2RvX3Rhc2tsZXQoKSBo
YXMgbm90IGJlZW4gY2FsbGVkLCBhbmQNCj4gY2hhbi0+Y29tcGxldGVkX2Nvb2tpZSBoYXMgbm90
IGJlZW4gdXBkYXRlZC4NCj4gDQo+IEluIHRoaXMgY2FzZSwgZG1hX2FzeW5jX2lzX2NvbXBsZXRl
KCkgKG9uIENQVTIpIHJldHVybnMgRE1BX1NVQ0NFU1MsIGV2ZW4gdGhvdWdoIHRoZSBETUEgb3Bl
cmF0aW9uIGhhcyBub3Qgc3VjY2VlZGVkLiBUaGUgRE1BIG9wZXJhdGlvbiBoYXMgbm90IGV2ZW4g
c3RhcnRlZCB5ZXQhDQo+IA0KPiBUaGUgc21wX21iKCkgZml4ZXMgdGhpcywgc2luY2UgaXQgZm9y
Y2VzIENQVTIgdG8gaGF2ZSBzZWVuIGFsbCBtZW1vcnkgb3BlcmF0aW9ucyB0aGF0IGhhcHBlbmVk
IGJlZm9yZSBDUFUxIHJlbGVhc2VkIHRoZSBzcGlubG9jay4gU3BpbmxvY2tzIGFyZSBpbXBsaWNp
dCBTTVAgbWVtb3J5IGJhcnJpZXJzLg0KPiANCj4gVGhlcmVmb3JlLCB0aGUgYWJvdmUgZXhhbXBs
ZSBiZWNvbWVzOg0KPiBzbXBfbWIoKTsNCj4gY2hhbi0+Y29tbW9uLmNvb2tpZSA9PSAyMA0KPiBj
aGFuLT5jb21wbGV0ZWRfY29va2llID09IDE5DQo+IGRlc2NyaXB0b3ItPmNvb2tpZSA9PSAyMA0K
PiANCj4gVGhlbiBkbWFfYXN5bmNfaXNfY29tcGxldGUoKSByZXR1cm5zIERNQV9JTl9QUk9HUkVT
Uywgd2hpY2ggaXMgY29ycmVjdC4NCj4gDQo+IFRoYW5rcywNCj4gSXJhDQo+IA0KPiANCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTGludXhwcGMt
ZGV2IG1haWxpbmcgbGlzdA0KPiBMaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBodHRw
czovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMtZGV2DQoNCg==
^ permalink raw reply
* RE: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use.
From: Li Yang-R58472 @ 2011-11-29 3:19 UTC (permalink / raw)
To: Ira W. Snyder, Shi Xuelin-B29237
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20111128163814.GA10919@ovro.caltech.edu>
PiBTdWJqZWN0OiBSZTogW1BBVENIXVtSRkNdIGZzbGRtYTogZml4IHBlcmZvcm1hbmNlIGRlZ3Jh
ZGF0aW9uIGJ5IG9wdGltaXppbmcNCj4gc3BpbmxvY2sgdXNlLg0KPiANCj4gT24gVGh1LCBOb3Yg
MjQsIDIwMTEgYXQgMDg6MTI6MjVBTSArMDAwMCwgU2hpIFh1ZWxpbi1CMjkyMzcgd3JvdGU6DQo+
ID4gSGkgSXJhLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCj4gPg0KPiA+IEFm
dGVyIHNlY29uZCB0aG91Z2h0LCBJIHRoaW5rIHlvdXIgc2NlbmFyaW8gbWF5IG5vdCBvY2N1ci4N
Cj4gPiBCZWNhdXNlIHRoZSBjb29raWUgMjAgd2UgcXVlcnkgbXVzdCBiZSByZXR1cm5lZCBieSBm
c2xfZG1hX3R4X3N1Ym1pdCguLi4pIGluDQo+IHByYWN0aWNlLg0KPiA+IFdlIG5ldmVyIHF1ZXJ5
IGEgY29va2llIG5vdCByZXR1cm5lZCBieSBmc2xfZG1hX3R4X3N1Ym1pdCguLi4pLg0KPiA+DQo+
IA0KPiBJIGFncmVlIGFib3V0IHRoaXMgcGFydC4NCj4gDQo+ID4gV2hlbiB3ZSBjYWxsIGZzbF90
eF9zdGF0dXMoMjApLCB0aGUgY2hhbi0+Y29tbW9uLmNvb2tpZSBpcyBkZWZpbml0ZWx5IHdyb3Rl
IGFzDQo+IDIwIGFuZCBjcHUyIGNvdWxkIG5vdCByZWFkIGFzIDE5Lg0KPiA+DQo+IA0KPiBUaGlz
IGlzIHdoYXQgSSBkb24ndCBhZ3JlZSBhYm91dC4gSG93ZXZlciwgSSdtIG5vdCBhbiBleHBlcnQg
b24gQ1BVIGNhY2hlIHZzLg0KPiBtZW1vcnkgYWNjZXNzZXMgaW4gYW4gbXVsdGktcHJvY2Vzc29y
IHN5c3RlbS4gVGhlIHNlY3Rpb24gdGl0bGVkICJDQUNIRQ0KPiBDT0hFUkVOQ1kiIGluIERvY3Vt
ZW50YXRpb24vbWVtb3J5LWJhcnJpZXJzLnR4dCBsZWFkcyBtZSB0byBiZWxpZXZlIHRoYXQgdGhl
DQo+IHNjZW5hcmlvIEkgZGVzY3JpYmVkIGlzIHBvc3NpYmxlLg0KDQpGb3IgRnJlZXNjYWxlIFBv
d2VyUEMsIHRoZSBjaGlwIGF1dG9tYXRpY2FsbHkgdGFrZXMgY2FyZSBvZiBjYWNoZSBjb2hlcmVu
Y3kuICBFdmVuIGlmIHRoaXMgaXMgYSBjb25jZXJuLCBzcGlubG9jayBjYW4ndCBhZGRyZXNzIGl0
Lg0KDQo+IA0KPiBXaGF0IGhhcHBlbnMgaWYgQ1BVMSdzIHdyaXRlIG9mIGNoYW4tPmNvbW1vbi5j
b29raWUgb25seSBnb2VzIGludG8gQ1BVMSdzDQo+IGNhY2hlLiBJdCBuZXZlciBtYWtlcyBpdCB0
byBtYWluIG1lbW9yeSBiZWZvcmUgQ1BVMiBmZXRjaGVzIHRoZSBvbGQgdmFsdWUgb2YgMTkuDQo+
IA0KPiBJIGRvbid0IHRoaW5rIHlvdSBzaG91bGQgc2VlIGFueSBwZXJmb3JtYW5jZSBpbXBhY3Qg
ZnJvbSB0aGUgc21wX21iKCkNCj4gb3BlcmF0aW9uLg0KDQpTbXBfbWIoKSBkbyBoYXZlIGltcGFj
dCBvbiBwZXJmb3JtYW5jZSBpZiBpdCdzIGluIHRoZSBob3QgcGF0aC4gIFdoaWxlIGl0IG1pZ2h0
IGJlIHNhZmVyIGhhdmluZyBpdCwgSSBkb3VidCBpdCBpcyByZWFsbHkgbmVjZXNzYXJ5LiAgSWYg
dGhlIENQVTEgZG9lc24ndCBoYXZlIHRoZSB1cGRhdGVkIGxhc3RfdXNlZCwgaXQncyBzaG91bGRu
J3QgaGF2ZSBrbm93biB0aGVyZSBpcyBhIGNvb2tpZSAyMCBleGlzdGVkIGVpdGhlci4NCg0KLSBM
ZW8NCg0KPiANCj4gVGhhbmtzLA0KPiBJcmENCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCj4gPiBGcm9tOiBJcmEgVy4gU255ZGVyIFttYWlsdG86aXdzQG92cm8uY2FsdGVjaC5l
ZHVdDQo+ID4gU2VudDogMjAxMeW5tDEx5pyIMjPml6UgMjo1OQ0KPiA+IFRvOiBTaGkgWHVlbGlu
LUIyOTIzNw0KPiA+IENjOiBkYW4uai53aWxsaWFtc0BpbnRlbC5jb207IExpIFlhbmctUjU4NDcy
OyB6d0B6aC1rZXJuZWwub3JnOw0KPiA+IHZpbm9kLmtvdWxAaW50ZWwuY29tOyBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gPiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+
ID4gU3ViamVjdDogUmU6IFtQQVRDSF1bUkZDXSBmc2xkbWE6IGZpeCBwZXJmb3JtYW5jZSBkZWdy
YWRhdGlvbiBieSBvcHRpbWl6aW5nDQo+IHNwaW5sb2NrIHVzZS4NCj4gPg0KPiA+IE9uIFR1ZSwg
Tm92IDIyLCAyMDExIGF0IDEyOjU1OjA1UE0gKzA4MDAsIGIyOTIzN0BmcmVlc2NhbGUuY29tIHdy
b3RlOg0KPiA+ID4gRnJvbTogRm9ycmVzdCBTaGkgPGIyOTIzN0BmcmVlc2NhbGUuY29tPg0KPiA+
ID4NCj4gPiA+ICAgICBkbWEgc3RhdHVzIGNoZWNrIGZ1bmN0aW9uIGZzbF90eF9zdGF0dXMgaXMg
aGVhdmlseSBjYWxsZWQgaW4NCj4gPiA+ICAgICBhIHRpZ2h0IGxvb3AgYW5kIHRoZSBkZXNjIGxv
Y2sgaW4gZnNsX3R4X3N0YXR1cyBjb250ZW5kZWQgYnkNCj4gPiA+ICAgICB0aGUgZG1hIHN0YXR1
cyB1cGRhdGUgZnVuY3Rpb24uIHRoaXMgY2F1c2VkIHRoZSBkbWEgcGVyZm9ybWFuY2UNCj4gPiA+
ICAgICBkZWdyYWRlcyBtdWNoLg0KPiA+ID4NCj4gPiA+ICAgICB0aGlzIHBhdGNoIHJlbGVhc2Vz
IHRoZSBsb2NrIGluIHRoZSBmc2xfdHhfc3RhdHVzIGZ1bmN0aW9uLg0KPiA+ID4gICAgIEkgYmVs
aWV2ZSBpdCBoYXMgbm8gbmVnbGVjdCBpbXBhY3Qgb24gdGhlIGZvbGxvd2luZyBjYWxsIG9mDQo+
ID4gPiAgICAgZG1hX2FzeW5jX2lzX2NvbXBsZXRlKC4uLikuDQo+ID4gPg0KPiA+ID4gICAgIHdl
IGNhbiBzZWUgYmVsb3cgdGhyZWUgY29uZGl0aW9ucyB3aWxsIGJlIGlkZW50aWZpZWQgYXMgc3Vj
Y2Vzcw0KPiA+ID4gICAgIGEpICB4IDwgY29tcGxldGUgPCB1c2UNCj4gPiA+ICAgICBiKSAgeCA8
IGNvbXBsZXRlK04gPCB1c2UrTg0KPiA+ID4gICAgIGMpICB4IDwgY29tcGxldGUgPCB1c2UrTg0K
PiA+ID4gICAgIGhlcmUgY29tcGxldGUgaXMgdGhlIGNvbXBsZXRlZF9jb29raWUsIHVzZSBpcyB0
aGUgbGFzdF91c2VkDQo+ID4gPiAgICAgY29va2llLCB4IGlzIHRoZSBxdWVyeWluZyBjb29raWUs
IE4gaXMgTUFYIGNvb2tpZQ0KPiA+ID4NCj4gPiA+ICAgICB3aGVuIGNoYW4tPmNvbXBsZXRlZF9j
b29raWUgaXMgYmVpbmcgcmVhZCwgdGhlIGxhc3RfdXNlZCBtYXkNCj4gPiA+ICAgICBiZSBpbmNy
ZXNlZC4gQW55d2F5IGl0IGhhcyBubyBuZWdsZWN0IGltcGFjdCBvbiB0aGUgZG1hIHN0YXR1cw0K
PiA+ID4gICAgIGRlY2lzaW9uLg0KPiA+ID4NCj4gPiA+ICAgICBTaWduZWQtb2ZmLWJ5OiBGb3Jy
ZXN0IFNoaSA8eHVlbGluLnNoaUBmcmVlc2NhbGUuY29tPg0KPiA+ID4gLS0tDQo+ID4gPiAgZHJp
dmVycy9kbWEvZnNsZG1hLmMgfCAgICA1IC0tLS0tDQo+ID4gPiAgMSBmaWxlcyBjaGFuZ2VkLCAw
IGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pDQo+ID4gPg0KPiA+ID4gZGlmZiAtLWdpdCBh
L2RyaXZlcnMvZG1hL2ZzbGRtYS5jIGIvZHJpdmVycy9kbWEvZnNsZG1hLmMgaW5kZXgNCj4gPiA+
IDhhNzgxNTQuLjFkY2E1NmYgMTAwNjQ0DQo+ID4gPiAtLS0gYS9kcml2ZXJzL2RtYS9mc2xkbWEu
Yw0KPiA+ID4gKysrIGIvZHJpdmVycy9kbWEvZnNsZG1hLmMNCj4gPiA+IEBAIC05ODYsMTUgKzk4
NiwxMCBAQCBzdGF0aWMgZW51bSBkbWFfc3RhdHVzIGZzbF90eF9zdGF0dXMoc3RydWN0DQo+IGRt
YV9jaGFuICpkY2hhbiwNCj4gPiA+ICAJc3RydWN0IGZzbGRtYV9jaGFuICpjaGFuID0gdG9fZnNs
X2NoYW4oZGNoYW4pOw0KPiA+ID4gIAlkbWFfY29va2llX3QgbGFzdF9jb21wbGV0ZTsNCj4gPiA+
ICAJZG1hX2Nvb2tpZV90IGxhc3RfdXNlZDsNCj4gPiA+IC0JdW5zaWduZWQgbG9uZyBmbGFnczsN
Cj4gPiA+IC0NCj4gPiA+IC0Jc3Bpbl9sb2NrX2lycXNhdmUoJmNoYW4tPmRlc2NfbG9jaywgZmxh
Z3MpOw0KPiA+ID4NCj4gPg0KPiA+IFRoaXMgd2lsbCBjYXVzZSBhIGJ1Zy4gU2VlIGJlbG93IGZv
ciBhIGRldGFpbGVkIGV4cGxhbmF0aW9uLiBZb3UgbmVlZCB0aGlzIGluc3RlYWQ6DQo+ID4NCj4g
PiAJLyoNCj4gPiAJICogT24gYW4gU01QIHN5c3RlbSwgd2UgbXVzdCBlbnN1cmUgdGhhdCB0aGlz
IENQVSBoYXMgc2VlbiB0aGUNCj4gPiAJICogbWVtb3J5IGFjY2Vzc2VzIHBlcmZvcm1lZCBieSBh
bm90aGVyIENQVSB1bmRlciB0aGUNCj4gPiAJICogY2hhbi0+ZGVzY19sb2NrIHNwaW5sb2NrLg0K
PiA+IAkgKi8NCj4gPiAJc21wX21iKCk7DQo+ID4gPiAgCWxhc3RfY29tcGxldGUgPSBjaGFuLT5j
b21wbGV0ZWRfY29va2llOw0KPiA+ID4gIAlsYXN0X3VzZWQgPSBkY2hhbi0+Y29va2llOw0KPiA+
ID4NCj4gPiA+IC0Jc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2hhbi0+ZGVzY19sb2NrLCBmbGFn
cyk7DQo+ID4gPiAtDQo+ID4gPiAgCWRtYV9zZXRfdHhfc3RhdGUodHhzdGF0ZSwgbGFzdF9jb21w
bGV0ZSwgbGFzdF91c2VkLCAwKTsNCj4gPiA+ICAJcmV0dXJuIGRtYV9hc3luY19pc19jb21wbGV0
ZShjb29raWUsIGxhc3RfY29tcGxldGUsIGxhc3RfdXNlZCk7ICB9DQo+ID4NCj4gPiBGYWN0czoN
Cj4gPiAtIGRjaGFuLT5jb29raWUgaXMgdGhlIHNhbWUgbWVtYmVyIGFzIGNoYW4tPmNvbW1vbi5j
b29raWUgKHNhbWUgbWVtb3J5DQo+ID4gbG9jYXRpb24pDQo+ID4gLSBjaGFuLT5jb21tb24uY29v
a2llIGlzIHRoZSAibGFzdCBhbGxvY2F0ZWQgY29va2llIGZvciBhIHBlbmRpbmcgdHJhbnNhY3Rp
b24iDQo+ID4gLSBjaGFuLT5jb21wbGV0ZWRfY29va2llIGlzIHRoZSAibGFzdCBjb21wbGV0ZWQg
dHJhbnNhY3Rpb24iDQo+ID4NCj4gPiBJIGhhdmUgcmVwbGFjZWQgImRjaGFuLT5jb29raWUiIHdp
dGggImNoYW4tPmNvbW1vbi5jb29raWUiIGluIHRoZSBiZWxvdw0KPiBleHBsYW5hdGlvbiwgdG8g
a2VlcCBldmVyeXRoaW5nIHJlZmVyZW5jZWQgZnJvbSB0aGUgc2FtZSBzdHJ1Y3R1cmUuDQo+ID4N
Cj4gPiBWYXJpYWJsZSB1c2FnZSBiZWZvcmUgeW91ciBjaGFuZ2UuIEV2ZXJ5dGhpbmcgaXMgdXNl
ZCBsb2NrZWQuDQo+ID4gLSBSVyBjaGFuLT5jb21tb24uY29va2llCQkoZnNsX2RtYV90eF9zdWJt
aXQpDQo+ID4gLSBSICBjaGFuLT5jb21tb24uY29va2llCQkoZnNsX3R4X3N0YXR1cykNCj4gPiAt
IFIgIGNoYW4tPmNvbXBsZXRlZF9jb29raWUJCShmc2xfdHhfc3RhdHVzKQ0KPiA+IC0gVyAgY2hh
bi0+Y29tcGxldGVkX2Nvb2tpZQkJKGRtYV9kb190YXNrbGV0KQ0KPiA+DQo+ID4gVmFyaWFibGUg
dXNhZ2UgYWZ0ZXIgeW91ciBjaGFuZ2U6DQo+ID4gLSBSVyBjaGFuLT5jb21tb24uY29va2llCQlM
T0NLRUQNCj4gPiAtIFIgIGNoYW4tPmNvbW1vbi5jb29raWUJCU5PIExPQ0sNCj4gPiAtIFIgIGNo
YW4tPmNvbXBsZXRlZF9jb29raWUJCU5PIExPQ0sNCj4gPiAtIFcgIGNoYW4tPmNvbXBsZXRlZF9j
b29raWUgICAgICAgICAgICAgTE9DS0VEDQo+ID4NCj4gPiBXaGF0IGlmIHdlIGFzc3VtZSB0aGF0
IHlvdSBoYXZlIGEgMiBDUFUgc3lzdGVtIChzdWNoIGFzIGEgUDIwMjApLiBBZnRlciB5b3VyDQo+
IGNoYW5nZXMsIG9uZSBwb3NzaWJsZSBzZXF1ZW5jZSBpczoNCj4gPg0KPiA+ID09PSBDUFUxIC0g
YWxsb2NhdGUgKyBzdWJtaXQgZGVzY3JpcHRvcjogZnNsX2RtYV90eF9zdWJtaXQoKSA9PT0NCj4g
PiBzcGluX2xvY2tfaXJxc2F2ZQ0KPiA+IGRlc2NyaXB0b3ItPmNvb2tpZSA9IDIwCQkoeCBpbiB5
b3VyIGV4YW1wbGUpDQo+ID4gY2hhbi0+Y29tbW9uLmNvb2tpZSA9IDIwCSh1c2VkIGluIHlvdXIg
ZXhhbXBsZSkNCj4gPiBzcGluX3VubG9ja19pcnFyZXN0b3JlDQo+ID4NCj4gPiA9PT0gQ1BVMiAt
IGltbWVkaWF0ZWx5IGNhbGxzIGZzbF90eF9zdGF0dXMoKSA9PT0NCj4gPiBjaGFuLT5jb21tb24u
Y29va2llID09IDE5DQo+ID4gY2hhbi0+Y29tcGxldGVkX2Nvb2tpZSA9PSAxOQ0KPiA+IGRlc2Ny
aXB0b3ItPmNvb2tpZSA9PSAyMA0KPiA+DQo+ID4gU2luY2Ugd2UgZG9uJ3QgaGF2ZSBsb2NrcyBh
bnltb3JlLCBDUFUyIG1heSBub3QgaGF2ZSBzZWVuIHRoZSB3cml0ZSB0bw0KPiA+IGNoYW4tPmNv
bW1vbi5jb29raWUgeWV0Lg0KPiA+DQo+ID4gQWxzbyBhc3N1bWUgdGhhdCB0aGUgRE1BIGhhcmR3
YXJlIGhhcyBub3Qgc3RhcnRlZCBwcm9jZXNzaW5nIHRoZQ0KPiA+IHRyYW5zYWN0aW9uIHlldC4g
VGhlcmVmb3JlIGRtYV9kb190YXNrbGV0KCkgaGFzIG5vdCBiZWVuIGNhbGxlZCwgYW5kDQo+ID4g
Y2hhbi0+Y29tcGxldGVkX2Nvb2tpZSBoYXMgbm90IGJlZW4gdXBkYXRlZC4NCj4gPg0KPiA+IElu
IHRoaXMgY2FzZSwgZG1hX2FzeW5jX2lzX2NvbXBsZXRlKCkgKG9uIENQVTIpIHJldHVybnMgRE1B
X1NVQ0NFU1MsIGV2ZW4NCj4gdGhvdWdoIHRoZSBETUEgb3BlcmF0aW9uIGhhcyBub3Qgc3VjY2Vl
ZGVkLiBUaGUgRE1BIG9wZXJhdGlvbiBoYXMgbm90IGV2ZW4NCj4gc3RhcnRlZCB5ZXQhDQo+ID4N
Cj4gPiBUaGUgc21wX21iKCkgZml4ZXMgdGhpcywgc2luY2UgaXQgZm9yY2VzIENQVTIgdG8gaGF2
ZSBzZWVuIGFsbCBtZW1vcnkgb3BlcmF0aW9ucw0KPiB0aGF0IGhhcHBlbmVkIGJlZm9yZSBDUFUx
IHJlbGVhc2VkIHRoZSBzcGlubG9jay4gU3BpbmxvY2tzIGFyZSBpbXBsaWNpdCBTTVANCj4gbWVt
b3J5IGJhcnJpZXJzLg0KPiA+DQo+ID4gVGhlcmVmb3JlLCB0aGUgYWJvdmUgZXhhbXBsZSBiZWNv
bWVzOg0KPiA+IHNtcF9tYigpOw0KPiA+IGNoYW4tPmNvbW1vbi5jb29raWUgPT0gMjANCj4gPiBj
aGFuLT5jb21wbGV0ZWRfY29va2llID09IDE5DQo+ID4gZGVzY3JpcHRvci0+Y29va2llID09IDIw
DQo+ID4NCj4gPiBUaGVuIGRtYV9hc3luY19pc19jb21wbGV0ZSgpIHJldHVybnMgRE1BX0lOX1BS
T0dSRVNTLCB3aGljaCBpcyBjb3JyZWN0Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IElyYQ0KPiA+
DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiA+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gPiBMaW51eHBwYy1kZXZAbGlzdHMu
b3psYWJzLm9yZw0KPiA+IGh0dHBzOi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9saW51eHBw
Yy1kZXYNCg0K
^ permalink raw reply
* Re: sam460ex, sm501 incorrect device id with kernel >=linux-2.6.39
From: acrux_it @ 2011-11-29 1:00 UTC (permalink / raw)
To: agust; +Cc: linuxppc-dev
>Da: agust@denx.de
>Data: 28/11/2011 21.22
>A: "acrux"<acrux_it@libero.it>
>Cc: "Josh Boyer"<jwboyer@gmail.com>, <linuxppc-dev@lists.ozlabs.org>
>Ogg: Re: sam460ex, sm501 incorrect device id with kernel >=linux-2.6.39
>
>On Mon, 28 Nov 2011 20:56:55 +0100
>acrux <acrux_it@libero.it> wrote:
>...
>> it seems to be an endianess issue but i didn't find when it was
>> introduced. Really strange this kind of issue was never noticed
>> bumping from 2.6.38.x to 2.6.39.x .
>
>Look at commit bf5f0019046d596d613caf74722ba4994e153899
>(video, sm501: add I/O functions for use on powerpc).
>This is the issue, I think. Especially changes in include/linux/sm501.h
>by this commit. Since CONFIG_PPC32 is defined for canyonlands,
>ioread32be() is used to access the registers at PCI space which
>is wrong. The patch was tested on tqm5200 with sm501 connected
>on localbus, so using ioread32be() worked there. Your sm502 is on
>PCI bus I suppose. This issue needs to be fixed.
>
>HTH,
>Anatolij
>
hallo Anatolij,
you are absolutely right altought i don't have a skill to fix it.
Indeed, this SM502 is located on PCI bus. Here a schema:
http://oi39.tinypic.com/34r9mw2.jpg
cheers,
--nico
^ permalink raw reply
* [PATCH] powerpc/book3e: Change hugetlb preload to take vma argument
From: Becky Bruce @ 2011-11-29 0:43 UTC (permalink / raw)
To: linuxppc-dev
From: Becky Bruce <beckyb@kernel.crashing.org>
This avoids an extra find_vma() and is less error-prone.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
arch/powerpc/include/asm/hugetlb.h | 3 ++-
arch/powerpc/mm/hugetlbpage-book3e.c | 8 ++++++--
arch/powerpc/mm/mem.c | 2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h
index 555044c..863f49d 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -52,7 +52,8 @@ static inline int is_hugepage_only_range(struct mm_struct *mm,
}
#endif
-void book3e_hugetlb_preload(struct mm_struct *mm, unsigned long ea, pte_t pte);
+void book3e_hugetlb_preload(struct vm_area_struct *vma, unsigned long ea,
+ pte_t pte);
void flush_hugetlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
void hugetlb_free_pgd_range(struct mmu_gather *tlb, unsigned long addr,
diff --git a/arch/powerpc/mm/hugetlbpage-book3e.c b/arch/powerpc/mm/hugetlbpage-book3e.c
index 4d6d849..3bc7006 100644
--- a/arch/powerpc/mm/hugetlbpage-book3e.c
+++ b/arch/powerpc/mm/hugetlbpage-book3e.c
@@ -37,12 +37,14 @@ static inline int book3e_tlb_exists(unsigned long ea, unsigned long pid)
return found;
}
-void book3e_hugetlb_preload(struct mm_struct *mm, unsigned long ea, pte_t pte)
+void book3e_hugetlb_preload(struct vm_area_struct *vma, unsigned long ea,
+ pte_t pte)
{
unsigned long mas1, mas2;
u64 mas7_3;
unsigned long psize, tsize, shift;
unsigned long flags;
+ struct mm_struct *mm;
#ifdef CONFIG_PPC_FSL_BOOK3E
int index, ncams;
@@ -51,12 +53,14 @@ void book3e_hugetlb_preload(struct mm_struct *mm, unsigned long ea, pte_t pte)
if (unlikely(is_kernel_addr(ea)))
return;
+ mm = vma->vm_mm;
+
#ifdef CONFIG_PPC_MM_SLICES
psize = get_slice_psize(mm, ea);
tsize = mmu_get_tsize(psize);
shift = mmu_psize_defs[psize].shift;
#else
- psize = vma_mmu_pagesize(find_vma(mm, ea));
+ psize = vma_mmu_pagesize(vma);
shift = __ilog2(psize);
tsize = shift - 10;
#endif
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 4dbc388..846065c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -552,6 +552,6 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
#if (defined(CONFIG_PPC_BOOK3E_64) || defined(CONFIG_PPC_FSL_BOOK3E)) \
&& defined(CONFIG_HUGETLB_PAGE)
if (is_vm_hugetlb_page(vma))
- book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
+ book3e_hugetlb_preload(vma, address, *ptep);
#endif
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 2/6] powerpc/85xx: consolidate of_platform_bus_probe calls
From: Tabi Timur-B04825 @ 2011-11-28 23:42 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1321552581-29773-2-git-send-email-dbaryshkov@gmail.com>
On Thu, Nov 17, 2011 at 11:56 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platfo=
rms/85xx/p1022_ds.c
> index 00d93a4..cacb4d4 100644
> --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> @@ -330,10 +330,6 @@ static void __init p1022_ds_setup_arch(void)
> =A0}
>
> =A0static struct of_device_id __initdata p1022_ds_ids[] =3D {
> - =A0 =A0 =A0 { .type =3D "soc", },
> - =A0 =A0 =A0 { .compatible =3D "soc", },
> - =A0 =A0 =A0 { .compatible =3D "simple-bus", },
> - =A0 =A0 =A0 { .compatible =3D "gianfar", },
> =A0 =A0 =A0 =A0/* So that the DMA channel nodes can be probed individuall=
y: */
> =A0 =A0 =A0 =A0{ .compatible =3D "fsl,eloplus-dma", },
> =A0 =A0 =A0 =A0{},
> @@ -343,6 +339,7 @@ static int __init p1022_ds_publish_devices(void)
> =A0{
> =A0 =A0 =A0 =A0return of_platform_bus_probe(NULL, p1022_ds_ids, NULL);
> =A0}
> +machine_device_initcall(p1022_ds, mpc85xx_common_publish_devices);
> =A0machine_device_initcall(p1022_ds, p1022_ds_publish_devices);
I don't think this is working. =A0I need to investigate some more to be
sure, but it looks like this is not picking up "fsl,eloplus-dma".
None of the DMA channels are being probed in the audio driver
(sound/soc/fsl_dma.c).
--
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Miche Baker-Harvey @ 2011-11-28 23:40 UTC (permalink / raw)
To: Amit Shah
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Mike Waychison,
ppc-dev, Greg Kroah-Hartman, Eric Northrup
In-Reply-To: <20111123103852.GG16665@amit-x200.redhat.com>
Amit,
You said that the work would be serialized "due to port additions
being on work items on the same workqueue". I'm not seeing that.
I've double checked this by using a mutex_trylock in
hvc_console::hvc_alloc(), and here's the relevant output from dmesg:
root@myubuntu:~# dmesg | grep MBH
[3307216.210274] MBH: got hvc_ports_mutex
[3307216.210690] MBH: trylock of hvc_ports_mutex failed
[3307216.211143] MBH: got hvc_ports_mutex
This is in a system with two virtio console ports, each of which is a
console. I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
were actually being serialized, the trylock should never fail.
What's the source of the serialization for the workqueue items? At
first reading it looks like the control_work_handler gets called for
each virtio interrupt?
Miche
On Wed, Nov 23, 2011 at 2:38 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Thu) 17 Nov 2011 [10:57:37], Miche Baker-Harvey wrote:
>> Rusty, Michael, Stephen, et al,
>>
>> Thanks for your comments on these patches.
>>
>> For what I'm trying to do, all three patches are necessary, but maybe
>> I'm going about it the wrong way. Your input would be appreciated.
>> I'm in no way claiming that these patches are "right", just that it's
>> working for me, and that what's in the current pool is not.
>>
>> What I'm trying to do is:
>> On X86,
>> under KVM,
>> start a virtio console device,
>> with multiple ports on the device,
>> at least one of which is also a console (as well as ttyS0).
>>
>> (Eventually, we want to be able to add virtio console ports on the
>> fly, and to have multiple virtio console ports be consoles.)
>
> Are you using kvm-tool to do this? =A0QEMU can already hot-plug ports
> and virtio-console (virtio-serial) devices.
>
>> When all three of the patches are in place, this works great. (By
>> great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
>> and console output goes to ttyS0 and to hvc0.
>> "who" shows three users: =A0ttyS0, hvc0, and hvc1.
>> "cat /proc/consoles" shows both ttyS0 and hvc0.
>> I can use all three getty's, and console output really does appear on
>> both the consoles.
>>
>> Based on Rusty's comments, I tried removing each of the patches
>> individually. Here's what happens today. I've seen other failure modes
>> depending on what precisely I'm passing the guest.
>> There's three patches:
>> 1/3 "fix locking of vtermno"
>> 2/3 "enforce one-time initialization with hvc_init
>> "3/3 "use separate struct console * for each console"
>>
>> If I remove the "fix locking of vtermno", I only get one virtio
>> console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
>> into the gettys on both. I don't get the second virtio console getty.
>> Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
>> console output is dumped twice to hvc0 (as you'd expect from looking
>> at printk.c, each line appears twice, followed by the next line.)
>
> I don't really understand why. =A0"fix locking of vtermno" adds locks in
> init_port_console(), which is called from add_port(), which should be
> serialised due to port additions being on work items on the same
> workqueue. =A0I don't see a race here.
>
>> If I remove the "enforce one-time initialization with hvc_init" patch,
>> which makes sure only a single thread is doing the hvc_init, and gates
>> anyone from continuing until it has completed, I get different
>> failures, including hangs, and dereferences of NULL pointers.
>>
>> If I remove the "use separate struct console * for each console"patch,
>> what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
>> present with gettys running on them, of the three, only ttyS0 is a
>> console.
>
> I don't see any difference in my testing with and without these
> patches.
>
> This is how I tested with qemu:
>
> ./x86_64-softmmu/qemu-system-x86_64 -m 512 -smp 2 -chardev
> socket,path=3D/tmp/foo,server,nowait,id=3Dfoo -chardev
> socket,path=3D/tmp/bar,server,nowait,id=3Dbar -device virtio-serial
> -device virtconsole,chardev=3Dfoo,nr=3D4 -device
> virtconsole,chardev=3Dbar,nr=3D3 -net none =A0-kernel
> /home/amit/src/linux/arch/x86/boot/bzImage -append 'root=3D/dev/sda1
> console=3Dtty0 console=3DttyS0' -initrd /tmp/initramfs.img
> /guests/f14-nolvm.qcow2 -enable-kvm -snapshot
>
> With this setup, with and without patches, I can spawn two consoles
> via:
>
> /sbin/agetty /dev/hvc0 9600 vt100
> /sbin/agetty /dev/hvc1 9600 vt100
>
> (Strange thing is, the second one gives a 'password incorrect' error
> on login attempts, while the first one logs in fine. =A0I do remember
> testing multiple consoles just fine a year and a half back, so no idea
> why this isn't behaving as expected -- but it mostly looks like a
> userspace issue rather than kernel one.)
>
> As mentioned earlier, I've not looked at the hvc code, but given my
> testing results, I'd like to first understand what you're seeing and
> what your environment is.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/time: Use clocksource_register_hz
From: john stultz @ 2011-11-28 23:30 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev, miltonm
In-Reply-To: <20111124060847.282144743@samba.org>
On Thu, 2011-11-24 at 17:07 +1100, Anton Blanchard wrote:
> plain text document attachment (clock3)
> Use clocksource_register_hz which calculates the shift/mult
> factors for us. Also remove the shift = 22 assumption in
> vsyscall_update - thanks to Paul Mackerras and John Stultz for
> catching that.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: linux-build/arch/powerpc/kernel/time.c
> ===================================================================
> --- linux-build.orig/arch/powerpc/kernel/time.c 2011-11-17 10:11:51.175038860 +1100
> +++ linux-build/arch/powerpc/kernel/time.c 2011-11-17 10:11:55.547114957 +1100
> @@ -86,8 +86,6 @@ static struct clocksource clocksource_rt
> .rating = 400,
> .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> .mask = CLOCKSOURCE_MASK(64),
> - .shift = 22,
> - .mult = 0, /* To be filled in */
> .read = rtc_read,
> };
>
> @@ -97,8 +95,6 @@ static struct clocksource clocksource_ti
> .rating = 400,
> .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> .mask = CLOCKSOURCE_MASK(64),
> - .shift = 22,
> - .mult = 0, /* To be filled in */
> .read = timebase_read,
> };
>
> @@ -822,9 +818,8 @@ void update_vsyscall(struct timespec *wa
> ++vdso_data->tb_update_count;
> smp_mb();
>
> - /* XXX this assumes clock->shift == 22 */
> - /* 4611686018 ~= 2^(20+64-22) / 1e9 */
> - new_tb_to_xs = (u64) mult * 4611686018ULL;
> + /* 19342813113834067 ~= 2^(20+64) / 1e9 */
> + new_tb_to_xs = (u64) mult * (19342813113834067ULL >> clock->shift);
I never verified the math on this, but assuming Paul had it right, this
patch looks good!
Acked-by: John Stultz <johnstul@us.ibm.com>
Thanks again!
-john
^ permalink raw reply
* Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
From: Scott Wood @ 2011-11-28 22:59 UTC (permalink / raw)
To: Josh Boyer
Cc: Josh Poimboeuf, David Laight, Alan Modra, Suzuki K. Poulose,
linuxppc-dev
In-Reply-To: <CA+5PVA6uVpB6XUFkjUABJCcVjubFiWWEQgmuMijTQpdAiN7PdQ@mail.gmail.com>
On 11/23/2011 10:47 AM, Josh Boyer wrote:
> On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose <suzuki@in.ibm.com> wrote:
>> The current implementation of CONFIG_RELOCATABLE in BookE is based
>> on mapping the page aligned kernel load address to KERNELBASE. This
>> approach however is not enough for platforms, where the TLB page size
>> is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used
>> currently in BookE to DYNAMIC_MEMSTART to reflect the actual method.
Should reword the config help to make it clear what the alignment
restriction is, or where to find the information for a particular
platform. Someone reading "page aligned" without any context that we're
talking about special large pages is going to think 4K -- and on e500,
many large page sizes are supported, so the required alignment is found
in Linux init code rather than a CPU manual.
>>
>> The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the
>> dynamic relocations will be introduced in the later in the patch series.
>>
>> This change would allow the use of the old method of RELOCATABLE for
>> platforms which can afford to enforce the page alignment (platforms with
>> smaller TLB size).
>
> I'm OK with the general direction, but this touches a lot of non-4xx
> code. I'd prefer it if Ben took this directly on whatever final
> solution is done.
>
>> I haven tested this change only on 440x. I don't have an FSL BookE to verify
>> the changes there.
>>
>> Scott,
>> Could you please test this patch on FSL and let me know the results ?
>
> Scott, did you ever get around to testing this? In my opinion, this
> shouldn't go in without a Tested-by: from someone that tried it on an
> FSL platform.
Booted OK for me on e500v2 with RAM starting at 256M.
Tested-by: Scott Wood <scottwood@freescale.com>
> We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for
> 64-bit. Then throughout almost the rest of the patch, all we're doing
> is duplicating what RELOCATABLE already did (e.g. if ! either thing).
> It works, but it is kind of ugly.
>
> Instead, could we define a helper config variable that can be used in
> place of that construct? Something like:
>
> config NONSTATIC_KERNEL (or whatever)
> bool
> default n
>
> ...
>
> config DYNAMIC_MEMSTART
> <blah>
> select NONSTATIC_KERNEL
>
> ...
>
> config RELOCATABLE
> <blah>
> select NONSTATIC_KERNEL
I agree.
-Scott
^ permalink raw reply
* Re: [PATCH 03/13] powerpc: Fix booke hugetlb preload code for PPC_MM_SLICES and 64-bit
From: Benjamin Herrenschmidt @ 2011-11-28 22:50 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798681100-git-send-email-beckyb@kernel.crashing.org>
> return;
>
> #ifdef CONFIG_PPC_MM_SLICES
> - psize = mmu_get_tsize(get_slice_psize(mm, ea));
> - tsize = mmu_get_psize(psize);
> + psize = get_slice_psize(mm, ea);
> + tsize = mmu_get_tsize(psize);
> shift = mmu_psize_defs[psize].shift;
> #else
> - vma = find_vma(mm, ea);
> - psize = vma_mmu_pagesize(vma); /* returns actual size in bytes */
> - asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (psize));
> - shift = 31 - lz;
> - tsize = 21 - lz;
> + psize = vma_mmu_pagesize(find_vma(mm, ea));
> + shift = __ilog2(psize);
> + tsize = shift - 10;
> #endif
>
BTW. Can you remind me what is the business with slices vs. no slices on
Book3E ?
I'd like to avoid having to build separate kernels for A2 vs. FSL ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-11-28 21:49 UTC (permalink / raw)
To: LiuShuo
Cc: Artem Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd, akpm,
David Woodhouse
In-Reply-To: <4ED401B3.1020001@freescale.com>
On 11/28/2011 03:48 PM, Scott Wood wrote:
> On 11/23/2011 06:41 PM, b35362@freescale.com wrote:
>> From: Liu Shuo <b35362@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
>> to support the Nand flash chip whose page size is larger than 2K bytes,
>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
>> them to a large buffer.
>>
>> Signed-off-by: Liu Shuo <b35362@freescale.com>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> drivers/mtd/nand/fsl_elbc_nand.c | 211 +++++++++++++++++++++++++++++++++++---
>> 1 files changed, 194 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
>> index d634c5f..c96e714 100644
>> --- a/drivers/mtd/nand/fsl_elbc_nand.c
>> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
>> @@ -55,7 +55,9 @@ struct fsl_elbc_mtd {
>> struct device *dev;
>> int bank; /* Chip select bank number */
>> u8 __iomem *vbase; /* Chip select base virtual address */
>> - int page_size; /* NAND page size (0=512, 1=2048) */
>> + int page_size; /* NAND page size, the mutiple of 2048.
>> + * (0=512, 1=2048, 2=4096, 4=8192....)
>> + */
>
> Again, please remove this. It was sort-of reasonable when it was a
> boolean that selected between slightly different programming models. It
> doesn't make sense as "mtd->writesize == 512 ? 0 : mtd->writesize / 512".
Sorry, I meant "mtd->writesize == 512 ? 0 : mtd->writesize / 2048".
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-11-28 21:48 UTC (permalink / raw)
To: LiuShuo
Cc: Artem Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd, akpm,
David Woodhouse
In-Reply-To: <1322095306-13156-3-git-send-email-b35362@freescale.com>
On 11/23/2011 06:41 PM, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
> them to a large buffer.
>
> Signed-off-by: Liu Shuo <b35362@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> drivers/mtd/nand/fsl_elbc_nand.c | 211 +++++++++++++++++++++++++++++++++++---
> 1 files changed, 194 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index d634c5f..c96e714 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -55,7 +55,9 @@ struct fsl_elbc_mtd {
> struct device *dev;
> int bank; /* Chip select bank number */
> u8 __iomem *vbase; /* Chip select base virtual address */
> - int page_size; /* NAND page size (0=512, 1=2048) */
> + int page_size; /* NAND page size, the mutiple of 2048.
> + * (0=512, 1=2048, 2=4096, 4=8192....)
> + */
Again, please remove this. It was sort-of reasonable when it was a
boolean that selected between slightly different programming models. It
doesn't make sense as "mtd->writesize == 512 ? 0 : mtd->writesize / 512".
What is the plan for migrating bad block markers on first use?
-Scott
^ permalink raw reply
* Re: [PATCH v3 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-11-28 21:41 UTC (permalink / raw)
To: LiuShuo
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, Liu Shuo,
Shengzhou Liu, linux-mtd, akpm, dwmw2
In-Reply-To: <4ECCE393.2030600@freescale.com>
On 11/23/2011 06:14 AM, LiuShuo wrote:
> =E4=BA=8E 2011=E5=B9=B411=E6=9C=8823=E6=97=A5 07:55, Scott Wood =E5=86=99=
=E9=81=93:
>> On 11/15/2011 03:29 AM, b35362@freescale.com wrote:
>>> From: Liu Shuo<b35362@freescale.com>
>>>
>>> - if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column !=3D 0 ||
>>> + if (elbc_fcm_ctrl->column>=3D mtd->writesize) {
>>> + /* write oob */
>>> + if (priv->page_size> 1) {
>>> + /* when pagesize of chip is greater than 2048,
>>> + * we have to write full page to write spare
>>> + * region, so we fill '0xff' to main region
>>> + * and some bytes of spare region which we
>>> + * don't want to rewrite.
>>> + * (write '1' won't change the original value)
>>> + */
>>> + memset(elbc_fcm_ctrl->buffer, 0xff,
>>> + elbc_fcm_ctrl->column);
>> I don't like relying on this -- can we use RNDIN instead to do a
>> discontiguous write?
>>
> I have no better way to implement it now.
> Some chips have 'NOP' limitation, so I don't use the FIR_OP_UA to do a
> oob write.
I don't think each RNDIN counts separately against NOP (someone correct
me if I'm wrong). You're writing discontiguous regions of the page in
one operation.
-Scott
^ permalink raw reply
* [PATCH] make gianfar eTSEC vlan hw acceleration work again.
From: Staale.Aakermann @ 2011-11-28 20:56 UTC (permalink / raw)
To: linuxppc-dev
Hi.
There seems to be a breakage in the VLAN TX HW acceleration in gianfar (ker=
nel 3.1). It seems like the previous patch that was submitted forgotten to =
initialize the TX registers.
--- drivers/net/gianfar.c-orig 2011-11-28 11:04:09.318992481 +0100
+++ drivers/net/gianfar.c 2011-11-28 11:05:43.530990635 +0100
@@ -394,6 +394,9 @@
/* Init rctrl based on our settings */
gfar_write(®s->rctrl, rctrl);
+ if (ndev->features & NETIF_F_HW_VLAN_TX)
+ tctrl |=3D TCTRL_VLINS;
+
if (ndev->features & NETIF_F_IP_CSUM)
tctrl |=3D TCTRL_INIT_CSUM;
After this patch, it seems vlan rx/tx for eTSEC works again.
Best regards
Staale Aakermann
________________________________
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be p=
roprietary, confidential or subject to export regulations, and is only mean=
t for the intended recipient(s). Any disclosure, copying, distribution or u=
se is prohibited, if not otherwise explicitly agreed with KONGSBERG. If rec=
eived in error, please delete it immediately from your system and notify th=
e sender properly.
^ permalink raw reply
* Re: MPIC cleanup series
From: Benjamin Herrenschmidt @ 2011-11-28 20:58 UTC (permalink / raw)
To: Kyle Moffett; +Cc: linuxppc-dev
In-Reply-To: <CAGZ=bqJZdN-gpeBW+EdE7Dd=qsNzhwbFr8hBCRqMM72VkT8W7g@mail.gmail.com>
On Mon, 2011-11-28 at 15:48 -0500, Kyle Moffett wrote:
> On Sun, Nov 27, 2011 at 18:51, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > Overall I really look your series. It doesn't quite apply cleanly
> > anymore so I'll as you for a new shoot after you address the comments
> > below, at which point, if you're fast enough, I'll stick it in -next :-)
>
> Awesome! Thanks!
>
> As I mentioned before, I have precious little of the hardware to test
> this all on, so I hope I don't break anything. At minimum I need to
> do a final build-and-run test on my e500 boards before I send it out.
> :-D
That's ok, I was planning on letting it simmer in -test for a week or
so, giving myself time to test on a range of powermacs etc...
> > Just a couple of comments on some of the patches:
> >
> > - 5/10: search for open-pic device-tree node if NULL
> >
> > The idea is fine, however most callers ignore the device-type and only
> > compare on compatible, while you replace that with a match entry that
> > seems to require matching on both. This is likely to break stuff. The
> > "type" part of te march entry should be NULL I believe.
>
> If you re-read that, the match table used if no of_node is passed in
> has *two* separate entries, one of them with a "type" and the other
> with a "compatible", as opposed to a single entry which matches both
> "type" and "compatible".
Oh, my bad. Ok.
> There are a lot of callers which do:
> dnp = of_find_node_by_type(NULL, "open-pic");
>
> So I doubt I can remove the "type" entry all together, unfortunately.
>
>
> > - 9/10: cache the node
> >
> > of_node_get() is your friend.
>
> Yes, I actually messed this one up in the prior patch too, thanks for
> noticing. It should all be fixed now.
>
>
> > - 10/10: Makes me a bit nervous. It 'looks' right but I wouldn't bet on
> > Apple device-trees being sane vs. chaining. I would like a test that
> > doesn't do the cascade if the mpic is a primary to at least limit the
> > risk of messup.
>
> Oh, you mean to wrap that block like this?
>
> if (mpic->flags & MPIC_SECONDARY) {
> virq = irq_of_parse_and_map(mpic->node, 0);
> ...
> }
Yes.
> Sure, makes sense to me. I've made that change.
>
> Thanks for the review!
Thanks. Re-post the whole series and I'll merge it.
Cheers,
Ben.
^ 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