* 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
* Re: [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Andrew Morton @ 2004-11-19 23:58 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <419E6900.5070001@mvista.com>
"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.
^ permalink raw reply
* netgear MA111 v2
From: Isidoro Reyes de Zuloaga @ 2004-11-19 21:31 UTC (permalink / raw)
To: linuxppc-dev list
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
^ permalink raw reply
* [PATCH][PPC32] Support for Artesyn Katana cPCI boards
From: Mark A. Greer @ 2004-11-19 22:29 UTC (permalink / raw)
To: akpm; +Cc: lkml, linuxppc-embedded
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
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-19 22:14 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev list
In-Reply-To: <20041119110609.GA2924@iram.es>
On Fri, 2004-11-19 at 12:06 +0100, Gabriel Paubert wrote:
> On Fri, Nov 19, 2004 at 05:56:50PM +1100, Benjamin Herrenschmidt wrote:
> > NOTE: Owners of _OTHER_ Apple laptops that could already sleep, like
> > earlier iBooks, or Titanium PowerBooks, please test this patch as well
> > for regression. More specifically, test if sleep still works, X/DRI, and
> > backlight control as I have made significant changes to radeonfb in ways
> > that could affect those areas.
>
> Everytime my Pismo wakes up I have the following:
>
> Badness in enable_irq at kernel/irq/manage.c:106
.../...
Yah, it's known, and harmless, just didn't find the time to fix it yet,
thanks for the patch. It's due to a change in the main OHCI code which
nowadaws frees and re-requests the interrupt on sleep.
Ben.
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-19 22:10 UTC (permalink / raw)
To: linuxppc-dev list
> 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:
http://gate.crashing.org/~benh/albook-ibookg4-sleep-2.diff
Ben.
^ permalink raw reply
* [PATCH][PPC32] Support for Marvell EV-64260[ab]-BP eval platform
From: Mark A. Greer @ 2004-11-19 21:49 UTC (permalink / raw)
To: akpm; +Cc: lkml, linuxppc-embedded
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
^ permalink raw reply
* [PATCH][PPC32] Marvell host bridge support (mv64x60)
From: Mark A. Greer @ 2004-11-19 21:43 UTC (permalink / raw)
To: akpm; +Cc: lkml, linuxppc-embedded
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
^ permalink raw reply
* [PATCH 2.6.10-rc2] ppc32: Fix __iomem warnings in TODC code
From: Tom Rini @ 2004-11-19 18:15 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
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/
^ permalink raw reply
* [PATCH 2.6.10-rc2] ppc32: Have the 8260 board-hook happen a bit later
From: Tom Rini @ 2004-11-19 18:06 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded; +Cc: Borut Lukic
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/
^ permalink raw reply
* [PATCH 2.6.10-rc2] ppc32: Update IBM EMAC copyright / emails
From: Tom Rini @ 2004-11-19 16:43 UTC (permalink / raw)
To: linuxppc-embedded
The following does 3 things:
- Shorten the GPL notice in all of the IBM EMAC driver files
- Generally put Matt Porter on the hook as maintainer, and remove Armin
Kuster and Johnnie Peters email addrs.
- Fix a typo Wolfgang Denk pointed out to me privately (MontaVista
Softare).
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- 1.2/drivers/net/ibm_emac/ibm_emac.h 2004-08-04 08:41:48 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac.h 2004-11-19 09:28:41 -07:00
@@ -1,16 +1,13 @@
/*
- * ibm_emac.h
+ * drivers/net/ibm_emac/ibm_emac.h
*
+ * Author: Armin Kuster <source@mvista.com>
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
*
- * Armin Kuster akuster@mvista.com
- * June, 2002
- *
- * Copyright 2002 MontaVista Softare Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2002 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#ifndef _IBM_EMAC_H_
--- 1.4/drivers/net/ibm_emac/ibm_emac_core.c 2004-10-20 01:37:15 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2004-11-19 09:30:15 -07:00
@@ -3,18 +3,18 @@
*
* Ethernet driver for the built in ethernet on the IBM 4xx PowerPC
* processors.
- *
- * (c) 2003 Benjamin Herrenschmidt <benh@kernel.crashing.org>
*
- * Based on original work by
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
+ *
+ * Based on original work by Armin Kuster and Johnnie Peters
+ * <source@mvista.com>
*
- * Armin Kuster <akuster@mvista.com>
- * Johnnie Peters <jpeters@mvista.com>
+ * 2002 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ * (c) 2003 Benjamin Herrenschmidt <benh@kernel.crashing.org>
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
* TODO
* - Check for races in the "remove" code path
* - Add some Power Management to the MAC and the PHY
--- 1.2/drivers/net/ibm_emac/ibm_emac_core.h 2004-08-05 07:26:55 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_core.h 2004-11-19 09:31:10 -07:00
@@ -1,22 +1,16 @@
/*
- * ibm_emac_core.h
+ * drivers/net/ibm_emac/ibm_emac_core.h
*
* Ethernet driver for the built in ethernet on the IBM 405 PowerPC
* processor.
*
- * Armin Kuster akuster@mvista.com
- * Sept, 2001
+ * Authors: Armin Kuster and Johnnie Peters <source@mvista.com>
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
*
- * Orignial driver
- * Johnnie Peters
- * jpeters@mvista.com
- *
- * Copyright 2000 MontaVista Softare Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2000-2001 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#ifndef _IBM_EMAC_CORE_H_
--- 1.1/drivers/net/ibm_emac/ibm_emac_debug.c 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_debug.c 2004-11-19 09:31:52 -07:00
@@ -1,17 +1,15 @@
/*
- * ibm_ocp_debug.c
+ * drivers/net/ibm_emac/ibm_ocp_debug.c
*
- * This has all the debug routines that where in *_enet.c
+ * Debug rountines for the IBM EMAC driver.
*
- * Armin Kuster akuster@mvista.com
- * April , 2002
+ * Authors: Armin Kuster <source@mvista.com>
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
*
- * Copyright 2002 MontaVista Softare Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2002 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#include <linux/config.h>
--- 1.2/drivers/net/ibm_emac/ibm_emac_mal.c 2004-09-07 23:33:14 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_mal.c 2004-11-19 09:32:08 -07:00
@@ -1,15 +1,13 @@
/*
- * ibm_ocp_mal.c
+ * drivers/net/ibm_emac/ibm_ocp_mal.c
*
- * Armin Kuster akuster@mvista.com
- * Juen, 2002
+ * Authors: Armin Kuster <source@mvista.com>
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
*
- * Copyright 2002 MontaVista Softare Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2002 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#include <linux/config.h>
--- 1.1/drivers/net/ibm_emac/ibm_emac_phy.h 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_phy.h 2004-11-19 09:40:45 -07:00
@@ -1,31 +1,12 @@
-
/*
- * ibm_emac_phy.h
- *
- *
- * Benjamin Herrenschmidt <benh@kernel.crashing.org>
- * February 2003
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 675 Mass Ave, Cambridge, MA 02139, USA.
+ * drivers/net/ibm_emac/ibm_emac_phy.h
*
+ * Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ *
+ * 2003 (c) Benjamin Herrenschmidt. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*
* This file basically duplicates sungem_phy.{c,h} with different PHYs
* supported. I'm looking into merging that in a single mii layer more
--- 1.1/drivers/net/ibm_emac/ibm_emac_rgmii.h 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_rgmii.h 2004-11-19 09:32:56 -07:00
@@ -2,15 +2,14 @@
* Defines for the IBM RGMII bridge
*
* Based on ocp_zmii.h/ibm_emac_zmii.h
- * Armin Kuster akuster@mvista.com
*
- * Copyright 2004 MontaVista Software, Inc.
- * Matt Porter <mporter@kernel.crashing.org>
+ * Authors: Armin Kuster <source@mvista.com>
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2004 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#ifndef _IBM_EMAC_RGMII_H_
--- 1.1/drivers/net/ibm_emac/ibm_emac_tah.h 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_tah.h 2004-11-19 09:39:37 -07:00
@@ -1,13 +1,12 @@
/*
* Defines for the IBM TAH
*
- * Copyright 2004 MontaVista Software, Inc.
- * Matt Porter <mporter@kernel.crashing.org>
+ * Author: Matt Porter <mporter@kernel.crashing.org>
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2004 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#ifndef _IBM_EMAC_TAH_H
--- 1.1/drivers/net/ibm_emac/ibm_emac_zmii.h 2004-05-22 10:13:08 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_zmii.h 2004-11-19 09:33:19 -07:00
@@ -3,15 +3,13 @@
*
* Defines for the IBM ZMII bridge
*
- * Armin Kuster akuster@mvista.com
- * Dec, 2001
+ * Authors: Armin Kuster <source@mvista.com>
+ * Maintainer: Matt Porter <mporter@kernel.crashing.org>
*
- * Copyright 2001 MontaVista Softare Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * 2001 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
*/
#ifndef _IBM_EMAC_ZMII_H_
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH][PPC] update_process_times simplification
From: Tom Rini @ 2004-11-19 15:05 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <200411151021.iAFAL0ds070897@sullivan.realtime.net>
On Mon, Nov 15, 2004 at 04:21:00AM -0600, Milton Miller wrote:
> When the update_process_times call was moved out of do_timer for the UP case,
> the replicator didn't track down the hiding and just added ifndef SMP.
>
> This removes the ifdefs and the indirection of calling another file for
> one function in a third file.
>
> I also removed the per-cpu multipler and counter. On some architectures
> (x86 and sparc64) these are set via /proc/profile setup_profiling_timer
> to increase the timer interrupt by a factor over HZ. However, this was
> not not implemented for ppc (like several other architectures), so it
> was just decrementing, testing, and setting per-cpu variables back to 1.
>
> Untested.
> Signed-off-by: Milton Miller <miltonm@bga.com>
Since this is untested, and Linus said he wants bugfixes only until
2.6.10 actually comes out, I'd like to hold this until the 2.6.10
release.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Lite5200 FEC Driver on linux 2.6 broken? (fixed again)
From: roger blofeld @ 2004-11-19 14:53 UTC (permalink / raw)
To: tnt; +Cc: linuxppc-embedded
In-Reply-To: <20041116201654.GA3088@xyzzy>
>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
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
^ permalink raw reply
* RE: MPC82xx -- DPRAM1
From: Rune Torgersen @ 2004-11-19 14:25 UTC (permalink / raw)
To: morten.banzon; +Cc: linuxppc-embedded
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> morten.banzon@axxessit.no
> Sent: Thursday, November 18, 2004 20:24
> I think the only thing missing from the=20
> driver is to setup the now famous SMCx_BASE pointers. This is=20
> ofcourse=20
> possible to do, but there might be good reasons why it is not=20
> done.
Send a patch to fix this in the driver. I think most people on this list
would like the seriaql drivers to be totally independent of the
bootloader (no matter what it is).
^ permalink raw reply
* Re: Problem bringing up Linux on Custom MPC852 Board
From: Wolfgang Denk @ 2004-11-19 13:36 UTC (permalink / raw)
To: Chris Down; +Cc: linuxppc-embedded
In-Reply-To: <000001c4ce35$6194b260$0101a8c0@alcor1>
In message <000001c4ce35$6194b260$0101a8c0@alcor1> you wrote:
>
> The solution was a lot simpler, there was no problem with the SDRAM
> initialisation. The cause was due to the fact that I had a BDI2000
> connected and
> the SYSIE bit was enabled in the DER for flash programming. Clearing
There is no need to set SYSIE.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We want to create puppets that pull their own strings. - Ann Marion
^ permalink raw reply
* RE: Problem bringing up Linux on Custom MPC852 Board
From: Chris Down @ 2004-11-19 12:43 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <000601c4c9c5$514b34c0$0101a8c0@alcor1>
.
> > > At this point it stops executing in arch_kernel_thread.
> >=20
> > I bet some beer that this is actually a FAQ - see
> > http://www.denx.de/twiki/bin/view/DULG/LinuxCrashesRandomly
> >=20
> > This phenomenon is typical for a novice's port of U-Boot.
> >=20
>=20
> Wolfgang, thanks for your reply. I will re-check the SDRAM=20
> initialisation and UPM programming.
>=20
Wolfgang,
The solution was a lot simpler, there was no problem with the SDRAM
initialisation. The cause was due to the fact that I had a BDI2000 =
connected and
the SYSIE bit was enabled in the DER for flash programming. Clearing =
this bit
solved the problem, probably a typical novice error :-)
Regards
Chris Down
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Gabriel Paubert @ 2004-11-19 11:06 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:
> NOTE: Owners of _OTHER_ Apple laptops that could already sleep, like
> earlier iBooks, or Titanium PowerBooks, please test this patch as well
> for regression. More specifically, test if sleep still works, X/DRI, and
> backlight control as I have made significant changes to radeonfb in ways
> that could affect those areas.
Everytime my Pismo wakes up I have the following:
Badness in enable_irq at kernel/irq/manage.c:106
Call trace:
[c0006db4] dump_stack+0x18/0x28
[c0004dfc] check_bug_trap+0x84/0xac
[c0004f84] ProgramCheckException+0x160/0x1a0
[c00044e0] ret_from_except_full+0x0/0x4c
[c002f8dc] enable_irq+0xa0/0xa8
[c0205570] ohci_pci_resume+0xe4/0xfc
[c01fc018] usb_hcd_pci_resume+0xb0/0x114
[c013a9f0] pci_device_resume+0x4c/0x50
[c0181474] resume_device+0x44/0x4c
[c01815ac] dpm_resume+0x130/0x148
[c01815fc] device_resume+0x38/0x78
[c0424ac8] 0xc0424ac8
[c0424fb0] 0xc0424fb0
[c042581c] 0xc042581c
[c0064680] sys_ioctl+0xdc/0x2f4
Badness in enable_irq at kernel/irq/manage.c:106
Call trace:
[c0006db4] dump_stack+0x18/0x28
[c0004dfc] check_bug_trap+0x84/0xac
[c0004f84] ProgramCheckException+0x160/0x1a0
[c00044e0] ret_from_except_full+0x0/0x4c
[c002f8dc] enable_irq+0xa0/0xa8
[c0205570] ohci_pci_resume+0xe4/0xfc
[c01fc018] usb_hcd_pci_resume+0xb0/0x114
[c013a9f0] pci_device_resume+0x4c/0x50
[c0181474] resume_device+0x44/0x4c
[c01815ac] dpm_resume+0x130/0x148
[c01815fc] device_resume+0x38/0x78
[c0424ac8] 0xc0424ac8
[c0424fb0] 0xc0424fb0
[c042581c] 0xc042581c
[c0064680] sys_ioctl+0xdc/0x2f4
It happens when reenabling USB interrupts (before the recent
irq consolidation it was a one line message about unbalanced
irq_enable IIRC). The appended patch fixes the problem for my
machine, the explanation being that some higher level code now
does an explicit free_irq() before suspending and request_irq()
on resume (in drivers/usb/core/hcd-pci.c).
Gabriel
===== drivers/usb/host/ohci-pci.c 1.33 vs edited =====
--- 1.33/drivers/usb/host/ohci-pci.c 2004-11-07 23:31:07 +01:00
+++ edited/drivers/usb/host/ohci-pci.c 2004-11-19 11:55:10 +01:00
@@ -119,14 +119,11 @@
/* let things settle down a bit */
msleep (100);
-
-#ifdef CONFIG_PMAC_PBOOK
- if (_machine == _MACH_Pmac)
- disable_irq ((to_pci_dev(hcd->self.controller))->irq);
+#ifdef CONFIG_PMAC_PBOOK
{
- struct device_node *of_node;
-
+ struct device_node *of_node;
+
/* Disable USB PAD & cell clock */
of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
if (of_node)
@@ -164,13 +161,6 @@
retval = ohci_hub_resume (hcd);
usb_unlock_device (hcd->self.root_hub);
#endif
-
- if (retval == 0) {
-#ifdef CONFIG_PMAC_PBOOK
- if (_machine == _MACH_Pmac)
- enable_irq (to_pci_dev(hcd->self.controller)->irq);
-#endif
- }
return retval;
}
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-19 10:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list
In-Reply-To: <1100854258.21273.273.camel@baythorne.infradead.org>
On Fri, 2004-11-19 at 08:50 +0000, David Woodhouse wrote:
> On Fri, 2004-11-19 at 17:56 +1100, Benjamin Herrenschmidt wrote:
> > (Message cross-posted to several lists, please do _NOT_ reply to all of
> > them).
>
> I forwarded it to fedora-ppc@lists.infradead.org too.
>
> Since I started using the previous patch and actually suspending, I've
> been seeing the GNOME panel and window list die frequently, and
> occasionally other X apps. When X apps have died which were started from
> the command line it seemed to be a spurious SIGPIPE, strangely.
>
> I don't _think_ I've ever seen it immediately after booting; only after
> suspend/resume. But that could be just a coincidence. Likewise the way
> it started when I added the sleep patch _could_ just be a coincidence --
> I was still running Fedora rawhide and updating other packages (and
> there were other kernel changes) at that time, so a lot of other things
> changed too... but has anyone else seen similar behaviour?
Try the new patch. Note that I posted a second one today, right after
the first one, that fixes a engine lockup bug (see my second mail).
The original patch had a bug where some of the CPU "HID" registers
weren't properly restored for 7447A type CPUs. If you had one of these,
it could explain the issue.
Ben.
^ permalink raw reply
* Re: Large PCI region mapping 8272
From: Marc Leeman @ 2004-11-19 10:34 UTC (permalink / raw)
To: Milligan, Keath; +Cc: linuxppc-dev
In-Reply-To: <F3CF3D25A7F8F44BB59BC7A2CA83E30B02322252@ausexch00.austin.polycom.com>
> Could someone point me in the right direction to getting everything
> initialized and mapped correctly?
I had the same impression (that the PCI initialisation) was not quite
right. After some investigation, it was me that used a wrong platform
file (overzealous deleting and copying to minimise custom code).
>From what I understand (after a brief look in the files), most of the
changes can be localised in that file.
You can enable debugging in (IIRC) -#define DEBUG-
arch/ppc/kernel/pci.c
to have a more verbose look at what is happening.
The same goes for quircks.c and pci.c (in drivers/ somewhere).
In any case, the pci mapping calls your platform dependent fixes.=20
--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul
^ permalink raw reply
* Re: Lite5200 FEC Driver on linux 2.6 broken? (fixed again)
From: Sylvain Munaut @ 2004-11-19 10:32 UTC (permalink / raw)
To: roger blofeld; +Cc: linuxppc-embedded
In-Reply-To: <20041118202213.20094.qmail@web53504.mail.yahoo.com>
roger blofeld wrote:
>Adding a call
>
> flush_dcache_range((u32)skb->data, (u32)skb->data + skb->len);
>
> just before spin_lock_irq() in fec_hard_start_xmit() removes the
>remaining transmission checksum errors for me.
>-rb
>
>
>
Mmmm.
That should not be needed.
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
^ permalink raw reply
* Re: TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: David Woodhouse @ 2004-11-19 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1100847411.25521.42.camel@gaston>
On Fri, 2004-11-19 at 17:56 +1100, Benjamin Herrenschmidt wrote:
> (Message cross-posted to several lists, please do _NOT_ reply to all of
> them).
I forwarded it to fedora-ppc@lists.infradead.org too.
Since I started using the previous patch and actually suspending, I've
been seeing the GNOME panel and window list die frequently, and
occasionally other X apps. When X apps have died which were started from
the command line it seemed to be a spurious SIGPIPE, strangely.
I don't _think_ I've ever seen it immediately after booting; only after
suspend/resume. But that could be just a coincidence. Likewise the way
it started when I added the sleep patch _could_ just be a coincidence --
I was still running Fedora rawhide and updating other packages (and
there were other kernel changes) at that time, so a lot of other things
changed too... but has anyone else seen similar behaviour?
--
dwmw2
^ permalink raw reply
* uClibc buildroot system
From: Vladimir @ 2004-11-19 8:18 UTC (permalink / raw)
To: linuxppc-embedded
Hello All !
Have anyone tried subj ?
I'm trying to build it for 405GP CPU. It compiles well, but when I'm trying to
boot from generated root fs in just silently hungs.
--
Best regards,
Vladimir
^ permalink raw reply
* TEST: Sleep suppport for iBook G4 & Aluminium PowerBooks (ATI based)
From: Benjamin Herrenschmidt @ 2004-11-19 6:56 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev, gentoo-ppc-user
(Message cross-posted to several lists, please do _NOT_ reply to all of
them).
NOTE: Owners of _OTHER_ Apple laptops that could already sleep, like
earlier iBooks, or Titanium PowerBooks, please test this patch as well
for regression. More specifically, test if sleep still works, X/DRI, and
backlight control as I have made significant changes to radeonfb in ways
that could affect those areas.
NOTE2: This is still quite experimental, be careful if something goes
wrong (like lots of oopses or crashes on wakeup), you'd rather
hard-restart the machine right away than let corrupted memory buffers be
written back to your disk ;)
First, let's give credit where it's due, as a lot of the work on the
original Aluminium PowerBook sleep code was done by Paul Mackerras,
happy owner of one of these beasts, and thanks to Rob Weir too who gave
me his iBook G4 for a few days, just long enough to get the stuff
working...
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.
The support for sleep on desktop G4s & dual CPU machines, including
support for "hotplug CPU" (allowing to put a CPU to sleep dynamically)
for dual machines isn't in this patch neither, it will be coming
spearately. It will only support one desktop video card at first anyway,
though it will be possible to extend that over time.
Get it at:
http://gate.crashing.org/~benh/albook-ibookg4-sleep.diff
Enjoy !
Ben.
^ permalink raw reply
* Re: MPC82xx -- DPRAM1
From: morten.banzon @ 2004-11-19 2:24 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
Dan Malek <dan@embeddededge.com>
19.11.2004 00:11
To: morten.banzon@axxessit.no
cc: linuxppc-embedded@ozlabs.org, Wolfgang Denk <wd@denx.de>
Subject: Re: MPC82xx -- DPRAM1
On Nov 18, 2004, at 3:08 PM, morten.banzon@axxessit.no wrote:
> > If you know the reason to why it is "a very bad idea" to relocate
these
> > resources within dpram1 I am very curious to learn. On the other hand
> > if
> > you do not know, then please refrain from giving such a stupid answer.
> As you have discovered, there are many dependencies on the
> configuration of the cpm smc from the boot rom to bootloaders to
> the Linux kernel itself. It's a bad idea to be changing one of these
> without changing all of the others to match .... and then you end
> up with a custom piece of software that you have to constantly
> maintain. If you make it configurable, then you end up with even
> more confusion when people mismatch the configurations on
> a board.
I aggree with that, I will strive to avoid such changes.
> There isn't any reason to change the current SMC buffering configuration
> on the CPM2 (and future) devices. If you like change for the sake
> of change, then go ahead and do it. We answered the questions
> you asked and specifically said the changes you were making at
> the time weren't a good idea. Just because you didn't agree
> doesn't make it a stupid response, especially since it's pretty easy
> to figure out on your own from looking at the code.
You might be right that there is no reason to change this cofiguration.
I guess you know that no one would change this for the sake of change.
No, you did not answer my questions. Just to recap a few questions and
answers:
1. I had trouble understanding the use of the CPM_DATAONLY_BASE constant,
or more precisely what was located at the addresses below
CPM_DATAONLY_BASE. It turns out that it is the smc parameter tables that
are placed there. But the real mystery was how the cpm was told where to
find these locations. The end of the story is that the cpm uart driver is
dependent on this particular configuration (writing these adresses into
the SMC1_BASE@0x87FC and SMC2_BASE@0x88FC) beeing set-up before being
loaded. At one point I was asking if this was intentional or not. The
answer to this I still do not know, but maybe it is not important either.
2. I stated that I relocated the buffer descriptors. This was done by
replacing cpm_dpalloc with cpm_dpalloc_fixed and an offset adress of my
choice. Your reply to this was the "very bad idea". Well, on my target I
can move these buffer descriptors around as I please within the dpram1,
and the smc1/console just keeps working. I do not say that this is not
problematic, just that I do not detect any problems neither do I see any
problems by reading the code. So, why this is a bad idea remains unclear.
What seems to be a bad idea, or at least a little messy, is to relocate
the smc parameter ram located below the first 128 bytes of dpram1.
Now you go on about "just because you didn't agree"? Where did that come
frome ? Maybe I am expressing myself very unclear, but as far as I know I
have not disagreed with anything. I am just asking questions and trying to
understand this peace of the system, and to be frank not many correct
answers have been provided.
Regarding "stupid response" I am baffled. Wolfgang presents a few very
clear statement, which are equally clearly wrong regarding this subject,
the cpm uart driver (smc). Your mail contradicts his mail. I have come to
the same conclusion as you have summarised in your previous mail. That is
why I call "read the code" a stupid answer. I think somebody else should
take a break and read the code. Besides saying "stupid" about that
particular answer, I have not called any other answer, suggestion, or
anything else stupid. I hope we are clear on that.
How you can say it is "pretty easy to figure out on your own from looking
at the code" I do not get, but that is not important. If you think it is
easy, that is fine for you. I think I have described the reason why it is
difficult to understand several times now, just a final point; in terms of
configuring the smc hardware I think the only thing missing from the
driver is to setup the now famous SMCx_BASE pointers. This is ofcourse
possible to do, but there might be good reasons why it is not done. How it
is supposed to be obvious that some boot code/loader set up these
particular pointers I disagree with, especially in light of Wolfgang's
mail.
Have a nice day,
-- Morten
^ permalink raw reply
* Re: MPC82xx -- DPRAM1
From: Dan Malek @ 2004-11-18 23:11 UTC (permalink / raw)
To: morten.banzon; +Cc: linuxppc-embedded
In-Reply-To: <OF39E98ED9.64FBC87A-ONC1256F50.006BC66A-C1256F50.006EA31B@axxessit.no>
On Nov 18, 2004, at 3:08 PM, morten.banzon@axxessit.no wrote:
> If you know the reason to why it is "a very bad idea" to relocate these
> resources within dpram1 I am very curious to learn. On the other hand
> if
> you do not know, then please refrain from giving such a stupid answer.
As you have discovered, there are many dependencies on the
configuration of the cpm smc from the boot rom to bootloaders to
the Linux kernel itself. It's a bad idea to be changing one of these
without changing all of the others to match .... and then you end
up with a custom piece of software that you have to constantly
maintain. If you make it configurable, then you end up with even
more confusion when people mismatch the configurations on
a board.
There isn't any reason to change the current SMC buffering configuration
on the CPM2 (and future) devices. If you like change for the sake
of change, then go ahead and do it. We answered the questions
you asked and specifically said the changes you were making at
the time weren't a good idea. Just because you didn't agree
doesn't make it a stupid response, especially since it's pretty easy
to figure out on your own from looking at the code.
Thanks.
-- Dan
^ 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