* 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
* 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
* 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: 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
* 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: [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 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
* [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
* [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 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 08/11] swiotlb: support HIGHMEM in swiotlb_bus_to_virt
From: Ian Campbell @ 2009-06-01 15:33 UTC (permalink / raw)
To: linux-kernel
Cc: Fitzhardinge, Jeremy, Ian Campbell, Tomonori, linuxppc-dev,
Ingo Molnar, FUJITA
In-Reply-To: <1243870383-12954-1-git-send-email-ian.campbell@citrix.com>
Rather than supplying a __weak hook which architectures which support
highmem can overide simply provide a version of swiotlb_bus_to_virt
which works with high memory. Make it conditional since it is a more
expensive variant than the non-highmem version.
Acutal function contents taken from the PowerPC swiotlb patchset by
Becky Bruce.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Becky Bruce <beckyb@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: linuxppc-dev@ozlabs.org
---
lib/swiotlb.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index d37499b..d2b296a 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -130,9 +130,18 @@ static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
return phys_to_dma(hwdev, virt_to_phys(address));
}
-void * __weak swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
+static void *swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t address)
{
+#ifdef CONFIG_HIGHMEM
+ unsigned long pfn = PFN_DOWN(dma_to_phys(hwdev, address));
+ void *pageaddr = page_address(pfn_to_page(pfn));
+
+ if (pageaddr != NULL)
+ return pageaddr + (address % PAGE_SIZE);
+ return NULL;
+#else
return phys_to_virt(dma_to_phys(hwdev, address));
+#endif
}
static void swiotlb_print_info(unsigned long bytes)
--
1.5.6.5
^ permalink raw reply related
* Re: [Linux-fbdev-devel] [PATCH] GXT400P and GXT6500P support
From: Benjamin Herrenschmidt @ 2009-06-02 0:42 UTC (permalink / raw)
To: cjg; +Cc: linuxppc-dev, linux-fbdev-devel, Krzysztof Helt
In-Reply-To: <1243841551.4215.5.camel@anestethize.cjg.home>
On Mon, 2009-06-01 at 09:32 +0200, Giuseppe Coviello wrote:
>
> Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
> Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
As long as you guys have verified that it actually works, I have
no objection.
Ack.
Cheers,
Ben.
> 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>]\"");
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Benjamin Herrenschmidt @ 2009-06-02 0:46 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev@ozlabs.org, Daniel Ng
In-Reply-To: <4A1E6877.2060106@aimvalley.nl>
>
> #define PIT_IRQ 65
In addition, the interrupt should be provided by the device-tree of
course, in which case a single function will look it up for you -and-
do the appropriate mapping.
Cheers,
Ben.
> virq = irq_create_mapping(NULL, PIT_IRQ);
> set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
>
> if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0)) {
> printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n", PIT_IRQ, virq);
> }
>
> All the above info comes from this mailing (and the linuxppc-embedd list) though.
> If you search these lists you'll find plenty of answers to similar questions.
>
> ---
> N. van Bolhuis
> AimValley
>
>
>
>
> Daniel Ng wrote:
> > Hi,
> >
> > I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
> > a MPC8272-based platform.
> >
> > So far, the kernel crashes when the driver tries to open (see below).
> >
> > It seems that the interrupt handler fails to register, with the
> > following condition in setup_irq() in manage.c:
> >
> > desc->chip == &no_irq_chip
> >
> > I notice that the only place where desc->chip is assigned to anything
> > else besides &no_irq_chip is in __set_irq_handler() in
> > kernel/irq/chip.c
> >
> > In that file, __set_irq_handler() assigns desc->chip to
> > &dummy_irq_chip, but this seems to be done for a special ARM-specific
> > case, according to the commenting:
> >
> > /*
> > * Some ARM implementations install a handler for really dumb
> > * interrupt hardware without setting an irq_chip. This worked
> > * with the ARM no_irq_chip but the check in setup_irq would
> > * prevent us to setup the interrupt at all. Switch it to
> > * dummy_irq_chip for easy transition.
> > */
> >
> > Should I try to somehow call __set_irq_handler(), or should I be
> > looking elsewhere?
> >
> > If I should be calling __set_irq_handler(), it seems the only relevant
> > function that calls this is cpm2_pic_host_map().
> >
> > The only relevant functions which call cpm2_pic_host_map() are
> > irq_setup_virq() or irq_alloc_hosts() with the IRQ_HOST_MAP_LEGACY
> > parameter. IRQ_HOST_MAP_LEGACY seems to be irrelevant. Can someone
> > tell me what a virq is?
> >
> > Cheers,
> > Daniel
> >
> >
> >
> > Badness at c00224ec [verbose debug info unavailable]
> > NIP: c00224ec LR: c019b254 CTR: c01aa9f8
> > REGS: c1a49c70 TRAP: 0700 Not tainted (2.6.27.19-800-OS-03050107)
> > MSR: 00021032 <ME,IR,DR> CR: 22002022 XER: 00000000
> > TASK = c1bda400[306] 'pppd' THREAD: c1a48000
> > GPR00: 00000001 c1a49d20 c1bda400 00000000 c0318880 c19c4d80 c1b92211 00000000
> > GPR08: 00001032 c02cb240 00000000 00000000 22002022 fffffffe 01ff8000 00000000
> > GPR16: 10344020 00000000 00000002 10049ac0 c194f800 ffff8914 c18cd900 c18cd90c
> > GPR24: c1a49e48 00009032 c1a48000 c02b5fdc 00000002 c19c4d80 c1a48000 c1a48000
> > NIP [c00224ec] local_bh_enable+0x94/0xb4
> > LR [c019b254] dev_queue_xmit+0x108/0x580
> > Call Trace:
> > [c1a49d20] [c19c4d80] 0xc19c4d80 (unreliable)
> > [c1a49d30] [c019b254] dev_queue_xmit+0x108/0x580
> > [c1a49d50] [c016ac98] sppp_flush_xmit+0x20/0x44
> > [c1a49d60] [c016c0b4] sppp_open+0x80/0xac
> > [c1a49d80] [c016a104] ppp_open+0x70/0x98
> > --- Exception: bfd26bb0 at 0x8914
> > LR = 0xc1a49e90
> > [c1a49da0] [c01699e0] hdlc_open+0x3c/0x104 (unreliable)
> > [c1a49dc0] [c016cdd4] ethos_wan_genhdlc_open+0xb0/0xef8
> > [c1a49df0] [c019c490] dev_open+0xbc/0x120
> > [c1a49e00] [c019bbc8] dev_change_flags+0x8c/0x1d0
> > [c1a49e20] [c01e1678] devinet_ioctl+0x700/0x7ac
> > [c1a49e90] [c01e2538] inet_ioctl+0xcc/0xf8
> > [c1a49ea0] [c018b584] sock_ioctl+0x60/0x268
> > [c1a49ec0] [c0084ab0] vfs_ioctl+0x3c/0xc4
> > [c1a49ee0] [c0084bb8] do_vfs_ioctl+0x80/0x454
> > [c1a49f10] [c0084fcc] sys_ioctl+0x40/0x88
> > [c1a49f40] [c000f928] ret_from_syscall+0x0/0x38
> > --- Exception: c01 at 0x480af50c
> > LR = 0x480af5e4
> > Instruction dump:
> > 41a20008 482044e1 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c02d
> > 3929b240 800900dc 7c000034 5400d97e <0f000000> 2f800000 41beff90 38000001
> > hdlc2: Carrier detected
> > setup_irq()- desc->chip == &no_irq_chip
> > request_irq()- setup_irq() FAILED
> > ethos_wan_genhdlc_open(): request_irq() FAILED! ethos_wan->io_addr: 0xc5080000
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Benjamin Herrenschmidt @ 2009-06-02 0:47 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev@ozlabs.org, Daniel Ng, Norbert van Bolhuis
In-Reply-To: <20090528123311.GA3112@pengutronix.de>
On Thu, 2009-05-28 at 14:33 +0200, Wolfram Sang wrote:
> > this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel driver
> > registers for the PIT IRQ (Interrupt ID 65)
> >
> > #define PIT_IRQ 65
> >
> > virq = irq_create_mapping(NULL, PIT_IRQ);
> > set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
> >
> > if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0)) {
> > printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n", PIT_IRQ, virq);
> > }
>
> It is some time ago, but when I did something similar I needed the
> following patch in order to use NULL for irq_create_mapping(). Have a
> try, and if it is still needed (as it looks from a glimpse), then maybe
> we should get it merged?
I would object that you wouldn't have this problem if you weren't hard
wiring your interrupt number and were using the device-tree properly
instead. As to getting your patch merged, you'll have to argue with
Scott Wood who, I think, maintains the CPM2 stuff lately.
Cheers,
Ben.
> ===
>
> From: Wolfram Sang <w.sang@pengutronix.de>
> Subject: [PATCH] powerpc/cpm2: make cpm2_pic the default host
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> arch/powerpc/sysdev/cpm2_pic.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
> index 78f1f7c..7a7d4e5 100644
> --- a/arch/powerpc/sysdev/cpm2_pic.c
> +++ b/arch/powerpc/sysdev/cpm2_pic.c
> @@ -272,4 +272,5 @@ void cpm2_pic_init(struct device_node *node)
> printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
> return;
> }
> + irq_set_default_host(cpm2_pic_host);
> }
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Benjamin Herrenschmidt @ 2009-06-02 0:48 UTC (permalink / raw)
To: Frank Svendsbøe
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Daniel Ng,
Norbert van Bolhuis
In-Reply-To: <1ba63b520905301322n72fa165ds7e2eb3af4475f109@mail.gmail.com>
On Sat, 2009-05-30 at 22:22 +0200, Frank Svendsbøe wrote:
> 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 think
> 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.
Well, precisely :-) The DTS allows to contain the linkage to the PIC and
let the kernel resolve it all nicely for you.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: fix annotation of pcibios_claim_one_bus
From: Stephen Rothwell @ 2009-06-02 0:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
It was __devinit, but it is also within a CONFIG_HOTPLUG guarded section
of code, so the __devinit does nothing but cause the following warning:
WARNING: vmlinux.o(.text+0x107a8): Section mismatch in reference from the function pcibios_finish_adding_to_bus() to the function .devinit.text:pcibios_claim_one_bus()
The function pcibios_finish_adding_to_bus() references
the function __devinit pcibios_claim_one_bus().
This is often because pcibios_finish_adding_to_bus lacks a __devinit
annotation or the annotation of pcibios_claim_one_bus is wrong.
It is also only (externally) used in arch/powerpc/kernel/of_platform.c
which cannot be built as a module so don't export it.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci-common.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 4fee63c..5a56e97 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1505,7 +1505,7 @@ void __init pcibios_resource_survey(void)
* rest of the code later, for now, keep it as-is as our main
* resource allocation function doesn't deal with sub-trees yet.
*/
-void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
+void pcibios_claim_one_bus(struct pci_bus *bus)
{
struct pci_dev *dev;
struct pci_bus *child_bus;
@@ -1533,7 +1533,6 @@ void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
list_for_each_entry(child_bus, &bus->children, node)
pcibios_claim_one_bus(child_bus);
}
-EXPORT_SYMBOL_GPL(pcibios_claim_one_bus);
/* pcibios_finish_adding_to_bus
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] powerpc/kvm: fix some init/exit annotations
From: Stephen Rothwell @ 2009-06-02 1:46 UTC (permalink / raw)
To: ppc-dev; +Cc: Liu Yu, kvm, Hollis Blanchard, kvm-ppc, Avi Kivity
Fixes a couple of warnings like this one:
WARNING: arch/powerpc/kvm/kvm-440.o(.text+0x1e8c): Section mismatch in reference from the function kvmppc_44x_exit() to the function .exit.text:kvmppc_booke_exit()
The function kvmppc_44x_exit() references a function in an exit section.
Often the function kvmppc_booke_exit() has valid usage outside the exit section
and the fix is to remove the __exit annotation of kvmppc_booke_exit.
Also add some __init annotations on obvious routines.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kvm/44x.c | 4 ++--
arch/powerpc/kvm/booke.c | 2 +-
arch/powerpc/kvm/e500.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 0cef809..f4d1b55 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -138,7 +138,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
}
-static int kvmppc_44x_init(void)
+static int __init kvmppc_44x_init(void)
{
int r;
@@ -149,7 +149,7 @@ static int kvmppc_44x_init(void)
return kvm_init(NULL, sizeof(struct kvmppc_vcpu_44x), THIS_MODULE);
}
-static void kvmppc_44x_exit(void)
+static void __exit kvmppc_44x_exit(void)
{
kvmppc_booke_exit();
}
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 642e420..e7bf4d0 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -520,7 +520,7 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
return kvmppc_core_vcpu_translate(vcpu, tr);
}
-int kvmppc_booke_init(void)
+int __init kvmppc_booke_init(void)
{
unsigned long ivor[16];
unsigned long max_ivor = 0;
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index d8067fd..674e796 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -132,7 +132,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
}
-static int kvmppc_e500_init(void)
+static int __init kvmppc_e500_init(void)
{
int r, i;
unsigned long ivor[3];
@@ -160,7 +160,7 @@ static int kvmppc_e500_init(void)
return kvm_init(NULL, sizeof(struct kvmppc_vcpu_e500), THIS_MODULE);
}
-static void kvmppc_e500_exit(void)
+static void __init kvmppc_e500_exit(void)
{
kvmppc_booke_exit();
}
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-06-02 1:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a defconfig update if you still get things in .30
Cheers,
Ben.
The following changes since commit d9244b5d2fbfe9fa540024b410047af13ceec90f:
Linus Torvalds (1):
Merge branch 'hwmon-for-linus' of git://git.kernel.org/.../jdelvare/staging
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc/pmac: Update PowerMac 32-bit defconfig
arch/powerpc/configs/pmac32_defconfig | 278 +++++++++++++++++++++++----------
1 files changed, 195 insertions(+), 83 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc: fix annotation of pcibios_claim_one_bus
From: Michael Ellerman @ 2009-06-02 2:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20090602105353.b4a7e93d.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Tue, 2009-06-02 at 10:53 +1000, Stephen Rothwell wrote:
> It was __devinit, but it is also within a CONFIG_HOTPLUG guarded section
> of code, so the __devinit does nothing but cause the following warning:
>
> WARNING: vmlinux.o(.text+0x107a8): Section mismatch in reference from the function pcibios_finish_adding_to_bus() to the function .devinit.text:pcibios_claim_one_bus()
Isn't the real problem that the PCI hotplug code is not marked as
__devinit?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix annotation of pcibios_claim_one_bus
From: Benjamin Herrenschmidt @ 2009-06-02 3:02 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <1243908409.6119.2.camel@concordia>
On Tue, 2009-06-02 at 12:06 +1000, Michael Ellerman wrote:
> On Tue, 2009-06-02 at 10:53 +1000, Stephen Rothwell wrote:
> > It was __devinit, but it is also within a CONFIG_HOTPLUG guarded section
> > of code, so the __devinit does nothing but cause the following warning:
> >
> > WARNING: vmlinux.o(.text+0x107a8): Section mismatch in reference from the function pcibios_finish_adding_to_bus() to the function .devinit.text:pcibios_claim_one_bus()
>
> Isn't the real problem that the PCI hotplug code is not marked as
> __devinit?
I'll take Stephen patch for now. We can do a proper sweep through PCI
hotplug after Kumar is done finishing the 32/64-bit PCI merge...
Cheers,
Ben.
^ permalink raw reply
* "next" branch update
From: Benjamin Herrenschmidt @ 2009-06-02 3:03 UTC (permalink / raw)
To: linuxppc-dev list
I've updated powerpc "next branch" with the following patches:
(Kumar: The swiotlb patch is still segregated in "test" until we resolve
how it's going to be merged vs. Ian Campbell series).
Anton Blanchard (1):
powerpc: Convert RTAS event scan from kernel thread to workqueue
Michael Ellerman (3):
powerpc/ftrace: Use ppc_function_entry() instead of GET_ADDR
powerpc/ftrace: Remove unused macros
powerpc/ftrace: Use PPC_INST_NOP directly
Michael Neuling (1):
powerpc: Make the NR_CPUS max 8192
Michel Dänzer (1):
therm_adt746x: Always clear hardware bit which inverts fan speed range.
Nathan Fontenot (1):
powerpc: Display processor virtualization resource allocs in lparcfg
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
roel kluin (1):
tape: beyond ARRAY_SIZE of viocd_diskinfo
^ permalink raw reply
* Re: "next" branch update
From: Grant Likely @ 2009-06-02 3:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243911828.5308.2.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]
How about the iomap_early() patch? What would you like me to do with that
one?
g.
On Jun 1, 2009 9:04 PM, "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
wrote:
I've updated powerpc "next branch" with the following patches:
(Kumar: The swiotlb patch is still segregated in "test" until we resolve
how it's going to be merged vs. Ian Campbell series).
Anton Blanchard (1):
powerpc: Convert RTAS event scan from kernel thread to workqueue
Michael Ellerman (3):
powerpc/ftrace: Use ppc_function_entry() instead of GET_ADDR
powerpc/ftrace: Remove unused macros
powerpc/ftrace: Use PPC_INST_NOP directly
Michael Neuling (1):
powerpc: Make the NR_CPUS max 8192
Michel Dänzer (1):
therm_adt746x: Always clear hardware bit which inverts fan speed range.
Nathan Fontenot (1):
powerpc: Display processor virtualization resource allocs in lparcfg
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
roel kluin (1):
tape: beyond ARRAY_SIZE of viocd_diskinfo
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 1635 bytes --]
^ permalink raw reply
* Re: "next" branch update
From: Benjamin Herrenschmidt @ 2009-06-02 3:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list
In-Reply-To: <fa686aa40906012026r71b3b75ar13790f7a569d9c08@mail.gmail.com>
On Mon, 2009-06-01 at 21:26 -0600, Grant Likely wrote:
> How about the iomap_early() patch? What would you like me to do with
> that one?
Wait for me to review it :-)
Cheers,
Ben.
> g.
>
> > On Jun 1, 2009 9:04 PM, "Benjamin Herrenschmidt"
> > <benh@kernel.crashing.org> wrote:
> >
> > I've updated powerpc "next branch" with the following patches:
> >
> > (Kumar: The swiotlb patch is still segregated in "test" until we
> > resolve
> > how it's going to be merged vs. Ian Campbell series).
> >
> > Anton Blanchard (1):
> > powerpc: Convert RTAS event scan from kernel thread to
> > workqueue
> >
> > Michael Ellerman (3):
> > powerpc/ftrace: Use ppc_function_entry() instead of GET_ADDR
> > powerpc/ftrace: Remove unused macros
> > powerpc/ftrace: Use PPC_INST_NOP directly
> >
> > Michael Neuling (1):
> > powerpc: Make the NR_CPUS max 8192
> >
> > Michel Dänzer (1):
> > therm_adt746x: Always clear hardware bit which inverts fan
> > speed range.
> >
> > Nathan Fontenot (1):
> > powerpc: Display processor virtualization resource allocs in
> > lparcfg
> >
> > Stephen Rothwell (1):
> > powerpc/pci: Fix annotation of pcibios_claim_one_bus
> >
> > roel kluin (1):
> > tape: beyond ARRAY_SIZE of viocd_diskinfo
> >
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Wolfram Sang @ 2009-06-02 4:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev@ozlabs.org, Daniel Ng, Norbert van Bolhuis
In-Reply-To: <1243903641.591.19.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
> I would object that you wouldn't have this problem if you weren't hard
> wiring your interrupt number and were using the device-tree properly
> instead. As to getting your patch merged, you'll have to argue with
> Scott Wood who, I think, maintains the CPM2 stuff lately.
I fully agree that the proper way is using the device tree. I can't recall
exactly why this wasn't an option to me a year ago, but I assume it had
something to do with this ugly out-of-tree-driver. I wouldn't really argue
about this patch, I just thought it might be useful as it seems there are
people trying to do the same for some reason. Then again, maybe it should be
skipped, as it makes it easier to not use the proper solution (= device tree)
:)
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- 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: Benjamin Herrenschmidt @ 2009-06-02 4:42 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev@ozlabs.org, Daniel Ng, Norbert van Bolhuis
In-Reply-To: <20090602043819.GA1069@pengutronix.de>
On Tue, 2009-06-02 at 06:38 +0200, Wolfram Sang wrote:
> I fully agree that the proper way is using the device tree. I can't recall
> exactly why this wasn't an option to me a year ago, but I assume it had
> something to do with this ugly out-of-tree-driver. I wouldn't really argue
> about this patch, I just thought it might be useful as it seems there are
> people trying to do the same for some reason. Then again, maybe it should be
> skipped, as it makes it easier to not use the proper solution (= device tree)
> :)
Whether the driver is in or out of tree shouldn't affect the device-tree
which represents the -devices- on the system regardless of whether a
driver is in-tree or not.
So while some people might flinch, I don't necessarily object to adding
nodes in the device-trees we ship with the kernel for things for which
we don't have an in-tree driver.
It does mean however that the risk of such nodes containing busted
informations that aren't spotted because nobody has the driver to test
is higher but that's a risk you are taking with out of tree drivers
anyway.
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox