LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 07/11] swiotlb: use dma_map_range
From: Ian Campbell @ 2009-06-01 15:32 UTC (permalink / raw)
  To: linux-kernel
  Cc: Benjamin, x86, Jeremy Fitzhardinge, Tony Luck, Olaf, Ian Campbell,
	Kirch, Greg KH, FUJITA Tomonori, linuxppc-dev, linux-ia64
In-Reply-To: <1243870383-12954-1-git-send-email-ian.campbell@citrix.com>

This replaces usages of address_needs_mapping, range_needs_mapping and
is_buffer_dma_capable and the __weak architecture hooks to those
functions with a more flexible single function.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Olaf Kirch <okir@suse.de>
Cc: Greg KH <gregkh@suse.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Becky Bruce <beckyb@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: x86@kernel.org
Cc: linux-ia64@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
---
 arch/x86/kernel/pci-swiotlb.c |    5 ---
 include/linux/dma-mapping.h   |    5 ---
 include/linux/swiotlb.h       |    2 -
 lib/swiotlb.c                 |   59 +++++++++++++---------------------------
 4 files changed, 19 insertions(+), 52 deletions(-)

diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index e89cf99..fdcc0e2 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -23,11 +23,6 @@ void *swiotlb_alloc(unsigned order, unsigned long nslabs)
 	return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
 }
 
-int __weak swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size)
-{
-	return 0;
-}
-
 static void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 					dma_addr_t *dma_handle, gfp_t flags)
 {
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 8083b6a..85dafa1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -96,11 +96,6 @@ static inline int is_device_dma_capable(struct device *dev)
 	return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
 }
 
-static inline int is_buffer_dma_capable(u64 mask, dma_addr_t addr, size_t size)
-{
-	return addr + size <= mask;
-}
-
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 #else
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 954feec..1b56dbf 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -27,8 +27,6 @@ swiotlb_init(void);
 extern void *swiotlb_alloc_boot(size_t bytes, unsigned long nslabs);
 extern void *swiotlb_alloc(unsigned order, unsigned long nslabs);
 
-extern int swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size);
-
 extern void
 *swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 			dma_addr_t *dma_handle, gfp_t flags);
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index baa1991..d37499b 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -135,17 +135,6 @@ void * __weak swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
 	return phys_to_virt(dma_to_phys(hwdev, address));
 }
 
-int __weak swiotlb_arch_address_needs_mapping(struct device *hwdev,
-					       dma_addr_t addr, size_t size)
-{
-	return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
-}
-
-int __weak swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size)
-{
-	return 0;
-}
-
 static void swiotlb_print_info(unsigned long bytes)
 {
 	phys_addr_t pstart, pend;
@@ -305,17 +294,6 @@ cleanup1:
 	return -ENOMEM;
 }
 
-static inline int
-address_needs_mapping(struct device *hwdev, dma_addr_t addr, size_t size)
-{
-	return swiotlb_arch_address_needs_mapping(hwdev, addr, size);
-}
-
-static inline int range_needs_mapping(phys_addr_t paddr, size_t size)
-{
-	return swiotlb_force || swiotlb_arch_range_needs_mapping(paddr, size);
-}
-
 static int is_swiotlb_buffer(char *addr)
 {
 	return addr >= io_tlb_start && addr < io_tlb_end;
@@ -542,7 +520,7 @@ void *
 swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 		       dma_addr_t *dma_handle, gfp_t flags)
 {
-	dma_addr_t dev_addr;
+	phys_addr_t phys;
 	void *ret;
 	int order = get_order(size);
 	u64 dma_mask = DMA_BIT_MASK(32);
@@ -551,9 +529,8 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 		dma_mask = hwdev->coherent_dma_mask;
 
 	ret = (void *)__get_free_pages(flags, order);
-	if (ret &&
-	    !is_buffer_dma_capable(dma_mask, swiotlb_virt_to_bus(hwdev, ret),
-				   size)) {
+	if (ret && !dma_map_range(hwdev, dma_mask, virt_to_phys(ret),
+				  size, dma_handle)) {
 		/*
 		 * The allocated memory isn't reachable by the device.
 		 */
@@ -572,19 +549,19 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	}
 
 	memset(ret, 0, size);
-	dev_addr = swiotlb_virt_to_bus(hwdev, ret);
+	phys = virt_to_phys(ret);
 
 	/* Confirm address can be DMA'd by device */
-	if (!is_buffer_dma_capable(dma_mask, dev_addr, size)) {
-		printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
+	if (!dma_map_range(hwdev, dma_mask, phys, size, dma_handle)) {
+		printk(KERN_WARNING "hwdev DMA mask = 0x%016Lx, "
+				    "physical addr = 0x%016Lx\n",
 		       (unsigned long long)dma_mask,
-		       (unsigned long long)dev_addr);
+		       (unsigned long long)phys);
 
 		/* DMA_TO_DEVICE to avoid memcpy in unmap_single */
 		do_unmap_single(hwdev, ret, size, DMA_TO_DEVICE);
 		return NULL;
 	}
-	*dma_handle = dev_addr;
 	return ret;
 }
 EXPORT_SYMBOL(swiotlb_alloc_coherent);
@@ -636,7 +613,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
 			    struct dma_attrs *attrs)
 {
 	phys_addr_t phys = page_to_phys(page) + offset;
-	dma_addr_t dev_addr = phys_to_dma(dev, phys);
+	dma_addr_t dev_addr;
 	void *map;
 
 	BUG_ON(dir == DMA_NONE);
@@ -645,8 +622,8 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
 	 * we can safely return the device addr and not worry about bounce
 	 * buffering it.
 	 */
-	if (!address_needs_mapping(dev, dev_addr, size) &&
-	    !range_needs_mapping(phys, size))
+	if (dma_map_range(dev, dma_get_mask(dev), phys, size, &dev_addr) &&
+	    !swiotlb_force)
 		return dev_addr;
 
 	/*
@@ -658,12 +635,12 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
 		map = io_tlb_overflow_buffer;
 	}
 
-	dev_addr = swiotlb_virt_to_bus(dev, map);
+	phys = virt_to_phys(map);
 
 	/*
 	 * Ensure that the address returned is DMA'ble
 	 */
-	if (address_needs_mapping(dev, dev_addr, size))
+	if (!dma_map_range(dev, dma_get_mask(dev), phys, size, &dev_addr))
 		panic("map_single: bounce buffer is not DMA'ble");
 
 	return dev_addr;
@@ -807,10 +784,11 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
 
 	for_each_sg(sgl, sg, nelems, i) {
 		phys_addr_t paddr = sg_phys(sg);
-		dma_addr_t dev_addr = phys_to_dma(hwdev, paddr);
+		dma_addr_t uninitialized_var(dev_addr);
 
-		if (range_needs_mapping(paddr, sg->length) ||
-		    address_needs_mapping(hwdev, dev_addr, sg->length)) {
+		if (!dma_map_range(hwdev, dma_get_mask(hwdev), dev_addr,
+				   sg->length, &dev_addr) ||
+		    swiotlb_force) {
 			void *map = map_single(hwdev, sg_phys(sg),
 					       sg->length, dir);
 			if (!map) {
@@ -822,7 +800,8 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
 				sgl[0].dma_length = 0;
 				return 0;
 			}
-			sg->dma_address = swiotlb_virt_to_bus(hwdev, map);
+			paddr = virt_to_phys(map);
+			sg->dma_address = phys_to_dma(hwdev, paddr);
 		} else
 			sg->dma_address = dev_addr;
 		sg->dma_length = sg->length;
-- 
1.5.6.5

^ permalink raw reply related

* [PATCH 06/11] swiotlb: use dma_to_phys and phys_to_dma
From: Ian Campbell @ 2009-06-01 15:32 UTC (permalink / raw)
  To: linux-kernel
  Cc: Benjamin, x86, Jeremy Fitzhardinge, Tony Luck, Olaf, Ian Campbell,
	Kirch, Greg KH, FUJITA Tomonori, linuxppc-dev, linux-ia64
In-Reply-To: <1243870383-12954-1-git-send-email-ian.campbell@citrix.com>

These new architecture-specific interfaces subsume the existing __weak
function hooks.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Olaf Kirch <okir@suse.de>
Cc: Greg KH <gregkh@suse.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Becky Bruce <beckyb@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: x86@kernel.org
Cc: linux-ia64@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
---
 arch/x86/kernel/pci-swiotlb.c |   10 ----------
 include/linux/swiotlb.h       |    5 -----
 lib/swiotlb.c                 |   18 ++++--------------
 3 files changed, 4 insertions(+), 29 deletions(-)

diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index a1712f2..e89cf99 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -23,16 +23,6 @@ void *swiotlb_alloc(unsigned order, unsigned long nslabs)
 	return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
 }
 
-dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
-{
-	return paddr;
-}
-
-phys_addr_t swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
-{
-	return baddr;
-}
-
 int __weak swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size)
 {
 	return 0;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index cb1a663..954feec 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -27,11 +27,6 @@ swiotlb_init(void);
 extern void *swiotlb_alloc_boot(size_t bytes, unsigned long nslabs);
 extern void *swiotlb_alloc(unsigned order, unsigned long nslabs);
 
-extern dma_addr_t swiotlb_phys_to_bus(struct device *hwdev,
-				      phys_addr_t address);
-extern phys_addr_t swiotlb_bus_to_phys(struct device *hwdev,
-				       dma_addr_t address);
-
 extern int swiotlb_arch_range_needs_mapping(phys_addr_t paddr, size_t size);
 
 extern void
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index bffe6d7..baa1991 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -124,25 +124,15 @@ void * __weak swiotlb_alloc(unsigned order, unsigned long nslabs)
 	return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
 }
 
-dma_addr_t __weak swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
-{
-	return paddr;
-}
-
-phys_addr_t __weak swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
-{
-	return baddr;
-}
-
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
 {
-	return swiotlb_phys_to_bus(hwdev, virt_to_phys(address));
+	return phys_to_dma(hwdev, virt_to_phys(address));
 }
 
 void * __weak swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
 {
-	return phys_to_virt(swiotlb_bus_to_phys(hwdev, address));
+	return phys_to_virt(dma_to_phys(hwdev, address));
 }
 
 int __weak swiotlb_arch_address_needs_mapping(struct device *hwdev,
@@ -646,7 +636,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
 			    struct dma_attrs *attrs)
 {
 	phys_addr_t phys = page_to_phys(page) + offset;
-	dma_addr_t dev_addr = swiotlb_phys_to_bus(dev, phys);
+	dma_addr_t dev_addr = phys_to_dma(dev, phys);
 	void *map;
 
 	BUG_ON(dir == DMA_NONE);
@@ -817,7 +807,7 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
 
 	for_each_sg(sgl, sg, nelems, i) {
 		phys_addr_t paddr = sg_phys(sg);
-		dma_addr_t dev_addr = swiotlb_phys_to_bus(hwdev, paddr);
+		dma_addr_t dev_addr = phys_to_dma(hwdev, paddr);
 
 		if (range_needs_mapping(paddr, sg->length) ||
 		    address_needs_mapping(hwdev, dev_addr, sg->length)) {
-- 
1.5.6.5

^ permalink raw reply related

* [PATCH 00/11] swiotlb: Introduce architecture-specific APIs to replace __weak functions (v2)
From: Ian Campbell @ 2009-06-01 15:32 UTC (permalink / raw)
  To: linux-kernel
  Cc: x86, Jeremy Fitzhardinge, Tony Luck, linux-ia64, Ian Campbell,
	Olaf Kirch, Greg KH, FUJITA Tomonori, linuxppc-dev, Ingo Molnar

This series:
* removes the swiotlb_(arch_)_phys_to_bus and bus_to_phys __weak
  hooks, replacing them with an architecture-specific phys_to_dma and
  dma_to_phys interface. These are used by both PowerPC and Xen to
  provide the correct mapping from physical to DMA addresses.
* removes the swiotlb_address_needs_mapping and
  swiotlb_range_needs_mapping __weak functions as well as
  is_buffer_dma_capable (which should never have been a generic
  function). All three are replaced by a single architecture-specific
  interface which meets the needs of both PowerPC and Xen.
* removes the swiotlb_virt_to_bus __weak function and replaces it with
  a CONFIG_HIGHMEM compatible version when high memory is in use. This
  is needed for 32 bit PowerPC swiotlb support.
* removes the swiotlb_alloc* __weak functions and replaces them with
  swiotlb_init_with_buffer which allows the use of a caller allocated
  buffer (and emergency pool).

I think these new interfaces are cleaner than the existing __weak
functions and isolate the swiotlb code from architecture internals.

This series does not contain any Xen or PowerPC specific changes, those
will follow in separate postings. The complete patchset has been boot
tested under Xen and native-x86 and compiled for IA64 and PowerPC

Changes since v1: 
- Fixed compile error in swiotlb_dma_to_virt highmem version. Moved
  #ifdef into function to avoid prototype drift.
- checkpatch fixes.
- missed a swiotlb_arch_range_needs_mapping in swiotlb.h and x86
  pci-swiotlb.c and swiotlb_bus_to_phys/phys_to_bus implementations in
  x86.
- additionally replaced __weak swiotlb_alloc* with
  swiotlb_init_with_buffer.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Becky Bruce <beckyb@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Greg KH <gregkh@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Olaf Kirch <okir@suse.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: x86@kernel.org

^ permalink raw reply

* Re: [PATCH 1/4] net/phy/marvell: update m88e1111 support for SGMII mode
From: David Miller @ 2009-06-01  9:51 UTC (permalink / raw)
  To: Haiying.Wang; +Cc: linuxppc-dev, netdev
In-Reply-To: <12435168302841-git-send-email-Haiying.Wang@freescale.com>


Patch 3 of this series doesn't apply cleanly to net-next-2.6
so I'm dropping the entire patch set.

Also, in patch 3 you put your signoff in the Subject line.

Please fix all of this up and resubmit your patch series.

Thank you.

^ permalink raw reply

* Re: [Linux-fbdev-devel] [PATCH] GXT400P and GXT6500P support
From: Giuseppe Coviello @ 2009-06-01  7:32 UTC (permalink / raw)
  To: Krzysztof Helt; +Cc: linuxppc-dev, linux-fbdev-devel
In-Reply-To: <20090530134236.b97158c9.krzysztof.h1@poczta.fm>

Il giorno sab, 30/05/2009 alle 13.42 +0200, Krzysztof Helt ha scritto:
> On Wed, 27 May 2009 20:57:55 +0200
> Giuseppe Coviello <cjg@cruxppc.org> wrote:
> 
> > This patch adds support for GXT4000P and GXT6500P cards found on some
> > IBM pSeries machines.
> > GXT4000P/6000P and GXT4500P/6500P  couples are  identical from
> > software's point of view and are based on the same  Raster Engine
> > (RC1000), except for a different reference clock for the PLL.
> > GXT6x00P models are equipped with an additional Geometry Engine
> > (GT1000) but this driver doesn't use it.
> > 
> > Regards, Giuseppe
> > 
> > 
> 
> Please also change name of the option to reflect the fact it supports
> more than just the GXT4500P, e.g.
> 
> "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
> 
> Please cc the updated patch to the linuxppc-dev@ozlabs.org.
> 
> Regards,
> Krzysztof

I've made the changes that you have suggested.

Regards, Giuseppe

Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0048f11..7ee1e65 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1964,14 +1964,16 @@ config FB_PNX4008_DUM_RGB
 	  Say Y here to enable support for PNX4008 RGB Framebuffer
 
 config FB_IBM_GXT4500
-	tristate "Framebuffer support for IBM GXT4500P adaptor"
+	tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
 	depends on FB && PPC
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	---help---
-	  Say Y here to enable support for the IBM GXT4500P display
-	  adaptor, found on some IBM System P (pSeries) machines.
+	  Say Y here to enable support for the IBM GXT4000P/6000P and
+	  GXT4500P/6500P display adaptor based on Raster Engine RC1000,
+	  found on some IBM System P (pSeries) machines. This driver
+	  doesn't use Geometry Engine GT1000.
 
 config FB_PS3
 	tristate "PS3 GPU framebuffer driver"
diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
index 896e53d..a3c4d41 100644
--- a/drivers/video/gxt4500.c
+++ b/drivers/video/gxt4500.c
@@ -1,5 +1,6 @@
 /*
- * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
+ * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
+ * display adaptors
  *
  * Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
  */
@@ -14,6 +15,8 @@
 #include <linux/string.h>
 
 #define PCI_DEVICE_ID_IBM_GXT4500P	0x21c
+#define PCI_DEVICE_ID_IBM_GXT6500P      0x21b
+#define PCI_DEVICE_ID_IBM_GXT4000P      0x16e
 #define PCI_DEVICE_ID_IBM_GXT6000P	0x170
 
 /* GXT4500P registers */
@@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devinitdata = {
 /* List of supported cards */
 enum gxt_cards {
 	GXT4500P,
+	GXT6500P,
+	GXT4000P,
 	GXT6000P
 };
 
@@ -182,6 +187,8 @@ static const struct cardinfo {
 	const char *cardname;
 } cardinfo[] = {
 	[GXT4500P] = { .refclk_ps = 9259, .cardname = "IBM GXT4500P" },
+	[GXT6500P] = { .refclk_ps = 9259, .cardname = "IBM GXT6500P" },
+	[GXT4000P] = { .refclk_ps = 40000, .cardname = "IBM GXT4000P" },
 	[GXT6000P] = { .refclk_ps = 40000, .cardname = "IBM GXT6000P" },
 };
 
@@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev *pdev)
 static const struct pci_device_id gxt4500_pci_tbl[] = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
 	  .driver_data = GXT4500P },
+	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
+	  .driver_data = GXT6500P },
+	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
+	  .driver_data = GXT4000P },
 	{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
 	  .driver_data = GXT6000P },
 	{ 0 }
@@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
 module_exit(gxt4500_exit);
 
 MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
-MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
+MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
 MODULE_LICENSE("GPL");
 module_param(mode_option, charp, 0);
 MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");

^ permalink raw reply related

* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Joakim Tjernlund @ 2009-06-01  6:14 UTC (permalink / raw)
  To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <1243764699.3217.0@antares>

>
> Hi Jocke:
>
> Am 29.05.09 08:31 schrieb(en) Joakim Tjernlund:
> > > No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I
> > just
> >
> > I think this is true for most RISC based CPU's. It is a pity as
> > post ops are a lot more common. The do {} while(--chunks) is also
> > better. Basically the "while(--chunks)" is free(but only if you don't
> > use
> > chunks inside the loop).
>
> Just a side note:  I looked at the assembly output of gcc 4.3.3 coming
> with Ubuntu Jaunty/PowerPC for
>
> <snip case="1">
>    n >>= 2;
>    do {
>      *++dst = *++src;
>    } while (--n);
> <snip>
>
> and
>
> <snip case="2">
>    n >>= 2;
>    while (n--)
>      *dst++ = *src++;
> </snip>
>
> Using the gcc options "-O2 -mcpu=603e -mtune=603e" (same effect with
> "-O3" instead of "-O2") the loop core is *exactly* the same in both
> cases.

Yes, the compiler can/should optimize this but ...

>
> With gcc 4.2.2 (coming with ELDK 4.2) the loop core in case 2 is indeed
> one statement longer, though...

.. not even 4.2.2 which is fairly modern will get it right. It breaks very
easy as gcc has never been any good at this type of optimization. Sometimes
small changes will make gcc unhappy and it won't do the right optimization.

 Jocke

^ permalink raw reply

* Re: MPC8343 - serial8250: too much work
From: Michael Ellerman @ 2009-06-01  0:47 UTC (permalink / raw)
  To: Alemao; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d970ff420905291307p62e9c6eck772e7ee3757ee44a@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Fri, 2009-05-29 at 17:07 -0300, Alemao wrote:
> Im facing some problems with serial, linux-2.6.23, getting flooded
> with this message in logs:
> 
> ---
> serial8250: too much work for irq16
> ---
> 
> Something I notice, in my .dts I have the following lines:
> 
> serial0: serial@4500,  interrupts   =  <9  0x8>
> serial1: serial@4600,  interrupts   =  <10 0x8>
> spi:       spi@7000,     interrupts   =  <16 0x8>
> 
> 
> But when kernel starts:
> 
> ---
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> ---
> 
> Why IRQ 16? Shouldn't it be IRQ 9?

No. Interrupt numbers are remapped on powerpc. If you were running a
mainline kernel you'd see a message something like:

irq: irq 9 on host ?? mapped to virtual irq 16

cheers


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* is the resolution of do_gettimeofday in usec?
From: wael showair @ 2009-05-31 22:51 UTC (permalink / raw)
  To: linuxppc-dev


Hi All,
i have board that contains MPC8555 processor with linux 2.6.27 ported to it.
i want to use an accurate function to measure the time. i searched the
kernel code & i found several functions but i read that the do_gettimeofday
is the most accurate one since it has a timer resolution of usec.

my question is how this function give this accuracy while the kernel timer
is 4msec?
is this a real accuracy or does it convert from msec to usec?
or does it depend on another timer counter that has this resolution?
or may b it measure the clock cycles of the processor within certain
interval?

Note that the freq of the processor is 850MHz.

Unfortunately, the function is implemented in assembly & i cant understand
it?
so can u tell me how this accurate numbers can be got or they r just fake
numbers?

thanks
-- 
View this message in context: http://www.nabble.com/is-the-resolution-of-do_gettimeofday-in-usec--tp23807779p23807779.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

^ permalink raw reply

* Re: [PATCH] KVM: powerpc: beyond ARRAY_SIZE of vcpu->arch.guest_tlb
From: Avi Kivity @ 2009-05-31 12:00 UTC (permalink / raw)
  To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, paulmck, kvm
In-Reply-To: <4A15B129.8070700@gmail.com>

Roel Kluin wrote:
> Do not go beyond ARRAY_SIZE of vcpu->arch.guest_tlb
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index 0fce4fb..c2cfd46 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -125,7 +125,7 @@ static int kvmppc_emul_tlbwe(struct kvm_vcpu *vcpu, u32 inst)
>  	ws = get_ws(inst);
>  
>  	index = vcpu->arch.gpr[ra];
> -	if (index > PPC44x_TLB_SIZE) {
> +	if (index >= PPC44x_TLB_SIZE) {
>  		printk("%s: index %d\n", __func__, index);
>  		kvmppc_dump_vcpu(vcpu);
>  		return EMULATE_FAIL;
>   

This code no longer exists in kvm.git.

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply

* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Albrecht Dreß @ 2009-05-31 10:11 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFC4733C3C.0E94C44D-ONC12575C5.00215A32-C12575C5.0023DB18@transmode.se>

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

Hi Jocke:

Am 29.05.09 08:31 schrieb(en) Joakim Tjernlund:
> > No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I  
> just
> 
> I think this is true for most RISC based CPU's. It is a pity as
> post ops are a lot more common. The do {} while(--chunks) is also
> better. Basically the "while(--chunks)" is free(but only if you don't  
> use
> chunks inside the loop).

Just a side note:  I looked at the assembly output of gcc 4.3.3 coming  
with Ubuntu Jaunty/PowerPC for

<snip case="1">
   n >>= 2;
   do {
     *++dst = *++src;
   } while (--n);
<snip>

and

<snip case="2">
   n >>= 2;
   while (n--)
     *dst++ = *src++;
</snip>

Using the gcc options "-O2 -mcpu=603e -mtune=603e" (same effect with  
"-O3" instead of "-O2") the loop core is *exactly* the same in both  
cases.

With gcc 4.2.2 (coming with ELDK 4.2) the loop core in case 2 is indeed  
one statement longer, though...

Best, Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* mailing list moving
From: Stephen Rothwell @ 2009-05-31  5:09 UTC (permalink / raw)
  To: ppc-dev

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Hi all,

Sometime over the next few days I will be moving this mailing list from
ozlabs.org to lists.ozlabs.org.  The old submission address
(linuxppc-dev@ozlabs.org) will still work and I hope that references into
the archives will also still work (though I can't guarantee that as
rebuilding Mailman archives sometimes renumbers the individual emails).

The change that will affect people is the change in the List-Id header
(for those that filter using it).  It will become "List-Id: Linux on
PowerPC Developers Mail List <linuxppc-dev.lists.ozlabs.org>".

All subscriptions (and preferences) will be preserved.

I will post another message after I have moved it.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Frank Svendsbøe @ 2009-05-30 20:22 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Daniel Ng, Norbert van Bolhuis
In-Reply-To: <20090529171835.GB22066@b07421-ec1.am.freescale.net>

On Fri, May 29, 2009 at 7:18 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> On Fri, May 29, 2009 at 12:56:13PM +0200, Frank Svendsb=F8e wrote:
>> FYI. The same applies to mpc8xx targets: No default host interrupt contr=
oller.
>> The following patch was needed for our target:
>> ---
>> diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8=
xx_pic.c
>> index 5d2d552..92b2b66 100644
>> --- a/arch/powerpc/sysdev/mpc8xx_pic.c
>> +++ b/arch/powerpc/sysdev/mpc8xx_pic.c
>> @@ -186,6 +186,7 @@ int mpc8xx_pic_init(void)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOMEM;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> =A0 =A0 =A0 =A0 }
>> + =A0 =A0 =A0 =A0irq_set_default_host(mpc8xx_pic_host);
>> =A0 =A0 =A0 =A0 return 0;
>
> This patch is whitespace mangled.
>
>>
>> =A0out:
>> ---
>> Maybe setting a default host ought to be mandatory? Or is doing the
>> mapping manually
>> (without device tree descriptions) considered being a hack?
>
> I consider it a hack -- not so much doing it manually (though the device
> tree is better), but relying on a default interrupt controller when doing
> so. =A0IRQ numbers only make sense in the context of a specific
> controller. =A0It's especially misleading on 8xx, which has separate
> regular and CPM PICs.
>
> -Scott
>

I agree, and was the reason I mentioned "hack". The patch wasn't meant
for commit,
just for reference (sorry for whitemangling ;-)

Regarding doing manual mapping: Is there another way to retrieve the
host controller
from a driver module without modifying kernel source? In case not, do you t=
hink
exporting the mpc8xx_pic_host symbol is a better solution?

Anyway, now that I'm beginning to understand dts I guess I might as
well just do it properly.

- Frank

^ permalink raw reply

* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Wolfgang Grandegger @ 2009-05-30 17:59 UTC (permalink / raw)
  To: David Miller; +Cc: linuxppc-dev, devicetree-discuss, arnd, netdev
In-Reply-To: <4A1BFB73.4020305@grandegger.com>

Wolfgang Grandegger wrote:
> David Miller wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>> Date: Tue, 26 May 2009 10:10:30 +0100
>>
>>> On Monday 25 May 2009, Wolfgang Grandegger wrote:
>>>>> Right, that makes sense. However, most drivers use the field to store the
>>>>> physical address, not the iomap token. Maybe there should be a new field
>>>>> in struct sja1000_priv for the virtual address, but that would be a change
>>>>> to the base driver, not just to the OF portion.
>>>> Is that common practice? If yes, I will add a member to store the
>>>> virtual address to struct sja1000_priv.
>>> I grepped through the network driver for usage of ->base_addr, and
>>> it's somewhat inconsistent. The majority of the users use it for
>>> a physical address, but there are also a few that use it for the
>>> __iomem token.
>>>
>>> Casts between unsigned long and qualified (__iomem, __user, const, ...)
>>> pointers do not cause a warning, but can easily lead to bugs when
>>> another user casts to an unqualified pointer.
>> It's such a baroque thing, there is no reason to set it at all if you
>> ask me.  It's only use is to allow ISA and similar primitive bus
>> devices to have their I/O ports changed via ifconfig.
> 
> OK, I see, there are good reasons not to (mis-)use dev->base_addr. I
> will prepare a patch for the SJA1000 CAN drivers.

I have just sent out a patch series fixing this issue and providing
a revised patch for the SJA1000 OF platform driver:

[net-next-2.6 PATCH 0/3] can: sja1000: misused netdev->base_addr and OF platform driver

Wolfgang.

^ permalink raw reply

* Re: [PATCH 6/9] swiotlb: use dma_to_phys and phys_to_dma
From: Ian Campbell @ 2009-05-30 13:02 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: x86, Tony Luck, linux-ia64, Olaf Kirch, Greg KH, linux-kernel,
	FUJITA Tomonori, linuxppc-dev
In-Reply-To: <4A204EFC.501@goop.org>

On Fri, 2009-05-29 at 14:09 -0700, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> >  void * __weak swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
> >   
> 
> Does this need to be weak too?

It's was wanted by PowerPC to support highmem, that's what patch 8/9
tries to address in an arch-independent way.

Ian.

^ permalink raw reply

* Re: [PATCH 8/9] swiotlb: support HIGHMEM in swiotlb_bus_to_virt
From: Ian Campbell @ 2009-05-30 13:02 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: linux-kernel, FUJITA Tomonori, linuxppc-dev, Ingo Molnar
In-Reply-To: <4A20060C.2050701@goop.org>

On Fri, 2009-05-29 at 08:58 -0700, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:

> > -void * __weak swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
> > +#ifdef CONFIG_HIGHMEM
> > +static void * swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
> >   
> 
> I think it would be better to put the #ifdef within the function body so 
> that there's no chance of prototype-drift.

Yes, good idea.

> > +{
> > +	unsigned long pfn = PFN_DOWN(dma_to_phys(hwdev, addr));
> > +	void *pageaddr = page_address(pfn_to_page(pfn));
> > +
> > +	if (pageaddr != NULL)
> > +		return pageaddr + (addr % PAGE_SIZE);
> >   
> Is there an arch-independent test to see if a pfn is considered highmem 
> or not (which returns a constant on non-highmem configurations)?  If so, 
> then I think this could be common without having to go via a struct page.

I'm not aware of a way apart from PageHighMem -- which needs the struct
page. Highmem is a property of the zone, I think, so you have to go
through the struct page back to the zone to find out if it is high or
not.

At first glance it looks like many of the callers of bus_to_virt
eventually end up in swiotlb_bounce which converts to a struct page
anyway. I'll take a look next week whether it makes any sense to go to
struct page further up the call chain and pass that around instead.

Ian.

^ permalink raw reply

* Re: Delay on intialization ide subsystem(most likely)
From: Andrey Gusev @ 2009-05-30 10:46 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200905201756.14769.bzolnier@gmail.com>

On Wed, 20 May 2009 17:56:14 +0200
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Friday 15 May 2009 22:40:07 Andrey Gusev wrote:
> > On Wed, 13 May 2009 20:46:33 +0200
> > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > 
> > > On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote:
> > > > On Wed, 13 May 2009 15:28:26 +0200
> > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > 
> > > > > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote:
> > > > > > On Mon, 27 Apr 2009 23:21:48 +0200
> > > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > > > 
> > > > > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote:
> > > > > > > > On Sat, 25 Apr 2009 16:48:38 +0200
> > > > > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote:
> > > > > > > > > > Hello!
> > > > > > > > > > 
> > > > > > > > > > I have tested linux-2.6.30-rc3 on my system and find
> > > > > > > > > > some problems. One of them is delaying on
> > > > > > > > > > initialization IDE subsystem. I don't have this
> > > > > > > > > > problem on 2.6.29.1. The difference is looked on
> > > > > > > > > > log of dmesg.
> > > > > > > > > 
> > > > > > > > > Unfortunately this doesn't give us any hint about the
> > > > > > > > > root cause of the bug so please try narrowing the
> > > > > > > > > problem down to the specific change using git-bisect
> > > > > > > > > (sorry, there were 212 drivers/ide/ commits during
> > > > > > > > > v2.6.29..v2.6.30-rc3 and much much more
> > > > > > > > > non-drivers/ide/ ones).
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Bart
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Hello!
> > > > > > > > 
> > > > > > > > 
> > > > > > > > The full result of bisect is:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > git bisect start
> > > > > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux
> > > > > > > > 2.6.29 git bisect good
> > > > > > > > 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad:
> > > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux
> > > > > > > > 2.6.30-rc3 git bisect bad
> > > > > > > > 091069740304c979f957ceacec39c461d0192158 # good:
> > > > > > > > [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB
> > > > > > > > (11166): pvrusb2: Implement status fetching from
> > > > > > > > sub-devices git bisect good
> > > > > > > > 40f07111be99b71c1e8d40c13cdc38445add787f # good:
> > > > > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging:
> > > > > > > > sxg: slicoss: Specify the license for Sahara SXG and
> > > > > > > > Slicoss drivers git bisect good
> > > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8
> > > > > > > > 
> > > > > > > > 
> > > > > > > > git bisect start 'drivers/ide/'
> > > > > > > 
> > > > > > > Please note that limiting search space to drivers/ide/
> > > > > > > may not give reliable results in case problem was
> > > > > > > introduced by some other kernel area.
> > > > > > > 
> > > > > > > > # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8]
> > > > > > > > Staging: sxg: slicoss: Specify the license for Sahara
> > > > > > > > SXG and Slicoss drivers git bisect good
> > > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad:
> > > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux
> > > > > > > > 2.6.30-rc3 git bisect bad
> > > > > > > > 091069740304c979f957ceacec39c461d0192158 # good:
> > > > > > > > [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd:
> > > > > > > > convert cdrom_decode_status() to use switch statements
> > > > > > > > git bisect good
> > > > > > > > e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d # good:
> > > > > > > > [3153c26b54230d025c6d536e8d3015def4524906] ide:
> > > > > > > > refactor tf_read() method git bisect good
> > > > > > > > 3153c26b54230d025c6d536e8d3015def4524906 # good:
> > > > > > > > [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix
> > > > > > > > HPT370 DMA timeouts git bisect good
> > > > > > > > c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac # bad:
> > > > > > > > [d5f840bf74c09ca5a31e518c9d984999926b5f44] ide: Remove
> > > > > > > > void casts git bisect bad
> > > > > > > > d5f840bf74c09ca5a31e518c9d984999926b5f44 # bad:
> > > > > > > > [59c8d04f5ee97ea46da854e9adbbaa45d988c39d] hpt366: use
> > > > > > > > ATA_DMA_* constants git bisect bad
> > > > > > > > 59c8d04f5ee97ea46da854e9adbbaa45d988c39d
> > > > > > > 
> > > > > > > Uhh.. something went wrong during bisect.
> > > > > > > 
> > > > > > > "hpt366: use ATA_DMA_* constants" cannot be a first bad
> > > > > > > commit because hpt366 is not even used on this system.
> > > > > > > 
> > > > > > > Could it be that the delay doesn't happen on every boot
> > > > > > > for "bad" kernels?
> > > > > > > 
> > > > > > > Also, is 2.6.30-rc1 okay?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Bart
> > > > > > > 
> > > > > > 
> > > > > > Hello all!
> > > > > > 
> > > > > > I continue to find reason of bug. I made more testing with
> > > > > > bisect and got result:
> > > > > > 
> > > > > > git bisect start
> > > > > > # bad: [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366:
> > > > > > fix HPT370 DMA timeouts git bisect bad
> > > > > >  # good:
> > > > > > [fb4252e59452c18b88af014a2c4ee697bbf8cbc6] at91_ide: turn on
> > > > > > PIO 6 support git bisect good
> > > > > > fb4252e59452c18b88af014a2c4ee697bbf8cbc6 # good:
> > > > > > [2e1c63b7ed36532b68f0eddd6a184d7ba1013b89] Merge branch
> > > > > > 'for-rc1/xen/core' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git
> > > > > > bisect good 2e1c63b7ed36532b68f0eddd6a184d7ba1013b89 # bad:
> > > > > > [cd97824994042b809493807ea644ba26c0c23290] Merge
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
> > > > > > git bisect bad cd97824994042b809493807ea644ba26c0c23290 #
> > > > > > bad: [a2c252ebdeaab28c9b400570594d576dae295958] Merge
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes
> > > > > > git bisect bad a2c252ebdeaab28c9b400570594d576dae295958 #
> > > > > > good: [b897e6fbc49dd84b2634bca664344d503b907ce9] Merge
> > > > > > branch 'drm-intel-next' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
> > > > > > git bisect good b897e6fbc49dd84b2634bca664344d503b907ce9 #
> > > > > > good: [dfbc4752eab33e66f113f9daa2effbe241cd661d] brd:
> > > > > > support barriers git bisect good
> > > > > > dfbc4752eab33e66f113f9daa2effbe241cd661d # good:
> > > > > > [a23c218bd36e11120daf18e00a91d5dc20e288e6] Merge branch
> > > > > > 'merge' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
> > > > > > git bisect good a23c218bd36e11120daf18e00a91d5dc20e288e6 #
> > > > > > good: [23da64b4714812b66ecf010e7dfb3ed1bf2eda69] Merge
> > > > > > branch 'for-linus' of git://git.kernel.dk/linux-2.6-block
> > > > > > git bisect good 23da64b4714812b66ecf010e7dfb3ed1bf2eda69 #
> > > > > > good: [a228df6339e0d385b8149c860d81b6007f5e9c81] GFS2: Move
> > > > > > umount flush rwsem git bisect good
> > > > > > a228df6339e0d385b8149c860d81b6007f5e9c81 # skip:
> > > > > > [1328df725239804ae30fc7257c1a3185e679b517] GFS2: Use
> > > > > > DEFINE_SPINLOCK git bisect skip
> > > > > > 1328df725239804ae30fc7257c1a3185e679b517 # good:
> > > > > > [10d2198805d7faa2b193485446ff6b1de42c9b78] GFS2: cleanup
> > > > > > file_operations mess git bisect good
> > > > > > 10d2198805d7faa2b193485446ff6b1de42c9b78
> > > > > > 
> > > > > > As I understand, I found bad commit, but it includes 5
> > > > > > commits. I checked them and they are good. So, I did git
> > > > > > checkout a2c252ebdeaab28c9b400570594d576dae295958 and test
> > > > > > one more time this commit. I found that bag is unstable.
> > > > > > The boot can be bad or good on this commit. I compared
> > > > > > dmesg of 'bad' and 'good' booting, but it is equal till
> > > > > > delay. 
> > > > > 
> > > > > Thanks for doing it.
> > > > > 
> > > > > > Any suggestions?
> > > > > 
> > > > > Hard to tell...
> > > > > 
> > > > > I went through all commits in-between
> > > > > 
> > > > > 	fb4252e59452c18b88af014a2c4ee697bbf8cbc6
> > > > > 
> > > > > and
> > > > > 
> > > > > 	a2c252ebdeaab28c9b400570594d576dae295958
> > > > > 
> > > > > and there are no obvious candidates..
> > > > > 
> > > > > Could you please refresh my memory and tell me whether
> > > > > 2.6.30-rc2 was OK?
> > > > > 
> > > > 
> > > > It was ok, but I don't sure now. I tested only one boot, but
> > > > this problem is not stable. I am rechecking it.
> > > 
> > > Ok.
> > > 
> > > Please also recheck first 'good' commit if 2.6.30-rc2 turns out
> > > to be 'bad'.
> > 
> > My last testing is very interesting. I check boot of each kernel at
> > least 10 times. I checked 2.6.30-rc2, it is good. Rest results:
> > 
> > git bisect start
> > # good: [0882e8dd3aad33eca41696d463bb896e6c8817eb] Linux 2.6.30-rc2
> > git bisect good 0882e8dd3aad33eca41696d463bb896e6c8817eb
> > # bad: [a2c252ebdeaab28c9b400570594d576dae295958] Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes
> > git bisect bad a2c252ebdeaab28c9b400570594d576dae295958 # good:
> > [c2572f2b4ffc27ba79211aceee3bef53a59bb5cd] brd: fix cacheflushing
> > git bisect good c2572f2b4ffc27ba79211aceee3bef53a59bb5cd # bad:
> > [b71a0c296cee4debaf446760fbd29ead1587a7ac] powerpc: pseries/dtl.c
> > should include asm/firmware.h git bisect bad
> > b71a0c296cee4debaf446760fbd29ead1587a7ac
> > 
> > Last commit had delay only on 10 time, but it ripped my system, I
> > can't read any place on my hard drive. I can't mount any other
> > device on it. Fortunately, I have tmpfs and I mounted second hard
> > disk on it place. After my computer didn't turn on. It looks like
> > dead drive or controller, but after on/off and replace disks, it
> > has alived. Below is log of this bad boot.
> 
> I think that is an old problem which for some reasons gets triggered
> more easily in newer kernels or a hardware issue (or just combination
> of both).

Could it be RCU (it is experimental implementation in this configuratin)
related? I have booted 2.6.30-rc6, sometimes it has long delay (about 66
seconds) after: "[    0.000000] Experimental hierarchical RCU implementation."
Currently I have it enabled on 2.6.29.4 and don't have any problems. 
I made photos of boots and some faults:
http://img17.imageshack.us/img17/149/dscn4403b.jpg
http://img21.imageshack.us/img21/254/dscn4407v.jpg
http://img21.imageshack.us/img21/4919/dscn4413.jpg
http://img14.imageshack.us/img14/1230/dscn4414y.jpg
http://img13.imageshack.us/img13/878/dscn4419c.jpg
It is not very good photo, but it is difficult to shoot monitor.
It looks like same delay.

> 
> [...]
> 
> > > [ BTW the above bisection points that the problem was introduced
> > > outside of drivers/ide or that it was introduced earlier that we'd
> > > initially thought ]
> > > 
> > > > I have added second hard drive and got new issue. May be this
> > > > log (dmesg) can tell you something. It is on first known 'bad
> > > > commit'. 2.6.29.2 can't properly
> > > 
> > > It tells us that there is some IRQ routing problem... seems like a
> > > platform or ide-pmac specific problem.  Does some earlier kernel
> > > work OK with this configuration?
> > 
> > I have Debian's 2.6.26, it has same problem. Don't take attention
> > to time, I caught another bug on Aureal Vortex2, this driver kills
> > kernel completely and system time too. I am lucky on bugs on this
> > machine.
> 
> [...]
> 
> > [477194869.958131] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
> 
> [...]
> 
> > [477194895.065957] ide-pmac lost interrupt, dma status: 8480
> > [477194895.068535] hdb: lost interrupt
> > [477194895.070952] hdb: dma_intr: status=0x58 { DriveReady
> > SeekComplete DataRequest } [477194895.073444] ide: failed opcode
> > was: unknown [477194895.076053] hda: DMA disabled
> > [477194895.078504] hdb: DMA disabled
> > [477194895.209948] ide0: reset: success
> > [477194895.430619]  hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
> 
> This drive is one of the "quirky" drives which has special
> workarounds in some host drivers...
> 
> OK, lets try something else.  I went through IDE code and fixed
> outstanding issues which may be related to these problems + mixed-in
> pending bugfixes.

There is dmesg of 2.6.30-rc6 with patch, I could logged in only once, 
2 boots couldn't give me such ability.
[    0.000000] Using PowerMac machine description
[    0.000000] Total memory = 1536MB; using 4096kB for hash table (at cfc00000)
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.30-rc6 (andrey@power-debian) (gcc version 4.3.3 (Debian 4.3.3-10) ) #23 SMP PREEMPT Sat May 30 12:24:28 MSD 2009
[    0.000000] Found initrd at 0xc1a00000:0xc1f15800
[    0.000000] Found UniNorth memory controller & host bridge @ 0xf8000000 revision: 0x24
[    0.000000] Mapped at 0xff7c0000
[    0.000000] Found a Keylargo mac-io controller, rev: 3, mapped at 0xff740000
[    0.000000] PowerMac motherboard: PowerMac G4 Windtunnel
[    0.000000] CPU maps initialized for 1 thread per core
[    0.000000]  (thread shift is 0)
[    0.000000] console [udbg0] enabled
[    0.000000] Found UniNorth PCI host bridge at 0x00000000f0000000. Firmware bus number: 0->0
[    0.000000] PCI host bridge /pci@f0000000  ranges:
[    0.000000]  MEM 0x00000000f1000000..0x00000000f1ffffff -> 0x00000000f1000000 
[    0.000000]   IO 0x00000000f0000000..0x00000000f07fffff -> 0x0000000000000000
[    0.000000]  MEM 0x0000000090000000..0x00000000afffffff -> 0x0000000090000000 
[    0.000000] Found UniNorth PCI host bridge at 0x00000000f2000000. Firmware bus number: 0->0
[    0.000000] PCI host bridge /pci@f2000000 (primary) ranges:
[    0.000000]  MEM 0x00000000f3000000..0x00000000f3ffffff -> 0x00000000f3000000 
[    0.000000]   IO 0x00000000f2000000..0x00000000f27fffff -> 0x0000000000000000
[    0.000000]  MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 
[    0.000000] Found UniNorth PCI host bridge at 0x00000000f4000000. Firmware bus number: 0->0
[    0.000000] PCI host bridge /pci@f4000000  ranges:
[    0.000000]  MEM 0x00000000f5000000..0x00000000f5ffffff -> 0x00000000f5000000 
[    0.000000]   IO 0x00000000f4000000..0x00000000f47fffff -> 0x0000000000000000
[    0.000000] via-pmu: Server Mode is disabled
[    0.000000] PMU driver v2 initialized for Core99, firmware: 0c
[    0.000000] nvram: Checking bank 0...
[    0.000000] nvram: gen0=1392, gen1=1391
[    0.000000] nvram: Active bank is: 0
[    0.000000] nvram: OF partition at 0x410
[    0.000000] nvram: XP partition at 0x1020
[    0.000000] nvram: NR partition at 0x1120
[    0.000000] Top of RAM: 0x60000000, Total RAM: 0x60000000
[    0.000000] Memory hole size: 0MB
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00030000
[    0.000000]   Normal   0x00030000 -> 0x00030000
[    0.000000]   HighMem  0x00030000 -> 0x00060000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00060000
[    0.000000] On node 0 totalpages: 393216
[    0.000000] free_area_init_node: node 0, pgdat c042c4a0, node_mem_map c04a9000
[    0.000000]   DMA zone: 1536 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 195072 pages, LIFO batch:31
[    0.000000]   HighMem zone: 1536 pages used for memmap
[    0.000000]   HighMem zone: 195072 pages, LIFO batch:31
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 390144
[    0.000000] Kernel command line: root=/dev/mapper/power--group-root ro 
[    0.000000] Experimental hierarchical RCU implementation.
[    0.000000] Experimental hierarchical RCU init done.
[    0.000000] NR_IRQS:512
[    0.000000] mpic: Setting up MPIC " MPIC 1   " version 1.2 at 80040000, max 4 CPUs
[    0.000000] mpic: ISU size: 64, shift: 6, mask: 3f
[    0.000000] mpic: Initializing for 64 sources
[    0.000000] irq: irq 55 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 55
[    0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[    0.000000] GMT Delta read from XPRAM: 240 minutes, DST: on
[    0.000000] time_init: decrementer frequency = 33.304615 MHz
[    0.000000] time_init: processor frequency   = 866.666664 MHz
[    0.000000] clocksource: timebase mult[781a7d6] shift[22] registered
[    0.000000] clockevent: decrementer mult[886] shift[16] cpu[0]
[    0.000299] Console: colour dummy device 80x25
[    0.000467] console handover: boot [udbg0] -> real [tty0]
[    0.000703] irq: irq 22 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 22
[    0.000743] irq: irq 23 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 23
[    0.001698] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.002871] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.217079] High memory: 786432k
[    0.217091] Memory: 1544188k/1572864k available (4132k kernel code, 27588k reserved, 152k data, 332k bss, 224k init)
[    0.217248] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.217278] Calibrating delay loop... 66.56 BogoMIPS (lpj=332800)
[    0.430489] Security Framework initialized
[    0.430535] Mount-cache hash table entries: 512
[    0.431106] device-tree: Duplicate name in /cpus/PowerPC,G4@0/l2-cache, renamed to "l2-cache#1"
[    0.431211] device-tree: Duplicate name in /cpus/PowerPC,G4@0, renamed to "l2-cache#1"
[    0.431349] device-tree: Duplicate name in /cpus/PowerPC,G4@1/l2-cache, renamed to "l2-cache#1"
[    0.431447] device-tree: Duplicate name in /cpus/PowerPC,G4@1, renamed to "l2-cache#1"
[    0.434910] Initializing cgroup subsys ns
[    0.434928] Initializing cgroup subsys cpuacct
[    0.434955] Initializing cgroup subsys devices
[    0.434968] Initializing cgroup subsys freezer
[    0.435346] PowerMac SMP probe found 2 cpus
[    0.435461] irq: irq 42 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 42
[    0.435511] KeyWest i2c @0xf8001003 irq 42 /uni-n@f8000000/i2c@f8001000
[    0.435529]  channel 0 bus <multibus>
[    0.435540]  channel 1 bus <multibus>
[    0.435580] irq: irq 26 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 26
[    0.435595] KeyWest i2c @0x80018000 irq 26 /pci@f2000000/mac-io@17/i2c@18000
[    0.435616]  channel 0 bus <multibus>
[    0.435636] PMU i2c /pci@f2000000/mac-io@17/via-pmu@16000/pmu-i2c
[    0.435654]  channel 1 bus <multibus>
[    0.435668]  channel 2 bus <multibus>
[    0.435694] pmf: no parser for command 17 !
[    0.435755] Processor timebase sync using GPIO 0x73
[    0.435773] mpic: requesting IPIs ... 
[    0.435794] irq: irq 251 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 251
[    0.435812] irq: irq 252 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 252
[    0.435828] irq: irq 253 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 253
[    0.435845] irq: irq 254 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 254
[    0.435855] CPU0: L2CR is 80080000
[    0.435869] CPU0: L3CR is 8f0b0000
[477194875.410567] CPU1: L2CR was 80000
[477194875.410605] CPU1: L2CR set to 80080000
[477194875.410611] CPU1: L3CR was 0
[477194875.410772] CPU1: L3CR set to 8f0b0000
[    0.437521] Processor 1 found.
[    0.437581] clockevent: decrementer mult[886] shift[16] cpu[1]
[    0.437626] Brought up 2 CPUs
[    0.437800] CPU0 attaching sched-domain:
[    0.437810]  domain 0: span 0-1 level CPU
[    0.437819]   groups: 0 1
[    0.437836] CPU1 attaching sched-domain:
[    0.437843]  domain 0: span 0-1 level CPU
[    0.437850]   groups: 1 0
[    0.448443] net_namespace: 568 bytes
[    0.448942] NET: Registered protocol family 16
[    0.450512] irq: irq 25 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 25
[    0.450568] irq: irq 47 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 47
[    0.451112] PCI: Probing PCI hardware
[    0.451419] pci 0000:00:10.0: reg 10 32bit mmio: [0x91000000-0x91ffffff]
[    0.451432] pci 0000:00:10.0: reg 14 32bit mmio: [0x98000000-0x9fffffff]
[    0.451444] pci 0000:00:10.0: reg 18 32bit mmio: [0x000000-0x07ffff]
[    0.451467] pci 0000:00:10.0: reg 30 32bit mmio: [0x90000000-0x9001ffff]
[    0.451571] irq: irq 48 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 48
[    0.452134] pci 0001:10:15.0: reg 10 32bit mmio: [0x800c0000-0x800fffff]
[    0.452147] pci 0001:10:15.0: reg 14 io port: [0x410-0x417]
[    0.452159] pci 0001:10:15.0: reg 18 io port: [0x400-0x407]
[    0.452203] pci 0001:10:15.0: supports D2
[    0.452236] pci 0001:10:17.0: reg 10 32bit mmio: [0x80000000-0x8007ffff]
[    0.452299] pci 0001:10:18.0: reg 10 32bit mmio: [0x80081000-0x80081fff]
[    0.452365] pci 0001:10:19.0: reg 10 32bit mmio: [0x80080000-0x80080fff]
[    0.452466] irq: irq 58 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 58
[    0.452514] irq: irq 27 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 27
[    0.452560] irq: irq 28 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 28
[    0.453522] pci 0002:20:0d.0: reg 10 32bit mmio: [0xf5004000-0xf5007fff]
[    0.453589] pci 0002:20:0e.0: reg 10 32bit mmio: [0xf5000000-0xf5000fff]
[    0.453636] pci 0002:20:0e.0: supports D1 D2
[    0.453643] pci 0002:20:0e.0: PME# supported from D0 D1 D2 D3hot
[    0.453670] pci 0002:20:0e.0: PME# disabled
[    0.453709] pci 0002:20:0f.0: reg 10 32bit mmio: [0xf5200000-0xf53fffff]
[    0.453739] pci 0002:20:0f.0: reg 30 32bit mmio: [0xf5100000-0xf51fffff]
[    0.453820] irq: irq 39 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 39
[    0.453856] irq: irq 40 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 40
[    0.453896] irq: irq 41 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 41
[    0.454602] PCI 0001:10 Cannot reserve Legacy IO [0x00-0xfff]
[    0.454630] pci_bus 0000:00: resource 0 io:  [0x802000-0x1001fff]
[    0.454638] pci_bus 0000:00: resource 1 mem: [0xf1000000-0xf1ffffff]
[    0.454647] pci_bus 0000:00: resource 2 mem: [0x90000000-0xafffffff]
[    0.454655] pci_bus 0001:10: resource 0 io:  [0x00-0x7fffff]
[    0.454663] pci_bus 0001:10: resource 1 mem: [0xf3000000-0xf3ffffff]
[    0.454672] pci_bus 0001:10: resource 2 mem: [0x80000000-0x8fffffff]
[    0.454681] pci_bus 0002:20: resource 0 io:  [0xff7fe000-0xffffdfff]
[    0.454689] pci_bus 0002:20: resource 1 mem: [0xf5000000-0xf5ffffff]
[    0.509190] bio: create slab <bio-0> at 0
[    0.510100] usbcore: registered new interface driver usbfs
[    0.510328] usbcore: registered new interface driver hub
[    0.510530] usbcore: registered new device driver usb
[    0.557749] Switched to high resolution mode on CPU 0
[    0.558830] NET: Registered protocol family 2
[    0.567707] Switched to high resolution mode on CPU 1
[    0.657889] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.658894] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.661220] TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
[    0.662927] TCP: Hash tables configured (established 131072 bind 65536)
[    0.662957] TCP reno registered
[    0.687989] NET: Registered protocol family 1
[    0.688239] Trying to unpack rootfs image as initramfs...
[    1.026390] Freeing initrd memory: 5206k freed
[    1.027461] Thermal assist unit not available
[    1.028036] setup_kcore: restrict size=3fffffff
[    1.040922] audit: initializing netlink socket (disabled)
[    1.040982] type=2000 audit(1243661004.030:1): initialized
[    1.041564] highmem bounce pool size: 64 pages
[    1.050059] VFS: Disk quotas dquot_6.5.2
[    1.050438] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.068976] msgmni has been set to 1492
[    1.069868] alg: No test for stdrng (krng)
[    1.069953] alg: No test for stdrng (ansi_cprng)
[    1.069996] io scheduler noop registered
[    1.070012] io scheduler anticipatory registered
[    1.070028] io scheduler deadline registered
[    1.070275] io scheduler cfq registered (default)
[    1.080864] nvidiafb: Device ID: 10de0172 
[    1.117762] nvidiafb: CRTC0 analog not found
[    1.157725] nvidiafb: CRTC1 analog found
[    1.301505] i2c-adapter i2c-0: unable to read EDID block.
[    1.521499] i2c-adapter i2c-0: unable to read EDID block.
[    1.741499] i2c-adapter i2c-0: unable to read EDID block.
[    2.127735] nvidiafb: EDID found from BUS2
[    2.127783] nvidiafb: CRTC 1appears to have a CRT attached
[    2.127803] nvidiafb: Using CRT on CRTC 1
[    2.151593] Console: switching to colour frame buffer device 160x64
[    2.155252] nvidiafb: PCI nVidia NV17 framebuffer (32MB @ 0x98000000)
[    2.194786] Generic non-volatile memory driver v1.1
[    2.194964] Linux agpgart interface v0.103
[    2.195037] agpgart-uninorth 0000:00:0b.0: Apple UniNorth 2 chipset
[    2.195274] agpgart-uninorth 0000:00:0b.0: configuring for size idx: 8
[    2.195489] agpgart-uninorth 0000:00:0b.0: AGP aperture is 32M @ 0x0
[    2.195720] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    2.196765] pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
[    2.196843] ttyPZ0 at MMIO 0x80013020 (irq = 22) is a Z85c30 ESCC - Serial port
[    2.197041] ttyPZ1 at MMIO 0x80013000 (irq = 23) is a Z85c30 ESCC - Serial port
[    2.211980] brd: module loaded
[    2.214174] loop: module loaded
[    2.214293] MacIO PCI driver attached to Keylargo chipset
[    2.215251] irq: irq 32 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 32
[    2.215767] irq: irq 19 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 19
[    2.215791] irq: irq 11 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 16
[    2.215974] irq: irq 20 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 20
[    2.215997] irq: irq 12 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 17
[    2.216189] irq: irq 5 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 18
[    2.216212] irq: irq 6 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 21
[    2.216460] irq: irq 7 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 24
[    2.216483] irq: irq 8 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 29
[    2.217261] input: Macintosh mouse button emulation as /class/input/input0
[    2.218084] Uniform Multi-Platform E-IDE driver
[    2.220358] adb: starting probe task...
[    2.220432] adb: finished probe task...
[    2.220622] ide-pmac 0002:20:0d.0: enabling device (0000 -> 0002)
[    3.247734] ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
[    3.247823] Probing IDE interface ide0...
[    3.547915] hda: IBM-IC35L060AVVA07-0, ATA DISK drive
[    3.907729] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
[   66.830570] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[   66.830747] hda: UDMA/100 mode selected
[   66.830945] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[   66.831191] hdb: UDMA/66 mode selected
[   66.831568] ide0 at 0xf1012000-0xf1012070,0xf1012160 on irq 39
[   67.867729] ide-pmac: Found Apple KeyLargo ATA-4 controller (macio), bus ID 2, irq 19
[   67.867805] Probing IDE interface ide1...
[   68.477787] ide1 at 0xf100e000-0xf100e070,0xf100e160 on irq 19
[   68.477882] ide-pmac: probe of 0.0001f000:ata-4 failed with error -1
[   69.507728] ide-pmac: Found Apple KeyLargo ATA-3 controller (macio), bus ID 0, irq 20
[   69.507797] Probing IDE interface ide1...
[   69.927909] hdc: PHILIPS CDD5101, ATAPI CD/DVD-ROM drive
[   70.287747] sysfs: cannot create duplicate filename '/class/ide_port/ide1'
[   70.287841] ------------[ cut here ]------------
[   70.287879] Badness at fs/sysfs/dir.c:487
[   70.287914] NIP: c01119f0 LR: c01119f0 CTR: 00000000
[   70.287956] REGS: ef84db20 TRAP: 0700   Not tainted  (2.6.30-rc6)
[   70.289743] MSR: 00029032 <EE,ME,CE,IR,DR>  CR: 22000082  XER: 00000000
[   70.291580] TASK = ef850000[1] 'swapper' THREAD: ef84c000 CPU: 0
[   70.291632] GPR00: c01119f0 ef84dbd0 ef850000 00000051 00001032 ffffffff ffffffff 00000000 
[   70.293489] GPR08: f40e0000 00000001 00000000 00000000 42000044 00000000 0176c0fc 0176c120 
[   70.295353] GPR16: 0180ca40 0176c128 01795c40 0176bd24 c0221fa4 c044845c c039a164 ef99e0f8 
[   70.297238] GPR24: c1849b40 ef84dd08 c1846a88 ef84dc28 ffffffef ef84dbf8 c18442a0 ef823000 
[   70.300954] NIP [c01119f0] sysfs_add_one+0x7c/0xa0
[   70.302789] LR [c01119f0] sysfs_add_one+0x7c/0xa0
[   70.304606] Call Trace:
[   70.306415] [ef84dbd0] [c01119f0] sysfs_add_one+0x7c/0xa0 (unreliable)
[   70.308283] [ef84dbf0] [c01120f4] create_dir+0x58/0xb4
[   70.310140] [ef84dc20] [c011219c] sysfs_create_dir+0x4c/0x70
[   70.312019] [ef84dc40] [c01a498c] kobject_add_internal+0xdc/0x1b8
[   70.313895] [ef84dc60] [c01a4cac] kobject_add+0x80/0x98
[   70.315768] [ef84dc90] [c020b4b0] device_add+0xe0/0x5dc
[   70.317639] [ef84dcd0] [c020ba74] device_create_vargs+0x98/0xd0
[   70.319517] [ef84dd00] [c020baec] device_create+0x40/0x50
[   70.321402] [ef84dd30] [c02237d4] ide_host_register+0x370/0x690
[   70.323288] [ef84dd80] [c0301418] pmac_ide_setup_device+0x444/0x46c
[   70.325192] [ef84de00] [c03015f8] pmac_ide_macio_attach+0x1b8/0x218
[   70.327117] [ef84de60] [c02169cc] macio_device_probe+0x64/0x8c
[   70.329042] [ef84de80] [c020de1c] driver_probe_device+0xb8/0x180
[   70.330965] [ef84dea0] [c020df54] __driver_attach+0x70/0xa4
[   70.332885] [ef84dec0] [c020d5d0] bus_for_each_dev+0x5c/0xac
[   70.334797] [ef84def0] [c020dc48] driver_attach+0x24/0x34
[   70.336699] [ef84df00] [c020ce1c] bus_add_driver+0xb4/0x218
[   70.338596] [ef84df20] [c020e2f8] driver_register+0xd0/0x170
[   70.340493] [ef84df40] [c0216894] macio_register_driver+0x28/0x38
[   70.342385] [ef84df50] [c03f6f10] pmac_ide_probe+0x58/0x80
[   70.344284] [ef84df60] [c0003b50] do_one_initcall+0x58/0x1ac
[   70.346184] [ef84dfd0] [c03d1304] kernel_init+0x164/0x1d4
[   70.348074] [ef84dff0] [c0014d08] kernel_thread+0x4c/0x68
[   70.349948] Instruction dump:
[   70.351800] 807d0000 7fe4fb78 4bffff51 3c80c037 38848ff0 4bf0965d 809e0010 4bf09655 
[   70.353775] 7c641b78 3c60c038 38632db8 481e9f7d <0fe00000> 7fe3fb78 4bfa8629 80010024 
[   70.355775] kobject_add_internal failed for ide1 with -EEXIST, don't try to register things with the same name in the same directory.
[   70.357743] Call Trace:
[   70.359703] [ef84dc00] [c00089b8] show_stack+0x4c/0x14c (unreliable)
[   70.361695] [ef84dc40] [c01a4a38] kobject_add_internal+0x188/0x1b8
[   70.363670] [ef84dc60] [c01a4cac] kobject_add+0x80/0x98
[   70.365641] [ef84dc90] [c020b4b0] device_add+0xe0/0x5dc
[   70.367627] [ef84dcd0] [c020ba74] device_create_vargs+0x98/0xd0
[   70.369617] [ef84dd00] [c020baec] device_create+0x40/0x50
[   70.371573] [ef84dd30] [c02237d4] ide_host_register+0x370/0x690
[   70.373510] [ef84dd80] [c0301418] pmac_ide_setup_device+0x444/0x46c
[   70.375455] [ef84de00] [c03015f8] pmac_ide_macio_attach+0x1b8/0x218
[   70.377391] [ef84de60] [c02169cc] macio_device_probe+0x64/0x8c
[   70.379351] [ef84de80] [c020de1c] driver_probe_device+0xb8/0x180
[   70.381295] [ef84dea0] [c020df54] __driver_attach+0x70/0xa4
[   70.383215] [ef84dec0] [c020d5d0] bus_for_each_dev+0x5c/0xac
[   70.385116] [ef84def0] [c020dc48] driver_attach+0x24/0x34
[   70.386999] [ef84df00] [c020ce1c] bus_add_driver+0xb4/0x218
[   70.388870] [ef84df20] [c020e2f8] driver_register+0xd0/0x170
[   70.390709] [ef84df40] [c0216894] macio_register_driver+0x28/0x38
[   70.392540] [ef84df50] [c03f6f10] pmac_ide_probe+0x58/0x80
[   70.394362] [ef84df60] [c0003b50] do_one_initcall+0x58/0x1ac
[   70.396190] [ef84dfd0] [c03d1304] kernel_init+0x164/0x1d4
[   70.398026] [ef84dff0] [c0014d08] kernel_thread+0x4c/0x68
[   70.399861] ide1: disabling port
[   70.401669] ide-pmac: probe of 0.00020000:ata-3 failed with error -1
[   70.427747] ide-gd driver 1.18
[   70.429609] hda: max request size: 128KiB
[   70.460436] hda: 120103200 sectors (61492 MB) w/1863KiB Cache, CHS=65535/16/63
[   70.462627] hda: cache flushes supported
[   70.464632]  hda: [mac] hda1 hda2 hda3 hda4
[   70.547879] hdb: max request size: 128KiB
[   70.580518] hdb: 40132503 sectors (20547 MB) w/1900KiB Cache, CHS=39813/16/63
[   70.582303] hdb: cache flushes not supported
[   70.584122]  hdb:<3>ide-pmac lost interrupt, dma status: 8480
[   90.579564] hdb: lost interrupt
[   90.581310] hdb: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
[   90.583132] ide: failed opcode was: unknown
[   90.587331] hda: DMA disabled
[   90.589112] hdb: DMA disabled
[   90.627724] ide0: reset: success
[   90.672825]  hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
[   90.917748] ide-cd driver 5.00
[   90.937884] sungem.c:v0.98 8/24/03 David S. Miller (davem@redhat.com)
[   91.010625] PHY ID: 2060e1, addr: 0
[   91.028338] eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:93:ab:d1:a6
[   91.030163] eth0: Found BCM5421 PHY
[   91.040347] I2O subsystem v1.325
[   91.042144] i2o: max drivers = 8
[   91.087762] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   91.100344] ohci_hcd 0001:10:18.0: enabling device (0000 -> 0002)
[   91.102179] ohci_hcd 0001:10:18.0: OHCI Host Controller
[   91.110255] ohci_hcd 0001:10:18.0: new USB bus registered, assigned bus number 1
[   91.112135] ohci_hcd 0001:10:18.0: irq 27, io mem 0x80081000
[   91.190134] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[   91.191972] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   91.193788] usb usb1: Product: OHCI Host Controller
[   91.195595] usb usb1: Manufacturer: Linux 2.6.30-rc6 ohci_hcd
[   91.197404] usb usb1: SerialNumber: 0001:10:18.0
[   91.200246] usb usb1: configuration #1 chosen from 1 choice
[   91.205363] hub 1-0:1.0: USB hub found
[   91.207145] hub 1-0:1.0: 2 ports detected
[   91.218319] ohci_hcd 0001:10:19.0: enabling device (0000 -> 0002)
[   91.220048] ohci_hcd 0001:10:19.0: OHCI Host Controller
[   91.228334] ohci_hcd 0001:10:19.0: new USB bus registered, assigned bus number 2
[   91.230096] ohci_hcd 0001:10:19.0: irq 28, io mem 0x80080000
[   91.310106] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[   91.311850] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   91.313572] usb usb2: Product: OHCI Host Controller
[   91.315280] usb usb2: Manufacturer: Linux 2.6.30-rc6 ohci_hcd
[   91.316980] usb usb2: SerialNumber: 0001:10:19.0
[   91.320360] usb usb2: configuration #1 chosen from 1 choice
[   91.322333] hub 2-0:1.0: USB hub found
[   91.324056] hub 2-0:1.0: 2 ports detected
[   91.329247] mice: PS/2 mouse device common for all mice
[   91.333296] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[   91.335374] i2c /dev entries driver
[   91.347271] PowerMac i2c bus pmu 2 registered
[   91.350237] PowerMac i2c bus pmu 1 registered
[   91.352265] PowerMac i2c bus mac-io 0 registered
[   91.355253] PowerMac i2c bus uni-n 1 registered
[   91.357915] PowerMac i2c bus uni-n 0 registered
[   91.392391] usbcore: registered new interface driver hiddev
[   91.394300] usbcore: registered new interface driver usbhid
[   91.395993] usbhid: v2.6:USB HID core driver
[   91.399438] TCP cubic registered
[   91.401174] NET: Registered protocol family 17
[   91.406259] registered taskstats version 1
[   91.409248] input: PMU as /class/input/input1
[   91.411233] rtc-generic rtc-generic: setting system clock to 2009-05-30 09:24:55 UTC (1243675495)
[   91.412954] Freeing unused kernel memory: 224k init
[   91.567767] usb 1-1: new low speed USB device using ohci_hcd and address 2
[   91.771262] usb 1-1: New USB device found, idVendor=0458, idProduct=002e
[   91.773100] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   91.774854] usb 1-1: Product: NetScroll+ Traveler
[   91.776591] usb 1-1: Manufacturer: KYE
[   91.778545] usb 1-1: configuration #1 chosen from 1 choice
[   91.795245] input: KYE NetScroll+ Traveler as /class/input/input2
[   91.797245] generic-usb 0003:0458:002E.0001: input,hidraw0: USB HID v1.10 Mouse [KYE NetScroll+ Traveler] on usb-0001:10:18.0-1/input0
[   91.930350] usb 2-1: new full speed USB device using ohci_hcd and address 2
[   92.099280] usb 2-1: New USB device found, idVendor=05e3, idProduct=0608
[   92.101244] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   92.103076] usb 2-1: Product: USB2.0 Hub
[   92.105116] usb 2-1: configuration #1 chosen from 1 choice
[   92.107366] hub 2-1:1.0: USB hub found
[   92.110314] hub 2-1:1.0: 4 ports detected
[   92.421274] usb 2-1.1: new full speed USB device using ohci_hcd and address 3
[   92.539288] usb 2-1.1: New USB device found, idVendor=05e3, idProduct=0608
[   92.541329] usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   92.543199] usb 2-1.1: Product: USB2.0 Hub
[   92.545262] usb 2-1.1: configuration #1 chosen from 1 choice
[   92.548385] hub 2-1.1:1.0: USB hub found
[   92.551287] hub 2-1.1:1.0: 4 ports detected
[   92.671280] usb 2-1.2: new low speed USB device using ohci_hcd and address 4
[   92.840319] usb 2-1.2: New USB device found, idVendor=04d9, idProduct=0022
[   92.842323] usb 2-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[   92.844186] usb 2-1.2: Product: USB Keyboard
[   92.846274] usb 2-1.2: configuration #1 chosen from 1 choice
[   92.861967] input: USB Keyboard as /class/input/input3
[   92.864123] generic-usb 0003:04D9:0022.0002: input,hidraw1: USB HID v1.10 Keyboard [USB Keyboard] on usb-0001:10:19.0-1.2/input0
[   92.885524] input: USB Keyboard as /class/input/input4
[   92.896565] generic-usb 0003:04D9:0022.0003: input,hidraw2: USB HID v1.10 Device [USB Keyboard] on usb-0001:10:19.0-1.2/input1
[   93.027997] ohci1394 0002:20:0e.0: enabling device (0000 -> 0002)
[   93.092286] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[40]  MMIO=[f5000000-f50007ff]  Max Packet=[2048]  IR/IT contexts=[8/8]
[   93.410741] eth0: Link is up at 100 Mbps, full-duplex.
[   93.476753] device-mapper: uevent: version 1.0.3
[   93.479265] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
[   94.428052] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[000393fffeabd1a6]
[  144.839059] kjournald starting.  Commit interval 5 seconds
[  144.839087] EXT3-fs: mounted filesystem with ordered data mode.
[  149.327322] udev: starting version 141
[  149.327519] udev: deprecated sysfs layout; update the kernel or disable CONFIG_SYSFS_DEPRECATED; some udev features will not work correctly
[  282.139537] EXT3 FS on dm-1, internal journal
[  282.944448] SCSI subsystem initialized
[  283.019220] DS1775 digital thermometer [@49]
[  283.019391] Temp: 53.0 C  Hyst: 75.0 C  OS: 80.0 C
[  283.023309] ADM1030 fan controller [@2c]
[  283.027522] Reducing overheating limit to 65.0 C (Hyst: 60.0 C)
[  287.594082] kjournald starting.  Commit interval 5 seconds
[  287.607496] EXT3 FS on dm-3, internal journal
[  287.612410] EXT3-fs: mounted filesystem with ordered data mode.
[  287.669137] REISERFS (device dm-4): found reiserfs format "3.6" with standard journal
[  287.669362] REISERFS (device dm-4): using ordered data mode
[  287.682997] REISERFS (device dm-4): journal params: device dm-4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[  287.686423] REISERFS (device dm-4): checking transaction log (dm-4)
[  287.735102] REISERFS (device dm-4): Using r5 hash to sort names
[  287.861075] Adding 1048568k swap on /dev/mapper/power--group-swap_1.  Priority:-1 extents:1 across:1048568k 
[  289.571657] eth0: Link is up at 100 Mbps, full-duplex.
[  289.571732] eth0: Pause is enabled (rxfifo: 10240 off: 7168 on: 5632)
[  291.038766] CPU-temp: 53.1 C, Case: 32.2 C,  Fan: 0 (tuned -11)
[  305.202444] Process Xorg (pid:2982) mapped non-existing PCI legacy memory for 00000:00


> 
> The end result is a patch for 2.6.30-rc6 below, please try it.
> 
> diff --git a/drivers/ide/hpt366.c b/drivers/ide/hpt366.c
> index 0feb66c..7ce68ef 100644
> --- a/drivers/ide/hpt366.c
> +++ b/drivers/ide/hpt366.c
> @@ -138,14 +138,6 @@
>  #undef	HPT_RESET_STATE_ENGINE
>  #undef	HPT_DELAY_INTERRUPT
>  
> -static const char *quirk_drives[] = {
> -	"QUANTUM FIREBALLlct08 08",
> -	"QUANTUM FIREBALLP KA6.4",
> -	"QUANTUM FIREBALLP LM20.4",
> -	"QUANTUM FIREBALLP LM20.5",
> -	NULL
> -};
> -
>  static const char *bad_ata100_5[] = {
>  	"IBM-DTLA-307075",
>  	"IBM-DTLA-307060",
> @@ -729,27 +721,13 @@ static void hpt3xx_set_pio_mode(ide_drive_t
> *drive, const u8 pio) hpt3xx_set_mode(drive, XFER_PIO_0 + pio);
>  }
>  
> -static void hpt3xx_quirkproc(ide_drive_t *drive)
> -{
> -	char *m			= (char
> *)&drive->id[ATA_ID_PROD];
> -	const  char **list	= quirk_drives;
> -
> -	while (*list)
> -		if (strstr(m, *list++)) {
> -			drive->quirk_list = 1;
> -			return;
> -		}
> -
> -	drive->quirk_list = 0;
> -}
> -
>  static void hpt3xx_maskproc(ide_drive_t *drive, int mask)
>  {
>  	ide_hwif_t *hwif	= drive->hwif;
>  	struct pci_dev	*dev	= to_pci_dev(hwif->dev);
>  	struct hpt_info *info	= hpt3xx_get_info(hwif->dev);
>  
> -	if (drive->quirk_list == 0)
> +	if ((drive->dev_flags & IDE_DFLAG_NIEN_QUIRK) == 0)
>  		return;
>  
>  	if (info->chip_type >= HPT370) {
> @@ -1404,7 +1382,6 @@ static int __devinit hpt36x_init(struct pci_dev
> *dev, struct pci_dev *dev2) static const struct ide_port_ops
> hpt3xx_port_ops = { .set_pio_mode		=
> hpt3xx_set_pio_mode, .set_dma_mode		= hpt3xx_set_mode,
> -	.quirkproc		= hpt3xx_quirkproc,
>  	.maskproc		= hpt3xx_maskproc,
>  	.mdma_filter		= hpt3xx_mdma_filter,
>  	.udma_filter		= hpt3xx_udma_filter,
> diff --git a/drivers/ide/ide-eh.c b/drivers/ide/ide-eh.c
> index 5d5fb96..fab7e89 100644
> --- a/drivers/ide/ide-eh.c
> +++ b/drivers/ide/ide-eh.c
> @@ -408,8 +408,9 @@ static ide_startstop_t do_reset1(ide_drive_t
> *drive, int do_not_try_atapi) /* more than enough time */
>  	udelay(10);
>  	/* clear SRST, leave nIEN (unless device is on the quirk
> list) */
> -	tp_ops->write_devctl(hwif, (drive->quirk_list == 2 ? 0 :
> ATA_NIEN) |
> -			     ATA_DEVCTL_OBS);
> +	tp_ops->write_devctl(hwif,
> +		((drive->dev_flags & IDE_DFLAG_NIEN_QUIRK) ? 0 :
> ATA_NIEN) |
> +		 ATA_DEVCTL_OBS);
>  	/* more than enough time */
>  	udelay(10);
>  	hwif->poll_timeout = jiffies + WAIT_WORSTCASE;
> diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> index 35dc38d..a4622b8 100644
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -503,11 +503,15 @@ repeat:
>  
>  		if ((hwif->host->host_flags & IDE_HFLAG_SERIALIZE) &&
>  		    hwif != prev_port) {
> +			ide_drive_t *cur_dev =
> +				prev_port ? prev_port->cur_dev :
> NULL; +
>  			/*
>  			 * set nIEN for previous port, drives in the
> -			 * quirk_list may not like intr
> setups/cleanups
> +			 * quirk list may not like intr
> setups/cleanups */
> -			if (prev_port &&
> prev_port->cur_dev->quirk_list == 0)
> +			if (cur_dev &&
> +			    (cur_dev->dev_flags &
> IDE_DFLAG_NIEN_QUIRK) == 0) prev_port->tp_ops->write_devctl(prev_port,
>  								ATA_NIEN
> | ATA_DEVCTL_OBS);
> @@ -696,7 +700,7 @@ void ide_timer_expiry (unsigned long data)
>  		}
>  		spin_lock_irq(&hwif->lock);
>  		enable_irq(hwif->irq);
> -		if (startstop == ide_stopped) {
> +		if (startstop == ide_stopped && hwif->polling == 0) {
>  			ide_unlock_port(hwif);
>  			plug_device = 1;
>  		}
> @@ -868,7 +872,7 @@ irqreturn_t ide_intr (int irq, void *dev_id)
>  	 * same irq as is currently being serviced here, and Linux
>  	 * won't allow another of the same (on any CPU) until we
> return. */
> -	if (startstop == ide_stopped) {
> +	if (startstop == ide_stopped && hwif->polling == 0) {
>  		BUG_ON(hwif->handler);
>  		ide_unlock_port(hwif);
>  		plug_device = 1;
> diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
> index c19a221..c1b5e86 100644
> --- a/drivers/ide/ide-iops.c
> +++ b/drivers/ide/ide-iops.c
> @@ -269,6 +269,29 @@ no_80w:
>  	return 0;
>  }
>  
> +static const char *nien_quirk_list[] = {
> +	"QUANTUM FIREBALLlct08 08",
> +	"QUANTUM FIREBALLP KA6.4",
> +	"QUANTUM FIREBALLP KA9.1",
> +	"QUANTUM FIREBALLP KX13.6",
> +	"QUANTUM FIREBALLP KX20.5",
> +	"QUANTUM FIREBALLP KX27.3",
> +	"QUANTUM FIREBALLP LM20.4",
> +	"QUANTUM FIREBALLP LM20.5",
> +	NULL
> +};
> +
> +void ide_check_nien_quirk_list(ide_drive_t *drive)
> +{
> +	const char **list, *m = (char *)&drive->id[ATA_ID_PROD];
> +
> +	for (list = nien_quirk_list; *list != NULL; list++)
> +		if (strstr(m, *list) != NULL) {
> +			drive->dev_flags |= IDE_DFLAG_NIEN_QUIRK;
> +			return;
> +		}
> +}
> +
>  int ide_driveid_update(ide_drive_t *drive)
>  {
>  	u16 *id;
> @@ -352,7 +375,7 @@ int ide_config_drive_speed(ide_drive_t *drive, u8
> speed) 
>  	tp_ops->exec_command(hwif, ATA_CMD_SET_FEATURES);
>  
> -	if (drive->quirk_list == 2)
> +	if (drive->dev_flags & IDE_DFLAG_NIEN_QUIRK)
>  		tp_ops->write_devctl(hwif, ATA_DEVCTL_OBS);
>  
>  	error = __ide_wait_stat(drive, drive->ready_stat,
> diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
> index 7f264ed..2399bc0 100644
> --- a/drivers/ide/ide-probe.c
> +++ b/drivers/ide/ide-probe.c
> @@ -295,7 +295,7 @@ int ide_dev_read_id(ide_drive_t *drive, u8 cmd,
> u16 *id) 
>  	timeout = ((cmd == ATA_CMD_ID_ATA) ? WAIT_WORSTCASE :
> WAIT_PIDENTIFY) / 2; 
> -	if (ide_busy_sleep(hwif, timeout, use_altstatus))
> +	if (ide_busy_sleep(drive, timeout, use_altstatus))
>  		return 1;
>  
>  	/* wait for IRQ and ATA_DRQ */
> @@ -316,8 +316,9 @@ int ide_dev_read_id(ide_drive_t *drive, u8 cmd,
> u16 *id) return rc;
>  }
>  
> -int ide_busy_sleep(ide_hwif_t *hwif, unsigned long timeout, int
> altstatus) +int ide_busy_sleep(ide_drive_t *drive, unsigned long
> timeout, int altstatus) {
> +	ide_hwif_t *hwif = drive->hwif;
>  	u8 stat;
>  
>  	timeout += jiffies;
> @@ -330,6 +331,8 @@ int ide_busy_sleep(ide_hwif_t *hwif, unsigned
> long timeout, int altstatus) return 0;
>  	} while (time_before(jiffies, timeout));
>  
> +	printk(KERN_ERR "%s: timeout in %s\n", drive->name,
> __func__); +
>  	return 1;	/* drive timed-out */
>  }
>  
> @@ -420,7 +423,7 @@ static int do_probe (ide_drive_t *drive, u8 cmd)
>  			tp_ops->dev_select(drive);
>  			msleep(50);
>  			tp_ops->exec_command(hwif,
> ATA_CMD_DEV_RESET);
> -			(void)ide_busy_sleep(hwif, WAIT_WORSTCASE,
> 0);
> +			(void)ide_busy_sleep(drive, WAIT_WORSTCASE,
> 0); rc = ide_dev_read_id(drive, cmd, id);
>  		}
>  
> @@ -699,8 +702,12 @@ static int ide_probe_port(ide_hwif_t *hwif)
>  	if (irqd)
>  		disable_irq(hwif->irq);
>  
> -	if (ide_port_wait_ready(hwif) == -EBUSY)
> -		printk(KERN_DEBUG "%s: Wait for ready failed before
> probe !\n", hwif->name);
> +	rc = ide_port_wait_ready(hwif);
> +	if (rc == -ENODEV) {
> +		printk(KERN_INFO "%s: no devices on the port\n",
> hwif->name);
> +		goto out;
> +	} else if (rc == -EBUSY)
> +		printk(KERN_ERR "%s: not ready before the probe\n",
> hwif->name); 
>  	/*
>  	 * Second drive should only exist if first drive was found,
> @@ -711,7 +718,7 @@ static int ide_probe_port(ide_hwif_t *hwif)
>  		if (drive->dev_flags & IDE_DFLAG_PRESENT)
>  			rc = 0;
>  	}
> -
> +out:
>  	/*
>  	 * Use cached IRQ number. It might be (and is...) changed by
> probe
>  	 * code above
> @@ -729,6 +736,8 @@ static void ide_port_tune_devices(ide_hwif_t
> *hwif) int i;
>  
>  	ide_port_for_each_present_dev(i, drive, hwif) {
> +		ide_check_nien_quirk_list(drive);
> +
>  		if (port_ops && port_ops->quirkproc)
>  			port_ops->quirkproc(drive);
>  	}
> diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c
> index b68906c..65ba823 100644
> --- a/drivers/ide/pdc202xx_new.c
> +++ b/drivers/ide/pdc202xx_new.c
> @@ -40,18 +40,6 @@
>  #define DBG(fmt, args...)
>  #endif
>  
> -static const char *pdc_quirk_drives[] = {
> -	"QUANTUM FIREBALLlct08 08",
> -	"QUANTUM FIREBALLP KA6.4",
> -	"QUANTUM FIREBALLP KA9.1",
> -	"QUANTUM FIREBALLP LM20.4",
> -	"QUANTUM FIREBALLP KX13.6",
> -	"QUANTUM FIREBALLP KX20.5",
> -	"QUANTUM FIREBALLP KX27.3",
> -	"QUANTUM FIREBALLP LM20.5",
> -	NULL
> -};
> -
>  static u8 max_dma_rate(struct pci_dev *pdev)
>  {
>  	u8 mode;
> @@ -200,19 +188,6 @@ static u8 pdcnew_cable_detect(ide_hwif_t *hwif)
>  		return ATA_CBL_PATA80;
>  }
>  
> -static void pdcnew_quirkproc(ide_drive_t *drive)
> -{
> -	const char **list, *m = (char *)&drive->id[ATA_ID_PROD];
> -
> -	for (list = pdc_quirk_drives; *list != NULL; list++)
> -		if (strstr(m, *list) != NULL) {
> -			drive->quirk_list = 2;
> -			return;
> -		}
> -
> -	drive->quirk_list = 0;
> -}
> -
>  static void pdcnew_reset(ide_drive_t *drive)
>  {
>  	/*
> @@ -473,7 +448,6 @@ static struct pci_dev * __devinit
> pdc20270_get_dev2(struct pci_dev *dev) static const struct
> ide_port_ops pdcnew_port_ops = { .set_pio_mode		=
> pdcnew_set_pio_mode, .set_dma_mode		=
> pdcnew_set_dma_mode,
> -	.quirkproc		= pdcnew_quirkproc,
>  	.resetproc		= pdcnew_reset,
>  	.cable_detect		= pdcnew_cable_detect,
>  };
> diff --git a/drivers/ide/pdc202xx_old.c b/drivers/ide/pdc202xx_old.c
> index 248a54b..ed5df32 100644
> --- a/drivers/ide/pdc202xx_old.c
> +++ b/drivers/ide/pdc202xx_old.c
> @@ -23,18 +23,6 @@
>  
>  #define PDC202XX_DEBUG_DRIVE_INFO	0
>  
> -static const char *pdc_quirk_drives[] = {
> -	"QUANTUM FIREBALLlct08 08",
> -	"QUANTUM FIREBALLP KA6.4",
> -	"QUANTUM FIREBALLP KA9.1",
> -	"QUANTUM FIREBALLP LM20.4",
> -	"QUANTUM FIREBALLP KX13.6",
> -	"QUANTUM FIREBALLP KX20.5",
> -	"QUANTUM FIREBALLP KX27.3",
> -	"QUANTUM FIREBALLP LM20.5",
> -	NULL
> -};
> -
>  static void pdc_old_disable_66MHz_clock(ide_hwif_t *);
>  
>  static void pdc202xx_set_mode(ide_drive_t *drive, const u8 speed)
> @@ -151,19 +139,6 @@ static void
> pdc_old_disable_66MHz_clock(ide_hwif_t *hwif) outb(clock &
> ~(hwif->channel ? 0x08 : 0x02), clock_reg); }
>  
> -static void pdc202xx_quirkproc(ide_drive_t *drive)
> -{
> -	const char **list, *m = (char *)&drive->id[ATA_ID_PROD];
> -
> -	for (list = pdc_quirk_drives; *list != NULL; list++)
> -		if (strstr(m, *list) != NULL) {
> -			drive->quirk_list = 2;
> -			return;
> -		}
> -
> -	drive->quirk_list = 0;
> -}
> -
>  static void pdc202xx_dma_start(ide_drive_t *drive)
>  {
>  	if (drive->current_speed > XFER_UDMA_2)
> @@ -311,13 +286,11 @@ static void __devinit
> pdc202ata4_fixup_irq(struct pci_dev *dev, static const struct
> ide_port_ops pdc20246_port_ops = { .set_pio_mode		=
> pdc202xx_set_pio_mode, .set_dma_mode		=
> pdc202xx_set_mode,
> -	.quirkproc		= pdc202xx_quirkproc,
>  };
>  
>  static const struct ide_port_ops pdc2026x_port_ops = {
>  	.set_pio_mode		= pdc202xx_set_pio_mode,
>  	.set_dma_mode		= pdc202xx_set_mode,
> -	.quirkproc		= pdc202xx_quirkproc,
>  	.resetproc		= pdc202xx_reset,
>  	.cable_detect		= pdc2026x_cable_detect,
>  };
> diff --git a/include/linux/ide.h b/include/linux/ide.h
> index ff65fff..fa8ffe0 100644
> --- a/include/linux/ide.h
> +++ b/include/linux/ide.h
> @@ -474,6 +474,7 @@ enum {
>  	IDE_DFLAG_NICE1			= (1 << 5),
>  	/* device is physically present */
>  	IDE_DFLAG_PRESENT		= (1 << 6),
> +	IDE_DFLAG_NIEN_QUIRK		= (1 << 7),
>  	/* id read from device (synthetic if not set) */
>  	IDE_DFLAG_ID_READ		= (1 << 8),
>  	IDE_DFLAG_NOPROBE		= (1 << 9),
> @@ -543,7 +544,6 @@ struct ide_drive_s {
>  	u8	waiting_for_dma;	/* dma currently in
> progress */ u8	dma;			/* atapi dma flag */
>  
> -        u8	quirk_list;	/* considered quirky, set for a
> specific host */ u8	init_speed;	/* transfer rate set at
> boot */ u8	current_speed;	/* current transfer rate set
> */ u8	desired_speed;	/* desired transfer rate set */
> @@ -1109,7 +1109,7 @@ void ide_fix_driveid(u16 *);
>  
>  extern void ide_fixstring(u8 *, const int, const int);
>  
> -int ide_busy_sleep(ide_hwif_t *, unsigned long, int);
> +int ide_busy_sleep(ide_drive_t *, unsigned long, int);
>  
>  int ide_wait_stat(ide_startstop_t *, ide_drive_t *, u8, u8, unsigned
> long); 
> @@ -1464,6 +1464,7 @@ static inline void
> ide_acpi_set_state(ide_hwif_t *hwif, int on) {} void
> ide_register_region(struct gendisk *); void
> ide_unregister_region(struct gendisk *); 
> +void ide_check_nien_quirk_list(ide_drive_t *);
>  void ide_undecoded_slave(ide_drive_t *);
>  
>  void ide_port_apply_params(ide_hwif_t *);
> 
> 

^ permalink raw reply

* [git pull] dmaengine fixes for 2.6.30-rc8
From: Dan Williams @ 2009-05-30  0:19 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Ira W. Snyder, Roel Kluin, Maciej Sosnowski, linux-kernel,
	linuxppc-dev, Li Yang

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git fixes

...to receive:

Ira Snyder (4):
      fsldma: fix "DMA halt timeout!" errors
      fsldma: fix infinite loop on multi-descriptor DMA chain completion
      fsldma: snooping is not enabled for last entry in descriptor chain
      fsldma: fix memory leak on error path in fsl_dma_prep_memcpy()

Kumar Gala (1):
      fsldma: Fix compile warnings

Li Yang (1):
      fsldma: update mailling list address in MAINTAINERS

Roel Kluin (1):
      fsldma: fix check on potential fdev->chan[] overflow

 MAINTAINERS          |    2 +-
 drivers/dma/fsldma.c |   71 +++++++++++++++++++++++++++++++++-----------------
 2 files changed, 48 insertions(+), 25 deletions(-)

This is a collection of fsldma fixes primarily from Ira that have come
through Li Yang, fsldma maintainer.  I took the fix from Kumar as
obviously correct.  It has been in linux-next for at least one release.

Thanks,
Dan

commit b787f2e2a37a373a045f4d9b9bed941ccff01663
Author: Kumar Gala <galak@kernel.crashing.org>
Date:   Wed May 13 16:25:57 2009 -0500

    fsldma: Fix compile warnings
    
    We we build with dma_addr_t as a 64-bit quantity we get:
    
    drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
    drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different size
    drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
    drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
    drivers/dma/fsldma.c:737: warning: cast to pointer from integer of different size
    drivers/dma/fsldma.c: In function 'of_fsl_dma_probe':
    drivers/dma/fsldma.c:927: warning: cast to pointer from integer of different
    
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 2e077f8e8337e52eef3c39c24c31e103b11a0326
Author: Ira Snyder <iws@ovro.caltech.edu>
Date:   Fri May 15 09:59:46 2009 -0700

    fsldma: fix memory leak on error path in fsl_dma_prep_memcpy()
    
    When preparing a memcpy operation, if the kernel fails to allocate memory
    for a link descriptor after the first link descriptor has already been
    allocated, then some memory will never be released. Fix the problem by
    walking the list of allocated descriptors backwards, and freeing the
    allocated descriptors back into the DMA pool.
    
    Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
    Signed-off-by: Li Yang <leoli@freescale.com>

commit 776c8943f2766f2819fafd88fdfbaf418ecd6e41
Author: Ira Snyder <iws@ovro.caltech.edu>
Date:   Fri May 15 11:33:20 2009 -0700

    fsldma: snooping is not enabled for last entry in descriptor chain
    
    On the 83xx controller, snooping is necessary for the DMA controller to
    ensure cache coherence with the CPU when transferring to/from RAM.
    
    The last descriptor in a chain will always have the End-of-Chain interrupt
    bit set, so we can set the snoop bit while adding the End-of-Chain
    interrupt bit.
    
    Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
    Signed-off-by: Li Yang <leoli@freescale.com>

commit bcfb7465c03a8c62c89da374677df56f6b894d44
Author: Ira Snyder <iws@ovro.caltech.edu>
Date:   Fri May 15 14:27:16 2009 -0700

    fsldma: fix infinite loop on multi-descriptor DMA chain completion
    
    When creating a DMA transaction with multiple descriptors, the async_tx
    cookie is set to 0 for each descriptor in the chain, excluding the last
    descriptor, whose cookie is set to -EBUSY.
    
    When fsl_dma_tx_submit() is run, it only assigns a cookie to the first
    descriptor. All of the remaining descriptors keep their original value,
    including the last descriptor, which is set to -EBUSY.
    
    After the DMA completes, the driver will update the last completed cookie
    to be -EBUSY, which is an error code instead of a valid cookie. This causes
    dma_async_is_complete() to always return DMA_IN_PROGRESS.
    
    This causes the fsldma driver to never cleanup the queue of link
    descriptors, and the driver will re-run the DMA transaction on the hardware
    each time it receives the End-of-Chain interrupt. This causes an infinite
    loop.
    
    With this patch, fsl_dma_tx_submit() is changed to assign a cookie to every
    descriptor in the chain. The rest of the code then works without problems.
    
    Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
    Signed-off-by: Li Yang <leoli@freescale.com>

commit 138ef0185177a6d221d24b6aa8f12d867fbbef90
Author: Ira Snyder <iws@ovro.caltech.edu>
Date:   Tue May 19 15:42:13 2009 -0700

    fsldma: fix "DMA halt timeout!" errors
    
    When using the DMA controller from multiple threads at the same time, it is
    possible to get lots of "DMA halt timeout!" errors printed to the kernel
    log.
    
    This occurs due to a race between fsl_dma_memcpy_issue_pending() and the
    interrupt handler, fsl_dma_chan_do_interrupt(). Both call the
    fsl_chan_xfer_ld_queue() function, which does not protect against
    concurrent accesses to dma_halt() and dma_start().
    
    The existing spinlock is moved to cover the dma_halt() and dma_start()
    functions. Testing shows that the "DMA halt timeout!" errors disappear.
    
    Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
    Signed-off-by: Li Yang <leoli@freescale.com>

commit f47edc6dab11801c2e97088ba7bbce042ded867c
Author: Roel Kluin <roel.kluin@gmail.com>
Date:   Fri May 22 16:46:52 2009 +0800

    fsldma: fix check on potential fdev->chan[] overflow
    
    Fix the check of potential array overflow when using corrupted channel
    device tree nodes.
    
    Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
    Signed-off-by: Li Yang <leoli@freescale.com>

commit 0899d6349c60e4021224b51c8c97f49b829dfefd
Author: Li Yang <leoli@freescale.com>
Date:   Fri May 22 16:39:59 2009 +0800

    fsldma: update mailling list address in MAINTAINERS
    
    linuxppc-embedded has been merged into linuxppc-dev.
    
    Signed-off-by: Li Yang <leoli@freescale.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index 2b349ba..cac3e3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2241,7 +2241,7 @@ P:	Li Yang
 M:	leoli@freescale.com
 P:	Zhang Wei
 M:	zw@zh-kernel.org
-L:	linuxppc-embedded@ozlabs.org
+L:	linuxppc-dev@ozlabs.org
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
 F:	drivers/dma/fsldma.*
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index da8a8ed..f18d1bd 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -179,9 +179,14 @@ static void dma_halt(struct fsl_dma_chan *fsl_chan)
 static void set_ld_eol(struct fsl_dma_chan *fsl_chan,
 			struct fsl_desc_sw *desc)
 {
+	u64 snoop_bits;
+
+	snoop_bits = ((fsl_chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_83XX)
+		? FSL_DMA_SNEN : 0;
+
 	desc->hw.next_ln_addr = CPU_TO_DMA(fsl_chan,
-		DMA_TO_CPU(fsl_chan, desc->hw.next_ln_addr, 64)	| FSL_DMA_EOL,
-		64);
+		DMA_TO_CPU(fsl_chan, desc->hw.next_ln_addr, 64) | FSL_DMA_EOL
+			| snoop_bits, 64);
 }
 
 static void append_ld_queue(struct fsl_dma_chan *fsl_chan,
@@ -313,8 +318,8 @@ static void fsl_chan_toggle_ext_start(struct fsl_dma_chan *fsl_chan, int enable)
 
 static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
 {
-	struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
 	struct fsl_dma_chan *fsl_chan = to_fsl_chan(tx->chan);
+	struct fsl_desc_sw *desc;
 	unsigned long flags;
 	dma_cookie_t cookie;
 
@@ -322,14 +327,17 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
 	spin_lock_irqsave(&fsl_chan->desc_lock, flags);
 
 	cookie = fsl_chan->common.cookie;
-	cookie++;
-	if (cookie < 0)
-		cookie = 1;
-	desc->async_tx.cookie = cookie;
-	fsl_chan->common.cookie = desc->async_tx.cookie;
+	list_for_each_entry(desc, &tx->tx_list, node) {
+		cookie++;
+		if (cookie < 0)
+			cookie = 1;
 
-	append_ld_queue(fsl_chan, desc);
-	list_splice_init(&desc->async_tx.tx_list, fsl_chan->ld_queue.prev);
+		desc->async_tx.cookie = cookie;
+	}
+
+	fsl_chan->common.cookie = cookie;
+	append_ld_queue(fsl_chan, tx_to_fsl_desc(tx));
+	list_splice_init(&tx->tx_list, fsl_chan->ld_queue.prev);
 
 	spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
 
@@ -454,8 +462,8 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
 {
 	struct fsl_dma_chan *fsl_chan;
 	struct fsl_desc_sw *first = NULL, *prev = NULL, *new;
+	struct list_head *list;
 	size_t copy;
-	LIST_HEAD(link_chain);
 
 	if (!chan)
 		return NULL;
@@ -472,7 +480,7 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
 		if (!new) {
 			dev_err(fsl_chan->dev,
 					"No free memory for link descriptor\n");
-			return NULL;
+			goto fail;
 		}
 #ifdef FSL_DMA_LD_DEBUG
 		dev_dbg(fsl_chan->dev, "new link desc alloc %p\n", new);
@@ -507,7 +515,19 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
 	/* Set End-of-link to the last link descriptor of new list*/
 	set_ld_eol(fsl_chan, new);
 
-	return first ? &first->async_tx : NULL;
+	return &first->async_tx;
+
+fail:
+	if (!first)
+		return NULL;
+
+	list = &first->async_tx.tx_list;
+	list_for_each_entry_safe_reverse(new, prev, list, node) {
+		list_del(&new->node);
+		dma_pool_free(fsl_chan->desc_pool, new, new->async_tx.phys);
+	}
+
+	return NULL;
 }
 
 /**
@@ -598,15 +618,16 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
 	dma_addr_t next_dest_addr;
 	unsigned long flags;
 
+	spin_lock_irqsave(&fsl_chan->desc_lock, flags);
+
 	if (!dma_is_idle(fsl_chan))
-		return;
+		goto out_unlock;
 
 	dma_halt(fsl_chan);
 
 	/* If there are some link descriptors
 	 * not transfered in queue. We need to start it.
 	 */
-	spin_lock_irqsave(&fsl_chan->desc_lock, flags);
 
 	/* Find the first un-transfer desciptor */
 	for (ld_node = fsl_chan->ld_queue.next;
@@ -617,19 +638,20 @@ static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
 				fsl_chan->common.cookie) == DMA_SUCCESS);
 		ld_node = ld_node->next);
 
-	spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
-
 	if (ld_node != &fsl_chan->ld_queue) {
 		/* Get the ld start address from ld_queue */
 		next_dest_addr = to_fsl_desc(ld_node)->async_tx.phys;
-		dev_dbg(fsl_chan->dev, "xfer LDs staring from %p\n",
-				(void *)next_dest_addr);
+		dev_dbg(fsl_chan->dev, "xfer LDs staring from 0x%llx\n",
+				(unsigned long long)next_dest_addr);
 		set_cdar(fsl_chan, next_dest_addr);
 		dma_start(fsl_chan);
 	} else {
 		set_cdar(fsl_chan, 0);
 		set_ndar(fsl_chan, 0);
 	}
+
+out_unlock:
+	spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
 }
 
 /**
@@ -734,8 +756,9 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int irq, void *data)
 	 */
 	if (stat & FSL_DMA_SR_EOSI) {
 		dev_dbg(fsl_chan->dev, "event: End-of-segments INT\n");
-		dev_dbg(fsl_chan->dev, "event: clndar %p, nlndar %p\n",
-			(void *)get_cdar(fsl_chan), (void *)get_ndar(fsl_chan));
+		dev_dbg(fsl_chan->dev, "event: clndar 0x%llx, nlndar 0x%llx\n",
+			(unsigned long long)get_cdar(fsl_chan),
+			(unsigned long long)get_ndar(fsl_chan));
 		stat &= ~FSL_DMA_SR_EOSI;
 		update_cookie = 1;
 	}
@@ -830,7 +853,7 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
 			new_fsl_chan->reg.end - new_fsl_chan->reg.start + 1);
 
 	new_fsl_chan->id = ((new_fsl_chan->reg.start - 0x100) & 0xfff) >> 7;
-	if (new_fsl_chan->id > FSL_DMA_MAX_CHANS_PER_DEVICE) {
+	if (new_fsl_chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
 		dev_err(fdev->dev, "There is no %d channel!\n",
 				new_fsl_chan->id);
 		err = -EINVAL;
@@ -925,8 +948,8 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
 	}
 
 	dev_info(&dev->dev, "Probe the Freescale DMA driver for %s "
-			"controller at %p...\n",
-			match->compatible, (void *)fdev->reg.start);
+			"controller at 0x%llx...\n",
+			match->compatible, (unsigned long long)fdev->reg.start);
 	fdev->reg_base = ioremap(fdev->reg.start, fdev->reg.end
 						- fdev->reg.start + 1);
 

^ permalink raw reply related

* Re: ipr boot failure caused by MSI (2.6.30-rc1+)
From: Brian King @ 2009-05-29 22:01 UTC (permalink / raw)
  To: James Bottomley; +Cc: ppc-dev, Wayne Boyer, linux-scsi
In-Reply-To: <1243009395.2873.18.camel@localhost.localdomain>

James Bottomley wrote:
> On Thu, 2009-05-21 at 14:51 -0500, James Bottomley wrote:
>> On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
>>> cc'ing linuxppc-dev...
>>>
>>> -Brian
>>>
>>>
>>> James Bottomley wrote:
>>>> Kernels after 2.6.30-rc1 stopped booting on my powerstation.  The ipr
>>>> just times out and refuses to probe devices.  If I let it drop into the
>>>> initramfs system, this is what the interrupts shows:
>>>>
>>>> (initramfs) cat /proc/interrupts 
>>>>            CPU0       CPU1       CPU2       CPU3       
>>>>  16:         20         10         13         11   MPIC      Level     pata_amd
>>>>  20:          0          0          0          0   MPIC      Level     ohci_hcd:usb1, ohci_hcd:usb2
>>>>  21:          0          0          0          0  MPIC-U3MSI Edge      ipr
>>>>  68:         37         37         48         37   MPIC      Edge      serial
>>>> 251:         10         71         69         72   MPIC      Edge      ipi call function
>>>> 252:       1555       1779       1372       1155   MPIC      Edge      ipi reschedule
>>>> 253:          0          0          0          0   MPIC      Edge      ipi call function single
>>>> 254:          0          0          0          0   MPIC      Edge      ipi debugger
>>>> BAD:        416
>>>>
>>>> So you see the IPR is the only device not receiving them.
>>>>
>>>> I can fix the boot hang by reverting
>>>>
>>>> commit 5a9ef25b14d39b8413364df12cb8d9bb7a673a32
>>>> Author: Wayne Boyer <wayneb@linux.vnet.ibm.com>
>>>> Date:   Fri Jan 23 09:17:35 2009 -0800
>>>>
>>>>     [SCSI] ipr: add MSI support
>>>>
>>>> The system in question is:
>>>>
>>>> SYSTEM INFORMATION
>>>>  Processor  = PowerPC,970MP @ 2500 MHz
>>>>  I/O Bridge = U4 (4.4)
>>>>  SMP Size   = 4 (#0 #1 #2 #3)
>>>>  Boot-Date  = 2009-04-21 17:13:36
>>>>  Memory     = 2 GB of RAM @ 666 MHz
>>>>  Board Type = Bimini (7047191/0000000/1)
>>>>  MFG Date   = 1608
>>>>  Part No.   = 10N8748     
>>>>  FRU No.    = 10N7182     
>>>>  FRU Serial = YL30W8106038
>>>>  UUID       = 00000000000000000000000000000000
>>>>  Flashside  = 1 (temporary)
>>>>  Version    = HEAD
>>>>  Build Date = 12-04-2008 16:13
>> OK, so as an update, I booted to the initrd and inserted the network
>> modules, which are also MSI enabled and this is what I get:
>>
>> (initramfs) cat /proc/interrupts 
>>            CPU0       CPU1       CPU2       CPU3       
>>  16:         14         11         11         18   MPIC      Level     pata_amd
>>  20:          0          0          0          0   MPIC      Level     ohci_hcd:usb1, ohci_hcd:usb2
>>  21:          0          0          0          0  MPIC-U3MSI Edge      ipr
>>  22:          1          0          1          0  MPIC-U3MSI Edge      eth0
>>  23:          0          2          1          0  MPIC-U3MSI Edge      eth1
>>  68:        193        166        113        177   MPIC      Edge      serial
>> 251:         16         65         71         70   MPIC      Edge      ipi call function
>> 252:       1574       1804       1346       1289   MPIC      Edge      ipi reschedule
>> 253:          0          0          0          0   MPIC      Edge      ipi call function single
>> 254:          0          0          0          0   MPIC      Edge      ipi debugger
>> BAD:       1866
>>
>> So clearly the MSI interrupts to the network cards are working and it
>> looks like just a local problem with the ipr rather than a platform
>> problem with MSI.
> 
> I saw the quirk fix for this go by:
> 
> http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072436.html
> 
> Is there an easy way to trigger an interrupt on this device?  Preferably
> in ipr_probe_ioa() so we can at least print out if the interrupts are
> misrouted and fall back from MSI to normal using the PCI infrastructure?

I just talked with one of the adapter firmware developers and it sounds like
this might be possible. I'll work with Wayne on coding something up to try.

-Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center

^ permalink raw reply

* Re: [PATCH 6/9] swiotlb: use dma_to_phys and phys_to_dma
From: Jeremy Fitzhardinge @ 2009-05-29 21:09 UTC (permalink / raw)
  To: Ian Campbell
  Cc: x86, Tony Luck, linux-ia64, Olaf Kirch, Greg KH, linux-kernel,
	FUJITA Tomonori, linuxppc-dev
In-Reply-To: <1243586643-5554-7-git-send-email-ian.campbell@citrix.com>

Ian Campbell wrote:
> static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
>  				      volatile void *address)
>  {
> -	return swiotlb_phys_to_bus(hwdev, virt_to_phys(address));
> +	return phys_to_dma(hwdev, virt_to_phys(address));
>  }
>  
>  void * __weak swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
>   

Does this need to be weak too?

    J

^ permalink raw reply

* Re: fastboot.
From: John Rigby @ 2009-05-29 20:45 UTC (permalink / raw)
  To: Kenneth Johansson; +Cc: linuxppc-dev
In-Reply-To: <4b73d43f0905291330i67c20bd3y2fa3f1a127077b74@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2551 bytes --]

One more thing.  You can get another speed up if you can do burst reads from
NOR.  This requires using the fifo in the local bus controller.  On the
ADS5121 board you need a cpld change to increment the address lines.  With
the cpld as shipped you end up reading bursts that have the first 4 bytes
repeated because the address lines do not increment.  I don't know if this
is feature or bug with the 5121 but I do know you can work around it in the
cpld.

With burst access working you should be able to speed up the kernel copy and
also the jffs2 mount and filesystem access.

I also found that coping an uncompressed kernel was faster than
decompressing a compressed kernel.  But your mileage may vary if you have
the data cache on.  I found that working around all the problems with
turning data cache on were going to take more time than I had.

John

On Fri, May 29, 2009 at 2:30 PM, John Rigby <jcrigby@gmail.com> wrote:

> Kenneth,
>
> I did some fastboot work for 5121 a few months ago.  U-boot, kernel and
> JFFS2 rootfs in NOR.  My reset to userland time was 2.0 seconds, where
> userland was first command executed in first rc.whatever file, so it
> included the time for /sbin/init to get up and start running the rc scripts.
>
> I did some profiling and noticed that the JFFS2 boot time was a significant
> hunk (not just the first time but everytime).  I ran sumtool on the JFFS2
> image and it dropped 600 ms from the boot time so my final time was 1.4
> seconds.  The sumtool program has been around for a few years but it was
> news to mean when I found it.
>
> John
>
>
> On Fri, May 29, 2009 at 5:13 AM, Kenneth Johansson <kenneth@southpole.se>wrote:
>
>> http://www.cambridgewireless.co.uk/news/article/default.aspx?objid=36792
>>
>> Anybody know what they mean by booting here.
>>
>> I have started the ads5121 board using u-boot and kernel in NOR flash
>> and root file system on a compact flash card connected to the IDE
>> interface in 2.05 second until init is started from the rootfs.
>>
>> This was fast enough for what was needed I did not try to optimize
>> further but since I already was in the domain where changes impacted
>> only a few milliseconds I have a hard time imagining going down to less
>> than a second.
>>
>> So I guess the only way is to skip u-boot and run linux kernel directly
>> out of NOR. Anyone know what MontaVista is doing ??
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3462 bytes --]

^ permalink raw reply

* Re: fastboot.
From: John Rigby @ 2009-05-29 20:30 UTC (permalink / raw)
  To: Kenneth Johansson; +Cc: linuxppc-dev
In-Reply-To: <1243595599.9769.35.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

Kenneth,

I did some fastboot work for 5121 a few months ago.  U-boot, kernel and
JFFS2 rootfs in NOR.  My reset to userland time was 2.0 seconds, where
userland was first command executed in first rc.whatever file, so it
included the time for /sbin/init to get up and start running the rc scripts.

I did some profiling and noticed that the JFFS2 boot time was a significant
hunk (not just the first time but everytime).  I ran sumtool on the JFFS2
image and it dropped 600 ms from the boot time so my final time was 1.4
seconds.  The sumtool program has been around for a few years but it was
news to mean when I found it.

John

On Fri, May 29, 2009 at 5:13 AM, Kenneth Johansson <kenneth@southpole.se>wrote:

> http://www.cambridgewireless.co.uk/news/article/default.aspx?objid=36792
>
> Anybody know what they mean by booting here.
>
> I have started the ads5121 board using u-boot and kernel in NOR flash
> and root file system on a compact flash card connected to the IDE
> interface in 2.05 second until init is started from the rootfs.
>
> This was fast enough for what was needed I did not try to optimize
> further but since I already was in the domain where changes impacted
> only a few milliseconds I have a hard time imagining going down to less
> than a second.
>
> So I guess the only way is to skip u-boot and run linux kernel directly
> out of NOR. Anyone know what MontaVista is doing ??
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

[-- Attachment #2: Type: text/html, Size: 2140 bytes --]

^ permalink raw reply

* MPC8343 - serial8250: too much work
From: Alemao @ 2009-05-29 20:07 UTC (permalink / raw)
  To: linuxppc-dev, linux-kernel

Im facing some problems with serial, linux-2.6.23, getting flooded
with this message in logs:

---
serial8250: too much work for irq16
---

Something I notice, in my .dts I have the following lines:

serial0: serial@4500,  interrupts   =  <9  0x8>
serial1: serial@4600,  interrupts   =  <10 0x8>
spi:       spi@7000,     interrupts   =  <16 0x8>


But when kernel starts:

---
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
---

Why IRQ 16? Shouldn't it be IRQ 9?

I traced functions calls in 8250.c driver:

---
serial8250_interrup() -> serial8250_handle_port() -> transmit_chars()
---

"too much work" is for transmiting, but there's nothing to transmit.

In my MPC8343 board I have only serial0 connected to a MAX3232, serial1
is floating.

I found this comments in linux/drivers/serial/8250.h, and tried to use
same defines that they used, but no success:

/*
 * Digital did something really horribly wrong with the OUT1 and OUT2
 * lines on at least some ALPHA's.  The failure mode is that if either
 * is cleared, the machine locks up with endless interrupts.
 */

/*
 * WindRiver did something similarly broken on their SBC8560 board. The
 * UART tristates its IRQ output while OUT2 is clear, but they pulled
 * the interrupt line _up_ instead of down, so if we register the IRQ
 * while the UART is in that state, we die in an IRQ storm.
 */


I also tried removing serial1 and spi from .dts, but didn't work.

Any sugestions?

Cheers,

--
Alemao

^ permalink raw reply

* Re: 8544 external interrupt configuration problems
From: Nancy Isaac @ 2009-05-29 17:20 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090529170909.GA22066@b07421-ec1.am.freescale.net>

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Thank you!  That was my problem.  I was looking at the defines in
linux/irq.h and it didn't match what I was seeing at all....but this works
now.

On Fri, May 29, 2009 at 10:09 AM, Scott Wood <scottwood@freescale.com>wrote:

> On Thu, May 28, 2009 at 06:48:48PM -0700, Nancy Isaac wrote:
> > > Is the level/sense information correct?
> >
> >
> > [NI] Yes, these interrupts are supposed to be active low, level sensitive
> > interrupts.
>
> But the level/sense value for that on mpic is 1, not 2.  2 is active
> high (see Documentation/powerpc/booting-without-of.txt).
>
> -Scott
>

[-- Attachment #2: Type: text/html, Size: 952 bytes --]

^ permalink raw reply

* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Scott Wood @ 2009-05-29 17:18 UTC (permalink / raw)
  To: Frank Svendsbøe
  Cc: linuxppc-dev@ozlabs.org, Daniel Ng, Norbert van Bolhuis
In-Reply-To: <1ba63b520905290356l5d519e64w3bd852d8fc4032be@mail.gmail.com>

On Fri, May 29, 2009 at 12:56:13PM +0200, Frank Svendsbøe wrote:
> FYI. The same applies to mpc8xx targets: No default host interrupt controller.
> The following patch was needed for our target:
> ---
> diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
> index 5d2d552..92b2b66 100644
> --- a/arch/powerpc/sysdev/mpc8xx_pic.c
> +++ b/arch/powerpc/sysdev/mpc8xx_pic.c
> @@ -186,6 +186,7 @@ int mpc8xx_pic_init(void)
>                 ret = -ENOMEM;
>                 goto out;
>         }
> +        irq_set_default_host(mpc8xx_pic_host);
>         return 0;

This patch is whitespace mangled.

> 
>  out:
> ---
> Maybe setting a default host ought to be mandatory? Or is doing the
> mapping manually
> (without device tree descriptions) considered being a hack?

I consider it a hack -- not so much doing it manually (though the device
tree is better), but relying on a default interrupt controller when doing
so.  IRQ numbers only make sense in the context of a specific
controller.  It's especially misleading on 8xx, which has separate
regular and CPM PICs.

-Scott

^ permalink raw reply

* Re: 8544 external interrupt configuration problems
From: Scott Wood @ 2009-05-29 17:09 UTC (permalink / raw)
  To: Nancy Isaac; +Cc: linuxppc-dev
In-Reply-To: <1bcc666d0905281848m5d237742h12b4bac272f28ca9@mail.gmail.com>

On Thu, May 28, 2009 at 06:48:48PM -0700, Nancy Isaac wrote:
> > Is the level/sense information correct?
> 
> 
> [NI] Yes, these interrupts are supposed to be active low, level sensitive
> interrupts.

But the level/sense value for that on mpic is 1, not 2.  2 is active
high (see Documentation/powerpc/booting-without-of.txt).

-Scott

^ 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