Communications among developers and users of Linux on embedded PowerPC boards

Scott Wood | 28 Jun 2012 01:48

[PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

The QEMU stuff is related to the PCI refactoring because currently
we have a hard time selecting a primary bus under QEMU, and also because
the generic qemu e500 platform wants a full list of FSL PCI compatibles
to check.

Scott Wood (3):
  powerpc/fsl-pci: get PCI init out of board files
  powerpc/e500: add paravirt QEMU platform
  powerpc/mpc85xx_ds: convert to unified PCI init

 arch/powerpc/platforms/85xx/Kconfig      |   16 +++++
 arch/powerpc/platforms/85xx/Makefile     |    1 +
 arch/powerpc/platforms/85xx/mpc85xx_ds.c |   97 +++++++++---------------------
 arch/powerpc/platforms/85xx/qemu_e500.c  |   66 ++++++++++++++++++++
 arch/powerpc/platforms/Kconfig.cputype   |    4 +
 arch/powerpc/sysdev/fsl_pci.c            |   66 ++++++++++++++++++++
 arch/powerpc/sysdev/fsl_pci.h            |    8 +++
 7 files changed, 190 insertions(+), 68 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c

--

-- 
1.7.5.4

headers

Scott Wood | 28 Jun 2012 01:50

[PATCH 1/3] powerpc/fsl-pci: provide common PCI init

As an alternative incremental starting point to Jia Hongtao's patchset,
get the FSL PCI init out of the board files, but do not yet convert to a
platform driver.

Rather than having each board supply a magic register offset for
determining the "primary" bus, we look for which PCI host bridge
contains an ISA node within its subtree.  If there is no ISA node,
normally that would mean there is no primary bus, but until certain
bugs are fixed we arbitrarily designate a primary in this case.

Conversion to a platform driver and related improvements can happen
after this, as the ordering issues are sorted out.

Signed-off-by: Scott Wood <scottwood <at> freescale.com>
---
 arch/powerpc/sysdev/fsl_pci.c |   66 +++++++++++++++++++++++++++++++++++++++++
 arch/powerpc/sysdev/fsl_pci.h |    8 +++++
 2 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 6073288..f61e407 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
 <at>  <at>  -807,3 +807,69  <at>  <at>  u64 fsl_pci_immrbar_base(struct pci_controller *hose)

 	return 0;
 }
+
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
+static const struct of_device_id pci_ids[] = {

(Continue reading)

headers

Scott Wood | 28 Jun 2012 01:50

[PATCH 1/3] powerpc/fsl-pci: provide common PCI init

As an alternative incremental starting point to Jia Hongtao's patchset,
get the FSL PCI init out of the board files, but do not yet convert to a
platform driver.

Rather than having each board supply a magic register offset for
determining the "primary" bus, we look for which PCI host bridge
contains an ISA node within its subtree.  If there is no ISA node,
normally that would mean there is no primary bus, but until certain
bugs are fixed we arbitrarily designate a primary in this case.

Conversion to a platform driver and related improvements can happen
after this, as the ordering issues are sorted out.

Signed-off-by: Scott Wood <scottwood <at> freescale.com>
---
 arch/powerpc/sysdev/fsl_pci.c |   66 +++++++++++++++++++++++++++++++++++++++++
 arch/powerpc/sysdev/fsl_pci.h |    8 +++++
 2 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 6073288..f61e407 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
 <at>  <at>  -807,3 +807,69  <at>  <at>  u64 fsl_pci_immrbar_base(struct pci_controller *hose)

 	return 0;
 }
+
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
+static const struct of_device_id pci_ids[] = {

(Continue reading)

headers

Scott Wood | 28 Jun 2012 01:50

[PATCH 2/3] powerpc/e500: add paravirt QEMU platform

This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios.  This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.

As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.

Signed-off-by: Scott Wood <scottwood <at> freescale.com>
---
 arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
 arch/powerpc/platforms/85xx/Makefile    |    1 +
 arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
 arch/powerpc/platforms/Kconfig.cputype  |    4 ++
 4 files changed, 87 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index f000d81..7bbebe5 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
 <at>  <at>  -263,6 +263,22  <at>  <at>  config P5020_DS
 	help
 	  This option enables support for the P5020 DS board

+config PPC_QEMU_E500
+	bool "QEMU generic e500 platform"
+	depends on EXPERIMENTAL

(Continue reading)

headers

Alexander Graf | 6 Jul 2012 14:29

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform


On 28.06.2012, at 01:50, Scott Wood wrote:

> This gives the kernel a paravirtualized machine to target, without
> requiring both sides to pretend to be targeting a specific board
> that likely has little to do with the host in KVM scenarios.  This
> avoids the need to add new boards to QEMU just to be able to
> run KVM on new CPUs.
> 
> As this is the first platform that can run with either e500v2 or
> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
> option, so add a help text.
> 
> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
> arch/powerpc/platforms/85xx/Makefile    |    1 +
> arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype  |    4 ++

I really think we should document what exactly this machine expects.

> 4 files changed, 87 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index f000d81..7bbebe5 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
>  <at>  <at>  -263,6 +263,22  <at>  <at>  config P5020_DS

(Continue reading)

headers

Scott Wood | 6 Jul 2012 18:25

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform

On 07/06/2012 07:29 AM, Alexander Graf wrote:
> 
> On 28.06.2012, at 01:50, Scott Wood wrote:
> 
>> This gives the kernel a paravirtualized machine to target, without
>> requiring both sides to pretend to be targeting a specific board
>> that likely has little to do with the host in KVM scenarios.  This
>> avoids the need to add new boards to QEMU just to be able to
>> run KVM on new CPUs.
>>
>> As this is the first platform that can run with either e500v2 or
>> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
>> option, so add a help text.
>>
>> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
>> arch/powerpc/platforms/85xx/Makefile    |    1 +
>> arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
>> arch/powerpc/platforms/Kconfig.cputype  |    4 ++
> 
> I really think we should document what exactly this machine expects.

Well, the point of this paravirt machine is to avoid such assumptions --
it's all device-tree driven, at least in theory.  If a certain qemu
configuration ends up breaking the Linux platform (such as using a
different PIC), then that's a lack of flexibility on Linux's part that
should get fixed if someone finds it useful enough to justify the
effort.  Same with real hardware -- if you care about it, you add
support -- we just don't have a unique name for every configuration.

(Continue reading)

headers

Alexander Graf | 6 Jul 2012 18:30

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform


On 06.07.2012, at 18:25, Scott Wood wrote:

> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>> 
>> On 28.06.2012, at 01:50, Scott Wood wrote:
>> 
>>> This gives the kernel a paravirtualized machine to target, without
>>> requiring both sides to pretend to be targeting a specific board
>>> that likely has little to do with the host in KVM scenarios.  This
>>> avoids the need to add new boards to QEMU just to be able to
>>> run KVM on new CPUs.
>>> 
>>> As this is the first platform that can run with either e500v2 or
>>> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
>>> option, so add a help text.
>>> 
>>> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
>>> ---
>>> arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
>>> arch/powerpc/platforms/85xx/Makefile    |    1 +
>>> arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
>>> arch/powerpc/platforms/Kconfig.cputype  |    4 ++
>> 
>> I really think we should document what exactly this machine expects.
> 
> Well, the point of this paravirt machine is to avoid such assumptions --
> it's all device-tree driven, at least in theory.  If a certain qemu
> configuration ends up breaking the Linux platform (such as using a
> different PIC), then that's a lack of flexibility on Linux's part that

(Continue reading)

headers

Scott Wood | 6 Jul 2012 18:52

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform

On 07/06/2012 11:30 AM, Alexander Graf wrote:
> 
> On 06.07.2012, at 18:25, Scott Wood wrote:
> 
>> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>>> I really think we should document what exactly this machine expects.
>>
>> Well, the point of this paravirt machine is to avoid such assumptions --
>> it's all device-tree driven, at least in theory.  If a certain qemu
>> configuration ends up breaking the Linux platform (such as using a
>> different PIC), then that's a lack of flexibility on Linux's part that
>> should get fixed if someone finds it useful enough to justify the
>> effort.  Same with real hardware -- if you care about it, you add
>> support -- we just don't have a unique name for every configuration.
>> The information is there in the device tree, though.
>>
>> Honestly, even having "qemu" in there is more specific than I'd prefer,
>> but I don't want to stir up the "generic platform" argument again
>> without at least limiting the scope.
> 
> Well, can't we note down the assumptions we make to make sure that
> whoever develops an implementation of it knows what to implement?
> It's ppc specific for example. I also don't think that plugging a G3
> in there works, would it?

Well, it does have "e500" in the name. :-P

>>>> +void __init qemu_e500_pic_init(void)
>>>> +{
>>>> +	struct mpic *mpic;

(Continue reading)

headers

Alexander Graf | 6 Jul 2012 18:59

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform


On 06.07.2012, at 18:52, Scott Wood wrote:

> On 07/06/2012 11:30 AM, Alexander Graf wrote:
>> 
>> On 06.07.2012, at 18:25, Scott Wood wrote:
>> 
>>> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>>>> I really think we should document what exactly this machine expects.
>>> 
>>> Well, the point of this paravirt machine is to avoid such assumptions --
>>> it's all device-tree driven, at least in theory.  If a certain qemu
>>> configuration ends up breaking the Linux platform (such as using a
>>> different PIC), then that's a lack of flexibility on Linux's part that
>>> should get fixed if someone finds it useful enough to justify the
>>> effort.  Same with real hardware -- if you care about it, you add
>>> support -- we just don't have a unique name for every configuration.
>>> The information is there in the device tree, though.
>>> 
>>> Honestly, even having "qemu" in there is more specific than I'd prefer,
>>> but I don't want to stir up the "generic platform" argument again
>>> without at least limiting the scope.
>> 
>> Well, can't we note down the assumptions we make to make sure that
>> whoever develops an implementation of it knows what to implement?
>> It's ppc specific for example. I also don't think that plugging a G3
>> in there works, would it?
> 
> Well, it does have "e500" in the name. :-P
>

(Continue reading)

headers

Alexander Graf | 6 Jul 2012 18:59

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform


On 06.07.2012, at 18:52, Scott Wood wrote:

> On 07/06/2012 11:30 AM, Alexander Graf wrote:
>> 
>> On 06.07.2012, at 18:25, Scott Wood wrote:
>> 
>>> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>>>> I really think we should document what exactly this machine expects.
>>> 
>>> Well, the point of this paravirt machine is to avoid such assumptions --
>>> it's all device-tree driven, at least in theory.  If a certain qemu
>>> configuration ends up breaking the Linux platform (such as using a
>>> different PIC), then that's a lack of flexibility on Linux's part that
>>> should get fixed if someone finds it useful enough to justify the
>>> effort.  Same with real hardware -- if you care about it, you add
>>> support -- we just don't have a unique name for every configuration.
>>> The information is there in the device tree, though.
>>> 
>>> Honestly, even having "qemu" in there is more specific than I'd prefer,
>>> but I don't want to stir up the "generic platform" argument again
>>> without at least limiting the scope.
>> 
>> Well, can't we note down the assumptions we make to make sure that
>> whoever develops an implementation of it knows what to implement?
>> It's ppc specific for example. I also don't think that plugging a G3
>> in there works, would it?
> 
> Well, it does have "e500" in the name. :-P
>

(Continue reading)

headers

Scott Wood | 6 Jul 2012 18:52

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform

On 07/06/2012 11:30 AM, Alexander Graf wrote:
> 
> On 06.07.2012, at 18:25, Scott Wood wrote:
> 
>> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>>> I really think we should document what exactly this machine expects.
>>
>> Well, the point of this paravirt machine is to avoid such assumptions --
>> it's all device-tree driven, at least in theory.  If a certain qemu
>> configuration ends up breaking the Linux platform (such as using a
>> different PIC), then that's a lack of flexibility on Linux's part that
>> should get fixed if someone finds it useful enough to justify the
>> effort.  Same with real hardware -- if you care about it, you add
>> support -- we just don't have a unique name for every configuration.
>> The information is there in the device tree, though.
>>
>> Honestly, even having "qemu" in there is more specific than I'd prefer,
>> but I don't want to stir up the "generic platform" argument again
>> without at least limiting the scope.
> 
> Well, can't we note down the assumptions we make to make sure that
> whoever develops an implementation of it knows what to implement?
> It's ppc specific for example. I also don't think that plugging a G3
> in there works, would it?

Well, it does have "e500" in the name. :-P

>>>> +void __init qemu_e500_pic_init(void)
>>>> +{
>>>> +	struct mpic *mpic;

(Continue reading)

headers

Alexander Graf | 6 Jul 2012 18:30

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform


On 06.07.2012, at 18:25, Scott Wood wrote:

> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>> 
>> On 28.06.2012, at 01:50, Scott Wood wrote:
>> 
>>> This gives the kernel a paravirtualized machine to target, without
>>> requiring both sides to pretend to be targeting a specific board
>>> that likely has little to do with the host in KVM scenarios.  This
>>> avoids the need to add new boards to QEMU just to be able to
>>> run KVM on new CPUs.
>>> 
>>> As this is the first platform that can run with either e500v2 or
>>> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
>>> option, so add a help text.
>>> 
>>> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
>>> ---
>>> arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
>>> arch/powerpc/platforms/85xx/Makefile    |    1 +
>>> arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
>>> arch/powerpc/platforms/Kconfig.cputype  |    4 ++
>> 
>> I really think we should document what exactly this machine expects.
> 
> Well, the point of this paravirt machine is to avoid such assumptions --
> it's all device-tree driven, at least in theory.  If a certain qemu
> configuration ends up breaking the Linux platform (such as using a
> different PIC), then that's a lack of flexibility on Linux's part that

(Continue reading)

headers

Scott Wood | 6 Jul 2012 18:25

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform

On 07/06/2012 07:29 AM, Alexander Graf wrote:
> 
> On 28.06.2012, at 01:50, Scott Wood wrote:
> 
>> This gives the kernel a paravirtualized machine to target, without
>> requiring both sides to pretend to be targeting a specific board
>> that likely has little to do with the host in KVM scenarios.  This
>> avoids the need to add new boards to QEMU just to be able to
>> run KVM on new CPUs.
>>
>> As this is the first platform that can run with either e500v2 or
>> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
>> option, so add a help text.
>>
>> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
>> arch/powerpc/platforms/85xx/Makefile    |    1 +
>> arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
>> arch/powerpc/platforms/Kconfig.cputype  |    4 ++
> 
> I really think we should document what exactly this machine expects.

Well, the point of this paravirt machine is to avoid such assumptions --
it's all device-tree driven, at least in theory.  If a certain qemu
configuration ends up breaking the Linux platform (such as using a
different PIC), then that's a lack of flexibility on Linux's part that
should get fixed if someone finds it useful enough to justify the
effort.  Same with real hardware -- if you care about it, you add
support -- we just don't have a unique name for every configuration.

(Continue reading)

headers

Alexander Graf | 6 Jul 2012 14:29

Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform


On 28.06.2012, at 01:50, Scott Wood wrote:

> This gives the kernel a paravirtualized machine to target, without
> requiring both sides to pretend to be targeting a specific board
> that likely has little to do with the host in KVM scenarios.  This
> avoids the need to add new boards to QEMU just to be able to
> run KVM on new CPUs.
> 
> As this is the first platform that can run with either e500v2 or
> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
> option, so add a help text.
> 
> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
> arch/powerpc/platforms/85xx/Makefile    |    1 +
> arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype  |    4 ++

I really think we should document what exactly this machine expects.

> 4 files changed, 87 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index f000d81..7bbebe5 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
>  <at>  <at>  -263,6 +263,22  <at>  <at>  config P5020_DS

(Continue reading)

headers

Scott Wood | 28 Jun 2012 01:50

[PATCH 2/3] powerpc/e500: add paravirt QEMU platform

This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios.  This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.

As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.

Signed-off-by: Scott Wood <scottwood <at> freescale.com>
---
 arch/powerpc/platforms/85xx/Kconfig     |   16 +++++++
 arch/powerpc/platforms/85xx/Makefile    |    1 +
 arch/powerpc/platforms/85xx/qemu_e500.c |   66 +++++++++++++++++++++++++++++++
 arch/powerpc/platforms/Kconfig.cputype  |    4 ++
 4 files changed, 87 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index f000d81..7bbebe5 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
 <at>  <at>  -263,6 +263,22  <at>  <at>  config P5020_DS
 	help
 	  This option enables support for the P5020 DS board

+config PPC_QEMU_E500
+	bool "QEMU generic e500 platform"
+	depends on EXPERIMENTAL

(Continue reading)

headers

Scott Wood | 28 Jun 2012 01:50

[PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init

Similar to how the primary PCI bridge is identified by looking
for an isa subnode, we determine whether to apply uli exclusions
by looking for a uli subnode.

Signed-off-by: Scott Wood <scottwood <at> freescale.com>
---
Besides being an example of a real-hardware board to use the new PCI init
(probably one of the more complicated examples due to the uli device
exclusion), this fixes PCI under QEMU's mpc8544ds machine.  QEMU was
only creating one PCI bus, and it wasn't the one Linux had arbitrarily
deemed primary for mpc8544ds (AFAIK, there's no legacy ISA on this
board).

Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli).

 arch/powerpc/platforms/85xx/mpc85xx_ds.c |   97 +++++++++---------------------
 1 files changed, 29 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 1fd91e9..6d3265f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
 <at>  <at>  -114,71 +114,53  <at>  <at>  void __init mpc85xx_ds_pic_init(void)
 }

 #ifdef CONFIG_PCI
-static int primary_phb_addr;
 extern int uli_exclude_device(struct pci_controller *hose,
 				u_char bus, u_char devfn);

(Continue reading)

headers

Kumar Gala | 10 Jul 2012 20:31

Re: [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init


On Jun 27, 2012, at 6:50 PM, Scott Wood wrote:

> Similar to how the primary PCI bridge is identified by looking
> for an isa subnode, we determine whether to apply uli exclusions
> by looking for a uli subnode.
> 
> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
> ---
> Besides being an example of a real-hardware board to use the new PCI init
> (probably one of the more complicated examples due to the uli device
> exclusion), this fixes PCI under QEMU's mpc8544ds machine.  QEMU was
> only creating one PCI bus, and it wasn't the one Linux had arbitrarily
> deemed primary for mpc8544ds (AFAIK, there's no legacy ISA on this
> board).
> 
> Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli).
> 
> arch/powerpc/platforms/85xx/mpc85xx_ds.c |   97 +++++++++---------------------
> 1 files changed, 29 insertions(+), 68 deletions(-)

Can you rebase against my 'next' branch.. having issues applying this.

- k

headers

Kumar Gala | 10 Jul 2012 20:31

Re: [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init


On Jun 27, 2012, at 6:50 PM, Scott Wood wrote:

> Similar to how the primary PCI bridge is identified by looking
> for an isa subnode, we determine whether to apply uli exclusions
> by looking for a uli subnode.
> 
> Signed-off-by: Scott Wood <scottwood <at> freescale.com>
> ---
> Besides being an example of a real-hardware board to use the new PCI init
> (probably one of the more complicated examples due to the uli device
> exclusion), this fixes PCI under QEMU's mpc8544ds machine.  QEMU was
> only creating one PCI bus, and it wasn't the one Linux had arbitrarily
> deemed primary for mpc8544ds (AFAIK, there's no legacy ISA on this
> board).
> 
> Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli).
> 
> arch/powerpc/platforms/85xx/mpc85xx_ds.c |   97 +++++++++---------------------
> 1 files changed, 29 insertions(+), 68 deletions(-)

Can you rebase against my 'next' branch.. having issues applying this.

- k

headers

Scott Wood | 28 Jun 2012 01:50

[PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init

Similar to how the primary PCI bridge is identified by looking
for an isa subnode, we determine whether to apply uli exclusions
by looking for a uli subnode.

Signed-off-by: Scott Wood <scottwood <at> freescale.com>
---
Besides being an example of a real-hardware board to use the new PCI init
(probably one of the more complicated examples due to the uli device
exclusion), this fixes PCI under QEMU's mpc8544ds machine.  QEMU was
only creating one PCI bus, and it wasn't the one Linux had arbitrarily
deemed primary for mpc8544ds (AFAIK, there's no legacy ISA on this
board).

Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli).

 arch/powerpc/platforms/85xx/mpc85xx_ds.c |   97 +++++++++---------------------
 1 files changed, 29 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 1fd91e9..6d3265f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
 <at>  <at>  -114,71 +114,53  <at>  <at>  void __init mpc85xx_ds_pic_init(void)
 }

 #ifdef CONFIG_PCI
-static int primary_phb_addr;
 extern int uli_exclude_device(struct pci_controller *hose,
 				u_char bus, u_char devfn);

(Continue reading)

headers

Jia Hongtao-B38951 | 28 Jun 2012 06:06

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, June 28, 2012 7:49 AM
> To: galak <at> kernel.crashing.org
> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> The QEMU stuff is related to the PCI refactoring because currently
> we have a hard time selecting a primary bus under QEMU, and also because
> the generic qemu e500 platform wants a full list of FSL PCI compatibles
> to check.
> 

It seems that not all primary bus has "isa" node like 8541 and 8555.

Without PM support for pci controllers I totally agree with this refactoring
for pci init. But in linux mechanism PM ops should be registered to a driver.
Do you have any ideas to add PM support for pci controllers under this patchset?

Thanks.
-Jia Hongtao.

headers

Scott Wood | 28 Jun 2012 18:31

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Thursday, June 28, 2012 7:49 AM
>> To: galak <at> kernel.crashing.org
>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>> platform
>>
>> The QEMU stuff is related to the PCI refactoring because currently
>> we have a hard time selecting a primary bus under QEMU, and also because
>> the generic qemu e500 platform wants a full list of FSL PCI compatibles
>> to check.
>>
> 
> It seems that not all primary bus has "isa" node like 8541 and 8555.

Do those boards (it's the boards that matter, not chips...) have legacy
ISA?  If they do, and it's not in the device tree, then we should fix
the device tree for consistency, but also retain some sort of hack to
remain compatible with old device trees.

A board can refrain from using the new common infrastructure if it has a
good reason to.

> Without PM support for pci controllers I totally agree with this refactoring
> for pci init. But in linux mechanism PM ops should be registered to a driver.
> Do you have any ideas to add PM support for pci controllers under this patchset?

(Continue reading)

headers

Jia Hongtao-B38951 | 29 Jun 2012 04:36

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, June 29, 2012 12:31 AM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Thursday, June 28, 2012 7:49 AM
> >> To: galak <at> kernel.crashing.org
> >> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
> >> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> >> platform
> >>
> >> The QEMU stuff is related to the PCI refactoring because currently
> >> we have a hard time selecting a primary bus under QEMU, and also
> because
> >> the generic qemu e500 platform wants a full list of FSL PCI
> compatibles
> >> to check.
> >>
> >
> > It seems that not all primary bus has "isa" node like 8541 and 8555.

(Continue reading)

headers

Kumar Gala | 29 Jun 2012 17:57

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:

> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Friday, June 29, 2012 12:31 AM
>> To: Jia Hongtao-B38951
>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>> platform
>> 
>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>> To: galak <at> kernel.crashing.org
>>>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>> platform
>>>> 
>>>> The QEMU stuff is related to the PCI refactoring because currently
>>>> we have a hard time selecting a primary bus under QEMU, and also
>> because
>>>> the generic qemu e500 platform wants a full list of FSL PCI
>> compatibles

(Continue reading)

headers

Scott Wood | 29 Jun 2012 18:01

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

On 06/29/2012 10:57 AM, Kumar Gala wrote:
> 
> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
> 
>>
>>
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Friday, June 29, 2012 12:31 AM
>>> To: Jia Hongtao-B38951
>>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
>>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
>>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>> platform
>>>
>>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>>> To: galak <at> kernel.crashing.org
>>>>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>>> platform
>>>>>
>>>>> The QEMU stuff is related to the PCI refactoring because currently
>>>>> we have a hard time selecting a primary bus under QEMU, and also
>>> because
>>>>> the generic qemu e500 platform wants a full list of FSL PCI

(Continue reading)

headers

Kumar Gala | 29 Jun 2012 18:04

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


On Jun 29, 2012, at 11:01 AM, Scott Wood wrote:

> On 06/29/2012 10:57 AM, Kumar Gala wrote:
>> 
>> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Friday, June 29, 2012 12:31 AM
>>>> To: Jia Hongtao-B38951
>>>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
>>>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
>>>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>> platform
>>>> 
>>>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Wood Scott-B07421
>>>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>>>> To: galak <at> kernel.crashing.org
>>>>>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>>>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>>>> platform
>>>>>> 
>>>>>> The QEMU stuff is related to the PCI refactoring because currently

(Continue reading)

headers

Kumar Gala | 29 Jun 2012 18:04

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


On Jun 29, 2012, at 11:01 AM, Scott Wood wrote:

> On 06/29/2012 10:57 AM, Kumar Gala wrote:
>> 
>> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Friday, June 29, 2012 12:31 AM
>>>> To: Jia Hongtao-B38951
>>>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
>>>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
>>>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>> platform
>>>> 
>>>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Wood Scott-B07421
>>>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>>>> To: galak <at> kernel.crashing.org
>>>>>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>>>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>>>> platform
>>>>>> 
>>>>>> The QEMU stuff is related to the PCI refactoring because currently

(Continue reading)

headers

Li Yang-R58472 | 29 Jun 2012 18:18

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, June 29, 2012 11:02 AM
> To: Kumar Gala
> Cc: Jia Hongtao-B38951; Wood Scott-B07421; Li Yang-R58472; agraf <at> suse.de;
> linuxppc-dev <at> lists.ozlabs.org
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> On 06/29/2012 10:57 AM, Kumar Gala wrote:
> >
> > On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Wood Scott-B07421
> >>> Sent: Friday, June 29, 2012 12:31 AM
> >>> To: Jia Hongtao-B38951
> >>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
> >>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
> >>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU
> >>> paravirt platform
> >>>
> >>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Wood Scott-B07421

(Continue reading)

headers

Scott Wood | 29 Jun 2012 18:59

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

On 06/29/2012 11:18 AM, Li Yang-R58472 wrote:
> 
> 
>> -----Original Message----- From: Wood Scott-B07421 Sent: Friday,
>> June 29, 2012 11:02 AM To: Kumar Gala Cc: Jia Hongtao-B38951; Wood
>> Scott-B07421; Li Yang-R58472; agraf <at> suse.de; 
>> linuxppc-dev <at> lists.ozlabs.org Subject: Re: [PATCH 0/3] powerpc/fsl:
>> PCI refactoring and QEMU paravirt platform
>> 
>> On 06/29/2012 10:57 AM, Kumar Gala wrote:
>>> Pretty sure the boards have ISA, if you see the .dts has
>>> references to
>> 'ISA bridge' & 'i8259' PIC.
>> 
>> OK.  How about looking for an i8259 node as well?
> 
> That could work, but looks hackish.  Our proposal for adding a new
> device tree property is a generic solution. 

Yes, all *new* boards should have an isa node.  But we want to remain
compatible with existing device trees.

> The only problem is that
> new kernels would work with old device trees.  I think we can use
> your solution for transitional period.  And go for a well defined
> device tree binding for this in long run.

The "transitional period" is until we no longer care about these
specific boards, or any out-of-tree derivatives.

(Continue reading)

headers

Scott Wood | 29 Jun 2012 18:59

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

On 06/29/2012 11:18 AM, Li Yang-R58472 wrote:
> 
> 
>> -----Original Message----- From: Wood Scott-B07421 Sent: Friday,
>> June 29, 2012 11:02 AM To: Kumar Gala Cc: Jia Hongtao-B38951; Wood
>> Scott-B07421; Li Yang-R58472; agraf <at> suse.de; 
>> linuxppc-dev <at> lists.ozlabs.org Subject: Re: [PATCH 0/3] powerpc/fsl:
>> PCI refactoring and QEMU paravirt platform
>> 
>> On 06/29/2012 10:57 AM, Kumar Gala wrote:
>>> Pretty sure the boards have ISA, if you see the .dts has
>>> references to
>> 'ISA bridge' & 'i8259' PIC.
>> 
>> OK.  How about looking for an i8259 node as well?
> 
> That could work, but looks hackish.  Our proposal for adding a new
> device tree property is a generic solution. 

Yes, all *new* boards should have an isa node.  But we want to remain
compatible with existing device trees.

> The only problem is that
> new kernels would work with old device trees.  I think we can use
> your solution for transitional period.  And go for a well defined
> device tree binding for this in long run.

The "transitional period" is until we no longer care about these
specific boards, or any out-of-tree derivatives.

(Continue reading)

headers

Li Yang-R58472 | 29 Jun 2012 18:18

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, June 29, 2012 11:02 AM
> To: Kumar Gala
> Cc: Jia Hongtao-B38951; Wood Scott-B07421; Li Yang-R58472; agraf <at> suse.de;
> linuxppc-dev <at> lists.ozlabs.org
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> On 06/29/2012 10:57 AM, Kumar Gala wrote:
> >
> > On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Wood Scott-B07421
> >>> Sent: Friday, June 29, 2012 12:31 AM
> >>> To: Jia Hongtao-B38951
> >>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
> >>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
> >>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU
> >>> paravirt platform
> >>>
> >>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Wood Scott-B07421

(Continue reading)

headers

Scott Wood | 29 Jun 2012 18:01

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

On 06/29/2012 10:57 AM, Kumar Gala wrote:
> 
> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
> 
>>
>>
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Friday, June 29, 2012 12:31 AM
>>> To: Jia Hongtao-B38951
>>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
>>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
>>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>> platform
>>>
>>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>>> To: galak <at> kernel.crashing.org
>>>>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>>> platform
>>>>>
>>>>> The QEMU stuff is related to the PCI refactoring because currently
>>>>> we have a hard time selecting a primary bus under QEMU, and also
>>> because
>>>>> the generic qemu e500 platform wants a full list of FSL PCI

(Continue reading)

headers

Zang Roy-R61911 | 29 Jun 2012 18:06

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=freescale.com <at> lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Friday, June 29, 2012 23:58 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev <at> lists.ozlabs.org; Li Yang-R58472;
> agraf <at> suse.de
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> 
> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Friday, June 29, 2012 12:31 AM
> >> To: Jia Hongtao-B38951
> >> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
> >> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
> >> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> >> platform
> >>
> >> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Wood Scott-B07421

(Continue reading)

headers

Zang Roy-R61911 | 29 Jun 2012 18:06

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=freescale.com <at> lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Friday, June 29, 2012 23:58 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev <at> lists.ozlabs.org; Li Yang-R58472;
> agraf <at> suse.de
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> 
> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Friday, June 29, 2012 12:31 AM
> >> To: Jia Hongtao-B38951
> >> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
> >> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
> >> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> >> platform
> >>
> >> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Wood Scott-B07421

(Continue reading)

headers

Kumar Gala | 29 Jun 2012 17:57

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:

> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Friday, June 29, 2012 12:31 AM
>> To: Jia Hongtao-B38951
>> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
>> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>> platform
>> 
>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>> To: galak <at> kernel.crashing.org
>>>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>> platform
>>>> 
>>>> The QEMU stuff is related to the PCI refactoring because currently
>>>> we have a hard time selecting a primary bus under QEMU, and also
>> because
>>>> the generic qemu e500 platform wants a full list of FSL PCI
>> compatibles

(Continue reading)

headers

Jia Hongtao-B38951 | 29 Jun 2012 04:36

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, June 29, 2012 12:31 AM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; galak <at> kernel.crashing.org; Li Yang-R58472;
> agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Thursday, June 28, 2012 7:49 AM
> >> To: galak <at> kernel.crashing.org
> >> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
> >> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> >> platform
> >>
> >> The QEMU stuff is related to the PCI refactoring because currently
> >> we have a hard time selecting a primary bus under QEMU, and also
> because
> >> the generic qemu e500 platform wants a full list of FSL PCI
> compatibles
> >> to check.
> >>
> >
> > It seems that not all primary bus has "isa" node like 8541 and 8555.

(Continue reading)

headers

Scott Wood | 28 Jun 2012 18:31

Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform

On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Thursday, June 28, 2012 7:49 AM
>> To: galak <at> kernel.crashing.org
>> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>> platform
>>
>> The QEMU stuff is related to the PCI refactoring because currently
>> we have a hard time selecting a primary bus under QEMU, and also because
>> the generic qemu e500 platform wants a full list of FSL PCI compatibles
>> to check.
>>
> 
> It seems that not all primary bus has "isa" node like 8541 and 8555.

Do those boards (it's the boards that matter, not chips...) have legacy
ISA?  If they do, and it's not in the device tree, then we should fix
the device tree for consistency, but also retain some sort of hack to
remain compatible with old device trees.

A board can refrain from using the new common infrastructure if it has a
good reason to.

> Without PM support for pci controllers I totally agree with this refactoring
> for pci init. But in linux mechanism PM ops should be registered to a driver.
> Do you have any ideas to add PM support for pci controllers under this patchset?

(Continue reading)

headers

Jia Hongtao-B38951 | 28 Jun 2012 06:06

RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, June 28, 2012 7:49 AM
> To: galak <at> kernel.crashing.org
> Cc: agraf <at> suse.de; linuxppc-dev <at> lists.ozlabs.org; Jia Hongtao-B38951
> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
> 
> The QEMU stuff is related to the PCI refactoring because currently
> we have a hard time selecting a primary bus under QEMU, and also because
> the generic qemu e500 platform wants a full list of FSL PCI compatibles
> to check.
> 

It seems that not all primary bus has "isa" node like 8541 and 8555.

Without PM support for pci controllers I totally agree with this refactoring
for pci init. But in linux mechanism PM ops should be registered to a driver.
Do you have any ideas to add PM support for pci controllers under this patchset?

Thanks.
-Jia Hongtao.