* [PATCH 4/8] Float the PCi bus number assignments on MPC8641HPCN board.
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Zhang Wei <wei.zhang@freescale.com>
Admittedly this is a non-ideal solution, but fixing it
properly might require systemic PCI bus renumbering
changes that we are not prepared to do yet.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 +
arch/powerpc/platforms/86xx/pci.c | 12 ++++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 1051702..9259788 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -363,6 +363,7 @@ mpc86xx_hpcn_setup_arch(void)
}
#ifdef CONFIG_PCI
+ pci_assign_all_buses = 1;
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
add_bridge(np);
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 07ff52c..c80d8f1 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -136,6 +136,18 @@ mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
int mpc86xx_exclude_device(u_char bus, u_char devfn)
{
+ struct pci_controller *hose;
+
+ hose = pci_bus_to_hose(bus);
+ if (unlikely(!hose))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ /* Correcting the hose->bus_offset value. */
+ out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
+ - hose->bus_offset) << 16));
+ if (unlikely(in_le32(hose->cfg_data) == 0xffffffff))
+ hose->bus_offset = hose->bus_offset ? 0 : hose->first_busno;
+
return PCIBIOS_SUCCESSFUL;
}
--
1.5.0.3
^ permalink raw reply related
* [PATCH 5/8] Set IDE in ULI1575 to not native mode.
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Zhang Wei <wei.zhang@freescale.com>
Set IDE in ULI1575 to not 100% native mode, which forces
the IDE driver to probe the irq itself.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 9259788..a82da4b 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -319,6 +319,7 @@ static void __devinit quirk_uli5229(struct pci_dev *dev)
{
unsigned short temp;
pci_write_config_word(dev, 0x04, 0x0405);
+ dev->class &= ~0x5;
pci_read_config_word(dev, 0x4a, &temp);
temp |= 0x1000;
pci_write_config_word(dev, 0x4a, temp);
--
1.5.0.3
^ permalink raw reply related
* [PATCH 6/8] Let subordinate transparent bridges be transparent.
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In pcibios_fixup_bus(), bridges that are subordinate
to transparent bridges were still relocating their
IORESOURCE_IO start and end values.
Fix this by preventing the transparent bridge from
relocating the start and end values, thus allowing the
subordinate non-transparent bridge full molestation rights.
Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/pci_32.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index e66064b..102264c 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -1372,7 +1372,9 @@ void __init pcibios_fixup_bus(struct pci_bus *bus)
continue;
if (!res->flags)
continue;
- if (io_offset && (res->flags & IORESOURCE_IO)) {
+ if (!bus->self->transparent
+ && io_offset
+ && (res->flags & IORESOURCE_IO)) {
res->start += io_offset;
res->end += io_offset;
} else if (hose->pci_mem_offset
--
1.5.0.3
^ permalink raw reply related
* [PATCH 7/8] Export of_bus_pci_get_flags().
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
It will be needed by the following patch.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/prom_parse.c | 2 +-
include/asm-powerpc/prom.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..754926f 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -153,7 +153,7 @@ static int of_bus_pci_translate(u32 *addr, u64 offset, int na)
return of_bus_default_translate(addr + 1, offset, na - 1);
}
-static unsigned int of_bus_pci_get_flags(const u32 *addr)
+unsigned int of_bus_pci_get_flags(const u32 *addr)
{
unsigned int flags = 0;
u32 w = addr[0];
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 6845af9..0168373 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -185,6 +185,7 @@ extern int pci_device_from_OF_node(struct device_node *node,
extern struct device_node* pci_busdev_to_OF_node(struct pci_bus *, int);
extern struct device_node* pci_device_to_OF_node(struct pci_dev *);
extern void pci_create_OF_bus_map(void);
+extern unsigned int of_bus_pci_get_flags(const u32 *addr);
#endif
extern struct resource *request_OF_resource(struct device_node* node,
--
1.5.0.3
^ permalink raw reply related
* [PATCH 8/8] Wrote quirk_mpc8641_transparent() to initialize bridge resources.
From: Jon Loeliger @ 2007-06-01 17:49 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
The 8641 RC poses as a transparent bridge, but does not implement the
IO_BASE or IO_LIMIT registers in the config space. This means that
the code which initializes the bridge resources ends up setting the
IO resources erroneously.
This change sets RC of mpc8641 to be a transparent bridge
for legacy I/O access and initializes the RC bridge resources
from the device tree.
Note: The 0x7010 is the device ID of host bridge for MPC8641
and 0x7011 is the device ID of host bridge fro MPC8641D.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
This patch combines the original function from Zheng Wei
and my followup rewrite of it to include resource allocation
as per list comments.
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 66 ++++++++++++++++++++++++++++
1 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index a82da4b..94e3c50 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -318,6 +318,7 @@ static void __devinit quirk_uli5288(struct pci_dev *dev)
static void __devinit quirk_uli5229(struct pci_dev *dev)
{
unsigned short temp;
+
pci_write_config_word(dev, 0x04, 0x0405);
dev->class &= ~0x5;
pci_read_config_word(dev, 0x4a, &temp);
@@ -325,6 +326,69 @@ static void __devinit quirk_uli5229(struct pci_dev *dev)
pci_write_config_word(dev, 0x4a, temp);
}
+#define GET_64BIT(prop, i) ((((u64) (prop)[(i)]) << 32) | (prop)[(i)+1])
+
+static void __devinit quirk_mpc8641_transparent(struct pci_dev *dev)
+{
+ const u32 *ranges;
+ struct resource *res;
+ int len;
+ int i;
+ unsigned int flags;
+ u64 size;
+ struct device_node *node;
+ struct pci_controller *hose;
+
+ /*
+ * Make the bridge be transparent.
+ */
+ dev->transparent = 1;
+
+ /*
+ * parse ranges property
+ * Ensure IO resource is placed in the PCI_BRIDGE_RESOURCES entry.
+ * PCI #address-cells == 3 and #size-cells == 2 always
+ */
+ node = pci_device_to_OF_node(dev);
+
+ hose = pci_bus_to_hose(dev->bus->number);
+ node = hose->arch_data;
+
+ ranges = of_get_property(node, "ranges", &len);
+ if (ranges == NULL) {
+ printk(KERN_DEBUG "Can't get ranges for PCI-PCI bridge %s\n",
+ node->full_name);
+ return;
+ }
+
+ i = PCI_BRIDGE_RESOURCES + 1;
+ for (; len >= 24; len -= 24, ranges += 6) {
+ flags = of_bus_pci_get_flags(&ranges[0]);
+ size = GET_64BIT(ranges, 4);
+ if (flags == 0 || size == 0)
+ continue;
+ if (flags & IORESOURCE_IO) {
+ res = &dev->resource[PCI_BRIDGE_RESOURCES];
+ if (res->flags) {
+ printk(KERN_ERR "PCI: ignoring extra I/O range"
+ " for bridge %s\n", node->full_name);
+ continue;
+ }
+ } else {
+ if (i >= PCI_NUM_RESOURCES) {
+ printk(KERN_ERR "PCI: too many memory ranges"
+ " for bridge %s\n", node->full_name);
+ continue;
+ }
+ res = &dev->resource[i];
+ ++i;
+ }
+ res->start = GET_64BIT(ranges, 1);
+ res->end = res->start + size - 1;
+ res->flags = flags;
+ }
+}
+
static void __devinit early_uli5249(struct pci_dev *dev)
{
unsigned char temp;
@@ -339,6 +403,8 @@ static void __devinit early_uli5249(struct pci_dev *dev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, quirk_uli1575);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5288, quirk_uli5288);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, quirk_uli5229);
+DECLARE_PCI_FIXUP_EARLY(0x1957, 0x7010, quirk_mpc8641_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, 0x7011, quirk_mpc8641_transparent);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
#endif /* CONFIG_PCI */
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-01 18:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180720112.14219.62.camel@ld0161-tx32>
> + ranges = <00000000 f8000000 00100000
> + 80000000 80000000 20000000
> + e2000000 e2000000 00100000
> + a0000000 a0000000 20000000
> + e3000000 e3000000 00100000>;
> reg = <f8000000 00100000>; // CCSRBAR 1M
"reg" included in "ranges"? Something is wrong here.
> + pci_bridge@0 {
> + #size-cells = <2>;
> + #address-cells = <3>;
> + ranges = <02000000 0 80000000
> + 02000000 0 80000000
> + 0 20000000
> + 01000000 0 00000000
> + 01000000 0 00000000
> + 0 00100000>;
> +
> + isa@1e {
> + #size-cells = <1>;
> + #address-cells = <2>;
>
> + ranges = <1 0 01000000 0 0
> + 00001000>;
You map the same range (4kB legacy I/O @ 0) for both
bridges here.
> + i8042@60 {
> + reg = <1 60 1 1 64 1>;
And this address space is included in both of those.
> + keyboard@0 {
> + compatible = "pnpPNP,303";
> + };
> +
> + mouse@1 {
> + compatible = "pnpPNP,f03";
> + };
These need a "reg" property.
> + rtc@70 {
> + compatible =
> + "pnpPNP,b00";
> + reg = <1 70 2>;
> + };
> +
> + gpio@400 {
> + reg = <1 400 80>;
> + };
Inclusive again.
> + i8259: i8259@4d0 {
Needs "reg". And 4d0 isn't the primary address
I think?
Segher
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Kumar Gala @ 2007-06-01 19:58 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: Paul Mackerras, linuxppc-dev list
In-Reply-To: <46B96294322F7D458F9648B60E15112C30780F@zch01exm26.fsl.freescale.net>
On Jun 1, 2007, at 1:45 AM, Zhang Wei-r63237 wrote:
> Hi, Paul,
>
>> -----Original Message-----
>> From: Paul Mackerras [mailto:paulus@samba.org]
>>
>> Kumar Gala writes:
>>
>>>> That's my original doing. If there a PCI bridge card be
>> pluged into
>>>> PCI
>>>> slot of hose0, I can not ensue the bus_offset number of hose1.
>>>
>>> Ok, but can't we use hose0's last_busno and use that set hose1-
>>>> first_busno & hose1->bus_offset?
>>
>> Why do the bus numbers for hose0 and hose1 have to have any relation
>> to each other at all? Aren't they separate PCI domains?
>
> There are lots of lagacy PCI codes in kernel, such as
> pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
> pci_bus_to_hose() can not return the correct hose. And there will
> effect
> /proc/pci and lspci tools.
So looking at the code it looks like pci_assign_all_buses should
handle numbering the busses properly when we scan the busses, so
what's the issue that causes that not to be correct?
- k
^ permalink raw reply
* Re: [patch] powerpc: Remove redundant pci_read_irq_line() function for 85xx platform
From: Andy Fleming @ 2007-06-01 20:06 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1180685138.17196.55.camel@localhost.localdomain>
On Jun 1, 2007, at 03:05, Zang Roy-r61911 wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Remove redundant pci_read_irq_line() function for
> 85xx CDS board.
> This function has been realized in common pci_32.c.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
^ permalink raw reply
* RE: Audio Dirver for the 403/405?
From: bert_maxel @ 2007-06-01 20:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070531193717.5743A1A48046@mail177-sin.bigfish.com>
Thanks for your input.
Can you send me the dsp driver that goes with opb_ac97?
That'll be a good start for me, I appreciate your help.
thank you Steve
bert
Stephen Neuendorffer wrote:
>
>
> There is an opb core developed for the Xilinx University Program board,
> which
> has a similar hardware interface to the ML403 (i.e. no PCI bridge)
> The XUPV2P web page with the opb_ac97 core is here:
> http://www.xilinx.com/univ/xupv2p.html
>
> I have a /dev/dsp driver (which I'll send to Bert directly) which limps
> along in 2.6.
> This core has a relatively small buffer and no master access to memory,
> which
> results in relatively poor performance, but it is a starting point.
>
> Steve
>
>> -----Original Message-----
>> From:
>> linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
>>
>> [mailto:linuxppc-embedded-bounces+stephen=neuendorffer.name@oz
> labs.org] On Behalf Of bert_maxel
>> Sent: Thursday, May 31, 2007 12:10 PM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: Re: Audio Dirver for the 403/405?
>>
>>
>>
>>
>> Grant Likely-2 wrote:
>> >
>> > On 5/30/07, bert_maxel <bonlutin@hotmail.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Has anybody got some working audio driver (linux) for the
>> ML403/405 ?
>> >> I know it's an ac97 codec, but I can't find anything
>> related to the
>> >> xilinx boards?
>> >> If nobody has worked on this yet, I'm in trouble. I don't
>> know where
>> >> to start, or from what ac97 driver should I base my
>> initial development?
>> >
>> > IIRC, the old mvista 2.4 tree has an audio driver.
>> >
>> > g.
>> >
>> > --
>> > Grant Likely, B.Sc., P.Eng.
>> > Secret Lab Technologies Ltd.
>> > grant.likely@secretlab.ca
>> > (403) 399-0195
>> > _______________________________________________
>> > Linuxppc-embedded mailing list
>> > Linuxppc-embedded@ozlabs.org
>> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> >
>> >
>>
>> There are plenty of boards with an ac97 codec, but what's
>> missing is the glue for the ML403 board, there's no pci bus
>> in this case, opb cores instead.
>> I hope somebody can point me to a link of interest.
>>
>> thanks
>> --
>> View this message in context:
>> http://www.nabble.com/Audio-Dirver-for-the-403-405--tf3843165.
> html#a10900170
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Audio-Dirver-for-the-403-405--tf3843165.html#a10920136
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 2.6.22-rc3-mm1
From: Mariusz Kozlowski @ 2007-06-01 20:50 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, paulus, Arnd Bergmann, Nick Piggin, linux-kernel
In-Reply-To: <20070531141943.5c4d587c.akpm@linux-foundation.org>
> > This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> > in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> > the patch to blame hmm.
> >
> > arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
> > arch/powerpc/platforms/cell/spufs/file.c:122: error: 'address' undeclared (first use in this function)
> > arch/powerpc/platforms/cell/spufs/file.c:122: error: (Each undeclared identifier is reported only once
> > arch/powerpc/platforms/cell/spufs/file.c:122: error: for each function it appears in.)
> > arch/powerpc/platforms/cell/spufs/file.c:141: error: expected ';' before 'if'
> > arch/powerpc/platforms/cell/spufs/file.c:122: warning: unused variable 'addr0'
> > make[3]: *** [arch/powerpc/platforms/cell/spufs/file.o] Blad 1
> > make[2]: *** [arch/powerpc/platforms/cell/spufs] Blad 2
> > make[1]: *** [arch/powerpc/platforms/cell] Blad 2
> >
>
> Yeah, that's the fix-fault-vs-invalidate-race patches, or my poor attempt
> to fix them when spufs changed. I suppose I'll have a poke at it next time
> I get the powerpc machine fired up.
I #if 0'ed that piece of code inside spufs_mem_mmap_fault() and run make again.
This is 'make allmodconfig && make' result:
ERROR: ".ps3av_set_hdr" [drivers/ps3/ps3av_cmd.ko] undefined!
ERROR: ".ps3av_do_pkt" [drivers/ps3/ps3av_cmd.ko] undefined!
ERROR: ".ps3_vuart_write" [drivers/ps3/ps3av_cmd.ko] undefined!
ERROR: ".ps3_vuart_read" [drivers/ps3/ps3av_cmd.ko] undefined!
ERROR: ".ps3av_cmd_fin" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_av_video_disable_sig" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_set_video_mode" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_video_get_monitor_info" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_audio_active" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_set_audio_mode" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_set_av_audio_param" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_vuart_read" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_av_get_hw_conf" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_av_video_mute" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_av_tv_mute" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_audio_mode" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_av_hdmi_mode" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_set_av_video_cs" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_vuart_write" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_audio_mute" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_avb_param" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_init" [drivers/ps3/ps3av.ko] undefined!
ERROR: ".ps3av_cmd_av_audio_mute" [drivers/ps3/ps3av.ko] undefined!
ERROR: "pmu_batteries" [drivers/power/pmu_battery.ko] undefined!
ERROR: "pmu_battery_count" [drivers/power/pmu_battery.ko] undefined!
ERROR: "pmu_power_flags" [drivers/power/pmu_battery.ko] undefined!
ERROR: "irq_map" [drivers/net/pasemi_mac.ko] undefined!
ERROR: "pmu_batteries" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: "pmu_battery_count" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: "pmu_power_flags" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: ".cpufreq_set_policy" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined!
make[1]: *** [__modpost] Blad 1
make: *** [modules] Blad 2
Regards,
Mariusz
^ permalink raw reply
* Re: 2.6.22-rc3-mm1
From: Andrew Morton @ 2007-06-01 21:02 UTC (permalink / raw)
To: Mariusz Kozlowski
Cc: linuxppc-dev, paulus, Arnd Bergmann, Nick Piggin, linux-kernel
In-Reply-To: <200706012250.58962.m.kozlowski@tuxland.pl>
On Fri, 1 Jun 2007 22:50:58 +0200
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> > > This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> > > in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> > > the patch to blame hmm.
> > >
> > > arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
> > > arch/powerpc/platforms/cell/spufs/file.c:122: error: 'address' undeclared (first use in this function)
> > > arch/powerpc/platforms/cell/spufs/file.c:122: error: (Each undeclared identifier is reported only once
> > > arch/powerpc/platforms/cell/spufs/file.c:122: error: for each function it appears in.)
> > > arch/powerpc/platforms/cell/spufs/file.c:141: error: expected ';' before 'if'
> > > arch/powerpc/platforms/cell/spufs/file.c:122: warning: unused variable 'addr0'
> > > make[3]: *** [arch/powerpc/platforms/cell/spufs/file.o] Blad 1
> > > make[2]: *** [arch/powerpc/platforms/cell/spufs] Blad 2
> > > make[1]: *** [arch/powerpc/platforms/cell] Blad 2
> > >
> >
> > Yeah, that's the fix-fault-vs-invalidate-race patches, or my poor attempt
> > to fix them when spufs changed. I suppose I'll have a poke at it next time
> > I get the powerpc machine fired up.
>
> I #if 0'ed that piece of code inside spufs_mem_mmap_fault() and run make again.
> This is 'make allmodconfig && make' result:
>
> ERROR: ".ps3av_set_hdr" [drivers/ps3/ps3av_cmd.ko] undefined!
> ERROR: ".ps3av_do_pkt" [drivers/ps3/ps3av_cmd.ko] undefined!
> ERROR: ".ps3_vuart_write" [drivers/ps3/ps3av_cmd.ko] undefined!
> ERROR: ".ps3_vuart_read" [drivers/ps3/ps3av_cmd.ko] undefined!
> ERROR: ".ps3av_cmd_fin" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_av_video_disable_sig" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_set_video_mode" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_video_get_monitor_info" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_audio_active" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_set_audio_mode" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_set_av_audio_param" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_vuart_read" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_av_get_hw_conf" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_av_video_mute" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_av_tv_mute" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_audio_mode" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_av_hdmi_mode" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_set_av_video_cs" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_vuart_write" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_audio_mute" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_avb_param" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_init" [drivers/ps3/ps3av.ko] undefined!
> ERROR: ".ps3av_cmd_av_audio_mute" [drivers/ps3/ps3av.ko] undefined!
> ERROR: "pmu_batteries" [drivers/power/pmu_battery.ko] undefined!
> ERROR: "pmu_battery_count" [drivers/power/pmu_battery.ko] undefined!
> ERROR: "pmu_power_flags" [drivers/power/pmu_battery.ko] undefined!
> ERROR: "irq_map" [drivers/net/pasemi_mac.ko] undefined!
> ERROR: "pmu_batteries" [drivers/macintosh/apm_emu.ko] undefined!
> ERROR: "pmu_battery_count" [drivers/macintosh/apm_emu.ko] undefined!
> ERROR: "pmu_power_flags" [drivers/macintosh/apm_emu.ko] undefined!
> ERROR: ".cpufreq_set_policy" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined!
> make[1]: *** [__modpost] Blad 1
> make: *** [modules] Blad 2
>
Yeah, allmodconfig tends to fall over in a heap on a lot of the
less-lavishly-maintained architectures. If any of these are specific to
-mm then I guess we should fix them up, prevent the kernel from actually
going backwards.
^ permalink raw reply
* Re: 2.6.22-rc3-mm1
From: Mariusz Kozlowski @ 2007-06-01 21:21 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, paulus, Arnd Bergmann, Nick Piggin, linux-kernel
In-Reply-To: <20070601140211.81e5c301.akpm@linux-foundation.org>
> > > > This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> > > > in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> > > > the patch to blame hmm.
> > > >
> > > > arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
> > > > arch/powerpc/platforms/cell/spufs/file.c:122: error: 'address' undeclared (first use in this function)
> > > > arch/powerpc/platforms/cell/spufs/file.c:122: error: (Each undeclared identifier is reported only once
> > > > arch/powerpc/platforms/cell/spufs/file.c:122: error: for each function it appears in.)
> > > > arch/powerpc/platforms/cell/spufs/file.c:141: error: expected ';' before 'if'
> > > > arch/powerpc/platforms/cell/spufs/file.c:122: warning: unused variable 'addr0'
> > > > make[3]: *** [arch/powerpc/platforms/cell/spufs/file.o] Blad 1
> > > > make[2]: *** [arch/powerpc/platforms/cell/spufs] Blad 2
> > > > make[1]: *** [arch/powerpc/platforms/cell] Blad 2
> > > >
> > >
> > > Yeah, that's the fix-fault-vs-invalidate-race patches, or my poor attempt
> > > to fix them when spufs changed. I suppose I'll have a poke at it next time
> > > I get the powerpc machine fired up.
> >
> > I #if 0'ed that piece of code inside spufs_mem_mmap_fault() and run make again.
> > This is 'make allmodconfig && make' result:
> >
> > ERROR: ".ps3av_set_hdr" [drivers/ps3/ps3av_cmd.ko] undefined!
> > ERROR: ".ps3av_do_pkt" [drivers/ps3/ps3av_cmd.ko] undefined!
> > ERROR: ".ps3_vuart_write" [drivers/ps3/ps3av_cmd.ko] undefined!
> > ERROR: ".ps3_vuart_read" [drivers/ps3/ps3av_cmd.ko] undefined!
> > ERROR: ".ps3av_cmd_fin" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_av_video_disable_sig" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_set_video_mode" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_video_get_monitor_info" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_audio_active" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_set_audio_mode" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_set_av_audio_param" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_vuart_read" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_av_get_hw_conf" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_av_video_mute" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_av_tv_mute" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_audio_mode" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_av_hdmi_mode" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_set_av_video_cs" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_vuart_write" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_audio_mute" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_avb_param" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_init" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: ".ps3av_cmd_av_audio_mute" [drivers/ps3/ps3av.ko] undefined!
> > ERROR: "pmu_batteries" [drivers/power/pmu_battery.ko] undefined!
> > ERROR: "pmu_battery_count" [drivers/power/pmu_battery.ko] undefined!
> > ERROR: "pmu_power_flags" [drivers/power/pmu_battery.ko] undefined!
> > ERROR: "irq_map" [drivers/net/pasemi_mac.ko] undefined!
> > ERROR: "pmu_batteries" [drivers/macintosh/apm_emu.ko] undefined!
> > ERROR: "pmu_battery_count" [drivers/macintosh/apm_emu.ko] undefined!
> > ERROR: "pmu_power_flags" [drivers/macintosh/apm_emu.ko] undefined!
> > ERROR: ".cpufreq_set_policy" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined!
> > make[1]: *** [__modpost] Blad 1
> > make: *** [modules] Blad 2
> >
>
> Yeah, allmodconfig tends to fall over in a heap on a lot of the
> less-lavishly-maintained architectures. If any of these are specific to
> -mm then I guess we should fix them up, prevent the kernel from actually
> going backwards.
I recall compiling earlier versions of -mm on this iMac just fine a few months ago.
Now it looks like a bunch of new warnings appeared and if fails to compile for various
reasons in different places. I'm thinking of running -mm in next few days so maybe
something interesting will come up :-)
BTW. This is 'make allnoconfig && make' result:
MODPOST vmlinux
ln: accessing `arch/powerpc/boot/zImage': No such file or directory
make[1]: *** [arch/powerpc/boot/zImage] Error 1
make: *** [zImage] Error 2
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Christoph Hellwig @ 2007-06-01 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <20070529064531.D874CDDF70@ozlabs.org>
This one doesn't seem to apply against current mainline plus the first
patch. The hung in ptrace.c rejects.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Wade Farnsworth @ 2007-06-01 21:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <dfc15991e31bfc09389461dc443acd7c@kernel.crashing.org>
On Fri, 2007-06-01 at 20:58 +0200, Segher Boessenkool wrote:
> > + ranges = <00000000 f8000000 00100000
> > + 80000000 80000000 20000000
> > + e2000000 e2000000 00100000
> > + a0000000 a0000000 20000000
> > + e3000000 e3000000 00100000>;
> > reg = <f8000000 00100000>; // CCSRBAR 1M
>
>
> "reg" included in "ranges"? Something is wrong here.
I think it's correct for soc nodes. At least, it appears that all of
the dts files with soc nodes do similar things (including this one even
without this patch).
>
> > + pci_bridge@0 {
>
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + ranges = <02000000 0 80000000
> > + 02000000 0 80000000
> > + 0 20000000
> > + 01000000 0 00000000
> > + 01000000 0 00000000
> > + 0 00100000>;
> > +
> > + isa@1e {
> > + #size-cells = <1>;
> > + #address-cells = <2>;
> >
> > + ranges = <1 0 01000000 0 0
> > + 00001000>;
>
> You map the same range (4kB legacy I/O @ 0) for both
> bridges here.
There is a one-to-one mapping between the I/O spaces of "isa" and
"pci_bridge", so wouldn't it be reasonable that a similar range be used?
>
> > + i8042@60 {
> > + reg = <1 60 1 1 64 1>;
>
> And this address space is included in both of those.
Again, shouldn't the child's address space be in its parent's range?
>
> > + keyboard@0 {
> > + compatible = "pnpPNP,303";
> > + };
> > +
> > + mouse@1 {
> > + compatible = "pnpPNP,f03";
> > + };
>
> These need a "reg" property.
I'll add them.
>
> > + rtc@70 {
> > + compatible =
> > + "pnpPNP,b00";
> > + reg = <1 70 2>;
> > + };
> > +
> > + gpio@400 {
> > + reg = <1 400 80>;
> > + };
>
> Inclusive again.
See above.
>
> > + i8259: i8259@4d0 {
>
> Needs "reg". And 4d0 isn't the primary address
> I think?
Yes, this is a standard i8259 with additional registers at 0x20 and
0xa0. I'll fix the address and add the registers.
--Wade
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Benjamin Herrenschmidt @ 2007-06-01 22:41 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <46604AE0.5040700@genesi-usa.com>
On Fri, 2007-06-01 at 17:35 +0100, Matt Sealey wrote:
> Re enabling proper domain support on 32-bit... now, now, now please!
>
> X guys won't merge in code, we've been punished by both sides on Pegasos
> for nearly 12 months now after there's been a bunch of misguided attempts
> to 'fix' domain support in X.
Well, I have commit rights on X git :-) But the current X code is too
hopeless to warrant anything but a quick hack which I don't want to do.
> The real fix is in the kernel to make it
> very clear that domains and proper, per-domain bus numbering (not
> global bus numbering) and suchlike is the standard like it is on SPARC
> and PPC64 and IA64.
Well... if the real fix means suddenly nobody can use X ... I'm sorry
but I won't inflict that one the remaining lots of 32 bits PowerMac (and
Pegasos) users. Not until there is a fixed X available. Once Ian's work
on pci-rework X.org branch is finally merged with the trunk then life
will be better for everybody.
> If ppc32 suddenly goes the way of these, X guys will fix it, there will
> be patches to work against this kernel, even if they have to detect the
> kernel version to do it or look at a procfs or sysfs entry to fix up
> their dumb pci scanning code.
X guys would probably expect me to fix it yeah :-)
> I don't think stalling on it "because of X" is right. Fix Linux, X will
> follow, because it really has to.
Ugh ... I don't think so.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Benjamin Herrenschmidt @ 2007-06-01 22:41 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Wei Zhang, Paul Mackerras, linuxppc-dev@ozlabs.org
In-Reply-To: <1180716433.14219.11.camel@ld0161-tx32>
On Fri, 2007-06-01 at 11:47 -0500, Jon Loeliger wrote:
>
> Therefore, I will go ahead and repost my PCI patch
> series to get PCI-E working again on 8641, and pointed
> in the right direction so we can merge in the support
> for 8548 and 8544 as follow ups.
>
> We (collectively) will then address the systemic PCI
> problem with 32-bit systems later.
Exactly.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Benjamin Herrenschmidt @ 2007-06-01 22:54 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <20070601212247.GA27149@lst.de>
On Fri, 2007-06-01 at 23:22 +0200, Christoph Hellwig wrote:
> This one doesn't seem to apply against current mainline plus the first
> patch. The hung in ptrace.c rejects.
It needs the 32 bits single step fixup that I posted a few days ago...
Ben.
^ permalink raw reply
* [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Mark A. Greer @ 2007-06-01 23:20 UTC (permalink / raw)
To: linuxppc-dev
Find the "rom" device for the prpmc2800 and create a device for it.
The device will be picked up by the code in drivers/mtd/maps/physmap_of.c
and will setup MTD on that FLASH device.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index d9db135..44c3144 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -20,6 +20,7 @@
#include <asm/system.h>
#include <asm/time.h>
#include <asm/kexec.h>
+#include <asm/of_platform.h>
#include <mm/mmu_decl.h>
@@ -134,6 +135,18 @@ void prpmc2800_show_cpuinfo(struct seq_file *m)
}
/*
+ * Register a platform device for MTD.
+ */
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
+ of_platform_device_create(np, np->name, NULL);
+}
+arch_initcall(prpmc2800_register_mtd);
+
+/*
* Called very early, device-tree isn't unflattened
*/
static int __init prpmc2800_probe(void)
^ permalink raw reply related
* Re: [patch] powerpc: Remove redundant pci_read_irq_line() function for 85xx platform
From: Benjamin Herrenschmidt @ 2007-06-01 23:23 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1180685138.17196.55.camel@localhost.localdomain>
On Fri, 2007-06-01 at 16:05 +0800, Zang Roy-r61911 wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Remove redundant pci_read_irq_line() function for
> 85xx CDS board.
> This function has been realized in common pci_32.c.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 76 +++++++++++++----------------
> 1 files changed, 34 insertions(+), 42 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> index 1490eb3..27b81ff 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> @@ -78,52 +78,44 @@ static int mpc85xx_exclude_device(u_char bus, u_char devfn)
> return PCIBIOS_SUCCESSFUL;
> }
>
> -static void __init mpc85xx_cds_pcibios_fixup(void)
> +static void __init mpc85xx_cds_pci_irq_fixup(struct pci_dev *dev)
> {
> - struct pci_dev *dev;
> - u_char c;
> -
> - if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
> - PCI_DEVICE_ID_VIA_82C586_1, NULL))) {
> + u_char c;
> + if (dev->vendor == PCI_VENDOR_ID_VIA) {
> + switch (dev->device) {
> + case PCI_DEVICE_ID_VIA_82C586_1:
> + /*
> + * U-Boot does not set the enable bits
> + * for the IDE device. Force them on here.
> + */
> + pci_read_config_byte(dev, 0x40, &c);
> + c |= 0x03; /* IDE: Chip Enable Bits */
> + pci_write_config_byte(dev, 0x40, c);
> +
> + /*
> + * Since only primary interface works, force the
> + * IDE function to standard primary IDE interrupt
> + * w/ 8259 offset
> + */
> + dev->irq = 14;
> + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
> + break;
> /*
> - * U-Boot does not set the enable bits
> - * for the IDE device. Force them on here.
> + * Force legacy USB interrupt routing
> */
> - pci_read_config_byte(dev, 0x40, &c);
> - c |= 0x03; /* IDE: Chip Enable Bits */
> - pci_write_config_byte(dev, 0x40, c);
> -
> - /*
> - * Since only primary interface works, force the
> - * IDE function to standard primary IDE interrupt
> - * w/ 8259 offset
> + case PCI_DEVICE_ID_VIA_82C586_2:
> + /* There are two USB controllers.
> + * Identify them by functon number
> */
> - dev->irq = 14;
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
> - pci_dev_put(dev);
> - }
> -
> - /*
> - * Force legacy USB interrupt routing
> - */
> - if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
> - PCI_DEVICE_ID_VIA_82C586_2, NULL))) {
> - dev->irq = 10;
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 10);
> - pci_dev_put(dev);
> - }
> -
> - if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
> - PCI_DEVICE_ID_VIA_82C586_2, dev))) {
> - dev->irq = 11;
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
> - pci_dev_put(dev);
> + if (PCI_FUNC(dev->devfn))
> + dev->irq = 11;
> + else
> + dev->irq = 10;
> + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
> + default:
> + break;
> + }
> }
> -
> - /* Now map all the PCI irqs */
> - dev = NULL;
> - for_each_pci_dev(dev)
> - pci_read_irq_line(dev);
> }
>
> #ifdef CONFIG_PPC_I8259
> @@ -259,7 +251,7 @@ static void __init mpc85xx_cds_setup_arch(void)
> for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> add_bridge(np);
>
> - ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
> + ppc_md.pci_irq_fixup = mpc85xx_cds_pci_irq_fixup;
> ppc_md.pci_exclude_device = mpc85xx_exclude_device;
> #endif
> }
^ permalink raw reply
* Re: [PATCH 6/8] Let subordinate transparent bridges be transparent.
From: Benjamin Herrenschmidt @ 2007-06-01 23:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180720134.14219.66.camel@ld0161-tx32>
On Fri, 2007-06-01 at 12:48 -0500, Jon Loeliger wrote:
> In pcibios_fixup_bus(), bridges that are subordinate
> to transparent bridges were still relocating their
> IORESOURCE_IO start and end values.
>
> Fix this by preventing the transparent bridge from
> relocating the start and end values, thus allowing the
> subordinate non-transparent bridge full molestation rights.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
NAK. The mem case needs a similar fix. I think we should instead do
- if (!res->flags)
- continue;
+ if (!res->flags || bus->self->transparent)
+ continue;
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-01 23:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <dfc15991e31bfc09389461dc443acd7c@kernel.crashing.org>
On Fri, 2007-06-01 at 20:58 +0200, Segher Boessenkool wrote:
> > + ranges = <00000000 f8000000 00100000
> > + 80000000 80000000 20000000
> > + e2000000 e2000000 00100000
> > + a0000000 a0000000 20000000
> > + e3000000 e3000000 00100000>;
> > reg = <f8000000 00100000>; // CCSRBAR 1M
>
>
> "reg" included in "ranges"? Something is wrong here.
Indeed. To be more precise, "ranges" is what gets forwarded to childs.
"reg" is what gets decoded by the bridge itself...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Benjamin Herrenschmidt @ 2007-06-01 23:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <CD8461E1-1881-407C-BE62-3679AECAE5AA@kernel.crashing.org>
On Fri, 2007-06-01 at 14:58 -0500, Kumar Gala wrote:
>
> So looking at the code it looks like pci_assign_all_buses should
> handle numbering the busses properly when we scan the busses, so
> what's the issue that causes that not to be correct?
Yeah, that's what powermac uses... Any reason it wouldn't work ?
Ben.
^ permalink raw reply
* Re: 2.6.22-rc3-mm1
From: Benjamin Herrenschmidt @ 2007-06-01 23:30 UTC (permalink / raw)
To: Andrew Morton
Cc: Nick Piggin, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Arnd Bergmann
In-Reply-To: <20070601140211.81e5c301.akpm@linux-foundation.org>
On Fri, 2007-06-01 at 14:02 -0700, Andrew Morton wrote:
>
>
> Yeah, allmodconfig tends to fall over in a heap on a lot of the
> less-lavishly-maintained architectures. If any of these are specific
> to
> -mm then I guess we should fix them up, prevent the kernel from
> actually
> going backwards.
Some of the later seems to be related to the lack of CONFIG_PM .. it's
not much a lavish maintainership issue than the fact that nobody every
builds the powermac drivers without CONFIG_PM :-) I'll look into fixing
some of these.
As for the ps3 bits, it's a known problem, the ps3 support is still very
much a work in progress.
Cheers,
Ben.
^ permalink raw reply
* BestComm ATA task on MPC52xx
From: Marian Balakowicz @ 2007-06-01 23:04 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am working on bringing up a DMA support for ATA controller on MPC52xx
and I am facing problems for which I am not pretty sure what the actual
root cause is.
There was a John Rigby's patch last year, which was based on arch/ppc
and drivers/ide (mpc52xx_ide.c). I use arch/powerpc and adopted to
libata version of mpc52xx_ide.c which is now merged to vanilla and is
called pata_mpc52xx.c. On top of this I have John Rigby's modifications
converted from ide to libata. Problems appear with the first DMA
transfer attempt, which happens during a driver probe when partition
table is read. There shall be a interrupt signaling a transfer end and
the handler (not present in John Rigby's code) should do the transfer
closing. But the interrupt is not received and after the cmd timeouts it
looks like ATA controller registers, BestComm registers, buffer
descriptors and BestComm ATA task variables are unchanged. So, it seems
that for some reason ATA BestComm task did not run/do it's job.
Did anyone had any success with ATA DMA on 52xx? Or maybe hear about
newer version of the ATA BestComm task, or some useful ways of debugging
BestComm stuff? I am planning to post my working code but need a day or
two to clean it up a little.
Thanks,
Marian
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-06-01 23:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <dfc15991e31bfc09389461dc443acd7c@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> "reg" included in "ranges"? Something is wrong here.
>
> You map the same range (4kB legacy I/O @ 0) for both
> bridges here.
>
> And this address space is included in both of those.
>
> These need a "reg" property.
>
> Inclusive again.
> Needs "reg". And 4d0 isn't the primary address
> I think?
And none of this could have been said earlier when
Wade first posted the patch?
jdl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox