LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/3] Xilinx: hwicap: Use fixed device major.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
  To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-3-git-send-email-stephen.neuendorffer@xilinx.com>

Major 259 has been assigned by lanana.  Use it.  Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.

Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |   43 +++++++++-------------------
 1 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 5b8d646..016f905 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -36,7 +36,7 @@
  *****************************************************************************/
 
 /*
- * This is the code behind /dev/xilinx_icap -- it allows a user-space
+ * This is the code behind /dev/icap* -- it allows a user-space
  * application to use the Xilinx ICAP subsystem.
  *
  * The following operations are possible:
@@ -67,7 +67,7 @@
  * user-space application code that uses this device.  The simplest
  * way to use this interface is simply:
  *
- * cp foo.bit /dev/xilinx_icap
+ * cp foo.bit /dev/icap0
  *
  * Note that unless foo.bit is an appropriately constructed partial
  * bitstream, this has a high likelyhood of overwriting the design
@@ -105,18 +105,14 @@
 #include "buffer_icap.h"
 #include "fifo_icap.h"
 
-#define DRIVER_NAME "xilinx_icap"
+#define DRIVER_NAME "icap"
 
 #define HWICAP_REGS   (0x10000)
 
-/* dynamically allocate device number */
-static int xhwicap_major;
-static int xhwicap_minor;
+#define XHWICAP_MAJOR 259
+#define XHWICAP_MINOR 0
 #define HWICAP_DEVICES 1
 
-module_param(xhwicap_major, int, S_IRUGO);
-module_param(xhwicap_minor, int, S_IRUGO);
-
 /* An array, which is set to true when the device is registered. */
 static bool probed_devices[HWICAP_DEVICES];
 static struct mutex icap_sem;
@@ -605,7 +601,7 @@ static int __devinit hwicap_setup(struct device *dev, int id,
 	probed_devices[id] = 1;
 	mutex_unlock(&icap_sem);
 
-	devt = MKDEV(xhwicap_major, xhwicap_minor + id);
+	devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR + id);
 
 	drvdata = kzalloc(sizeof(struct hwicap_drvdata), GFP_KERNEL);
 	if (!drvdata) {
@@ -710,7 +706,7 @@ static int __devexit hwicap_remove(struct device *dev)
 	dev_set_drvdata(dev, NULL);
 
 	mutex_lock(&icap_sem);
-	probed_devices[MINOR(dev->devt)-xhwicap_minor] = 0;
+	probed_devices[MINOR(dev->devt)-XHWICAP_MINOR] = 0;
 	mutex_unlock(&icap_sem);
 	return 0;		/* success */
 }
@@ -850,23 +846,12 @@ static int __init hwicap_module_init(void)
 	icap_class = class_create(THIS_MODULE, "xilinx_config");
 	mutex_init(&icap_sem);
 
-	if (xhwicap_major) {
-		devt = MKDEV(xhwicap_major, xhwicap_minor);
-		retval = register_chrdev_region(
-				devt,
-				HWICAP_DEVICES,
-				DRIVER_NAME);
-		if (retval < 0)
-			return retval;
-	} else {
-		retval = alloc_chrdev_region(&devt,
-				xhwicap_minor,
-				HWICAP_DEVICES,
-				DRIVER_NAME);
-		if (retval < 0)
-			return retval;
-		xhwicap_major = MAJOR(devt);
-	}
+	devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
+	retval = register_chrdev_region(devt,
+					HWICAP_DEVICES,
+					DRIVER_NAME);
+	if (retval < 0)
+		return retval;
 
 	retval = platform_driver_register(&hwicap_platform_driver);
 
@@ -891,7 +876,7 @@ static int __init hwicap_module_init(void)
 
 static void __exit hwicap_module_cleanup(void)
 {
-	dev_t devt = MKDEV(xhwicap_major, xhwicap_minor);
+	dev_t devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
 
 	class_destroy(icap_class);
 
-- 
1.5.3.4-dirty

^ permalink raw reply related

* [PATCH 1/3] Xilinx: hwicap: Refactor status handling code.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
  To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-1-git-send-email-stephen.neuendorffer@xilinx.com>

Both the buffer-based and fifo-based icap cores have a status
register.  Previously, this was only used internally to check whether
transactions have completed.  However, the status can be useful to the
main driver as well.  This patch exposes these status functions to the
main driver along with some masks for the differnet bits.

Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 drivers/char/xilinx_hwicap/buffer_icap.c   |   22 ++++---------------
 drivers/char/xilinx_hwicap/buffer_icap.h   |    5 ++-
 drivers/char/xilinx_hwicap/fifo_icap.c     |   31 ++++++++++++++++++++-------
 drivers/char/xilinx_hwicap/fifo_icap.h     |    1 +
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |    2 +
 drivers/char/xilinx_hwicap/xilinx_hwicap.h |   24 +++++++++++++++++++++
 6 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
index f577dae..aa7f796 100644
--- a/drivers/char/xilinx_hwicap/buffer_icap.c
+++ b/drivers/char/xilinx_hwicap/buffer_icap.c
@@ -74,7 +74,7 @@
 
 /**
  * buffer_icap_get_status - Get the contents of the status register.
- * @base_address: is the base address of the device
+ * @drvdata: a pointer to the drvdata.
  *
  * The status register contains the ICAP status and the done bit.
  *
@@ -88,9 +88,9 @@
  * D1 - Always 1
  * D0 - Done bit
  **/
-static inline u32 buffer_icap_get_status(void __iomem *base_address)
+u32 buffer_icap_get_status(struct hwicap_drvdata *drvdata)
 {
-	return in_be32(base_address + XHI_STATUS_REG_OFFSET);
+	return in_be32(drvdata->base_address + XHI_STATUS_REG_OFFSET);
 }
 
 /**
@@ -117,20 +117,8 @@ static inline u32 buffer_icap_get_bram(void __iomem *base_address,
  **/
 static inline bool buffer_icap_busy(void __iomem *base_address)
 {
-	return (buffer_icap_get_status(base_address) & 1) == XHI_NOT_FINISHED;
-}
-
-/**
- * buffer_icap_busy - Return true if the icap device is not busy
- * @base_address: is the base address of the device
- *
- * The queries the low order bit of the status register, which
- * indicates whether the current configuration or readback operation
- * has completed.
- **/
-static inline bool buffer_icap_done(void __iomem *base_address)
-{
-	return (buffer_icap_get_status(base_address) & 1) == XHI_FINISHED;
+	u32 status = in_be32(base_address + XHI_STATUS_REG_OFFSET);
+	return (status & 1) == XHI_NOT_FINISHED;
 }
 
 /**
diff --git a/drivers/char/xilinx_hwicap/buffer_icap.h b/drivers/char/xilinx_hwicap/buffer_icap.h
index 0318495..c5b1840 100644
--- a/drivers/char/xilinx_hwicap/buffer_icap.h
+++ b/drivers/char/xilinx_hwicap/buffer_icap.h
@@ -44,8 +44,6 @@
 #include <asm/io.h>
 #include "xilinx_hwicap.h"
 
-void buffer_icap_reset(struct hwicap_drvdata *drvdata);
-
 /* Loads a partial bitstream from system memory. */
 int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 			     u32 Size);
@@ -54,4 +52,7 @@ int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 int buffer_icap_get_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 			     u32 Size);
 
+u32 buffer_icap_get_status(struct hwicap_drvdata *drvdata);
+void buffer_icap_reset(struct hwicap_drvdata *drvdata);
+
 #endif
diff --git a/drivers/char/xilinx_hwicap/fifo_icap.c b/drivers/char/xilinx_hwicap/fifo_icap.c
index 6f45dbd..776b505 100644
--- a/drivers/char/xilinx_hwicap/fifo_icap.c
+++ b/drivers/char/xilinx_hwicap/fifo_icap.c
@@ -78,13 +78,6 @@
 #define XHI_CR_READ_MASK 0x00000002 /* Read from ICAP to FIFO */
 #define XHI_CR_WRITE_MASK 0x00000001 /* Write from FIFO to ICAP */
 
-/* Status Register (SR) */
-#define XHI_SR_CFGERR_N_MASK 0x00000100 /* Config Error Mask */
-#define XHI_SR_DALIGN_MASK 0x00000080 /* Data Alignment Mask */
-#define XHI_SR_RIP_MASK 0x00000040 /* Read back Mask */
-#define XHI_SR_IN_ABORT_N_MASK 0x00000020 /* Select Map Abort Mask */
-#define XHI_SR_DONE_MASK 0x00000001 /* Done bit Mask  */
-
 
 #define XHI_WFO_MAX_VACANCY 1024 /* Max Write FIFO Vacancy, in words */
 #define XHI_RFO_MAX_OCCUPANCY 256 /* Max Read FIFO Occupancy, in words */
@@ -152,13 +145,35 @@ static inline void fifo_icap_start_readback(struct hwicap_drvdata *drvdata)
 }
 
 /**
+ * fifo_icap_get_status - Get the contents of the status register.
+ * @drvdata: a pointer to the drvdata.
+ *
+ * The status register contains the ICAP status and the done bit.
+ *
+ * D8 - cfgerr
+ * D7 - dalign
+ * D6 - rip
+ * D5 - in_abort_l
+ * D4 - Always 1
+ * D3 - Always 1
+ * D2 - Always 1
+ * D1 - Always 1
+ * D0 - Done bit
+ **/
+u32 fifo_icap_get_status(struct hwicap_drvdata *drvdata)
+{
+	u32 status = in_be32(drvdata->base_address + XHI_SR_OFFSET);
+	dev_dbg(drvdata->dev, "Getting status = %x\n", status);
+	return status;
+}
+
+/**
  * fifo_icap_busy - Return true if the ICAP is still processing a transaction.
  * @drvdata: a pointer to the drvdata.
  **/
 static inline u32 fifo_icap_busy(struct hwicap_drvdata *drvdata)
 {
 	u32 status = in_be32(drvdata->base_address + XHI_SR_OFFSET);
-	dev_dbg(drvdata->dev, "Getting status = %x\n", status);
 	return (status & XHI_SR_DONE_MASK) ? 0 : 1;
 }
 
diff --git a/drivers/char/xilinx_hwicap/fifo_icap.h b/drivers/char/xilinx_hwicap/fifo_icap.h
index 4d3068d..ffabd3b 100644
--- a/drivers/char/xilinx_hwicap/fifo_icap.h
+++ b/drivers/char/xilinx_hwicap/fifo_icap.h
@@ -56,6 +56,7 @@ int fifo_icap_set_configuration(
 		u32 *FrameBuffer,
 		u32 NumWords);
 
+u32 fifo_icap_get_status(struct hwicap_drvdata *drvdata);
 void fifo_icap_reset(struct hwicap_drvdata *drvdata);
 void fifo_icap_flush_fifo(struct hwicap_drvdata *drvdata);
 
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 2284fa2..304727d 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -664,12 +664,14 @@ static int __devinit hwicap_setup(struct device *dev, int id,
 static struct hwicap_driver_config buffer_icap_config = {
 	.get_configuration = buffer_icap_get_configuration,
 	.set_configuration = buffer_icap_set_configuration,
+	.get_status = buffer_icap_get_status,
 	.reset = buffer_icap_reset,
 };
 
 static struct hwicap_driver_config fifo_icap_config = {
 	.get_configuration = fifo_icap_get_configuration,
 	.set_configuration = fifo_icap_set_configuration,
+	.get_status = fifo_icap_get_status,
 	.reset = fifo_icap_reset,
 };
 
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.h b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
index 405fee7..1f9c8b0 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.h
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
@@ -65,10 +65,27 @@ struct hwicap_drvdata {
 };
 
 struct hwicap_driver_config {
+	/* Read configuration data given by size into the data buffer.
+	   Return 0 if successful. */
 	int (*get_configuration)(struct hwicap_drvdata *drvdata, u32 *data,
 			u32 size);
+	/* Write configuration data given by size from the data buffer.
+	   Return 0 if successful. */
 	int (*set_configuration)(struct hwicap_drvdata *drvdata, u32 *data,
 			u32 size);
+	/* Get the status register, bit pattern given by:
+	 * D8 - 0 = configuration error
+	 * D7 - 1 = alignment found
+	 * D6 - 1 = readback in progress
+	 * D5 - 0 = abort in progress
+	 * D4 - Always 1
+	 * D3 - Always 1
+	 * D2 - Always 1
+	 * D1 - Always 1
+	 * D0 - 1 = operation completed
+	 */
+	u32 (*get_status)(struct hwicap_drvdata *drvdata);
+	/* Reset the hw */
 	void (*reset)(struct hwicap_drvdata *drvdata);
 };
 
@@ -163,6 +180,13 @@ struct config_registers {
 /* Constant to use for CRC check when CRC has been disabled */
 #define XHI_DISABLED_AUTO_CRC       0x0000DEFCUL
 
+/* Meanings of the bits returned by get_status */
+#define XHI_SR_CFGERR_N_MASK 0x00000100 /* Config Error Mask */
+#define XHI_SR_DALIGN_MASK 0x00000080 /* Data Alignment Mask */
+#define XHI_SR_RIP_MASK 0x00000040 /* Read back Mask */
+#define XHI_SR_IN_ABORT_N_MASK 0x00000020 /* Select Map Abort Mask */
+#define XHI_SR_DONE_MASK 0x00000001 /* Done bit Mask  */
+
 /**
  * hwicap_type_1_read - Generates a Type 1 read packet header.
  * @reg: is the address of the register to be read back.
-- 
1.5.3.4-dirty

^ permalink raw reply related

* [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Anton Vorontsov @ 2008-03-17 17:52 UTC (permalink / raw)
  To: linuxppc-dev

MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
fixed-link property in the device tree.

If not, ethernet will not work:
  e0024520:03 not found
  eth1: Could not attach to PHY
  IP-Config: Failed to open eth1

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 arch/powerpc/boot/dts/mpc8377_rdb.dts      |    8 +-------
 arch/powerpc/boot/dts/mpc8378_rdb.dts      |    8 +-------
 arch/powerpc/boot/dts/mpc8379_rdb.dts      |    8 +-------
 arch/powerpc/configs/mpc837x_rdb_defconfig |    2 +-
 4 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index d2332fb..476f65a 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -164,12 +164,6 @@
 				reg = <0x2>;
 				device_type = "ethernet-phy";
 			};
-			phy3: ethernet-phy@3 {
-				interrupt-parent = <&ipic>;
-				interrupts = <18 0x8>;
-				reg = <0x3>;
-				device_type = "ethernet-phy";
-			};
 		};
 
 		enet0: ethernet@24000 {
@@ -195,7 +189,7 @@
 			interrupts = <35 0x8 36 0x8 37 0x8>;
 			phy-connection-type = "mii";
 			interrupt-parent = <&ipic>;
-			phy-handle = <&phy3>;
+			fixed-link = <1 1 1000 0 0>;
 		};
 
 		serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 711f9a3..0e872a6 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -164,12 +164,6 @@
 				reg = <0x2>;
 				device_type = "ethernet-phy";
 			};
-			phy3: ethernet-phy@3 {
-				interrupt-parent = <&ipic>;
-				interrupts = <18 0x8>;
-				reg = <0x3>;
-				device_type = "ethernet-phy";
-			};
 		};
 
 		enet0: ethernet@24000 {
@@ -195,7 +189,7 @@
 			interrupts = <35 0x8 36 0x8 37 0x8>;
 			phy-connection-type = "mii";
 			interrupt-parent = <&ipic>;
-			phy-handle = <&phy3>;
+			fixed-link = <1 1 1000 0 0>;
 		};
 
 		serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index c11ceb7..1eb8def 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -164,12 +164,6 @@
 				reg = <0x2>;
 				device_type = "ethernet-phy";
 			};
-			phy3: ethernet-phy@3 {
-				interrupt-parent = <&ipic>;
-				interrupts = <18 0x8>;
-				reg = <0x3>;
-				device_type = "ethernet-phy";
-			};
 		};
 
 		enet0: ethernet@24000 {
@@ -195,7 +189,7 @@
 			interrupts = <35 0x8 36 0x8 37 0x8>;
 			phy-connection-type = "mii";
 			interrupt-parent = <&ipic>;
-			phy-handle = <&phy3>;
+			fixed-link = <1 1 1000 0 0>;
 		};
 
 		serial0: serial@4500 {
diff --git a/arch/powerpc/configs/mpc837x_rdb_defconfig b/arch/powerpc/configs/mpc837x_rdb_defconfig
index 91d291e..c429a33 100644
--- a/arch/powerpc/configs/mpc837x_rdb_defconfig
+++ b/arch/powerpc/configs/mpc837x_rdb_defconfig
@@ -425,7 +425,7 @@ CONFIG_MARVELL_PHY=y
 # CONFIG_SMSC_PHY is not set
 # CONFIG_BROADCOM_PHY is not set
 # CONFIG_ICPLUS_PHY is not set
-# CONFIG_FIXED_PHY is not set
+CONFIG_FIXED_PHY=y
 # CONFIG_MDIO_BITBANG is not set
 CONFIG_NET_ETHERNET=y
 CONFIG_MII=y
-- 
1.5.2.2

^ permalink raw reply related

* Help getting USB keyboard active on MPC5200B
From: Edward Jubenville @ 2008-03-17 17:42 UTC (permalink / raw)
  To: Linuxppc-Embedded

I would appreciate a little help getting a USB keyboard working on a
MPC5200B-based Lite5200 clone board.

I'm working with the 2.4.25 kernel from ELDK 3.1.  I've tweaked my kernel
configuration parameters enough to have gotten a some USB functionality
working (memory stick, and mouse), but I cannot get any keyboard-related
device name to show up in the /dev tree.

I have USB debug enabled for verbose messages.  When I plug in a keyboard I
see:

  hub.c: new USB device 0-1.4, assigned address 5
  Manufacturer: Dell
  Product: Dell USB Keyboard
  usb.c: USB device 5 (vend/prod 0x413c/0x2003) is not claimed by any active
driver.
    Length              = 18
    DescriptorType      = 01
    USB version         = 1.10
    Vendor:Product      = 413c:2003
    MaxPacketSize0      = 8
    NumConfigurations   = 1
    Device version      = 3.01
    (remainder omitted)

I assume the message "... is not claimed by any driver" is the problem I
need to address.

I've compared my configuration parameters to those used in the Lite5200
CoralP configuration that supports USB, and I don't see any differences
related to the keyboard that might explain what's wrong.

When I diff my configuration to non-USB
arch/ppc/configs/icecube_5200_defconfig, these parameters stand out:

	CONFIG_INPUT=y
	CONFIG_INPUT_KEYBDEV=y
	CONFIG_INPUT_MOUSEDEV=y
	CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
	CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
	CONFIG_INPUT_EVDEV=y
	CONFIG_VT=y
	CONFIG_VT_CONSOLE=y
	CONFIG_MOUSE=y
	CONFIG_USB=y
	CONFIG_USB_DEBUG=y
	CONFIG_USB_DEVICEFS=y
	CONFIG_USB_OHCI_5xxx=y
	CONFIG_USB_OHCI_BIG_ENDIAN=y
	CONFIG_USB_OHCI=y
	CONFIG_USB_STORAGE=y
	CONFIG_USB_STORAGE_DEBUG=y
	CONFIG_USB_HID=y
	CONFIG_USB_HIDINPUT=y
	CONFIG_USB_HIDDEV=y

Can anyone point me in the right direction to get access to the USB
keyboard?  I'm using a serial system console and wish to keep it that way,
so the keyboard needs to be available an application input device.

Thanks,

Ed Jubenville

^ permalink raw reply

* Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Dan Williams @ 2008-03-17 18:46 UTC (permalink / raw)
  To: Olof Johansson
  Cc: linuxppc-dev, pasemi-linux, shannon.nelson, linux-kernel,
	hskinnemoen
In-Reply-To: <20080316213002.GA2589@lixom.net>

On Sun, Mar 16, 2008 at 2:30 PM, Olof Johansson <olof@lixom.net> wrote:
> pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
>
>  DMA copy offload driver for PA Semi PWRficient. It uses the
>
> platform-specific functions to allocate channels, etc.
>
>  Signed-off-by: Olof Johansson <olof@lixom.net>
>
>  ---
>
>  Changes since last post:
>
>  * Add DMA_INTERRUPT support and handling of the interrupt flag
>  * Fix interrupt handler for above and add tasklet
>  * Switch to spin_lock_bh() where possible
>  * Remove empty dependency_added() function since it's no longer
>   used in the framework.
>  * Fix bug in "ring full" estimation.
>

Hi Olof,

Looks good, makes me want to go back and cleanup iop-adma a bit.  A
few fyi's below, but no other review comments.

>  Note that this still needs to go on top of the powerpc.git tree due to the
>  pasemi_dma.h updates that this driver depends on. I suggest merging this
>  through pasemi.git->powerpc.git->linus with an Acked-by from the DMA guys.

Ok, it still may not compile in mainline until after 2.6.26-rc1 due to
additional dmaengine cleanups like the ack-to-flags change I posted
earlier.  Any better way to handle this?  Go through -mm?

>
>  -Olof
>

Acked-by: Dan Williams <dan.j.williams@intel.com>

> --- /dev/null
>  +++ b/drivers/dma/pasemi_dma.c
[..]
>  +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
>  +{
>  +       int old, new, i;
>
> +       struct pasemi_dma_desc *desc;
>  +       dma_async_tx_callback callback;
>  +
>  +restart:
>  +       spin_lock_bh(&chan->desc_lock);
>
> +
>  +       old = chan->next_to_clean;
>  +
>  +       new = *chan->chan.status & PAS_STATUS_PCNT_M;
>  +       new <<= 2;
>  +       new &= (RING_SZ-1);
>  +
>  +       if (old > new)
>  +               new += RING_SZ;
>  +
>  +       for (i = old; i < new; i += 4) {
>  +               if (unlikely(chan->chan.ring_virt[i & (RING_SZ-1)] & XCT_COPY_O))
>  +                       break;
>  +               desc = chan->ring_info[i & (RING_SZ-1)];
>  +
>  +               callback = desc->async_tx.callback;
>  +               if (callback) {
>  +                       /* Can't re-lock and just loop, since another cpu
>  +                        * might have came in here while we released the lock.
>  +                        * Instead, start all over again to re-read status words.
>  +                        */
>
> +                       chan->next_to_clean = i & (RING_SZ-1);
>  +                       spin_unlock_bh(&chan->desc_lock);
>  +                       callback(desc->async_tx.callback_param);
>  +                       goto restart;
>  +               }

Clients do not submit new operations in their callback routines so it
is "ok" to hold this lock over the callback.

Also, if your platform will need to support channel switching at some
point you can go ahead and add a call to async_tx_run_dependencies()
here.

^ permalink raw reply

* [PATCH] [POWERPC] Xilinx: Serial: Adding 8250 console support to OF serial
From: John Linn @ 2008-03-17 19:09 UTC (permalink / raw)
  To: linuxppc-dev, jwboyer; +Cc: John Linn

This change adds code to serial_of.c to support the 8250 console.
Initialization was added to get the UART data from the device tree
and setup the UART and console for the 8250.

The cmd line was not being used for the baud rate and is still not
being used as the speed for the uart is being pulled from the UART
properties in the device tree. The input clock frequency for the
UART must be specified in the device tree so the baud rate generator
can be setup.

<Signed-off-by: John Linn <john.linn@xilinx.com>

---

Please pull this patch for 2.6.26.
---
 drivers/serial/8250.c      |   20 ++++++--
 drivers/serial/of_serial.c |  128 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 144 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..7b32af1 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2366,7 +2366,7 @@ serial8250_type(struct uart_port *port)
 	return uart_config[type].name;
 }
 
-static struct uart_ops serial8250_pops = {
+struct uart_ops serial8250_pops = {
 	.tx_empty	= serial8250_tx_empty,
 	.set_mctrl	= serial8250_set_mctrl,
 	.get_mctrl	= serial8250_get_mctrl,
@@ -2519,10 +2519,13 @@ serial8250_console_write(struct console *co, const char *s, unsigned int count)
 static int __init serial8250_console_setup(struct console *co, char *options)
 {
 	struct uart_port *port;
+
+#ifndef CONFIG_SERIAL_OF_PLATFORM
 	int baud = 9600;
 	int bits = 8;
 	int parity = 'n';
 	int flow = 'n';
+#endif
 
 	/*
 	 * Check whether an invalid uart number has been specified, and
@@ -2535,10 +2538,13 @@ static int __init serial8250_console_setup(struct console *co, char *options)
 	if (!port->iobase && !port->membase)
 		return -ENODEV;
 
+#ifndef CONFIG_SERIAL_OF_PLATFORM
 	if (options)
 		uart_parse_options(options, &baud, &parity, &bits, &flow);
-
 	return uart_set_options(port, co, baud, parity, bits, flow);
+#else
+	return 0;
+#endif
 }
 
 static int serial8250_console_early_setup(void)
@@ -2547,7 +2553,7 @@ static int serial8250_console_early_setup(void)
 }
 
 static struct uart_driver serial8250_reg;
-static struct console serial8250_console = {
+struct console serial8250_console = {
 	.name		= "ttyS",
 	.write		= serial8250_console_write,
 	.device		= uart_console_device,
@@ -2558,13 +2564,19 @@ static struct console serial8250_console = {
 	.data		= &serial8250_reg,
 };
 
-static int __init serial8250_console_init(void)
+int __init serial8250_console_init(void)
 {
 	serial8250_isa_init_ports();
 	register_console(&serial8250_console);
 	return 0;
 }
+
+/* when OF is being used with the 8250 console, the OF hooks in the 
+   8250 console
+*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(CONFIG_SERIAL_OF_PLATFORM)
 console_initcall(serial8250_console_init);
+#endif
 
 int serial8250_find_port(struct uart_port *p)
 {
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..eed245a 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -13,9 +13,11 @@
 #include <linux/module.h>
 #include <linux/serial_core.h>
 #include <linux/serial_8250.h>
+#include <linux/console.h>
 
 #include <asm/of_platform.h>
 #include <asm/prom.h>
+#include <asm/io.h>
 
 struct of_serial_info {
 	int type;
@@ -158,6 +160,132 @@ static void __exit of_platform_serial_exit(void)
 };
 module_exit(of_platform_serial_exit);
 
+#if defined(CONFIG_SERIAL_8250_CONSOLE)
+
+/* when an 8250 console is being used and OF, the OF needs to
+   setup the uart before the 8250 console initializes
+*/
+extern struct console serial8250_console;
+extern int serial8250_console_init(void);
+extern int early_serial_console_setup(struct uart_port *);
+extern struct uart_ops serial8250_pops;
+
+static struct uart_port of_uart_port;
+
+static struct of_device_id __devinit uart_of_match[] = {
+	{ .type = "serial", .compatible = "ns16550", },
+	{},
+};
+
+static unsigned int *spd;
+
+/*
+ * Setup the uart based on OF properties
+ */
+static int __init uart_of_setup(struct device_node *np,
+					struct uart_port *port)
+{
+	struct resource resource;
+	const unsigned int *clk, *regshift;
+	int ret;
+
+	memset(port, 0, sizeof *port);
+	spd = of_get_property(np, "current-speed", NULL);
+	regshift = of_get_property(np, "reg-shift", NULL);
+	clk = of_get_property(np, "clock-frequency", NULL);
+	if (!clk) {
+		return -ENODEV;
+	}
+
+	ret = of_address_to_resource(np, 0, &resource);
+	if (ret) {
+		return ret;
+	}
+
+	spin_lock_init(&port->lock);
+	port->irq = irq_of_parse_and_map(np, 0);
+	port->iotype = UPIO_MEM;
+	port->type = PORT_16550;
+	port->uartclk = *clk;
+	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
+		| UPF_FIXED_PORT;
+	if (!spd)
+		*spd = 9600;
+		
+	port->custom_divisor = *clk / (16 * (*spd));
+
+	if (regshift) {
+		port->regshift = *regshift;
+		port->mapbase = resource.start + ((1 << *regshift) - 1);
+	} else {
+		port->mapbase = resource.start;
+	}
+	return 0;
+}
+
+static struct device_node __init *console_of_find_device(int id)
+{
+	struct device_node *np;
+        const struct of_device_id *matches = uart_of_match;
+
+	while (matches->compatible[0]) {
+		for_each_compatible_node(np, NULL, matches->compatible) {
+			if (!of_match_node(matches, np))
+				continue;
+
+                        of_node_put(np);
+                        return np;
+		}
+		matches++;
+	}
+	return 0;
+}
+
+static int __init console_setup(struct console *co)
+{
+	struct device_node *np;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	/* Find a matching uart port in the device tree */
+	np = console_of_find_device(co->index);
+	if (!np)
+		return -ENODEV;
+		
+	if (uart_of_setup(np, &of_uart_port))
+		return -ENODEV;
+
+	/* registers mapped yet? */
+	if (!of_uart_port.membase) {
+		of_uart_port.membase = ioremap(of_uart_port.mapbase, 64);
+		if (!of_uart_port.membase)
+			return -ENODEV;
+	}
+
+	of_uart_port.ops = &serial8250_pops;
+	uart_set_options(&of_uart_port, co, *spd, parity, bits, flow);
+
+	return 0;
+}
+
+/* This function sets up the 8250 console by getting the OF data at 
+   console init time and then setting up the 8250 uart and console. 
+   This solves the problem of the OF uart not being setup in time 
+   for the 8250 console to use it.
+*/
+static int __init of_console_init(void)
+{
+	if (!console_setup(&serial8250_console)) {
+		early_serial_setup(&of_uart_port);	
+		serial8250_console_init();	
+	}
+	return 0;
+}
+
+console_initcall(of_console_init);
+#endif
+
 MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Serial Port driver for Open Firmware platform devices");
-- 
1.5.2.1

^ permalink raw reply related

* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-17 19:19 UTC (permalink / raw)
  To: Bartlomiej Sieka; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <47DE94F4.90804@semihalf.com>

On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
>  > Paul, here is a bug fix that needs to go in for 2.6.25.
>
>  Hi Grant,
>
>  What is the status of the various MPC5200-related patches (support for
>  TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
>  time ago by Marian Balakowicz? There's been some comments to the patches
>  on the list, which were addressed and no further discussion occurred, so
>  we were hoping that the changes would go upstream (in 2.6.25). I can see
>  that the .dts files for those boards are in the mainline already, but I
>  see no trace of for example _defconfig files -- could you shed some
>  light on this?

Yes, the separate dts files have been dropped in preference for a
single mpc5200_defconfig for all 5200 boards.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* powerpc: cuImage.* creation error
From: Adrian Bunk @ 2008-03-17 19:36 UTC (permalink / raw)
  To: Kumar Gala, Grant Likely, Paul Mackerras, Paul Gortmaker
  Cc: linuxppc-dev, linux-kernel

When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
them fail to build, and all with similar problems:


mpc85xx_defconfig:

<--  snip  -->

...
  WRAP    arch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb  on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

<--  snip  -->


sbc8548_defconfig:

<--  snip  -->

...
Entry Point:  0x00000000
make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed by `arch/powerpc/boot/zImage'.  Stop.

<--  snip  -->


tqm8540_defconfig:

<--  snip  -->

...
  WRAP    arch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb  on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

<--  snip  -->


Is this a problem on my side or is there a bug that should be fixed?


TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

^ permalink raw reply

* Re: powerpc: cuImage.* creation error
From: Grant Likely @ 2008-03-17 19:39 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Paul Gortmaker, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <20080317193652.GA9550@cs181133002.pp.htv.fi>

On Mon, Mar 17, 2008 at 1:36 PM, Adrian Bunk <bunk@kernel.org> wrote:
> When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
>  them fail to build, and all with similar problems:
>
>  powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such file or directory
>  make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed >  powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such file or directory
>  make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1
>
>  Is this a problem on my side or is there a bug that should be fixed?

I may have messed something up.  I'll dig into it this afternoon.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Joakim Tjernlund @ 2008-03-17 19:42 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080317175208.GA17844@localhost.localdomain>


On Mon, 2008-03-17 at 20:52 +0300, Anton Vorontsov wrote:
> MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
> fixed-link property in the device tree.
> 
> If not, ethernet will not work:
>   e0024520:03 not found
>   eth1: Could not attach to PHY
>   IP-Config: Failed to open eth1
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>

Trying to add fixed-link support for ucc_geth as this is broken too. I
noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
my board once I got the ucc_geth driver to recognize fixed-link.
Does it work for you?

 Jocke

^ permalink raw reply

* Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: Grant Likely @ 2008-03-17 19:47 UTC (permalink / raw)
  To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080317164202.7E8A41A3806F@mail213-sin.bigfish.com>

On Mon, Mar 17, 2008 at 10:41 AM, John Linn <john.linn@xilinx.com> wrote:
> The UART 16550 initialization was not setting up the registers
>  correctly. Code was added to pull the frequency and speed from
>  the device tree and initialize the registers using those values.
>
>  The boot code was not and is still not using the cmd line
>  to setup up the uart. The frequency of the clock driving the
>  UART must be specified in the device tree so that the baud
>  rate generator can be setup.

The bootwrapper makes the assumption that the firmware has already
initialized the serial device and it should not be fiddled with so
that there is less chance of messing up a working output
configuration.

For platforms such as the virtex which don't have firmware the serial
port should be setup earlier in the boot process (in the appropriate
platform_init() function).

Cheers,
g.

>
>  ---
>
>  Please pull this patch for 2.6.26.
>  ---
>   arch/powerpc/boot/ns16550.c |   69 +++++++++++++++++++++++++++++++++---------
>   1 files changed, 54 insertions(+), 15 deletions(-)
>
>  diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
>  index f8f1b2f..d8edd48 100644
>  --- a/arch/powerpc/boot/ns16550.c
>  +++ b/arch/powerpc/boot/ns16550.c
>  @@ -15,23 +15,47 @@
>   #include "io.h"
>   #include "ops.h"
>
>  -#define UART_DLL       0       /* Out: Divisor Latch Low */
>  -#define UART_DLM       1       /* Out: Divisor Latch High */
>  -#define UART_FCR       2       /* Out: FIFO Control Register */
>  -#define UART_LCR       3       /* Out: Line Control Register */
>  -#define UART_MCR       4       /* Out: Modem Control Register */
>  -#define UART_LSR       5       /* In:  Line Status Register */
>  -#define UART_LSR_THRE  0x20    /* Transmit-hold-register empty */
>  -#define UART_LSR_DR    0x01    /* Receiver data ready */
>  -#define UART_MSR       6       /* In:  Modem Status Register */
>  -#define UART_SCR       7       /* I/O: Scratch Register */
>  -
>  -static unsigned char *reg_base;
>  -static u32 reg_shift;
>  +#define UART_DLL               0       /* Out: Divisor Latch Low */
>  +#define UART_DLM               1       /* Out: Divisor Latch High */
>  +#define UART_FCR               2       /* Out: FIFO Control Register */
>  +#define UART_FCR_CLEAR_RCVR    0x02    /* Clear the RCVR FIFO */
>  +#define UART_FCR_CLEAR_XMIT    0x04    /* Clear the XMIT FIFO */
>  +#define UART_LCR               3       /* Out: Line Control Register */
>  +#define UART_MCR               4       /* Out: Modem Control Register */
>  +#define UART_MCR_RTS           0x02    /* RTS complement */
>  +#define UART_MCR_DTR           0x01    /* DTR complement */
>  +#define UART_LSR               5       /* In:  Line Status Register */
>  +#define UART_LSR_THRE          0x20    /* Transmit-hold-register empty */
>  +#define UART_LSR_DR            0x01    /* Receiver data ready */
>  +#define UART_LCR_DLAB          0x80    /* Divisor latch access bit */
>  +#define UART_LCR_WLEN8         0x03    /* Wordlength: 8 bits */
>  +#define UART_MSR               6       /* In:  Modem Status Register */
>  +#define UART_SCR               7       /* I/O: Scratch Register */
>  +
>  +volatile static unsigned char *reg_base;
>  +volatile static u32 reg_shift;
>  +volatile static u16 divisor;
>
>   static int ns16550_open(void)
>   {
>  -       out_8(reg_base + (UART_FCR << reg_shift), 0x06);
>  +
>  +       /* Access baud rate */
>  +       out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_DLAB);
>  +
>  +       /* Baud rate based on input clock */
>  +       out_8(reg_base + (UART_DLL << reg_shift), divisor & 0xFF);
>  +       out_8(reg_base + (UART_DLM << reg_shift), divisor >> 8);
>  +
>  +       /* 8 data, 1 stop, no parity */
>  +       out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_WLEN8);
>  +
>  +       /* RTS/DTR */
>  +       out_8(reg_base + (UART_MCR << reg_shift), UART_MCR_RTS | UART_MCR_DTR);
>  +
>  +       /* Clear transmitter and receiver */
>  +       out_8(reg_base + (UART_FCR << reg_shift),
>  +                               UART_FCR_CLEAR_XMIT | UART_FCR_CLEAR_RCVR);
>  +
>         return 0;
>   }
>
>  @@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
>   {
>         int n;
>         unsigned long reg_phys;
>  +       u32 clk, spd;
>
>         n = getprop(devp, "virtual-reg", &reg_base, sizeof(reg_base));
>         if (n != sizeof(reg_base)) {
>  @@ -65,9 +90,23 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
>                 reg_base = (void *)reg_phys;
>         }
>
>  -       n = getprop(devp, "reg-shift", &reg_shift, sizeof(reg_shift));
>  +       n = getprop(devp, "reg-shift", (void *)&reg_shift, sizeof(reg_shift));
>         if (n != sizeof(reg_shift))
>                 reg_shift = 0;
>  +
>  +       /* the base address has to change for devices with odd reg spacing */
>  +       reg_base = reg_base + ((1 << reg_shift) - 1);
>  +
>  +       n = getprop(devp, "current-speed", (void *)&spd, sizeof(spd));
>  +       if (n != sizeof(spd))
>  +               spd = 9600;
>  +
>  +       /* should there be a default clock rate?*/
>  +       n = getprop(devp, "clock-frequency", (void *)&clk, sizeof(clk));
>  +       if (n != sizeof(clk))
>  +               return -1;
>  +
>  +       divisor = clk / (16 * spd);
>
>         scdp->open = ns16550_open;
>         scdp->putc = ns16550_putc;
>  --
>  1.5.2.1
>
>
>
>  _______________________________________________
>  Linuxppc-dev mailing list
>  Linuxppc-dev@ozlabs.org
>  https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* crash in init_ipic_sysfs on efika
From: Olaf Hering @ 2008-03-17 19:53 UTC (permalink / raw)
  To: linuxppc-dev


I cant reproduce this bug on my board, but:

The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
ipic_init() fails. init_ipic_sysfs() will crash in that case.

Something like this may fix it:

Index: linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
===================================================================
--- linux-2.6.25-rc6.orig/arch/powerpc/sysdev/ipic.c
+++ linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
@@ -906,7 +906,7 @@ static int __init init_ipic_sysfs(void)
 {
        int rc;
 
-       if (!primary_ipic->regs)
+       if (!primary_ipic || !primary_ipic->regs)
                return -ENODEV;
        printk(KERN_DEBUG "Registering ipic with sysfs...\n");
 


ok boot eth:192.168.2.52,inst32 inst32 console=ttyPSC0,115200

SuSE Linux zImage starting: loaded at 00040000-00d24cbc (0/0/01003ed8;
sp: 017ffe80)
uncompressing ELF header done. (00000100 bytes)
Allocated 008584d4 bytes for kernel @ 02000000
Allocated 00a963a2 bytes for initrd @ 02859000
uncompressing kernel done. (004faeb8 bytes)
entering kernel at 02010000(2859000/a963a2/01003ed8)
OF stdout device is: /failsafe
command line: console=ttyPSC0,115200
memory layout at init:
  alloc_bottom : 032f0000
  alloc_top    : 30000000
  alloc_top_hi : f000c000
  rmo_top      : 30000000
  ram_top      : f000c000
Looking for displays
instantiating rtas at 0x07ffb000 ... done
Applying EFIKA device tree fixups
Fixing bestcomm interrupts property
Adding Ethernet MDIO node
Adding Ethernet PHY node
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x032f1000 -> 0x032f17e0
Device tree struct  0x032f2000 -> 0x03315000
Calling quiesce ...
returning from prom_init
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 113264k/131072k available (4808k kernel code, 17648k reserved,
164k data, 461k bss, 228k init)
Security Framework initialized
AppArmor: AppArmor initialized
AppArmor: Unable to log event (1505) to audit subsys
AppArmor: Registered secondary security module name="capability"
AppArmor: Unable to log event (1505) to audit subsys
Capability LSM initialized as secondary
Failure registering Root Plug module with the kernel
AppArmor: Unable to register %s as a secondary security module
name="root_plug"
AppArmor: Unable to log event (1505) to audit subsys
Failure registering Root Plug  module with primary security module.
Mount-cache hash table entries: 512
net_namespace: 544 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
DMA: MPC52xx BestComm driver
DMA: MPC52xx BestComm engine @f0001200 ok !
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0486aac
Oops: Kernel access of bad area, sig: 11 [#1]
Efika
Modules linked in:
NIP: c0486aac LR: c0479200 CTR: c0486a90
REGS: c782bea0 TRAP: 0300   Not tainted  (2.6.25-rc5-git2-5-default)
MSR: 00009032 <EE,ME,IR,DR>  CR: 44002082  XER: 20000000
DAR: 00000000, DSISR: 20000000
TASK = c78237c0[1] 'swapper' THREAD: c782a000
GPR00: c0479200 c782bf50 c78237c0 ffffffed 00000003 00000000 00000000
00000000
GPR08: fffffffc 00000000 c7800780 000f06a0 22002022 dffffff7 c0405540
c0405558
GPR16: c0405568 c040558c c0405594 c04055a4 c04055d0 c0400000 024184a4
ffffffff
GPR24: 00000000 c04a6468 c0405550 c782a000 c04e0000 00000000 00000000
c04af198
NIP [c0486aac] init_ipic_sysfs+0x1c/0x90
LR [c0479200] kernel_init+0xf8/0x2a0
Call Trace:
[c782bf50] [c04869fc] mpc52xx_bcom_init+0x24/0x34 (unreliable)
[c782bf60] [c0479200] kernel_init+0xf8/0x2a0
[c782bff0] [c001330c] kernel_thread+0x44/0x60
Instruction dump:
80010024 bb61000c 38210020 7c0803a6 4e800020 9421fff0 7c0802a6 3d20c04f
3860ffed 90010014 93e1000c 81299730 <80090000> 2f800000 41be0058 3c60c041
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..

^ permalink raw reply

* RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: John Linn @ 2008-03-17 19:57 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171247j709bc554pe709628c46205600@mail.gmail.com>

That makes sense.  Since I'm not using a boot loader I didn't realize
that.

I'm not sure how hard it will be to get the data from the device tree at
that time.

I'll look into the details more.

What about checking to see if it's setup assuming that's possible by
looking at registers, and then not messing with it if it's already
setup, otherwise do what my patch does.

Thanks,
John

-----Original Message-----
From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
Sent: Monday, March 17, 2008 1:48 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; jwboyer@linux.vnet.ibm.com
Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization

On Mon, Mar 17, 2008 at 10:41 AM, John Linn <john.linn@xilinx.com>
wrote:
> The UART 16550 initialization was not setting up the registers
>  correctly. Code was added to pull the frequency and speed from
>  the device tree and initialize the registers using those values.
>
>  The boot code was not and is still not using the cmd line
>  to setup up the uart. The frequency of the clock driving the
>  UART must be specified in the device tree so that the baud
>  rate generator can be setup.

The bootwrapper makes the assumption that the firmware has already
initialized the serial device and it should not be fiddled with so
that there is less chance of messing up a working output
configuration.

For platforms such as the virtex which don't have firmware the serial
port should be setup earlier in the boot process (in the appropriate
platform_init() function).

Cheers,
g.

>
>  ---
>
>  Please pull this patch for 2.6.26.
>  ---
>   arch/powerpc/boot/ns16550.c |   69
+++++++++++++++++++++++++++++++++---------
>   1 files changed, 54 insertions(+), 15 deletions(-)
>
>  diff --git a/arch/powerpc/boot/ns16550.c
b/arch/powerpc/boot/ns16550.c
>  index f8f1b2f..d8edd48 100644
>  --- a/arch/powerpc/boot/ns16550.c
>  +++ b/arch/powerpc/boot/ns16550.c
>  @@ -15,23 +15,47 @@
>   #include "io.h"
>   #include "ops.h"
>
>  -#define UART_DLL       0       /* Out: Divisor Latch Low */
>  -#define UART_DLM       1       /* Out: Divisor Latch High */
>  -#define UART_FCR       2       /* Out: FIFO Control Register */
>  -#define UART_LCR       3       /* Out: Line Control Register */
>  -#define UART_MCR       4       /* Out: Modem Control Register */
>  -#define UART_LSR       5       /* In:  Line Status Register */
>  -#define UART_LSR_THRE  0x20    /* Transmit-hold-register empty */
>  -#define UART_LSR_DR    0x01    /* Receiver data ready */
>  -#define UART_MSR       6       /* In:  Modem Status Register */
>  -#define UART_SCR       7       /* I/O: Scratch Register */
>  -
>  -static unsigned char *reg_base;
>  -static u32 reg_shift;
>  +#define UART_DLL               0       /* Out: Divisor Latch Low */
>  +#define UART_DLM               1       /* Out: Divisor Latch High */
>  +#define UART_FCR               2       /* Out: FIFO Control Register
*/
>  +#define UART_FCR_CLEAR_RCVR    0x02    /* Clear the RCVR FIFO */
>  +#define UART_FCR_CLEAR_XMIT    0x04    /* Clear the XMIT FIFO */
>  +#define UART_LCR               3       /* Out: Line Control Register
*/
>  +#define UART_MCR               4       /* Out: Modem Control
Register */
>  +#define UART_MCR_RTS           0x02    /* RTS complement */
>  +#define UART_MCR_DTR           0x01    /* DTR complement */
>  +#define UART_LSR               5       /* In:  Line Status Register
*/
>  +#define UART_LSR_THRE          0x20    /* Transmit-hold-register
empty */
>  +#define UART_LSR_DR            0x01    /* Receiver data ready */
>  +#define UART_LCR_DLAB          0x80    /* Divisor latch access bit
*/
>  +#define UART_LCR_WLEN8         0x03    /* Wordlength: 8 bits */
>  +#define UART_MSR               6       /* In:  Modem Status Register
*/
>  +#define UART_SCR               7       /* I/O: Scratch Register */
>  +
>  +volatile static unsigned char *reg_base;
>  +volatile static u32 reg_shift;
>  +volatile static u16 divisor;
>
>   static int ns16550_open(void)
>   {
>  -       out_8(reg_base + (UART_FCR << reg_shift), 0x06);
>  +
>  +       /* Access baud rate */
>  +       out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_DLAB);
>  +
>  +       /* Baud rate based on input clock */
>  +       out_8(reg_base + (UART_DLL << reg_shift), divisor & 0xFF);
>  +       out_8(reg_base + (UART_DLM << reg_shift), divisor >> 8);
>  +
>  +       /* 8 data, 1 stop, no parity */
>  +       out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_WLEN8);
>  +
>  +       /* RTS/DTR */
>  +       out_8(reg_base + (UART_MCR << reg_shift), UART_MCR_RTS |
UART_MCR_DTR);
>  +
>  +       /* Clear transmitter and receiver */
>  +       out_8(reg_base + (UART_FCR << reg_shift),
>  +                               UART_FCR_CLEAR_XMIT |
UART_FCR_CLEAR_RCVR);
>  +
>         return 0;
>   }
>
>  @@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
>   {
>         int n;
>         unsigned long reg_phys;
>  +       u32 clk, spd;
>
>         n =3D getprop(devp, "virtual-reg", &reg_base, =
sizeof(reg_base));
>         if (n !=3D sizeof(reg_base)) {
>  @@ -65,9 +90,23 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
>                 reg_base =3D (void *)reg_phys;
>         }
>
>  -       n =3D getprop(devp, "reg-shift", &reg_shift,
sizeof(reg_shift));
>  +       n =3D getprop(devp, "reg-shift", (void *)&reg_shift,
sizeof(reg_shift));
>         if (n !=3D sizeof(reg_shift))
>                 reg_shift =3D 0;
>  +
>  +       /* the base address has to change for devices with odd reg
spacing */
>  +       reg_base =3D reg_base + ((1 << reg_shift) - 1);
>  +
>  +       n =3D getprop(devp, "current-speed", (void *)&spd,
sizeof(spd));
>  +       if (n !=3D sizeof(spd))
>  +               spd =3D 9600;
>  +
>  +       /* should there be a default clock rate?*/
>  +       n =3D getprop(devp, "clock-frequency", (void *)&clk,
sizeof(clk));
>  +       if (n !=3D sizeof(clk))
>  +               return -1;
>  +
>  +       divisor =3D clk / (16 * spd);
>
>         scdp->open =3D ns16550_open;
>         scdp->putc =3D ns16550_putc;
>  --
>  1.5.2.1
>
>
>
>  _______________________________________________
>  Linuxppc-dev mailing list
>  Linuxppc-dev@ozlabs.org
>  https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: Grant Likely @ 2008-03-17 20:08 UTC (permalink / raw)
  To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080317195756.4F7411BE807D@mail119-dub.bigfish.com>

On Mon, Mar 17, 2008 at 1:57 PM, John Linn <John.Linn@xilinx.com> wrote:
> That makes sense.  Since I'm not using a boot loader I didn't realize
>  that.
>
>  I'm not sure how hard it will be to get the data from the device tree at
>  that time.

You should be good.  It is now possible to read data from the device
tree at platform_init() time.

Cheers,
g.

>  What about checking to see if it's setup assuming that's possible by
>  looking at registers, and then not messing with it if it's already
>  setup, otherwise do what my patch does.

Ugh.  The old arch/ppc code used to do this and it was kind of ugly
and fragile.  I'd rather avoid doing it again.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: John Linn @ 2008-03-17 20:10 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171308h5ef7f8a9m5119ef12d8c87980@mail.gmail.com>

Great, I'll do that.

Does this also apply to my other patch, Adding 8250 console support to
OF serial, as it's not clear to me when to assume the UART is already
setup or not?

Thanks,
John

-----Original Message-----
From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
Sent: Monday, March 17, 2008 2:08 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; jwboyer@linux.vnet.ibm.com
Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization

On Mon, Mar 17, 2008 at 1:57 PM, John Linn <John.Linn@xilinx.com> wrote:
> That makes sense.  Since I'm not using a boot loader I didn't realize
>  that.
>
>  I'm not sure how hard it will be to get the data from the device tree
at
>  that time.

You should be good.  It is now possible to read data from the device
tree at platform_init() time.

Cheers,
g.

>  What about checking to see if it's setup assuming that's possible by
>  looking at registers, and then not messing with it if it's already
>  setup, otherwise do what my patch does.

Ugh.  The old arch/ppc code used to do this and it was kind of ugly
and fragile.  I'd rather avoid doing it again.

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: Grant Likely @ 2008-03-17 20:13 UTC (permalink / raw)
  To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080317201035.CBCAC1468068@mail95-dub.bigfish.com>

On Mon, Mar 17, 2008 at 2:10 PM, John Linn <John.Linn@xilinx.com> wrote:
> Great, I'll do that.
>
>  Does this also apply to my other patch, Adding 8250 console support to
>  OF serial, as it's not clear to me when to assume the UART is already
>  setup or not?

I haven't reviewed that one yet.  I'll get to it this afternoon.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: Stephen Neuendorffer @ 2008-03-17 20:17 UTC (permalink / raw)
  To: Grant Likely, John Linn; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171308h5ef7f8a9m5119ef12d8c87980@mail.gmail.com>

Grant,

If you have working platform code using libfdt, can you publish it?

Steve

> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of =
Grant
Likely
> Sent: Monday, March 17, 2008 1:08 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization
>=20
> On Mon, Mar 17, 2008 at 1:57 PM, John Linn <John.Linn@xilinx.com>
wrote:
> > That makes sense.  Since I'm not using a boot loader I didn't
realize
> >  that.
> >
> >  I'm not sure how hard it will be to get the data from the device
tree at
> >  that time.
>=20
> You should be good.  It is now possible to read data from the device
> tree at platform_init() time.
>=20
> Cheers,
> g.
>=20
> >  What about checking to see if it's setup assuming that's possible
by
> >  looking at registers, and then not messing with it if it's already
> >  setup, otherwise do what my patch does.
>=20
> Ugh.  The old arch/ppc code used to do this and it was kind of ugly
> and fragile.  I'd rather avoid doing it again.
>=20
> Cheers,
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: [PATCH 2/3] Xilinx: hwicap: Verify sync before reading idcode.
From: Grant Likely @ 2008-03-17 20:18 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, linux-kernel
In-Reply-To: <20080317173645.7A21D9A8069@mail131-sin.bigfish.com>

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> It appears that in some cases, the sync word might not be recognized
>  by the hardware correctly.  If this happens, then attempting to read
>  from the port results in an unrecoverable error because of the design
>  of the FPGA core.  This patch updates the code to check the status of
>  the device before reading the IDCODE, in order to avoid entering this
>  unrecoverable state.  This patch also adds additional NOOP commands
>  into the sychronization sequence, which appears to be necessary to
>  avoid the condition on some hardware.
>
>  Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>

>  ---
>   drivers/char/xilinx_hwicap/xilinx_hwicap.c |   18 ++++++++++++++++++
>   1 files changed, 18 insertions(+), 0 deletions(-)
>
>  diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>  index 304727d..5b8d646 100644
>  --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>  +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>  @@ -250,8 +250,26 @@ static int hwicap_get_configuration_register(struct hwicap_drvdata *drvdata,
>          * Create the data to be written to the ICAP.
>          */
>         buffer[index++] = XHI_DUMMY_PACKET;
>  +       buffer[index++] = XHI_NOOP_PACKET;
>         buffer[index++] = XHI_SYNC_PACKET;
>         buffer[index++] = XHI_NOOP_PACKET;
>  +       buffer[index++] = XHI_NOOP_PACKET;
>  +
>  +       /*
>  +        * Write the data to the FIFO and initiate the transfer of data present
>  +        * in the FIFO to the ICAP device.
>  +        */
>  +       status = drvdata->config->set_configuration(drvdata,
>  +                                                   &buffer[0], index);
>  +       if (status)
>  +               return status;
>  +
>  +       /* If the syncword was not found, then we need to start over. */
>  +       status = drvdata->config->get_status(drvdata);
>  +       if ((status & XHI_SR_DALIGN_MASK) != XHI_SR_DALIGN_MASK)
>  +               return -EIO;
>  +
>  +       index = 0;
>         buffer[index++] = hwicap_type_1_read(reg) | 1;
>         buffer[index++] = XHI_NOOP_PACKET;
>         buffer[index++] = XHI_NOOP_PACKET;
>  --
>  1.5.3.4-dirty
>
>
>
>  --
>  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: powerpc: cuImage.* creation error
From: Paul Gortmaker @ 2008-03-17 20:07 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080317193652.GA9550@cs181133002.pp.htv.fi>

In message: powerpc: cuImage.* creation error
on 17/03/2008 Adrian Bunk wrote:

> When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
> them fail to build, and all with similar problems:
> 
> <--  snip  -->
> 
> 
> sbc8548_defconfig:
> 
> <--  snip  -->
> 
> ...
> Entry Point:  0x00000000
> make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed by `arch/powerpc/boot/zImage'.  Stop.
> 

Untested, but I'll guess that this is at least part of the problem for
the sbc one...

Thanks,
Paul.

---

Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Mon Mar 17 15:47:03 2008 -0400

    cuimage: fix board names in Makefile
    
    Fix the copy and paste error from 25431333813686654907ab987fb5de10c10a16db
    for the sbc8548 and sbc8560
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..1aded8f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540)			+= cuImage.tqm8540
 image-$(CONFIG_TQM8541)			+= cuImage.tqm8541
 image-$(CONFIG_TQM8555)			+= cuImage.tqm8555
 image-$(CONFIG_TQM8560)			+= cuImage.tqm8560
-image-$(CONFIG_SBC8548)			+= cuImage.tqm8548
-image-$(CONFIG_SBC8560)			+= cuImage.tqm8560
+image-$(CONFIG_SBC8548)			+= cuImage.sbc8548
+image-$(CONFIG_SBC8560)			+= cuImage.sbc8560
 
 # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
 image-$(CONFIG_STORCENTER)		+= cuImage.storcenter

^ permalink raw reply related

* Re: [PATCH 3/3] Xilinx: hwicap: Use fixed device major.
From: Grant Likely @ 2008-03-17 20:20 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, linux-kernel
In-Reply-To: <20080317173641.C8BE6640069@mail113-sin.bigfish.com>

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Major 259 has been assigned by lanana.  Use it.  Also, publish
>  /dev/icap[0-k] as the device entries, and register platform devices
>  named 'icap' to be consistent.
>
>  Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>

Looks good to me
Acked-by: Grant Likely <grant.likely@secretlab.ca>

>  ---
>   drivers/char/xilinx_hwicap/xilinx_hwicap.c |   43 +++++++++-------------------
>   1 files changed, 14 insertions(+), 29 deletions(-)
>
>  diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>  index 5b8d646..016f905 100644
>  --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>  +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>  @@ -36,7 +36,7 @@
>   *****************************************************************************/
>
>   /*
>  - * This is the code behind /dev/xilinx_icap -- it allows a user-space
>  + * This is the code behind /dev/icap* -- it allows a user-space
>   * application to use the Xilinx ICAP subsystem.
>   *
>   * The following operations are possible:
>  @@ -67,7 +67,7 @@
>   * user-space application code that uses this device.  The simplest
>   * way to use this interface is simply:
>   *
>  - * cp foo.bit /dev/xilinx_icap
>  + * cp foo.bit /dev/icap0
>   *
>   * Note that unless foo.bit is an appropriately constructed partial
>   * bitstream, this has a high likelyhood of overwriting the design
>  @@ -105,18 +105,14 @@
>   #include "buffer_icap.h"
>   #include "fifo_icap.h"
>
>  -#define DRIVER_NAME "xilinx_icap"
>  +#define DRIVER_NAME "icap"
>
>   #define HWICAP_REGS   (0x10000)
>
>  -/* dynamically allocate device number */
>  -static int xhwicap_major;
>  -static int xhwicap_minor;
>  +#define XHWICAP_MAJOR 259
>  +#define XHWICAP_MINOR 0
>   #define HWICAP_DEVICES 1
>
>  -module_param(xhwicap_major, int, S_IRUGO);
>  -module_param(xhwicap_minor, int, S_IRUGO);
>  -
>   /* An array, which is set to true when the device is registered. */
>   static bool probed_devices[HWICAP_DEVICES];
>   static struct mutex icap_sem;
>  @@ -605,7 +601,7 @@ static int __devinit hwicap_setup(struct device *dev, int id,
>         probed_devices[id] = 1;
>         mutex_unlock(&icap_sem);
>
>  -       devt = MKDEV(xhwicap_major, xhwicap_minor + id);
>  +       devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR + id);
>
>         drvdata = kzalloc(sizeof(struct hwicap_drvdata), GFP_KERNEL);
>         if (!drvdata) {
>  @@ -710,7 +706,7 @@ static int __devexit hwicap_remove(struct device *dev)
>         dev_set_drvdata(dev, NULL);
>
>         mutex_lock(&icap_sem);
>  -       probed_devices[MINOR(dev->devt)-xhwicap_minor] = 0;
>  +       probed_devices[MINOR(dev->devt)-XHWICAP_MINOR] = 0;
>         mutex_unlock(&icap_sem);
>         return 0;               /* success */
>   }
>  @@ -850,23 +846,12 @@ static int __init hwicap_module_init(void)
>         icap_class = class_create(THIS_MODULE, "xilinx_config");
>         mutex_init(&icap_sem);
>
>  -       if (xhwicap_major) {
>  -               devt = MKDEV(xhwicap_major, xhwicap_minor);
>  -               retval = register_chrdev_region(
>  -                               devt,
>  -                               HWICAP_DEVICES,
>  -                               DRIVER_NAME);
>  -               if (retval < 0)
>  -                       return retval;
>  -       } else {
>  -               retval = alloc_chrdev_region(&devt,
>  -                               xhwicap_minor,
>  -                               HWICAP_DEVICES,
>  -                               DRIVER_NAME);
>  -               if (retval < 0)
>  -                       return retval;
>  -               xhwicap_major = MAJOR(devt);
>  -       }
>  +       devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
>  +       retval = register_chrdev_region(devt,
>  +                                       HWICAP_DEVICES,
>  +                                       DRIVER_NAME);
>  +       if (retval < 0)
>  +               return retval;
>
>         retval = platform_driver_register(&hwicap_platform_driver);
>
>  @@ -891,7 +876,7 @@ static int __init hwicap_module_init(void)
>
>   static void __exit hwicap_module_cleanup(void)
>   {
>  -       dev_t devt = MKDEV(xhwicap_major, xhwicap_minor);
>  +       dev_t devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
>
>         class_destroy(icap_class);
>
>  --
>  1.5.3.4-dirty
>
>
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH 1/3] Xilinx: hwicap: Refactor status handling code.
From: Grant Likely @ 2008-03-17 20:23 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, linux-kernel
In-Reply-To: <20080317173644.C24651C00069@mail59-sin.bigfish.com>

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Both the buffer-based and fifo-based icap cores have a status
>  register.  Previously, this was only used internally to check whether
>  transactions have completed.  However, the status can be useful to the
>  main driver as well.  This patch exposes these status functions to the
>  main driver along with some masks for the differnet bits.
>
>  Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: Grant Likely @ 2008-03-17 20:24 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: John Linn, linuxppc-dev
In-Reply-To: <20080317201731.CED20181005E@mail146-sin.bigfish.com>

On Mon, Mar 17, 2008 at 2:17 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Grant,
>
>  If you have working platform code using libfdt, can you publish it?

Yes,

I've actually already published it once.  I'll post v2 this afternoon.

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: Stephen Neuendorffer @ 2008-03-17 20:25 UTC (permalink / raw)
  To: Grant Likely; +Cc: John Linn, linuxppc-dev
In-Reply-To: <fa686aa40803171324hfd813b5q896da8ff9b5875f0@mail.gmail.com>


Sorry, guess I missed it...
Steve

> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Monday, March 17, 2008 1:25 PM
> To: Stephen Neuendorffer
> Cc: John Linn; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization
>=20
> On Mon, Mar 17, 2008 at 2:17 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> > Grant,
> >
> >  If you have working platform code using libfdt, can you publish it?
>=20
> Yes,
>=20
> I've actually already published it once.  I'll post v2 this afternoon.
>=20
> g.
>=20
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.

^ permalink raw reply

* RE: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Nelson, Shannon @ 2008-03-17 20:34 UTC (permalink / raw)
  To: Olof Johansson, Williams, Dan J, Sosnowski, Maciej
  Cc: linuxppc-dev, pasemi-linux, linux-kernel, hskinnemoen
In-Reply-To: <20080316213002.GA2589@lixom.net>

>From: Olof Johansson [mailto:olof@lixom.net]=20
>Sent: Sunday, March 16, 2008 2:30 PM
>
>pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
>
>DMA copy offload driver for PA Semi PWRficient. It uses the
>platform-specific functions to allocate channels, etc.
>
>Signed-off-by: Olof Johansson <olof@lixom.net>
>
>---
>
>Changes since last post:
>
>* Add DMA_INTERRUPT support and handling of the interrupt flag
>* Fix interrupt handler for above and add tasklet
>* Switch to spin_lock_bh() where possible
>* Remove empty dependency_added() function since it's no longer
>  used in the framework.
>* Fix bug in "ring full" estimation.
>
>Note that this still needs to go on top of the powerpc.git=20
>tree due to the
>pasemi_dma.h updates that this driver depends on. I suggest=20
>merging this
>through pasemi.git->powerpc.git->linus with an Acked-by from=20
>the DMA guys.

Hi Olof,

In the future please copy Maciej as one of "the DMA guys" as he has
taken over ioatdma for me.  Beyond that, one little picky comment
below...


>
>
>-Olof
>
> [...]
>=20
>+
>+static unsigned int channels =3D 4;
>+module_param(channels, uint, S_IRUGO);
>+MODULE_PARM_DESC(channels, "Number of channels for copy=20
>(default: 2)");

Is the number of channels defaulting to 2 or 4?

sln

^ permalink raw reply

* Re: Interrupt handling documentation
From: Benjamin Herrenschmidt @ 2008-03-17 20:44 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803171713.51671.laurentp@cse-semaphore.com>


On Mon, 2008-03-17 at 17:13 +0100, Laurent Pinchart wrote:

> The PIC I am working with is linked to a falling-edge external irq on the 
> CPM2. When the first PIC interrupt was generated the kernel called the PIC 
> chained irq handler endlessly.
> 
> After some investigation it turned out the external interrupt bit in the CPM2 
> interrupt pending register never got cleared. set_irq_chained_handler() 
> registers the chained irq handler at the lowest level in the irq stack, 
> bypassing all the interrupt acknowledgement/masking logic.

Yes, exactly. To answer a previous question in the thread, the reason
there are two approaches to cascades is just that:

 - The "easy" approach using setup_irq(). The normal interrupt handling
is done for the cascade, it's masked/acked/whatever-is-needed as any
other interrupt before the second interrupt is fetched. This results
is slightly more kernel stack usage and overhead in getting to the
second interrupt, among other things, but is easier.

 - The "fast" approach using a chained handler. This, as you noticed,
bypass pretty much the whole stack and calls the chain handler directly.
That means that your chain handler is responsible to perform all the
necessary things to ensure the cascade interrupt is properly ack'ed
etc...
 
> The fix was easy, all I had to do was to call desc->chip->ack(irq) at the 
> beginning on the chained irq handler and desc->chip->eoi(irq) at the end. 

For an edge cascade, that would do, I suppose. But beware that if you
are only calling ack() and not mask(), then a subsequent chain interrupt
from the same cascade can (and will) potentially happen while you are
calling the handler as the cascade itself has been ack'ed and not
masked. In the case of cpm2, that also probably means you don't need to
call end().

That might be fine though, but it increases the chances of having of
stack overflows caused by interrupts stacking up.

> However, I'm wondering if this really belongs in the PIC code, or if PICs 
> shouldn't be registered at a higher level (setup_irq or even request_irq) so 
> that they would reuse the handle_*_irq handlers. Any opinion on this ?

They can. The chain handling mechanism is an optimisation. It avoids a
spinlock and other bits & pieces which improve performance & latency of
handling cascaded interrupts, at the expense of that added complexity.

Ben.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox