[PATCH] [193/2many] MAINTAINERS - FREESCALE SOC FS_ENET DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index e06f478..2ef0ec4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1859,6 +1859,8 @@ M:[EMAIL PROTECTED] L: linuxppc-embedded@ozlabs.org L: [EMAIL PROTECTED] S: Maintained +F: drivers/net/fs_enet/ +F: include/linus/fs_enet_pd.h FREESCALE HIGHSPEED USB DEVICE DRIVER P: Li Yang ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [381/2many] MAINTAINERS - POWERPC 4xx EMAC DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 0d30368..f526cf5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3659,6 +3659,7 @@ W:http://kernel.ebshome.net/emac/ L: linuxppc-embedded@ozlabs.org L: [EMAIL PROTECTED] S: Maintained +F: drivers/net/ibm_emac/ PNP SUPPORT P: Adam Belay ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [194/2many] MAINTAINERS - FREESCALE HIGHSPEED USB DEVICE DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 2ef0ec4..944316a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1868,6 +1868,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linuxppc-embedded@ozlabs.org S: Maintained +F: drivers/usb/gadget/fsl_usb2_udc.c FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
On 12/08/07 13:57 +, Ming Liu wrote:
Dear all,
I am reading LDD(V3) chapter 6 on the topic of wait_event(queue, condition)
and wake_up(queue) functions. I am quite confused on the sayings. One is
Until condition evaluates to a true value, the process continues to
sleep, which looks like that 'condition' is the one who wake up the
process from its sleeping. However the other saying is The basic function
that wakes up sleeping processes is called wake_up, and wake_up wakes up
all processes waiting on the given queue So who is the exact one to wake
the sleeping process up at all, condition or wake_up? From my
understanding, if the condition becomes true, then the sleeping process
will leave its sleeping status and wake up. Then what's the use of wake_up
function?
I understand it this way:
- condition
Just checking the condition is one way (if you don't have a wake_up
source, like an interrupt), but that's not really what wait_event does.
It would be something like
while (condition) {
msleep(10);
}
There was some talk on poll_wait(), but I don't know what happened to
it.
- wake_up
Just wake_up isn't enough, you get a race:
| interrupt handler | process |
--
| do_something() ||
| wake_up() ||
| ... | wait on wq |
And so you have a process waiting on waitqueue, that just missed the
wakeup. Obviously should not be used.
- wake_up condition
| interrupt handler | process |
--
| flag = 1||
| wake_up() ||
| ... | wait_event |
| ... | flag = 0 |
This will work properly and if wait_event misses a wake_up, the
condition check (flag) will kick in before putting it to sleep.
My senario could be described as: in my char device driver, I use one ioctl
command to initiate a DMA transfer. After all related registers are
initiated, this process will be put to sleep for saving CPU cycles. In the
interrupt handler which is for a DMA_done, I wake that process up and
resume its following executing. With this method, in my application program
if I release a DMA initiation command, it is a Blocking operation and it
will wait until the DMA transfer is done.
Looks like you should use the wake_up and condition option.
Domen
Perhaps my question is quite simple or basic. Thanks for any explanation
and comment on this topic in my senario from you experts. Thanks a lot.
Br
Ming
_
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [294/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC8XX
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index e295b18..896c8bf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2821,6 +2821,7 @@ M:[EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/ppc/syslib/ppc8xx* LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [293/2many] MAINTAINERS - LINUX FOR POWERPC BOOT CODE
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 38810b7..e295b18 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2813,6 +2813,7 @@ M:[EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/ppc/boot/ LINUX FOR POWERPC EMBEDDED PPC8XX P: Marcelo Tosatti ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [295/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 896c8bf..a289176 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2829,6 +2829,7 @@ M:[EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/ppc/syslib/ppc83xx_* LINUX FOR POWERPC PA SEMI PWRFICIENT P: Olof Johansson ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 0862965..38810b7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2804,6 +2804,8 @@ M:[EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/ppc/syslib/ppc4xx_* +F: include/asm-ppc/ppc4xx_* LINUX FOR POWERPC BOOT CODE P: Tom Rini ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
Dear Domen,
Thanks for your reply first.
I understand it this way:
- condition
Just checking the condition is one way (if you don't have a wake_up
source, like an interrupt), but that's not really what wait_event does.
It would be something like
while (condition) {
msleep(10);
}
There was some talk on poll_wait(), but I don't know what happened to
it.
So you mean in my senario (wake the process up in the interrupt handler), I
needn't to use wake_up at all? A condition == true in the interrupt
handler is enough to wake the sleeping process up? Am I right?
I checked the source code in linux/wait.h and here is the defination of
wait_event:
#define __wait_event(wq, condition)
do {
DEFINE_WAIT(__wait);
for (;;) { \
prepare_to_wait(wq, __wait, TASK_UNINTERRUPTIBLE);
if (condition)
break;
schedule();
}
finish_wait(wq, __wait);
} while (0)
#define wait_event(wq, condition)
do {
if (condition)
break;
__wait_event(wq, condition);
} while (0)
From the source code, it seems like that this mechanism doesn't use
msleep(), like what you mentioned, to release its executing. Instead, it
uses schedule() to do that.
- wake_up
Just wake_up isn't enough, you get a race:
| interrupt handler | process |
--
| do_something() ||
| wake_up() ||
| ... | wait on wq |
And so you have a process waiting on waitqueue, that just missed the
wakeup. Obviously should not be used.
- wake_up condition
| interrupt handler | process |
--
| flag = 1||
| wake_up() ||
| ... | wait_event |
| ... | flag = 0 |
This will work properly and if wait_event misses a wake_up, the
condition check (flag) will kick in before putting it to sleep.
Thanks for your explaining on the race problem. I can understand this now.
However I still cannot understand, is such a problem: In the above figures
for my case, if flag=1 could wake the process up, then what's the use of
wake_up()? From my understanding if the condition turns true, then the
process which depends on this condition will be waken up. Thus what's the
exact use of wake_up()? Also in my program, I tried to remove wake_up()
sentence and it seems that there is no difference on the result.
Thanks for the explanation.
BR
Ming
_
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [291/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED MPC52XX
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 8282088..0862965 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2795,6 +2795,8 @@ W:http://www.penguinppc.org/ L: [EMAIL PROTECTED] L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/powerpc/platforms/52xx/ +F: include/asm-powerpc/mpc52xx.h LINUX FOR POWERPC EMBEDDED PPC4XX P: Matt Porter ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
On 13/08/07 08:33 +, Ming Liu wrote:
Dear Domen,
Thanks for your reply first.
I understand it this way:
- condition
Just checking the condition is one way (if you don't have a wake_up
source, like an interrupt), but that's not really what wait_event does.
It would be something like
while (condition) {
msleep(10);
}
There was some talk on poll_wait(), but I don't know what happened to
it.
So you mean in my senario (wake the process up in the interrupt handler), I
needn't to use wake_up at all? A condition == true in the interrupt
handler is enough to wake the sleeping process up? Am I right?
No.
Without the wake_up(), wait_event() would (normally) just wait
... and wait... and wait...
When you set your task_state to TASK_{UN,}INTERRUPTIBLE you need to have
a way to wake it up again.
That's why I used msleep(10) in my example. It would check condition every
10 ms.
I checked the source code in linux/wait.h and here is the defination of
wait_event:
#define __wait_event(wq, condition)
do {
DEFINE_WAIT(__wait);
for (;;) { \
prepare_to_wait(wq, __wait, TASK_UNINTERRUPTIBLE);
if (condition)
break;
schedule();
}
finish_wait(wq, __wait);
} while (0)
#define wait_event(wq, condition)
do {
if (condition)
break;
__wait_event(wq, condition);
} while (0)
From the source code, it seems like that this mechanism doesn't use
msleep(), like what you mentioned, to release its executing. Instead, it
uses schedule() to do that.
msleep() was just an example of how to do polling wait. Didn't mean to
confuze you there, sorry.
- wake_up
Just wake_up isn't enough, you get a race:
| interrupt handler | process |
--
| do_something() ||
| wake_up() ||
| ... | wait on wq |
And so you have a process waiting on waitqueue, that just missed the
wakeup. Obviously should not be used.
- wake_up condition
| interrupt handler | process |
--
| flag = 1||
| wake_up() ||
| ... | wait_event |
| ... | flag = 0 |
This will work properly and if wait_event misses a wake_up, the
condition check (flag) will kick in before putting it to sleep.
Thanks for your explaining on the race problem. I can understand this now.
However I still cannot understand, is such a problem: In the above figures
for my case, if flag=1 could wake the process up, then what's the use of
wake_up()? From my understanding if the condition turns true, then the
process which depends on this condition will be waken up. Thus what's the
exact use of wake_up()? Also in my program, I tried to remove wake_up()
sentence and it seems that there is no difference on the result.
As explained above, flag = 1 does not wake up the process, it just makes
sure you don't have miss-the-wakeup race.
Domen
Thanks for the explanation.
BR
Ming
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
On Monday 13 August 2007 11:22, Ming Liu wrote: Dear Momen, OK. I see now. So you mean condition is only to judge whether a sleeping process could be waken up or not when wake_up() is executed in other processes or interrupt handlers. What really wakes the process up is still the function of wake_up, right? We just execute wake_up() and then check if condition is true. If yes, the process will leave its sleeping and wake up; if not, it keep sleeping. Am I right? Actually, the process will wake up every time you call wake_up(). It will then evaluate the condition. If the condition is true, the process will return from wait_event. If the condition is false, it will go back to sleep. Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
On 13/08/07 09:22 +, Ming Liu wrote: Dear Momen, OK. I see now. So you mean condition is only to judge whether a sleeping process could be waken up or not when wake_up() is executed in other processes or interrupt handlers. What really wakes the process up is still the function of wake_up, right? We just execute wake_up() and then check if condition is true. If yes, the process will leave its sleeping and wake up; if not, it keep sleeping. Am I right? Right. Domen ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
Thank you so much for your explanation. Now I am quite clear on this topic. Domen, Sorry for my misspelling of your name. That should be Domen not Momen. Sorry for that. :) BR Ming From: Domen Puncer [EMAIL PROTECTED] To: Ming Liu [EMAIL PROTECTED] CC: Linuxppc-embedded@ozlabs.org Subject: Re: basic and stupid question on wait_event and wake_up Date: Mon, 13 Aug 2007 11:31:07 +0200 On 13/08/07 09:22 +, Ming Liu wrote: Dear Momen, OK. I see now. So you mean condition is only to judge whether a sleeping process could be waken up or not when wake_up() is executed in other processes or interrupt handlers. What really wakes the process up is still the function of wake_up, right? We just execute wake_up() and then check if condition is true. If yes, the process will leave its sleeping and wake up; if not, it keep sleeping. Am I right? Right. Domen _ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
On Sun, 12 Aug 2007 23:31:11 -0700 [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 0862965..38810b7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2804,6 +2804,8 @@ M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/ppc/syslib/ppc4xx_* +F: include/asm-ppc/ppc4xx_* You're missing arch/ppc/platforms/4xx/, among other things. Also, we're in the middle of merging 4xx to arch/powerpc. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Power Managment (mpc83xx)
I have mpc83xx, and I work with Linux 2.6 I am trying to use power management states. I succeed to get into D1 state (echo standby /sys/power/state), And to waked up by GPIO. But when I try tried echo mem /sys/power/state it waked up by reset (that stuck in the middle) Or echo disk /sys/power/state didn't went to sleep at all. There is a way to get into economic power state (less power then D1 (standby)) and to wake up fast? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
PCI BAR mapping problem
Hello, I am having some problems with the initialization of BAR registers of the PCI bus. I have a number of devices connected to the bus, which have a BAR-size of less than PAGE_SIZE. For example: 01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01) Subsystem: PLX Technology, Inc.: Unknown device 9656 Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52 Memory at dfeffe00 (32-bit, non-prefetchable) [size=512] I/O ports at e000 [size=256] Memory at dfeffdc0 (32-bit, non-prefetchable) [size=64] Memory at d800 (32-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 0 Capabilities: [48] #00 [0080] I want to access the PCI-areas from from user space, so I try to do an mmap. The returned address is however rounded to multiple of PAGE_SIZE (=0x1000). To access for example BAR0, I have to use the return-value from mmap+0xE00. And in the above case, I am able to access the BAR0 and BAR2 areas with only 1 mmap cal, as the 2 addresses are within one page. The problem is that, when running my code on a I386 platform the BAR registers are mapped at address 0x0 of the returned area. When looking at the PCI init code (arch/ppc/syslib/pci_auto.c) I see that the BAR-base address and/or size is not corrected for PAGE_SIZE. Is this correct behaviour? I could image the following line being changed from: bar_value = (*upper_limit - bar_size) ~(bar_size - 1); to: bar_value = ((*upper_limit - bar_size) ~(bar_size - 1)) ~(PAGE_SIZE-1); The PCI area is assigned using a top-down method. Using this statement the bar_value is rounded down to the first PAGE_SIZE boundary. This gives the following output: 01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01) Subsystem: PLX Technology, Inc.: Unknown device 9656 Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52 Memory at dfeff000 (32-bit, non-prefetchable) [size=512] I/O ports at e0fff000 [size=256] Memory at dfefe000 (32-bit, non-prefetchable) [size=64] Memory at d800 (32-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 0 Capabilities: [48] #00 [0080] Kind regards, Johan Borkhuis ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC755 L2 Cache data parity error
Did you ever solve this problem? I have a module with a similar architecture as the one you described and I can get this same data parity failure just by making the L2 cache private memory and copying a file into the L2 cache. Thanks Chuck Brown ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC5200 and Bestcomm
We're starting a new MPC5200 project and I'm trying to track down the best kernel to start from. Is Sylvain's tree at http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs from the web page don't work. Everything 5200 related in the trees at Secret Labs already appears to be merged. Most of this work also appears to be in the Open Embedded tree's Ekifa support. Is that a better place to start? I need to get multiple I2S ports running with DMA. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Power Managment (mpc83xx)
On Mon, Aug 13, 2007 at 02:44:50PM +0300, Yoni Levin wrote: I have mpc83xx, and I work with Linux 2.6 I am trying to use power management states. I succeed to get into D1 state (echo standby /sys/power/state), That's actually closer to D3hot than D1. It uses sleep mode, but does not power down the core. And to waked up by GPIO. But when I try tried echo mem /sys/power/state it waked up by reset (that stuck in the middle) You need u-boot support to resume from deep sleep on 831x. See the code in the mpc8313erdb board files. Or echo disk /sys/power/state didn't went to sleep at all. There's no support for suspend-to-disk in my patchset. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
On 8/13/07, Jon Smirl [EMAIL PROTECTED] wrote: We're starting a new MPC5200 project and I'm trying to track down the best kernel to start from. Is Sylvain's tree at http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs from the web page don't work. Everything 5200 related in the trees at Secret Labs already appears to be merged. Most of this work also appears to be in the Open Embedded tree's Ekifa support. Is that a better place to start? It might be. The major problem with MPC5200 is the Ethernet driver. I believe both Domen and Sylvain have been working on drivers suitable for arch/powerpc inclusion. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
On 8/13/07, Grant Likely [EMAIL PROTECTED] wrote: On 8/13/07, Jon Smirl [EMAIL PROTECTED] wrote: We're starting a new MPC5200 project and I'm trying to track down the best kernel to start from. Is Sylvain's tree at http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs from the web page don't work. Everything 5200 related in the trees at Secret Labs already appears to be merged. Most of this work also appears to be in the Open Embedded tree's Ekifa support. Is that a better place to start? It might be. The major problem with MPC5200 is the Ethernet driver. I believe both Domen and Sylvain have been working on drivers suitable for arch/powerpc inclusion. OpenEmbedded has this series against 2.6.20 0001-powerpc-serial-Dispose-irq-mapping-when-done-in-mpc52xx_serial.c.txt 0003-powerpc-Add-device-tree-fixups-for-the-EFIKA.txt 0004-powerpc-Use-common-52xx-of_platform-probe-code-for-EFIKA.txt 0005-powerpc-Restore-proper-link-order-in-platform.txt 0006-Rework-the-OHCI-quirk-mecanism-as-suggested-by-David.txt 0007-Implement-support-for-split-endian-OHCI.txt 0008-ohci-Rework-bus-glue-integration-to-allow-several-at-once.txt 0009-ohci-Add-support-for-OHCI-controller-on-the-of_platform-bus.txt 0010-libata-Add-support-for-the-MPC52xx-ATA-controller.txt 0011-ohci-Whitespace-and-typo-fix-in-ohci-ppc-of.c.txt 0012-ata-Fix-pata_mpc52xx.c-compatible-list.txt 0013-powerpc-serial-Fix-mpc52xx_uart.c-compatible-list.txt 0014-powerpc-Small-cleanup-of-EFIKA-platform.txt 0015-powerpc-Add-a-unified-uevent-handler-for-bus-based-on-of_device.txt 0016-macintosh-Use-the-new-of_device-common-uevent-handler.txt 0017-powerpc-Add-uevent-handler-for-of_platform_bus.txt 0018-powerpc-Add-uevent-handler-for-ibmebus.txt 0019-MPC5200-Bestcomm-platform-driver.txt 0020-Fec-MPC5200-eth-driver.txt 0021-POWERPC-Copy-bestcomm-support-files-into-arch-powerpc.txt 0022-MPC52xx-PCI-now-working-on-lite5200.-ugly-but-working.txt 0023-POWERPC-Make-FEC-work-on-the-lite5200.txt 0024-Add-missing-function-prototype.txt 0025-POWERPC-Misc-EFIKA-fixups-for-rtas-chrp.txt 0026-POWERPC-Cleanup-mpc52xx-PCI-support.txt 0027-POWERPC-Change-name-of-mpc52xx-pci-support-file-in-Makefile.txt 0028-POWERPC-Change-link-order-so-mpc52xx-fec-always-shows-up-as-eth0.txt 0029-POWERPC-Fixup-pr_print-format-for-mpc52xx-pci-support.txt 0030-POWERPC-Add-mpc52xx-lite5200-PCI-support.txt 0031-sound-Add-support-for-the-MPC52xx-PSC-AC97-Link.txt 0032-POWERPC-EFIKA-Adds-missing-interrupts-from-bestcomm-node.txt 0033-EFIKA-fullduplex-prpl_aln.txt defconfig v4l.diff -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
Another series is being posted to the Efika boards. 0001-powerpc-exports-rheap-symbol-to-modules.patch 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch 0005-powerpc-BestcComm-ATA-task-support.patch 0006-powerpc-BestcComm-FEC-task-support.patch 0007-powerpc-BestcComm-GenBD-task-support.patch 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch 0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch 0082-powerpc-pata_mpc52xx-suspend.patch -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote: You're missing arch/ppc/platforms/4xx/, among other things. Also, we're in the middle of merging 4xx to arch/powerpc. We can leave the whole block unmodified until you're ready. LINUX FOR POWERPC EMBEDDED PPC4XX P: Matt Porter M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
On Mon, 13 Aug 2007 10:35:01 -0700 Joe Perches [EMAIL PROTECTED] wrote: On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote: You're missing arch/ppc/platforms/4xx/, among other things. Also, we're in the middle of merging 4xx to arch/powerpc. We can leave the whole block unmodified until you're ready. LINUX FOR POWERPC EMBEDDED PPC4XX P:Matt Porter M:[EMAIL PROTECTED] W:http://www.penguinppc.org/ L:linuxppc-embedded@ozlabs.org S:Maintained Yeah. I would actually prefer that, thanks. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
The current (2.6.22) patchset for the Efika is being held here for the moment; http://dev.gentoo.org/~nixnut/efika/ That's everything you 'really need' and it's probably the same as this patch list. However practically none of it is mainline-worthy at the moment, Sylvain has detailed too many things he thinks is wrong with it. I'm having a go with the new ethernet driver patch right now (a customer asked me for a prebuilt kernel..) so I can get on with testing that. The most important ones for rewrites besides that are the AC97 driver (which is a little.. sparse) and actually using the ATA task. I'll put in a decent request here for any work on this subject to please at least attempt to retrieve the tasks from the Efika firmware rather than replacing them in Linux gratuituously. I understand this doesn't help the Lite5200 guys.. but.. pretty please with a cherry on top? :] -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Jon Smirl wrote: Another series is being posted to the Efika boards. 0001-powerpc-exports-rheap-symbol-to-modules.patch 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch 0005-powerpc-BestcComm-ATA-task-support.patch 0006-powerpc-BestcComm-FEC-task-support.patch 0007-powerpc-BestcComm-GenBD-task-support.patch 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch 0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch 0082-powerpc-pata_mpc52xx-suspend.patch ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
Grant Likely wrote: On 8/13/07, Jon Smirl [EMAIL PROTECTED] wrote: We're starting a new MPC5200 project and I'm trying to track down the best kernel to start from. Is Sylvain's tree at http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs from the web page don't work. Everything 5200 related in the trees at Secret Labs already appears to be merged. Most of this work also appears to be in the Open Embedded tree's Ekifa support. Is that a better place to start? It might be. The major problem with MPC5200 is the Ethernet driver. I believe both Domen and Sylvain have been working on drivers suitable for arch/powerpc inclusion. We have integrated FEC code floating around into DENX Linux 2.6 tree, and have it working on several boards in the arch/powerpc context. It might be worthwhile to check out git://www.denx.de/git/linux-2.6-denx.git#linux-2.6-denx HTH, Bartlomiej ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
On 8/13/07, Matt Sealey [EMAIL PROTECTED] wrote: I'll put in a decent request here for any work on this subject to please at least attempt to retrieve the tasks from the Efika firmware rather than replacing them in Linux gratuituously. I understand this doesn't help the Lite5200 guys.. but.. pretty please with a cherry on top? :] We're making an open device with all software being replaceable. I already have u-boot. Is there a free open firmware option? Which is the recommended path? Matt, I'll buy some Efikas as soon as you're selling them again., -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] tsec: Allow Ten Bit Interface to be configurable
Allow the address of the Ten Bit Interface (TBI) to be changed in the event of a conflict with another device. Signed-off by: Joe Hamman [EMAIL PROTECTED] --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 81ef81c..ba67b3b 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2276,6 +2276,14 @@ config GFAR_NAPI bool NAPI Support depends on GIANFAR +config GFAR_TBIPA_VALUE + hex Ten Bit Interface Port Address Value + depends on GIANFAR + range 0 0x1f if BFIN_MAC_USE_L1 + default 0x1f + help + Select an address that does not conflict with other addresses on the board. + config UCC_GETH tristate Freescale QE Gigabit Ethernet depends on QUICC_ENGINE diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index f926905..91ae0d3 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev) /* Initialise TBI i/f to communicate with serdes (lynx phy) */ /* Single clk mode, mii mode off(for aerdes communication) */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); /* Supported pause and full-duplex, no half-duplex */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE, + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE, ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE | ADVERTISE_1000XPSE_ASYM); /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000); } @@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev) gfar_write(priv-regs-minflr, MINFLR_INIT_SETTINGS); /* Assign the TBI an address which won't conflict with the PHYs */ - gfar_write(priv-regs-tbipa, TBIPA_VALUE); + gfar_write(priv-regs-tbipa, CONFIG_GFAR_TBIPA_VALUE); } diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index d8e779c..0fd1c02 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -131,7 +131,6 @@ extern const char gfar_driver_version[]; #define DEFAULT_RXCOUNT16 #define DEFAULT_RXTIME 4 -#define TBIPA_VALUE0x1f #define MIIMCFG_INIT_VALUE 0x0007 #define MIIMCFG_RESET 0x8000 #define MIIMIND_BUSY0x0001 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
Allow the address of the Ten Bit Interface (TBI) to be changed in the event of a conflict with another device. Signed-off by: Joe Hamman [EMAIL PROTECTED] --- Please ignore the last patch - I missed a cut paste error on the range that my testing didn't catch. --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 81ef81c..b4813d9 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2276,6 +2276,14 @@ config GFAR_NAPI bool NAPI Support depends on GIANFAR +config GFAR_TBIPA_VALUE + hex Ten Bit Interface Port Address Value + depends on GIANFAR + range 0 0x1f + default 0x1f + help + Select an address that does not conflict with other addresses on the board. + config UCC_GETH tristate Freescale QE Gigabit Ethernet depends on QUICC_ENGINE diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index f926905..91ae0d3 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev) /* Initialise TBI i/f to communicate with serdes (lynx phy) */ /* Single clk mode, mii mode off(for aerdes communication) */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); /* Supported pause and full-duplex, no half-duplex */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE, + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE, ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE | ADVERTISE_1000XPSE_ASYM); /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000); } @@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev) gfar_write(priv-regs-minflr, MINFLR_INIT_SETTINGS); /* Assign the TBI an address which won't conflict with the PHYs */ - gfar_write(priv-regs-tbipa, TBIPA_VALUE); + gfar_write(priv-regs-tbipa, CONFIG_GFAR_TBIPA_VALUE); } diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index d8e779c..0fd1c02 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -131,7 +131,6 @@ extern const char gfar_driver_version[]; #define DEFAULT_RXCOUNT16 #define DEFAULT_RXTIME 4 -#define TBIPA_VALUE0x1f #define MIIMCFG_INIT_VALUE 0x0007 #define MIIMCFG_RESET 0x8000 #define MIIMIND_BUSY0x0001 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Xilinx EMAC driver for Linux in polling mode.
Does anyboady have adapter.c file (or any source code) for Linux kernel driver for Xilinx EMAC IP core, WORKING in POLLING mode? For certain reasons I cannot use interrupt in my system. Thanks, Leonid. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Bestcomm Firmware update
I wrote the disassembler below but never was able to get MPC5200/I2S
DMA running. Hope you can further BestComm code
Copy of Posting 3/30/2006:
BestComm Dudes:
I was able to contact Davide Santo, AN2604 Introduction to BestComm.
He admitted the short commings of his document in the area of Firmware
instruction info and gave me a name of a guy, [EMAIL PROTECTED]
in the ASIC design area in Austin. Ed has agreed to answer questions,
push for resources to provide a support tool and provided me with a
document from their head programmer SmartDMA Hand-Assembly Guides (see
attached pdf).
With this secret decoded ring I was able to put together a disassembler,
see attached disasm.c. Cut and paste your favorite Task into fw[] array
at the beginning, cc -o d disasm.c ; d It's not perfect, but useful-
Enjoy.
If we can formulate a list of questions Ed might be able to help, I'll
start:
o what does init=31 mean?
AN2604 say init=0 means always requestor and 31 is reserved but
referenced alot in the F/W comments
o Need more info on how MORE works
o Tell us about LCD levels. Only 2? (let's call a LCD indent a level)
LCD seems to reset DRD to 1A. DRD2B1or2 follow a DRD2A (ext=1)?
o LCD[28:23]orLCD[20:15] or LCD[11:6] what is extraN?
drop 101nnn - extraN
add 1n - indexN
o how many DRD2B1[2] can be stacked up?
o when is/can a LDC Literal used? and how?
Frank Bennett
/*
* disasm.c - disassembler for MPC5200 Bestcomm DMA Firmware
*copy and paste task code into fw, compile a run
* by Frank bennett, 3/29/2006
*
* Based on Freescale pdf SmartDMA Hand-Assembly Guides
*
* TODO:
* o add inc[0:7] array (maybe var) to deternmine proper term condition (upper 3 bits)
* o need to review sheet 3 of the pdf
* o simulator would be nice
*
*/
// Task12 (TASK_GEN_TX_BD) : Start of TDT - 0xf0008528
// linuxppc_2_4_devel/arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/dma_image.reloc.c
//
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7, 6, 5, 4| 3, 2, 1, 0
// 0 0 0 1 0 0| 0 0 0 0 0| 0 0| 0 0| 0| 0 0 0 1 0 0| 1| 1 0 0 0 0 1| 0 0 0
// 0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
// 1 0 0| 1 1 0 0 1 0| 0| 0| 1 1 0 0 1 0| 0 0| 0| 0 0 0 0 0 0| 1 1 0| 1 1 0
// 0x99190036, /* 002CLCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7, 6, 5, 4| 3, 2, 1, 0
// 1 0| 0 1 1 0, 0 1 0 1,1 0 0, 0 0 1| 1 0| 1 0 0 1 0 0 0 0 1 0 0 0 0
// 0x9950d210
/* Task12(TASK_GEN_TX_BD): Start of TDT - 0xf0008528 */
unsigned long fw[] = {
0x800220e3, /* LCD: idx0 = var0, idx1 = var4; idx1 = var3; idx0 += inc4, idx1 += inc3 */
0x13e01010, /* 0004DRD1A: var4 = var2; FN=0 MORE init=24 WS=0 RS=0 */
0xb8808264, /* 0008LCD: idx2 = *idx1, idx3 = var1; idx2 var9; idx2 += inc4, idx3 += inc4 */
0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
0x60140002, /* 0010 DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2 */
0x0cccfcca, /* 0014 DRD2B1: *idx3 = EU3(); EU3(*idx3,var10) */
0xd9190300, /* 0018LCDEXT: idx2 = idx2; idx2 var12; idx2 += inc0 */
0xb8c5e009, /* 001CLCD: idx3 = *(idx1 + var0015); ; idx3 += inc1 */
0x03fec398, /* 0020 DRD1A: *idx0 = *idx3; FN=0 init=24 WS=3 RS=2 */
0x9919826a, /* 0024LCD: idx2 = idx2, idx3 = idx3; idx2 var9; idx2 += inc5, idx3 += inc2 */
0x0feac398, /* 0028 DRD1A: *idx0 = *idx3; FN=0 TFD INT init=24 WS=1 RS=2 */
0x99190036, /* 002CLCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
0x6005, /* 0030 DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 EXT init=0 WS=0 RS=0 */
0x0c4cf889, /* 0034 DRD2B1: *idx1 = EU3(); EU3(idx2,var9) */
0x01f8, /* 0038NOP */
0x9950d210,
0x2c4cf889,
0
};
union
{
unsigned long i;
struct
{
unsigned sb:3; // [02:00] increment #2
unsigned sa:3; // [05:03] increment #1
unsigned tc:6; // [11:06] variable to which idx is compared
unsigned drtc:1; //[12] dr ? *(tc) : (tc)
unsigned tu:2; // [14:13] term usage 00-idx_a, 01-idx_b, 10- lit init 11-no cond
unsigned ib:6; // [20:15] init_b
unsigned drib:1; //[21] dr ? *(init_a) : (init_a)
unsigned p:1; //[22] indx plus offset
unsigned ia:6; // [28:23] init_a
unsigned dria:1; //[29] dr ? *(init_a) : (init_a)
unsigned ext:1;//[30] = 2 or 3 for LCD
unsigned op:1; //[31] = 2 or 3 for LCD
} lcd;
struct
{
unsigned ll:13;// [12:00] literal init low
unsigned tu:2; // [14:13] term usage == 2
unsigned lh:15;// [29:15] literal init hi
unsigned bas:1;//[30] = 2 or 3 for LCD
unsigned
Best Linux tree for Xilinx support.
Hi: I have several boards with different architectures (Microblaze, PPC), running Linux/uClinux and using Xilinx IP cores. I use both Virtex and Spartan FPGAs. Historically I'm using different kernels for them, starting from uClinux 2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and there to get working. I certainly feel a need to move to some standard kernel tree. I understand that you guys are in some advanced steps of integrating Xilinx into Linux. What would be my best choice of Linux kernel now? I see the following options: - download some GIT tree your are using (which one?). - get latest tree from kernel.org and patch it using your patches (where I can get them?). - ?? Please advise, Thanks, Leonid. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote: Allow the address of the Ten Bit Interface (TBI) to be changed in the event of a conflict with another device. Signed-off by: Joe Hamman [EMAIL PROTECTED] --- Please ignore the last patch - I missed a cut paste error on the range that my testing didn't catch. I think we'd rather this came from the device tree. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Monday, August 13, 2007 10:10 PM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
configurable
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman [EMAIL PROTECTED]
---
Please ignore the last patch - I missed a cut paste error on the
range
that my testing didn't catch.
I think we'd rather this came from the device tree.
Duh, that makes sense ;-)
Has there been any discussion yet? Maybe something like this:
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
device_type = mdio;
compatible = gianfar;
reg = 24520 20;
phy0: [EMAIL PROTECTED] {
interrupt-parent = mpic;
interrupts = a 1;
reg = 0;
device_type = ethernet-phy;
};
phy1: [EMAIL PROTECTED] {
interrupt-parent = mpic;
interrupts = a 1;
reg = 1;
device_type = ethernet-phy;
};
phy2: [EMAIL PROTECTED] {
interrupt-parent = mpic;
interrupts = a 1;
reg = 2;
device_type = ethernet-phy;
};
phy3: [EMAIL PROTECTED] {
interrupt-parent = mpic;
interrupts = a 1;
reg = 3;
device_type = ethernet-phy;
};
tbi: [EMAIL PROTECTED] {
reg = 1f;
device_type = ethernet-tbi;
};
};
Thanks,
Joe
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Best Linux tree for Xilinx support.
Hi Leonid, I am in the process of publishing a Xilinx Linux git tree which will contain most of the drivers for Xilinx IP including recent contributions from Grant Likely, John Williams, Joachim Foerster and others. This tree will be available on the Xilinx git server soon, however it will be a non-supported (and likely unstable) tree. Its main purpose is to provide a common code base for development and a channel to push new driver code out into the community. I am still waiting on IT to set up the new server machine. I will post an announcement once the server is up and running. Cheers, Wolfgang Leonid wrote: Hi: I have several boards with different architectures (Microblaze, PPC), running Linux/uClinux and using Xilinx IP cores. I use both Virtex and Spartan FPGAs. Historically I'm using different kernels for them, starting from uClinux 2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and there to get working. I certainly feel a need to move to some standard kernel tree. I understand that you guys are in some advanced steps of integrating Xilinx into Linux. What would be my best choice of Linux kernel now? I see the following options: - download some GIT tree your are using (which one?). - get latest tree from kernel.org and patch it using your patches (where I can get them?). - ?? Please advise, Thanks, Leonid. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
