* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Kumar Gala @ 2007-08-14 3:09 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <1187044669.10295.4.camel@server>
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 <joe.hamman@embeddedspecialties.com>
> ---
>
> 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
^ permalink raw reply
* RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-14 3:29 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <3FE16C0A-892F-4481-999A-A699C0C70BF9@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Monday, August 13, 2007 10:10 PM
> To: joe.hamman@embeddedspecialties.com
> 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 <joe.hamman@embeddedspecialties.com>
> > ---
> >
> > 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:
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <1>;
device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <2>;
device_type = "ethernet-phy";
};
phy3: ethernet-phy@3 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <3>;
device_type = "ethernet-phy";
};
tbi: ethernet-tbi@1f {
reg = <1f>;
device_type = "ethernet-tbi";
};
};
Thanks,
Joe
^ permalink raw reply
* [0/3] UIC fixes
From: David Gibson @ 2007-08-14 3:48 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer, Benjamin Herrenschmidt,
Valentine Barshak, linuxppc-dev
This series fixes several small problems with the driver for the UIC
interrupt controller found in PowerPC 4xx embedded CPUs.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 2/3] Fix irq flow handler for 4xx UIC
From: David Gibson @ 2007-08-14 3:52 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070814034811.GA8791@localhost.localdomain>
At present the driver for the UIC (the embedded interrupt controller
in 4xx chips) uses the handle_level_irq() flow handler. It turns out
this does not correctly handle level triggered interrupts on the UIC.
Specifically, acknowledging an irq on the UIC (i.e. clearing the
relevant bit in UIC_SR) will have no effect for a level interrupt
which is still asserted by the external device, even if the irq is
already masked. Therefore, unlike handle_level_irq() we must ack the
interrupt after invoking the ISR (which should cause the device to
stop asserting the irq) instead of acking it when we mask it, before
the ISR.
This patch implements this change, in a new handle_uic_irq(), a
customised irq flow handler for the UIC. For edge triggered
interrupts, handle_uic_irq() still uses the old flow - we must ack
edge triggered interrupt before the ISR not after, or we could miss a
second event which occurred between invoking the ISR and acking the
irq.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/sysdev/uic.c | 61 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 60 insertions(+), 1 deletion(-)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:52.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:57.000000000 +1000
@@ -24,6 +24,7 @@
#include <linux/spinlock.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/kernel_stat.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -159,6 +160,64 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
+/**
+ * handle_uic_irq - irq flow handler for UIC
+ * @irq: the interrupt number
+ * @desc: the interrupt description structure for this irq
+ *
+ * This is modified version of the generic handle_level_irq() suitable
+ * for the UIC. On the UIC, acking (i.e. clearing the SR bit) a level
+ * irq will have no effect if the interrupt is still asserted by the
+ * device, even if the interrupt is already masked. Therefore, unlike
+ * the standard handle_level_irq(), we must ack the interrupt *after*
+ * invoking the ISR (which should have de-asserted the interrupt in
+ * the external source). For edge interrupts we ack at the beginning
+ * instead of the end, to keep the window in which we can miss an
+ * interrupt as small as possible.
+ */
+void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cpu = smp_processor_id();
+ struct irqaction *action;
+ irqreturn_t action_ret;
+
+ spin_lock(&desc->lock);
+ if (desc->status & IRQ_LEVEL)
+ desc->chip->mask(irq);
+ else
+ desc->chip->mask_ack(irq);
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto out_unlock;
+ desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
+ kstat_cpu(cpu).irqs[irq]++;
+
+ /*
+ * If its disabled or no action available
+ * keep it masked and get out of here
+ */
+ action = desc->action;
+ if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ desc->status |= IRQ_PENDING;
+ goto out_unlock;
+ }
+
+ desc->status |= IRQ_INPROGRESS;
+ desc->status &= ~IRQ_PENDING;
+ spin_unlock(&desc->lock);
+
+ action_ret = handle_IRQ_event(irq, action);
+
+ spin_lock(&desc->lock);
+ desc->status &= ~IRQ_INPROGRESS;
+ if (desc->status & IRQ_LEVEL)
+ desc->chip->ack(irq);
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+out_unlock:
+ spin_unlock(&desc->lock);
+}
+
static int uic_host_match(struct irq_host *h, struct device_node *node)
{
struct uic *uic = h->host_data;
@@ -173,7 +232,7 @@ static int uic_host_map(struct irq_host
set_irq_chip_data(virq, uic);
/* Despite the name, handle_level_irq() works for both level
* and edge irqs on UIC. FIXME: check this is correct */
- set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
+ set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
/* Set default irq type */
set_irq_type(virq, IRQ_TYPE_NONE);
^ permalink raw reply
* [PATCH 1/3] Fix setting of irq trigger type in UIC driver
From: David Gibson @ 2007-08-14 3:52 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070814034811.GA8791@localhost.localdomain>
The UIC (interrupt controller in 4xx embedded CPUs) driver currently
missets the IRQ_lEVEL flag in desc->status, due to a thinko. This
patch fixes the bug.
Currently this is only a cosmetic problem (affects the output in
/proc/interrupts), however subsequent patches will use the IRQ_LEVEL
flag to affect flow handling.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/sysdev/uic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:44.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:17:52.000000000 +1000
@@ -142,7 +142,7 @@ static int uic_set_irq_type(unsigned int
desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
- if (trigger)
+ if (!trigger)
desc->status |= IRQ_LEVEL;
spin_unlock_irqrestore(&uic->lock, flags);
^ permalink raw reply
* [PATCH 3/3] Improve robustness of the UIC cascade handler
From: David Gibson @ 2007-08-14 3:52 UTC (permalink / raw)
To: Paul Mackerras, Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070814034811.GA8791@localhost.localdomain>
At present the cascade interrupt handler for the UIC (interrupt
controller on 4xx embedded chips) will misbehave badly if it is called
spuriously - that is if the handler is invoked when no interrupts are
asserted in the child UIC.
Although spurious interrupts shouldn't happen, it's good to behave
robustly if they do. This patch does so by checking for and ignoring
spurious interrupts.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/sysdev/uic.c | 3 +++
1 file changed, 3 insertions(+)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:46:02.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:46:02.000000000 +1000
@@ -266,6 +266,9 @@ irqreturn_t uic_cascade(int virq, void *
int subvirq;
msr = mfdcr(uic->dcrbase + UIC_MSR);
+ if (!msr) /* spurious interrupt */
+ return IRQ_HANDLED;
+
src = 32 - ffs(msr);
subvirq = irq_linear_revmap(uic->irqhost, src);
^ permalink raw reply
* Re: Best Linux tree for Xilinx support.
From: Wolfgang Reissnegger @ 2007-08-14 5:07 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C02053A10@ehost011-3.exch011.intermedia.net>
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.
>
^ permalink raw reply
* Re: patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: David Gibson @ 2007-08-14 6:45 UTC (permalink / raw)
To: gregkh; +Cc: stable-commits, paulus, linuxppc-dev
In-Reply-To: <20070813234218.4796D14540D0@imap.suse.de>
On Mon, Aug 13, 2007 at 04:26:27PM -0700, gregkh@suse.de wrote:
>
> This is a note to let you know that we have just queued up the patch titled
>
> Subject: powerpc: Fix size check for hugetlbfs
>
> to the 2.6.22-stable tree. Its filename is
>
> powerpc-fix-size-check-for-hugetlbfs.patch
>
> A git repo of this tree can be found at
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
>
> >From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 08 Aug 2007 15:44:15 +1000
> Subject: powerpc: Fix size check for hugetlbfs
> To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
> Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
> Message-ID: <1186551855.938.164.camel@localhost.localdomain>
>
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> My "slices" address space management code that was added in 2.6.22
> implementation of get_unmapped_area() doesn't properly check that the
> size is a multiple of the requested page size. This allows userland to
> create VMAs that aren't a multiple of the huge page size with hugetlbfs
> (since hugetlbfs entirely relies on get_unmapped_area() to do that
> checking) which leads to a kernel BUG() when such areas are torn down.
Ok, I said I was going to look into a libhugetlbfs testcase for this.
Doesn't appear there's specifically a testcase for misaligned size -
I'll add one.
However, it seems the current kernel, on ppc64, gives a testcase
failure on 'misaligned_offset', because it's not failing a mapping
with a non-hugepage aligned file offset. I'm not sure (yet) if this
failure is also caused by the new slice code, but it seems a likely
candidate.
Still investigating...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [patch 07/12] powerpc: Fix size check for hugetlbfs
From: Greg KH @ 2007-08-14 7:29 UTC (permalink / raw)
To: linux-kernel, stable, linuxppc-dev list
Cc: Theodore Ts'o, Zwane Mwaikambo, Justin Forbes,
Domenico Andreoli, Chris Wedgwood, Paul Mackerras, Randy Dunlap,
Michael Krufky, Chuck Ebbert, Dave Jones, Chuck Wolber, akpm,
torvalds, alan
In-Reply-To: <20070814072813.GA15025@kroah.com>
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/mm/slice.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
--
^ permalink raw reply
* Re: patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: David Gibson @ 2007-08-14 7:48 UTC (permalink / raw)
To: gregkh, benh, linuxppc-dev, paulus, stable-commits
In-Reply-To: <20070814064534.GE8791@localhost.localdomain>
On Tue, Aug 14, 2007 at 04:45:34PM +1000, David Gibson wrote:
> On Mon, Aug 13, 2007 at 04:26:27PM -0700, gregkh@suse.de wrote:
> >
> > This is a note to let you know that we have just queued up the patch titled
> >
> > Subject: powerpc: Fix size check for hugetlbfs
> >
> > to the 2.6.22-stable tree. Its filename is
> >
> > powerpc-fix-size-check-for-hugetlbfs.patch
> >
> > A git repo of this tree can be found at
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> >
> >
> > >From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date: Wed, 08 Aug 2007 15:44:15 +1000
> > Subject: powerpc: Fix size check for hugetlbfs
> > To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
> > Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
> > Message-ID: <1186551855.938.164.camel@localhost.localdomain>
> >
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > My "slices" address space management code that was added in 2.6.22
> > implementation of get_unmapped_area() doesn't properly check that the
> > size is a multiple of the requested page size. This allows userland to
> > create VMAs that aren't a multiple of the huge page size with hugetlbfs
> > (since hugetlbfs entirely relies on get_unmapped_area() to do that
> > checking) which leads to a kernel BUG() when such areas are torn down.
>
> Ok, I said I was going to look into a libhugetlbfs testcase for this.
> Doesn't appear there's specifically a testcase for misaligned size -
> I'll add one.
>
> However, it seems the current kernel, on ppc64, gives a testcase
> failure on 'misaligned_offset', because it's not failing a mapping
> with a non-hugepage aligned file offset. I'm not sure (yet) if this
> failure is also caused by the new slice code, but it seems a likely
> candidate.
I have written a new test for the handling of misaligned addresses,
lengths and offsets for libhugetlbfs. With it I've verified that this
patch does correct a serious problem with length handling - without
the patch this new testcase causes an oops for me. It's simpler than
the 'misaligned_offset' testcase in which the misaligned mapping was
just a step to triggering a different and much more subtle kernel bug
(where the misaligned mapping failed, but corrupted some pagetables in
the process).
But the testcase still fails because a mapping with misaligned offset
still succeeds. Still don't know if this is related to the same slice
changes or not. Need to do a bisect, but I'm putting it off because I
have some other bugs to chase.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 07/12] powerpc: Fix size check for hugetlbfs
From: David Gibson @ 2007-08-14 7:56 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Zwane Mwaikambo, torvalds, Justin Forbes,
linux-kernel, Chris Wedgwood, Domenico Andreoli,
linuxppc-dev list, Randy Dunlap, Paul Mackerras, Chuck Ebbert,
Dave Jones, Michael Krufky, akpm, Chuck Wolber, stable, alan
In-Reply-To: <20070814072918.GG15025@kroah.com>
On Tue, Aug 14, 2007 at 12:29:18AM -0700, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> My "slices" address space management code that was added in 2.6.22
> implementation of get_unmapped_area() doesn't properly check that the
> size is a multiple of the requested page size. This allows userland to
> create VMAs that aren't a multiple of the huge page size with hugetlbfs
> (since hugetlbfs entirely relies on get_unmapped_area() to do that
> checking) which leads to a kernel BUG() when such areas are torn down.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From: Olaf Hering @ 2007-08-14 11:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse, linux-kernel
In-Reply-To: <17938.57292.870224.132415@cargo.ozlabs.ibm.com>
On Wed, Apr 04, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > There are proper device numbers registered for pmac_zilog now. Use them.
Which numbers?
> Sigh. I guess this is inevitable, but IMNSHO this exposes a weakness
> in our serial subsystem.
So, when will the name of pmac_zilog get changed?
What major/minor pair will the two ports get?
^ permalink raw reply
* Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From: David Woodhouse @ 2007-08-14 11:53 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20070814114931.GA13319@aepfle.de>
On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
> On Wed, Apr 04, Paul Mackerras wrote:
>
> > David Woodhouse writes:
> >
> > > There are proper device numbers registered for pmac_zilog now. Use them.
>
> Which numbers?
shinybook /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
crw-rw---- 1 root uucp 204, 192 2007-08-13 11:48 /dev/ttyPZ0
crw-rw---- 1 root uucp 204, 193 2007-08-13 11:48 /dev/ttyPZ1
--
dwmw2
^ permalink raw reply
* RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-14 12:47 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <013b01c7de23$5baa7d70$6f00a8c0@ESIDT>
Hi Kumar,
Or do you think it should be added to gianfar_mdio_data? Easier, but does
it belong there?
Thanks,
Joe
> -----Original Message-----
> From: linuxppc-embedded-
> bounces+joe.hamman=embeddedspecialties.com@ozlabs.org [mailto:linuxppc-
> embedded-bounces+joe.hamman=embeddedspecialties.com@ozlabs.org] On Behalf
> Of Joe Hamman
> Sent: Monday, August 13, 2007 10:30 PM
> To: 'Kumar Gala'
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
>
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Monday, August 13, 2007 10:10 PM
> > To: joe.hamman@embeddedspecialties.com
> > 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 <joe.hamman@embeddedspecialties.com>
> > > ---
> > >
> > > 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:
>
> mdio@24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> compatible = "gianfar";
> reg = <24520 20>;
> phy0: ethernet-phy@0 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <0>;
> device_type = "ethernet-phy";
> };
> phy1: ethernet-phy@1 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <1>;
> device_type = "ethernet-phy";
> };
> phy2: ethernet-phy@2 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <2>;
> device_type = "ethernet-phy";
> };
> phy3: ethernet-phy@3 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <3>;
> device_type = "ethernet-phy";
> };
> tbi: ethernet-tbi@1f {
> reg = <1f>;
> device_type = "ethernet-tbi";
> };
> };
>
> Thanks,
> Joe
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* MPC755
From: Chuck Brown @ 2007-08-14 15:45 UTC (permalink / raw)
To: linuxppc-embedded
Are you still checking this account?
^ permalink raw reply
* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Andy Fleming @ 2007-08-14 16:04 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <013b01c7de23$5baa7d70$6f00a8c0@ESIDT>
On Aug 13, 2007, at 22:29, Joe Hamman wrote:
>>
>>
>> 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 <joe.hamman@embeddedspecialties.com>
>>> ---
>>>
>>> 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:
>
> mdio@24520 {
>
...
> phy3: ethernet-phy@3 {
> interrupt-parent = <&mpic>;
> interrupts = <a 1>;
> reg = <3>;
> device_type = "ethernet-phy";
> };
> tbi: ethernet-tbi@1f {
> reg = <1f>;
> device_type = "ethernet-tbi";
> };
It's actually a per-tsec property. There's not one tbi, there's one
per TSEC. The one on TSEC 0 is special in that it can interfere with
PHYs on the MDIO bus.
So I would suggest making it a property of the ethernet node:
ethernet@24000 {
...
tbipa = <1f>;
...
}
etc
Andy
^ permalink raw reply
* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Scott Wood @ 2007-08-14 16:16 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <1B668DF2-9909-4D43-AAFF-3A2ADFA283B2@freescale.com>
Andy Fleming wrote:
> It's actually a per-tsec property. There's not one tbi, there's one
> per TSEC. The one on TSEC 0 is special in that it can interfere with
> PHYs on the MDIO bus.
>
> So I would suggest making it a property of the ethernet node:
>
> ethernet@24000 {
> ...
> tbipa = <1f>;
> ...
> }
"tbipa" isn't likely to pass the Segher test. :-)
If the TBI address is in PHY-space, then it should go in the MDIO bus.
For the second TSEC, create a second MDIO bus node.
-Scott
^ permalink raw reply
* Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
From: Olaf Hering @ 2007-08-14 16:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1187092392.3707.74.camel@shinybook.infradead.org>
On Tue, Aug 14, David Woodhouse wrote:
> On Tue, 2007-08-14 at 13:49 +0200, Olaf Hering wrote:
> > On Wed, Apr 04, Paul Mackerras wrote:
> >
> > > David Woodhouse writes:
> > >
> > > > There are proper device numbers registered for pmac_zilog now. Use them.
> >
> > Which numbers?
>
> shinybook /shiny/git/mtd-utils $ ls -l /dev/ttyPZ*
> crw-rw---- 1 root uucp 204, 192 2007-08-13 11:48 /dev/ttyPZ0
> crw-rw---- 1 root uucp 204, 193 2007-08-13 11:48 /dev/ttyPZ1
I dont see 204:192 in devices.txt
^ permalink raw reply
* [PATCH] ps3: Fix no storage devices found
From: Geert Uytterhoeven @ 2007-08-14 16:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development, Hiroyuki Machida, Olaf Hering
In-Reply-To: <46C1D0D6.7030403@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1379 bytes --]
Fix probing of PS3 storage devices: in the success case, we should set `error'
to zero, not `result'.
Without this patch no storage devices are found.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
This brown paper bag bug slipped in due to bad patch splitting.
Please apply as soon as possible. Thanks!
arch/powerpc/platforms/ps3/device-init.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -372,7 +372,7 @@ static int ps3_storage_wait_for_device(c
notify_event->dev_type == repo->dev_type) {
pr_debug("%s:%u: device ready: dev_id %u\n", __func__,
__LINE__, repo->dev_id);
- result = 0;
+ error = 0;
break;
}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] ps3: Fix no storage devices found
From: Geoff Levand @ 2007-08-14 16:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Hiroyuki Machida, Andrew Morton,
Olaf Hering
In-Reply-To: <Pine.LNX.4.62.0708141828170.3886@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> Fix probing of PS3 storage devices: in the success case, we should set `error'
> to zero, not `result'.
>
> Without this patch no storage devices are found.
>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
> This brown paper bag bug slipped in due to bad patch splitting.
> Please apply as soon as possible. Thanks!
Looks good.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-14 16:50 UTC (permalink / raw)
To: 'Scott Wood', 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <46C1D553.4000201@freescale.com>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]
> Sent: Tuesday, August 14, 2007 11:16 AM
> To: Andy Fleming
> Cc: joe.hamman@embeddedspecialties.com; linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
> Andy Fleming wrote:
> > It's actually a per-tsec property. There's not one tbi, there's one
> > per TSEC. The one on TSEC 0 is special in that it can interfere with
> > PHYs on the MDIO bus.
> >
> > So I would suggest making it a property of the ethernet node:
> >
> > ethernet@24000 {
> > ...
> > tbipa = <1f>;
> > ...
> > }
>
> "tbipa" isn't likely to pass the Segher test. :-)
>
> If the TBI address is in PHY-space, then it should go in the MDIO bus.
> For the second TSEC, create a second MDIO bus node.
>
How about something like this?
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy1f: ethernet-phy@1f {
reg = <1f>;
device_type = "ethernet-phy";
};
phy0: ethernet-phy@0 {
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
reg = <1>;
device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
reg = <2>;
device_type = "ethernet-phy";
};
tbi1e: ethernet-tbi@1e {
reg = <1e>;
device_type = "ethernet-tbi";
};
};
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <24000 1000>;
mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <1d 2 1e 2 22 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1f>;
tbi-handle = <&tbi1e>;
};
Joe
^ permalink raw reply
* RE: Best Linux tree for Xilinx support.
From: Leonid @ 2007-08-14 17:28 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070814050748.EE7C2D0075@mail26-fra.bigfish.com>
Hi Wolfgang:
Thank you very much for the information. What kernel.org version your
tree is based on?
As you noticed, it will be rather reference tree to set some coding
standard, namely where files are located, how drivers are included,
etc... So, I would appreciate if I can get a glimpse of your suggested
tree structure, actual sources are not even required.
Previous support for Xilinx was more oriented toward PPC405 core in
Virtex FPGA and everything was naturally concentrated under
arch/ppc/platform/4xx.
I deem such approach is not very good one. I'm using precisely same IP
cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
which means (OK, may be cores are different somewhat for different FPGAs
but low level Xilinx code is the same). That means at least 2 different
CPU architectures (PPC and Microblaze).=20
You certainly gave thought to such an issue. What tree structure do you
suggest? There are 3 groups of Xilinx files to place in the Linux tree:
- common .h files (like xbasic_types.h);
- common .c files, used by several cores (like all DMA stuff).
- specific core .h/.c files (say xemac.h and xemac.c).
They all kind of "architecture independent" (at least 2 architectures
can be used - MB and PPC).
Of course, except tree structure there are several other (not completely
independent) questions to answer like:
A How EDK project parameters get into Linux kernel? This is huge issue
which can be divided on several items.
A.1. Do you also suppose that some special type of BSP (.tcl script,
defined by OS parameter of MSS file) shall run or you assume that it
will be regular xaparameters.h file, prepared by standard standalone
BSP? In latter case xparamerts.h needs manual editing since it doesn't
have all parameters required by certain cores.=20
A.2. There is also a question how these definitions get into .c and Make
files. Petalogix has interesting solution when they bump all XILINX
parameters to autoconf.h and .config files thus making them available
for both compiler and make. What's your approach?
A.3. If .config is not prepared automatically, then all configuration
must be done via "make menuconfig" meaning Kconfig files shall be
modified. Do you intend having several FPGA flags like CONFIG_VIRTEX and
CONFIG_SPARTAN? Drivers' inclusion will depend on one of them.
A.4. Is it assumed that Xilinx low level code will stay intact as it is
supplied with EDK package or you are going to prepare special Linux
Xilinx set (mostly because of name convention)?
B How drivers get registered - via platform devices structure in
virtex.c file or something different?
All these questions have been discussed by the community but I somehow
missed a conclusion if any took place. Does anything (kind of memo or
readme) exist on these subjects?
Thanks,
Leonid.
-----Original Message-----
From: Wolfgang Reissnegger [mailto:wolfgang.reissnegger@xilinx.com]=20
Sent: Monday, August 13, 2007 10:08 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: 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:
>=20
> I have several boards with different architectures (Microblaze, PPC),=20
> running Linux/uClinux and using Xilinx IP cores. I use both Virtex and
> Spartan FPGAs.
>=20
> Historically I'm using different kernels for them, starting from=20
> uClinux 2.4, all way through Linux 2.6.16 and 2.6.19. I patched them=20
> here and there to get working.
>=20
> I certainly feel a need to move to some standard kernel tree.
>=20
> I understand that you guys are in some advanced steps of integrating=20
> Xilinx into Linux. What would be my best choice of Linux kernel now?
>=20
> I see the following options:
>=20
> - download some GIT tree your are using (which one?).
> - get latest tree from kernel.org and patch it using your patches=20
> (where I can get them?).
> - ??
>=20
> Please advise,
>=20
> Thanks,
>=20
> Leonid.
>=20
^ permalink raw reply
* Re: Best Linux tree for Xilinx support.
From: Grant Likely @ 2007-08-14 17:53 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C02053B0F@ehost011-3.exch011.intermedia.net>
On 8/14/07, Leonid <Leonid@a-k-a.net> wrote:
> I deem such approach is not very good one. I'm using precisely same IP
> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
> which means (OK, may be cores are different somewhat for different FPGAs
> but low level Xilinx code is the same). That means at least 2 different
> CPU architectures (PPC and Microblaze).
The driver code should all be in platform independent locations. Only
the ppc405 support code lives in arch/ppc. For ublaze support, you
need to look at the ublaze mailing list.
>
> You certainly gave thought to such an issue. What tree structure do you
> suggest? There are 3 groups of Xilinx files to place in the Linux tree:
>
> - common .h files (like xbasic_types.h);
Common include files go in include/linux. However, the xilinx
os-independent files are a stopgap measure. They will probably never
be merged into the mainline Linux source tree.
> - common .c files, used by several cores (like all DMA stuff).
I think we've agreed that drivers/misc is a suitable location.
> - specific core .h/.c files (say xemac.h and xemac.c).
Eth drivers go under drivers/net
serial drivers go under drivers/serial
i2c drivers go under drivers/i2c
etc.
> They all kind of "architecture independent" (at least 2 architectures
> can be used - MB and PPC).
Many of the drivers already are arch independent. A key feature of
this is that xilinx ip drivers should *not* make use of xparameters.h
directly. Which drivers are you having trouble with?
> Of course, except tree structure there are several other (not completely
> independent) questions to answer like:
>
> A How EDK project parameters get into Linux kernel? This is huge issue
> which can be divided on several items.
In arch/ppc (depreciated), via platform bus registrations. The
platform bus is populated via
arch/ppc/platforms/4xx/xparameters/xparameters.h
In arch/powerpc, via a device tree blob. The device tree blob will be
generated from the EDK project.
in microblaze, I believe it is currently via platform bus
registrations like in arch/ppc, but there is desire to move to using
the arch/powerpc device tree also.
>
> A.1. Do you also suppose that some special type of BSP (.tcl script,
> defined by OS parameter of MSS file) shall run or you assume that it
> will be regular xaparameters.h file, prepared by standard standalone
> BSP? In latter case xparamerts.h needs manual editing since it doesn't
> have all parameters required by certain cores.
>
> A.2. There is also a question how these definitions get into .c and Make
> files. Petalogix has interesting solution when they bump all XILINX
> parameters to autoconf.h and .config files thus making them available
> for both compiler and make. What's your approach?
Just to reinforce my point: xilinx device drivers should *NEVER* use
xparameters.h directly. The device driver binding code should either
retrieve the device configuration from the platform bus or from the
device tree.
>
> A.3. If .config is not prepared automatically, then all configuration
> must be done via "make menuconfig" meaning Kconfig files shall be
> modified. Do you intend having several FPGA flags like CONFIG_VIRTEX and
> CONFIG_SPARTAN? Drivers' inclusion will depend on one of them.
Yes, some of them even already exist! :-)
There can also be some defconfigs for supported boards.
>
> A.4. Is it assumed that Xilinx low level code will stay intact as it is
> supplied with EDK package or you are going to prepare special Linux
> Xilinx set (mostly because of name convention)?
No. The xilinx EDK drivers are not desirable for inclusion in
mainline. Slowly the drivers are being replaced with Linux specific
drivers. New uartlite, ns16550, xsysace and framebuffer drivers are
already in mainline.
>
> B How drivers get registered - via platform devices structure in
> virtex.c file or something different?
Read up on 'platform bus' and 'of platform bus'. platform bus is what
works now. of platform bus is how it will work when we migrate to
arch/powerpc.
>
> All these questions have been discussed by the community but I somehow
> missed a conclusion if any took place. Does anything (kind of memo or
> readme) exist on these subjects?
Unfortunately, no.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Scott Wood @ 2007-08-14 18:00 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <018801c7de93$43390e80$6f00a8c0@ESIDT>
Joe Hamman wrote:
> ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> model = "eTSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> mac-address = [ 00 E0 0C 00 73 00 ];
> interrupts = <1d 2 1e 2 22 2>;
> interrupt-parent = <&mpic>;
> phy-handle = <&phy1f>;
> tbi-handle = <&tbi1e>;
> };
Is any given board going to have at runtime (i.e. not jumper selectable)
both a phy and a tbi (I'm not very familiar with the latter, so I
apologize if this is a dumb question). If not, I'd stick with
phy-handle and have something in the phy node to indicate that it's tbi.
-Scott
^ permalink raw reply
* ft_ordered removal patch status?
From: Becky Bruce @ 2007-08-14 18:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
Hi Paul,
Is there a reason this hasn't been picked up:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035906.html
It fixes a build warning in the tree and removes some dead code. It
appears to still apply cleanly to the top of your tree.... if there
are issues please let me know so I can fix them.
Thanks,
Becky
^ 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