Linux on HP PA-RISC development discussion ()

Michael S. Tsirkin | 4 Dec 2011 11:48

Picon

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> 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 <at> redhat.com>

Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!

> ---
>  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
>  <at>  <at>  -14,6 +14,7  <at>  <at>  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

(Continue reading)

James Bottomley | 4 Dec 2011 15:22

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> > 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 <at> redhat.com>
> 
> Sorry to nag, any ACKs/NACKs on the parisc part?
> I intend to send this to Linus if there are no
> objections. Thanks!

Next time, send the patch to linux-arch or linux-parisc ... it helps to
get people to review it.  Although this one looks completely trivial,
unless I'm missing something?

Obviously there was a bit of a brain fart when this was done: the parisc
piece shouldn't be a copy of the generic code: we don't have native i/o
ports and emulation is pretty expensive, so we should prefer
IORESOURCE_MEM over IORESOURCE_IO when both are available  ... but even
on x86, memory mapping is faster (although not by the order of magnitude
it is on parisc), so it looks like you could fix this in the generic
code.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Michael S. Tsirkin | 4 Dec 2011 15:30

Picon

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Sun, Dec 04, 2011 at 08:22:34AM -0600, James Bottomley wrote:
> On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> > > 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 <at> redhat.com>
> > 
> > Sorry to nag, any ACKs/NACKs on the parisc part?
> > I intend to send this to Linus if there are no
> > objections. Thanks!
> 
> Next time, send the patch to linux-arch or linux-parisc ... it helps to
> get people to review it. Although this one looks completely trivial,
> unless I'm missing something?

I think it's trivial but I don't have the setup to even compile it so
depend on someone to ack.

> Obviously there was a bit of a brain fart when this was done: the parisc
> piece shouldn't be a copy of the generic code: we don't have native i/o
> ports and emulation is pretty expensive, so we should prefer
> IORESOURCE_MEM over IORESOURCE_IO when both are available  ... but even
> on x86, memory mapping is faster (although not by the order of magnitude
> it is on parisc), so it looks like you could fix this in the generic
> code.
> 
> James

(Continue reading)

James Bottomley | 4 Dec 2011 15:32

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Sun, 2011-12-04 at 16:30 +0200, Michael S. Tsirkin wrote:
> On Sun, Dec 04, 2011 at 08:22:34AM -0600, James Bottomley wrote:
> > On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> > > On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> > > > 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 <at> redhat.com>
> > > 
> > > Sorry to nag, any ACKs/NACKs on the parisc part?
> > > I intend to send this to Linus if there are no
> > > objections. Thanks!
> > 
> > Next time, send the patch to linux-arch or linux-parisc ... it helps to
> > get people to review it. Although this one looks completely trivial,
> > unless I'm missing something?
> 
> I think it's trivial but I don't have the setup to even compile it so
> depend on someone to ack.
> 
> > Obviously there was a bit of a brain fart when this was done: the parisc
> > piece shouldn't be a copy of the generic code: we don't have native i/o
> > ports and emulation is pretty expensive, so we should prefer
> > IORESOURCE_MEM over IORESOURCE_IO when both are available  ... but even
> > on x86, memory mapping is faster (although not by the order of magnitude
> > it is on parisc), so it looks like you could fix this in the generic
> > code.
> > 
> > James

(Continue reading)

Michael S. Tsirkin | 4 Dec 2011 15:42

Picon

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Sun, Dec 04, 2011 at 08:32:24AM -0600, James Bottomley wrote:
> On Sun, 2011-12-04 at 16:30 +0200, Michael S. Tsirkin wrote:
> > On Sun, Dec 04, 2011 at 08:22:34AM -0600, James Bottomley wrote:
> > > On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> > > > > 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 <at> redhat.com>
> > > > 
> > > > Sorry to nag, any ACKs/NACKs on the parisc part?
> > > > I intend to send this to Linus if there are no
> > > > objections. Thanks!
> > > 
> > > Next time, send the patch to linux-arch or linux-parisc ... it helps to
> > > get people to review it. Although this one looks completely trivial,
> > > unless I'm missing something?
> > 
> > I think it's trivial but I don't have the setup to even compile it so
> > depend on someone to ack.
> > 
> > > Obviously there was a bit of a brain fart when this was done: the parisc
> > > piece shouldn't be a copy of the generic code: we don't have native i/o
> > > ports and emulation is pretty expensive, so we should prefer
> > > IORESOURCE_MEM over IORESOURCE_IO when both are available  ... but even
> > > on x86, memory mapping is faster (although not by the order of magnitude
> > > it is on parisc), so it looks like you could fix this in the generic
> > > code.
> > >

(Continue reading)

James Bottomley | 5 Dec 2011 16:33

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Sun, 2011-12-04 at 16:42 +0200, Michael S. Tsirkin wrote:
> On Sun, Dec 04, 2011 at 08:32:24AM -0600, James Bottomley wrote:
> > On Sun, 2011-12-04 at 16:30 +0200, Michael S. Tsirkin wrote:
> > > On Sun, Dec 04, 2011 at 08:22:34AM -0600, James Bottomley wrote:
> > > > On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> > > > > On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> > > > > > 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 <at> redhat.com>
> > > > > 
> > > > > Sorry to nag, any ACKs/NACKs on the parisc part?
> > > > > I intend to send this to Linus if there are no
> > > > > objections. Thanks!
> > > > 
> > > > Next time, send the patch to linux-arch or linux-parisc ... it helps to
> > > > get people to review it. Although this one looks completely trivial,
> > > > unless I'm missing something?
> > > 
> > > I think it's trivial but I don't have the setup to even compile it so
> > > depend on someone to ack.
> > > 
> > > > Obviously there was a bit of a brain fart when this was done: the parisc
> > > > piece shouldn't be a copy of the generic code: we don't have native i/o
> > > > ports and emulation is pretty expensive, so we should prefer
> > > > IORESOURCE_MEM over IORESOURCE_IO when both are available  ... but even
> > > > on x86, memory mapping is faster (although not by the order of magnitude
> > > > it is on parisc), so it looks like you could fix this in the generic
> > > > code.

(Continue reading)

Michael S. Tsirkin | 5 Dec 2011 17:24

Picon

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Mon, Dec 05, 2011 at 09:33:29AM -0600, James Bottomley wrote:
> On Sun, 2011-12-04 at 16:42 +0200, Michael S. Tsirkin wrote:
> > On Sun, Dec 04, 2011 at 08:32:24AM -0600, James Bottomley wrote:
> > > On Sun, 2011-12-04 at 16:30 +0200, Michael S. Tsirkin wrote:
> > > > On Sun, Dec 04, 2011 at 08:22:34AM -0600, James Bottomley wrote:
> > > > > On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> > > > > > On Thu, Nov 24, 2011 at 10:19:34PM +0200, Michael S. Tsirkin wrote:
> > > > > > > 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 <at> redhat.com>
> > > > > > 
> > > > > > Sorry to nag, any ACKs/NACKs on the parisc part?
> > > > > > I intend to send this to Linus if there are no
> > > > > > objections. Thanks!
> > > > > 
> > > > > Next time, send the patch to linux-arch or linux-parisc ... it helps to
> > > > > get people to review it. Although this one looks completely trivial,
> > > > > unless I'm missing something?
> > > > 
> > > > I think it's trivial but I don't have the setup to even compile it so
> > > > depend on someone to ack.
> > > > 
> > > > > Obviously there was a bit of a brain fart when this was done: the parisc
> > > > > piece shouldn't be a copy of the generic code: we don't have native i/o
> > > > > ports and emulation is pretty expensive, so we should prefer
> > > > > IORESOURCE_MEM over IORESOURCE_IO when both are available  ... but even
> > > > > on x86, memory mapping is faster (although not by the order of magnitude
> > > > > it is on parisc), so it looks like you could fix this in the generic

(Continue reading)

James Bottomley | 5 Dec 2011 17:46

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Mon, 2011-12-05 at 18:24 +0200, Michael S. Tsirkin wrote:
> > > so ... ACK?
> > 
> > Um, well, it looks like a trivial code shift, so it doesn't really need
> > one (it can just go through the trivial tree).
> 
> It's part of a larger set not all of which is trivial.

OK, so it looks fine to me.

> >  Unless there's some
> > reason actually to test it out on parisc because something will break
> > (in which case, I'll need the actual patch, not just a quoted one).
> > 
> > James
> 
> A build test would be nice. Just forwarded you a patch.
> It's also on linux-next.

Actually, sending it to me doesn't help.  Being busy and lazy, I want to
see if someone else will test it ... that's why we send patches to the
list.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Grant Grundler | 5 Dec 2011 19:23

Picon

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Sun, Dec 4, 2011 at 6:30 AM, Michael S. Tsirkin <mst <at> redhat.com> wrote:
...
> AFAIK, on PCI a resource is either IO or MEM, but never both.
> What am I missing?

Yes, a particular PCI BAR (Base Address Register) is either IO or MEM
(not both) address space resource.

James is observing many older devices have the same set of registers
mapped in both address spaces using two BARs. As you already know,
MMIO is "lighter weight" (CPU cost to generate transactions on PCI
bus). I think this is orthogonal to the issue you are addressing.

Regarding handling of IO Port space cookies:
> -     if (flags & IORESOURCE_IO)
> -             return ioport_map(start, len);

I don't know who all the consumers of pci_iomap() are. If user space
can somehow call this, it should fail for IO port space "mappings"
since unlike x86, parisc has no INB/OUTB instructions. Generating IO
Port space requires frobbing PCI Bus controller registers that I don't
think we want to expose to user space.

I'm going to assume this is NOT a problem since any code that
generates anything that tries to look like an INB/OUTB just won't
compile on parisc.  I think removing the parisc specific definition
and using the generic one instead looks fine to me.  But I'm not
confident enough to offer a formal ACKed-by line. Sorry. :(

cheers,

(Continue reading)

Michael S. Tsirkin | 6 Dec 2011 12:06

Picon

Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP

On Mon, Dec 05, 2011 at 10:23:17AM -0800, Grant Grundler wrote:
> On Sun, Dec 4, 2011 at 6:30 AM, Michael S. Tsirkin <mst <at> redhat.com> wrote:
> ...
> > AFAIK, on PCI a resource is either IO or MEM, but never both.
> > What am I missing?
> 
> Yes, a particular PCI BAR (Base Address Register) is either IO or MEM
> (not both) address space resource.
> 
> James is observing many older devices have the same set of registers
> mapped in both address spaces using two BARs. As you already know,
> MMIO is "lighter weight" (CPU cost to generate transactions on PCI
> bus). I think this is orthogonal to the issue you are addressing.
> 
> Regarding handling of IO Port space cookies:
> > -     if (flags & IORESOURCE_IO)
> > -             return ioport_map(start, len);
> 
> I don't know who all the consumers of pci_iomap() are. If user space
> can somehow call this, it should fail for IO port space "mappings"
> since unlike x86, parisc has no INB/OUTB instructions. Generating IO
> Port space requires frobbing PCI Bus controller registers that I don't
> think we want to expose to user space.
> 
> I'm going to assume this is NOT a problem since any code that
> generates anything that tries to look like an INB/OUTB just won't
> compile on parisc.  I think removing the parisc specific definition
> and using the generic one instead looks fine to me.  But I'm not
> confident enough to offer a formal ACKed-by line. Sorry. :(
>

(Continue reading)

Group

gmane.linux.ports.parisc.

Project Web Page

Linux on HP PA-RISC development discussion ()

Search Archive

Page

1 | 2 | 3

Articles in period: 22

December 2011

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Compliments Of The Day / Your Response!!!! (22 May 2013)
[PATCH] parisc/superio: Use module_pci_driver to register driver (20 May 2013)
[PATCH] parisc: make interrupt and interruption stack allocation reent (20 May 2013)
[PATCH] parisc: use arch_spinlock_t instead of raw_spinlock_t in irqst (19 May 2013)
[PATCH] parisc: show number of FPE and unaligned access handler calls (18 May 2013)
[PATCH] parisc: add additional parisc git tree to MAINTAINERS file (16 May 2013)
[PATCH] parisc: use PAGE_SHIFT instead of hardcoded value 12 in pacach (16 May 2013)
[PATCH] parisc: add rp5470 entry to machine database (16 May 2013)
[PATCH] parisc: use long branch in fork_like macro (16 May 2013)
[PATCH] parisc: fix SMP races when updating PTE and TLB entries in ent (16 May 2013)
[PATCH] parisc: only re-enable interrupts if we need to schedule or de (16 May 2013)
[GIT PULL] parisc updates for v3.10 (13 May 2013)
[PATCH] parisc: make default cross compiler search more robust (v3) (11 May 2013)
[PATCH] parisc: fix SMP races when updating PTE and TLB entries in ent (11 May 2013)
[PATCH] parisc: make default cross compiler search more robust (9 May 2013)
[PATCH] parisc: implement irq stacks - part 2 (9 May 2013)
[PATCH] parisc: avoid WARNING: at kernel/cpu/idle.c:96 (8 May 2013)
[RFC] [PATCH] parisc: use Page Deallocation Table from firmware to exc (8 May 2013)
dringender Vorschlag (8 May 2013)
[GIT PULL] parisc updates for v3.10 (8 May 2013)
[PATCH] parisc: tlb flush counting fix for SMP and UP (7 May 2013)

Archives

68	May 2013
84	April 2013
27	March 2013
68	February 2013
29	January 2013
15	December 2012
20	November 2012
56	October 2012
23	September 2012
25	August 2012
9	July 2012
19	June 2012
150	May 2012
25	April 2012
19	March 2012
61	February 2012
39	January 2012
22	December 2011
12	November 2011
53	October 2011
26	September 2011
20	August 2011
69	July 2011
36	June 2011
54	May 2011
112	April 2011
42	March 2011
69	February 2011
37	January 2011
52	December 2010
55	November 2010
85	October 2010
23	September 2010
37	August 2010
17	July 2010
83	June 2010
62	May 2010
75	April 2010
57	March 2010
50	February 2010
62	January 2010
120	December 2009
75	November 2009
60	October 2009
124	September 2009
116	August 2009
130	July 2009
126	June 2009
112	May 2009
157	April 2009
92	March 2009
88	February 2009
174	January 2009
187	December 2008
66	November 2008
18	October 2008
111	September 2008
114	August 2008
98	July 2008
114	June 2008
72	May 2008
42	April 2008
106	March 2008
55	February 2008
30	January 2008
60	December 2007

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template