* Re: [PATCH-RFC 01/10] lib: move GENERIC_IOMAP to lib/Kconfig
From: Jesper Nilsson @ 2011-11-25 8:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips@linux-mips.org,
linux-m68k@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-sh@vger.kernel.org, linux@openrisc.net,
linux-pci@vger.kernel.org, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux@vger.kernel.org,
Guan Xuetao, Lennox Wu, Jonas Bonn, Russell King,
linux-hexagon@vger.kernel.org, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
linux-arch@vger.kernel.org, Arend van Spriel, Matt Turner,
Fenghua Yu, Lasse Collin, Arnd Bergmann, Lucas De Marchi,
microblaze-uclinux@itee.uq.edu.au, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel@lists.infradead.org,
Richard Henderson, Michael Ellerman, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel, Paul Gortmaker,
linux-kernel@vger.kernel.org, Ralf Baechle, Richard Kuo,
Kyle McMartin, Paul Mundt, linux-alpha@vger.kernel.org,
Olof Johansson, Andrew Morton, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <5aed7b7e1dbc8a50ebd6986245df8054fd05b7cd.1322163031.git.mst@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
On Thu, Nov 24, 2011 at 09:15:42PM +0100, Michael S. Tsirkin wrote:
> define GENERIC_IOMAP in a central location
> instead of all architectures. This will be helpful
> for the follow-up patch which makes it select
> other configs. Code is also a bit shorter this way.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
For the CRIS part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: Enabling MBX in MPC5121 - OGLES kernel modules
From: Einar Már Björgvinsson @ 2011-11-25 8:20 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <76E1146DEE728E4E95C1C6D1EEA1DBA96F174768@GRBSR0004.marel.net>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Hi
Wanted to repeat my previous email about enabling MBX in MPC5121.
Anybody out there who can assist me ?
regards
Einar
________________________________
From: Einar Már Björgvinsson
Sent: Tuesday, November 22, 2011 7:15 PM
To: linuxppc-dev@lists.ozlabs.org
Subject: Enabling MBX in MPC5121 - OGLES kernel modules
Hi
I've been working on enabling the PowerVR GPU core in MPC5121 chip. I've been following the documentation from here:
http://www.datasheetarchive.com/indexdl/Datasheet-076/DSAE0026055.pdf
This documentation was released in a bundle with MBX libraries and MBX kernel patches. Also have I downloaded the OGLES SDK from Imgtech where I've successfully built some demos for MPC5121.
The last piece of the puzzle is to have the right kernel modules. There are some kernel modules provided in the documentation bundle but they are build against older kernel version (2.6.24) but I'm am using kernel version 2.6.33 with RT 29.
What I'm hoping is that somebody have the source code for the following kernel modules:
- pvr.ko
- clcdc.ko
- swcamera.ko
- dgbdrv.ko
Hope somebody out there can assist
Regards
Einar M. Bjorgvinsson
Embedded Software Engineer
Marel ehf
Iceland
[-- Attachment #2: Type: text/html, Size: 2269 bytes --]
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Juntang Fu(David) @ 2011-11-25 5:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, oprofile-list, Fleming, Andy
In-Reply-To: <1322198672.32635.24.camel@pasglop>
On 11/25/2011 01:24 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
>
>> I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
>> correct backtrace but I cannot turn on frame pointers for the ppc kernel.
>> Isn't frame pointers needed for pcc? what about user space?
> PowerPC always has frame pointers, ignore that :-)
Recently I have met a similar problem on frame pointer but at arm_v7
variant in back tracing
support for Oprofile, could you help me see it? thanks in advance:
in my case, I have enabled Oprofile support in my arm_v7 thumb2 target,
in the created binary image
including kernel image and rootfs, seems that frame pointer is not
enabled for arm thumb2, So I have met
the following problems in back trace:
I can get the right stack traces for kernel stack, but for user stack, the
stack length is always one depth, why?
Is this a known deficiency in supporting arm thumb2 for Oprofile stack
trace?
Thanks.
B.R.
--David
> Cheers,
> Ben.
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
^ permalink raw reply
* [PATCH] powerpc: Atomically output each stack frame line in show_stack
From: Anton Blanchard @ 2011-11-25 5:47 UTC (permalink / raw)
To: benh, paulus, miltonm; +Cc: linuxppc-dev
From: Milton Miller <miltonm@bga.com>
show_stack uses up to 4 printks per line and other CPUs using printk
can corrupt the output. This patch calls printk once per stack frame
line to produce more readable output.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/process.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/process.c 2011-11-25
16:44:06.548045629 +1100 +++
linux-build/arch/powerpc/kernel/process.c 2011-11-25
16:44:07.944070260 +1100 @@ -1147,7 +1147,7 @@ void show_stack(struct
task_struct *tsk, { unsigned long sp, ip, lr, newsp;
int count = 0;
- int firstframe = 1;
+ char *firstframe = " (unreliable)";
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
int curr_frame = current->curr_ret_stack;
extern void return_to_handler(void);
@@ -1180,20 +1180,20 @@ void show_stack(struct task_struct *tsk,
stack = (unsigned long *) sp;
newsp = stack[0];
ip = stack[STACK_FRAME_LR_SAVE];
- if (!firstframe || ip != lr) {
- printk("["REG"] ["REG"] %pS", sp, ip, (void
*)ip);
+ if (!firstframe[0] || ip != lr) {
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
if ((ip == rth || ip == mrth) && curr_frame >=
0) {
- printk(" (%pS)",
- (void
*)current->ret_stack[curr_frame].ret);
+ printk("["REG"] ["REG"] %pS
(%pS)%s\n", sp, ip,
+ (void *)ip, (void *)
+
current->ret_stack[curr_frame].ret,
+ firstframe);
curr_frame--;
- }
+ } else
#endif
- if (firstframe)
- printk(" (unreliable)");
- printk("\n");
+ printk("["REG"] ["REG"] %pS%s\n", sp,
ip,
+ (void *)ip, firstframe);
}
- firstframe = 0;
+ firstframe = "";
/*
* See if this is an exception frame.
@@ -1206,7 +1206,7 @@ void show_stack(struct task_struct *tsk,
lr = regs->link;
printk("--- Exception: %lx at %pS\n LR =
%pS\n", regs->trap, (void *)regs->nip, (void *)lr);
- firstframe = 1;
+ firstframe = " (unreliable)";
}
sp = newsp;
^ permalink raw reply
* [PATCH] powerpc: Harden xics hypervisor backend
From: Anton Blanchard @ 2011-11-25 5:39 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
During kdump stress testing I sometimes see the kdump kernel panic
with:
Interrupt 0x306 (real) is invalid, disabling it.
Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306
Instead of panicing print the error message, dump the stack the first
time it happens and continue on. Add some more information to the
debug messages as well.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/sysdev/xics/icp-hv.c
===================================================================
--- linux-build.orig/arch/powerpc/sysdev/xics/icp-hv.c 2011-11-25 14:01:50.756984686 +1100
+++ linux-build/arch/powerpc/sysdev/xics/icp-hv.c 2011-11-25 14:13:22.389244117 +1100
@@ -27,33 +27,49 @@ static inline unsigned int icp_hv_get_xi
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
long rc;
+ unsigned int ret = XICS_IRQ_SPURIOUS;
rc = plpar_hcall(H_XIRR, retbuf, cppr);
- if (rc != H_SUCCESS)
- panic(" bad return code xirr - rc = %lx\n", rc);
- return (unsigned int)retbuf[0];
+ if (rc == H_SUCCESS) {
+ ret = (unsigned int)retbuf[0];
+ } else {
+ pr_err("%s: bad return code xirr cppr=0x%x returned %ld\n",
+ __func__, cppr, rc);
+ WARN_ON_ONCE(1);
+ }
+
+ return ret;
}
static inline void icp_hv_set_xirr(unsigned int value)
{
long rc = plpar_hcall_norets(H_EOI, value);
- if (rc != H_SUCCESS)
- panic("bad return code EOI - rc = %ld, value=%x\n", rc, value);
+ if (rc != H_SUCCESS) {
+ pr_err("%s: bad return code eoi xirr=0x%x returned %ld\n",
+ __func__, value, rc);
+ WARN_ON_ONCE(1);
+ }
}
static inline void icp_hv_set_cppr(u8 value)
{
long rc = plpar_hcall_norets(H_CPPR, value);
- if (rc != H_SUCCESS)
- panic("bad return code cppr - rc = %lx\n", rc);
+ if (rc != H_SUCCESS) {
+ pr_err("%s: bad return code cppr cppr=0x%x returned %ld\n",
+ __func__, value, rc);
+ WARN_ON_ONCE(1);
+ }
}
static inline void icp_hv_set_qirr(int n_cpu , u8 value)
{
- long rc = plpar_hcall_norets(H_IPI, get_hard_smp_processor_id(n_cpu),
- value);
- if (rc != H_SUCCESS)
- panic("bad return code qirr - rc = %lx\n", rc);
+ int hw_cpu = get_hard_smp_processor_id(n_cpu);
+ long rc = plpar_hcall_norets(H_IPI, hw_cpu, value);
+ if (rc != H_SUCCESS) {
+ pr_err("%s: bad return code qirr cpu=%d hw_cpu=%d mfrr=0x%x "
+ "returned %ld\n", __func__, n_cpu, hw_cpu, value, rc);
+ WARN_ON_ONCE(1);
+ }
}
static void icp_hv_eoi(struct irq_data *d)
^ permalink raw reply
* [PATCH] powerpc: Decode correct MSR bits in oops output
From: Anton Blanchard @ 2011-11-25 5:35 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
On a 64bit book3s machine I have an oops from a system reset that
claims the book3e CE bit was set:
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 24004082 XER: 00000010
On a book3s machine system reset sets IBM bit 46 and 47 depending on
the power saving mode. Separate the definitions by type and for
completeness add the rest of the bits in.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/process.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/process.c 2011-11-25 13:22:24.294919094 +1100
+++ linux-build/arch/powerpc/kernel/process.c 2011-11-25 13:36:23.213834524 +1100
@@ -584,16 +584,32 @@ static struct regbit {
unsigned long bit;
const char *name;
} msr_bits[] = {
+#if defined(CONFIG_PPC64) && !defined(CONFIG_BOOKE)
+ {MSR_SF, "SF"},
+ {MSR_HV, "HV"},
+#endif
+ {MSR_VEC, "VEC"},
+ {MSR_VSX, "VSX"},
+#ifdef CONFIG_BOOKE
+ {MSR_CE, "CE"},
+#endif
{MSR_EE, "EE"},
{MSR_PR, "PR"},
{MSR_FP, "FP"},
- {MSR_VEC, "VEC"},
- {MSR_VSX, "VSX"},
{MSR_ME, "ME"},
- {MSR_CE, "CE"},
+#ifdef CONFIG_BOOKE
{MSR_DE, "DE"},
+#else
+ {MSR_SE, "SE"},
+ {MSR_BE, "BE"},
+#endif
{MSR_IR, "IR"},
{MSR_DR, "DR"},
+ {MSR_PMM, "PMM"},
+#ifndef CONFIG_BOOKE
+ {MSR_RI, "RI"},
+ {MSR_LE, "LE"},
+#endif
{0, NULL}
};
^ permalink raw reply
* Re: ibm_newemac tx problem with jumbo frame enabled
From: Benjamin Herrenschmidt @ 2011-11-25 5:25 UTC (permalink / raw)
To: Prashant Bhole; +Cc: linuxppc-dev
In-Reply-To: <CAD6p20dmksH7YEjijdqLRG06aigaKTpzLPdoL0SCNGD3Ji9d2A@mail.gmail.com>
On Fri, 2011-11-18 at 10:33 +0530, Prashant Bhole wrote:
> Hi,
> I have been facing problem with ibm_newemac driver (v3.54).
> The board gets disconnected and can not be pinged in between
> some heavy network traffic. In my case I am running IOmeter
> "All-in-One" 8 threads on the iSCSI target. MTU is 4088.
>
> I found that after executing emac_full_tx_reset(), the board can
> be pinged again. Again after some heavy traffic of 5-6 seconds,
> traffic stops. This can be repeated after full tx reset.
>
> Is this a known issue? what could cause this?
> Any pointers would be greatly appreciated.
Not that I know of. Can you check if any of the error reporting
registers trip anything ? Could it just be a fifo overflow which we may
not be handling properly in the driver ?
Cheers,
Ben.
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Benjamin Herrenschmidt @ 2011-11-25 5:24 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Robert Richter, linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <OFD2223A5C.914A7555-ONC125794C.002D68B7-C125794C.002DFF90@transmode.se>
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
> I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame pointers, ignore that :-)
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-11-25 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a handful of tiny fixes for ppc, essentially embedded bits and
all reasonably trivial.
Cheers,
Ben.
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Alexandre Rusev (1):
powerpc/fsl-lbc: Fix for fsl_upm
Joakim Tjernlund (1):
powerpc/qe: Fixup QE_General4 errata
Julia Lawall (1):
arch/powerpc/sysdev/ehv_pic.c: add missing kfree
Kumar Gala (2):
powerpc/85xx: Fix compile error on p3060_qds.c
powerpc: Fix compiliation with hugetlbfs enabled
Paul Bolle (1):
powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
Roy Zang (1):
powerpc/p1023: set IRQ[4:6,11] to active-high level sensitive for PCIe
Shaohui Xie (1):
drivers/edac/mpc85xx_edac.c: fix memory controller compatible for edac
Tony Breeds (1):
powerpc/44x: Add mtd ndfc to the ppx44x defconfig
arch/powerpc/boot/dts/p1023rds.dts | 17 +++++++++++++----
arch/powerpc/configs/ppc44x_defconfig | 2 ++
arch/powerpc/mm/hugetlbpage.c | 1 +
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
arch/powerpc/sysdev/ehv_pic.c | 1 +
arch/powerpc/sysdev/fsl_lbc.c | 1 +
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
drivers/edac/mpc85xx_edac.c | 2 +-
9 files changed, 22 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/5] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Benjamin Herrenschmidt @ 2011-11-25 3:41 UTC (permalink / raw)
To: Matthew McClintock; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1319583246-6120-5-git-send-email-msm@freescale.com>
On Tue, 2011-10-25 at 17:54 -0500, Matthew McClintock wrote:
> boot_cpuid and init_thread_info.cpu are redundant, just use the
> var that stays around longer and add a define to make boot_cpuid
> point at the correct value
Breaks pseries build. Looks trivial but I haven't had a chance to fix
it (obvious one liner didn't do it and no time today).
Please re-submit fixed.
Cheers,
Ben.
> boot_cpudid_phys is not needed and can completely go away from the
> SMP case, we leave it there for the non-SMP case since the paca
> struct is not around to store this info
>
> This patch also has the effect of having the logical cpu number
> of the boot cpu be updated correctly independently of the ordering
> of the cpu nodes in the device tree.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> Could also just change boot_cpuid every to init_thread_info.cpu instead
> of using this define
>
> This is only tested on 32-bit parts, only compiled on 64-bit
>
> arch/powerpc/include/asm/smp.h | 2 +-
> arch/powerpc/kernel/setup_32.c | 7 ++++---
> arch/powerpc/kernel/setup_64.c | 1 -
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index adba970..f26c554 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -29,7 +29,7 @@
> #endif
> #include <asm/percpu.h>
>
> -extern int boot_cpuid;
> +#define boot_cpuid (init_thread_info.cpu)
> extern int spinning_secondaries;
>
> extern void cpu_die(void);
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index c1ce863..f396847 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -46,10 +46,11 @@
>
> extern void bootx_init(unsigned long r4, unsigned long phys);
>
> -int boot_cpuid = -1;
> -EXPORT_SYMBOL_GPL(boot_cpuid);
> -int boot_cpuid_phys;
> +/* we need a place to store phys cpu for non-SMP case */
> +#ifndef CONFIG_SMP
> +int boot_cpuid_phys = -1;
> EXPORT_SYMBOL_GPL(boot_cpuid_phys);
> +#endif
>
> int smp_hw_index[NR_CPUS];
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index d4168c9..eacefba 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -73,7 +73,6 @@
> #define DBG(fmt...)
> #endif
>
> -int boot_cpuid = 0;
> int __initdata spinning_secondaries;
> u64 ppc64_pft_size;
>
^ permalink raw reply
* Re: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-11-25 3:15 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-m68k, linuxppc-dev, linux-serial, Geert Uytterhoeven
In-Reply-To: <20111124145624.24438832@lxorguk.ukuu.org.uk>
On Thu, 24 Nov 2011, Alan Cox wrote:
> Given the change should work for all hardware do we really need the
> ifdefs. Far better I would have thought to just change it so we don't
> have to maintain what is effectively two versions of the code between
> now and 2038.
I agree.
>
> So no ack from me yet - I'd like to understand the ifdef decision first.
Removing ifdefs makes the changes more invasive and the suspend/resume
code then has to be addressed, which I've avoided.
The suspend/resume code path can't be tested on m68k macs and the common
code paths I can't easily test on a powermac.
This patch should not be needed because the chip reset shouldn't leave the
tx and rx interrupts enabled. Those interrupts are explicitly enabled only
after request_irq(), so patching the master interrupt enable behaviour
should be redundant. But that's not the case in practice.
The chip reset code is already messy. I was inclined towards ifdefs and
reluctant to share more code after practical experience suggested possible
differences in the SCC/ESCC devices.
I guess I was hoping that the powermac maintainers might prefer ifdefs to
increased risk of destabilising the driver on powermacs...
But a more invasive patch would make for better code. I will see if I can
borrow a suitable PCI PowerMac.
Finn
> Otherwise it looks sensible.
>
> Alan
^ permalink raw reply
* Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
From: Stephen Rothwell @ 2011-11-25 0:59 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64, linux-sh,
linux-pci, linux, Jesse Barnes, Chen Liqin, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Guan Xuetao, Lennox Wu,
Jonas Bonn, Jesper Nilsson, Russell King, linux-hexagon,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Arend van Spriel, Matt Turner, linux-arch,
Lasse Collin, Arnd Bergmann, Lucas De Marchi, microblaze-uclinux,
Michal Simek, Rob Herring, Mikael Starvik, Ivan Kokshaysky,
Franky Lin, Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Paul Bolle, Tony Luck,
linux-cris-kernel, linux-parisc, Paul Gortmaker, linux-kernel,
Fenghua Yu, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Fabio Baltieri, linuxppc-dev, David S. Miller
In-Reply-To: <20111125115455.9d5e18da6e683586d84ed9c8@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
Hi Michael,
On Fri, 25 Nov 2011 11:54:55 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Just wondering why you move pci_iomap but not pic_iounmap.
I figured this out. Arches have their own.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
From: Stephen Rothwell @ 2011-11-25 0:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64, linux-sh,
linux-pci, linux, Jesse Barnes, Chen Liqin, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Guan Xuetao, Lennox Wu,
Jonas Bonn, Jesper Nilsson, Russell King, linux-hexagon,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Arend van Spriel, Matt Turner, linux-arch,
Lasse Collin, Arnd Bergmann, Lucas De Marchi, microblaze-uclinux,
Michal Simek, Rob Herring, Mikael Starvik, Ivan Kokshaysky,
Franky Lin, Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Paul Bolle, Tony Luck,
linux-cris-kernel, linux-parisc, Paul Gortmaker, linux-kernel,
Fenghua Yu, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Fabio Baltieri, linuxppc-dev, David S. Miller
In-Reply-To: <b5a1327dd8bb38f87cba7ae10b308ec3b63de66a.1322163031.git.mst@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5328 bytes --]
Hi Michael,
On Thu, 24 Nov 2011 22:17:02 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 9120887..c8a67345 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -19,6 +19,8 @@
> #include <asm-generic/iomap.h>
> #endif
>
> +#include <asm-generic/pci_iomap.h>
> +
> #ifndef mmiowb
> #define mmiowb() do {} while (0)
> #endif
> @@ -283,9 +285,6 @@ static inline void writesb(const void __iomem *addr, const void *buf, int len)
> #define __io_virt(x) ((void __force *) (x))
>
> #ifndef CONFIG_GENERIC_IOMAP
> -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> -struct pci_dev;
> -extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
> {
> }
Just wondering why you move pci_iomap but not pic_iounmap. And also if
pci_iounmap is meant to stay here, then the "struct pci_dev" should
probably stay as well.
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index 98dcd76..fdcddcb 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -69,16 +69,13 @@ extern void ioport_unmap(void __iomem *);
> #ifdef CONFIG_PCI
> /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> struct pci_dev;
> -extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
Ditto with pci_iounmap. Also the comment above really belongs with pci_iomap.
> diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
> new file mode 100644
> index 0000000..e08b3bd
> --- /dev/null
> +++ b/include/asm-generic/pci_iomap.h
> @@ -0,0 +1,26 @@
> +/* Generic I/O port emulation, based on MN10300 code
> + *
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +#ifndef __ASM_GENERIC_PCI_IOMAP_H
> +#define __ASM_GENERIC_PCI_IOMAP_H
> +
> +#ifdef CONFIG_PCI
> +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> +struct pci_dev;
You could move this struct declaration above the ifdef and remove the
duplicate below.
> +extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> +#else
> +struct pci_dev;
> +static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
> +{
> + return NULL;
> +}
> +#endif
> +
> +#endif /* __ASM_GENERIC_IO_H */
> diff --git a/lib/iomap.c b/lib/iomap.c
> index 5dbcb4b..ada922a 100644
> --- a/lib/iomap.c
> +++ b/lib/iomap.c
> @@ -242,45 +242,11 @@ EXPORT_SYMBOL(ioport_unmap);
> #endif /* CONFIG_HAS_IOPORT */
>
> #ifdef CONFIG_PCI
> -/**
> - * pci_iomap - create a virtual mapping cookie for a PCI BAR
> - * @dev: PCI device that owns the BAR
> - * @bar: BAR number
> - * @maxlen: length of the memory to map
> - *
> - * Using this function you will get a __iomem address to your device BAR.
> - * You can access it using ioread*() and iowrite*(). These functions hide
> - * the details if this is a MMIO or PIO address space and will just do what
> - * you expect from them in the correct way.
> - *
> - * @maxlen specifies the maximum length to map. If you want to get access to
> - * the complete BAR without checking for its length first, pass %0 here.
> - * */
> -void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> -{
> - resource_size_t start = pci_resource_start(dev, bar);
> - resource_size_t len = pci_resource_len(dev, bar);
> - unsigned long flags = pci_resource_flags(dev, bar);
> -
> - if (!len || !start)
> - return NULL;
> - if (maxlen && len > maxlen)
> - len = maxlen;
> - if (flags & IORESOURCE_IO)
> - return ioport_map(start, len);
> - if (flags & IORESOURCE_MEM) {
> - if (flags & IORESOURCE_CACHEABLE)
> - return ioremap(start, len);
> - return ioremap_nocache(start, len);
> - }
> - /* What? */
> - return NULL;
> -}
> -
> +/* Hide the details if this is a MMIO or PIO address space and just do what
> + * you expect in the correct way. */
> void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
> {
> IO_COND(addr, /* nothing */, iounmap(addr));
> }
> -EXPORT_SYMBOL(pci_iomap);
> EXPORT_SYMBOL(pci_iounmap);
Ditto with pci_iounmap
> diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
> new file mode 100644
> index 0000000..40b26cb
> --- /dev/null
> +++ b/lib/pci_iomap.c
> @@ -0,0 +1,48 @@
> +/*
> + * Implement the default iomap interfaces
> + *
> + * (C) Copyright 2004 Linus Torvalds
> + */
> +#include <linux/pci.h>
> +#include <linux/io.h>
> +
> +#include <linux/module.h>
If this is relative to (at least) v3.2-rc1, then you should use export.h
instead of module.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 03/13] powerpc: Fix booke hugetlb preload code for PPC_MM_SLICES and 64-bit
From: Benjamin Herrenschmidt @ 2011-11-25 0:43 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798681100-git-send-email-beckyb@kernel.crashing.org>
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
.../...
> #ifdef CONFIG_PPC_MM_SLICES
> - psize = mmu_get_tsize(get_slice_psize(mm, ea));
> - tsize = mmu_get_psize(psize);
> + psize = get_slice_psize(mm, ea);
> + tsize = mmu_get_tsize(psize);
> shift = mmu_psize_defs[psize].shift;
> #else
> - vma = find_vma(mm, ea);
> - psize = vma_mmu_pagesize(vma); /* returns actual size in bytes */
> - asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (psize));
> - shift = 31 - lz;
> - tsize = 21 - lz;
> + psize = vma_mmu_pagesize(find_vma(mm, ea));
> + shift = __ilog2(psize);
> + tsize = shift - 10;
> #endif
Now, I know it was already there and you are just moving it around in
this patch but come on ... find_vma() here ? Really ? And with no result
checking nor boundary checking (remember it can return a vma that
doesn't enclose the address etc....). Now I know in this specific case
it -should- be safe but still...
Now, the caller is just doing:
book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
So why not just change the prototype and pass the vma down instead ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH v5 2/9] fadump: Reserve the memory for firmware assisted dump.
From: Paul Mackerras @ 2011-11-24 23:02 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Anton Blanchard, Amerigo Wang, Kexec-ml, Linux Kernel,
Milton Miller, linuxppc-dev, Randy Dunlap, Eric W. Biederman,
Vivek Goyal
In-Reply-To: <20111115151343.16533.70101.stgit@mars.in.ibm.com>
On Tue, Nov 15, 2011 at 08:43:43PM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> Reserve the memory during early boot to preserve CPU state data, HPTE region
> and RMR region data in case of kernel crash. At the time of crash, powerpc
> firmware will store CPU state data, HPTE region data and move RMR region
> data to the reserved memory area.
What is "RMR"? I don't see anywhere that you explain this acronym.
Is it the same as the RMA (real mode area)?
> +config FA_DUMP
> + bool "Firmware-assisted dump"
Is this new fadump infrastructure intended to supersede the existing
phyp dump code? Does it use the same phyp interfaces as phyp dump?
If so, you should probably remove the phyp dump code and config option
as the final patch in your series.
> +/*
> + * The RMR region will be saved for later dumping when kernel crashes.
> + * Set this to RMO size.
> + */
> +#define RMR_START 0x0
> +#define RMR_END (ppc64_rma_size)
An explanation of "RMR" here, and what the distinction (if any)
between RMR and RMA/RMO is, would help future readers.
> + sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + &size);
> +
> + if (!sections)
> + return 0;
> +
> + num_sections = size / sizeof(struct dump_section);
> +
> + for (i = 0; i < num_sections; i++) {
> + switch (sections[i].dump_section) {
> + case FADUMP_CPU_STATE_DATA:
> + fw_dump.cpu_state_data_size = sections[i].section_size;
> + break;
> + case FADUMP_HPTE_REGION:
> + fw_dump.hpte_region_size = sections[i].section_size;
> + break;
It's generally better to use of_read_number() or of_read_ulong() to
parse OF properties, rather than using a structure like this.
> + /* divide by 20 to get 5% of value */
> + size = memblock_end_of_DRAM();
> + do_div(size, 20);
You could just say size = memblock_end_of_DRAM() / 20 here; no need to
use do_div, since we won't be using this code on 32-bit platforms.
> + if (!fw_dump.fadump_supported) {
> + printk(KERN_ERR "Firmware-assisted dump is not supported on"
> + " this hardware\n");
This shouldn't be KERN_ERR; it's not an error to boot a kernel with
fadump configured in on a machine that doesn't have firmware fadump
support. I don't think we really need any message, but if we have one
it should be KERN_INFO at most.
> +/* Look for fadump= cmdline option. */
> +static int __init early_fadump_param(char *p)
> +{
> + if (!p)
> + return 1;
> +
> + if (p[0] == '1')
> + fw_dump.fadump_enabled = 1;
> + else if (p[0] == '0')
> + fw_dump.fadump_enabled = 0;
I think it's usual to allow "on" and "off" as values for this kind of
option. There might be a handy little helper function to parse this
sort of thing (but if there is I don't know what it is called).
Paul.
^ permalink raw reply
* Re: [RFC PATCH v5 1/9] fadump: Add documentation for firmware-assisted dump.
From: Paul Mackerras @ 2011-11-24 22:34 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Amerigo Wang, Kexec-ml, Linux Kernel, Milton Miller, linuxppc-dev,
Randy Dunlap, Anton Blanchard, Vivek Goyal, Eric W. Biederman
In-Reply-To: <20111115151334.16533.5790.stgit@mars.in.ibm.com>
On Tue, Nov 15, 2011 at 08:43:34PM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> Documentation for firmware-assisted dump. This document is based on the
> original documentation written for phyp assisted dump by Linas Vepstas
> and Manish Ahuja, with few changes to reflect the current implementation.
>
> Change in v3:
> - Modified the documentation to reflect introdunction of fadump_registered
> sysfs file and few minor changes.
>
> Change in v2:
> - Modified the documentation to reflect the change of fadump_region
> file under debugfs filesystem.
In general we don't want the changes between successive versions in
the patch description; this information should go below the "---"
line. The patch description should describe how the patch is now and
give any information that will be useful to someone looking at the
resulting git commit later on, but it doesn't need to tell us about
previous versions of the patch that will never appear in the git
history.
> +-- Once the dump is copied out, the memory that held the dump
> + is immediately available to the running kernel. A further
> + reboot isn't required.
I have a general worry about the system making allocations that are
intended to be node-local while it is running with restricted memory
(i.e. after the crash and reboot and before the dump has been written
out and the dump memory freed). Those allocations will probably all
come from one node and thus won't necessarily be on the desired node.
So, for very large systems with significant NUMA characteristics, it
may be desirable (though not required) to reboot after taking the
dump.
What happens about the NUMA information in the kernel -- all the
memory sections, etc.? Do they get set up as normal even though the
second kernel is booting with only a small amount of memory initially?
> + /sys/kernel/debug/powerpc/fadump_region
> +
> + This file shows the reserved memory regions if fadump is
> + enabled otherwise this file is empty. The output format
> + is:
> + <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
> +
> + e.g.
> + Contents when fadump is registered during first kernel
> +
> + # cat /sys/kernel/debug/powerpc/fadump_region
> + CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
> + HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
> + DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
How come the HPTE region is only 0x1000 (4k) bytes? The hashed page
table (HPT) will be much bigger than this. Is this our way of telling
the hypervisor that we don't care about the HPT? If so, is it
possible to make this region 0 bytes instead of 0x1000?
Paul.
^ permalink raw reply
* Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
From: Arnd Bergmann @ 2011-11-24 22:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Nicolas Pitre, linux-mips, linux-m68k, x86, linux-ia64,
Michael S. Tsirkin, linux-pci, linux, Jesse Barnes, Chen Liqin,
Paul Mackerras, Ralf Baechle, H. Peter Anvin, sparclinux,
Guan Xuetao, Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King,
linux-hexagon, Helge Deller, linux-sh, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Arend van Spriel, Matt Turner,
linux-arch, Lasse Collin, Lucas De Marchi, microblaze-uclinux,
Michal Simek, Rob Herring, Mikael Starvik, Ivan Kokshaysky,
Franky Lin, Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Paul Bolle, Tony Luck,
linux-cris-kernel, linux-parisc, Paul Gortmaker, linux-kernel,
Fenghua Yu, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Fabio Baltieri, David S. Miller
In-Reply-To: <b5a1327dd8bb38f87cba7ae10b308ec3b63de66a.1322163031.git.mst@redhat.com>
On Thursday 24 November 2011 22:17:02 Michael S. Tsirkin wrote:
> Many architectures want a generic pci_iomap but
> not the rest of iomap.c. Split that to a separate .c
> file and add a new config symbol. select automatically
> by GENERIC_IOMAP.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Very nice!
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* RE: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Benjamin Herrenschmidt @ 2011-11-24 20:43 UTC (permalink / raw)
To: David Laight
Cc: linuxppc-dev, linux-m68k, Geert Uytterhoeven, linux-serial,
Finn Thain
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEE1@saturn3.aculab.com>
On Thu, 2011-11-24 at 15:28 +0000, David Laight wrote:
> > On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> > masked. This can be a problem when pmac_zilog starts up.
>
> Wouldn't this also happen if the interrupt were shared?
> Hopefully nothing vaguely modern uses the borked Zilog 8530 SCC
> (which I presume is the part in question - brings back
> too many nightmares....)
Yup. Afaik, the most recent you can find with that are PowerMacs which
used it for their internal modem (even my G5 has one wired to the
internal slot afaik), tho none of those had shared interrupts.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Benjamin Herrenschmidt @ 2011-11-24 20:41 UTC (permalink / raw)
To: Alan Cox
Cc: Geert Uytterhoeven, linux-m68k, linuxppc-dev, linux-serial,
Finn Thain
In-Reply-To: <20111124145624.24438832@lxorguk.ukuu.org.uk>
On Thu, 2011-11-24 at 14:56 +0000, Alan Cox wrote:
> > This patch has been tested on a variety of m68k Macs but no
> PowerMacs.
> >
> > I am re-sending this patch Cc linux-serial. It still needs a
> suitable ack
> > so that Geert can push it through his tree.
>
> Given the change should work for all hardware do we really need the
> ifdefs. Far better I would have thought to just change it so we don't
> have to maintain what is effectively two versions of the code between
> now
> and 2038.
>
> So no ack from me yet - I'd like to understand the ifdef decision
> first.
> Otherwise it looks sensible.
Yes, agreed. Sorry, that one was one my to-do list for a while, I meant
to look into more details and test on a ppc or two here see if it breaks
anything, and never got to do it.
I'll try to give it a go before hell freezes over.
Cheers,
Ben.
^ permalink raw reply
* [PATCH-RFC 10/10] sparc: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2011-11-24 20:21 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64,
Michael S. Tsirkin, linux, linux-pci, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King, linux-sh,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, linux-arch, Arend van Spriel,
Matt Turner, Fenghua Yu, Lasse Collin, Arnd Bergmann,
Lucas De Marchi, microblaze-uclinux, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel, Richard Henderson,
Michael Ellerman, Michal Simek, Tony Luck, linux-parisc,
linux-cris-kernel, Paul Gortmaker, linux-kernel, Ralf Baechle,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cover.1322163031.git.mst@redhat.com>
sparc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/sparc/Kconfig | 1 +
arch/sparc/include/asm/io_32.h | 5 ++++-
arch/sparc/include/asm/io_64.h | 5 ++++-
arch/sparc/lib/iomap.c | 23 -----------------------
4 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index f92602e..a4644f5 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -28,6 +28,7 @@ config SPARC
select HAVE_GENERIC_HARDIRQS
select GENERIC_IRQ_SHOW
select USE_GENERIC_SMP_HELPERS if SMP
+ select GENERIC_PCI_IOMAP
config SPARC32
def_bool !64BIT
diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h
index c2ced21..9be8778 100644
--- a/arch/sparc/include/asm/io_32.h
+++ b/arch/sparc/include/asm/io_32.h
@@ -8,6 +8,10 @@
#include <asm/page.h> /* IO address mapping routines need this */
#include <asm/system.h>
+#ifdef __KERNEL__
+#include <asm-generic/pci_iomap.h>
+#endif
+
#define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
static inline u32 flip_dword (u32 l)
@@ -324,7 +328,6 @@ extern void ioport_unmap(void __iomem *);
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
struct pci_dev;
-extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
/*
diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h
index 9c89654..19cd51d 100644
--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -9,6 +9,10 @@
#include <asm/system.h>
#include <asm/asi.h>
+#ifdef __KERNEL__
+#include <asm-generic/pci_iomap.h>
+#endif
+
/* PC crapola... */
#define __SLOW_DOWN_IO do { } while (0)
#define SLOW_DOWN_IO do { } while (0)
@@ -514,7 +518,6 @@ extern void ioport_unmap(void __iomem *);
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
struct pci_dev;
-extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
static inline int sbus_can_dma_64bit(void)
diff --git a/arch/sparc/lib/iomap.c b/arch/sparc/lib/iomap.c
index 9ef37e1..c4d42a5 100644
--- a/arch/sparc/lib/iomap.c
+++ b/arch/sparc/lib/iomap.c
@@ -18,31 +18,8 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (!len || !start)
- return NULL;
- if (maxlen && len > maxlen)
- len = maxlen;
- if (flags & IORESOURCE_IO)
- return ioport_map(start, len);
- if (flags & IORESOURCE_MEM) {
- if (flags & IORESOURCE_CACHEABLE)
- return ioremap(start, len);
- return ioremap_nocache(start, len);
- }
- /* What? */
- return NULL;
-}
-
void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
{
/* nothing to do */
}
-EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH-RFC 09/10] sh: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2011-11-24 20:20 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64,
Michael S. Tsirkin, linux, linux-pci, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King, linux-sh,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, linux-arch, Arend van Spriel,
Matt Turner, Fenghua Yu, Lasse Collin, Arnd Bergmann,
Lucas De Marchi, microblaze-uclinux, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel, Richard Henderson,
Michael Ellerman, Michal Simek, Tony Luck, linux-parisc,
linux-cris-kernel, Paul Gortmaker, linux-kernel, Ralf Baechle,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cover.1322163031.git.mst@redhat.com>
sh copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/sh/Kconfig | 1 +
arch/sh/drivers/pci/pci.c | 23 -----------------------
2 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 5aeab58..ead1640 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -857,6 +857,7 @@ config PCI
bool "PCI support"
depends on SYS_SUPPORTS_PCI
select PCI_DOMAINS
+ select GENERIC_PCI_IOMAP
help
Find out whether you have a PCI motherboard. PCI is the name of a
bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c
index c2691af..11aaf2f 100644
--- a/arch/sh/drivers/pci/pci.c
+++ b/arch/sh/drivers/pci/pci.c
@@ -393,29 +393,6 @@ static void __iomem *ioport_map_pci(struct pci_dev *dev,
return (void __iomem *)(chan->io_map_base + port);
}
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (unlikely(!len || !start))
- return NULL;
- if (maxlen && len > maxlen)
- len = maxlen;
-
- if (flags & IORESOURCE_IO)
- return ioport_map_pci(dev, start, len);
- if (flags & IORESOURCE_MEM) {
- if (flags & IORESOURCE_CACHEABLE)
- return ioremap(start, len);
- return ioremap_nocache(start, len);
- }
-
- return NULL;
-}
-EXPORT_SYMBOL(pci_iomap);
-
void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
{
iounmap(addr);
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH-RFC 08/10] powerpc: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2011-11-24 20:19 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64,
Michael S. Tsirkin, linux, linux-pci, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King, linux-sh,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, linux-arch, Arend van Spriel,
Matt Turner, Fenghua Yu, Lasse Collin, Arnd Bergmann,
Lucas De Marchi, microblaze-uclinux, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel, Richard Henderson,
Michael Ellerman, Michal Simek, Tony Luck, linux-parisc,
linux-cris-kernel, Paul Gortmaker, linux-kernel, Ralf Baechle,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cover.1322163031.git.mst@redhat.com>
powerpc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code since arch/powerpc/include/asm/io.h
defines ioremap_nocache same as ioremap.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/iomap.c | 19 -------------------
2 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 951e18f..6ffe3df 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -710,6 +710,7 @@ config PCI
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
default PCI_QSPAN if !4xx && !CPM2 && 8xx
select ARCH_SUPPORTS_MSI
+ select GENERIC_PCI_IOMAP
help
Find out whether your system includes a PCI bus. PCI is the name of
a bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index 2627918..97a3715 100644
--- a/arch/powerpc/kernel/iomap.c
+++ b/arch/powerpc/kernel/iomap.c
@@ -119,24 +119,6 @@ EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
#ifdef CONFIG_PCI
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (!len)
- return NULL;
- if (max && len > max)
- len = max;
- if (flags & IORESOURCE_IO)
- return ioport_map(start, len);
- if (flags & IORESOURCE_MEM)
- return ioremap(start, len);
- /* What? */
- return NULL;
-}
-
void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
{
if (isa_vaddr_is_ioport(addr))
@@ -146,6 +128,5 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
iounmap(addr);
}
-EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
#endif /* CONFIG_PCI */
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2011-11-24 20:19 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64,
Michael S. Tsirkin, linux, linux-pci, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King, linux-sh,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, linux-arch, Arend van Spriel,
Matt Turner, Fenghua Yu, Lasse Collin, Arnd Bergmann,
Lucas De Marchi, microblaze-uclinux, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel, Richard Henderson,
Michael Ellerman, Michal Simek, Tony Luck, linux-parisc,
linux-cris-kernel, Paul Gortmaker, linux-kernel, Ralf Baechle,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cover.1322163031.git.mst@redhat.com>
parisc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/parisc/Kconfig | 1 +
arch/parisc/lib/iomap.c | 23 -----------------------
2 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index fdfd8be..242a1b7 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -14,6 +14,7 @@ config PARISC
select GENERIC_ATOMIC64 if !64BIT
select HAVE_GENERIC_HARDIRQS
select GENERIC_IRQ_PROBE
+ select GENERIC_PCI_IOMAP
select IRQ_PER_CPU
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/parisc/lib/iomap.c b/arch/parisc/lib/iomap.c
index 8f470c9..fb8e10a 100644
--- a/arch/parisc/lib/iomap.c
+++ b/arch/parisc/lib/iomap.c
@@ -436,28 +436,6 @@ void ioport_unmap(void __iomem *addr)
}
}
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (!len || !start)
- return NULL;
- if (maxlen && len > maxlen)
- len = maxlen;
- if (flags & IORESOURCE_IO)
- return ioport_map(start, len);
- if (flags & IORESOURCE_MEM) {
- if (flags & IORESOURCE_CACHEABLE)
- return ioremap(start, len);
- return ioremap_nocache(start, len);
- }
- /* What? */
- return NULL;
-}
-
void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
{
if (!INDIRECT_ADDR(addr)) {
@@ -483,5 +461,4 @@ EXPORT_SYMBOL(iowrite16_rep);
EXPORT_SYMBOL(iowrite32_rep);
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2011-11-24 20:18 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64,
Michael S. Tsirkin, linux, linux-pci, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King, linux-sh,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, linux-arch, Arend van Spriel,
Matt Turner, Fenghua Yu, Lasse Collin, Arnd Bergmann,
Lucas De Marchi, microblaze-uclinux, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel, Richard Henderson,
Michael Ellerman, Michal Simek, Tony Luck, linux-parisc,
linux-cris-kernel, Paul Gortmaker, linux-kernel, Ralf Baechle,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cover.1322163031.git.mst@redhat.com>
mips copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/mips/Kconfig | 1 +
arch/mips/lib/iomap-pci.c | 26 --------------------------
2 files changed, 1 insertions(+), 26 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d46f1da..b70c96f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2317,6 +2317,7 @@ config PCI
bool "Support for PCI controller"
depends on HW_HAS_PCI
select PCI_DOMAINS
+ select GENERIC_PCI_IOMAP
help
Find out whether you have a PCI motherboard. PCI is the name of a
bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/arch/mips/lib/iomap-pci.c b/arch/mips/lib/iomap-pci.c
index 2ab899c..2635b1a 100644
--- a/arch/mips/lib/iomap-pci.c
+++ b/arch/mips/lib/iomap-pci.c
@@ -40,32 +40,6 @@ static void __iomem *ioport_map_pci(struct pci_dev *dev,
return (void __iomem *) (ctrl->io_map_base + port);
}
-/*
- * Create a virtual mapping cookie for a PCI BAR (memory or IO)
- */
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (!len || !start)
- return NULL;
- if (maxlen && len > maxlen)
- len = maxlen;
- if (flags & IORESOURCE_IO)
- return ioport_map_pci(dev, start, len);
- if (flags & IORESOURCE_MEM) {
- if (flags & IORESOURCE_CACHEABLE)
- return ioremap(start, len);
- return ioremap_nocache(start, len);
- }
- /* What? */
- return NULL;
-}
-
-EXPORT_SYMBOL(pci_iomap);
-
void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
{
iounmap(addr);
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH-RFC 05/10] microblaze: switch to GENERIC_PCI_IOMAP
From: Michael S. Tsirkin @ 2011-11-24 20:18 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64,
Michael S. Tsirkin, linux, linux-pci, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King, linux-sh,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, linux-arch, Arend van Spriel,
Matt Turner, Fenghua Yu, Lasse Collin, Arnd Bergmann,
Lucas De Marchi, microblaze-uclinux, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel, Richard Henderson,
Michael Ellerman, Michal Simek, Tony Luck, linux-parisc,
linux-cris-kernel, Paul Gortmaker, linux-kernel, Ralf Baechle,
Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cover.1322163031.git.mst@redhat.com>
microblaze copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code since arch/microblaze/include/asm/io.h
defines ioremap_nocache same as ioremap.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/microblaze/Kconfig | 1 +
arch/microblaze/pci/iomap.c | 19 -------------------
2 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index e446bab..f0eead7 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -17,6 +17,7 @@ config MICROBLAZE
select HAVE_GENERIC_HARDIRQS
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
+ select GENERIC_PCI_IOMAP
config SWAP
def_bool n
diff --git a/arch/microblaze/pci/iomap.c b/arch/microblaze/pci/iomap.c
index 57acda8..b07abba 100644
--- a/arch/microblaze/pci/iomap.c
+++ b/arch/microblaze/pci/iomap.c
@@ -10,25 +10,6 @@
#include <asm/io.h>
#include <asm/pci-bridge.h>
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (!len)
- return NULL;
- if (max && len > max)
- len = max;
- if (flags & IORESOURCE_IO)
- return ioport_map(start, len);
- if (flags & IORESOURCE_MEM)
- return ioremap(start, len);
- /* What? */
- return NULL;
-}
-EXPORT_SYMBOL(pci_iomap);
-
void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
{
if (isa_vaddr_is_ioport(addr))
--
1.7.5.53.gc233e
^ permalink raw reply related
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