* [PATCH 0/4] 440SPe support
From: Roland Dreier @ 2005-09-23 3:03 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-embedded
Here is a series of patches that add basic support for AMCC's PowerPC
440SPe SoC. With these patches, the kernel will boot and run on the
"Yucca" 440SPe eval board, with ethernet and serial working.
I don't have PCI-X or PCI Express in a mergeable state, but I thought
it would be worth posting these now for review. Also, it would
probably be good to figure out how we want to merge this upstream once
2.6.14 comes out -- 440SPe requires some minor changes to ethernet PHY
handling, which will have to be coordinated with the ibm_emac rewrite,
and there are also some minor conflicts with the 440GR patches I saw.
Right now I'm working on PCI Express support, and I'll post those
patches once I have something reasonable.
I also have a git tree at
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/ppc440spe.git
that contains all of these patches, in case that makes it easier to
merge this stuff.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
From: Eugene Surovegin @ 2005-09-23 3:22 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-embedded
In-Reply-To: <2005922203.qtfGFmWm3E8jkhq1@cisco.com>
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote:
> Eugene, I'm not sure what the status of your ibm_emac rewrite is. Is
> there a tree somewhere that you would like me to merge this change
> with and then send you a patch, or do you want to take care of merging?
Well, new driver was sent to jgarzik and netdev list three weeks ago.
So far I haven't heard anything technical from Jeff. I don't know when
and even if it will be merged.
There is a GIT tree with new driver, for more info look at
http://kernel.ebshome.net/emac/index.html
I don't know what to recommend now - wait for net driver maintainer
(I've heard some people have been waiting for couple months already)
or sent this patch upstream ignoring new driver :(. Matt?
I'll try to look at merging your patch into my tree, but probably not
right now - I'm kinda busy with other stuff and netdev "progress"
doesn't quite motivate me working on this project, frankly. Though, if
you can send me a patch against my tree, I'll appreciate it :).
--
Eugene
^ permalink raw reply
* Re: [PATCH 2/4] [PPC32] Add 440SPe support
From: Eugene Surovegin @ 2005-09-23 3:29 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-embedded
In-Reply-To: <2005922203.UPGbNSgrHKasoXYq@cisco.com>
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote:
> Add support for the AMCC PowerPC 440SPe SoC.
[snip]
> +static struct ocp_func_mal_data amc440spe_mal0_def = {
> + .num_tx_chans = 1, /* Number of TX channels */
> + .num_rx_chans = 1, /* Number of RX channels */
> + .txeob_irq = 38, /* TX End Of Buffer IRQ */
> + .rxeob_irq = 39, /* RX End Of Buffer IRQ */
> + .txde_irq = 34, /* TX Descriptor Error IRQ */
> + .rxde_irq = 35, /* RX Descriptor Error IRQ */
> + .serr_irq = 33, /* MAL System Error IRQ */
> +};
> +OCP_SYSFS_MAL_DATA()
Roland, I recently added new field (.dcr_base) to this structure (as a
preparation step for new EMAC driver), could you do this for 440SPe as
well? It's not needed right now, but as soon as new EMAC driver is in,
440SPe will stop working.
[snip]
> +static void __init ppc4xx_pic_impl_init(void)
> +{
> + /* Enable cascade interrupts in UIC0 */
> + /* Enable cascade interrupt in UIC0 */
I think you probably missed this part :)
--
Eugene
^ permalink raw reply
* Re: [PATCH 4/4] [PPC32] Add Yucca (440SPe eval board) platform
From: Eugene Surovegin @ 2005-09-23 3:32 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-embedded
In-Reply-To: <2005922203.tCj2DaX4oc1ISyYc@cisco.com>
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote:
> Add support for AMCC PowerPC 440SPe "Yucca" eval board platform.
[snip]
> +/*
> + * This is a horrible kludge, we eventually need to abstract this
> + * generic PHY stuff, so the standard phy mode defines can be
> + * easily used from arch code.
> + */
> +#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
This is not needed anymore. Please, remove this.
--
Eugene
^ permalink raw reply
* Re: [PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
From: Roland Dreier @ 2005-09-23 5:25 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20050923032236.GA10089@gate.ebshome.net>
Eugene> Well, new driver was sent to jgarzik and netdev list three
Eugene> weeks ago. So far I haven't heard anything technical from
Eugene> Jeff. I don't know when and even if it will be merged.
Assuming everyone in the PPC4xx world thinks your driver should
replace the old driver, it might be worth sending directly to Andrew.
There's no reason Jeff has to become a bottleneck for this.
Eugene> I'll try to look at merging your patch into my tree, but
Eugene> probably not right now - I'm kinda busy with other stuff
Eugene> and netdev "progress" doesn't quite motivate me working on
Eugene> this project, frankly. Though, if you can send me a patch
Eugene> against my tree, I'll appreciate it :).
No problem at all. Here's a patch against your git tree -- only
tested on my Yucca board, so you might want to doublecheck that I
didn't break all the systems will the opposite polarity.
Thanks,
Roland
For some reason, the hardware designers made the polarity of one bit
in the 440SPe's PHY interface register the opposite of all other PPC
440 chips. To handle this, abstract our access to this bit and do the
right thing based on the configured CPU type.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -26,7 +26,7 @@
/* This is a simple check to prevent use of this driver on non-tested SoCs */
#if !defined(CONFIG_405GP) && !defined(CONFIG_405GPR) && !defined(CONFIG_405EP) && \
!defined(CONFIG_440GP) && !defined(CONFIG_440GX) && !defined(CONFIG_440SP) && \
- !defined(CONFIG_440EP) && !defined(CONFIG_NP405H)
+ !defined(CONFIG_440EP) && !defined(CONFIG_NP405H) && !defined(CONFIG_440SPE)
#error "Unknown SoC. Please, check chip user manual and make sure EMAC defines are OK"
#endif
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -139,6 +139,29 @@ static inline void EMAC_RX_CLK_DEFAULT(i
#define EMAC_CLK_EXTERNAL ((void)0)
#endif
+/*
+ * For the 440SPe, AMCC inexplicably changed the polarity of
+ * the "operation complete" bit in the MII control register.
+ */
+#ifdef CONFIG_440SPE
+static inline int emac_phy_done(uint32_t stacr)
+{
+ return !(stacr & EMAC_STACR_OC);
+};
+
+#define EMAC_STACR_START EMAC_STACR_OC
+
+#else /* CONFIG_440SPE */
+
+static inline int emac_phy_done(uint32_t stacr)
+{
+ return stacr & EMAC_STACR_OC;
+};
+
+#define EMAC_STACR_START 0
+#endif /* CONFIG_440SPE */
+
+
/* I don't want to litter system log with timeout errors
* when we have brain-damaged PHY.
*/
@@ -546,7 +569,7 @@ static int __emac_mdio_read(struct ocp_e
/* Wait for management interface to become idle */
n = 10;
- while (!(in_be32(&p->stacr) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -556,11 +579,12 @@ static int __emac_mdio_read(struct ocp_e
out_be32(&p->stacr,
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_READ |
(reg & EMAC_STACR_PRA_MASK)
- | ((id & EMAC_STACR_PCDA_MASK) << EMAC_STACR_PCDA_SHIFT));
+ | ((id & EMAC_STACR_PCDA_MASK) << EMAC_STACR_PCDA_SHIFT)
+ | EMAC_STACR_START);
/* Wait for read to complete */
n = 100;
- while (!((r = in_be32(&p->stacr)) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(r = in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -594,7 +618,7 @@ static void __emac_mdio_write(struct ocp
/* Wait for management interface to be idle */
n = 10;
- while (!(in_be32(&p->stacr) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -605,11 +629,12 @@ static void __emac_mdio_write(struct ocp
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_WRITE |
(reg & EMAC_STACR_PRA_MASK) |
((id & EMAC_STACR_PCDA_MASK) << EMAC_STACR_PCDA_SHIFT) |
- (val << EMAC_STACR_PHYD_SHIFT));
+ (val << EMAC_STACR_PHYD_SHIFT) |
+ EMAC_STACR_START);
/* Wait for write to complete */
n = 100;
- while (!(in_be32(&p->stacr) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -34,7 +34,8 @@
#if defined(CONFIG_405GP) || defined(CONFIG_405GPR) || defined(CONFIG_405EP) || \
defined(CONFIG_440EP) || defined(CONFIG_NP405H)
#define MAL_VERSION 1
-#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP)
+#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP) || \
+ defined(CONFIG_440SPE)
#define MAL_VERSION 2
#else
#error "Unknown SoC, please check chip manual and choose MAL 'version'"
^ permalink raw reply
* Re: [PATCH 2/4] [PPC32] Add 440SPe support
From: Roland Dreier @ 2005-09-23 5:44 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-embedded
In-Reply-To: <20050923032949.GB10089@gate.ebshome.net>
Eugene> Roland, I recently added new field (.dcr_base) to this
Eugene> structure (as a preparation step for new EMAC driver),
Eugene> could you do this for 440SPe as well? It's not needed
Eugene> right now, but as soon as new EMAC driver is in, 440SPe
Eugene> will stop working.
Eugene> I think you probably missed this part :)
Both fixed and pushed in a new git tree...
- R.
^ permalink raw reply
* Re: [PATCH 4/4] [PPC32] Add Yucca (440SPe eval board) platform
From: Roland Dreier @ 2005-09-23 5:44 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-embedded
In-Reply-To: <20050923033257.GC10089@gate.ebshome.net>
Eugene> This is not needed anymore. Please, remove this.
Done and also pushed out in the new git tree.
- R.
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/rwsem.h
From: David Howells @ 2005-09-23 7:32 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <E1EIXAI-0006Q0-OS@jdl.com>
Jon Loeliger <jdl@freescale.com> wrote:
> Merge asm-ppc*/rwsem.h into include/asm-powerpc.
> Removed smp_*mb() memory barriers from the ppc32 code
> as they are now burried in the atomic_*() functions as
> suggested by Paul, implemented by Arnd, and pushed out
> by Becky. I am not the droid you are looking for.
rwsems on ppc64 should really be using a 64-bit counter, not a 32-bit counter,
otherwise you limit the maximum number of processes to 32K-ish.
The counter should be "signed long" really.
David
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/rwsem.h
From: Anton Blanchard @ 2005-09-23 7:44 UTC (permalink / raw)
To: David Howells; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <606.1127460740@warthog.cambridge.redhat.com>
> rwsems on ppc64 should really be using a 64-bit counter, not a 32-bit counter,
> otherwise you limit the maximum number of processes to 32K-ish.
>
> The counter should be "signed long" really.
Agreed, we should move to a 64bit count.
Anton
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/rwsem.h
From: David Howells @ 2005-09-23 7:52 UTC (permalink / raw)
To: Anton Blanchard; +Cc: David Howells, linuxppc-dev, linuxppc64-dev
In-Reply-To: <20050923074413.GD19971@krispykreme>
Anton Blanchard <anton@samba.org> wrote:
> > The counter should be "signed long" really.
>
> Agreed, we should move to a 64bit count.
With a 64-bit counter, the constants should be:
#define RWSEM_UNLOCKED_VALUE 0x0000000000000000L
#define RWSEM_ACTIVE_BIAS 0x0000000000000001L
#define RWSEM_ACTIVE_MASK 0x00000000ffffffffL
#define RWSEM_WAITING_BIAS (-0x0000000100000000L)
#define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
Just like in the asm-s390/rwsem.h.
David
^ permalink raw reply
* Re: [PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
From: Eugene Surovegin @ 2005-09-23 8:24 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-embedded
In-Reply-To: <52irwscq49.fsf@cisco.com>
On Thu, Sep 22, 2005 at 10:25:26PM -0700, Roland Dreier wrote:
> No problem at all. Here's a patch against your git tree -- only
> tested on my Yucca board, so you might want to doublecheck that I
> didn't break all the systems will the opposite polarity.
Thanks Roland, I've just pushed your patch with minor style changes
to my GIT tree.
I changed uint32_t -> u32 and moved emac_phy_done() functions to
ibm_emac.h. Booted new kernel on Ocotea and everything seems to be OK.
--
Eugene
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/seccomp.h
From: Christoph Hellwig @ 2005-09-23 9:08 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <E1EIVwC-0001IQ-5s@jdl.com>
On Thu, Sep 22, 2005 at 01:36:52PM -0500, Jon Loeliger wrote:
> So, like, the other day Christoph Hellwig mumbled:
> > > +#include <linux/thread_info.h>
> > > +
> > > +#if defined(__powerpc64__) && !defined(TIF_32BIT)
> > > +#error "unexpected TIF_32BIT on ppc64"
> > > +#endif
> >
> > just kill this check, it's rather pointless
>
> OK.
>
> But keep the #include? It's actually the part
> that is defining TIF_32BIT for ppc64 (indirectly
> through linux/thread_info.h and asm/thread_info.h).
> Won't those bits be needed still?
I'm not sure. This header definitly doesn't need it, but I suspect
seccompt.c expects to get it via this header.
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-09-23 10:55 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85946A@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
>There is a bug in the SMC init code, wher the base address for the SMC's
>is not reinitialized by the kernel, so if the SMC is not initialized by
>the bootloader, it will not work.
>
>If that is the case, try this patch.
>
>
The SMC was previously initialised, but I still upgraded to 2.6.14-rc2,
which includes your patch. It still doesn't work, the buffer descriptor
must be at a wrong address somehow since the board just hangs now in the
same routine.
I did manage to decode the message coming to the console with the two
leds onboard... it begun with "Linux ve", which at least looks like a
good boot-up message :)
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/rwsem.h
From: Jon Loeliger @ 2005-09-23 12:52 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
In-Reply-To: <606.1127460740@warthog.cambridge.redhat.com>
So, like, the other day David Howells mumbled:
>
> rwsems on ppc64 should really be using a 64-bit counter, not a 32-bit counter
> ,
> otherwise you limit the maximum number of processes to 32K-ish.
>
> The counter should be "signed long" really.
No problem. I _can_ resubmit the patch with this fix.
However, I am not certain that I should yet.
But what do you wan to do with ppc32 land then?
Leaving it a "signed long" will limit ppc32 land but
not ppc64 folks. (No problem.) Or we can have it
be "singed long long" for ppc32 to also get 64 bits.
(Again, no problem.)
Also, this begs the question of the comment from Paul:
struct rw_semaphore {
/* XXX this should be able to be an atomic_t -- paulus */
signed int count;
Which, of course is:
typedef struct { volatile int counter; } atomic_t;
Changing the size of counter will cause bad sizes
due to the actual treatment of count as an atomic_t.
So. Should we, in fact, convert it to be an atomic_t
and further dispense with the casts?:
static inline void __down_write(struct rw_semaphore *sem)
{
int tmp;
tmp = atomic_add_return(RWSEM_ACTIVE_WRITE_BIAS,
(atomic_t *)(&sem->count));
And if we _do_ convert it to be an atomic_t, should _that_
be where the real type for count gets established?
And finally, I've been working on merging header files
under the vague guideline of "merge maintaining existing
functionality/breakage". I've been trying NOT to introduce
simultaneous "improvements" at the risk of breaking something.
To that end, I ask if the request to make 'count' be 64-bits
should be submitted as a follow on patch that stands on its
own and can clean up around it as necessary? Or do you want
it mixed in with this "merge" patch too?
Just need to know the preferences.
Thanks,
jdl
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/seccomp.h
From: Jon Loeliger @ 2005-09-23 12:54 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20050923090809.GA31688@lst.de>
So, like, the other day Christoph Hellwig mumbled:
> >
> > But keep the #include? It's actually the part
> > that is defining TIF_32BIT for ppc64 (indirectly
> > through linux/thread_info.h and asm/thread_info.h).
> > Won't those bits be needed still?
>
> I'm not sure. This header definitly doesn't need it, but I suspect
> seccompt.c expects to get it via this header.
I dug around in this a bit. The nested includes here yield
a fairly wide distribution of availability of TIF_32BIT.
I'm hesitant to remove it in this "merge" patch, so I
will leave its removal to a follow on patch/effort.
New patch with #if test removed coming up.
jdl
^ permalink raw reply
* PATCH powerpc Merge asm-ppc*/seccomp.h, drop TIF_32BIT check
From: Jon Loeliger @ 2005-09-23 13:05 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Merge asm-ppc*/seccomp.h. Drop TIF_32BIT check.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
include/asm-powerpc/seccomp.h | 16 ++++++++++++++++
include/asm-ppc/seccomp.h | 10 ----------
include/asm-ppc64/seccomp.h | 21 ---------------------
3 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/include/asm-powerpc/seccomp.h b/include/asm-powerpc/seccomp.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/seccomp.h
@@ -0,0 +1,16 @@
+#ifndef _ASM_POWERPC_SECCOMP_H
+
+#include <linux/thread_info.h>
+#include <linux/unistd.h>
+
+#define __NR_seccomp_read __NR_read
+#define __NR_seccomp_write __NR_write
+#define __NR_seccomp_exit __NR_exit
+#define __NR_seccomp_sigreturn __NR_rt_sigreturn
+
+#define __NR_seccomp_read_32 __NR_read
+#define __NR_seccomp_write_32 __NR_write
+#define __NR_seccomp_exit_32 __NR_exit
+#define __NR_seccomp_sigreturn_32 __NR_sigreturn
+
+#endif /* _ASM_POWERPC_SECCOMP_H */
diff --git a/include/asm-ppc/seccomp.h b/include/asm-ppc/seccomp.h
deleted file mode 100644
--- a/include/asm-ppc/seccomp.h
+++ /dev/null
@@ -1,10 +0,0 @@
-#ifndef _ASM_SECCOMP_H
-
-#include <linux/unistd.h>
-
-#define __NR_seccomp_read __NR_read
-#define __NR_seccomp_write __NR_write
-#define __NR_seccomp_exit __NR_exit
-#define __NR_seccomp_sigreturn __NR_rt_sigreturn
-
-#endif /* _ASM_SECCOMP_H */
diff --git a/include/asm-ppc64/seccomp.h b/include/asm-ppc64/seccomp.h
deleted file mode 100644
--- a/include/asm-ppc64/seccomp.h
+++ /dev/null
@@ -1,21 +0,0 @@
-#ifndef _ASM_SECCOMP_H
-
-#include <linux/thread_info.h> /* already defines TIF_32BIT */
-
-#ifndef TIF_32BIT
-#error "unexpected TIF_32BIT on ppc64"
-#endif
-
-#include <linux/unistd.h>
-
-#define __NR_seccomp_read __NR_read
-#define __NR_seccomp_write __NR_write
-#define __NR_seccomp_exit __NR_exit
-#define __NR_seccomp_sigreturn __NR_rt_sigreturn
-
-#define __NR_seccomp_read_32 __NR_read
-#define __NR_seccomp_write_32 __NR_write
-#define __NR_seccomp_exit_32 __NR_exit
-#define __NR_seccomp_sigreturn_32 __NR_sigreturn
-
-#endif /* _ASM_SECCOMP_H */
^ permalink raw reply
* Re: PATCH powerpc Merge asm-ppc*/rwsem.h
From: David Howells @ 2005-09-23 14:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <E1EIn23-0001pB-H0@jdl.com>
Jon Loeliger <jdl@freescale.com> wrote:
> No problem. I _can_ resubmit the patch with this fix.
> However, I am not certain that I should yet.
I'd suggest that you wait until the merge is complete, I think.
> But what do you wan to do with ppc32 land then?
> Leaving it a "signed long" will limit ppc32 land but
> not ppc64 folks. (No problem.)
I'd suggest "signed long" in both cases. A maximum of 32K processes on ppc32
is probably reasonable.
> Also, this begs the question of the comment from Paul:
>
> struct rw_semaphore {
> /* XXX this should be able to be an atomic_t -- paulus */
> signed int count;
Paul can be wrong sometimes:-)
Changing to atomic_t would leave the 32K process limit in place.
> Changing the size of counter will cause bad sizes
> due to the actual treatment of count as an atomic_t.
You will not be able to use the standard atomic ops unless you increase them
to 64-bits on ppc64.
> And if we _do_ convert it to be an atomic_t, should _that_
> be where the real type for count gets established?
You should not do that unless you increase atomic_t to 64-bits on ppc64.
> And finally, I've been working on merging header files
> under the vague guideline of "merge maintaining existing
> functionality/breakage". I've been trying NOT to introduce
> simultaneous "improvements" at the risk of breaking something.
Sounds reasonable.
> To that end, I ask if the request to make 'count' be 64-bits
> should be submitted as a follow on patch that stands on its
> own and can clean up around it as necessary? Or do you want
> it mixed in with this "merge" patch too?
Follow-on is fine.
David
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 13, Issue 51
From: vanamali gouripeddi @ 2005-09-23 14:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050923020004.5B44F68368@ozlabs.org>
hello
i hav started a project to port linux on ppc8260 can u plz let me know
which is the stable kernel thet is experimented
shashank
On 9/23/05, linuxppc-embedded-request@ozlabs.org
<linuxppc-embedded-request@ozlabs.org> wrote:
> Send Linuxppc-embedded mailing list submissions to
> linuxppc-embedded@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> or, via email, send a message with subject or body 'help' to
> linuxppc-embedded-request@ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-embedded-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
>
>
> Today's Topics:
>
> 1. Re: How to limit the log file size? (Ricardo Scop)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Sep 2005 17:47:40 -0300
> From: Ricardo Scop <scop@digitel.com.br>
> Subject: Re: How to limit the log file size?
> To: ????EMAIL <rober@opnet.com.tw>, linuxppc-embedded@ozlabs.org
> Message-ID: <200509221747.41076.scop@digitel.com.br>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Rober,
>
> On Wednesday 21 September 2005 23:07, 徐小威的EMAIL wrote:
> > Hi all:
> >
> > There are some daemon like snmpd, boa...has log file at directory
> > var, I want to know how to limte it's file size?
>
> I'm using emlog module (http://www.circlemud.org/~jelson/software/emlog/) to
>
> create circular buffers that are used as log files instead of regular ones.
>
> You can define the file size when it is created; runs smoothly and
> flawlessly.
>
> HTH,
>
> --
> Ricardo Scop.
>
> \|/
> ___ -*-
> (@ @)/|\
> / V \| R SCOP Consult.
> /( )\ Linux-based communications
> --^^---^^+------------------------------
> rscop@matrix.com.br
> +55 51 999-36-777
> Porto Alegre, RS - BRazil
> --
> P. S.: "If you don't have time to do it right, when will you have time
> to do it over?" -- Penny Hines
>
>
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 13, Issue 51
> *************************************************
>
^ permalink raw reply
* Re: [PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
From: Roland Dreier @ 2005-09-23 15:17 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-embedded
In-Reply-To: <20050923082407.GA14671@gate.ebshome.net>
Eugene> Booted new kernel on Ocotea and everything seems to be OK.
I tested on Yucca/440SPe and it works fine for me too.
Thanks,
Roland
^ permalink raw reply
* Tiny patch for cputable.c -> 750CXe support
From: Nicolas DET @ 2005-09-23 16:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Morton, Sven Luther, David Holm
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
Amiga............: SimpleMail http://simplemail.sourceforge.net/
Unix.............: Metamail ftp://ftp.bellcore.com/nsb/
Windows/Macintosh: Eudora http://www.qualcomm.com/
General info about MIME can be found at:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/top.html
[-- Attachment #2: Type: text/plain, Size: 482 bytes --]
Hello,
You can find enclosed or at
http://arrakin.homedns.org/~nicolas/cputable_750CXe_2.6.14.rc1.diff
A tiny patch which alow to correctly recognized every (let's hope) 750CXe
cpus.
Tested on my system (750 CXe rev 3.1, PVR: 0008 3311).
Feel free to comment and review it.
By the way, a nice 750CXe PVR summary can be found there:
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/291C8D0EF3EAEC1687256B72005C745C#C1
Regards,
--
Nicolas DET
MorphOS & Linux developer
[-- Attachment #3: cputable_750CXe_2.6.14.rc1.diff --]
[-- Type: application/octet-stream, Size: 2626 bytes --]
--- linux-2.6.14-rc1/arch/ppc/kernel/cputable.c 2005-09-14 08:14:43.672219560 +0200
+++ linux-2.6.14-rc1_nico/arch/ppc/kernel/cputable.c 2005-09-23 17:01:40.355003000 +0200
@@ -198,6 +198,7 @@
.num_pmcs = 4,
.cpu_setup = __setup_cpu_750
},
+ // For the 750CX familly see: http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/291C8D0EF3EAEC1687256B72005C745C#C1
{ /* 750CX (80100 and 8010x?) */
.pvr_mask = 0xfffffff0,
.pvr_value = 0x00080100,
@@ -212,10 +213,10 @@
.num_pmcs = 4,
.cpu_setup = __setup_cpu_750cx
},
- { /* 750CX (82201 and 82202) */
- .pvr_mask = 0xfffffff0,
- .pvr_value = 0x00082200,
- .cpu_name = "750CX",
+ { /* 750CXe (82202) */
+ .pvr_mask = 0xffffffff,
+ .pvr_value = 0x00082202,
+ .cpu_name = "750CXe rev 2.2",
.cpu_features = CPU_FTR_COMMON |
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
@@ -226,10 +227,24 @@
.num_pmcs = 4,
.cpu_setup = __setup_cpu_750cx
},
- { /* 750CXe (82214) */
- .pvr_mask = 0xfffffff0,
- .pvr_value = 0x00082210,
- .cpu_name = "750CXe",
+ { /* 750CXe (82214 & 82314) */
+ .pvr_mask = 0xfffff0ff,
+ .pvr_value = 0x00082214,
+ .cpu_name = "750CXe rev 2.4",
+ .cpu_features = CPU_FTR_COMMON |
+ CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
+ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
+ CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP,
+ .cpu_user_features = COMMON_PPC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750cx
+ },
+ { /* 750CXe (00082311 or 00083311) revision 3.1 / 3.1 pre_GA */
+ .pvr_mask = 0xffff0fff,
+ .pvr_value = 0x00080311,
+ .cpu_name = "750CXe rev 3.1",
.cpu_features = CPU_FTR_COMMON |
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
@@ -243,7 +258,21 @@
{ /* 750CXe "Gekko" (83214) */
.pvr_mask = 0xffffffff,
.pvr_value = 0x00083214,
- .cpu_name = "750CXe",
+ .cpu_name = "750CXe 'Gekko'",
+ .cpu_features = CPU_FTR_COMMON |
+ CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
+ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
+ CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP,
+ .cpu_user_features = COMMON_PPC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750cx
+ },
+ { /* 750CX (82201 and 82202) */
+ .pvr_mask = 0xfffffff0,
+ .pvr_value = 0x00082200,
+ .cpu_name = "750CX",
.cpu_features = CPU_FTR_COMMON |
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
^ permalink raw reply
* Re: Tiny patch for cputable.c -> 750CXe support
From: Kumar Gala @ 2005-09-23 15:54 UTC (permalink / raw)
To: Nicolas DET; +Cc: Andrew Morton, linuxppc-dev, Sven Luther, David Holm
In-Reply-To: <20050923152242.BE6F62400135@mwinf0609.wanadoo.fr>
This patch is overkill for what you want.
First you are changing 82202 which is listed as a 750CX to be
reported as a 750CXe. Second, why not just add in the one case for
00083311 which is missing. Finally, we shouldn't put the revision
info into the cpu_name unless it actually matters. Seeing as the
cpu_features fields are all the same for all 750CXe parts there is no
need to distinguish them, we only need to ensure a match occurs.
Your patch really should be something like:
+ { /* 750CXe rev 3.1 */
+ .pvr_mask = 0xffff0fff,
+ .pvr_value = 0x00080311,
+ .cpu_name = "750CXe",
+ .cpu_features = CPU_FTR_COMMON |
+ CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
+ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
+ CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP,
+ .cpu_user_features = COMMON_PPC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750cx
+ },
- kumar
On Sep 23, 2005, at 11:22 AM, Nicolas DET wrote:
> Hello,
>
> You can find enclosed or at
> http://arrakin.homedns.org/~nicolas/cputable_750CXe_2.6.14.rc1.diff
>
> A tiny patch which alow to correctly recognized every (let's hope)
> 750CXe
> cpus.
> Tested on my system (750 CXe rev 3.1, PVR: 0008 3311).
>
> Feel free to comment and review it.
>
> By the way, a nice 750CXe PVR summary can be found there:
> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/
> 291C8D0EF3EAEC
> 1687256B72005C745C#C1
>
> Regards,
> --
> Nicolas DET
> MorphOS & Linux developer
>
> <cputable_750CXe_2.6.14.rc1.diff>
> <ATT368009.txt>
>
^ permalink raw reply
* [PATCH] powerpc: merge semaphore.h
From: Becky Bruce @ 2005-09-23 16:07 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
powerpc: Merge semaphore.h
Adopted the ppc64 version of semaphore.h. The 32-bit version used
smp_wmb(), but recent updates to atomic.h mean this is no longer required.
The 64-bit version made use of unlikely(), which has been retained in the
combined version.
This patch requires the recent atomic.h patch.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 76b1ba19ac14976b8cd288180bb939f429a70820
tree 330c84e832b71d9b803feaa340de40de689edc78
parent ab08c88845ac6e755db2ef806c36d1e469ef4180
author Becky Bruce <becky.bruce@freescale.com> Fri, 23 Sep 2005 11:01:14 -0500
committer Becky Bruce <becky.bruce@freescale.com> Fri, 23 Sep 2005 11:01:14 -0500
include/asm-powerpc/semaphore.h | 98 ++++++++++++++++++++++++++++++++++
include/asm-ppc/semaphore.h | 111 ---------------------------------------
include/asm-ppc64/semaphore.h | 98 ----------------------------------
3 files changed, 98 insertions(+), 209 deletions(-)
diff --git a/include/asm-powerpc/semaphore.h b/include/asm-powerpc/semaphore.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/semaphore.h
@@ -0,0 +1,98 @@
+#ifndef _ASM_POWERPC_SEMAPHORE_H
+#define _ASM_POWERPC_SEMAPHORE_H
+
+/*
+ * Remove spinlock-based RW semaphores; RW semaphore definitions are
+ * now in rwsem.h and we use the generic lib/rwsem.c implementation.
+ * Rework semaphores to use atomic_dec_if_positive.
+ * -- Paul Mackerras (paulus@samba.org)
+ */
+
+#ifdef __KERNEL__
+
+#include <asm/atomic.h>
+#include <asm/system.h>
+#include <linux/wait.h>
+#include <linux/rwsem.h>
+
+struct semaphore {
+ /*
+ * Note that any negative value of count is equivalent to 0,
+ * but additionally indicates that some process(es) might be
+ * sleeping on `wait'.
+ */
+ atomic_t count;
+ wait_queue_head_t wait;
+};
+
+#define __SEMAPHORE_INITIALIZER(name, n) \
+{ \
+ .count = ATOMIC_INIT(n), \
+ .wait = __WAIT_QUEUE_HEAD_INITIALIZER((name).wait) \
+}
+
+#define __MUTEX_INITIALIZER(name) \
+ __SEMAPHORE_INITIALIZER(name, 1)
+
+#define __DECLARE_SEMAPHORE_GENERIC(name, count) \
+ struct semaphore name = __SEMAPHORE_INITIALIZER(name,count)
+
+#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name, 1)
+#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name, 0)
+
+static inline void sema_init (struct semaphore *sem, int val)
+{
+ atomic_set(&sem->count, val);
+ init_waitqueue_head(&sem->wait);
+}
+
+static inline void init_MUTEX (struct semaphore *sem)
+{
+ sema_init(sem, 1);
+}
+
+static inline void init_MUTEX_LOCKED (struct semaphore *sem)
+{
+ sema_init(sem, 0);
+}
+
+extern void __down(struct semaphore * sem);
+extern int __down_interruptible(struct semaphore * sem);
+extern void __up(struct semaphore * sem);
+
+static inline void down(struct semaphore * sem)
+{
+ might_sleep();
+
+ /*
+ * Try to get the semaphore, take the slow path if we fail.
+ */
+ if (unlikely(atomic_dec_return(&sem->count) < 0))
+ __down(sem);
+}
+
+static inline int down_interruptible(struct semaphore * sem)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (unlikely(atomic_dec_return(&sem->count) < 0))
+ ret = __down_interruptible(sem);
+ return ret;
+}
+
+static inline int down_trylock(struct semaphore * sem)
+{
+ return atomic_dec_if_positive(&sem->count) < 0;
+}
+
+static inline void up(struct semaphore * sem)
+{
+ if (unlikely(atomic_inc_return(&sem->count) <= 0))
+ __up(sem);
+}
+
+#endif /* __KERNEL__ */
+
+#endif /* _ASM_POWERPC_SEMAPHORE_H */
diff --git a/include/asm-ppc/semaphore.h b/include/asm-ppc/semaphore.h
deleted file mode 100644
--- a/include/asm-ppc/semaphore.h
+++ /dev/null
@@ -1,111 +0,0 @@
-#ifndef _PPC_SEMAPHORE_H
-#define _PPC_SEMAPHORE_H
-
-/*
- * Swiped from asm-sparc/semaphore.h and modified
- * -- Cort (cort@cs.nmt.edu)
- *
- * Stole some rw spinlock-based semaphore stuff from asm-alpha/semaphore.h
- * -- Ani Joshi (ajoshi@unixbox.com)
- *
- * Remove spinlock-based RW semaphores; RW semaphore definitions are
- * now in rwsem.h and we use the generic lib/rwsem.c implementation.
- * Rework semaphores to use atomic_dec_if_positive.
- * -- Paul Mackerras (paulus@samba.org)
- */
-
-#ifdef __KERNEL__
-
-#include <asm/atomic.h>
-#include <asm/system.h>
-#include <linux/wait.h>
-#include <linux/rwsem.h>
-
-struct semaphore {
- /*
- * Note that any negative value of count is equivalent to 0,
- * but additionally indicates that some process(es) might be
- * sleeping on `wait'.
- */
- atomic_t count;
- wait_queue_head_t wait;
-};
-
-#define __SEMAPHORE_INITIALIZER(name, n) \
-{ \
- .count = ATOMIC_INIT(n), \
- .wait = __WAIT_QUEUE_HEAD_INITIALIZER((name).wait) \
-}
-
-#define __MUTEX_INITIALIZER(name) \
- __SEMAPHORE_INITIALIZER(name, 1)
-
-#define __DECLARE_SEMAPHORE_GENERIC(name, count) \
- struct semaphore name = __SEMAPHORE_INITIALIZER(name,count)
-
-#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name, 1)
-#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name, 0)
-
-static inline void sema_init (struct semaphore *sem, int val)
-{
- atomic_set(&sem->count, val);
- init_waitqueue_head(&sem->wait);
-}
-
-static inline void init_MUTEX (struct semaphore *sem)
-{
- sema_init(sem, 1);
-}
-
-static inline void init_MUTEX_LOCKED (struct semaphore *sem)
-{
- sema_init(sem, 0);
-}
-
-extern void __down(struct semaphore * sem);
-extern int __down_interruptible(struct semaphore * sem);
-extern void __up(struct semaphore * sem);
-
-extern inline void down(struct semaphore * sem)
-{
- might_sleep();
-
- /*
- * Try to get the semaphore, take the slow path if we fail.
- */
- if (atomic_dec_return(&sem->count) < 0)
- __down(sem);
- smp_wmb();
-}
-
-extern inline int down_interruptible(struct semaphore * sem)
-{
- int ret = 0;
-
- might_sleep();
-
- if (atomic_dec_return(&sem->count) < 0)
- ret = __down_interruptible(sem);
- smp_wmb();
- return ret;
-}
-
-extern inline int down_trylock(struct semaphore * sem)
-{
- int ret;
-
- ret = atomic_dec_if_positive(&sem->count) < 0;
- smp_wmb();
- return ret;
-}
-
-extern inline void up(struct semaphore * sem)
-{
- smp_wmb();
- if (atomic_inc_return(&sem->count) <= 0)
- __up(sem);
-}
-
-#endif /* __KERNEL__ */
-
-#endif /* !(_PPC_SEMAPHORE_H) */
diff --git a/include/asm-ppc64/semaphore.h b/include/asm-ppc64/semaphore.h
deleted file mode 100644
--- a/include/asm-ppc64/semaphore.h
+++ /dev/null
@@ -1,98 +0,0 @@
-#ifndef _PPC64_SEMAPHORE_H
-#define _PPC64_SEMAPHORE_H
-
-/*
- * Remove spinlock-based RW semaphores; RW semaphore definitions are
- * now in rwsem.h and we use the generic lib/rwsem.c implementation.
- * Rework semaphores to use atomic_dec_if_positive.
- * -- Paul Mackerras (paulus@samba.org)
- */
-
-#ifdef __KERNEL__
-
-#include <asm/atomic.h>
-#include <asm/system.h>
-#include <linux/wait.h>
-#include <linux/rwsem.h>
-
-struct semaphore {
- /*
- * Note that any negative value of count is equivalent to 0,
- * but additionally indicates that some process(es) might be
- * sleeping on `wait'.
- */
- atomic_t count;
- wait_queue_head_t wait;
-};
-
-#define __SEMAPHORE_INITIALIZER(name, n) \
-{ \
- .count = ATOMIC_INIT(n), \
- .wait = __WAIT_QUEUE_HEAD_INITIALIZER((name).wait) \
-}
-
-#define __MUTEX_INITIALIZER(name) \
- __SEMAPHORE_INITIALIZER(name, 1)
-
-#define __DECLARE_SEMAPHORE_GENERIC(name, count) \
- struct semaphore name = __SEMAPHORE_INITIALIZER(name,count)
-
-#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name, 1)
-#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name, 0)
-
-static inline void sema_init (struct semaphore *sem, int val)
-{
- atomic_set(&sem->count, val);
- init_waitqueue_head(&sem->wait);
-}
-
-static inline void init_MUTEX (struct semaphore *sem)
-{
- sema_init(sem, 1);
-}
-
-static inline void init_MUTEX_LOCKED (struct semaphore *sem)
-{
- sema_init(sem, 0);
-}
-
-extern void __down(struct semaphore * sem);
-extern int __down_interruptible(struct semaphore * sem);
-extern void __up(struct semaphore * sem);
-
-static inline void down(struct semaphore * sem)
-{
- might_sleep();
-
- /*
- * Try to get the semaphore, take the slow path if we fail.
- */
- if (unlikely(atomic_dec_return(&sem->count) < 0))
- __down(sem);
-}
-
-static inline int down_interruptible(struct semaphore * sem)
-{
- int ret = 0;
-
- might_sleep();
-
- if (unlikely(atomic_dec_return(&sem->count) < 0))
- ret = __down_interruptible(sem);
- return ret;
-}
-
-static inline int down_trylock(struct semaphore * sem)
-{
- return atomic_dec_if_positive(&sem->count) < 0;
-}
-
-static inline void up(struct semaphore * sem)
-{
- if (unlikely(atomic_inc_return(&sem->count) <= 0))
- __up(sem);
-}
-
-#endif /* __KERNEL__ */
-
-#endif /* !(_PPC64_SEMAPHORE_H) */
^ permalink raw reply
* moving math-emu
From: Kumar Gala @ 2005-09-23 16:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, ppc-dev list
Paul,
I have a big patch that moves arch/ppc/math-emu to arch/powerpc/math-
emu and fixes up the arch/ppc/Makefile. How do you want me to send
this to you since its too big for the list or can you just make this
change since its:
1. git rename arch/ppc/math-emu arch/powerpc/math-emu
2. fixup arch/ppc/Makefile so:
core-$(CONFIG_MATH_EMULATION) += arch/powerpc/math-emu/
Let me know.
- kumar
^ permalink raw reply
* Re: SPI bus master driver for the Freescale MPC52xx
From: Grant Likely @ 2005-09-23 16:33 UTC (permalink / raw)
To: bennett78, linuxppc-embedded
In-Reply-To: <43335991.1040004@digis.net>
Hi.
First off, I've included the linuxppc-embedded mailing list in my
reply. It's better to mail the list and CC: me rather than just
mailing me. There are many others far brighter than me on the list
who can provide far more help.
On 9/22/05, Frank Bennett <bennett78@digis.net> wrote:
> Gary:
My name is Grant
>
> I saw your patch on http://patchwork.ozlabs.org/linuxppc
> I'm developing a SPI driver for the Lite5200.
Are you using a PSC or the SPI peripheral? The driver I've written is for =
a PSC
>
> What distribution of Linux is this for?
Any distro you want. It should apply cleanly against any recent 2.6.x kern=
el
> What is this patch registry all about?
Are you refering to the bit about device drivers registering to the
SPI subsystem? If so, the first patch provides the generic SPI
infrastructure. Device drivers for SPI masters and SPI slaves
register to the SPI subsystem. That way SPI master device drivers are
decoupled from SPI slave device drivers. It follows the new device
model in the 2.6.x kernels. (See "Linux Device Drivers" book from
O'reilly for details.
> Can I get a snapshot of the mpc52xx driver stuff?
I've made no changes since posting the patch.
Eventually I'll have a public git tree with all my changes posted in
it; but not yet.
> How can I contribute to this effort?
Write code, write documentation and post patches. Also, look in the
LKML archives. There are two other competing SPI implementations that
are being developed. I've been pulled off onto other work so I've not
done any additional work. The other code looks more promising.
That being said, my code works for me so it may be usable for you as-is.
cheers,
g.
^ permalink raw reply
* Re: SPI bus master driver for the Freescale MPC52xx
From: Grant Likely @ 2005-09-23 16:54 UTC (permalink / raw)
To: bennett78, linuxppc-embedded
In-Reply-To: <528646bc0509230933251d6600@mail.gmail.com>
Bah! Your reply-to: address is broken. Check your email client.
let me try that again...
On 9/23/05, Grant Likely <glikely@gmail.com> wrote:
> Hi.
>
> First off, I've included the linuxppc-embedded mailing list in my
> reply. It's better to mail the list and CC: me rather than just
> mailing me. There are many others far brighter than me on the list
> who can provide far more help.
>
> On 9/22/05, Frank Bennett <bennett78@digis.net> wrote:
> > Gary:
> My name is Grant
>
> >
> > I saw your patch on http://patchwork.ozlabs.org/linuxppc
> > I'm developing a SPI driver for the Lite5200.
> Are you using a PSC or the SPI peripheral? The driver I've written is fo=
r a PSC
> >
> > What distribution of Linux is this for?
> Any distro you want. It should apply cleanly against any recent 2.6.x ke=
rnel
>
> > What is this patch registry all about?
> Are you refering to the bit about device drivers registering to the
> SPI subsystem? If so, the first patch provides the generic SPI
> infrastructure. Device drivers for SPI masters and SPI slaves
> register to the SPI subsystem. That way SPI master device drivers are
> decoupled from SPI slave device drivers. It follows the new device
> model in the 2.6.x kernels. (See "Linux Device Drivers" book from
> O'reilly for details.
>
> > Can I get a snapshot of the mpc52xx driver stuff?
> I've made no changes since posting the patch.
>
> Eventually I'll have a public git tree with all my changes posted in
> it; but not yet.
>
> > How can I contribute to this effort?
> Write code, write documentation and post patches. Also, look in the
> LKML archives. There are two other competing SPI implementations that
> are being developed. I've been pulled off onto other work so I've not
> done any additional work. The other code looks more promising.
>
> That being said, my code works for me so it may be usable for you as-is.
>
> cheers,
> g.
>
^ 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