* Re: VME driver problem on MVME6100
From: Xavier Grave @ 2006-05-24 19:44 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310605241005q1987845di@mail.gmail.com>
Hi,
Perhaps the size of the window you want is too big ?
I have only experience with MVME5100 and 5500 so I can only guess that.
xavier
Le mercredi 24 mai 2006 à 19:05 +0200, Konstantin Boyanov a écrit :
> Hi there,
>
> These days I'm trying to "bring up" a VME driver on a Motorola SBC but
> I'm getting in some troubles.
> Actually there are no problems with the driver itself, methinks, it
> loads correctly and everithing seems to be fine.
> But when I try to create an outbound window, in order to "talk" some
> other boards in the crate I get this:
>
> __ioremap(): phys addr 01000000 is RAM lr d100be34
> mode 0
> vmedrv: No memory for outbound window
> testout: VME_IOCTL_SET_OUTBOUND failed. Errno = 12
>
> I'm not sure I understand all of this anyways... Except that there is
> no sufficient memory to map for the outbound window.
> That's what this test is supposed to do is to open the appropriate
> devices for the VME bus (in this case /dev/vme_m[0-7]), configure the
> outbound windows from 0 through 6 (the 7th is reserved) and then
> verifies that data can be read through these outbound windows.
> I'm using an VME driver downloaded from vmelinux.org and here is the
> source of the test program I'm trying to run ->
> http://www-zeuthen.desy.de/~boyanov/testOutWindow.txt
>
> I'm sorry for the newb question, but any ideas what is going wrong?
> Thank you.
>
> Kind regards,
> Konstantin Boyanov
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Wolfgang Denk @ 2006-05-24 19:57 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr>
In message <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr> you wrote:
>
> I have a MPC8260 processor card with a Coral-P evaluation board (rev 4.0).
> My system do not have keyboard nor mouse (i use the serial console).
>
> I use linux kernel 2.4.25 & 2.6.9.
We have instructions on our web site; did you read these?
> I'm trying to get the framebuffer driver to work. During the boot the
> driver loads fine but the monitor remains blank (no video signal). If i
> try to `cat /dev/urandom > /dev/fb/0` nothing happens.
Are you using devfs? Don't! Use /dev/fb0
> I compiled an Xserver (Release 6.9), and the x11 drivers for the coralp.
> When I start X, it says that it can not open tty0 (indeed it doesn't
> exists).
Well, you got an error message (tty0 cannot be opened), you verified
that it is valid (tty0 does not exist), so fix the problem...
> For kernel 2.6.9 :
Can't comment on Coreal-P on 2.6.x
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
War is never imperative.
-- McCoy, "Balance of Terror", stardate 1709.2
^ permalink raw reply
* Re: Question about IRQs on MPC8540
From: Kumar Gala @ 2006-05-24 19:40 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: linuxppc-embedded
In-Reply-To: <4474B4F7.9000204@broadcom.com>
On May 24, 2006, at 2:33 PM, Travis B. Sawyer wrote:
> I sent this to Kumar, should have sent directly to the list...
I guess I'll reply to both :)
> I'm porting our kernel base from 2.4->2.6 for our boards and an ODM
> board.
> The ODM board is board that is based off of the 8540 ADS.
>
> I'm having a bit of a problem understanding what went on btw 2.6.12
> and
> 2.6.16.16 wrt
> the 85xx interrupts.
>
> For example, in 2.6.12 I had external interrupts as follows:
> {0, MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0}, /* The bridge */
> {MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0, 0}, /*
> Cardbus */
> {MPC85xx_IRQ_EXT6, 0, 0, 0}, /* IDSEL 18
> -- QE */
> {MPC85xx_IRQ_EXT5, 0, 0, 0}, /* neo2 FE */
> {MPC85xx_IRQ_EXT9, 0, 0, 0}, /* neo3 FE
> egress */
> {MPC85xx_IRQ_EXT10, 0, 0, 0}, /* neo3 FE
> ingress IDSEL 21 */
> Where ext2 was 98, ext3 was 99, etc.
>
> With the newer 2.6.16.16 kernel, I see
> ext2 is 50, ext3 51, etc.
>
> mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.0
> mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.1
> mpc85xx_map_irq: res: 54 for idsel 18 pin 1 0:18.0
> mpc85xx_map_irq: res: 53 for idsel 19 pin 1 0:19.0
> mpc85xx_map_irq: res: 50 for idsel 16 pin 2 1:1.0
> mpc85xx_map_irq: res: 51 for idsel 16 pin 3 1:1.1
This is because we most likely removed the offset that was added to
the IRQs. This is done via MPC85xx_OPENPIC_IRQ_OFFSET, its really
intended to reserve a range for CPM and/or i8259 interrupts. On a
normal 8540 board setting it to 0 is fine.
> The problem is that when the PCI device drivers request the irq, it
> fails.
> Sandburst Thin Driver 1.1.0 May 24 2006 loaded
> Support available from http://www.sandburst.com
> sbthin: sb/ife0 (241/0) at 0xea3e0000, device 19
> sbthin_init_one:sb/ife0 request irq failed with -38
what is the IRQ its trying to request?
> and
>
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:01:01.0, mfunc 0x00001000, devctl 0x66
> Yenta: request_irq() in yenta_probe_cb_irq() failed!
> Yenta TI: socket 0000:01:01.0 no PCI interrupts. Fish. Please report.
> Yenta: no PCI IRQ, CardBus support disabled for this socket.
>
>
> Can you give me some pointers where to look? I've been scouring the
> changes and can't
> really put my finger on it.
What does your map_irq function look like?
- k
^ permalink raw reply
* Question about IRQs on MPC8540
From: Travis B. Sawyer @ 2006-05-24 19:33 UTC (permalink / raw)
To: linuxppc-embedded
I sent this to Kumar, should have sent directly to the list...
I'm porting our kernel base from 2.4->2.6 for our boards and an ODM board.
The ODM board is board that is based off of the 8540 ADS.
I'm having a bit of a problem understanding what went on btw 2.6.12 and
2.6.16.16 wrt
the 85xx interrupts.
For example, in 2.6.12 I had external interrupts as follows:
{0, MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0}, /* The bridge */
{MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0, 0}, /* Cardbus */
{MPC85xx_IRQ_EXT6, 0, 0, 0}, /* IDSEL 18 -- QE */
{MPC85xx_IRQ_EXT5, 0, 0, 0}, /* neo2 FE */
{MPC85xx_IRQ_EXT9, 0, 0, 0}, /* neo3 FE egress */
{MPC85xx_IRQ_EXT10, 0, 0, 0}, /* neo3 FE
ingress IDSEL 21 */
Where ext2 was 98, ext3 was 99, etc.
With the newer 2.6.16.16 kernel, I see
ext2 is 50, ext3 51, etc.
mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.0
mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.1
mpc85xx_map_irq: res: 54 for idsel 18 pin 1 0:18.0
mpc85xx_map_irq: res: 53 for idsel 19 pin 1 0:19.0
mpc85xx_map_irq: res: 50 for idsel 16 pin 2 1:1.0
mpc85xx_map_irq: res: 51 for idsel 16 pin 3 1:1.1
The problem is that when the PCI device drivers request the irq, it fails.
Sandburst Thin Driver 1.1.0 May 24 2006 loaded
Support available from http://www.sandburst.com
sbthin: sb/ife0 (241/0) at 0xea3e0000, device 19
sbthin_init_one:sb/ife0 request irq failed with -38
and
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:01:01.0, mfunc 0x00001000, devctl 0x66
Yenta: request_irq() in yenta_probe_cb_irq() failed!
Yenta TI: socket 0000:01:01.0 no PCI interrupts. Fish. Please report.
Yenta: no PCI IRQ, CardBus support disabled for this socket.
Can you give me some pointers where to look? I've been scouring the
changes and can't
really put my finger on it.
thanx in advance,
travis
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Rick Moleres @ 2006-05-24 18:52 UTC (permalink / raw)
To: Ming Liu, rick.moleres; +Cc: linuxppc-embedded
Ming,
Another option for you may be to get MontaVista's latest linuxppc-2.4 =
kernel tree from source.mvista.com (using rsync), which I believe has =
the xilinx_gige directory and menuconfig entries.
-Rick
-----Original Message-----
From: Ming Liu [mailto:eemingliu@hotmail.com]=20
Sent: Wednesday, May 24, 2006 12:36 PM
To: rick.moleres
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: question about linux with Xilinx ML-403
Dear Rick,
OK. I will try that. However I cannot promise to finish this very soon=20
because I am a novice. :) I will let you know if there is any result.
Thanks for your method.
BR
Ming
>From: "Rick Moleres" <rick.moleres@xilinx.com>
>To: "Ming Liu" <eemingliu@hotmail.com>, "rick.moleres"=20
<rick.moleres@xilinx.com>
>CC: <linuxppc-embedded@ozlabs.org>
>Subject: RE: question about linux with Xilinx ML-403
>Date: Wed, 24 May 2006 10:25:10 -0600
>
>
>
>Ming,
>
>
>
>
>
> >Our best recommendation is to use the drivers/net/xilinx_enet =
directory
>
> >for the temac driver and just enable the Xilinx 10/100 Ethernet in
>
> >menuconfig.
>
>
>
>I am not so clear with this. Do you mean that I just copy the source
>code
>
>in the directory of xilinx_gige generated by EDK into the directory of
>
>xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet
>in
>
>the menuconfig? Can this method realize the 1000M ethernet? The source
>code
>
>file names for Temac (xtemac_xxx.c or .h) are different with the ones
>for
>
>emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the
>linux
>
>kernel?
>
>
>
>Right - you would need to copy the xtemac* files and the Makefile over,
>and would have to change the Makefile to make sure it produces
>xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we
>don't think there's any reason this shouldn't work. Can you let us =
know
>how it goes?
>
>
>
>
>
>
>
>
>
_________________________________________________________________
=C3=E2=B7=D1=CF=C2=D4=D8 MSN Explorer: http://explorer.msn.com/lccn/ =20
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-24 18:36 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C02594618@XCO-EXCHVS1.xlnx.xilinx.com>
Dear Rick,
OK. I will try that. However I cannot promise to finish this very soon
because I am a novice. :) I will let you know if there is any result.
Thanks for your method.
BR
Ming
>From: "Rick Moleres" <rick.moleres@xilinx.com>
>To: "Ming Liu" <eemingliu@hotmail.com>, "rick.moleres"
<rick.moleres@xilinx.com>
>CC: <linuxppc-embedded@ozlabs.org>
>Subject: RE: question about linux with Xilinx ML-403
>Date: Wed, 24 May 2006 10:25:10 -0600
>
>
>
>Ming,
>
>
>
>
>
> >Our best recommendation is to use the drivers/net/xilinx_enet directory
>
> >for the temac driver and just enable the Xilinx 10/100 Ethernet in
>
> >menuconfig.
>
>
>
>I am not so clear with this. Do you mean that I just copy the source
>code
>
>in the directory of xilinx_gige generated by EDK into the directory of
>
>xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet
>in
>
>the menuconfig? Can this method realize the 1000M ethernet? The source
>code
>
>file names for Temac (xtemac_xxx.c or .h) are different with the ones
>for
>
>emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the
>linux
>
>kernel?
>
>
>
>Right - you would need to copy the xtemac* files and the Makefile over,
>and would have to change the Makefile to make sure it produces
>xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we
>don't think there's any reason this shouldn't work. Can you let us know
>how it goes?
>
>
>
>
>
>
>
>
>
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Dan Malek @ 2006-05-24 18:31 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr>
On May 24, 2006, at 12:54 PM, jourdan@enib.fr wrote:
> I have a MPC8260 processor card with a Coral-P evaluation board
> (rev 4.0).
Are you sure?
The 8260 does not have a PCI bus and the Coral-P
is a PCI card :-)
Good Luck.
-- Dan
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: Carlos Munoz @ 2006-05-24 18:03 UTC (permalink / raw)
To: Roger Larsson; +Cc: linuxppc-embedded
In-Reply-To: <200605240850.24333.roger.larsson@norran.net>
Roger Larsson wrote:
>On onsdag 24 maj 2006 08.12, sandeep malik wrote:
>
>
>>Hi All...
>>
>> I am trying to run an application compiled with gcc toolchain gcc--3.4.3
>>and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I
>>am getting following error....
>>
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>>
>> I was suspecting this error might be because the hardware is not
>>supporting floating point operations and hence i tried a simple program in
>>which I intentionally did some floating point operation but that program
>>was running as expected.
>>
>>
>No, the warning is more serious than that.
>
>Linux does not save floating point registers when entering kernel.
>It might even optimize not to store/reload when doing a context switch.
>
>If your kernel module is using floating point in your kernel code.
>It will probably work on a processor not having floating point but will
>break in mysterious ways on one supporting hardware floating point.
>
>Do not use floating point in kernel. If you still have to you must take
>extremely care.
> Turn off kernel preemption.
> Save FP registers.
> Do your stuff.
> Reload FP registers.
> Turn on preemption.
>But the question is why would you have to?
>Simple calculations can be done in fixed point, and complex calculations
>does not belong in the kernel.
>
>/RogerL
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
Hi Sandeep,
I had the same problem as you. The processor I was using didn't have fp
support, so what I did was link the kernel with the gcc library and I
got it to work. However, as Roger said it would break on processors with
fp support. In the long run I looked at the floating point calculations
(log2 in my case) and was able to do the same math with fixed point.
Can you post the floating point calculations you need to do ? Someone
here might be able to do the same using fix point.
Thanks,
Carlos
^ permalink raw reply
* [PATCH] ppc32 CPM_UART: various fixes for pq2 uart users
From: Vitaly Bordug @ 2006-05-24 17:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
This fixes various odd things that missed update together with cpm_uart
platform_device move. Unified resources names, restructurisation, etc.
Also, addressed issue with recent phys/virt translation rework. Being
cache-coherent, CPM2's do alloc_bootmem() for the console stuff, and it was
used to treat console buffer descriptor mapping 1:1 (as in CPM1 case),
which is definitely wrong.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/platforms/mpc8272ads_setup.c | 10 +++++-----
arch/ppc/syslib/pq2_devices.c | 16 ++++++++--------
arch/ppc/syslib/pq2_sys.c | 8 ++++----
drivers/serial/cpm_uart/cpm_uart_core.c | 8 +++++---
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
index e62b757..abb7154 100644
--- a/arch/ppc/platforms/mpc8272ads_setup.c
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -279,11 +279,11 @@ static int mpc8272ads_platform_notify(st
static const struct platform_notify_dev_map dev_map[] = {
{
.bus_id = "fsl-cpm-fcc",
- .rtn = mpc8272ads_fixup_enet_pdata
+ .rtn = mpc8272ads_fixup_enet_pdata,
},
{
.bus_id = "fsl-cpm-scc:uart",
- .rtn = mpc
+ .rtn = mpc8272ads_fixup_uart_pdata,
},
{
.bus_id = NULL
@@ -335,15 +335,15 @@ struct platform_device* early_uart_get_p
struct platform_device* pdev = NULL;
if(index) { /*assume SCC4 here*/
pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC4];
- pinfo = &mpc8272<F12>_uart_pdata[1];
+ pinfo = &mpc8272_uart_pdata[fsid_scc4_uart];
} else { /*over SCC1*/
pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC1];
- pinfo = &mpc8272_uart_pdata[0];
+ pinfo = &mpc8272_uart_pdata[fsid_scc1_uart];
}
pinfo->uart_clk = bd->bi_intfreq;
pdev->dev.platform_data = pinfo;
- ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
return NULL;
}
diff --git a/arch/ppc/syslib/pq2_devices.c b/arch/ppc/syslib/pq2_devices.c
index 0636aed..8692d00 100644
--- a/arch/ppc/syslib/pq2_devices.c
+++ b/arch/ppc/syslib/pq2_devices.c
@@ -121,13 +121,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A00,
.end = 0x11A1F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8000,
.end = 0x80ff,
.flags = IORESOURCE_MEM,
@@ -145,13 +145,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A20,
.end = 0x11A3F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8100,
.end = 0x81ff,
.flags = IORESOURCE_MEM,
@@ -169,13 +169,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A40,
.end = 0x11A5F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8200,
.end = 0x82ff,
.flags = IORESOURCE_MEM,
@@ -193,13 +193,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A60,
.end = 0x11A7F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8300,
.end = 0x83ff,
.flags = IORESOURCE_MEM,
diff --git a/arch/ppc/syslib/pq2_sys.c b/arch/ppc/syslib/pq2_sys.c
index 433b0fa..fee8948 100644
--- a/arch/ppc/syslib/pq2_sys.c
+++ b/arch/ppc/syslib/pq2_sys.c
@@ -139,13 +139,13 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "8272",
.mask = 0x0000ff00,
.value = 0x00000c00,
- .num_devices = 11,
+ .num_devices = 12,
.device_list = (enum ppc_sys_devices[])
{
MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
- MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
- MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
- MPC82xx_CPM_USB, MPC82xx_SEC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
+ MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
+ MPC82xx_CPM_I2C, MPC82xx_CPM_USB, MPC82xx_SEC1,
},
},
/* below is a list of the 8280 family of processors */
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 969f949..5cba59a 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1164,14 +1164,16 @@ static int __init cpm_uart_console_setup
struct fs_uart_platform_info *pdata;
struct platform_device* pdev = early_uart_get_pdev(co->index);
- port =
- (struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
- pinfo = (struct uart_cpm_port *)port;
if (!pdev) {
pr_info("cpm_uart: console: compat mode\n");
/* compatibility - will be cleaned up */
cpm_uart_init_portdesc();
+ }
+ port =
+ (struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
+ pinfo = (struct uart_cpm_port *)port;
+ if (!pdev) {
if (pinfo->set_lineif)
pinfo->set_lineif(pinfo);
} else {
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 4b2de08..cdba128 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -213,7 +213,7 @@ int cpm_uart_allocbuf(struct uart_cpm_po
L1_CACHE_ALIGN(pinfo->tx_nrfifos * pinfo->tx_fifosize);
if (is_con) {
mem_addr = alloc_bootmem(memsz);
- dma_addr = mem_addr;
+ dma_addr = virt_to_bus(mem_addr);
}
else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
^ permalink raw reply related
* Can't get CoralP drivers to work
From: jourdan @ 2006-05-24 16:54 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I have a MPC8260 processor card with a Coral-P evaluation board (rev 4.0).
My system do not have keyboard nor mouse (i use the serial console).
I use linux kernel 2.4.25 & 2.6.9.
For kernel 2.4.25 :
I'm trying to get the framebuffer driver to work. During the boot the
driver loads fine but the monitor remains blank (no video signal). If i
try to `cat /dev/urandom > /dev/fb/0` nothing happens.
I compiled an Xserver (Release 6.9), and the x11 drivers for the coralp.
When I start X, it says that it can not open tty0 (indeed it doesn't
exists).
For kernel 2.6.9 :
When I start X, it complains about virtual terminals but doesn't stop. It
loads the x11_mb86290 driver then stop because it can't find a valid
framebuffer driver. Is it mandatory to have the mb86290fb driver worknig
in order to get the x11_mb86290 driver ?
I guess it just a configuration problem but I can figure it out. I added
the support for virtual terminals in my kernel (X seems to need it) but I
don't have ttyN entries in /dev. If I add them manually, they can not be
opened.
Thanks for your help.
^ permalink raw reply
* VME driver problem on MVME6100
From: Konstantin Boyanov @ 2006-05-24 17:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
Hi there,
These days I'm trying to "bring up" a VME driver on a Motorola SBC but I'm
getting in some troubles.
Actually there are no problems with the driver itself, methinks, it loads
correctly and everithing seems to be fine.
But when I try to create an outbound window, in order to "talk" some other
boards in the crate I get this:
__ioremap(): phys addr 01000000 is RAM lr d100be34
mode 0
vmedrv: No memory for outbound window
testout: VME_IOCTL_SET_OUTBOUND failed. Errno = 12
I'm not sure I understand all of this anyways... Except that there is no
sufficient memory to map for the outbound window.
That's what this test is supposed to do is to open the appropriate devices
for the VME bus (in this case /dev/vme_m[0-7]), configure the outbound
windows from 0 through 6 (the 7th is reserved) and then verifies that data
can be read through these outbound windows.
I'm using an VME driver downloaded from vmelinux.org and here is the source
of the test program I'm trying to run ->
http://www-zeuthen.desy.de/~boyanov/testOutWindow.txt<http://www-zeuthen.desy.de/%7Eboyanov/testOutWindow.txt>
I'm sorry for the newb question, but any ideas what is going wrong?
Thank you.
Kind regards,
Konstantin Boyanov
[-- Attachment #2: Type: text/html, Size: 1544 bytes --]
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Rick Moleres @ 2006-05-24 16:25 UTC (permalink / raw)
To: Ming Liu, rick.moleres; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
Ming,
>Our best recommendation is to use the drivers/net/xilinx_enet directory
>for the temac driver and just enable the Xilinx 10/100 Ethernet in
>menuconfig.
I am not so clear with this. Do you mean that I just copy the source
code
in the directory of xilinx_gige generated by EDK into the directory of
xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet
in
the menuconfig? Can this method realize the 1000M ethernet? The source
code
file names for Temac (xtemac_xxx.c or .h) are different with the ones
for
emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the
linux
kernel?
Right - you would need to copy the xtemac* files and the Makefile over,
and would have to change the Makefile to make sure it produces
xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we
don't think there's any reason this shouldn't work. Can you let us know
how it goes?
[-- Attachment #2: Type: text/html, Size: 4973 bytes --]
^ permalink raw reply
* RE: I2C bus issues on MPC8248
From: Belaire, Ron @ 2006-05-24 16:00 UTC (permalink / raw)
To: Laurent Pinchart, hs; +Cc: linuxppc-embedded
I'm also attempting to use the i2c patch on a MPC8247 and have a couple
of questions:
Is i2c-core.c still used with this patch since it appears to be using
the platform bus?
I'm enabling MPC82xx_CPM_I2C and setting platform_notify but never get a
callback. What triggers the callback?
I get /sys/bus/platform/fsl-cpm-i2c appearing but fsl_ic2_probe is never
called. What triggers the probe?
I'm obviously new to the platform bus and think that I am missing
something, so anything would help.
Best regards,
Ron Belaire
-----Original Message-----
From: linuxppc-embedded-bounces+rbelaire=3Dciena.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+rbelaire=3Dciena.com@ozlabs.org] On
Behalf Of Laurent Pinchart
Sent: May 22, 2006 5:06 AM
To: hs@denx.de
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: I2C bus issues on MPC8248
Hi Heiko,
> > I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel.=20
> > The mailing list archives mention a driver for the MPC8260
> > (http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html)
> > which I modified to reflect the memory map differences between the=20
> > MPC8260 and the MPC8248, as mentionned in the e-mail.
> >
> > The good news is that the driver works. The bad news is that it=20
> > doesn't work
>
> OK.
>
> > correctly.
> >
> :-(
> :
> > The Linux I2C layer probes the I2C bus for peripherals when drivers=20
> > are loaded. The probing function writes a single byte with the=20
> > device address and check if the data is acked. I monitored the SCL=20
> > and SDA lines using an
>
> [...]
>
> > Using that code, no data is sent on the bus, the BD_SC_READY bit is=20
> > never cleared and no interrupt is generated. Once again I suspected=20
> > a CPM bug when writing a single byte on the bus, so I increased
cbd_datlen to 2:
> >
> > tbdf[0].cbd_bufaddr =3D __pa(tb);
> > tbdf[0].cbd_datlen =3D 2;
> > tbdf[0].cbd_sc =3D count ? BD_SC_READY | BD_IIC_START :
> > BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
> > BD_SC_LAST | BD_SC_WRAP;
> >
> > This worked, and two bytes were written on the bus, leading me to=20
> > believe that the CPM was at fault.
>
> I don t know, if this is a CPM Bug, but it seems so to me ...
I've contacted Freescale's technical support about that issue. They
answered that 0-byte buffer descriptors are not legal (even though no
documentation states so), and that the address byte is output on the I2C
bus when the next byte is written to the internal TX FIFO, making it
impossible to send a single byte on the bus. Basically, that's a
"feature", and they don't intend to fix it.
> > Has anyone noticed the same behaviour ? Is there a workaround
available ?
> > I tried searching Freescale's website for CPM microcode updates but=20
> > haven't found anything related to the I2C controller.
>
> Yes, Holger Speck had the same problem. He solved it by doing the
> following:
>
> If the cpm_iic_write is called with count =3D 0. He made a read with=20
> count =3D
> 1
>
> I think this is safer than writing 2 Bytes to the Slave.
> Could you try this?
I've tried that with success. The I2C bus still gets stuck from time to
time, I'll try to investigate that.
Thanks for your help.
Best regards,
Laurent Pinchart
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-24 12:30 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded
In-Reply-To: <200605241148.38708.roger.larsson@norran.net>
[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]
>It might be the application who runs, calls kernel for output, drivers used
>for output uses floating point.
>No application running => no floating point exceptions...
Yes even I do agree with this point.....and need ur help how to check this coz
the main reason is that the error is not consistently coming from one particular point but the location keeps on changing......
if we try to debug and remove from one point it start coming from some other point in the application......
>Some driver, most likely your if you have made any yourself is
>using floating point.
>serial, console, ethernet drivers?
No I am not running any such drivers which are new and can be suspected
all the drivers used are fully tested and working well with all other applications...
>pc = 3184 (in hex)
>Now check your System.map
>The routine with the closest lower address is your main suspect,
>the use of inlines can blur this...
>(the task pointer is not that useful, they should have converted it
>to process id)
Even this pc value is very less. I think it should be in the range of c0000000 - c0233e38(range I got from system.map file)....
if we think pc is returning the four LSB's even then it is not giving any such clue
as there are only ISR's defined in arc/ppc/kernel/head.S which are lying close to this address
Regards,
Malik
Roger Larsson <roger.larsson@norran.net> wrote:
On onsdag 24 maj 2006 10.14, you wrote:
> Hi Roger...
> Thanks for your response.....but in my case the application is causing
> this error....
It might be the application who runs, calls kernel for output, drivers used
for output uses floating point.
No application running => no floating point exceptions...
> The result was exactly what is expected.....so i think this is not
> related to floating point but might be some other issue......
Some driver, most likely your if you have made any yourself is
using floating point.
serial, console, ethernet drivers?
>
> Are there any other scenarios which can lead to this message????
Not unless the exception is setup wrong - I would not bet on that.
Lets trace it:
> > floating point used in kernel (task=c0398410, pc=3184)
This message is generated in ./arch/ppc/kernel/head.S
pc = 3184 (in hex)
Now check your System.map
The routine with the closest lower address is your main suspect,
the use of inlines can blur this...
(the task pointer is not that useful, they should have converted it
to process id)
/RogerL
---------------------------------
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
[-- Attachment #2: Type: text/html, Size: 3378 bytes --]
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Stelian Pop @ 2006-05-24 10:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
In-Reply-To: <1148383943.25971.2.camel@johannes>
Le mardi 23 mai 2006 à 13:32 +0200, Johannes Berg a écrit :
> For those who don't know: ams, written by Stelian Pop, is a driver for
> the motion sensor present in some PowerBooks (the series the
> PowerBook5,6 falls into, later ones have a slightly different one the
> driver doesn't handle).
>
> Even though we still don't seem to have a client that can actually use
> this data (something to actually tell the hd to protect itself) I
> updated the ams code to compile against the latest linux kernel
> versions. I also fixed a buglet (the interrupt handler should return
> IRQ_HANDLED even if the init flag isn't set yet since we own the
> interrupts, they can't be shared).
Version 0.3 of ams (from http://popies.net/ams/) already had all those
changes :)
The latest version (0.4) has some additionnal changes (fixes a double
free induced by the use of input_free_device(), some other more cosmetic
changes).
> Stelian and all, how about adding this driver to linux? hdaps seems to
> be there even if it too doesn't serve a useful purpose at this time.
Ah, I wasn't aware that hdaps was already in. Oh, in this case let's
submit it.
Here it comes, along with proper kernel integration (Johannes, I've kept
your Signed-off-by since the code is almost the same, feel free to
disagree loudly if you must :) ).
---
From: Stelian Pop <stelian@popies.net>
This driver provides support for the Apple Motion Sensor (ams),
which provides an accelerometer and other misc. data.
Some Apple PowerBooks (the series the PowerBook5,6 falls into,
later ones have a slightly different one the driver doesn't handle)
are supported. The accelerometer data is readable via sysfs.
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick.
In the future (once the proper API exist in the block layer) this
driver will tell the laptop disk to protect its heads in the event
of a catastrophic fall.
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/hwmon/ams.c | 519 +++++++++++++++++++++++++++++++++++++++++++++++++
drivers/hwmon/Kconfig | 17 +
drivers/hwmon/Makefile | 1
3 files changed, 537 insertions(+)
diff -r e292f327d882 drivers/hwmon/Kconfig
--- a/drivers/hwmon/Kconfig Wed May 24 11:35:02 2006 +0200
+++ b/drivers/hwmon/Kconfig Wed May 24 11:44:34 2006 +0200
@@ -450,6 +450,23 @@ config SENSORS_HDAPS
Say Y here if you have an applicable laptop and want to experience
the awesome power of hdaps.
+config SENSORS_AMS
+ tristate "Apple Motion Sensor (ams)"
+ depends on HWMON && INPUT && PPC32
+ default n
+ help
+ This driver provides support for the Apple Motion Sensor (ams),
+ which provides an accelerometer and other misc. data.
+ Some Apple PowerBooks (the series the PowerBook5,6 falls into,
+ later ones have a slightly different one the driver doesn't handle)
+ are supported. The accelerometer data is readable via sysfs.
+
+ This driver also provides an absolute input class device, allowing
+ the laptop to act as a pinball machine-esque joystick.
+
+ Say Y here if you have an applicable laptop and want to experience
+ the awesome power of ams.
+
config HWMON_DEBUG_CHIP
bool "Hardware Monitoring Chip debugging messages"
depends on HWMON
diff -r e292f327d882 drivers/hwmon/Makefile
--- a/drivers/hwmon/Makefile Wed May 24 11:35:02 2006 +0200
+++ b/drivers/hwmon/Makefile Wed May 24 11:44:34 2006 +0200
@@ -16,6 +16,7 @@ obj-$(CONFIG_SENSORS_ADM1026) += adm1026
obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o
obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o
obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o
+obj-$(CONFIG_SENSORS_AMS) += ams.o
obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_F71805F) += f71805f.o
diff -r e292f327d882 drivers/hwmon/ams.c
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/hwmon/ams.c Wed May 24 11:44:34 2006 +0200
@@ -0,0 +1,519 @@
+/*
+ * Apple Motion Sensor driver
+ *
+ * Copyright (C) 2005 Stelian Pop (stelian@popies.net)
+ *
+ * Clean room implementation based on the reverse engineered OSX driver by
+ * Johannes Berg <johannes@sipsolutions.net>, documentation available at
+ * http://johannes.sipsolutions.net/PowerBook/Apple_Motion_Sensor_Specification
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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.
+ *
+ */
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/input.h>
+#include <linux/kthread.h>
+
+#include <asm/of_device.h>
+#include <asm/pmac_feature.h>
+
+MODULE_DESCRIPTION("Apple Motion Sensor driver");
+MODULE_AUTHOR("Stelian Pop");
+MODULE_LICENSE("GPL");
+
+static unsigned int mouse;
+module_param(mouse, bool, 0);
+MODULE_PARM_DESC(mouse, "enable the input class device on module load");
+
+/* AMS registers */
+#define AMS_COMMAND 0x00 /* command register */
+#define AMS_STATUS 0x01 /* status register */
+#define AMS_CTRL1 0x02 /* read control 1 (number of values) */
+#define AMS_CTRL2 0x03 /* read control 2 (offset?) */
+#define AMS_CTRL3 0x04 /* read control 3 (size of each value?) */
+#define AMS_DATA1 0x05 /* read data 1 */
+#define AMS_DATA2 0x06 /* read data 2 */
+#define AMS_DATA3 0x07 /* read data 3 */
+#define AMS_DATA4 0x08 /* read data 4 */
+#define AMS_DATAX 0x20 /* data X */
+#define AMS_DATAY 0x21 /* data Y */
+#define AMS_DATAZ 0x22 /* data Z */
+#define AMS_FREEFALL 0x24 /* freefall int control */
+#define AMS_SHOCK 0x25 /* shock int control */
+#define AMS_SENSLOW 0x26 /* sensitivity low limit */
+#define AMS_SENSHIGH 0x27 /* sensitivity high limit */
+#define AMS_CTRLX 0x28 /* control X */
+#define AMS_CTRLY 0x29 /* control Y */
+#define AMS_CTRLZ 0x2A /* control Z */
+#define AMS_UNKNOWN1 0x2B /* unknown 1 */
+#define AMS_UNKNOWN2 0x2C /* unknown 2 */
+#define AMS_UNKNOWN3 0x2D /* unknown 3 */
+#define AMS_VENDOR 0x2E /* vendor */
+
+/* AMS commands - use with the AMS_COMMAND register */
+enum ams_cmd {
+ AMS_CMD_NOOP = 0,
+ AMS_CMD_VERSION,
+ AMS_CMD_READMEM,
+ AMS_CMD_WRITEMEM,
+ AMS_CMD_ERASEMEM,
+ AMS_CMD_READEE,
+ AMS_CMD_WRITEEE,
+ AMS_CMD_RESET,
+ AMS_CMD_START,
+};
+
+struct ams {
+ char init; /* has it been initialized ? */
+ int bus; /* i2c bus */
+ int address; /* i2c address */
+ struct i2c_client client; /* i2c client */
+ struct of_device *of_dev; /* sysfs device */
+ char vflag; /* use orient1 or orient2 ? */
+ u32 orient1; /* orientation words */
+ u32 orient2;
+ int irq1; /* first irq line */
+ int irq2; /* second irq line */
+ struct work_struct worker; /* worker thread */
+ struct input_dev *idev; /* input device */
+ int xcalib; /* calibrated null value for x */
+ int ycalib; /* calibrated null value for y */
+ struct task_struct *kthread; /* kthread for input */
+};
+
+static struct ams ams;
+
+static int ams_attach(struct i2c_adapter *adapter);
+static int ams_detach(struct i2c_adapter *adapter);
+
+static struct i2c_driver ams_driver = {
+ .driver = {
+ .name = "ams",
+ .owner = THIS_MODULE,
+ },
+ .attach_adapter = ams_attach,
+ .detach_adapter = ams_detach,
+};
+
+static inline s32 ams_read(u8 reg)
+{
+ return i2c_smbus_read_byte_data(&ams.client, reg);
+}
+
+static inline int ams_write(u8 reg, u8 value)
+{
+ return i2c_smbus_write_byte_data(&ams.client, reg, value);
+}
+
+static int ams_cmd(enum ams_cmd cmd)
+{
+ s32 result;
+ int i;
+
+ ams_write(AMS_COMMAND, cmd);
+ for (i = 0; i < 10; i++) {
+ mdelay(5);
+ result = ams_read(AMS_COMMAND);
+ if (result == 0 || result & 0x80)
+ return 0;
+ }
+ return -1;
+}
+
+static void ams_sensors(s8 *x, s8 *y, s8 *z)
+{
+ u32 orient;
+
+ *x = ams_read(AMS_DATAX);
+ *y = ams_read(AMS_DATAY);
+ *z = ams_read(AMS_DATAZ);
+
+ orient = ams.vflag ? ams.orient2 : ams.orient1;
+ if (orient & 0x80) {
+ s8 tmp = *x;
+ *x = *y;
+ *y = tmp;
+ }
+ if (orient & 0x04)
+ *z = ~*z;
+ if (orient & 0x02)
+ *y = ~*y;
+ if (orient & 0x01)
+ *x = ~*x;
+
+ /* printk(KERN_DEBUG "ams: Sensors (%d, %d, %d)\n", *x, *y, *z); */
+}
+
+static ssize_t ams_show_x(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int retval;
+ s8 x, y, z;
+
+ ams_sensors(&x, &y, &z);
+ retval = snprintf(buf, PAGE_SIZE, "%d\n", x);
+ return retval;
+}
+static DEVICE_ATTR(x, S_IRUGO, ams_show_x, NULL);
+
+static ssize_t ams_show_y(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int retval;
+ s8 x, y, z;
+
+ ams_sensors(&x, &y, &z);
+ retval = snprintf(buf, PAGE_SIZE, "%d\n", y);
+ return retval;
+}
+static DEVICE_ATTR(y, S_IRUGO, ams_show_y, NULL);
+
+static ssize_t ams_show_z(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int retval;
+ s8 x, y, z;
+
+ ams_sensors(&x, &y, &z);
+ retval = snprintf(buf, PAGE_SIZE, "%d\n", z);
+ return retval;
+}
+
+static DEVICE_ATTR(z, S_IRUGO, ams_show_z, NULL);
+
+static int ams_mouse_kthread(void *data)
+{
+ s8 x, y, z;
+
+ while (!kthread_should_stop()) {
+ ams_sensors(&x, &y, &z);
+
+ input_report_abs(ams.idev, ABS_X, x - ams.xcalib);
+ input_report_abs(ams.idev, ABS_Y, y - ams.ycalib);
+
+ input_sync(ams.idev);
+
+ msleep(25);
+ }
+ return 0;
+}
+
+static void ams_mouse_enable(void)
+{
+ s8 x, y, z;
+
+ if (ams.idev)
+ return;
+
+ ams_sensors(&x, &y, &z);
+ ams.xcalib = x;
+ ams.ycalib = y;
+
+ ams.idev = input_allocate_device();
+ if (!ams.idev)
+ return;
+
+ ams.idev->name = "Apple Motion Sensor";
+ ams.idev->id.bustype = BUS_I2C;
+ ams.idev->id.vendor = 0;
+
+ input_set_abs_params(ams.idev, ABS_X, -50, 50, 3, 0);
+ input_set_abs_params(ams.idev, ABS_Y, -50, 50, 3, 0);
+
+ set_bit(EV_ABS, ams.idev->evbit);
+ set_bit(EV_KEY, ams.idev->evbit);
+ set_bit(BTN_TOUCH, ams.idev->keybit);
+
+ if (input_register_device(ams.idev)) {
+ input_free_device(ams.idev);
+ ams.idev = NULL;
+ return;
+ }
+
+ ams.kthread = kthread_run(ams_mouse_kthread, NULL, "kams");
+ if (IS_ERR(ams.kthread)) {
+ input_unregister_device(ams.idev);
+ ams.idev = NULL;
+ return;
+ }
+}
+
+static void ams_mouse_disable(void)
+{
+ if (!ams.idev)
+ return;
+
+ kthread_stop(ams.kthread);
+
+ input_unregister_device(ams.idev);
+
+ ams.idev = NULL;
+}
+
+static ssize_t ams_show_mouse(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", mouse);
+}
+
+static ssize_t ams_store_mouse(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ if (sscanf(buf, "%d\n", &mouse) != 1)
+ return -EINVAL;
+
+ mouse = !!mouse;
+
+ if (mouse)
+ ams_mouse_enable();
+ else
+ ams_mouse_disable();
+
+ return count;
+}
+static DEVICE_ATTR(mouse, S_IRUGO | S_IWUSR, ams_show_mouse, ams_store_mouse);
+
+static void ams_worker(void *data)
+{
+ /* TODO: park hard disk drives like OSX ? */
+ if (ams_read(AMS_FREEFALL) & 0x80)
+ printk(KERN_INFO "ams: freefall interrupt\n");
+ if (ams_read(AMS_SHOCK) & 0x80)
+ printk(KERN_INFO "ams: shock interrupt\n");
+
+ ams_write(AMS_FREEFALL, 0);
+ ams_write(AMS_SHOCK, 0);
+}
+
+static irqreturn_t ams_interrupt(int irq, void *devid, struct pt_regs *regs)
+{
+ if (ams.init)
+ schedule_work(&ams.worker);
+ return IRQ_HANDLED;
+}
+
+static int ams_attach(struct i2c_adapter *adapter)
+{
+ int vmaj, vmin;
+ unsigned long bus;
+
+ if (ams.init)
+ return 0;
+
+ if (strncmp(adapter->name, "uni-n", 5))
+ return -ENODEV;
+ bus = simple_strtoul(adapter->name + 6, NULL, 10);
+ if (bus != ams.bus)
+ return -ENODEV;
+
+ ams.client.addr = ams.address;
+ ams.client.adapter = adapter;
+ ams.client.driver = &ams_driver;
+ strcpy(ams.client.name, "Apple Motion Sensor");
+
+ if (ams_cmd(AMS_CMD_RESET)) {
+ printk(KERN_INFO "ams: Failed to reset the device\n");
+ return -ENODEV;
+ }
+
+ if (ams_cmd(AMS_CMD_START)) {
+ printk(KERN_INFO "ams: Failed to start the device\n");
+ return -ENODEV;
+ }
+
+ /* get version/vendor information */
+ ams_write(AMS_CTRL1, 0x02);
+ ams_write(AMS_CTRL2, 0x85);
+ ams_write(AMS_CTRL3, 0x01);
+
+ ams_cmd(AMS_CMD_READMEM);
+
+ vmaj = ams_read(AMS_DATA1);
+ vmin = ams_read(AMS_DATA2);
+ if (vmaj != 1 || vmin != 52) {
+ printk(KERN_INFO "ams: Incorrect device version (%d.%d)\n",
+ vmaj, vmin);
+ return -ENODEV;
+ }
+
+ ams_cmd(AMS_CMD_VERSION);
+
+ vmaj = ams_read(AMS_DATA1);
+ vmin = ams_read(AMS_DATA2);
+ if (vmaj != 0 || vmin != 1) {
+ printk(KERN_INFO "ams: Incorrect firmware version (%d.%d)\n",
+ vmaj, vmin);
+ return -ENODEV;
+ }
+
+ if (ams_read(AMS_VENDOR) & 0x10)
+ ams.vflag = 1;
+
+ /* write initial values */
+ ams_write(AMS_SENSLOW, 0x15);
+ ams_write(AMS_SENSHIGH, 0x60);
+ ams_write(AMS_CTRLX, 0x08);
+ ams_write(AMS_CTRLY, 0x0F);
+ ams_write(AMS_CTRLZ, 0x4F);
+ ams_write(AMS_UNKNOWN1, 0x14);
+
+ ams_write(AMS_FREEFALL, 0);
+ ams_write(AMS_SHOCK, 0);
+
+ /* enable interrupts */
+ ams_write(AMS_CTRLX, 0x88);
+ ams_write(AMS_CTRLY, 0x8F);
+ ams_write(AMS_CTRLZ, 0xCF);
+
+ if (i2c_attach_client(&ams.client)) {
+ printk(KERN_INFO "ams: Failed to attach the client\n");
+ return -ENODEV;
+ }
+
+ if (mouse)
+ ams_mouse_enable();
+
+ ams.init = 1;
+
+ printk(KERN_INFO "ams: Apple Motion Sensor enabled\n");
+
+ return 0;
+}
+
+static int ams_detach(struct i2c_adapter *adapter)
+{
+ if (!ams.init)
+ return 0;
+
+ if (ams.idev)
+ ams_mouse_disable();
+
+ i2c_detach_client(&ams.client);
+
+ /* disable and ack interrupts */
+ ams_write(AMS_CTRLX, 0x08);
+ ams_write(AMS_CTRLY, 0x0F);
+ ams_write(AMS_CTRLZ, 0x4F);
+ ams_write(AMS_FREEFALL, 0);
+ ams_write(AMS_SHOCK, 0);
+
+ ams.init = 0;
+
+ printk(KERN_INFO "ams: Apple Motion Sensor disabled\n");
+
+ return 0;
+}
+
+static int __init ams_init(void)
+{
+ struct device_node* np;
+ u32 *prop;
+
+ np = of_find_node_by_name(NULL, "accelerometer");
+ if (!np)
+ return -ENODEV;
+ if (!device_is_compatible(np, "AAPL,accelerometer_1"))
+ return -ENODEV;
+
+ prop = (u32 *)get_property(np, "orientation", NULL);
+ if (!prop)
+ return -EIO;
+ ams.orient1 = *prop;
+ ams.orient2 = *(prop + 1);
+
+ prop = (u32 *)get_property(np, "reg", NULL);
+ if (!prop)
+ return -ENODEV;
+
+ /* look for bus either by path or using "reg" */
+ if (strstr(np->full_name, "/i2c-bus@") != NULL) {
+ const char *tmp_bus = (strstr(np->full_name, "/i2c-bus@") + 9);
+ ams.bus = tmp_bus[0]-'0';
+ } else {
+ ams.bus = ((*prop) >> 8) & 0x0f;
+ }
+ ams.address = ((*prop) & 0xff) >> 1;
+
+ np = of_find_node_by_name(NULL, "accelerometer-1");
+ if (!np || np->n_intrs < 1)
+ return -ENODEV;
+
+ ams.irq1 = np->intrs[0].line;
+
+ np = of_find_node_by_name(NULL, "accelerometer-2");
+ if (!np || np->n_intrs < 1)
+ return -ENODEV;
+
+ ams.irq2 = np->intrs[0].line;
+
+ if (request_irq(ams.irq1, ams_interrupt, 0, "accelerometer-1",
+ NULL < 0))
+ return -ENODEV;
+
+ if (request_irq(ams.irq2, ams_interrupt, 0, "accelerometer-2",
+ NULL < 0)) {
+ free_irq(ams.irq1, NULL);
+ return -ENODEV;
+ }
+
+ INIT_WORK(&ams.worker, ams_worker, NULL);
+
+ if ((ams.of_dev = of_platform_device_create(np, "ams", NULL)) == NULL) {
+ free_irq(ams.irq1, NULL);
+ free_irq(ams.irq2, NULL);
+ return -ENODEV;
+ }
+
+ device_create_file(&ams.of_dev->dev, &dev_attr_x);
+ device_create_file(&ams.of_dev->dev, &dev_attr_y);
+ device_create_file(&ams.of_dev->dev, &dev_attr_z);
+ device_create_file(&ams.of_dev->dev, &dev_attr_mouse);
+
+ if (i2c_add_driver(&ams_driver) < 0) {
+ free_irq(ams.irq1, NULL);
+ free_irq(ams.irq2, NULL);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit ams_exit(void)
+{
+ i2c_del_driver(&ams_driver);
+
+ free_irq(ams.irq1, NULL);
+ free_irq(ams.irq2, NULL);
+
+ device_remove_file(&ams.of_dev->dev, &dev_attr_x);
+ device_remove_file(&ams.of_dev->dev, &dev_attr_y);
+ device_remove_file(&ams.of_dev->dev, &dev_attr_z);
+ device_remove_file(&ams.of_dev->dev, &dev_attr_mouse);
+
+ of_device_unregister(ams.of_dev);
+}
+
+module_init(ams_init);
+module_exit(ams_exit);
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Johannes Berg @ 2006-05-24 10:09 UTC (permalink / raw)
To: Stelian Pop; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
In-Reply-To: <1148465069.6723.26.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
On Wed, 2006-05-24 at 12:04 +0200, Stelian Pop wrote:
> Version 0.3 of ams (from http://popies.net/ams/) already had all those
> changes :)
Oh heh. :I downloaded the 2 version a while ago and forgot to check for
updates before fixing it up.
> The latest version (0.4) has some additionnal changes (fixes a double
> free induced by the use of input_free_device(), some other more cosmetic
> changes).
Nice :)
> Here it comes, along with proper kernel integration (Johannes, I've kept
> your Signed-off-by since the code is almost the same, feel free to
> disagree loudly if you must :) ).
:)
Patch looks good, thanks.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: delay programming
From: Li Yang-r58472 @ 2006-05-24 9:48 UTC (permalink / raw)
To: 'tony', linuxppc-embedded
That depends on how accurate you want. Sleep() functions can't be too accurate
for Linux schedule characteristic. To get best accuracy, you can use hardware
timer. udelay() is a choice which reduces the overall system performance.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of tony
> Sent: Wednesday, May 24, 2006 5:24 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: delay programming
>
>
> hi all
> I want to delay 1ms in the program,
> does usleep(1000) works accurate?
> any good idea?
>
> regards
> tony
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: Roger Larsson @ 2006-05-24 9:48 UTC (permalink / raw)
To: sandeep malik, linuxppc-embedded
In-Reply-To: <20060524081447.12399.qmail@web8410.mail.in.yahoo.com>
On onsdag 24 maj 2006 10.14, you wrote:
> Hi Roger...
> Thanks for your response.....but in my case the application is causing
> this error....
It might be the application who runs, calls kernel for output, drivers used
for output uses floating point.
No application running => no floating point exceptions...
> The result was exactly what is expected.....so i think this is not
> related to floating point but might be some other issue......
Some driver, most likely your if you have made any yourself is
using floating point.
serial, console, ethernet drivers?
>
> Are there any other scenarios which can lead to this message????
Not unless the exception is setup wrong - I would not bet on that.
Lets trace it:
> > floating point used in kernel (task=c0398410, pc=3184)
This message is generated in ./arch/ppc/kernel/head.S
pc = 3184 (in hex)
Now check your System.map
The routine with the closest lower address is your main suspect,
the use of inlines can blur this...
(the task pointer is not that useful, they should have converted it
to process id)
/RogerL
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-24 9:46 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C0252AB7B@XCO-EXCHVS1.xlnx.xilinx.com>
Dear Rick,
First, thanks a lot for your information. However I still have something to
ask.
>Our best recommendation is to use the drivers/net/xilinx_enet directory
>for the temac driver and just enable the Xilinx 10/100 Ethernet in
>menuconfig.
I am not so clear with this. Do you mean that I just copy the source code
in the directory of xilinx_gige generated by EDK into the directory of
xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet in
the menuconfig? Can this method realize the 1000M ethernet? The source code
file names for Temac (xtemac_xxx.c or .h) are different with the ones for
emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the linux
kernel?
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-24 9:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148422544.13249.96.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Wed, 2006-05-24 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> > Right, that's how snd-powermac does it. It has the nasty side-effect of
> > polluting the cache a lot though, since dbdma commands are 16 bytes
> > long. Am I wrong?
>
> You don't have that much DBDMA commands that it would pollute the cache
> _a lot_ :)
Ah, yeah, I guess so. Well I do have 32 dbdma commands, them being
spaced up in 16-bytes means 16 cachelines, no? I'm not sure how the
cache is wired up ...
> > Alsa calls this thing the 'pointer' :) The frame counter we currently
> > use is the frame counter register of the i2s bus controller, and I don't
> > see why we shouldn't do that instead of reading back all the dbdma
> > command status fields.
>
> If you manage to have it properly in sync, that may work too.
Seems to work fine so far, even if bcm43xx kills a few interrupts ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-24 9:41 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148395617.3434.0.camel@diesel>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Tue, 2006-05-23 at 09:46 -0500, Hollis Blanchard wrote:
> Yeah, I'm not sure how I was supposed to know that i2sbus was the magic
> module.
Heh, yeah, sorry. Thing is, if you'd have just installed the modules and
rebooted, it would have worked :)
> That seems to be working now. Again, from PowerMac11,2:
Yeah looks fine, except I just fixed a very stupid bug in the i2sbus
module. Please don't try to remove it after loading, until you upgrade
to the current version.
> This is probably just because I loaded all the modules I could find.
I tried changing the tas module to detect if the codec *really is
present*, but failed. There's some code in there, but I'll solicit some
help with that later.
> Volume control does indeed work when the tas module isn't loaded.
Interesting, but good to know. I'd have thought that the fabric would
not take the codec into use. Will see if I can fix that.
> Could you also add a sample modules.conf? For example, users should be
> told to remove snd-powermac.
Good point. Everything else should not be necessary though, since the
i2sbus module should automatically load due to having a macio modalias.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* via-pmu runs device_power_down in atomic context
From: Johannes Berg @ 2006-05-24 8:01 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: cpufreq
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
Hey,
Everytime I suspend my powerbook, I see the following trace:
[10655.887546] BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
[10655.887558] in_atomic():0, irqs_disabled():1
[10655.887562] Call Trace:
[10655.887565] [C581BD20] [C00081E8] show_stack+0x50/0x190 (unreliable)
[10655.887582] [C581BD50] [C0023BB0] __might_sleep+0xcc/0xe8
[10655.887592] [C581BD60] [C0038290] blocking_notifier_call_chain+0x2c/0xc0
[10655.887606] [C581BD80] [C01E90C0] cpufreq_suspend+0x130/0x148
[10655.887616] [C581BDB0] [C019D9E8] sysdev_suspend+0x10c/0x300
[10655.887627] [C581BDF0] [C01A3888] device_power_down+0x74/0xac
[10655.887636] [C581BE10] [C01B1264] pmac_suspend_devices+0x98/0x188
[10655.887643] [C581BE30] [C01B18F0] pmu_ioctl+0x59c/0xbc0
[10655.887649] [C581BED0] [C008E898] do_ioctl+0x80/0x84
[10655.887660] [C581BEE0] [C008E928] vfs_ioctl+0x8c/0x48c
[10655.887666] [C581BF10] [C008ED68] sys_ioctl+0x40/0x74
[10655.887673] [C581BF40] [C000F3A4] ret_from_syscall+0x0/0x38
The might_sleep() comes from down_read() and this happens because
blocking_notifier_call_chain calls it, it is also commented to run in
process context so this is all proper.
However, it obviously isn't run at process context. Looking why, I see
this in via-pmu.c:
/* We can now disable MSR_EE. This code of course works properly only
* on UP machines... For SMP, if we ever implement sleep, we'll have to
* stop the "other" CPUs way before we do all that stuff.
*/
local_irq_disable();
/* Broadcast power down irq
* This isn't that useful in most cases (only directly wired devices can
* use this but still... This will take care of sysdev's as well, so
* we exit from here with local irqs disabled and PIC off.
*/
ret = device_power_down(PMSG_SUSPEND);
Apparently this was a deliberate decision.
So the question is: which is correct? I can test and submit a patch to
fix the issue at either end; if cpufreq is wrong I'd move from a
blocking_ to an atomic_notifier_call_chain, if via-pmu.c is wrong I'd
call device_power_down earlier...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* delay programming
From: tony @ 2006-05-24 9:23 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
hi all
I want to delay 1ms in the program,
does usleep(1000) works accurate?
any good idea?
regards
tony
^ permalink raw reply
* Re:Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-24 8:14 UTC (permalink / raw)
To: linuxppc-embedded, roger.larsson
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
Hi Roger...
Thanks for your response.....but in my case the application is causing this error....this is not coming from any kernel module but a user space application which is creating problem.....and in that application also i have replaced all double occurances with long but still the same error was being flashed......what i suspect is this error is no where related to the usage of floating point as i compiled following code and run the same on the 8325 board and the code was running without any issue.....
#include "stdio.h"
int main()
{
int i=0;
float j= 1.2;
float result;
for(i=0; i<10; i++ )
{
result = result * 2;
}
printf("\n result %f",result);
return 0;
}
The result was exactly what is expected.....so i think this is not related to floating point but might be some other issue......
Are there any other scenarios which can lead to this message????
Regards,
Malik
=====================================================
> Hi All...
>
> I am trying to run an application compiled with gcc toolchain gcc--3.4.3
> and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I
> am getting following error....
>
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
>
> I was suspecting this error might be because the hardware is not
> supporting floating point operations and hence i tried a simple program in
> which I intentionally did some floating point operation but that program
> was running as expected.
No, the warning is more serious than that.
Linux does not save floating point registers when entering kernel.
It might even optimize not to store/reload when doing a context switch.
If your kernel module is using floating point in your kernel code.
It will probably work on a processor not having floating point but will
break in mysterious ways on one supporting hardware floating point.
Do not use floating point in kernel. If you still have to you must take
extremely care.
Turn off kernel preemption.
Save FP registers.
Do your stuff.
Reload FP registers.
Turn on preemption.
But the question is why would you have to?
Simple calculations can be done in fixed point, and complex calculations
does not belong in the kernel.
/RogerL
---------------------------------
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
[-- Attachment #2: Type: text/html, Size: 3599 bytes --]
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-24 7:23 UTC (permalink / raw)
To: Kumar Gala
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
> On May 18, 2006, at 3:05 AM, Zang Roy-r61911 wrote:
>
> >>
> >>> The tsi108 serial port is not a sub node of "soc". well,
> any way, I
> >>> can try soc!
> >>
> >> What is it ? Where is it ? "soc" is a bit of a generic name for
> >> something in the device-tree in fact... we might want to
> define a way
> >> to expose any bus via some kind of soc mecanism even if it's not a
> >> root bus.
> >>
> >>
> > Should I just use add_legacy_soc_port() instead of a new function
> > add_legacy_tsi_port()?
>
> I think seeing your dts will help here. We need to have a
> concept of a "bridge" that may be similar to an "soc".
mpc7448hpc2 dts :
/*
* MPC7448HPC2 (Taiga) board Device Tree Source
*
* Copyright 2006 Freescale Semiconductor Inc.
* 2006 Roy Zang <Roy Zang at freescale.com>.
*
* 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.
*/
/ {
model = "mpc7448hpc2";
compatible = "mpc74xx";
#address-cells = <1>;
#size-cells = <1>;
linux,phandle = <100>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells =<0>;
linux,phandle = <200>;
PowerPC,7448@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K bytes
i-cache-size = <8000>; // L1, 32K bytes
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
32-bit;
linux,phandle = <201>;
linux,boot-cpu;
};
};
memory {
device_type = "memory";
linux,phandle = <300>;
reg = <00000000 20000000 // DDR2 512M at 0
>;
};
tsi108@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "tsi-bridge";
ranges = <00000000 c0000000 00010000>;
reg = <c0000000 00010000>;
bus-frequency = <0>;
i2c@7000 {
interrupt-parent = <7400>;
interrupts = <E 3>;
reg = <7000 400>;
device_type = "i2c";
compatible = "tsi-i2c";
};
mdio@6000 {
device_type = "mdio";
compatible = "tsi-ethernet"; // FIXME
ethernet-phy@6000 {
linux,phandle = <6000>;
interrupt-parent = <7400>;
interrupts = <2 1>;
reg = <6000 50>;
device_type = "ethernet-phy";
};
ethernet-phy@6400 {
linux,phandle = <6400>;
interrupt-parent = <7400>;
interrupts = <2 1>;
reg = <6400 50>;
device_type = "ethernet-phy";
};
};
ethernet@6200 {
#size-cells = <0>;
device_type = "network";
model = "TSI-ETH"; // FIXME
compatible = "tsi-ethernet"; // FIXME
reg = <6200 200>;
address = [ 00 06 D2 00 00 01 ];
interrupts = <10 3 10 3 10 3>;
interrupt-parent = <7400>;
phy-handle = <6000>;
};
ethernet@6600 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSI-ETH"; // FIXME
compatible = "tsi-ethernet"; // FIXME
reg = <6600 200>;
address = [ 00 06 D2 00 00 02 ];
interrupts = <11 3 11 3 11 3>;
interrupt-parent = <7400>;
phy-handle = <6400>;
};
serial@7808 {
device_type = "serial";
compatible = "ns16550";
reg = <7808 200>;
clock-frequency = <3f6b5a00>;
interrupts = <c 3>;
interrupt-parent = <7400>;
};
serial@7c08 {
device_type = "serial";
compatible = "ns16550";
reg = <7c08 200>;
clock-frequency = <3f6b5a00>;
interrupts = <d 3>;
interrupt-parent = <7400>;
};
pic@7400 {
linux,phandle = <7400>;
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
pci@1000 {
compatible = "tsi10x";
device_type = "pci";
linux,phandle = <1000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <1000 1000>;
bus-range = <0 0>;
ranges = <02000000 0 e0000000 e0000000 0 1A000000
01000000 0 00000000 fa000000 0 00010000>;
clock-frequency = <7f28154>;
interrupt-parent = <7400>;
interrupts = <8 0>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 */
8800 0 0 1 7400 24 0
8800 0 0 2 7400 25 0
8800 0 0 3 7400 26 0
8800 0 0 4 7400 27 0
/* IDSEL 0x12 */
9000 0 0 1 7400 25 0
9000 0 0 2 7400 26 0
9000 0 0 3 7400 27 0
9000 0 0 4 7400 24 0
/* IDSEL 0x13 */
9800 0 0 1 7400 26 0
9800 0 0 2 7400 27 0
9800 0 0 3 7400 24 0
9800 0 0 4 7400 25 0
/* IDSEL 0x14 */
a000 0 0 1 7400 27 0
a000 0 0 2 7400 24 0
a000 0 0 3 7400 25 0
a000 0 0 4 7400 26 0
>;
};
};
};
^ 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