* [PATCH 1/3] powerpc/fsl-pci: provide common PCI init
2012-06-27 23:48 [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Scott Wood
@ 2012-06-27 23:50 ` Scott Wood
2012-06-27 23:50 ` [PATCH 2/3] powerpc/e500: add paravirt QEMU platform Scott Wood
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Scott Wood @ 2012-06-27 23:50 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, agraf, Jia Hongtao
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@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
@@ -807,3 +807,69 @@ 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[] = {
+ { .compatible = "fsl,mpc8540-pci", },
+ { .compatible = "fsl,mpc8548-pcie", },
+ { .compatible = "fsl,mpc8610-pci", },
+ { .compatible = "fsl,mpc8641-pcie", },
+ { .compatible = "fsl,p1022-pcie", },
+ { .compatible = "fsl,p1010-pcie", },
+ { .compatible = "fsl,p1023-pcie", },
+ { .compatible = "fsl,p4080-pcie", },
+ { .compatible = "fsl,qoriq-pcie-v2.3", },
+ { .compatible = "fsl,qoriq-pcie-v2.2", },
+ {},
+};
+
+struct device_node *fsl_pci_primary;
+
+void __devinit fsl_pci_init(void)
+{
+ struct device_node *node;
+ struct pci_controller *hose;
+ dma_addr_t max = 0xffffffff;
+
+ /* If a PCI host bridge has an ISA node under it, it's primary. */
+ node = of_find_node_by_type(NULL, "isa");
+ while ((fsl_pci_primary = of_get_parent(node))) {
+ of_node_put(node);
+ node = fsl_pci_primary;
+
+ if (of_match_node(pci_ids, node))
+ break;
+ }
+
+ node = NULL;
+ for_each_node_by_type(node, "pci") {
+ if (of_match_node(pci_ids, node)) {
+ /*
+ * If there's no PCI host bridge with ISA, arbitrarily
+ * designate one as primary. This can go away once
+ * various bugs with primary-less systems are fixed.
+ */
+ if (!fsl_pci_primary)
+ fsl_pci_primary = node;
+
+ fsl_add_bridge(node, fsl_pci_primary == node);
+ hose = pci_find_hose_for_OF_device(node);
+ max = min(max, hose->dma_window_base_cur +
+ hose->dma_window_size);
+ }
+ }
+
+#ifdef CONFIG_SWIOTLB
+ /*
+ * if we couldn't map all of DRAM via the dma windows
+ * we need SWIOTLB to handle buffers located outside of
+ * dma capable memory region
+ */
+ if (memblock_end_of_DRAM() - 1 > max) {
+ ppc_swiotlb_enable = 1;
+ set_pci_dma_ops(&swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+ }
+#endif
+}
+#endif
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a39ed5c..baa0fd1 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -93,5 +93,13 @@ extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
extern int mpc83xx_add_bridge(struct device_node *dev);
u64 fsl_pci_immrbar_base(struct pci_controller *hose);
+extern struct device_node *fsl_pci_primary;
+
+#ifdef CONFIG_FSL_PCI
+void fsl_pci_init(void);
+#else
+static inline void fsl_pci_init(void) {}
+#endif
+
#endif /* __POWERPC_FSL_PCI_H */
#endif /* __KERNEL__ */
--
1.7.5.4
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-06-27 23:48 [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Scott Wood
2012-06-27 23:50 ` [PATCH 1/3] powerpc/fsl-pci: provide common PCI init Scott Wood
@ 2012-06-27 23:50 ` Scott Wood
2012-07-06 12:29 ` Alexander Graf
2012-06-27 23:50 ` [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init Scott Wood
2012-06-28 4:06 ` [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Jia Hongtao-B38951
3 siblings, 1 reply; 20+ messages in thread
From: Scott Wood @ 2012-06-27 23:50 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, agraf, Jia Hongtao
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@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
@@ -263,6 +263,22 @@ 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
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for running as a QEMU guest using
+ QEMU's generic e500 machine. This is not required if you're
+ using a QEMU machine that targets a specific board, such as
+ mpc8544ds.
+
+ Unlike most e500 boards that target a specific CPU, this
+ platform works with any e500-family CPU that QEMU supports.
+ Thus, you'll need to make sure CONFIG_PPC_E500MC is set or
+ unset based on the emulated CPU (or actual host CPU in the case
+ of KVM).
+
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 2125d4c..f841ac8 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_SOCRATES) += socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560) += ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
obj-$(CONFIG_GE_IMP3A) += ge_imp3a.o
+obj-$(CONFIG_PPC_QEMU_E500) += qemu_e500.o
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
new file mode 100644
index 0000000..77c8d5d
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -0,0 +1,66 @@
+/*
+ * Paravirt target for a generic QEMU e500 machine
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_fdt.h>
+#include <asm/machdep.h>
+#include <asm/time.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include "smp.h"
+#include "mpc85xx.h"
+
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+static void __init qemu_e500_setup_arch(void)
+{
+ ppc_md.progress("qemu_e500_setup_arch()", 0);
+
+ fsl_pci_init();
+ mpc85xx_smp_init();
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init qemu_e500_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return !!of_flat_dt_is_compatible(root, "fsl,qemu-e500");
+}
+
+machine_device_initcall(qemu_e500, mpc85xx_common_publish_devices);
+
+define_machine(qemu_e500) {
+ .name = "QEMU e500",
+ .probe = qemu_e500_probe,
+ .setup_arch = qemu_e500_setup_arch,
+ .init_IRQ = qemu_e500_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 61c9550..30fd01d 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -159,6 +159,10 @@ config PPC_E500MC
bool "e500mc Support"
select PPC_FPU
depends on E500
+ help
+ This must be enabled for running on e500mc (and derivatives
+ such as e5500/e6500), and must be disabled for running on
+ e500v1 or e500v2.
config PPC_FPU
bool
--
1.7.5.4
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-06-27 23:50 ` [PATCH 2/3] powerpc/e500: add paravirt QEMU platform Scott Wood
@ 2012-07-06 12:29 ` Alexander Graf
2012-07-06 16:25 ` Scott Wood
0 siblings, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2012-07-06 12:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Jia Hongtao
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.
>=20
> 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.
>=20
> Signed-off-by: Scott Wood <scottwood@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
>=20
> 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
> @@ -263,6 +263,22 @@ config P5020_DS
> help
> This option enables support for the P5020 DS board
>=20
> +config PPC_QEMU_E500
> + bool "QEMU generic e500 platform"
> + depends on EXPERIMENTAL
> + select DEFAULT_UIMAGE
> + help
> + This option enables support for running as a QEMU guest using
> + QEMU's generic e500 machine. This is not required if you're
> + using a QEMU machine that targets a specific board, such as
> + mpc8544ds.
> +
> + Unlike most e500 boards that target a specific CPU, this
> + platform works with any e500-family CPU that QEMU supports.
> + Thus, you'll need to make sure CONFIG_PPC_E500MC is set or
> + unset based on the emulated CPU (or actual host CPU in the =
case
> + of KVM).
> +
> endif # FSL_SOC_BOOKE
>=20
> config TQM85xx
> diff --git a/arch/powerpc/platforms/85xx/Makefile =
b/arch/powerpc/platforms/85xx/Makefile
> index 2125d4c..f841ac8 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_SOCRATES) +=3D socrates.o =
socrates_fpga_pic.o
> obj-$(CONFIG_KSI8560) +=3D ksi8560.o
> obj-$(CONFIG_XES_MPC85xx) +=3D xes_mpc85xx.o
> obj-$(CONFIG_GE_IMP3A) +=3D ge_imp3a.o
> +obj-$(CONFIG_PPC_QEMU_E500) +=3D qemu_e500.o
> diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c =
b/arch/powerpc/platforms/85xx/qemu_e500.c
> new file mode 100644
> index 0000000..77c8d5d
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/qemu_e500.c
> @@ -0,0 +1,66 @@
> +/*
> + * Paravirt target for a generic QEMU e500 machine
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or =
modify it
> + * under the terms of the GNU General Public License as published =
by the
> + * Free Software Foundation; either version 2 of the License, or =
(at your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/of_fdt.h>
> +#include <asm/machdep.h>
> +#include <asm/time.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +#include "smp.h"
> +#include "mpc85xx.h"
> +
> +void __init qemu_e500_pic_init(void)
> +{
> + struct mpic *mpic;
> +
> + mpic =3D mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | =
MPIC_SINGLE_DEST_CPU,
> + 0, 256, " OpenPIC ");
Does that mean we're configuring the MPIC regardless of what the guest =
tells us? So the MPIC is a hard requirement. We can't use UIC or XPIC =
with this machine, right? This needs to be documented.
> +
> + BUG_ON(mpic =3D=3D NULL);
> + mpic_init(mpic);
> +}
> +
> +static void __init qemu_e500_setup_arch(void)
> +{
> + ppc_md.progress("qemu_e500_setup_arch()", 0);
> +
> + fsl_pci_init();
> + mpc85xx_smp_init();
> +}
> +
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +static int __init qemu_e500_probe(void)
> +{
> + unsigned long root =3D of_get_flat_dt_root();
> +
> + return !!of_flat_dt_is_compatible(root, "fsl,qemu-e500");
So the machine needs to be compatible "fsl,qemu-e500". Needs =
documentation in the machine spec.
I'm sure you'll find more constraints that appear logical, but really =
should be written down so we have something formal that potentially =
someone not-QEMU or not-Scott could write a machine implementation =
against ;).
Alex
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-07-06 12:29 ` Alexander Graf
@ 2012-07-06 16:25 ` Scott Wood
2012-07-06 16:30 ` Alexander Graf
0 siblings, 1 reply; 20+ messages in thread
From: Scott Wood @ 2012-07-06 16:25 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev
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@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.
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.
>> +void __init qemu_e500_pic_init(void)
>> +{
>> + struct mpic *mpic;
>> +
>> + mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
>> + 0, 256, " OpenPIC ");
>
> Does that mean we're configuring the MPIC regardless of what the
> guest tells us? So the MPIC is a hard requirement. We can't use UIC
> or XPIC with this machine, right? This needs to be documented.
Then what would we do if we want to add an ePAPR virtual PIC instead?
Or if something replaces MPIC on future FSL chips?
Better to change the Linux implementation as needed than to change a spec.
-Scott
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-07-06 16:25 ` Scott Wood
@ 2012-07-06 16:30 ` Alexander Graf
2012-07-06 16:52 ` Scott Wood
0 siblings, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2012-07-06 16:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
On 06.07.2012, at 18:25, Scott Wood wrote:
> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>>=20
>> On 28.06.2012, at 01:50, Scott Wood wrote:
>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Signed-off-by: Scott Wood <scottwood@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 ++
>>=20
>> I really think we should document what exactly this machine expects.
>=20
> 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.
>=20
> 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?
>=20
>>> +void __init qemu_e500_pic_init(void)
>>> +{
>>> + struct mpic *mpic;
>>> +
>>> + mpic =3D mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | =
MPIC_SINGLE_DEST_CPU,
>>> + 0, 256, " OpenPIC ");
>>=20
>> Does that mean we're configuring the MPIC regardless of what the
>> guest tells us? So the MPIC is a hard requirement. We can't use UIC
>> or XPIC with this machine, right? This needs to be documented.
>=20
> Then what would we do if we want to add an ePAPR virtual PIC instead?
> Or if something replaces MPIC on future FSL chips?
Then we need a different compatible anyways, because we wouldn't be =
backwards compatible, no?
> Better to change the Linux implementation as needed than to change a =
spec.
Why not keep the 2 in sync in the same patch? Just throw a file with a =
rough outline of the machine in Documentation/.
Alex
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-07-06 16:30 ` Alexander Graf
@ 2012-07-06 16:52 ` Scott Wood
2012-07-06 16:59 ` Alexander Graf
0 siblings, 1 reply; 20+ messages in thread
From: Scott Wood @ 2012-07-06 16:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev
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;
>>>> +
>>>> + mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
>>>> + 0, 256, " OpenPIC ");
>>>
>>> Does that mean we're configuring the MPIC regardless of what the
>>> guest tells us? So the MPIC is a hard requirement. We can't use UIC
>>> or XPIC with this machine, right? This needs to be documented.
>>
>> Then what would we do if we want to add an ePAPR virtual PIC instead?
>> Or if something replaces MPIC on future FSL chips?
>
> Then we need a different compatible anyways, because we wouldn't be backwards compatible, no?
No, that's exactly what I'm trying to avoid. This notion of a toplevel
compatible that tells you everything you need to know about the machine
(even if Linux chooses to be device-tree-based for some arbitrary subset
of that information) is incompatible with a flexible virtual platform.
All this compatible is saying is "see the rest of the device tree".
How well Linux does so is a quality of implementation issue that can be
addressed as needed. The information about what sort of interrupt
controller you have is already in the device tree. The device tree is
the machine spec.
Another assumption this patch makes is that it doesn't need SWIOTLB. Is
"has more than 4GiB RAM" a machine attribute that would warrant a
separate toplevel compatible? SWIOTLB for PCI is handled due to the
previous patch that provides common PCI code -- but in a previous
version of the patch it was not handled. Is it yet another incompatible
machine spec if RAM must be less than 4GiB minus PCICSRBAR (ignoring the
QEMU bug that PCICSRBAR is not implemented)?
>> Better to change the Linux implementation as needed than to change a spec.
>
> Why not keep the 2 in sync in the same patch? Just throw a file with a rough outline of the machine in Documentation/.
Because that would give people the wrong impression about what this
machine is, and be unlikely to stay in sync or be a complete listing of
current assumptions. You're basically suggesting to use Documentation/
as a bug tracker.
-Scott
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-07-06 16:52 ` Scott Wood
@ 2012-07-06 16:59 ` Alexander Graf
2012-07-06 22:04 ` Scott Wood
0 siblings, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2012-07-06 16:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
On 06.07.2012, at 18:52, Scott Wood wrote:
> On 07/06/2012 11:30 AM, Alexander Graf wrote:
>>=20
>> On 06.07.2012, at 18:25, Scott Wood wrote:
>>=20
>>> On 07/06/2012 07:29 AM, Alexander Graf wrote:
>>>> I really think we should document what exactly this machine =
expects.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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?
>=20
> Well, it does have "e500" in the name. :-P
>=20
>>>>> +void __init qemu_e500_pic_init(void)
>>>>> +{
>>>>> + struct mpic *mpic;
>>>>> +
>>>>> + mpic =3D mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | =
MPIC_SINGLE_DEST_CPU,
>>>>> + 0, 256, " OpenPIC ");
>>>>=20
>>>> Does that mean we're configuring the MPIC regardless of what the
>>>> guest tells us? So the MPIC is a hard requirement. We can't use UIC
>>>> or XPIC with this machine, right? This needs to be documented.
>>>=20
>>> Then what would we do if we want to add an ePAPR virtual PIC =
instead?
>>> Or if something replaces MPIC on future FSL chips?
>>=20
>> Then we need a different compatible anyways, because we wouldn't be =
backwards compatible, no?
>=20
> No, that's exactly what I'm trying to avoid. This notion of a =
toplevel
> compatible that tells you everything you need to know about the =
machine
> (even if Linux chooses to be device-tree-based for some arbitrary =
subset
> of that information) is incompatible with a flexible virtual platform.
>=20
> All this compatible is saying is "see the rest of the device tree".
> How well Linux does so is a quality of implementation issue that can =
be
> addressed as needed. The information about what sort of interrupt
> controller you have is already in the device tree. The device tree is
> the machine spec.
>=20
> Another assumption this patch makes is that it doesn't need SWIOTLB. =
Is
> "has more than 4GiB RAM" a machine attribute that would warrant a
> separate toplevel compatible? SWIOTLB for PCI is handled due to the
> previous patch that provides common PCI code -- but in a previous
> version of the patch it was not handled. Is it yet another =
incompatible
> machine spec if RAM must be less than 4GiB minus PCICSRBAR (ignoring =
the
> QEMU bug that PCICSRBAR is not implemented)?
Well, the thing that I'm wary of is the following. Imagine we make this =
the default machine type for all e500 user cases. Which is reasonable. =
Now we release 3.6 which works awesome with QEMU 1.2. We change =
something in QEMU. QEMU 1.3 comes out. It can no longer boot your old =
kernel 3.6.
That's the type of situation I don't want to be in. We need to be =
backwards compatible with what we used to be able to run. We can get =
away with declaring things as experimental for now, until we settled on =
a reasonable compromise to achieve said compatibility. But it needs to =
be our goal somewhere.
One idea would be to version the machine type according to what Linux =
implements. If Linux finds a machine type that is newer than what it =
implements, it spawns a warning. If we want, we can implement backwards =
compatible machine types in QEMU, similar to how we implement -M pc-0.12 =
and friends today.
Again, no need to do so as long as we tell users to not use it. As soon =
as we want them to actually run the machine, we need to have independent =
upgrade paths in place. New QEMU needs to be able to run old kernels. =
New kernels need to be run on old QEMU.
>=20
>>> Better to change the Linux implementation as needed than to change a =
spec.
>>=20
>> Why not keep the 2 in sync in the same patch? Just throw a file with =
a rough outline of the machine in Documentation/.
>=20
> Because that would give people the wrong impression about what this
> machine is, and be unlikely to stay in sync or be a complete listing =
of
> current assumptions. You're basically suggesting to use =
Documentation/
> as a bug tracker.
I'm just saying that every time we hardcode assumptions, we need to make =
sure we document it somewhere. And currently we do hardcode assumptions, =
even though only a few.
Alex
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
2012-07-06 16:59 ` Alexander Graf
@ 2012-07-06 22:04 ` Scott Wood
0 siblings, 0 replies; 20+ messages in thread
From: Scott Wood @ 2012-07-06 22:04 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev
On 07/06/2012 11:59 AM, Alexander Graf wrote:
>
> 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:
>>>
>>>> Then what would we do if we want to add an ePAPR virtual PIC
>>>> instead? Or if something replaces MPIC on future FSL chips?
>>>
>>> Then we need a different compatible anyways, because we wouldn't
>>> be backwards compatible, no?
>>
>> No, that's exactly what I'm trying to avoid. This notion of a
>> toplevel compatible that tells you everything you need to know
>> about the machine (even if Linux chooses to be device-tree-based
>> for some arbitrary subset of that information) is incompatible with
>> a flexible virtual platform.
>>
>> All this compatible is saying is "see the rest of the device
>> tree". How well Linux does so is a quality of implementation issue
>> that can be addressed as needed. The information about what sort
>> of interrupt controller you have is already in the device tree.
>> The device tree is the machine spec.
>>
>> Another assumption this patch makes is that it doesn't need
>> SWIOTLB. Is "has more than 4GiB RAM" a machine attribute that
>> would warrant a separate toplevel compatible? SWIOTLB for PCI is
>> handled due to the previous patch that provides common PCI code --
>> but in a previous version of the patch it was not handled. Is it
>> yet another incompatible machine spec if RAM must be less than 4GiB
>> minus PCICSRBAR (ignoring the QEMU bug that PCICSRBAR is not
>> implemented)?
>
> Well, the thing that I'm wary of is the following. Imagine we make
> this the default machine type for all e500 user cases. Which is
> reasonable. Now we release 3.6 which works awesome with QEMU 1.2. We
> change something in QEMU. QEMU 1.3 comes out. It can no longer boot
> your old kernel 3.6.
Do you expect your old kernel to boot when you get new hardware? QEMU
is basically hardware that is easy to change.
The only thing that using a more specific compatible would do is make
sure that the kernel wouldn't boot whenever it changes, rather than just
having a chance of certain combinations having problems.
Obviously we should make a reasonable effort to avoid gratuitous
breakage in the default config, but I just don't see how overspecifying
things is going to help.
> That's the type of situation I don't want to be in. We need to be
> backwards compatible with what we used to be able to run. We can get
> away with declaring things as experimental for now, until we settled
> on a reasonable compromise to achieve said compatibility. But it
> needs to be our goal somewhere.
>
> One idea would be to version the machine type according to what Linux
> implements. If Linux finds a machine type that is newer than what it
> implements, it spawns a warning.
What does it mean to have a version number for a platform which is
intended to eventually be arbitrarily configurable?
> If we want, we can implement
> backwards compatible machine types in QEMU, similar to how we
> implement -M pc-0.12 and friends today.
Heh, I was just about to respond by saying "how would you version a PC"? :-)
If you want a stable versioned platform that happens to not pretend to
be a real board, go ahead and add one -- that's not what this is for.
Maybe instead of documenting things like "has an MPIC", there should be
some comment mentioning that this platform is intended to be flexible
and device tree driven, not static. The device tree is the machine
spec. I could see an argument for versioning individual devices, OTOH,
rather than e.g. pretending the PCI is really equivalent to an
mpc8540-pci despite significant missing functionality.
BTW, could you point me to the documentation that explains exactly what
a pc-0.12 is? And is there any place in Linux that actually sees this
version number and does anything with it? How would a user know what
version of a PC to request? What version do you get by default? Under
what conditions are the version number bumped?
> Again, no need to do so as long as we tell users to not use it. As
> soon as we want them to actually run the machine, we need to have
> independent upgrade paths in place. New QEMU needs to be able to run
> old kernels. New kernels need to be run on old QEMU.
They will, usually. We can't guarantee this will always be true
regardless of a versioning scheme, since bugs will happen.
>>>> Better to change the Linux implementation as needed than to
>>>> change a spec.
>>>
>>> Why not keep the 2 in sync in the same patch? Just throw a file
>>> with a rough outline of the machine in Documentation/.
>>
>> Because that would give people the wrong impression about what
>> this machine is, and be unlikely to stay in sync or be a complete
>> listing of current assumptions. You're basically suggesting to use
>> Documentation/ as a bug tracker.
>
> I'm just saying that every time we hardcode assumptions, we need to
> make sure we document it somewhere. And currently we do hardcode
> assumptions, even though only a few.
If you want a bug tracker, use a bug tracker. Linux already has plenty
of assumptions regarding the real hardware it runs on, how firmware
configures it, etc. Most of these assumptions are not documented, and
things get changed when new hardware comes along that breaks an
assumption. Most of the assumptions this platform would be making come
from outside the platform file itself. If I tried to document it, it
would be incomplete and quickly become out of date.
-Scott
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init
2012-06-27 23:48 [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Scott Wood
2012-06-27 23:50 ` [PATCH 1/3] powerpc/fsl-pci: provide common PCI init Scott Wood
2012-06-27 23:50 ` [PATCH 2/3] powerpc/e500: add paravirt QEMU platform Scott Wood
@ 2012-06-27 23:50 ` Scott Wood
2012-07-10 18:31 ` Kumar Gala
2012-06-28 4:06 ` [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Jia Hongtao-B38951
3 siblings, 1 reply; 20+ messages in thread
From: Scott Wood @ 2012-06-27 23:50 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, agraf, Jia Hongtao
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@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
@@ -114,71 +114,53 @@ 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);
+static struct device_node *pci_with_uli;
+
static int mpc85xx_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn)
{
- struct device_node* node;
- struct resource rsrc;
-
- node = hose->dn;
- of_address_to_resource(node, 0, &rsrc);
-
- if ((rsrc.start & 0xfffff) == primary_phb_addr) {
+ if (hose->dn == pci_with_uli)
return uli_exclude_device(hose, bus, devfn);
- }
return PCIBIOS_SUCCESSFUL;
}
#endif /* CONFIG_PCI */
-/*
- * Setup the architecture
- */
-static void __init mpc85xx_ds_setup_arch(void)
+static void __init mpc85xx_ds_pci_init(void)
{
#ifdef CONFIG_PCI
- struct device_node *np;
- struct pci_controller *hose;
-#endif
- dma_addr_t max = 0xffffffff;
+ struct device_node *node;
- if (ppc_md.progress)
- ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
+ fsl_pci_init();
-#ifdef CONFIG_PCI
- for_each_node_by_type(np, "pci") {
- if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
- of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
- of_device_is_compatible(np, "fsl,p2020-pcie")) {
- struct resource rsrc;
- of_address_to_resource(np, 0, &rsrc);
- if ((rsrc.start & 0xfffff) == primary_phb_addr)
- fsl_add_bridge(np, 1);
- else
- fsl_add_bridge(np, 0);
-
- hose = pci_find_hose_for_OF_device(np);
- max = min(max, hose->dma_window_base_cur +
- hose->dma_window_size);
+ /* See if we have a ULI under the primary */
+
+ node = of_find_node_by_name(NULL, "uli1575");
+ while ((pci_with_uli = of_get_parent(node))) {
+ of_node_put(node);
+ node = pci_with_uli;
+
+ if (pci_with_uli == fsl_pci_primary) {
+ ppc_md.pci_exclude_device = mpc85xx_exclude_device;
+ break;
}
}
-
- ppc_md.pci_exclude_device = mpc85xx_exclude_device;
#endif
+}
- mpc85xx_smp_init();
+/*
+ * Setup the architecture
+ */
+static void __init mpc85xx_ds_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
-#ifdef CONFIG_SWIOTLB
- if (memblock_end_of_DRAM() > max) {
- ppc_swiotlb_enable = 1;
- set_pci_dma_ops(&swiotlb_dma_ops);
- ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
- }
-#endif
+ mpc85xx_ds_pci_init();
+ mpc85xx_smp_init();
printk("MPC85xx DS board from Freescale Semiconductor\n");
}
@@ -190,14 +172,7 @@ static int __init mpc8544_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "MPC8544DS")) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0xb000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, "MPC8544DS");
}
machine_device_initcall(mpc8544_ds, mpc85xx_common_publish_devices);
@@ -215,14 +190,7 @@ static int __init mpc8572_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "fsl,MPC8572DS")) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0x8000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, "fsl,MPC8572DS");
}
/*
@@ -232,14 +200,7 @@ static int __init p2020_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "fsl,P2020DS")) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0x9000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, "fsl,P2020DS");
}
define_machine(mpc8544_ds) {
--
1.7.5.4
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init
2012-06-27 23:50 ` [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init Scott Wood
@ 2012-07-10 18:31 ` Kumar Gala
0 siblings, 0 replies; 20+ messages in thread
From: Kumar Gala @ 2012-07-10 18:31 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, agraf, Jia Hongtao
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.
>=20
> Signed-off-by: Scott Wood <scottwood@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).
>=20
> Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli).
>=20
> 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=
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-27 23:48 [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Scott Wood
` (2 preceding siblings ...)
2012-06-27 23:50 ` [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init Scott Wood
@ 2012-06-28 4:06 ` Jia Hongtao-B38951
2012-06-28 16:31 ` Scott Wood
3 siblings, 1 reply; 20+ messages in thread
From: Jia Hongtao-B38951 @ 2012-06-28 4:06 UTC (permalink / raw)
To: Wood Scott-B07421, galak, Li Yang-R58472; +Cc: linuxppc-dev, agraf
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, June 28, 2012 7:49 AM
> To: galak@kernel.crashing.org
> Cc: agraf@suse.de; linuxppc-dev@lists.ozlabs.org; Jia Hongtao-B38951
> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
>=20
> 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.
>=20
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 refactorin=
g
for pci init. But in linux mechanism PM ops should be registered to a drive=
r.
Do you have any ideas to add PM support for pci controllers under this patc=
hset?
Thanks.
-Jia Hongtao.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-28 4:06 ` [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform Jia Hongtao-B38951
@ 2012-06-28 16:31 ` Scott Wood
2012-06-29 2:36 ` Jia Hongtao-B38951
0 siblings, 1 reply; 20+ messages in thread
From: Scott Wood @ 2012-06-28 16:31 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, agraf, linuxppc-dev, Li Yang-R58472
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@kernel.crashing.org
>> Cc: agraf@suse.de; linuxppc-dev@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?
This isn't meant to be instead of making it a platform device. It's
just meant to get us away from board-specific code and primary-bus
hardcoding now, rather than once we sort out all the issues with
platform devices.
-Scott
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-28 16:31 ` Scott Wood
@ 2012-06-29 2:36 ` Jia Hongtao-B38951
2012-06-29 15:57 ` Kumar Gala
0 siblings, 1 reply; 20+ messages in thread
From: Jia Hongtao-B38951 @ 2012-06-29 2:36 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: agraf, linuxppc-dev, Li Yang-R58472
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBKdW5lIDI5LCAyMDEyIDEyOjMxIEFNDQo+IFRvOiBKaWEgSG9u
Z3Rhby1CMzg5NTENCj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBnYWxha0BrZXJuZWwuY3Jhc2hp
bmcub3JnOyBMaSBZYW5nLVI1ODQ3MjsNCj4gYWdyYWZAc3VzZS5kZTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAwLzNdIHBvd2VycGMvZnNsOiBQ
Q0kgcmVmYWN0b3JpbmcgYW5kIFFFTVUgcGFyYXZpcnQNCj4gcGxhdGZvcm0NCj4gDQo+IE9uIDA2
LzI3LzIwMTIgMTE6MDYgUE0sIEppYSBIb25ndGFvLUIzODk1MSB3cm90ZToNCj4gPg0KPiA+DQo+
ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFdvb2QgU2NvdHQtQjA3
NDIxDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI4LCAyMDEyIDc6NDkgQU0NCj4gPj4gVG86
IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmcNCj4gPj4gQ2M6IGFncmFmQHN1c2UuZGU7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBKaWEgSG9uZ3Rhby1CMzg5NTENCj4gPj4gU3ViamVj
dDogW1BBVENIIDAvM10gcG93ZXJwYy9mc2w6IFBDSSByZWZhY3RvcmluZyBhbmQgUUVNVSBwYXJh
dmlydA0KPiA+PiBwbGF0Zm9ybQ0KPiA+Pg0KPiA+PiBUaGUgUUVNVSBzdHVmZiBpcyByZWxhdGVk
IHRvIHRoZSBQQ0kgcmVmYWN0b3JpbmcgYmVjYXVzZSBjdXJyZW50bHkNCj4gPj4gd2UgaGF2ZSBh
IGhhcmQgdGltZSBzZWxlY3RpbmcgYSBwcmltYXJ5IGJ1cyB1bmRlciBRRU1VLCBhbmQgYWxzbw0K
PiBiZWNhdXNlDQo+ID4+IHRoZSBnZW5lcmljIHFlbXUgZTUwMCBwbGF0Zm9ybSB3YW50cyBhIGZ1
bGwgbGlzdCBvZiBGU0wgUENJDQo+IGNvbXBhdGlibGVzDQo+ID4+IHRvIGNoZWNrLg0KPiA+Pg0K
PiA+DQo+ID4gSXQgc2VlbXMgdGhhdCBub3QgYWxsIHByaW1hcnkgYnVzIGhhcyAiaXNhIiBub2Rl
IGxpa2UgODU0MSBhbmQgODU1NS4NCj4gDQo+IERvIHRob3NlIGJvYXJkcyAoaXQncyB0aGUgYm9h
cmRzIHRoYXQgbWF0dGVyLCBub3QgY2hpcHMuLi4pIGhhdmUgbGVnYWN5DQo+IElTQT8gIElmIHRo
ZXkgZG8sIGFuZCBpdCdzIG5vdCBpbiB0aGUgZGV2aWNlIHRyZWUsIHRoZW4gd2Ugc2hvdWxkIGZp
eA0KPiB0aGUgZGV2aWNlIHRyZWUgZm9yIGNvbnNpc3RlbmN5LCBidXQgYWxzbyByZXRhaW4gc29t
ZSBzb3J0IG9mIGhhY2sgdG8NCj4gcmVtYWluIGNvbXBhdGlibGUgd2l0aCBvbGQgZGV2aWNlIHRy
ZWVzLg0KPiANCj4gQSBib2FyZCBjYW4gcmVmcmFpbiBmcm9tIHVzaW5nIHRoZSBuZXcgY29tbW9u
IGluZnJhc3RydWN0dXJlIGlmIGl0IGhhcyBhDQo+IGdvb2QgcmVhc29uIHRvLg0KDQpJJ20gbm90
IHN1cmUgdGhhdCBNUEM4NTQxQ0RTIChvciA4NTU1KSBoYXMgbGVnYWN5IElTQS4gSSBqdXN0IGNo
ZWNrZWQgaW4NCmtlcm5lbCBhbmQgZHRzIHdoaWNoIGltcGxpZXMgdGhlIGJvYXJkIGhhcyBwcmlt
YXJ5IGJ1cyBhbmQgbm8gImlzYSIgbm9kZS4NCkkgd2lsbCBmaW5kIG91dCB0aGUgZmFjdHMgbGF0
ZXIuDQoNCg0KPiANCj4gPiBXaXRob3V0IFBNIHN1cHBvcnQgZm9yIHBjaSBjb250cm9sbGVycyBJ
IHRvdGFsbHkgYWdyZWUgd2l0aCB0aGlzDQo+IHJlZmFjdG9yaW5nDQo+ID4gZm9yIHBjaSBpbml0
LiBCdXQgaW4gbGludXggbWVjaGFuaXNtIFBNIG9wcyBzaG91bGQgYmUgcmVnaXN0ZXJlZCB0byBh
DQo+IGRyaXZlci4NCj4gPiBEbyB5b3UgaGF2ZSBhbnkgaWRlYXMgdG8gYWRkIFBNIHN1cHBvcnQg
Zm9yIHBjaSBjb250cm9sbGVycyB1bmRlciB0aGlzDQo+IHBhdGNoc2V0Pw0KPiANCj4gVGhpcyBp
c24ndCBtZWFudCB0byBiZSBpbnN0ZWFkIG9mIG1ha2luZyBpdCBhIHBsYXRmb3JtIGRldmljZS4g
IEl0J3MNCj4ganVzdCBtZWFudCB0byBnZXQgdXMgYXdheSBmcm9tIGJvYXJkLXNwZWNpZmljIGNv
ZGUgYW5kIHByaW1hcnktYnVzDQo+IGhhcmRjb2Rpbmcgbm93LCByYXRoZXIgdGhhbiBvbmNlIHdl
IHNvcnQgb3V0IGFsbCB0aGUgaXNzdWVzIHdpdGgNCj4gcGxhdGZvcm0gZGV2aWNlcy4NCj4gDQo+
IC1TY290dA0KDQpUaGFua3MsIEknbGwgbG9vayBpbnRvIHRoZSBpc3N1ZXMuDQoNCi1KaWEgSG9u
Z3Rhby4NCg==
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-29 2:36 ` Jia Hongtao-B38951
@ 2012-06-29 15:57 ` Kumar Gala
2012-06-29 16:01 ` Scott Wood
2012-06-29 16:06 ` Zang Roy-R61911
0 siblings, 2 replies; 20+ messages in thread
From: Kumar Gala @ 2012-06-29 15:57 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472, agraf
On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Friday, June 29, 2012 12:31 AM
>> To: Jia Hongtao-B38951
>> Cc: Wood Scott-B07421; galak@kernel.crashing.org; Li Yang-R58472;
>> agraf@suse.de; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU =
paravirt
>> platform
>>=20
>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>> To: galak@kernel.crashing.org
>>>> Cc: agraf@suse.de; linuxppc-dev@lists.ozlabs.org; Jia =
Hongtao-B38951
>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
>>>> platform
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> It seems that not all primary bus has "isa" node like 8541 and 8555.
>>=20
>> 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.
>>=20
>> A board can refrain from using the new common infrastructure if it =
has a
>> good reason to.
>=20
> I'm not sure that MPC8541CDS (or 8555) has legacy ISA. I just checked =
in
> kernel and dts which implies the board has primary bus and no "isa" =
node.
> I will find out the facts later.
Pretty sure the boards have ISA, if you see the .dts has references to =
'ISA bridge' & 'i8259' PIC.
- k
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-29 15:57 ` Kumar Gala
@ 2012-06-29 16:01 ` Scott Wood
2012-06-29 16:04 ` Kumar Gala
2012-06-29 16:18 ` Li Yang-R58472
2012-06-29 16:06 ` Zang Roy-R61911
1 sibling, 2 replies; 20+ messages in thread
From: Scott Wood @ 2012-06-29 16:01 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, agraf, linuxppc-dev, Li Yang-R58472,
Jia Hongtao-B38951
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@kernel.crashing.org; Li Yang-R58472;
>>> agraf@suse.de; linuxppc-dev@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@kernel.crashing.org
>>>>> Cc: agraf@suse.de; linuxppc-dev@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.
>>
>> I'm not sure that MPC8541CDS (or 8555) has legacy ISA. I just checked in
>> kernel and dts which implies the board has primary bus and no "isa" node.
>> I will find out the facts later.
>
> 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?
-Scott
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-29 16:01 ` Scott Wood
@ 2012-06-29 16:04 ` Kumar Gala
2012-06-29 16:18 ` Li Yang-R58472
1 sibling, 0 replies; 20+ messages in thread
From: Kumar Gala @ 2012-06-29 16:04 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, agraf, linuxppc-dev, Li Yang-R58472,
Jia Hongtao-B38951
On Jun 29, 2012, at 11:01 AM, Scott Wood wrote:
> On 06/29/2012 10:57 AM, Kumar Gala wrote:
>>=20
>> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Friday, June 29, 2012 12:31 AM
>>>> To: Jia Hongtao-B38951
>>>> Cc: Wood Scott-B07421; galak@kernel.crashing.org; Li Yang-R58472;
>>>> agraf@suse.de; linuxppc-dev@lists.ozlabs.org
>>>> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU =
paravirt
>>>> platform
>>>>=20
>>>> On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote:
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Wood Scott-B07421
>>>>>> Sent: Thursday, June 28, 2012 7:49 AM
>>>>>> To: galak@kernel.crashing.org
>>>>>> Cc: agraf@suse.de; linuxppc-dev@lists.ozlabs.org; Jia =
Hongtao-B38951
>>>>>> Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU =
paravirt
>>>>>> platform
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>=20
>>>>> It seems that not all primary bus has "isa" node like 8541 and =
8555.
>>>>=20
>>>> 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.
>>>>=20
>>>> A board can refrain from using the new common infrastructure if it =
has a
>>>> good reason to.
>>>=20
>>> I'm not sure that MPC8541CDS (or 8555) has legacy ISA. I just =
checked in
>>> kernel and dts which implies the board has primary bus and no "isa" =
node.
>>> I will find out the facts later.
>>=20
>> Pretty sure the boards have ISA, if you see the .dts has references =
to 'ISA bridge' & 'i8259' PIC.
>=20
> OK. How about looking for an i8259 node as well?
>=20
> -Scott
Works for me, saves us having to waste time on figuring out how to =
update .dts for the boards.
- k
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-29 16:01 ` Scott Wood
2012-06-29 16:04 ` Kumar Gala
@ 2012-06-29 16:18 ` Li Yang-R58472
2012-06-29 16:59 ` Scott Wood
1 sibling, 1 reply; 20+ messages in thread
From: Li Yang-R58472 @ 2012-06-29 16:18 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala; +Cc: linuxppc-dev, agraf, Jia Hongtao-B38951
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBKdW5lIDI5LCAyMDEyIDExOjAyIEFNDQo+IFRvOiBLdW1hciBH
YWxhDQo+IENjOiBKaWEgSG9uZ3Rhby1CMzg5NTE7IFdvb2QgU2NvdHQtQjA3NDIxOyBMaSBZYW5n
LVI1ODQ3MjsgYWdyYWZAc3VzZS5kZTsNCj4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCAwLzNdIHBvd2VycGMvZnNsOiBQQ0kgcmVmYWN0b3Jpbmcg
YW5kIFFFTVUgcGFyYXZpcnQNCj4gcGxhdGZvcm0NCj4gDQo+IE9uIDA2LzI5LzIwMTIgMTA6NTcg
QU0sIEt1bWFyIEdhbGEgd3JvdGU6DQo+ID4NCj4gPiBPbiBKdW4gMjgsIDIwMTIsIGF0IDk6MzYg
UE0sIEppYSBIb25ndGFvLUIzODk1MSB3cm90ZToNCj4gPg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+
ID4+PiBTZW50OiBGcmlkYXksIEp1bmUgMjksIDIwMTIgMTI6MzEgQU0NCj4gPj4+IFRvOiBKaWEg
SG9uZ3Rhby1CMzg5NTENCj4gPj4+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgZ2FsYWtAa2VybmVs
LmNyYXNoaW5nLm9yZzsgTGkgWWFuZy1SNTg0NzI7DQo+ID4+PiBhZ3JhZkBzdXNlLmRlOyBsaW51
eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+Pj4gU3ViamVjdDogUmU6IFtQQVRDSCAwLzNd
IHBvd2VycGMvZnNsOiBQQ0kgcmVmYWN0b3JpbmcgYW5kIFFFTVUNCj4gPj4+IHBhcmF2aXJ0IHBs
YXRmb3JtDQo+ID4+Pg0KPiA+Pj4gT24gMDYvMjcvMjAxMiAxMTowNiBQTSwgSmlhIEhvbmd0YW8t
QjM4OTUxIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gPj4+Pj4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPj4+Pj4gU2VudDog
VGh1cnNkYXksIEp1bmUgMjgsIDIwMTIgNzo0OSBBTQ0KPiA+Pj4+PiBUbzogZ2FsYWtAa2VybmVs
LmNyYXNoaW5nLm9yZw0KPiA+Pj4+PiBDYzogYWdyYWZAc3VzZS5kZTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmc7IEppYQ0KPiA+Pj4+PiBIb25ndGFvLUIzODk1MQ0KPiA+Pj4+PiBTdWJq
ZWN0OiBbUEFUQ0ggMC8zXSBwb3dlcnBjL2ZzbDogUENJIHJlZmFjdG9yaW5nIGFuZCBRRU1VDQo+
ID4+Pj4+IHBhcmF2aXJ0IHBsYXRmb3JtDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBRRU1VIHN0dWZm
IGlzIHJlbGF0ZWQgdG8gdGhlIFBDSSByZWZhY3RvcmluZyBiZWNhdXNlIGN1cnJlbnRseQ0KPiA+
Pj4+PiB3ZSBoYXZlIGEgaGFyZCB0aW1lIHNlbGVjdGluZyBhIHByaW1hcnkgYnVzIHVuZGVyIFFF
TVUsIGFuZCBhbHNvDQo+ID4+PiBiZWNhdXNlDQo+ID4+Pj4+IHRoZSBnZW5lcmljIHFlbXUgZTUw
MCBwbGF0Zm9ybSB3YW50cyBhIGZ1bGwgbGlzdCBvZiBGU0wgUENJDQo+ID4+PiBjb21wYXRpYmxl
cw0KPiA+Pj4+PiB0byBjaGVjay4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEl0IHNlZW1zIHRo
YXQgbm90IGFsbCBwcmltYXJ5IGJ1cyBoYXMgImlzYSIgbm9kZSBsaWtlIDg1NDEgYW5kIDg1NTUu
DQo+ID4+Pg0KPiA+Pj4gRG8gdGhvc2UgYm9hcmRzIChpdCdzIHRoZSBib2FyZHMgdGhhdCBtYXR0
ZXIsIG5vdCBjaGlwcy4uLikgaGF2ZQ0KPiA+Pj4gbGVnYWN5IElTQT8gIElmIHRoZXkgZG8sIGFu
ZCBpdCdzIG5vdCBpbiB0aGUgZGV2aWNlIHRyZWUsIHRoZW4gd2UNCj4gPj4+IHNob3VsZCBmaXgg
dGhlIGRldmljZSB0cmVlIGZvciBjb25zaXN0ZW5jeSwgYnV0IGFsc28gcmV0YWluIHNvbWUNCj4g
Pj4+IHNvcnQgb2YgaGFjayB0byByZW1haW4gY29tcGF0aWJsZSB3aXRoIG9sZCBkZXZpY2UgdHJl
ZXMuDQo+ID4+Pg0KPiA+Pj4gQSBib2FyZCBjYW4gcmVmcmFpbiBmcm9tIHVzaW5nIHRoZSBuZXcg
Y29tbW9uIGluZnJhc3RydWN0dXJlIGlmIGl0DQo+ID4+PiBoYXMgYSBnb29kIHJlYXNvbiB0by4N
Cj4gPj4NCj4gPj4gSSdtIG5vdCBzdXJlIHRoYXQgTVBDODU0MUNEUyAob3IgODU1NSkgaGFzIGxl
Z2FjeSBJU0EuIEkganVzdCBjaGVja2VkDQo+ID4+IGluIGtlcm5lbCBhbmQgZHRzIHdoaWNoIGlt
cGxpZXMgdGhlIGJvYXJkIGhhcyBwcmltYXJ5IGJ1cyBhbmQgbm8gImlzYSINCj4gbm9kZS4NCj4g
Pj4gSSB3aWxsIGZpbmQgb3V0IHRoZSBmYWN0cyBsYXRlci4NCj4gPg0KPiA+IFByZXR0eSBzdXJl
IHRoZSBib2FyZHMgaGF2ZSBJU0EsIGlmIHlvdSBzZWUgdGhlIC5kdHMgaGFzIHJlZmVyZW5jZXMg
dG8NCj4gJ0lTQSBicmlkZ2UnICYgJ2k4MjU5JyBQSUMuDQo+IA0KPiBPSy4gIEhvdyBhYm91dCBs
b29raW5nIGZvciBhbiBpODI1OSBub2RlIGFzIHdlbGw/DQoNClRoYXQgY291bGQgd29yaywgYnV0
IGxvb2tzIGhhY2tpc2guICBPdXIgcHJvcG9zYWwgZm9yIGFkZGluZyBhIG5ldyBkZXZpY2UgdHJl
ZSBwcm9wZXJ0eSBpcyBhIGdlbmVyaWMgc29sdXRpb24uICBUaGUgb25seSBwcm9ibGVtIGlzIHRo
YXQgbmV3IGtlcm5lbHMgd291bGQgd29yayB3aXRoIG9sZCBkZXZpY2UgdHJlZXMuICBJIHRoaW5r
IHdlIGNhbiB1c2UgeW91ciBzb2x1dGlvbiBmb3IgdHJhbnNpdGlvbmFsIHBlcmlvZC4gIEFuZCBn
byBmb3IgYSB3ZWxsIGRlZmluZWQgZGV2aWNlIHRyZWUgYmluZGluZyBmb3IgdGhpcyBpbiBsb25n
IHJ1bi4NCg0KLSBMZW8NCg==
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-29 16:18 ` Li Yang-R58472
@ 2012-06-29 16:59 ` Scott Wood
0 siblings, 0 replies; 20+ messages in thread
From: Scott Wood @ 2012-06-29 16:59 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: Wood Scott-B07421, agraf, linuxppc-dev, Jia Hongtao-B38951
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@suse.de;
>> linuxppc-dev@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.
-Scott
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
2012-06-29 15:57 ` Kumar Gala
2012-06-29 16:01 ` Scott Wood
@ 2012-06-29 16:06 ` Zang Roy-R61911
1 sibling, 0 replies; 20+ messages in thread
From: Zang Roy-R61911 @ 2012-06-29 16:06 UTC (permalink / raw)
To: Kumar Gala, Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev, Li Yang-R58472, agraf
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@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@lists.ozlabs.org; Li Yang-R58472;
> agraf@suse.de
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> platform
>=20
>=20
> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Friday, June 29, 2012 12:31 AM
> >> To: Jia Hongtao-B38951
> >> Cc: Wood Scott-B07421; galak@kernel.crashing.org; Li Yang-R58472;
> >> agraf@suse.de; linuxppc-dev@lists.ozlabs.org
> >> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravir=
t
> >> 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@kernel.crashing.org
> >>>> Cc: agraf@suse.de; linuxppc-dev@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 legac=
y
> >> 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.
> >
> > I'm not sure that MPC8541CDS (or 8555) has legacy ISA. I just checked i=
n
> > kernel and dts which implies the board has primary bus and no "isa" nod=
e.
> > I will find out the facts later.
>=20
> Pretty sure the boards have ISA, if you see the .dts has references to 'I=
SA
> bridge' & 'i8259' PIC.
It is on the VIA south bridge.
Roy
^ permalink raw reply [flat|nested] 20+ messages in thread