All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org
Subject: Re: [PATCH 2/11] cell: generalize io-workarounds code
Date: Fri, 28 Mar 2008 08:08:21 +1100	[thread overview]
Message-ID: <1206652101.10388.28.camel@pasglop> (raw)
In-Reply-To: <20080327.200215.-1300539001.kouish@swc.toshiba.co.jp>


On Thu, 2008-03-27 at 20:02 +0900, Ishizaki Kou wrote:
> 
> > I'll try to have a closer look next week, but I'm a bit worried by
> > having all IO go through 2 level of function pointers, the PPE isn't
> > very good at it and this will slow things down more than they
> already
> > are.
> 
> Only on celleb, all IO go through 2 level of function pointers.
>  
> On cell blades, you can set global variable "ppc_pci_io" up at
> function 
> spider_pci_workaround_init() directly instead of calling function
> io_workaround_init(), so all IO on cell blades use only one level of 
> function pointer which is stored in ppc_pci_io.

But I would probably want to also use the PCI Express stuff for cell
blades...

> As you said, if read/write/in/out functions take device parameter,
> taking I/O function pointers into the dev_archdata structure should be
> the best solution. But they don't take device parameter, and they must
> search I/O function pointers with address parameter. I think it's
> better they search pointers from bus bridges, because access mothod
> for a device on its parent bus bridge, not device itself.

What I meant is that if the pointers are in dev_archdata, we can
populate with a different set of pointers for PCI vs. PCI-E.

Ben.

  reply	other threads:[~2008-03-27 21:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-14 12:20 [PATCH 2/11] cell: generalize io-workarounds code Ishizaki Kou
2008-03-24 10:41 ` Benjamin Herrenschmidt
2008-03-24 10:44   ` Benjamin Herrenschmidt
2008-03-27 11:02     ` Ishizaki Kou
2008-03-27 21:08       ` Benjamin Herrenschmidt [this message]
2008-04-02 10:52         ` Ishizaki Kou
2008-04-02 11:00           ` Benjamin Herrenschmidt
2008-04-04  6:42             ` Ishizaki Kou
2008-04-04  7:50               ` Benjamin Herrenschmidt
2008-04-09  7:46                 ` Ishizaki Kou
2008-04-16  7:18 ` Benjamin Herrenschmidt
2008-04-17  1:48   ` Benjamin Herrenschmidt
2008-04-24  3:07     ` Ishizaki Kou
2008-04-24  3:30       ` Benjamin Herrenschmidt
2008-04-24  3:10     ` Ishizaki Kou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206652101.10388.28.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=kou.ishizaki@toshiba.co.jp \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.