* Re: Platform device model drawback
From: Grant Likely @ 2005-11-17 23:46 UTC (permalink / raw)
To: Greg KH, Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <20051115224056.GA14357@kroah.com>
On 11/15/05, Greg KH <greg@kroah.com> wrote:
> On Tue, Nov 15, 2005 at 01:34:47PM -0600, Kumar Gala wrote:
> > This is where the confusion is. We have two instances of device A. We
> > want instance 1 of device A bound to driver "enet" and instance 2 of
> > device A bound to "serial".
>
> That's different from what was described earlier :)
>
> In this case, you need two different struct devices.
Which is what we have.
>
> > Today both instances are called "deviceA". However we can't register t=
wo
> > different drivers as "deviceA".
>
> Nor would you want to.
>
> > Not sure if that clarifies the issue any.
>
> A bit. I think it still sounds messy...
Does this help? (We also discussed this a bit at the PPC BoF at OLS this y=
ear)
For example on the mpc52xx (see arch/ppc/syslib/mpc52xx_devices.c);
- 6 PSC devices on chip;
- (struct platform_device) for each device has: .name=3D'mpc52xx-psc';
- However, SCC1 may be driven by the Ethernet driver but PSC2 and
PSC6 may be serial
- problem then is: How do you get only PSC1 bound to the
psc-ethernet driver and only PSC2 & PSC6 bound to the serial driver?
Possible solution; Modify the naming scheme slightly from what is
currently used.
1. Make the Ethernet driver register the name "mpc52xx-psc:eth"
2. Make the serial driver register the name "mpc52xx-psc:uart"
3. In the board-specific platform code, modify the .name field in
struct platform_device *before* the device is registered with the
platform device. (possibly by extending ppc_sys_device_fixup callback)
- The board specific code would set PSC1 to "mpc52xx-psc:eth",
PSC2&6 to "mpc52xx-psc:uart". PSC3-5 would stick with "mpc52xx-psc"
and so would not get bound to anything.
Q: Can the .name field be modified *after* platform_device is
registered w/ the platform bus?
g.
^ permalink raw reply
* [PATCH] ppc: Fix warnings related to seq_file
From: Kumar Gala @ 2005-11-17 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, linux-kernel, linuxppc-embedded
When we moved things around in irq.h seq_file became an issue. Fix
warnings related to its usage.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit ac2a1a810d71d6c5f928cfbb428717bc3c567fde
tree c213a8035b6bb13aeb5e2bf639b3af9830462fb2
parent 81fa90f4627668b94ba55163dca08b076ee71e50
author Kumar Gala <galak@kernel.crashing.org> Thu, 17 Nov 2005 17:47:03 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 17 Nov 2005 17:47:03 -0600
arch/ppc/platforms/85xx/mpc85xx_ads_common.h | 2 ++
arch/ppc/platforms/85xx/stx_gp3.h | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/platforms/85xx/mpc85xx_ads_common.h b/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
index 7b26bcc..198a6a0 100644
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
@@ -25,6 +25,8 @@
#define BCSR_ADDR ((uint)0xf8000000)
#define BCSR_SIZE ((uint)(32 * 1024))
+struct seq_file;
+
extern int mpc85xx_ads_show_cpuinfo(struct seq_file *m);
extern void mpc85xx_ads_init_IRQ(void) __init;
extern void mpc85xx_ads_map_io(void) __init;
diff --git a/arch/ppc/platforms/85xx/stx_gp3.h b/arch/ppc/platforms/85xx/stx_gp3.h
index 7bcc6c3..2f25b51 100644
--- a/arch/ppc/platforms/85xx/stx_gp3.h
+++ b/arch/ppc/platforms/85xx/stx_gp3.h
@@ -21,7 +21,6 @@
#include <linux/config.h>
#include <linux/init.h>
-#include <linux/seq_file.h>
#include <asm/ppcboot.h>
#define BOARD_CCSRBAR ((uint)0xe0000000)
@@ -43,7 +42,6 @@ extern void mpc85xx_setup_hose(void) __i
extern void mpc85xx_restart(char *cmd);
extern void mpc85xx_power_off(void);
extern void mpc85xx_halt(void);
-extern int mpc85xx_show_cpuinfo(struct seq_file *m);
extern void mpc85xx_init_IRQ(void) __init;
extern unsigned long mpc85xx_find_end_of_memory(void) __init;
extern void mpc85xx_calibrate_decr(void) __init;
^ permalink raw reply related
* Re: [PATCH] ppc boot: replace string labels with numbers
From: Jerry Van Baren @ 2005-11-17 22:54 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20051117210902.GB31775@suse.de>
Olaf Hering wrote:
> Replacing the string labels with numbers saves 117 bytes in the final zImage.
> These local labels are not discared.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> arch/powerpc/boot/crt0.S | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> Index: linux-2.6.15-rc1-olh/arch/powerpc/boot/crt0.S
> ===================================================================
> --- linux-2.6.15-rc1-olh.orig/arch/powerpc/boot/crt0.S
> +++ linux-2.6.15-rc1-olh/arch/powerpc/boot/crt0.S
> @@ -14,43 +14,42 @@
> .text
> .globl _zimage_start
> _zimage_start:
> - bl reloc_offset
> + bl 1f
>
> -reloc_offset:
> +1:
> mflr r0
> - lis r9,reloc_offset@ha
> - addi r9,r9,reloc_offset@l
> + lis r9,1b@ha
> + addi r9,r9,1b@l
> subf. r0,r9,r0
> - beq clear_caches
> + beq 3f
[snip]
OK, I've waited for someone dumber than me to ask, but I guess I'm the
bottom guy on the totem pole here.
How does changing a local ascii label to a temporary label _but using
the same machine instructions_ affect the output image size???? Why
would "lis r9,reloc_offset@ha" generate a smaller (!) instruction than
"lis r9,1b@ha"????
My first thought was that the symbol section of the ELF output is
bigger, but the labels are not globals. Even if the local labels end up
in the symbol section (which the comment on the original patch message
sort of implies), that isn't going to make a (stripped) binary any
bigger. If that is the case, isn't a better cure to strip the ELF file?
While I'm being dumb, I gotta ask, how big is zImage and why does 117
bytes make a difference?
My 2c: if you are going to use inscrutable labels (1,2,3,4), please put
comments in. At least the previous labels gave hints as to what was
happening.
Puzzled,
gvb
^ permalink raw reply
* Re: gianfar generic PHY assumptions.
From: Matt Porter @ 2005-11-17 23:14 UTC (permalink / raw)
To: David Updegraff; +Cc: linux-ppc-embedded
In-Reply-To: <437CFB43.4060400@cray.com>
On Thu, Nov 17, 2005 at 03:50:59PM -0600, David Updegraff wrote:
> Hi.
>
> This patch lets gianfar work on 83xx (or 85xx??) boards that have
> Generic PHYs on them that do _NOT_ happen to have an IRQ line wired to
> external_15. Surely reasonable that if we can't ID the PHY that its
> probably not irq-wired the Freescale-ADS "way"...
>
> It was critical for us; perhaps usefull for others.
Aside from the fact that the patch doesn't apply against the
current kernel due to the change of gianfar to use the phy
layer...why wouldn't you just set the board_flags field
appropriately in your board port? If you don't use a phy interrupt
then don't set the flag claiming that you do. stx_gp3.c doesn't
make use of the phy interrupt functionality, as an example.
I looked at an older kernel and I'm not sure where you see external
15 being used. It seems to be EXT5 on all the Fscale boards.
-Matt
^ permalink raw reply
* Re: gianfar generic PHY assumptions.
From: Kumar Gala @ 2005-11-17 23:07 UTC (permalink / raw)
To: David Updegraff; +Cc: linux-ppc-embedded
In-Reply-To: <437CFB43.4060400@cray.com>
On Thu, 17 Nov 2005, David Updegraff wrote:
> Hi.
>
> This patch lets gianfar work on 83xx (or 85xx??) boards that have
> Generic PHYs on them that do _NOT_ happen to have an IRQ line wired to
> external_15. Surely reasonable that if we can't ID the PHY that its
> probably not irq-wired the Freescale-ADS "way"...
>
> It was critical for us; perhaps usefull for others.
The way PHYs are handle in 2.6.15 is completely different and the patch
is not valid against the current tree.
- kumar
^ permalink raw reply
* [PATCH] ppc: Fix MPC83xx device table
From: Kumar Gala @ 2005-11-17 23:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: dave, Paul Mackerras, linux-kernel, linuxppc-embedded
The SVRs for MPC8343/E where incorrect and really the SVRs
for MPC8347/E.
Signed-off-by: David Updegraff <dave@cray.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 6eba85c696e0a0fef59435bd641110a759b308ab
tree 0f2393d85f4f225793508a321460c74579c9d834
parent 5b45c04aa9d209ba1a71ff8061fda9ae3979ddd6
author Kumar Gala <galak@kernel.crashing.org> Thu, 17 Nov 2005 17:06:02 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 17 Nov 2005 17:06:02 -0600
arch/ppc/syslib/mpc83xx_sys.c | 28 ++++++++++++++++++++++++++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/syslib/mpc83xx_sys.c b/arch/ppc/syslib/mpc83xx_sys.c
index a152398..82cf3ab 100644
--- a/arch/ppc/syslib/mpc83xx_sys.c
+++ b/arch/ppc/syslib/mpc83xx_sys.c
@@ -69,9 +69,33 @@ struct ppc_sys_spec ppc_sys_specs[] = {
},
},
{
- .ppc_sys_name = "8343E",
+ .ppc_sys_name = "8347E",
.mask = 0xFFFF0000,
.value = 0x80540000,
+ .num_devices = 9,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
+ MPC83xx_IIC2, MPC83xx_DUART, MPC83xx_SEC2,
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH, MPC83xx_MDIO
+ },
+ },
+ {
+ .ppc_sys_name = "8347",
+ .mask = 0xFFFF0000,
+ .value = 0x80550000,
+ .num_devices = 8,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
+ MPC83xx_IIC2, MPC83xx_DUART,
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH, MPC83xx_MDIO
+ },
+ },
+ {
+ .ppc_sys_name = "8343E",
+ .mask = 0xFFFF0000,
+ .value = 0x80560000,
.num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
@@ -83,7 +107,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
{
.ppc_sys_name = "8343",
.mask = 0xFFFF0000,
- .value = 0x80550000,
+ .value = 0x80570000,
.num_devices = 7,
.device_list = (enum ppc_sys_devices[])
{
^ permalink raw reply related
* Re: Platform device model drawback
From: Peter Hanson @ 2005-11-17 23:05 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-embedded
In-Reply-To: <20051117174912.GA23034@kroah.com>
On 11/17/05, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 17, 2005 at 09:51:56AM -0800, Peter Hanson wrote:
> > On 11/16/05, Greg KH <greg@kroah.com> wrote:
> > > On Wed, Nov 16, 2005 at 06:39:49PM -0800, Peter Hanson wrote:
> > > > IIRC, Arabella claims to deal nicely with dynamic allocation of
> > > > PowerPC resources to Linux devices =3D>
> > > > http://www.arabellasw.com/home.php
> > >
> > > I don't understand how that pertains to this thread...
> >
> > Potential conflict: multiple logical devices competing for the same
> > SoC resource. Converse: similar logical devices supported by
> > different resources. Both cases have been mentioned in this thread,
> > with confusion about how to deal with them.
> >
> > Does Arabella solve it as claimed? I don't know. But dynamic
> > allocation doesn't sound crazy. Maybe some of the code or design can
> > even be copied.
>
> Do you have a pointer to their code anywhere?
I checked [http://www.arabellasw.com/products-free.php], and the
downloadable source is now gone. :-(
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: PVR wrong for mpc8343 chips.
From: Kumar Gala @ 2005-11-17 23:01 UTC (permalink / raw)
To: David Updegraff; +Cc: linux-ppc-embedded
In-Reply-To: <437CFBF9.70505@cray.com>
On Thu, 17 Nov 2005, David Updegraff wrote:
> Hi.
>
> The PVRs are wrongly enumerated for the 8343/8343e chips.
>
> -dbu
Good catch. I'll send a fixed up version of this patch upstream.
In the future take a look at Documentation/SubmittingPatches.
thanks
- kumar
^ permalink raw reply
* PVR wrong for mpc8343 chips.
From: David Updegraff @ 2005-11-17 21:54 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 69 bytes --]
Hi.
The PVRs are wrongly enumerated for the 8343/8343e chips.
-dbu
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1575 bytes --]
diff --git a/arch/ppc/syslib/mpc83xx_sys.c b/arch/ppc/syslib/mpc83xx_sys.c
index 29aa633..556b233 100644
--- a/arch/ppc/syslib/mpc83xx_sys.c
+++ b/arch/ppc/syslib/mpc83xx_sys.c
@@ -69,29 +69,53 @@ struct ppc_sys_spec ppc_sys_specs[] = {
},
},
{
- .ppc_sys_name = "8343E",
+ .ppc_sys_name = "8347E",
.mask = 0xFFFF0000,
.value = 0x80540000,
- .num_devices = 7,
+ .num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART, MPC83xx_SEC2,
- MPC83xx_USB2_DR,
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH
},
},
{
- .ppc_sys_name = "8343",
+ .ppc_sys_name = "8347",
.mask = 0xFFFF0000,
.value = 0x80550000,
- .num_devices = 6,
+ .num_devices = 7,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART,
- MPC83xx_USB2_DR,
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH
},
},
+ {
+ .ppc_sys_name = "8343E",
+ .mask = 0xFFFF0000,
+ .value = 0x80560000,
+ .num_devices = 7,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
+ MPC83xx_IIC2, MPC83xx_DUART, MPC83xx_SEC2,
+ MPC83xx_USB2_DR
+ }
+ },
+ {
+ .ppc_sys_name = "8343",
+ .mask = 0xFFFF0000,
+ .value = 0x80570000,
+ .num_devices = 6,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
+ MPC83xx_IIC2, MPC83xx_DUART,
+ MPC83xx_USB2_DR
+ }
+ },
{ /* default match */
.ppc_sys_name = "",
.mask = 0x00000000,
^ permalink raw reply related
* gianfar generic PHY assumptions.
From: David Updegraff @ 2005-11-17 21:50 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
Hi.
This patch lets gianfar work on 83xx (or 85xx??) boards that have
Generic PHYs on them that do _NOT_ happen to have an IRQ line wired to
external_15. Surely reasonable that if we can't ID the PHY that its
probably not irq-wired the Freescale-ADS "way"...
It was critical for us; perhaps usefull for others.
-dbu.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1071 bytes --]
diff --git a/drivers/net/gianfar_phy.c b/drivers/net/gianfar_phy.c
index 7c965f2..1c08bd0 100644
--- a/drivers/net/gianfar_phy.c
+++ b/drivers/net/gianfar_phy.c
@@ -234,6 +234,19 @@ static int marvell_config_aneg(struct gf
return 0;
}
+/* Init for GENERIC: just here to make sure the gainfar driver does not assume
+ * that it has an interrupt. Since don't even know what model it is, seems
+ * unlikely that they have bothered to wire in an IRQ line exactly like the
+ * the platform/ files have assumed.
+ */
+static int genmii_init(struct gfar_mii_info *mii_info)
+{
+ struct gfar_private *priv = netdev_priv(mii_info->dev);
+ if (priv)
+ priv->einfo->board_flags &= ~FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ return 0;
+}
+
static int genmii_config_aneg(struct gfar_mii_info *mii_info)
{
if (mii_info->autoneg) {
@@ -585,6 +598,7 @@ static struct phy_info phy_info_genmii=
.phy_id_mask = 0x00000000,
.name = "Generic MII",
.features = MII_BASIC_FEATURES,
+ .init = genmii_init,
.config_aneg = genmii_config_aneg,
.read_status = genmii_read_status,
};
^ permalink raw reply related
* [PATCH] ppc boot: replace string labels with numbers
From: Olaf Hering @ 2005-11-17 21:09 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Replacing the string labels with numbers saves 117 bytes in the final zImage.
These local labels are not discared.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/boot/crt0.S | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
Index: linux-2.6.15-rc1-olh/arch/powerpc/boot/crt0.S
===================================================================
--- linux-2.6.15-rc1-olh.orig/arch/powerpc/boot/crt0.S
+++ linux-2.6.15-rc1-olh/arch/powerpc/boot/crt0.S
@@ -14,43 +14,42 @@
.text
.globl _zimage_start
_zimage_start:
- bl reloc_offset
+ bl 1f
-reloc_offset:
+1:
mflr r0
- lis r9,reloc_offset@ha
- addi r9,r9,reloc_offset@l
+ lis r9,1b@ha
+ addi r9,r9,1b@l
subf. r0,r9,r0
- beq clear_caches
+ beq 3f
-reloc_got2:
lis r9,__got2_start@ha
addi r9,r9,__got2_start@l
lis r8,__got2_end@ha
addi r8,r8,__got2_end@l
subf. r8,r9,r8
- beq clear_caches
+ beq 3f
srwi. r8,r8,2
mtctr r8
add r9,r0,r9
-reloc_got2_loop:
+2:
lwz r8,0(r9)
add r8,r8,r0
stw r8,0(r9)
addi r9,r9,4
- bdnz reloc_got2_loop
+ bdnz 2b
-clear_caches:
+3:
lis r9,_start@h
add r9,r0,r9
lis r8,_etext@ha
addi r8,r8,_etext@l
add r8,r0,r8
-1: dcbf r0,r9
+4: dcbf r0,r9
icbi r0,r9
addi r9,r9,0x20
cmplwi 0,r9,8
- blt 1b
+ blt 4b
sync
isync
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* INTERACTIVE_CONSOLE for misc-embedded.c and watchdog issue
From: Marcelo Tosatti @ 2005-11-17 15:17 UTC (permalink / raw)
To: Tom Rini; +Cc: linux-ppc-embedded
Hi Tom,
The following patch against misc-embedded.c adds an INTERACTIVE_CONSOLE
#define to guard reading from console (causes unecessary delay in some
situations).
Its an adaptation of misc.c's define, a difference being that platform
headers define "NO_INTERACTIVE_CONSOLE" if required.
What do you think?
Another issue is the watchdog - if it is active all 8xx systems
should fail to boot because load_kernel() (and the gzip functions)
don't calm the dog.
Our internal kernels always have sprinkled "service_wdt()" calls
around "load_kernel()".
Adding hooks for the wdt to be service there (and possibly other places)
is terrible, but is there any other solution so early?
Setting up a HW timer with early setup code might be possible,
but sounds quite complicated.
Of course, with U-Boot all of this is a non-issue, but for simple
bootloaders (which I suppose are quite common) it is a nasty problem.
diff --git a/arch/ppc/boot/simple/misc-embedded.c b/arch/ppc/boot/simple/misc-embedded.c
index 3865f3f..85e3e24 100644
--- a/arch/ppc/boot/simple/misc-embedded.c
+++ b/arch/ppc/boot/simple/misc-embedded.c
@@ -23,6 +23,10 @@
#include "nonstdio.h"
+#ifndef NO_INTERACTIVE_CONSOLE
+#define INTERACTIVE_CONSOLE
+#endif
+
/* The linker tells us where the image is. */
extern char __image_begin, __image_end;
extern char __ramdisk_begin, __ramdisk_end;
@@ -82,8 +86,11 @@ embed_config(bd_t **bdp)
unsigned long
load_kernel(unsigned long load_addr, int num_words, unsigned long cksum, bd_t *bp)
{
+#ifdef INTERACTIVE_CONSOLE
char *cp, ch;
- int timer = 0, zimage_size;
+ int timer = 0;
+#endif
+ int zimage_size;
unsigned long initrd_size;
/* First, capture the embedded board information. Then
@@ -187,6 +194,8 @@ load_kernel(unsigned long load_addr, int
#endif
while ( *cp )
putc(*cp++);
+
+#ifdef INTERACTIVE_CONSOLE
while (timer++ < 5*1000) {
if (tstc()) {
while ((ch = getc()) != '\n' && ch != '\r') {
@@ -211,6 +220,7 @@ load_kernel(unsigned long load_addr, int
udelay(1000); /* 1 msec */
}
*cp = 0;
+#endif
puts("\nUncompressing Linux...");
gunzip(0, 0x400000, zimage_start, &zimage_size);
^ permalink raw reply related
* Re: "Now booting the kernel"
From: David H. Lynch Jr @ 2005-11-17 19:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <437C4E07.8020307@comcast.net>
David H. Lynch Jr. wrote:
> I am having similar difficulties on a Xilinx Virtex 4.
>
> I have some advantages over Nitesh in that I have a 32bit port at
> 0x70000000 that I can write values to and see what they are (at least
> until the MMU is enabled)
> and with some additional complexity use as a sort of UART to write
> text.
> Thus far this is what I get:
>
> Starting MonitorX.elf: V3.3.2.0.
> Loading zImage.elf.
Sorry, this is Linux 2.6.14 on a Xilinx-VI
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Marcelo Tosatti @ 2005-11-17 14:07 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <437B2051.5030408@ru.mvista.com>
On Wed, Nov 16, 2005 at 03:04:33PM +0300, Vitaly Bordug wrote:
> This adds board-specific files needed to utilize fs_enet Ethernet driver
> for MPC885ADS and MPC866ADS.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>
Vitaly,
It also sounds to me that mpc885_nonplatform_device_init()
initialization suits board_init() time, instead of post-start_kernel()
do_initcalls(). No?
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Marcelo Tosatti @ 2005-11-17 13:58 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <437B2051.5030408@ru.mvista.com>
Hi Vitaly,
On Wed, Nov 16, 2005 at 03:04:33PM +0300, Vitaly Bordug wrote:
> This adds board-specific files needed to utilize fs_enet Ethernet driver
> for MPC885ADS and MPC866ADS.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>
> +menu "Freescale Ethernet driver platform-specific options"
> + depends on FS_ENET
> +
> + config MPC8xx_SECOND_ETH
> + bool "Second Ethernet channel"
> + depends on (MPC885ADS || MPC86XADS)
> + default y
> + help
> + This enables support for second Ethernet on MPC885ADS and
> MPC86xADS boards.
Some line breakage here?
> choice
> prompt "Machine Type"
> depends on 6xx || POWER3 || POWER4
> diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
> index 7c5cdab..cce6487 100644
> --- a/arch/ppc/platforms/Makefile
> +++ b/arch/ppc/platforms/Makefile
> @@ -45,6 +45,8 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o
> obj-$(CONFIG_SPRUCE) += spruce.o
> obj-$(CONFIG_LITE5200) += lite5200.o
> obj-$(CONFIG_EV64360) += ev64360.o
> +obj-$(CONFIG_MPC86XADS) += mpc866ads_setup.o
> +obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o
>
> ifeq ($(CONFIG_SMP),y)
> obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
> diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h
> index a48fb8d..e1c0b1b 100644
> --- a/arch/ppc/platforms/fads.h
> +++ b/arch/ppc/platforms/fads.h
> @@ -112,7 +112,7 @@
>
> /* CPM Ethernet through SCC1 or SCC2 */
>
> -#ifdef CONFIG_SCC1_ENET /* Probably 860 variant */
> +#if defined(CONFIG_SCC1_ENET) || defined(CONFIG_MPC8xx_SECOND_ETH_SCC1) /*
> Probably 860
> variant */
> /* Bits in parallel I/O port registers that have to be set/cleared
> * to configure the pins for SCC1 use.
> * TCLK - CLK1, RCLK - CLK2.
> diff --git a/arch/ppc/platforms/mpc866ads_setup.c
> b/arch/ppc/platforms/mpc866ads_setup.c
> new file mode 100644
> index 0000000..6ffdb0e
> --- /dev/null
> +++ b/arch/ppc/platforms/mpc866ads_setup.c
> @@ -0,0 +1,290 @@
> +/*arch/ppc/platforms/mpc885ads-setup.c
> + *
> + * Platform setup for the Freescale mpc885ads board
> + *
> + * Vitaly Bordug <vbordug@ru.mvista.com>
> + *
> + * Copyright 2005 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>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/param.h>
> +#include <linux/string.h>
> +#include <linux/ioport.h>
> +#include <linux/device.h>
> +
> +#include <linux/fs_enet_pd.h>
> +#include <linux/mii.h>
> +
> +#include <asm/delay.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/page.h>
> +#include <asm/processor.h>
> +#include <asm/system.h>
> +#include <asm/time.h>
> +#include <asm/ppcboot.h>
> +#include <asm/8xx_immap.h>
> +#include <asm/commproc.h>
> +#include <asm/ppc_sys.h>
> +#include <asm/mpc8xx.h>
> +
> +extern unsigned char __res[];
> +
> +/* access ports */
> +#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v))
> +#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
> +
> +#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v))
> +#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
These definitions should go to generic header files.
> +
> +static struct fs_mii_bus_info fec_mii_bus_info = {
> + .method = fsmii_fec,
> + .id = 0,
> +};
> +
> +static struct fs_mii_bus_info scc_mii_bus_info = {
> + .method = fsmii_fixed,
> + .id = 0,
> + .i.fixed.speed = 10,
> + .i.fixed.duplex = 0,
> +};
> +
> +static struct fs_platform_info mpc8xx_fec_pdata[] = {
> + {
> + .rx_ring = 128,
> + .tx_ring = 16,
> + .rx_copybreak = 240,
> +
> + .use_napi = 1,
> + .napi_weight = 17,
> +
> + .phy_addr = 15,
> + .phy_irq = -1,
> +
> + .use_rmii = 0,
> +
> + .bus_info = &fec_mii_bus_info,
> + }
> +};
> +
> +static struct fs_platform_info mpc8xx_scc_pdata = {
> + .rx_ring = 64,
> + .tx_ring = 8,
> + .rx_copybreak = 240,
> +
> + .use_napi = 1,
> + .napi_weight = 17,
> +
> + .phy_addr = -1,
> + .phy_irq = -1,
> +
> + .bus_info = &scc_mii_bus_info,
> +};
> +
> +static void mpc866_nonplatform_device_init(void)
> +{
> + volatile cpm8xx_t *cp = cpmp;
> + unsigned *bcsr_io;
> +
> + bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
> +
> + if (bcsr_io == NULL) {
> + printk(KERN_CRIT "Could not remap BCSR1\n");
> + return;
> + }
> +#ifdef CONFIG_SERIAL_CPM_SMC1
> + cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
> + out_be32(bcsr_io, in_be32(bcsr_io) & ~(0x80000000 >> 7));
> +#else
> + out_be32(bcsr_io, in_be32(bcsr_io) | (0x80000000 >> 7));
> + cp->cp_pbpar &= ~(0x000000c0);
> + cp->cp_pbdir |= 0x000000c0;
> + cp->cp_smc[0].smc_smcmr = 0;
> + cp->cp_smc[0].smc_smce = 0;
> +#endif
> +
> +#ifdef CONFIG_SERIAL_CPM_SMC2
> + cp->cp_simode &= ~(0xe0000000 >> 1);
> + cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
> + out_be32(bcsr_io, in_be32(bcsr_io) & ~(0x80000000 >> 13));
> +#else
> + out_be32(bcsr_io, in_be32(bcsr_io) | (0x80000000 >> 13));
Should use the clrbit/setbit macro definitions?
> + cp->cp_pbpar &= ~(0x00000c00);
> + cp->cp_pbdir |= 0x00000c00;
> + cp->cp_smc[1].smc_smcmr = 0;
> + cp->cp_smc[1].smc_smce = 0;
> +#endif
> + iounmap(bcsr_io);
> +}
> +
> +static void setup_fec1_ioports(void)
> +{
> + immap_t *immap = (immap_t *) IMAP_ADDR;
> +
> + setbits16(immap->im_ioport.iop_pdpar, 0x1fff);
> + setbits16(immap->im_ioport.iop_pddir, 0x1fff);
> +}
> +
> +static void setup_scc1_ioports(void)
> +{
> + immap_t *immap = (immap_t *) IMAP_ADDR;
> + unsigned *bcsr_io;
> +
> + bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
> +
> + if (bcsr_io == NULL) {
> + printk(KERN_CRIT "Could not remap BCSR1\n");
> + return;
> + }
> +
> + /* Enable the PHY.
> + */
> + out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_ETHEN);
> +
> + /* Configure port A pins for Txd and Rxd.
> + */
> + /* Disable receive and transmit in case EPPC-Bug started it.
> + */
> + setbits16(immap->im_ioport.iop_papar, PA_ENET_RXD | PA_ENET_TXD);
> + clrbits16(immap->im_ioport.iop_padir, PA_ENET_RXD | PA_ENET_TXD);
> + clrbits16(immap->im_ioport.iop_paodr, PA_ENET_TXD);
> +
> + /* Configure port C pins to enable CLSN and RENA.
> + */
> + clrbits16(immap->im_ioport.iop_pcpar, PC_ENET_CLSN | PC_ENET_RENA);
> + clrbits16(immap->im_ioport.iop_pcdir, PC_ENET_CLSN | PC_ENET_RENA);
> + setbits16(immap->im_ioport.iop_pcso, PC_ENET_CLSN | PC_ENET_RENA);
> + /* Configure port A for TCLK and RCLK.
> + */
> + setbits16(immap->im_ioport.iop_papar, PA_ENET_TCLK | PA_ENET_RCLK);
> + clrbits16(immap->im_ioport.iop_padir, PA_ENET_TCLK | PA_ENET_RCLK);
> + clrbits32(immap->im_cpm.cp_pbpar, PB_ENET_TENA);
> + clrbits32(immap->im_cpm.cp_pbdir, PB_ENET_TENA);
> +
> + /* Configure Serial Interface clock routing.
> + * First, clear all SCC bits to zero, then set the ones we want.
> + */
> + clrbits32(immap->im_cpm.cp_sicr, SICR_ENET_MASK);
> + setbits32(immap->im_cpm.cp_sicr, SICR_ENET_CLKRT);
> +
> + /* In the original SCC enet driver the following code is placed at
> the end of the
> initialization */
Strange formatting?
^ permalink raw reply
* Re: Platform device model drawback
From: Greg KH @ 2005-11-17 17:49 UTC (permalink / raw)
To: Peter Hanson; +Cc: linuxppc-embedded
In-Reply-To: <50e923300511170951o5695e3f2s8b4b7ae4c1f8788a@mail.google.com>
On Thu, Nov 17, 2005 at 09:51:56AM -0800, Peter Hanson wrote:
> On 11/16/05, Greg KH <greg@kroah.com> wrote:
> > On Wed, Nov 16, 2005 at 06:39:49PM -0800, Peter Hanson wrote:
> > > IIRC, Arabella claims to deal nicely with dynamic allocation of
> > > PowerPC resources to Linux devices =>
> > > http://www.arabellasw.com/home.php
> >
> > I don't understand how that pertains to this thread...
>
> Potential conflict: multiple logical devices competing for the same
> SoC resource. Converse: similar logical devices supported by
> different resources. Both cases have been mentioned in this thread,
> with confusion about how to deal with them.
>
> Does Arabella solve it as claimed? I don't know. But dynamic
> allocation doesn't sound crazy. Maybe some of the code or design can
> even be copied.
Do you have a pointer to their code anywhere?
thanks,
greg k-h
^ permalink raw reply
* Depmod crash when installing modules
From: Clement Fabien @ 2005-11-17 17:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi=20
As anyone here previously encountered a "segmentation fault" on depmod
when trying to install modules?
I'm building a 2.6.13, with Alex Zeffertt PQ2 Sar driver + atm modules,
and I've got a nice crash (see following)
make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
Building modules, stage 2.
MODPOST
CC net/atm/atm.mod.o
CC net/atm/br2684.mod.o
CC net/atm/clip.mod.o
LD [M] net/atm/atm.ko
LD [M] net/atm/clip.ko
LD [M] net/atm/br2684.ko
make modules_install INSTALL_MOD_PATH=3D/home/xxx/Atm/
INSTALL net/atm/atm.ko
INSTALL net/atm/br2684.ko
INSTALL net/atm/clip.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
System.map -b /home/xxx/Atm/ -r 2.6.13; fi
/bin/sh: line 1: 8902 Segmentation fault /sbin/depmod -ae -F
System.map -b /home/xxx/Atm/ -r 2.6.13
make: *** [_modinst_post] Error 139
With depmod -V =3D> module-init-tools 3.1-pre5
Fabien.
^ permalink raw reply
* Re: Platform device model drawback
From: Peter Hanson @ 2005-11-17 17:51 UTC (permalink / raw)
To: Greg KH, linuxppc-embedded
In-Reply-To: <20051117041645.GA19145@kroah.com>
On 11/16/05, Greg KH <greg@kroah.com> wrote:
> On Wed, Nov 16, 2005 at 06:39:49PM -0800, Peter Hanson wrote:
> > IIRC, Arabella claims to deal nicely with dynamic allocation of
> > PowerPC resources to Linux devices =3D>
> > http://www.arabellasw.com/home.php
>
> I don't understand how that pertains to this thread...
Potential conflict: multiple logical devices competing for the same
SoC resource. Converse: similar logical devices supported by
different resources. Both cases have been mentioned in this thread,
with confusion about how to deal with them.
Does Arabella solve it as claimed? I don't know. But dynamic
allocation doesn't sound crazy. Maybe some of the code or design can
even be copied.
> And why did you post it only to me?
Oops. Correcting now.
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Russell King @ 2005-11-17 16:10 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linux-kernel, ML linuxppc-embedded
In-Reply-To: <437A2EE8.4050404@varma-el.com>
On Tue, Nov 15, 2005 at 09:54:32PM +0300, Andrey Volkov wrote:
> I fear it is not a last patch of such kind :(.
> Please recheck places where you are changed
> pdev<->dev.
Applied. However, what you ask is to review the entire kernel looking
for a one-character error needle in a massive haystack. That's a job
better suited to compilers than eyes.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* [PATCH] Fix zImage boot on old Pegasos firmware
From: David Woodhouse @ 2005-11-17 15:24 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
If a claim fails, the Pegasos firmware pretends it never even made it
into the prom, rather than indicating that it tried and failed.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/boot/prom.c b/arch/powerpc/boot/prom.c
index 4bea2f4..e8a6304 100644
--- a/arch/powerpc/boot/prom.c
+++ b/arch/powerpc/boot/prom.c
@@ -116,6 +116,7 @@ finddevice(const char *name)
void *
claim(unsigned long virt, unsigned long size, unsigned long align)
{
+ int ret;
struct prom_args {
char *service;
int nargs;
@@ -132,7 +133,11 @@ claim(unsigned long virt, unsigned long
args.virt = virt;
args.size = size;
args.align = align;
- (*prom)(&args);
+ ret = (*prom)(&args);
+ /* The original Pegasos II firmware claims that the call never made
+ it into the prom, rather than returning failure correctly */
+ if (ret)
+ return (void *)-1;
return args.ret;
}
--
dwmw2
^ permalink raw reply related
* RE: Booting hangs after "Calibrating delay loop..."
From: Jaap de Jong @ 2005-11-17 15:04 UTC (permalink / raw)
To: linuxppc-embedded
Hi Binh,
I am working with this fpga too, different board, same linux version,
and not very succesfull until now too...
But my build passes the "Calibrating delay loop..." and prints the
correct value!
Just guessing... perhaps your problem is timer related. Fi no timer
interrupts?
Best regards!
Jaap de Jong
> Hi all,
>=20
> When booting Monta Vista Linux on Memec board
> (Virtex-4 FX12 LC), it hung after printing the
> following message:
>=20
> "Calibrating delay loop..."
>
> By looking at the source code, I found that in the
> init/main.c the problem came from the
> calibrate_delay()
> function: jiffies was not incremented (jiffies was
> always equal to 0).
>
> Have anyone get the similar problem or any experience
> to fix it?
^ permalink raw reply
* Re: 11-16-05 2.6.14 on AMCC Yosemite board(PCI-IDE card boot error)
From: Stefan Roese @ 2005-11-17 15:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051116121846.1C1BD1FD0@smtp.263.net>
Hi Kylong,
On Wednesday 16 November 2005 13:18, KylongMu wrote:
> Dear Denk,
BTW: It's either Wolfgang or Mr. Denk.
> Thanks for your help; it makes my Yosemite run up! I'm try to add a
> PCI-IDE
>
> Card on it. I test my Promise-PDC20268 card and AEC6280 (ATP865-B chip
> type) card,
>
> Both of them all failed with same error, the boot message included in the
> attachment.
Sorry, but we don't have such a PCI IDE controller available. So we did test
with a Promise SATA controller:
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ata1: SATA max UDMA/133 cmd 0xD1008200 ctl 0xD1008238 bmdma 0x0 irq 25
ata2: SATA max UDMA/133 cmd 0xD1008280 ctl 0xD10082B8 bmdma 0x0 irq 25
ata3: SATA max UDMA/133 cmd 0xD1008300 ctl 0xD1008338 bmdma 0x0 irq 25
ata4: SATA max UDMA/133 cmd 0xD1008380 ctl 0xD10083B8 bmdma 0x0 irq 25
ata1: no device found (phy stat 00000000)
scsi0 : sata_promise
ata2: no device found (phy stat 00000000)
scsi1 : sata_promise
ata3: no device found (phy stat 00000000)
scsi2 : sata_promise
ata4: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48
ata4: dev 0 configured for UDMA/133
scsi3 : sata_promise
Vendor: ATA Model: Maxtor 7Y250M0 Rev: YAR5
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sda: drive cache: write back
sda: sda1
sd 3:0:0:0: Attached scsi disk sda
...
bash-3.00# lspci -v
00:0c.0 Class 0180: 105a:3d18 (rev 02)
Subsystem: 105a:3d18
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 25
I/O ports at ff80 [size=128]
I/O ports at fe00 [size=256]
Memory at 00000000affff000 (32-bit, non-prefetchable) [size=4K]
Memory at 00000000affc0000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 0000000000080000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
bash-3.00# cat /proc/scsi/scsi
Attached devices:
Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Maxtor 7Y250M0 Rev: YAR5
Type: Direct-Access ANSI SCSI revision: 05
bash-3.00# fdisk -l /dev/sda
Disk /dev/sda: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 30515 245111706 83 Linux
bash-3.00# mke2fs -m0 -j /dev/sda1
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
30654464 inodes, 61277926 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=62914560
1871 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
bash-3.00# mount /dev/sda1 /mnt
mount: unknown filesystem type 'ext3'
bash-3.00# mount -t ext2 /dev/sda1 /mnt
EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as
ext2
bash-3.00# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 231G 189M 230G 1% /mnt
bash-3.00# cd /tmp/bonnie
bash-3.00# ./Bonnie -m yosemite -s 256 -d /mnt
Bonnie 1.4: File '/mnt/Bonnie.423', size: 268435456, volumes: 1
Writing with putc()... done: 4492 kB/s 99.5 %CPU
Rewriting... done: 9576 kB/s 12.4 %CPU
Writing intelligently... done: 17375 kB/s 12.9 %CPU
Reading with getc()... done: 4278 kB/s 95.6 %CPU
Reading intelligently... done: 49108 kB/s 41.4 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential Input-- --Rnd
Seek-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k
(03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
%CPU
yosemi 1* 256 4492 99.5 17375 12.9 9576 12.4 4278 95.6 49108 41.4 2395.4
27.3
Everything is working fine with this PCI board. So it can't be a Yosemite
related problem. Sorry, can't help you here.
Best regards,
Stefan
^ permalink raw reply
* Re: help
From: Wolfgang Denk @ 2005-11-17 14:04 UTC (permalink / raw)
To: prabha.j; +Cc: linuxppc-embedded
In-Reply-To: <OFF101A064.257D1AD3-ON652570BC.0020DC73-652570BC.002126C8@tcs.com>
In message <OFF101A064.257D1AD3-ON652570BC.0020DC73-652570BC.002126C8@tcs.com> you wrote:
>
> I am trying to build kernel image for my custom borad which is similar to
> mpc8260ads board. But i am getting the error.
"Similar to" means "not exactly the same", so you should not expect
that the code runs unchanged. As a minimum, you must carefully select
a configuration that matches your board.
...
> arch/ppc/kernel/entry.S: undefined reference to `__res'
Fix this!
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
"Nature is very un-American. Nature never hurries."
- William George Jordan
^ permalink raw reply
* Re: [REQUEST] Tap for right click on PowerBook trackpad
From: Olivier Mehani @ 2005-11-17 12:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200511171234.31085.lkml@oxley.org>
[-- Attachment #1: Type: text/plain, Size: 973 bytes --]
On Thu, 17 Nov 2005 12:34:29 +0000
Felix Oxley <lkml@oxley.org> wrote:
> Actually, ububtu which I was experimenting with had this feature
> enabled by default. However I find it extremely cumbersome to have to
> remove my hand form the trackpad in order to press F12.
If I'm not mistaken, the default mapping are fn+Alt for right click and
fn+Ctrl for middle click, which I find much more convenient than F11
and F12 on my iBook (closer to the trackpad).
> I believe the Linux trackpad driver can do other specail action such
> as 'click and drag' or something similar. Therefore I was/am hoping
> that implementing tap for right click would be possible.
I'm adding my own question as it is almost the same topic:
Is it possible to have the same behavior as with synaptics touchpads
(scrolling) ? I've googled but didn't find any sure answer.
--
Olivier Mehani <shtrom@ssji.net>
PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8555 USB host support
From: Yuli Barcohen @ 2005-11-17 12:34 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Jonathan Masel, 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <437B56E7.5090109@ru.mvista.com>
>>>>> Vitaly Bordug writes:
...
Vitaly> I also have a bunch of patches for gregkh, supporting serial
Vitaly> function, but they need nontrivial cleanup I do not have
Vitaly> time currently for. So I think I grab this one together with
Vitaly> my stuff when I head for it.
Kumar> Also, are you aware of Freescale's driver for this?
Vitaly> I used to try arabella one (came with MW bsp) but that
Vitaly> version does not work with 8272.
If so, it's a very old version. The driver works with any MPC82xx (and
MPC885, BTW). Also, please remember that many Freescale ADS boards have
hardware problems (depending on the board's revision).
Vitaly> If there are something usable, it will be interesting to
Vitaly> look at.
...
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ 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