* Re: [PATCH] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
From: Josh Boyer @ 2007-07-13 13:11 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184299081.30789.9.camel@localhost.localdomain>
On Fri, 2007-07-13 at 11:58 +0800, Zang Roy-r61911 wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Update mpc7448hpc2 device tree to be compatible for tsi109 chip.
Are there any actual changes in the drivers or platform files for
tsi109? I seem to recall that Linux treated tsi108 and tsi109
identically at the moment.
If there are changes coming that differentiate tsi109 and tsi108, please
CC me on those so I can update the Holly board as well.
josh
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Jens Axboe @ 2007-07-13 13:05 UTC (permalink / raw)
To: James Bottomley
Cc: linux-scsi, linux-kernel, Alessandro Rubini, linuxppc-dev,
Paul Mackerras, Geert Uytterhoeven
In-Reply-To: <1184331741.3402.13.camel@localhost.localdomain>
On Fri, Jul 13 2007, James Bottomley wrote:
> On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > + if (!kaddr)
> > + return -1;
> > + len = sgpnt->length;
> > + if ((req_len + len) > buflen) {
> > + active = 0;
> > + len = buflen - req_len;
> > + }
> > + memcpy(kaddr + sgpnt->offset, buf + req_len,
> > len);
> > + kunmap_atomic(kaddr, KM_USER0);
>
> This isn't a SCSI objection, but this sequence appears several times in
> this driver. It's wrong for a non-PIPT architecture (and I believe the
> PS3 is VIPT) because you copy into the kernel alias for the page, which
> dirties the line in the cache of that alias (the user alias cache line
> was already invalidated). However, unless you flush the kernel alias to
> main memory, the user could read stale data. The way this is supposed
> to be done is to do a
>
> flush_kernel_dcache_page(kaddr)
>
> before doing the kunmap.
>
> Otherwise it looks OK from the SCSI point of view.
Well, even worse is that fact that it's using KM_USER0 from interrupt
context.
--
Jens Axboe
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: James Bottomley @ 2007-07-13 13:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, linux-scsi, linux-kernel, Alessandro Rubini,
linuxppc-dev, Paul Mackerras
In-Reply-To: <20070704132346.591348000@pademelon.sonytel.be>
On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> + if (!kaddr)
> + return -1;
> + len = sgpnt->length;
> + if ((req_len + len) > buflen) {
> + active = 0;
> + len = buflen - req_len;
> + }
> + memcpy(kaddr + sgpnt->offset, buf + req_len,
> len);
> + kunmap_atomic(kaddr, KM_USER0);
This isn't a SCSI objection, but this sequence appears several times in
this driver. It's wrong for a non-PIPT architecture (and I believe the
PS3 is VIPT) because you copy into the kernel alias for the page, which
dirties the line in the cache of that alias (the user alias cache line
was already invalidated). However, unless you flush the kernel alias to
main memory, the user could read stale data. The way this is supposed
to be done is to do a
flush_kernel_dcache_page(kaddr)
before doing the kunmap.
Otherwise it looks OK from the SCSI point of view.
James
^ permalink raw reply
* Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
From: Christoph Hellwig @ 2007-07-13 12:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Philippe Elie, linuxppc, Bob Nelson, oprofile, Andrew Morton,
Christoph Hellwig
In-Reply-To: <1184330090.6059.219.camel@localhost.localdomain>
On Fri, Jul 13, 2007 at 10:34:50PM +1000, Benjamin Herrenschmidt wrote:
>
> > > + if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
> > > + &ctx->sched_flags))) {
> > > + clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
> >
> > this should use test_and_clear_bit
>
> This also looks like an abuse of atomics to effectively implement a lock
> or did I miss something ?
not really. We set a flag on the context to make sure some action is
performed when it comes through spu_run the next time. It's not exactly
elegant, but cleaning this up will have to wait for the grand spu_run
rewrite.
^ permalink raw reply
* Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
From: Benjamin Herrenschmidt @ 2007-07-13 12:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linuxppc, Andrew Morton, Bob Nelson, oprofile, Philippe Elie
In-Reply-To: <20070713101233.GA12426@lst.de>
> > + if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
> > + &ctx->sched_flags))) {
> > + clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
>
> this should use test_and_clear_bit
This also looks like an abuse of atomics to effectively implement a lock
or did I miss something ?
Ben.
^ permalink raw reply
* Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
From: Benjamin Herrenschmidt @ 2007-07-13 12:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development,
Ben Collins
In-Reply-To: <Pine.LNX.4.62.0707131404320.18802@pademelon.sonytel.be>
> Since 720p is a broadcast mode, I can't make it default to fullscreen, as a
> part of the image will fall off on most monitors.
Do you have any info from the EDID block that would tell you whether the
monitor displays the full picture (typical of flat panels) or not ?
Ben.
^ permalink raw reply
* PS3 Storage Driver O_DIRECT issue
From: Olaf Hering @ 2007-07-13 12:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, James E.J. Bottomley, linux-scsi, Alessandro Rubini,
linux-kernel, linuxppc-dev, Paul Mackerras
In-Reply-To: <20070704132212.726923000@pademelon.sonytel.be>
This driver (or the generic PS3 code) has appearently problems with
O_DIRECT.
glibc aborts parted because the malloc metadata get corrupted. While it
is reproducible, the place where it crashes changes with every version
of the debug attempt.
I dont have a handle right now, all I know is that the metadata after a
malloc area get overwritten with zeros.
Can you have a look at this?
parted /dev/ps3da
print (a few times)
^ permalink raw reply
* Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
From: Geert Uytterhoeven @ 2007-07-13 12:06 UTC (permalink / raw)
To: Håvard Espeland
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development,
Ben Collins
In-Reply-To: <20070713094814.GD507@ping.uio.no>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 3004 bytes --]
Hi Håvard,
> On Thu, Jul 12, 2007 at 05:12:43PM +0200, Geert Uytterhoeven wrote:
> > On Thu, 12 Jul 2007, [iso-8859-1] H?vard Espeland wrote:
> > > On Thu, Jul 12, 2007 at 10:40:47AM +0200, Geert Uytterhoeven wrote:
> > > > If it fails, please add `#define DEBUG' to drivers/ps3/ps3av.c, send me the
> > > > `Monitor Info' output in the kernel log (dmesg), and tell me which of the
> > > > PS3 video modes (1-13) work and which don't. ps3av has a quirk database for
> > > > monitors that advertise non-working modes, so it can probably be fixed.
> > > > (BTW, even if autodetect works fine, I always welcome this information)
> > > >
> > > > In case you have a big pile of monitors at your site, you don't have to reboot
> > > > to try them all. Just plug in the new monitor and run `ps3videomode -v 0' to
> > > > switch to the best resolution of the newly-connected monitor.
> > >
> > > Hi, the autodetect code does not work correctly with a LG L226WTQ
> > So your monitor advertises:
> >
> > Supported 60 Hz modes: 1080p 480p 720p 1080i (0000400d)
> > Supported VESA modes: VGA (00000001)
> >
> > But 1080p and 1080i don't work. As 1080p is the best advertised mode, you don't
> > get anything to see :-(
> >
> > Does this patch help? It should give you 720p by default.
> >
> > Index: ps3-linux-2.6/drivers/ps3/ps3av.c
> > ===================================================================
> > --- ps3-linux-2.6.orig/drivers/ps3/ps3av.c 2007-07-12 10:26:33.000000000 +0200
> > +++ ps3-linux-2.6/drivers/ps3/ps3av.c 2007-07-12 16:57:39.000000000 +0200
> > @@ -720,6 +720,10 @@ static const struct ps3av_monitor_quirk
> > {
> > .monitor_name = "DELL 2007WFP",
> > .clear_60 = PS3AV_RESBIT_1920x1080I
> > + }, {
> > + .monitor_name = "L226WTQ",
> > + .clear_60 = PS3AV_RESBIT_1920x1080I |
> > + PS3AV_RESBIT_1920x1080P
> > }
> > };
> >
>
> The patch gives me a picture, but it does not cover the whole screen.
> Ps3videomode returns mode 67, and if i add 128 to that number I get
Yep, 720p. Good.
> working fullscreen. Additionally, the break in ps3av_fixup_monitor_info
Since 720p is a broadcast mode, I can't make it default to fullscreen, as a
part of the image will fall off on most monitors.
> is misplaced and will only try the first quirk.
Woops, fixed, thanks!
> ps3av_hdmi_get_vid: Using supported resolution 9
>
> --
> Håvard Espeland
>
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
From: Christoph Hellwig @ 2007-07-13 10:13 UTC (permalink / raw)
To: Bob Nelson; +Cc: linuxppc, Andrew Morton, oprofile, Philippe Elie
In-Reply-To: <20070713101233.GA12426@lst.de>
On Fri, Jul 13, 2007 at 12:12:33PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 12, 2007 at 06:45:40PM -0500, Bob Nelson wrote:
> > We would like this patch included in -mm and in 2.6.23.
>
> Do you plan to submit oprofile support aswell? In that case it's fine
> otherwise please send it together with the actual oprofile support.
I just saw the oprofile patch is next, so this is okay.
^ permalink raw reply
* Re: [PATCH 2/4] Implement arch disable/enable irq hooks.
From: Johannes Berg @ 2007-07-13 10:11 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070712191257.GA31381@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
On Thu, 2007-07-12 at 14:12 -0500, Scott Wood wrote:
> +void generic_suspend_disable_irqs(void)
> +void generic_suspend_enable_irqs(void)
Oh hm on second thought, can we have these in some header file so we can
call them if we need to use the ppc_md hooks?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] Implement arch disable/enable irq hooks.
From: Johannes Berg @ 2007-07-13 10:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070712191257.GA31381@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
On Thu, 2007-07-12 at 14:12 -0500, Scott Wood wrote:
> These hooks ensure that a decrementer interrupt is not pending when
> suspending; otherwise, problems may occur. For example, with deep sleep
> on the 831x, a pending decrementer will cause a system freeze because the
> SoC thinks the decrementer interrupt would have woken the system, but the
> core must have interrupts disabled due to the setup required for deep
> sleep.
> +/* Overrides the weak version in kernel/power/main.c */
> +void arch_suspend_disable_irqs(void)
> +{
> + if (ppc_md.suspend_disable_irqs)
> + ppc_md.suspend_disable_irqs();
> + else
> + generic_suspend_disable_irqs();
> +}
Looks good to me, thanks for the update with ppc_md.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
From: Christoph Hellwig @ 2007-07-13 10:12 UTC (permalink / raw)
To: Bob Nelson; +Cc: linuxppc, Andrew Morton, oprofile, Philippe Elie
In-Reply-To: <1184283940.16584.5.camel@bnelson60.rchland.ibm.com>
On Thu, Jul 12, 2007 at 06:45:40PM -0500, Bob Nelson wrote:
> We would like this patch included in -mm and in 2.6.23.
Do you plan to submit oprofile support aswell? In that case it's fine
otherwise please send it together with the actual oprofile support.
> +static void notify_spus_active(void)
> +{
> + int node;
> + /* Wake up the active spu_contexts. When the awakened processes
> + * see their "notify_active" flag is set, they will call
> + * spu_switch_notify();
> + */
Small style issue, this should be:
int node;
/*
* Wake up the active spu_contexts.
*
* When the awakened processes see their "notify_active" flag is set,
* they will call spu_switch_notify().
*/
> -static inline int spu_stopped(struct spu_context *ctx, u32 * stat)
> +static inline int spu_stopped(struct spu_context *ctx, u32 *stat)
useless (and wrong) reformatting, please remove.
> -static int spu_run_init(struct spu_context *ctx, u32 * npc)
> +static int spu_run_init(struct spu_context *ctx, u32 *npc)
Same here.
> -static int spu_run_fini(struct spu_context *ctx, u32 * npc,
> - u32 * status)
> +static int spu_run_fini(struct spu_context *ctx, u32 *npc,
> + u32 *status)
Same here.
> + if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
> + &ctx->sched_flags))) {
> + clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
this should use test_and_clear_bit
^ permalink raw reply
* [PATCH 2/2] Add PCI/PCI Express node for 8544DS board]
From: Zang Roy-r61911 @ 2007-07-13 10:05 UTC (permalink / raw)
To: Kumar Gala, Paul Mackerras; +Cc: linuxppc-dev list
From: Roy Zang <tie-fei.zang@freescale.com>
Add PCI/PCI Express node for 8544DS board.
---
arch/powerpc/boot/dts/mpc8544ds.dts | 211 +++++++++++++++++++++++++++++++++++
1 files changed, 211 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 43bf5c1..aab0bc6 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -143,6 +143,217 @@
fsl,has-rstcr;
};
+ pci@8000 {
+ compatible = "fsl,mpc8540-pci";
+ device_type = "pci";
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 J17 Slot 1 */
+ 8800 0 0 1 &mpic 2 1
+ 8800 0 0 2 &mpic 3 1
+ 8800 0 0 3 &mpic 4 1
+ 8800 0 0 4 &mpic 1 1
+
+ /* IDSEL 0x12 J16 Slot 2 */
+
+ 9000 0 0 1 &mpic 3 1
+ 9000 0 0 2 &mpic 4 1
+ 9000 0 0 3 &mpic 2 1
+ 9000 0 0 4 &mpic 1 1>;
+
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 80000000 80000000 0 10000000
+ 01000000 0 00000000 e2000000 0 00800000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ };
+
+ pci@a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <a000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 90000000 90000000 0 10000000
+ 01000000 0 00000000 e2800000 0 00800000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <19 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ };
+
+ pci@9000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <9000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 a0000000 a0000000 0 10000000
+ 01000000 0 00000000 e3000000 0 00800000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1a 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 4 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ };
+
+ pci@b000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <b000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 b0000000 b0000000 0 10000000
+ 01000000 0 00000000 e3800000 0 00800000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1b 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ // IDSEL 0x1a
+ d000 0 0 1 &i8259 6 2
+ d000 0 0 2 &i8259 3 2
+ d000 0 0 3 &i8259 4 2
+ d000 0 0 4 &i8259 5 2
+
+ // IDSEL 0x1b
+ d800 0 0 1 &i8259 5 2
+ d800 0 0 2 &i8259 0 0
+ d800 0 0 3 &i8259 0 0
+ d800 0 0 4 &i8259 0 0
+
+ // IDSEL 0x1c USB
+ e000 0 0 1 &i8259 9 2
+ e000 0 0 2 &i8259 a 2
+ e000 0 0 3 &i8259 c 2
+ e000 0 0 4 &i8259 7 2
+
+ // IDSEL 0x1d Audio
+ e800 0 0 1 &i8259 9 2
+ e800 0 0 2 &i8259 a 2
+ e800 0 0 3 &i8259 b 2
+ e800 0 0 4 &i8259 0 0
+
+ // IDSEL 0x1e Legacy
+ f000 0 0 1 &i8259 c 2
+ f000 0 0 2 &i8259 0 0
+ f000 0 0 3 &i8259 0 0
+ f000 0 0 4 &i8259 0 0
+
+ // IDSEL 0x1f IDE/SATA
+ f800 0 0 1 &i8259 6 2
+ f800 0 0 2 &i8259 0 0
+ f800 0 0 3 &i8259 0 0
+ f800 0 0 4 &i8259 0 0
+ >;
+ uli1575@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 a0000000
+ 02000000 0 a0000000
+ 0 10000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00080000>;
+
+ pci_bridge@0 {
+ reg = <0 0 0 0 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 {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <f000 0 0 0 0>;
+ ranges = <1 0 01000000 0 0
+ 00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ reg = <1 20 2
+ 1 a0 2
+ 1 4d0 2>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ interrupts = <9 2>;
+ interrupt-parent =
+ <&mpic>;
+ };
+
+ i8042@60 {
+ #size-cells = <0>;
+ #address-cells = <1>;
+ reg = <1 60 1 1 64 1>;
+ interrupts = <1 3 c 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ reg = <0>;
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ reg = <1>;
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible =
+ "pnpPNP,b00";
+ reg = <1 70 2>;
+ };
+
+ gpio@400 {
+ reg = <1 400 80>;
+ };
+ };
+ };
+ };
+
+ };
+
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
--
1.5.1
^ permalink raw reply related
* [PATCH 1/2] Add basic PCI /PCI Express support for 8544DS board
From: Zang Roy-r61911 @ 2007-07-13 10:05 UTC (permalink / raw)
To: Kumar Gala, Paul Mackerras; +Cc: linuxppc-dev list
From: Roy Zang <tie-fei.zang@freescale.com>
Add basic PCI/PCI Express support for 8544DS board.
Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/platforms/85xx/Kconfig | 1 +
arch/powerpc/platforms/85xx/mpc8544_ds.c | 252 ++++++++++++++++++++++++++++++
2 files changed, 253 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 526ddde..6729e12 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -30,6 +30,7 @@ config MPC85xx_MDS
config MPC8544_DS
bool "Freescale MPC8544 DS"
+ select PPC_I8259
select DEFAULT_UIMAGE
help
This option enables support for the MPC8544 DS board
diff --git a/arch/powerpc/platforms/85xx/mpc8544_ds.c b/arch/powerpc/platforms/85xx/mpc8544_ds.c
index 6fb90aa..e5ec8dd 100644
--- a/arch/powerpc/platforms/85xx/mpc8544_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc8544_ds.c
@@ -2,6 +2,8 @@
* MPC8544 DS Board Setup
*
* Author Xianghua Xiao (x.xiao@freescale.com)
+ * Roy Zang <tie-fei.zang@freescale.com>
+ * - Add PCI/PCI Exprees support
* Copyright 2007 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
@@ -12,13 +14,16 @@
#include <linux/stddef.h>
#include <linux/kernel.h>
+#include <linux/pci.h>
#include <linux/kdev_t.h>
#include <linux/delay.h>
#include <linux/seq_file.h>
+#include <linux/interrupt.h>
#include <asm/system.h>
#include <asm/time.h>
#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
#include <asm/mpc85xx.h>
#include <mm/mmu_decl.h>
#include <asm/prom.h>
@@ -27,6 +32,7 @@
#include <asm/i8259.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include "mpc85xx.h"
#undef DEBUG
@@ -37,6 +43,17 @@
#define DBG(fmt, args...)
#endif
+#ifdef CONFIG_PPC_I8259
+static void mpc8544_8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+
+ if (cascade_irq != NO_IRQ) {
+ generic_handle_irq(cascade_irq);
+ }
+ desc->chip->eoi(irq);
+}
+#endif /* CONFIG_PPC_I8259 */
void __init mpc8544_ds_pic_init(void)
{
@@ -96,18 +113,252 @@ void __init mpc8544_ds_pic_init(void)
#endif /* CONFIG_PPC_I8259 */
}
+#ifdef CONFIG_PCI
+enum pirq { PIRQA = 8, PIRQB, PIRQC, PIRQD, PIRQE, PIRQF, PIRQG, PIRQH };
+
+/*
+ * Value in table -- IRQ number
+ */
+const unsigned char uli1575_irq_route_table[16] = {
+ 0, /* 0: Reserved */
+ 0x8,
+ 0, /* 2: Reserved */
+ 0x2,
+ 0x4,
+ 0x5,
+ 0x7,
+ 0x6,
+ 0, /* 8: Reserved */
+ 0x1,
+ 0x3,
+ 0x9,
+ 0xb,
+ 0, /* 13: Reserved */
+ 0xd,
+ 0xf,
+};
+
+static int __devinit
+get_pci_irq_from_of(struct pci_controller *hose, int slot, int pin)
+{
+ struct of_irq oirq;
+ u32 laddr[3];
+ struct device_node *hosenode = hose ? hose->arch_data : NULL;
+
+ if (!hosenode)
+ return -EINVAL;
+
+ laddr[0] = (hose->first_busno << 16) | (PCI_DEVFN(slot, 0) << 8);
+ laddr[1] = laddr[2] = 0;
+ of_irq_map_raw(hosenode, &pin, 1, laddr, &oirq);
+ DBG("mpc8544_ds: pci irq addr %x, slot %d, pin %d, irq %d\n",
+ laddr[0], slot, pin, oirq.specifier[0]);
+ return oirq.specifier[0];
+}
+
+/*8259*/
+static void __devinit quirk_uli1575(struct pci_dev *dev)
+{
+ unsigned short temp;
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ unsigned char irq2pin[16];
+ unsigned long pirq_map_word = 0;
+ u32 irq;
+ int i;
+
+ /*
+ * ULI1575 interrupts route setup
+ */
+ memset(irq2pin, 0, 16); /* Initialize default value 0 */
+
+ irq2pin[6]=PIRQA+3; /* enabled mapping for IRQ6 to PIRQD, used by SATA */
+
+ /*
+ * PIRQE -> PIRQF mapping set manually
+ *
+ * IRQ pin IRQ#
+ * PIRQE ---- 9
+ * PIRQF ---- 10
+ * PIRQG ---- 11
+ * PIRQH ---- 12
+ */
+ for (i = 0; i < 4; i++)
+ irq2pin[i + 9] = PIRQE + i;
+
+ /* Set IRQ-PIRQ Mapping to ULI1575 */
+ for (i = 0; i < 16; i++)
+ if (irq2pin[i])
+ pirq_map_word |= (uli1575_irq_route_table[i] & 0xf)
+ << ((irq2pin[i] - PIRQA) * 4);
+
+ pirq_map_word |= 1<<26; /* disable INTx in EP mode*/
+
+ /* ULI1575 IRQ mapping conf register default value is 0xb9317542 */
+ DBG("Setup ULI1575 IRQ mapping configuration register value = 0x%x\n",
+ (int)pirq_map_word);
+ pci_write_config_dword(dev, 0x48, pirq_map_word);
+
+#define ULI1575_SET_DEV_IRQ(slot, pin, reg) \
+ do { \
+ int irq; \
+ irq = get_pci_irq_from_of(hose, slot, pin); \
+ if (irq > 0 && irq < 16) \
+ pci_write_config_byte(dev, reg, irq2pin[irq]); \
+ else \
+ printk(KERN_WARNING "ULI1575 device" \
+ "(slot %d, pin %d) irq %d is invalid.\n", \
+ slot, pin, irq); \
+ } while(0)
+
+ /* USB 1.1 OHCI controller 1, slot 28, pin 1 */
+ ULI1575_SET_DEV_IRQ(28, 1, 0x86);
+
+ /* USB 1.1 OHCI controller 2, slot 28, pin 2 */
+ ULI1575_SET_DEV_IRQ(28, 2, 0x87);
+
+ /* USB 1.1 OHCI controller 3, slot 28, pin 3 */
+ ULI1575_SET_DEV_IRQ(28, 3, 0x88);
+
+ /* USB 2.0 controller, slot 28, pin 4 */
+ irq = get_pci_irq_from_of(hose, 28, 4);
+ if (irq >= 0 && irq <= 15)
+ pci_write_config_dword(dev, 0x74, uli1575_irq_route_table[irq]);
+
+ /* Audio controller, slot 29, pin 1 */
+ ULI1575_SET_DEV_IRQ(29, 1, 0x8a);
+
+ /* Modem controller, slot 29, pin 2 */
+ ULI1575_SET_DEV_IRQ(29, 2, 0x8b);
+
+ /* HD audio controller, slot 29, pin 3 */
+ ULI1575_SET_DEV_IRQ(29, 3, 0x8c);
+
+ /* SMB interrupt: slot 30, pin 1 */
+ ULI1575_SET_DEV_IRQ(30, 1, 0x8e);
+
+ /* PMU ACPI SCI interrupt: slot 30, pin 2 */
+ ULI1575_SET_DEV_IRQ(30, 2, 0x8f);
+
+ /* Serial ATA interrupt: slot 31, pin 1 */
+ ULI1575_SET_DEV_IRQ(31, 1, 0x8d);
+
+ /* Primary PATA IDE IRQ: 14
+ * Secondary PATA IDE IRQ: 15
+ */
+ pci_write_config_byte(dev, 0x44, 0x30 | uli1575_irq_route_table[14]);
+ pci_write_config_byte(dev, 0x75, uli1575_irq_route_table[15]);
+
+ /* Set IRQ14 and IRQ15 to legacy IRQs */
+ pci_read_config_word(dev, 0x46, &temp);
+ temp |= 0xc000;
+ pci_write_config_word(dev, 0x46, temp);
+
+ /* Set i8259 interrupt trigger
+ * IRQ 3: Level
+ * IRQ 4: Level
+ * IRQ 5: Level
+ * IRQ 6: Level
+ * IRQ 7: Level
+ * IRQ 9: Level
+ * IRQ 10: Level
+ * IRQ 11: Level
+ * IRQ 12: Level
+ * IRQ 14: Edge
+ * IRQ 15: Edge
+ */
+ outb(0xfa, 0x4d0);
+ outb(0x1e, 0x4d1);
+
+#undef ULI1575_SET_DEV_IRQ
+}
+
+/* SATA */
+static void __devinit quirk_uli5288(struct pci_dev *dev)
+{
+ unsigned char c;
+
+ pci_read_config_byte(dev, 0x83, &c);
+ c |= 0x80; /* read/write lock */
+ pci_write_config_byte(dev, 0x83, c);
+
+ pci_write_config_byte(dev, 0x09, 0x01); /* Base class code: storage */
+ pci_write_config_byte(dev, 0x0a, 0x06); /* IDE disk */
+
+ pci_read_config_byte(dev, 0x83, &c);
+ c &= 0x7f;
+ pci_write_config_byte(dev, 0x83, c);
+
+ pci_read_config_byte(dev, 0x84, &c);
+ c |= 0x01; /* emulated PATA mode enabled */
+ pci_write_config_byte(dev, 0x84, c);
+}
+
+/* PATA */
+static void __devinit quirk_uli5229(struct pci_dev *dev)
+{
+ unsigned short temp;
+ pci_write_config_word(dev, 0x04, 0x0405); /* MEM IO MSI */
+ pci_read_config_word(dev, 0x4a, &temp);
+ temp |= 0x1000; /* Enable Native IRQ 14/15 */
+ pci_write_config_word(dev, 0x4a, temp);
+}
+
+/*Bridge*/
+static void __devinit early_uli5249(struct pci_dev *dev)
+{
+ unsigned char temp;
+ pci_write_config_word(dev, 0x04, 0x0007); /* mem access */
+ pci_read_config_byte(dev, 0x7c, &temp);
+ pci_write_config_byte(dev, 0x7c, 0x80); /* R/W lock control */
+ pci_write_config_byte(dev, 0x09, 0x01); /* set as pci-pci bridge */
+ pci_write_config_byte(dev, 0x7c, temp); /* restore pci bus debug control */
+ dev->class |= 0x1;
+}
+
+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(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
+#endif /* CONFIG_PCI */
/*
* Setup the architecture
*/
static void __init mpc8544_ds_setup_arch(void)
{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+
if (ppc_md.progress)
ppc_md.progress("mpc8544_ds_setup_arch()", 0);
+#ifdef CONFIG_PCI
+ for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;) {
+ struct resource rsrc;
+ of_address_to_resource(np, 0, &rsrc);
+ if ((rsrc.start & 0xfffff) == 0x9000)
+ fsl_add_bridge(np, 0);
+ else
+ fsl_add_bridge(np, 1);
+ }
+#endif
+
printk("MPC8544 DS board from Freescale Semiconductor\n");
}
+void __init mpc8544_ds_pcibios_fixup_bus(struct pci_bus *bus)
+{
+ if (bus->self && bus->self->vendor == 0x10b9
+ && bus->self->device == 0x5249) {
+ bus->parent->resource[0]->end = bus->parent->resource[0]->start
+ + 0xffff;
+ if (bus->resource[1] && bus->parent->resource[1])
+ bus->parent->resource[1]->end +=
+ bus->resource[1]->end + 1 + 0x100000
+ - bus->resource[1]->start;
+ }
+}
/*
* Called very early, device-tree isn't unflattened
@@ -124,6 +375,7 @@ define_machine(mpc8544_ds) {
.probe = mpc8544_ds_probe,
.setup_arch = mpc8544_ds_setup_arch,
.init_IRQ = mpc8544_ds_pic_init,
+ .pcibios_fixup_bus = mpc8544_ds_pcibios_fixup_bus,
.get_irq = mpic_get_irq,
.restart = mpc85xx_restart,
.calibrate_decr = generic_calibrate_decr,
--
1.5.1
^ permalink raw reply related
* [PATCH 0/2] Add basic PCI/PCI express support for 8544DS board
From: Zang Roy-r61911 @ 2007-07-13 10:04 UTC (permalink / raw)
To: Kumar Gala, Paul Mackerras; +Cc: linuxppc-dev list
These two patches add basic PCI/PCI Express support
for 8544DS board.
These patches are based on current Kumar's tree for_paulus.
Roy
^ permalink raw reply
* Re: [PATCH 2/2] Add support to OProfile for profiling Cell BE SPUs
From: Arnd Bergmann @ 2007-07-13 10:02 UTC (permalink / raw)
To: linuxppc-dev, rrnelson; +Cc: oprofile, Andrew Morton, Philippe Elie
In-Reply-To: <1184284059.16584.7.camel@bnelson60.rchland.ibm.com>
On Friday 13 July 2007, Bob Nelson wrote:
> We would like this patch included in -mm and 2.6.23.
>=20
> Subject: Add support to OProfile for profiling Cell BE SPUs
>=20
> From: Maynard Johnson <mpjohn@us.ibm.com>
> Bob Nelson <rrnelson@us.ibm.com>
>=20
The patch itself looks ok, but unfortunately, you have a few
formal mistakes in the submission. Most importantly, the long
lines got wrapped by your mail client, so it won't apply.
About the start of the mail, please put the 'We would like to...'
part and everything else that is not supposed to show up in
the changelog _below_ the introduction, separated from the
changelog with a single line containing the string '---'.
The Subject: line should not be in the mail body, it's only
used if you want to use the 'quilt mail' tool, which will
move it to the real subject of the mail.
The From: line can only have one name in it. If you want to
give credit to multiple people, that should be in the
changelog text.
Please resend.
Arnd <><
> This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
> to add in the SPU profiling capabilities. =A0In addition, a 'cell'
> subdirectory
> was added to arch/powerpc/oprofile to hold Cell-specific SPU profiling
> code.
> Also incorporated several fixes from other patches. =A0Check pointer
> returned from kzalloc. =A0Eliminated unnecessary cast. =A0Better error
> handling and cleanup in the related area. =A064-bit unsigned long
> parameter
> was being demoted to 32-bit unsigned int and eventually promoted back to
> unsigned long.
>=20
> Signed-off-by: Carl Love <carll@us.ibm.com>
> Signed-off-by: Maynard Johnson <mpjohn@us.ibm.com>
> Signed-off-by: Bob Nelson <rrnelson@us.ibm.com>
> Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 0/5] Kconfig cleanup revisited
From: Arnd Bergmann @ 2007-07-13 9:54 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070713013953.GC29074@mag.az.mvista.com>
On Friday 13 July 2007, Mark A. Greer wrote:
> I really like what you've done here, thanks.
>
> The patches don't apply straight up so what other patches do these go
> on top of?
They are meant to apply on top of powerpc.git. I found now that
the first patch has a trivial reject against the for-2.6.23 branch,
but works fine for the master branch.
Should I resend?
Arnd <><
^ permalink raw reply
* Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
From: Håvard Espeland @ 2007-07-13 9:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development,
Ben Collins
In-Reply-To: <Pine.LNX.4.62.0707121704270.8368@pademelon.sonytel.be>
On Thu, Jul 12, 2007 at 05:12:43PM +0200, Geert Uytterhoeven wrote:
> On Thu, 12 Jul 2007, [iso-8859-1] H?vard Espeland wrote:
> > On Thu, Jul 12, 2007 at 10:40:47AM +0200, Geert Uytterhoeven wrote:
> > > If it fails, please add `#define DEBUG' to drivers/ps3/ps3av.c, send me the
> > > `Monitor Info' output in the kernel log (dmesg), and tell me which of the
> > > PS3 video modes (1-13) work and which don't. ps3av has a quirk database for
> > > monitors that advertise non-working modes, so it can probably be fixed.
> > > (BTW, even if autodetect works fine, I always welcome this information)
> > >
> > > In case you have a big pile of monitors at your site, you don't have to reboot
> > > to try them all. Just plug in the new monitor and run `ps3videomode -v 0' to
> > > switch to the best resolution of the newly-connected monitor.
> >
> > Hi, the autodetect code does not work correctly with a LG L226WTQ
> > (native resolution 1680x1050). The detected mode (11) works fine without
> > fullscreen, but goes out of range with '-f'.
>
> This `supported resolution 11' is not the same as the mode number to pass to
> ps3videomode, it's a PS3AV_CMD_VIDEO_VID_* ID.
>
> Vid 11 corresponds to PS3AV_CMD_VIDEO_VID_1080P_60Hz (i.e. 1080p).
> While mode 11 is WXGA (i.e. 1280x768).
>
> (Upon further inspection, this `vid' is immediately converted to a mode number,
> so I'll change the code to use mode numbers instead, and cause less
> confusion).
>
> > Resolutions w/o fullscreen:
> > OK: 2, 3, 7, 8, 11, 12
> > BAD: 1, 4, 5, 6, 9, 10, 13
>
> Looks reasonable for a 1680x1050 monitor...
>
> > Resolutions with fullscreen:
> > OK: 2, 3, 7, 8
> > BAD: 1, 4, 5, 6, 9, 10, 11, 12, 13
>
> Euh, `-f' shouldn't make any difference for modes 11-13, as they're always
> fullscreen.
>
> > Monitor Info: size 96
> > avport: 00
> > monitor_id: 1e 6d 4e 56 d7 2a 03 00 03 11
> > monitor_type: 02
> > monitor_name: L226WTQ
> > resolution_60: bits: 0000400d native: 00000000
> > resolution_50: bits: 00000000 native: 00000000
> > resolution_other: bits: 00000000 native: 00000000
> > resolution_vesa: bits: 00000001 native: 00000000
>
> So your monitor advertises:
>
> Supported 60 Hz modes: 1080p 480p 720p 1080i (0000400d)
> Supported VESA modes: VGA (00000001)
>
> But 1080p and 1080i don't work. As 1080p is the best advertised mode, you don't
> get anything to see :-(
>
> Does this patch help? It should give you 720p by default.
>
> Index: ps3-linux-2.6/drivers/ps3/ps3av.c
> ===================================================================
> --- ps3-linux-2.6.orig/drivers/ps3/ps3av.c 2007-07-12 10:26:33.000000000 +0200
> +++ ps3-linux-2.6/drivers/ps3/ps3av.c 2007-07-12 16:57:39.000000000 +0200
> @@ -720,6 +720,10 @@ static const struct ps3av_monitor_quirk
> {
> .monitor_name = "DELL 2007WFP",
> .clear_60 = PS3AV_RESBIT_1920x1080I
> + }, {
> + .monitor_name = "L226WTQ",
> + .clear_60 = PS3AV_RESBIT_1920x1080I |
> + PS3AV_RESBIT_1920x1080P
> }
> };
>
The patch gives me a picture, but it does not cover the whole screen.
Ps3videomode returns mode 67, and if i add 128 to that number I get
working fullscreen. Additionally, the break in ps3av_fixup_monitor_info
is misplaced and will only try the first quirk.
dmesg:
ps3av_hdmi_get_vid: Using supported resolution 9
--
Håvard Espeland
^ permalink raw reply
* [PATCH] Add global-utilities node for mpc8544ds and mpc8572mds boards
From: Zang Roy-r61911 @ 2007-07-13 9:35 UTC (permalink / raw)
To: Kumar Gala, Paul Mackerras; +Cc: linuxppc-dev list
From: Roy Zang <tie-fei.zang@freescale.com>
Add global-utilities node for mpc8544ds and mpc8572mds boards
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/boot/dts/mpc8544ds.dts | 6 ++++++
arch/powerpc/boot/dts/mpc8568mds.dts | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 8285925..43bf5c1 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -137,6 +137,12 @@
interrupt-parent = <&mpic>;
};
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index c6cd1d6..5eeb0e6 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -170,6 +170,12 @@
interrupt-parent = <&mpic>;
};
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
pci@8000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
--
1.5.1
^ permalink raw reply related
* Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4
From: Geert Uytterhoeven @ 2007-07-13 9:31 UTC (permalink / raw)
To: Paul Mackerras, James E.J. Bottomley, Alessandro Rubini
Cc: Linux/PPC Development, Linux Kernel Development, linux-scsi
In-Reply-To: <Pine.LNX.4.62.0707100944470.22782@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1901 bytes --]
On Tue, 10 Jul 2007, Geert Uytterhoeven wrote:
> On Wed, 4 Jul 2007, Geert Uytterhoeven wrote:
> > This is the fourth submission of the new PS3 storage drivers:
> > [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
> > [2] ps3: Storage Driver Core
> > [3] ps3: Storage device registration routines.
> > [4] ps3: Disk Storage Driver
> > [5] ps3: BD/DVD/CD-ROM Storage Driver
> > [6] ps3: FLASH ROM Storage Driver
> >
> > They are based on:
> > - the current Linux kernel source tree,
> > - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev,
> > - plus the shost_priv() patch in scsi-misc (commit
> > bcd92c9fbcc679ee95003083056f0441a1f474fa).
> >
> > All issues raised during the previous review rounds should be fixed.
> > There were no more comments after the third submission.
> >
> > Paul already integrated Geoff Levand's PS3 patches and the first 3 patches
> > in this series in the for-2.6.23 branch in powerpc.git.
> >
> > Maintainers of block/SCSI/misc, can you please ack the last 3 patches so Paul
> > can take them, too?
>
> Ping block/SCSI/misc maintainers?
Ping SCSI and misc maintainers?
Please either ack patches 5 and 6, so Paulus can integrate them for 2.6.23, or
tell me why they can't go in.
Thanks again.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: XSysAce driver cant mount DOS part
From: urwithsudheer @ 2007-07-13 9:25 UTC (permalink / raw)
To: Robertson, Joseph M.; +Cc: linuxppc-embedded
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]
Hi
Robertson, Joseph M. wrote:
>
> Hi all,
>
> I've been workig with this for a while but have made no progress.
> Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> it to get clean code.
> I inherited the previous code from another developer.
>
Can you send the link to xsysace driver source code from where you obtained.
Thanks
Sudheer
>
> My problem is that mounting the DOS partition always fails in a short
> time with a kernel oops.
>
> ECAU-9999:# Oops: kernel access of bad area, sig: 11
> [#1]
> PREEMPT
> NIP: C00701C8 LR: C0070C18 CTR:
> 00000000
> REGS: c0391dd0 TRAP: 0300 Not tainted
> (2.6.17.1)
> MSR: 00021030 <ME,IR,DR> CR: 22028082 XER:
> 0000000B
> DAR: 00000000, DSISR:
> 00800000
> TASK = c0373030[4] 'events/0' THREAD:
> c0390000
> GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000
> C02CAC00
> GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900
> 007FFF3B
> GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002
> C0280000
> GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20
> C0E03000
> NIP [C00701C8]
> free_block+0x8c/0x138
> LR [C0070C18]
> drain_array+0xb8/0x124
> Call Trace:
>
> The setup:
> My own build system.
> Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace.
> Crosscompiled for PPC405.
> Latest, clean XSysAce code. mods: major hardcoded to = 125. Polled
> mode.
> CF: 3 partitions,
> 1: DOS FAT16
> 2: Ext2 main
> 3: Ext2 rescue
>
> This build boots up fine, mounts a ext2 as root fine. I can also
> mount the rescue partition with no problems.
>
> Does anyone have any pointers of where I should look for problems?
>
> My next step is to go and set it up for interrupt service and see if
> that changes anything.
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson@sanmina-sci.com
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for
> use by the addressee(s) named herein and may contain legally
> privileged and/or confidential information. If you are not the
> intended recipient of this e-mail message, you are hereby notified
> that any dissemination, distribution or copying of this e-mail
> message, and any attachments thereto, is strictly prohibited. If you
> have received this e-mail message in error, please immediately notify
> the sender and permanently delete the original and any copies of this
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
> Uniform Electronic Transactions Act or the applicability of any other
> law of similar substance and effect, absent an express statement to
> the contrary hereinabove, this e-mail message its contents, and any
> attachments hereto are not intended to represent an offer or
> acceptance to enter into a contract and are not otherwise intended to
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
> or any other person or entity.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 6824 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: Domen Puncer @ 2007-07-13 9:12 UTC (permalink / raw)
To: Russell King; +Cc: David Brownell, linuxppc-dev, Christoph Hellwig, linux-mips
In-Reply-To: <20070711203454.GC2301@flint.arm.linux.org.uk>
On 11/07/07 21:34 +0100, Russell King wrote:
> On Wed, Jul 11, 2007 at 10:02:54AM -0700, David Brownell wrote:
> > On Wednesday 11 July 2007, Christoph Hellwig wrote:
> > > On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > > > > Umm, this is about the fifth almost identical implementation of
> > > > > the clk_ functions. Please, please put it into common code.
> > > > >
> > > > > And talk to the mips folks which just got a similar comment from me.
> > > >
> > > > You mean like a lib/clock.c core, rather than an opsvector?
> > >
> > > I mean an ops vector and surrounding wrappers. Every architecture
> > > is reimplementing their own dispatch table which is rather annoying.
> >
> > ARM doesn't. :)
> >
> > But then, nobody expects one kernel to support more than one
> > vendor's ARM chips; or usually, more than one generation of
> > that vendor's chips. So any dispatch table is specific to
> > a given platform, and tuned to its quirks. Not much to share
> > between OMAP and AT91, for example, except in some cases maybe
> > an arm926ejs block.
>
> And also the information stored within a 'struct clk' is very platform
> dependent. In the most basic situation, 'struct clk' may not actually
> be a structure, but the clock rate. All functions with the exception of
> clk_get() and clk_get_rate() could well be no-ops, clk_get() just returns
> the 'struct clk' representing the rate and 'clk_get_rate' returns that
> as an integer.
>
> More complex setups might want 'struct clk' to contain the address of a
> clock enable register, the bit position to enable that clock source, the
> clock rate, a refcount, and so on, all of which would be utterly useless
> for a platform which had fixed rate clocks.
The patch that triggered this discussion is at the end.
It doesn't make any assumption on struct clk, it's just a
wrapper around functions from clk.h.
Point of this patch was to abstract exported functions, since
arch/powerpc/ can support multiple platfroms in one binary.
>
> > I've not seen a solid proposal for such a thing, and it's not
> > clear to me how that would play with with older code (e.g. any
> > of the ARM implementations).
>
> If people are implementing their own incompatible changes without reference
> to the API they're invalid implementations as far as I'm concerned. If
> they can't bothered to lift a finger to even _talk_ to me about their
> requirements they just don't have any say concerning any future
> developments IMO.
My changes were implemented according to clk.h API.
And honestly, I just wanted to rework clocks in some SPI driver and
others made me do all the clk work. ;-)
Domen
>
> IOW, talk to me and I'll talk back. Ignore me and I'll ignore them.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
clk interface for arch/powerpc, platforms should fill
clk_functions.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/kernel/Makefile | 3 -
arch/powerpc/kernel/clock.c | 82 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/clk_interface.h | 20 ++++++++
3 files changed, 104 insertions(+), 1 deletion(-)
Index: work-powerpc.git/arch/powerpc/kernel/clock.c
===================================================================
--- /dev/null
+++ work-powerpc.git/arch/powerpc/kernel/clock.c
@@ -0,0 +1,82 @@
+/*
+ * Dummy clk implementations for powerpc.
+ * These need to be overridden in platform code.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <asm/clk_interface.h>
+
+struct clk_interface clk_functions;
+
+struct clk *clk_get(struct device *dev, const char *id)
+{
+ if (clk_functions.clk_get)
+ return clk_functions.clk_get(dev, id);
+ return ERR_PTR(-ENOSYS);
+}
+EXPORT_SYMBOL(clk_get);
+
+void clk_put(struct clk *clk)
+{
+ if (clk_functions.clk_put)
+ clk_functions.clk_put(clk);
+}
+EXPORT_SYMBOL(clk_put);
+
+int clk_enable(struct clk *clk)
+{
+ if (clk_functions.clk_enable)
+ return clk_functions.clk_enable(clk);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_enable);
+
+void clk_disable(struct clk *clk)
+{
+ if (clk_functions.clk_disable)
+ clk_functions.clk_disable(clk);
+}
+EXPORT_SYMBOL(clk_disable);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+ if (clk_functions.clk_get_rate)
+ return clk_functions.clk_get_rate(clk);
+ return 0;
+}
+EXPORT_SYMBOL(clk_get_rate);
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+ if (clk_functions.clk_round_rate)
+ return clk_functions.clk_round_rate(clk, rate);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_round_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ if (clk_functions.clk_set_rate)
+ return clk_functions.clk_set_rate(clk, rate);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_set_rate);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+ if (clk_functions.clk_get_parent)
+ return clk_functions.clk_get_parent(clk);
+ return ERR_PTR(-ENOSYS);
+}
+EXPORT_SYMBOL(clk_get_parent);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ if (clk_functions.clk_set_parent)
+ return clk_functions.clk_set_parent(clk, parent);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_set_parent);
Index: work-powerpc.git/include/asm-powerpc/clk_interface.h
===================================================================
--- /dev/null
+++ work-powerpc.git/include/asm-powerpc/clk_interface.h
@@ -0,0 +1,20 @@
+#ifndef __ASM_POWERPC_CLK_INTERFACE_H
+#define __ASM_POWERPC_CLK_INTERFACE_H
+
+#include <linux/clk.h>
+
+struct clk_interface {
+ struct clk* (*clk_get) (struct device *dev, const char *id);
+ int (*clk_enable) (struct clk *clk);
+ void (*clk_disable) (struct clk *clk);
+ unsigned long (*clk_get_rate) (struct clk *clk);
+ void (*clk_put) (struct clk *clk);
+ long (*clk_round_rate) (struct clk *clk, unsigned long rate);
+ int (*clk_set_rate) (struct clk *clk, unsigned long rate);
+ int (*clk_set_parent) (struct clk *clk, struct clk *parent);
+ struct clk* (*clk_get_parent) (struct clk *clk);
+};
+
+extern struct clk_interface clk_functions;
+
+#endif /* __ASM_POWERPC_CLK_INTERFACE_H */
Index: work-powerpc.git/arch/powerpc/kernel/Makefile
===================================================================
--- work-powerpc.git.orig/arch/powerpc/kernel/Makefile
+++ work-powerpc.git/arch/powerpc/kernel/Makefile
@@ -12,7 +12,8 @@ endif
obj-y := semaphore.o cputable.o ptrace.o syscalls.o \
irq.o align.o signal_32.o pmc.o vdso.o \
- init_task.o process.o systbl.o idle.o
+ init_task.o process.o systbl.o idle.o \
+ clock.o
obj-y += vdso32/
obj-$(CONFIG_PPC64) += setup_64.o binfmt_elf32.o sys_ppc32.o \
signal_64.o ptrace32.o \
^ permalink raw reply
* Re: [PATCH] fix showing xmon help
From: Ishizaki Kou @ 2007-07-13 9:11 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1184284430.25007.5.camel@concordia.ozlabs.ibm.com>
> On Thu, 2007-07-12 at 16:59 +0900, Ishizaki Kou wrote:
> > In some configuration, xmon help string is larger than xmon output
> > buffer. To show whole help string, this patch splits it into 2
parts.
> >
> > Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
(snip)
> I'm not sure I like the fix though, it's a bit of a kludge :)
>
> We don't actually need to printf() the help string, so what'd be nicer
> is to add an xmon_puts() to arch/powerpc/xmon/nonstdio.c which just
> calls xmon_write(s, strlen(s)) and use that for printing the help
> string.
Thank you for your suggestion.
You're right. I'll send a new patch.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: Tickless Hz/hrtimers/etc. on PowerPC
From: Domen Puncer @ 2007-07-13 8:41 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <4696199B.3040105@genesi-usa.com>
On 12/07/07 13:07 +0100, Matt Sealey wrote:
> Domen,
>
> You wouldn't have tried these on the Efika yet, would you?
Not yet, but they worked on a mpc5200b based board (lite5200b).
Domen
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Domen Puncer wrote:
> > On 11/07/07 19:06 +0100, Matt Sealey wrote:
> >> Does anyone have the definitive patchset to enable the tickless hz,
> >> some kind of hrtimer and the other related improvements in the
> >> PowerPC tree?
> >
> > I use attached patches for tickless.
> > Order in which they're applied:
> >
> > PowerPC_GENERIC_CLOCKEVENTS.patch
> > PowerPC_GENERIC_TIME.linux-2.6.18-rc6_timeofday-arch-ppc_C6.patch
> > PowerPC_enable_HRT_and_dynticks_support.patch
> > PowerPC_no_hz_fix.patch
> > tickless-enable.patch
> >
> > HTH
> >
> >
> > Domen
^ permalink raw reply
* questions about mpc82xx_ads and porting to other, similar, platform
From: Alexandros Kostopoulos @ 2007-07-13 8:51 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I am trying to port kernel 2.6.22.1 to my own platform, which incorporat=
es =
an mpc8275 chip. I'm using platform code for mpc82xx_ads as a template (=
is =
this right in the first place?). I have a couple of questions:
1. mpc82xx_ads.c uses init_scc_ioports function to initialize the scc =
uarts. However, this function is only used by the code in
arch/powerpc/sysdev/fsl_soc.c, and spefically in fs_enet_of_init(), whic=
h =
is used to initialize the ethernet driver and not the cpm_uart driver.
On the other hand, cpm_uart_of_init() function seems to be the one that =
=
initializes the uarts in cpm, and actually makes use of the device-id, =
model, rx-clock and tx-clock properties of the scc nodes in OF tree. So,=
=
AFAICT, init_scc_ioports should not be there, since it won't be actually=
=
called at all (although I have not actually tested this - I haven't yet =
=
managed to boot the kernel). Instead, cpm_uart_of_init should take care =
of =
everything, except for the pport initialization, which is done in u-boot=
=
anyway (at least in my case). Any thoughts on this?
2. I have also some questions regarding the device tree. Why are there t=
wo =
nodes regarding the interrupt controller in there? and in the top level =
=
node, what does this property means: reg =3D <f8200000 f8200004>; ?
Finally, in the memory node, the reg property defines a second mem regio=
n, =
(f4500000 f4500020). What is this? maybe a special memory mapped =
peripheral of this board? If I have a board with many mem configurations=
=
(e.g. it uses a DIMM SDRAM what can be changed), what value should I pla=
ce =
in the mem node? I have to change dts every time I insert a new DIMM?
any help would be greatly appreciated,
thank you in advance
Alex
^ 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