* Re: netgear MA111 v2
From: Dustin Lang @ 2004-11-19 23:36 UTC (permalink / raw)
To: Isidoro Reyes de Zuloaga; +Cc: linuxppc-dev list
In-Reply-To: <200411192231.49831.isidoro@qassessorament.net>
Hi,
Disclaimer: I'm not an expert here, just someone with a working
wireless-USB device on linux-ppc.
>From a brief web search, it looks like the support for SiS162 is not
great. If a (good) driver doesn't exist, you're just out of luck, unless
you want to try to find specs for the chipset and then write something
yourself (or wait for someone else to do it). If you can, take it back
and buy a different adapter. There are several USB wireless devices that
work well. Look on the web for someone reporting that a given device
works, and make sure you get exactly the right revision. I have a Linksys
WUSB 11 (I forget which rev) and it works great.
Cheers,
dstn
> Hi!
> I just bought the wireless usb adapter of netgear. I bought this model because
> i read arround that i was working fine with linux. The problem now is that i
> bought the v2 model, with a sis chipset.
> Does anyone know how to fix this, or what to do.
> I downloaded the wlan-ng drivers, i compile them....
> Just wanna know some ideas.
> thanks in advance.
> isidoro
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Linux Kernel Memory map for MPC8280
From: Srivatsan @ 2004-11-20 9:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20041120010005.624B42BF11@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 13132 bytes --]
Is there any documentation which provided details about Linux Kernel
Memory map (before and after decompression - assumption is a compressed
Linux Kernel Image) with Ram Disk image, Root File system or can anybody
provide me some insight onto the Kernel Memory map (Not talking about
the process memory layout).
I am using PowerQuicc II processor.
With Best Regards,
C.R.Srivatsan
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
linuxppc-embedded-request@ozlabs.org
Sent: Saturday, November 20, 2004 6:30 AM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 3, Issue 30
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. [PATCH 2.6.10-rc2] ppc32: Have the 8260 board-hook happen a
bit later (Tom Rini)
2. [PATCH 2.6.10-rc2] ppc32: Fix __iomem warnings in TODC code
(Tom Rini)
3. [PATCH][PPC32] Marvell host bridge support (mv64x60)
(Mark A. Greer)
4. [PATCH][PPC32] Support for Marvell EV-64260[ab]-BP eval
platform (Mark A. Greer)
5. [PATCH][PPC32] Support for Artesyn Katana cPCI boards
(Mark A. Greer)
6. Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
(Andrew Morton)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Nov 2004 11:06:53 -0700
From: Tom Rini <trini@kernel.crashing.org>
Subject: [PATCH 2.6.10-rc2] ppc32: Have the 8260 board-hook happen a
bit later
To: Andrew Morton <akpm@osdl.org>, linuxppc-embedded@ozlabs.org
Cc: Borut Lukic <borutlukic@email.si>
Message-ID: <20041119180653.GF16043@smtp.west.cox.net>
Content-Type: text/plain; charset=us-ascii
Borut Lukic <borutlukic@email.si> brought to my attention that in
platform_init() on 8260 the board hook was being called too early to
allow for overrides (e.g. different memory sizings functions or rtc, or
anything else). This moves the call to the end of platform_init() and I
suspect fixes some unnoticed yet bugs in a number of 8260 platforms.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- 1.26/arch/ppc/syslib/m8260_setup.c 2004-08-24 08:31:20 -07:00
+++ edited/arch/ppc/syslib/m8260_setup.c 2004-11-19 11:03:35
-07:00
@@ -241,9 +241,6 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
- /* Call back for board-specific settings. */
- m82xx_board_init();
-
ppc_md.setup_arch = m8260_setup_arch;
ppc_md.show_cpuinfo = m8260_show_cpuinfo;
ppc_md.init_IRQ = m8260_init_IRQ;
@@ -259,4 +256,7 @@
ppc_md.find_end_of_memory = m8260_find_end_of_memory;
ppc_md.setup_io_mappings = m8260_map_io;
+
+ /* Call back for board-specific settings and overrides. */
+ m82xx_board_init();
}
--
Tom Rini
http://gate.crashing.org/~trini/
------------------------------
Message: 2
Date: Fri, 19 Nov 2004 11:15:25 -0700
From: Tom Rini <trini@kernel.crashing.org>
Subject: [PATCH 2.6.10-rc2] ppc32: Fix __iomem warnings in TODC code
To: Andrew Morton <akpm@osdl.org>, linuxppc-embedded@ozlabs.org
Message-ID: <20041119181525.GG16043@smtp.west.cox.net>
Content-Type: text/plain; charset=us-ascii
A trivial fix for the __iomem warnings in arch/ppc/syslib/todc_time.c
Signed-off-by: Randy Vinson <rvinson@mvista.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- a/arch/ppc/syslib/todc_time.c 2004-10-29 18:29:54.000000000
-0700
+++ b/arch/ppc/syslib/todc_time.c 2004-10-29 18:40:10.000000000
-0700
@@ -82,13 +82,13 @@ extern spinlock_t rtc_lock;
u_char
todc_direct_read_val(int addr)
{
- return readb(todc_info->nvram_data + addr);
+ return readb((void __iomem *)(todc_info->nvram_data + addr));
}
void
todc_direct_write_val(int addr, unsigned char val)
{
- writeb(val, todc_info->nvram_data + addr);
+ writeb(val, (void __iomem *)(todc_info->nvram_data + addr));
return;
}
--
Tom Rini
http://gate.crashing.org/~trini/
------------------------------
Message: 3
Date: Fri, 19 Nov 2004 14:43:28 -0700
From: "Mark A. Greer" <mgreer@mvista.com>
Subject: [PATCH][PPC32] Marvell host bridge support (mv64x60)
To: akpm <akpm@osdl.org>
Cc: lkml <linux-kernel@vger.kernel.org>, linuxppc-embedded@ozlabs.org
Message-ID: <419E6900.5070001@mvista.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This patch adds core support for a line of host bridges from Marvell
(formerly Galileo). This code has been tested with a GT64260a,
GT64260b, MV64360, and MV64460. Patches for platforms that use these
bridges will be sent separately.
The patch is rather large so a link is provided.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
ftp://source.mvista.com/pub/mgreer/mv64x60.patch
------------------------------
Message: 4
Date: Fri, 19 Nov 2004 14:49:04 -0700
From: "Mark A. Greer" <mgreer@mvista.com>
Subject: [PATCH][PPC32] Support for Marvell EV-64260[ab]-BP eval
platform
To: akpm <akpm@osdl.org>
Cc: lkml <linux-kernel@vger.kernel.org>, linuxppc-embedded@ozlabs.org
Message-ID: <419E6A50.5060107@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
This patch adds support for a line of evaluation platforms from Marvell
that use the Marvell GT64260[ab] host bridges.
This patch depends on the Marvell host bridge support patch (mv64x60).
This patch is larger than 40KB so a link is provided (as per
instructions in SubmittingPatches).
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
ftp://source.mvista.com/pub/mgreer/ev64260.patch
------------------------------
Message: 5
Date: Fri, 19 Nov 2004 15:29:59 -0700
From: "Mark A. Greer" <mgreer@mvista.com>
Subject: [PATCH][PPC32] Support for Artesyn Katana cPCI boards
To: akpm <akpm@osdl.org>
Cc: lkml <linux-kernel@vger.kernel.org>, linuxppc-embedded@ozlabs.org
Message-ID: <419E73E7.8080703@mvista.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This patch adds support for the Artesyn Katana 750i, 752i, and 3750.
This patch depends on the Marvell host bridge support patch (mv64x60)
[and the ev64260 platform support patch because the 2 patches touch the
same Makefiles and Kconfig file but there are no code dependencies].
Note that the patch itself does not depend on the previously submitted
MPSC driver but the platform does. That is, to use the serial ports on
those boards, the MPSC driver patch is required.
This patch is larger that 40KB so a link is provided (as per
instructions in SubmittingPatches).
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
ftp://source.mvista.com/pub/mgreer/katana.patch
------------------------------
Message: 6
Date: Fri, 19 Nov 2004 15:58:54 -0800
From: Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
To: "Mark A. Greer" <mgreer@mvista.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org
Message-ID: <20041119155854.02af2174.akpm@osdl.org>
Content-Type: text/plain; charset=US-ASCII
"Mark A. Greer" <mgreer@mvista.com> wrote:
>
> This patch adds core support for a line of host bridges from Marvell
> (formerly Galileo). This code has been tested with a GT64260a,
> GT64260b, MV64360, and MV64460. Patches for platforms that use these
> bridges will be sent separately.
>
Shouldn't these guys:
+ u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE
},
+ { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE
},
+ { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE
},
+ { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE
}
+ };
+ u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64360_MPSC2MEM_0_BASE,
MV64360_MPSC2MEM_0_SIZE },
+ { MV64360_MPSC2MEM_1_BASE,
MV64360_MPSC2MEM_1_SIZE },
+ { MV64360_MPSC2MEM_2_BASE,
MV64360_MPSC2MEM_2_SIZE },
+ { MV64360_MPSC2MEM_3_BASE,
MV64360_MPSC2MEM_3_SIZE }
+ };
+ u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb,
0x7 };
be static, and maybe __devinitdata? Right now, the CPU has to populate
them by hand at runtime.
+wait_for_ownership(int chan)
+{
+ int i;
+
+ for (i=0; i<MAX_TX_WAIT; i++) {
+ if ((MV64x60_REG_READ(sdma_regs[chan].sdcm) &
+ SDMA_SDCM_TXD) == 0)
+ break;
+
+ udelay(1000);
ow, big busywait. Can't use a sleep in here? I guess not :(
+ * arch/ppc/boot/simple/mv64x60_tty.c
hm. Normally we put arch-specific drivers like this into drivers/serial
and do the appropriate Kconfig work. Is there a reason why this serial
driver is buried under arch/ppc?
+#include "../../../../drivers/serial/mpsc_defs.h"
erk.
+struct mv64x60_rx_desc {
+ volatile u16 bufsize;
+ volatile u16 bytecnt;
+ volatile u32 cmd_stat;
+ volatile u32 next_desc_ptr;
+ volatile u32 buffer;
+};
+
+struct mv64x60_tx_desc {
+ volatile u16 bytecnt;
+ volatile u16 shadow;
+ volatile u32 cmd_stat;
+ volatile u32 next_desc_ptr;
+ volatile u32 buffer;
+};
Do these need to be volatile? If so, it indicates that the driver is
doing
something wrong.
+gt64260_register_hdlrs(void)
+{
+ /* Register CPU interface error interrupt handler */
+ request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler,
+ SA_INTERRUPT, CPU_INTR_STR, 0);
request_irq() can fail.
+int
+mv64360_get_irq(struct pt_regs *regs)
+{
+ int irq;
+ int irq_gpp;
+
+#ifdef CONFIG_SMP
+ /*
+ * Second CPU gets only doorbell (message) interrupts.
+ * The doorbell interrupt is BIT28 in the main interrupt low
cause reg.
+ */
+ int cpu_nr = smp_processor_id();
This function has no callers, so I am unable to determine whether it is
called from non-preemptible code. If it is called from preemptible code
then that smp_processor_id() is buggy, because you can switch CPUs at
any
time.
+static struct platform_device mpsc_shared_device = { /* Shared device
*/
+ .name = MPSC_SHARED_NAME,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources),
+ .resource = mv64x60_mpsc_shared_resources,
+ .dev = {
+ .driver_data = (void *)&mv64x60_mpsc_shared_pd_dd,
+ },
+};
The cast to void* is unnecessary.
+ (void)mv64x60_setup_for_chip(&bh);
how come you always stick that (void) in there?
+mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh,
+ struct mv64x60_setup_info *si,
+ u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
+{
+ u32 i, win;
+ u32 prot_tab[] = {
+ MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
+ MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
+ };
+ u32 cpu_snoop_tab[] = {
+ MV64x60_CPU_SNOOP_0_WIN,
MV64x60_CPU_SNOOP_1_WIN,
+ MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN
+ };
static initialisation?
+mv64x60_config_cpu2pci_windows(struct mv64x60_handle *bh,
+ struct mv64x60_pci_info *pi, u32 bus)
+{
+ int i;
+ u32 win_tab[2][4] = {
+ { MV64x60_CPU2PCI0_IO_WIN,
MV64x60_CPU2PCI0_MEM_0_WIN,
+ MV64x60_CPU2PCI0_MEM_1_WIN,
+ MV64x60_CPU2PCI0_MEM_2_WIN },
+ { MV64x60_CPU2PCI1_IO_WIN,
MV64x60_CPU2PCI1_MEM_0_WIN,
+ MV64x60_CPU2PCI1_MEM_1_WIN,
+ MV64x60_CPU2PCI1_MEM_2_WIN },
+ };
+ u32 remap_tab[2][4] = {
+ { MV64x60_CPU2PCI0_IO_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_0_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_1_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_2_REMAP_WIN },
+ { MV64x60_CPU2PCI1_IO_REMAP_WIN,
+ MV64x60_CPU2PCI1_MEM_0_REMAP_WIN,
+ MV64x60_CPU2PCI1_MEM_1_REMAP_WIN,
+ MV64x60_CPU2PCI1_MEM_2_REMAP_WIN }
+ };
+
ditto
+mv64x60_config_pci2mem_windows(struct mv64x60_handle *bh,
and here
+mv64360_set_pci2mem_window(struct pci_controller *hose, u32 bus, u32
window,
and here
+mv64360_config_io2mem_windows(struct mv64x60_handle *bh,
and here
Anyway, I'll stick this as-is in -mm. Feel free to send an incremental
patch, or a replacement.
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 3, Issue 30
************************************************
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
^ permalink raw reply
* Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Christoph Hellwig @ 2004-11-20 16:26 UTC (permalink / raw)
To: Mark A. Greer; +Cc: akpm, lkml, linuxppc-embedded
In-Reply-To: <419E6900.5070001@mvista.com>
Just looking through this and you should share some more code with mips,
e.g. the mavell register layout should move from asm-mips/marvell.h and
your file to linux/marvell.h or something, especially as another ppc
plattform (pegasosII) needs it aswell.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Sean Neakums @ 2004-11-20 21:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
> http://gate.crashing.org/~benh/albook-ibookg4-sleep-2.diff
I tried this on my 15" AlBook (one of the new 1.5GHz ones), applied to
Debian's 2.6.9. It suspended and resumed fine (and quickly!), but
after resume I noticed that images (in Mozilla and the root window)
would become corrupted if obscured and made visible again, e.g. by
switching tabs, or by moving between a full and an empty workspace.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Armando Di Cianno @ 2004-11-20 22:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <6ubrdsjiq1.fsf@zork.zork.net>
[-- Attachment #1.1: Type: text/plain, Size: 811 bytes --]
On 2004-11-20 16:47:34 -0500 Sean Neakums <sneakums@zork.net> wrote:
> I tried this on my 15" AlBook (one of the new 1.5GHz ones), applied to
> Debian's 2.6.9. It suspended and resumed fine (and quickly!), but
> after resume I noticed that images (in Mozilla and the root window)
> would become corrupted if obscured and made visible again, e.g. by
> switching tabs, or by moving between a full and an empty workspace.
Just a note that I tried this with gentoo's
gentoo-dev-sources-2.6.9-r3 and discovered the exact some symptoms.
It mainly only seems to have corrupted the X root window, although
some, but not all, images in a web page in firefox show similar
distortions. Currently my system is running XOrg 6.7.0. I did not
notice this problem with the first patch for sleep.
__Armando Di Cianno
[-- Attachment #1.2: RFC3156.txt --]
[-- Type: text/plain, Size: 65 bytes --]
RFC3156 defines security multipart formats for MIME with OpenPGP.
[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-20 22:22 UTC (permalink / raw)
To: Sean Neakums; +Cc: linuxppc-dev list
In-Reply-To: <6ubrdsjiq1.fsf@zork.zork.net>
On Sat, 2004-11-20 at 21:47 +0000, Sean Neakums wrote:
> > http://gate.crashing.org/~benh/albook-ibookg4-sleep-2.diff
>
> I tried this on my 15" AlBook (one of the new 1.5GHz ones), applied to
> Debian's 2.6.9. It suspended and resumed fine (and quickly!), but
> after resume I noticed that images (in Mozilla and the root window)
> would become corrupted if obscured and made visible again, e.g. by
> switching tabs, or by moving between a full and an empty workspace.
Do you have APM emulation enabled in the kenrel config and do you
have /dev/apm_bios ? (check in X log that it properly opens the APM
device and gets notified of suspend and resume events).
Ben.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Michel Dänzer @ 2004-11-20 22:20 UTC (permalink / raw)
To: Armando Di Cianno; +Cc: linuxppc-dev
In-Reply-To: <e40ed3e4cb162b693ee83310e34b9a3d@nephiliah>
On Sat, 2004-11-20 at 17:08 -0500, Armando Di Cianno wrote:
> On 2004-11-20 16:47:34 -0500 Sean Neakums <sneakums@zork.net> wrote:
> > I tried this on my 15" AlBook (one of the new 1.5GHz ones), applied to
> > Debian's 2.6.9. It suspended and resumed fine (and quickly!), but
> > after resume I noticed that images (in Mozilla and the root window)
> > would become corrupted if obscured and made visible again, e.g. by
> > switching tabs, or by moving between a full and an empty workspace.
>=20
> Just a note that I tried this with gentoo's=20
> gentoo-dev-sources-2.6.9-r3 and discovered the exact some symptoms. =20
> It mainly only seems to have corrupted the X root window, although=20
> some, but not all, images in a web page in firefox show similar=20
> distortions. Currently my system is running XOrg 6.7.0. I did not=20
> notice this problem with the first patch for sleep.
Sounds like the offscreen pixmap cache gets corrupted. The usual
question for this kind of problem: Does
grep APM /var/log/X{Free86,org}.0.log
show
(II) Open APM successful
?
--=20
Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop=
er
Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Armando Di Cianno @ 2004-11-20 22:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1100989339.3795.6.camel@gaston>
[-- Attachment #1.1: Type: text/plain, Size: 1072 bytes --]
On 2004-11-20 17:22:19 -0500 Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Do you have APM emulation enabled in the kenrel config and do you
> have /dev/apm_bios ? (check in X log that it properly opens the APM
> device and gets notified of suspend and resume events).
Michel Daenzer wrote:
> Sounds like the offscreen pixmap cache gets corrupted. The usual
> question for this kind of problem: Does
> grep APM /var/log/X{Free86,org}.0.log
> show
> (II) Open APM successful
nephiliah root # grep -i apm /usr/src/linux/.config
CONFIG_PMAC_APM_EMU=y
nephiliah root # grep APM /var/log/Xorg.0.log
(II) Open APM successful
(II) Open APM successful
Eyeballing the Xorg.0.log doesn't show any apm irregularities. (I
suspect the second "Open APM..." comes from when I just resumed.)
nephiliah root # ls -l /dev/apm_bios
lr-xr-xr-x 1 root root 13 Nov 19 19:57 /dev/apm_bios -> misc/apm_bios
nephiliah root # ls -l /dev/misc/apm_bios
crw------- 1 armando root 10, 134 Dec 31 1969 /dev/misc/apm_bios
Any other info I can offer to help?
__Armando Di Cianno
[-- Attachment #1.2: RFC3156.txt --]
[-- Type: text/plain, Size: 65 bytes --]
RFC3156 defines security multipart formats for MIME with OpenPGP.
[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Sean Neakums @ 2004-11-20 22:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1100989339.3795.6.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sat, 2004-11-20 at 21:47 +0000, Sean Neakums wrote:
>> > http://gate.crashing.org/~benh/albook-ibookg4-sleep-2.diff
>>
>> I tried this on my 15" AlBook (one of the new 1.5GHz ones), applied to
>> Debian's 2.6.9. It suspended and resumed fine (and quickly!), but
>> after resume I noticed that images (in Mozilla and the root window)
>> would become corrupted if obscured and made visible again, e.g. by
>> switching tabs, or by moving between a full and an empty workspace.
>
> Do you have APM emulation enabled in the kenrel config and do you
> have /dev/apm_bios ? (check in X log that it properly opens the APM
> device and gets notified of suspend and resume events).
It was built modular but not loaded, and /dev/apm_bios was present.
Having exited X, loaded the module and restarted X, I tried
suspend/resume again. It worked well as before, but the corruption is
still present. In XFree86.0.log, I now see a "(II) Open APM
successful" instead of "(WW) Open APM failed (/dev/apm_bios) (No such
device) ", but nothing that seems to relate to suspend/resume events.
The corruption doesn't appear immediately; it starts as a light
specking of the image and progressively getting worse with subsequent
redisplayings.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Sean Neakums @ 2004-11-20 22:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <6u7jogjg8t.fsf@zork.zork.net>
Sean Neakums <sneakums@zork.net> writes:
> The corruption doesn't appear immediately; it starts as a light
> specking of the image and progressively getting worse with subsequent
> redisplayings.
Also, restarting X does not get rid of the corruption.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-20 22:52 UTC (permalink / raw)
To: Sean Neakums; +Cc: linuxppc-dev list
In-Reply-To: <6u7jogjg8t.fsf@zork.zork.net>
On Sat, 2004-11-20 at 22:41 +0000, Sean Neakums wrote:
> It was built modular but not loaded, and /dev/apm_bios was present.
> Having exited X, loaded the module and restarted X, I tried
> suspend/resume again. It worked well as before, but the corruption is
> still present. In XFree86.0.log, I now see a "(II) Open APM
> successful" instead of "(WW) Open APM failed (/dev/apm_bios) (No such
> device) ", but nothing that seems to relate to suspend/resume events.
>
> The corruption doesn't appear immediately; it starts as a light
> specking of the image and progressively getting worse with subsequent
> redisplayings.
No idea at this point. It doesn't happen on the albooks I could test
with here... Can you send me a snapshot of a corrupted screen ? Does
it still happen if you disable dynamic clocks ?
(radeonfb.default_dynclk=-1 on the kernel cmdline and Option
"DynamicClocks" "false" in X if you are using X.org). And if you disable
accel in X ? (Option "NoAccel" "true")
Ben.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Sean Neakums @ 2004-11-20 23:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1100991146.3795.17.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sat, 2004-11-20 at 22:41 +0000, Sean Neakums wrote:
>
>> It was built modular but not loaded, and /dev/apm_bios was present.
>> Having exited X, loaded the module and restarted X, I tried
>> suspend/resume again. It worked well as before, but the corruption is
>> still present. In XFree86.0.log, I now see a "(II) Open APM
>> successful" instead of "(WW) Open APM failed (/dev/apm_bios) (No such
>> device) ", but nothing that seems to relate to suspend/resume events.
>>
>> The corruption doesn't appear immediately; it starts as a light
>> specking of the image and progressively getting worse with subsequent
>> redisplayings.
>
> No idea at this point. It doesn't happen on the albooks I could test
> with here... Can you send me a snapshot of a corrupted screen ?
Here is a (rather large) screen shot I took, showing the corrupted
root window image.
http://dasbistro.com/~sneakums/corruption.png
> Does it still happen if you disable dynamic clocks ?
> (radeonfb.default_dynclk=-1 on the kernel cmdline and Option
> "DynamicClocks" "false" in X if you are using X.org). And if you
> disable accel in X ? (Option "NoAccel" "true")
I'll try these out.
^ permalink raw reply
* [PATCH] ppc32: Fix an IRQ issue with cpufreq
From: Benjamin Herrenschmidt @ 2004-11-20 23:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Hi !
The ppc32 PowerMac cpufreq code, when using the PMU to switch the frequency,
would eventually lose interrupts. The solution is to raise the CPU priority
at the controller level. It's also unnecessary to call the full PIC
suspend/resume code in this case as the IO chip isn't reset, unlike the
sleep code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/include/asm-ppc/open_pic.h
===================================================================
--- linux-work.orig/include/asm-ppc/open_pic.h 2004-11-09 14:03:51.000000000 +1100
+++ linux-work/include/asm-ppc/open_pic.h 2004-11-21 10:05:17.885389728 +1100
@@ -55,6 +55,7 @@
extern void smp_openpic_message_pass(int target, int msg, unsigned long data,
int wait);
extern void openpic_set_k2_cascade(int irq);
+extern void openpic_set_priority(u_int pri);
extern inline int openpic_to_irq(int irq)
{
Index: linux-work/arch/ppc/syslib/open_pic.c
===================================================================
--- linux-work.orig/arch/ppc/syslib/open_pic.c 2004-11-09 14:03:50.000000000 +1100
+++ linux-work/arch/ppc/syslib/open_pic.c 2004-11-21 10:05:17.888389272 +1100
@@ -53,7 +53,6 @@
/* Global Operations */
static void openpic_disable_8259_pass_through(void);
-static void openpic_set_priority(u_int pri);
static void openpic_set_spurious(u_int vector);
#ifdef CONFIG_SMP
@@ -477,7 +476,7 @@
}
#endif /* notused */
-static void __init openpic_set_priority(u_int pri)
+void openpic_set_priority(u_int pri)
{
DECL_THIS_CPU;
@@ -955,6 +954,8 @@
return 0;
}
+ openpic_set_priority(0xf);
+
open_pic.enable = openpic_cached_enable_irq;
open_pic.disable = openpic_cached_disable_irq;
@@ -1028,6 +1029,8 @@
open_pic.enable = openpic_enable_irq;
open_pic.disable = openpic_disable_irq;
+ openpic_set_priority(0);
+
spin_unlock_irqrestore(&openpic_setup_lock, flags);
return 0;
Index: linux-work/arch/ppc/platforms/pmac_cpufreq.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cpufreq.c 2004-10-23 08:45:23.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_cpufreq.c 2004-11-21 10:05:17.889389120 +1100
@@ -33,6 +33,8 @@
#include <asm/sections.h>
#include <asm/cputable.h>
#include <asm/time.h>
+#include <asm/system.h>
+#include <asm/open_pic.h>
/* WARNING !!! This will cause calibrate_delay() to be called,
* but this is an __init function ! So you MUST go edit
@@ -51,10 +53,6 @@
extern void low_choose_7447a_dfs(int dfs);
extern void low_choose_750fx_pll(int pll);
extern void low_sleep_handler(void);
-extern void openpic_suspend(struct sys_device *sysdev, u32 state);
-extern void openpic_resume(struct sys_device *sysdev);
-extern void enable_kernel_altivec(void);
-extern void enable_kernel_fp(void);
/*
* Currently, PowerMac cpufreq supports only high & low frequencies
@@ -208,7 +206,7 @@
printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
#endif
/* Disable all interrupt sources on openpic */
- openpic_suspend(NULL, 1);
+ openpic_set_priority(0xf);
/* Make sure the decrementer won't interrupt us */
asm volatile("mtdec %0" : : "r" (0x7fffffff));
@@ -275,7 +273,7 @@
wakeup_decrementer();
/* Restore interrupts */
- openpic_resume(NULL);
+ openpic_set_priority(0);
/* Let interrupts flow again ... */
local_irq_enable();
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Sean Neakums @ 2004-11-20 23:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <6uy8gwi0qz.fsf@zork.zork.net>
Sean Neakums <sneakums@zork.net> writes:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> Does it still happen if you disable dynamic clocks ?
>> (radeonfb.default_dynclk=-1 on the kernel cmdline and Option
>> "DynamicClocks" "false" in X if you are using X.org). And if you
>> disable accel in X ? (Option "NoAccel" "true")
>
> I'll try these out.
With radeonfb.default_dynclk=-1 alone (using Debian's XFree86 4.3.0,
so no Option "DynamicClocks" "false"), the corruption is slower to
progress, but seems to be the same as the corruption seen with dynamic
clocks enabled.
With NoAccel alone, I do not yet see any corruption; I would expect to
have seen it by now, going by the previous tests.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-21 0:01 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list; +Cc: gentoo-ppc-user
In-Reply-To: <1100852423.3855.2.camel@gaston>
On Fri, 2004-11-19 at 19:20 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2004-11-19 at 17:56 +1100, Benjamin Herrenschmidt wrote:
> > So here's the new patch, it replaces the previous one for Aluminium
> > PowerBooks, and is still against 2.6.9. I'll do something against 2.6.10
> > when that one is out (it's a bit late to get that merged with Linus,
> > 2.6.10 is in freeze mode now) and I hope to get all of that in 2.6.11.
> >
> > .../...
>
> Ok, I already found a bug, occasional lockups on boot and when setting
> the backlight. I uploaded a new version at:
Here's a 3rd version. It may or may not help, as I didn't have a chance
to test this one on either albook or ibook g4 yet. I added saving and
restoring of a few more registers that may fix the Xv problem (or not...
depends what X does at this point) and eventually some corruption
problem (the bandwidth related registers weren't restored).
It also adds an unrelated fix to the cpufreq code for powerbooks using
PMU-based frequency switching which would occasionally cause hangs at
boot.
http://gate.crashing.org/~benh/albook-ibookg4-sleep-3.diff
Ben.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Armando Di Cianno @ 2004-11-21 3:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1100995268.3796.39.camel@gaston>
On 2004-11-20 19:01:08 -0500 Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Here's a 3rd version. It may or may not help, as I didn't have a
> chance
> to test this one on either albook or ibook g4 yet. I added saving and
> restoring of a few more registers that may fix the Xv problem (or
> not...
> depends what X does at this point) and eventually some corruption
> problem (the bandwidth related registers weren't restored).
>
> It also adds an unrelated fix to the cpufreq code for powerbooks using
> PMU-based frequency switching which would occasionally cause hangs at
> boot.
Using 'NoAccel' in xorg.conf seems to hide the symptoms of the bug, or
remove the bug.
However, without that option, with this patch, the problem seems "less
bad", if that's even possible. It takes longer for the root window to
get "ridiculously speckled." Not sure if that info helps at all. :-)
Not sure if I mentioned that, the first patch (the one sent a couple
weeks ago) did not seem to have this problem.
Thanks,
__Armando Di Cianno
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-21 7:11 UTC (permalink / raw)
To: Armando Di Cianno; +Cc: linuxppc-dev list
In-Reply-To: <2101489e3424befc4c73bd04bbebaa25@nephiliah>
On Sat, 2004-11-20 at 22:00 -0500, Armando Di Cianno wrote:
> Using 'NoAccel' in xorg.conf seems to hide the symptoms of the bug, or
> remove the bug.
>
> However, without that option, with this patch, the problem seems "less
> bad", if that's even possible. It takes longer for the root window to
> get "ridiculously speckled." Not sure if that info helps at all. :-)
>
> Not sure if I mentioned that, the first patch (the one sent a couple
> weeks ago) did not seem to have this problem.
Yes, you did mention it, which is weird. I'll have to spend some time
comparing the 2 versions and see if I can spot something.
Ben
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: David Woodhouse @ 2004-11-21 19:34 UTC (permalink / raw)
To: Sean Neakums; +Cc: linuxppc-dev
In-Reply-To: <6ubrdsjiq1.fsf@zork.zork.net>
On Sat, 2004-11-20 at 21:47 +0000, Sean Neakums wrote:
> > http://gate.crashing.org/~benh/albook-ibookg4-sleep-2.diff
>
> I tried this on my 15" AlBook (one of the new 1.5GHz ones), applied to
> Debian's 2.6.9. It suspended and resumed fine (and quickly!), but
> after resume I noticed that images (in Mozilla and the root window)
> would become corrupted if obscured and made visible again, e.g. by
> switching tabs, or by moving between a full and an empty workspace.
I've seen similar behaviour in firefox on a 17" AlBook with Fedora Core
3. I can't remember if it was with Ben's first or second patch. Neither
can I reproduce it now with the second version.
--
dwmw2
^ permalink raw reply
* Re: Lite5200 FEC Driver on linux 2.6 broken? (fixed again)
From: Sylvain Munaut @ 2004-11-21 16:10 UTC (permalink / raw)
To: roger blofeld; +Cc: linuxppc-embedded
In-Reply-To: <20041119145354.59388.qmail@web53507.mail.yahoo.com>
roger blofeld wrote:
>>What tree are you exactly using ?
>>In mainstream XLB snooping is not configured so if you have the
>>mainstream + added DMA,
>>the problem may come from this.
>>
>>
>> Sylvain
>>
>>
>
>I did a bk clone of the linux-2.5 tree (2.6.10-rc2), then a bk pull of
>your tree. You're probably right about the snooping. Since the driver
>is working at the moment, I'll wait until your tree is updated before
>doing more testing.
>Thanks
>-rb
>
>
Wow, that must have led to a bunch of conflicts no ?
Now, it's more up-to-date and cloning mainstream and pulling should be ok.
Note that my tree is now :
bk://bkbits.246tNt.com/linux-2.5-mpc52xx
(no -devel, I merged the two in only one)
The flush_dcache_range is not present because if it still fails I'd like
to understand why.
I should not be needed or maybe I'm missing something. If still doesn't
work, I'll
add it with a note.
Sylvain
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Olof Johansson @ 2004-11-19 19:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1100847411.25521.42.camel@gaston>
On Fri, Nov 19, 2004 at 05:56:50PM +1100, Benjamin Herrenschmidt wrote:
> So here's the new patch, it replaces the previous one for Aluminium
> PowerBooks, and is still against 2.6.9. I'll do something against 2.6.10
> when that one is out (it's a bit late to get that merged with Linus,
> 2.6.10 is in freeze mode now) and I hope to get all of that in 2.6.11.
Seems to work well on my 1.2GHz 12" iBook. First attempt caused a
failure while I had the WUSB12 adapter plugged in (after reboot when the
device was reinitialized the keyboard stopped working and the mouse went
crazy). If I unplug the adapter before sleep, it seems to wakeup without
problem.
No observed problems with backlight or anything else either, but I
haven't been stress testing anything.
Good work, Ben! I owe you a beer next time you're in Austin! :)
-Olof
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Olof Johansson @ 2004-11-21 17:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1100995268.3796.39.camel@gaston>
On Sun, Nov 21, 2004 at 11:01:08AM +1100, Benjamin Herrenschmidt wrote:
> > Ok, I already found a bug, occasional lockups on boot and when setting
> > the backlight. I uploaded a new version at:
>
> Here's a 3rd version. It may or may not help, as I didn't have a chance
> to test this one on either albook or ibook g4 yet. I added saving and
> restoring of a few more registers that may fix the Xv problem (or not...
> depends what X does at this point) and eventually some corruption
> problem (the bandwidth related registers weren't restored).
This one caused problems for me. Looks like the backlight got turned off
at boot, I had to sleep it and wake it up to get it back.
-Olof
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-21 21:36 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20041121173711.GA5692@austin.ibm.com>
On Sun, 2004-11-21 at 11:37 -0600, Olof Johansson wrote:
> On Sun, Nov 21, 2004 at 11:01:08AM +1100, Benjamin Herrenschmidt wrote:
> > > Ok, I already found a bug, occasional lockups on boot and when setting
> > > the backlight. I uploaded a new version at:
> >
> > Here's a 3rd version. It may or may not help, as I didn't have a chance
> > to test this one on either albook or ibook g4 yet. I added saving and
> > restoring of a few more registers that may fix the Xv problem (or not...
> > depends what X does at this point) and eventually some corruption
> > problem (the bandwidth related registers weren't restored).
>
> This one caused problems for me. Looks like the backlight got turned off
> at boot, I had to sleep it and wake it up to get it back.
There have been no change regarding backlight at boot, could just be
some latent problem... Next time it happens, test what happens if turn
the backlight all the way down to 0 (with the backlight keys), wait a
bit, then back up.
Ben.
^ permalink raw reply
* TEST: Sleep patch #4
From: Benjamin Herrenschmidt @ 2004-11-22 0:32 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list; +Cc: gentoo-ppc-user
In-Reply-To: <1100852423.3855.2.camel@gaston>
Ok, here's the 4th iteration of the patch. It includes John Steele Scott fixes for
cpufreq and the sound driver and fixes a problem where memory refresh wouldn't properly
be re-enabled on the video chip upon wakeup. I also cleaned a bit more the MDLL reset
code for r300, plus a couple of other things.
http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff
Ben.
^ permalink raw reply
* Re: TEST: Sleep patch #4
From: Armando Di Cianno @ 2004-11-22 3:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, gentoo-ppc-user
In-Reply-To: <1101083578.13597.5.camel@gaston>
On 2004-11-21 19:32:58 -0500 Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Ok, here's the 4th iteration of the patch. It includes John Steele
> Scott
> fixes for
> cpufreq and the sound driver and fixes a problem where memory refresh
> wouldn't properly
> be re-enabled on the video chip upon wakeup. I also cleaned a bit
> more the
> MDLL reset
> code for r300, plus a couple of other things.
Tested the 4th version of this patch, and things do seem to be working
as expected on the AluBook I have (1.5Ghz, 15'').
Once again, Ben: you rock! :-)
__Armando Di Cianno
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: David Woodhouse @ 2004-11-22 8:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20041121173711.GA5692@austin.ibm.com>
On Sun, 2004-11-21 at 11:37 -0600, Olof Johansson wrote:
> On Sun, Nov 21, 2004 at 11:01:08AM +1100, Benjamin Herrenschmidt wrote:
> > > Ok, I already found a bug, occasional lockups on boot and when setting
> > > the backlight. I uploaded a new version at:
> >
> > Here's a 3rd version. It may or may not help, as I didn't have a chance
> > to test this one on either albook or ibook g4 yet. I added saving and
> > restoring of a few more registers that may fix the Xv problem (or not...
> > depends what X does at this point) and eventually some corruption
> > problem (the bandwidth related registers weren't restored).
>
> This one caused problems for me. Looks like the backlight got turned off
> at boot, I had to sleep it and wake it up to get it back.
I've seen that since the first version. I also have to restart
pbbuttonsd to make it work again after sleep. I keep logging in on tty1
to run 'fblevel 15'.
Actually the backlight tends to turn off some time later, too. It's not
just that it's off after sleep.
--
dwmw2
^ 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