Re: [PATCH 1/3] Raise the upper limit of NR_CPUS.
On Tue, Apr 22, 2008 at 01:50:05PM +1000, Stephen Rothwell wrote:
> Hi Tony,
>
> On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <[EMAIL PROTECTED]>
> wrote:
> >
> > +void __init initialise_pacas(void)
> > +{
> > + int cpu;
> > + unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
>
> This line could do with a comment saying what it is doing ...
It does need a comment I agree, but I don't think I can do it justice :)
... I just used what was already there.
> > +++ b/include/asm-powerpc/paca.h
> >
> > +#if NR_CPUS >= 32
> > +#define NR_STATIC_PACAS64
>
> This allocates 64 pacas etc for NR_CPUS == 32 so surely that test should
> be >?
Yes it should be.
Yours Tony
linux.conf.auhttp://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Monday 21 April 2008, Benjamin Herrenschmidt wrote: > On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote: > > -- > > - As suggested by Benjamin Herrenschmidt, don't determine endpoint mode > > by looking at the already configured PCIe port state, but evaluate > > the device_type property instead. This makes it possible for boards > > without a previously run PCIe configuration (e.g. U-Boot) to configure > > a port as endpoint as well. > > > > - Don't map the big external config space upon endpoint configuration. > > > > - Introduce "vendor-id" and "device-id" properties to be written to > > the host bridge. > > and class-code too ? Sure, could be done. But this is not really endpoint/root-complex related. So I suggest to add this later with an additional patch. > Appart from that, I'll have a quick look at the patch later today but at > first it looks good. Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 22, 2008 12:35 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev list; Gala Kumar
> Subject: RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
>
> On Mon, 2008-04-21 at 18:01 +0800, Jin Zhengxiong wrote:
> > Hi, Michael,
> >
> > Thank you very much for you input, please see my inline answer.
>
> No worries.
>
> > > > +static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi) {
> > > > + int i, len;
> > > > + const u32 *p;
> > > > +
> > > > + p = of_get_property(msi->of_node,
> "msi-available-ranges", &len);
> > > > + if (!p) {
> > > > + pr_debug("fsl_msi: no msi-available-ranges
> > > property found \
> > > > + on %s\n",
> msi->of_node->full_name);
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + if (len & 0x8 != 0) {
> > > > + printk(KERN_WARNING "fsl_msi: Malformed
> > > msi-available-ranges "
> > > > + "property on %s\n",
> msi->of_node->full_name);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Do you really want a bitwise and with 0x8?
> > >
> > The range for the msi interrupt can be seperated to several part.
> > This can used to check the if the ranges is correct.
>
> I don't see how. AFAIK the "msi-available-ranges" property is
> just a list of u32 pairs, so the only thing that makes sense
> is to check that the length is a multiple of 8, not that it
> has the 3rd bit set.
>
I found the problem. I'll check the length if it's a multiple of 8.
Thanks
> > > > +static void fsl_compose_msi_msg(struct pci_dev *pdev,
> int hwirq,
> > > > + struct msi_msg *msg)
> > > > +{
> > > > + unsigned int srs;
> > > > + unsigned int ibs;
> > > > + struct fsl_msi *msi = fsl_msi;
> > > > +
> > > > + srs = hwirq / INT_PER_MSIR;
> > > > + ibs = hwirq % INT_PER_MSIR;
> > > > +
> > > > + msg->address_lo = msi->msi_addr_lo;
> > > > + msg->address_hi = msi->msi_addr_hi;
> > > > + msg->data = (srs << 5) | (ibs & 0x1F);
> > >
> > > Is the 5 and 0x1F independent of the INT_PER_MSIR value?
> Given the
> > > current values isn't this a no-op, or am I missing something?
> > >
> > Do you mean there're another way to get the msg->data from
> the hwirq?
>
> No I mean I'm confused about the maths here. If we pull out
> the variables it boils down to:
>
> data = ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)
>
> Which doesn't seem to actually do anything?
>
Thanks, The hwirq number can stand for the data to the msiir in this
case.
I'll change this.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
On Tuesday 22 April 2008, Benjamin Herrenschmidt wrote: > On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote: > > On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote: > > > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects > > > the internal loopback mode. Clear these bits so that both EMACs > > > don't use loopback mode as default. > > > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > > --- > > > I'm not sure if this should be done here in the board platform code, > > > or in the newemac driver or perhaps in some code common for 405EX. > > > > > > Any thoughts on this welcome. > > > > This should be done in EMAC since we also need to force internal > > loopback & clocking when probing the PHY or we might not probe > > it properly (and fail reset) if there is no link. > > Is that patch still needed if I apply Valentine patches ? I'm fixing > them up so they don't break DCR MMIO anymore. Great. I will send an additional patch to take care of this 405EX(r) loopback issue once your version of Valentines patches is available. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
On Mon, 2008-04-21 at 18:01 +0800, Jin Zhengxiong wrote:
> Hi, Michael,
>
> Thank you very much for you input, please see my inline answer.
No worries.
> > > +static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi)
> > > +{
> > > + int i, len;
> > > + const u32 *p;
> > > +
> > > + p = of_get_property(msi->of_node, "msi-available-ranges", &len);
> > > + if (!p) {
> > > + pr_debug("fsl_msi: no msi-available-ranges
> > property found \
> > > + on %s\n", msi->of_node->full_name);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + if (len & 0x8 != 0) {
> > > + printk(KERN_WARNING "fsl_msi: Malformed
> > msi-available-ranges "
> > > +"property on %s\n", msi->of_node->full_name);
> > > + return -EINVAL;
> > > + }
> >
> > Do you really want a bitwise and with 0x8?
> >
> The range for the msi interrupt can be seperated to several part.
> This can used to check the if the ranges is correct.
I don't see how. AFAIK the "msi-available-ranges" property is just a
list of u32 pairs, so the only thing that makes sense is to check that
the length is a multiple of 8, not that it has the 3rd bit set.
> > > +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
> > > + struct msi_msg *msg)
> > > +{
> > > + unsigned int srs;
> > > + unsigned int ibs;
> > > + struct fsl_msi *msi = fsl_msi;
> > > +
> > > + srs = hwirq / INT_PER_MSIR;
> > > + ibs = hwirq % INT_PER_MSIR;
> > > +
> > > + msg->address_lo = msi->msi_addr_lo;
> > > + msg->address_hi = msi->msi_addr_hi;
> > > + msg->data = (srs << 5) | (ibs & 0x1F);
> >
> > Is the 5 and 0x1F independent of the INT_PER_MSIR value? Given the
> > current values isn't this a no-op, or am I missing something?
> >
> Do you mean there're another way to get the msg->data from the hwirq?
No I mean I'm confused about the maths here. If we pull out the
variables it boils down to:
data = ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)
Which doesn't seem to actually do anything?
> > > +static int fsl_setup_msi_irqs(struct pci_dev *pdev, int
> > nvec, int type)
> > > +{
> > > + irq_hw_number_t hwirq;
> > > + int rc;
> > > + unsigned int virq;
> > > + struct msi_desc *entry;
> > > + struct msi_msg msg;
> > > + struct fsl_msi *msi = fsl_msi;
> >
> > A couple of places you put this into a local called "msi"
> > which is not the
> > greatest name in the world IMHO :)
> >
> Thank you, I'll try to use another name, Do you have any suggestion?
Oh I dunno, maybe msi_data or msi_state ?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] Make iSeries spin on __secondary_hold_spinloop, like pSeries.
Hi Tony, On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <[EMAIL PROTECTED]> wrote: > > Currently all iSeries secondary CPU's spin directly on the cpu_start in thier > paca. Make them spin on the global __secondary_hold_spinloop, until after the > pacas have been initialised. > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> (Noting that the __secondary_hold_spinloop variable was already being set for legacy iSeries even though it was not being used previously.) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpndsH7Xk8wq.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] Raise the upper limit of NR_CPUS.
Hi Tony,
On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <[EMAIL PROTECTED]> wrote:
>
> +void __init initialise_pacas(void)
> +{
> + int cpu;
> + unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
This line could do with a comment saying what it is doing ...
> +++ b/include/asm-powerpc/paca.h
>
> +#if NR_CPUS >= 32
> +#define NR_STATIC_PACAS 64
This allocates 64 pacas etc for NR_CPUS == 32 so surely that test should
be >?
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp6Ty1Ge99HA.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] Make iSeries spin on __secondary_hold_spinloop, like pSeries.
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier paca. Make them spin on the global __secondary_hold_spinloop, until after the pacas have been initialised. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- arch/powerpc/platforms/iseries/exception.S | 27 ++- 1 files changed, 26 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/iseries/exception.S b/arch/powerpc/platforms/iseries/exception.S index c775cd4..8ff330d 100644 --- a/arch/powerpc/platforms/iseries/exception.S +++ b/arch/powerpc/platforms/iseries/exception.S @@ -59,8 +59,33 @@ system_reset_iSeries: andcr4,r4,r5 mtspr SPRN_CTRLT,r4 +/* Spin on __secondary_hold_spinloop until it is updated by the boot cpu. */ +/* In the UP case we'll yeild() later, and we will not access the paca anyway */ +#ifdef CONFIG_SMP 1: HMT_LOW + LOAD_REG_IMMEDIATE(r23, __secondary_hold_spinloop) + ld r23,0(r23) + sync + LOAD_REG_IMMEDIATE(r3,current_set) + sldir28,r24,3 /* get current_set[cpu#] */ + ldx r3,r3,r28 + addir1,r3,THREAD_SIZE + subir1,r1,STACK_FRAME_OVERHEAD + + cmpwi 0,r23,0 /* Keep poking the Hypervisor until */ + bne 2f /* we're released */ + /* Let the Hypervisor know we are alive */ + /* 8002 is a call to HvCallCfg::getLps, a harmless Hypervisor function */ + lis r3,0x8002 + rldicr r3,r3,32,15 /* r0 = (r3 << 32) & 0x */ + li r0,-1 /* r0=-1 indicates a Hypervisor call */ + sc /* Invoke the hypervisor via a system call */ + b 1b +#endif + +2: + HMT_LOW #ifdef CONFIG_SMP lbz r23,PACAPROCSTART(r13) /* Test if this processor * should start */ @@ -91,7 +116,7 @@ iSeries_secondary_smp_loop: li r0,-1 /* r0=-1 indicates a Hypervisor call */ sc /* Invoke the hypervisor via a system call */ mfspr r13,SPRN_SPRG3 /* Put r13 back */ - b 1b /* If SMP not configured, secondaries + b 2b /* If SMP not configured, secondaries * loop forever */ /*** ISeries-LPAR interrupt handlers ***/ -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] Move the paca array into the BSS.
With NR_CPUS=1024
textdata bss dec hex filename
137 1704032 0 1704169 1a00e9 arch/powerpc/kernel/paca.o :Before
121 1179744 524288 1704153 1a00d9 arch/powerpc/kernel/paca.o :After
Now that we're not staatically allocating the paca, we don't need the
NR_STATIC_PACAS #define anymore.
Also remove unneeded #includes.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/paca.c | 64 +++-
include/asm-powerpc/paca.h | 17 ---
2 files changed, 4 insertions(+), 77 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 7cd55f2..c4c02c6 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -7,26 +7,11 @@
* 2 of the License, or (at your option) any later version.
*/
-#include
#include
#include
-#include
-#include
-#include
#include
#include
-#include
-
-/*
- * In order to handle "strange" values of NR_CPUS, Make sure we use
- * max(NR_CPUS, NR_STATIC_PACAS) for array sizes below
- */
-#if NR_CPUS > NR_STATIC_PACAS
-#define MAX_CPUS NR_CPUS
-#else
-#define MAX_CPUS NR_STATIC_PACAS
-#endif
/* This symbol is provided by the linker - let it fill in the paca
* field correctly */
@@ -42,7 +27,7 @@ extern unsigned long __toc_start;
* will suffice to ensure that it doesn't cross a page boundary.
*/
struct lppaca lppaca[] = {
- [0 ... (MAX_CPUS-1)] = {
+ [0 ... (NR_CPUS-1)] = {
.desc = 0xd397d781, /* "LpPa" */
.size = sizeof(struct lppaca),
.dyn_proc_status = 2,
@@ -59,7 +44,7 @@ struct lppaca lppaca[] = {
* initially, hence will all be invaild until we actually write them.
*/
struct slb_shadow slb_shadow[] __cacheline_aligned = {
- [0 ... (MAX_CPUS-1)] = {
+ [0 ... (NR_CPUS-1)] = {
.persistent = SLB_NUM_BOLTED,
.buffer_length = sizeof(struct slb_shadow),
},
@@ -74,57 +59,16 @@ struct slb_shadow slb_shadow[] __cacheline_aligned = {
* processors. The processor VPD array needs one entry per physical
* processor (not thread).
*/
-#define PACA_INIT(number) \
-{ \
- .lppaca_ptr = &lppaca[number], \
- .lock_token = 0x8000, \
- .paca_index = (number), /* Paca Index */\
- .kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
- .hw_cpu_id = 0x,\
- .slb_shadow_ptr = &slb_shadow[number], \
- .__current = &init_task,\
-}
-
-struct paca_struct paca[MAX_CPUS] = {
- PACA_INIT(0),
-#if NR_CPUS > 1
- PACA_INIT( 1), PACA_INIT( 2), PACA_INIT( 3),
-#if NR_CPUS > 4
- PACA_INIT( 4), PACA_INIT( 5), PACA_INIT( 6), PACA_INIT( 7),
-#if NR_CPUS > 8
- PACA_INIT( 8), PACA_INIT( 9), PACA_INIT( 10), PACA_INIT( 11),
- PACA_INIT( 12), PACA_INIT( 13), PACA_INIT( 14), PACA_INIT( 15),
- PACA_INIT( 16), PACA_INIT( 17), PACA_INIT( 18), PACA_INIT( 19),
- PACA_INIT( 20), PACA_INIT( 21), PACA_INIT( 22), PACA_INIT( 23),
- PACA_INIT( 24), PACA_INIT( 25), PACA_INIT( 26), PACA_INIT( 27),
- PACA_INIT( 28), PACA_INIT( 29), PACA_INIT( 30), PACA_INIT( 31),
-#if NR_CPUS > 32
- PACA_INIT( 32), PACA_INIT( 33), PACA_INIT( 34), PACA_INIT( 35),
- PACA_INIT( 36), PACA_INIT( 37), PACA_INIT( 38), PACA_INIT( 39),
- PACA_INIT( 40), PACA_INIT( 41), PACA_INIT( 42), PACA_INIT( 43),
- PACA_INIT( 44), PACA_INIT( 45), PACA_INIT( 46), PACA_INIT( 47),
- PACA_INIT( 48), PACA_INIT( 49), PACA_INIT( 50), PACA_INIT( 51),
- PACA_INIT( 52), PACA_INIT( 53), PACA_INIT( 54), PACA_INIT( 55),
- PACA_INIT( 56), PACA_INIT( 57), PACA_INIT( 58), PACA_INIT( 59),
- PACA_INIT( 60), PACA_INIT( 61), PACA_INIT( 62), PACA_INIT( 63),
-#endif
-#endif
-#endif
-#endif
-};
+struct paca_struct paca[NR_CPUS];
EXPORT_SYMBOL(paca);
-/*
- * The first few (NR_STATIC_PACAS) paca entires are initiialised
- * statically. populate the rest.
- */
void __init initialise_pacas(void)
{
int cpu;
unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
/* Can't use for_each_*_cpu, as they aren't functional yet */
- for (cpu = NR_STATIC_PACAS; cpu < NR_CPUS; cpu++) {
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
struct paca_struct *new_paca = &paca[cpu];
new_paca->lppaca_ptr = &lppaca[cpu];
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index 871f693..0bfc180 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -22,23 +22,6 @@
#include
#include
-/*
-
[PATCH 1/3] Raise the upper limit of NR_CPUS.
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required functionality to fill in any excess pacas
at runtime.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/paca.c | 57
arch/powerpc/kernel/setup_64.c |3 ++
arch/powerpc/platforms/Kconfig.cputype |4 +-
include/asm-powerpc/paca.h | 20 +++
4 files changed, 61 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index ac163bd..7cd55f2 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -18,6 +18,15 @@
#include
#include
+/*
+ * In order to handle "strange" values of NR_CPUS, Make sure we use
+ * max(NR_CPUS, NR_STATIC_PACAS) for array sizes below
+ */
+#if NR_CPUS > NR_STATIC_PACAS
+#define MAX_CPUS NR_CPUS
+#else
+#define MAX_CPUS NR_STATIC_PACAS
+#endif
/* This symbol is provided by the linker - let it fill in the paca
* field correctly */
@@ -33,7 +42,7 @@ extern unsigned long __toc_start;
* will suffice to ensure that it doesn't cross a page boundary.
*/
struct lppaca lppaca[] = {
- [0 ... (NR_CPUS-1)] = {
+ [0 ... (MAX_CPUS-1)] = {
.desc = 0xd397d781, /* "LpPa" */
.size = sizeof(struct lppaca),
.dyn_proc_status = 2,
@@ -50,7 +59,7 @@ struct lppaca lppaca[] = {
* initially, hence will all be invaild until we actually write them.
*/
struct slb_shadow slb_shadow[] __cacheline_aligned = {
- [0 ... (NR_CPUS-1)] = {
+ [0 ... (MAX_CPUS-1)] = {
.persistent = SLB_NUM_BOLTED,
.buffer_length = sizeof(struct slb_shadow),
},
@@ -76,7 +85,7 @@ struct slb_shadow slb_shadow[] __cacheline_aligned = {
.__current = &init_task,\
}
-struct paca_struct paca[] = {
+struct paca_struct paca[MAX_CPUS] = {
PACA_INIT(0),
#if NR_CPUS > 1
PACA_INIT( 1), PACA_INIT( 2), PACA_INIT( 3),
@@ -98,27 +107,33 @@ struct paca_struct paca[] = {
PACA_INIT( 52), PACA_INIT( 53), PACA_INIT( 54), PACA_INIT( 55),
PACA_INIT( 56), PACA_INIT( 57), PACA_INIT( 58), PACA_INIT( 59),
PACA_INIT( 60), PACA_INIT( 61), PACA_INIT( 62), PACA_INIT( 63),
-#if NR_CPUS > 64
- PACA_INIT( 64), PACA_INIT( 65), PACA_INIT( 66), PACA_INIT( 67),
- PACA_INIT( 68), PACA_INIT( 69), PACA_INIT( 70), PACA_INIT( 71),
- PACA_INIT( 72), PACA_INIT( 73), PACA_INIT( 74), PACA_INIT( 75),
- PACA_INIT( 76), PACA_INIT( 77), PACA_INIT( 78), PACA_INIT( 79),
- PACA_INIT( 80), PACA_INIT( 81), PACA_INIT( 82), PACA_INIT( 83),
- PACA_INIT( 84), PACA_INIT( 85), PACA_INIT( 86), PACA_INIT( 87),
- PACA_INIT( 88), PACA_INIT( 89), PACA_INIT( 90), PACA_INIT( 91),
- PACA_INIT( 92), PACA_INIT( 93), PACA_INIT( 94), PACA_INIT( 95),
- PACA_INIT( 96), PACA_INIT( 97), PACA_INIT( 98), PACA_INIT( 99),
- PACA_INIT(100), PACA_INIT(101), PACA_INIT(102), PACA_INIT(103),
- PACA_INIT(104), PACA_INIT(105), PACA_INIT(106), PACA_INIT(107),
- PACA_INIT(108), PACA_INIT(109), PACA_INIT(110), PACA_INIT(111),
- PACA_INIT(112), PACA_INIT(113), PACA_INIT(114), PACA_INIT(115),
- PACA_INIT(116), PACA_INIT(117), PACA_INIT(118), PACA_INIT(119),
- PACA_INIT(120), PACA_INIT(121), PACA_INIT(122), PACA_INIT(123),
- PACA_INIT(124), PACA_INIT(125), PACA_INIT(126), PACA_INIT(127),
-#endif
#endif
#endif
#endif
#endif
};
EXPORT_SYMBOL(paca);
+
+/*
+ * The first few (NR_STATIC_PACAS) paca entires are initiialised
+ * statically. populate the rest.
+ */
+void __init initialise_pacas(void)
+{
+ int cpu;
+ unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
+
+ /* Can't use for_each_*_cpu, as they aren't functional yet */
+ for (cpu = NR_STATIC_PACAS; cpu < NR_CPUS; cpu++) {
+ struct paca_struct *new_paca = &paca[cpu];
+
+ new_paca->lppaca_ptr = &lppaca[cpu];
+ new_paca->lock_token = 0x8000;
+ new_paca->paca_index = cpu;
+ new_paca->kernel_toc = kernel_toc;
+ new_paca->hw_cpu_id = 0x;
+ new_paca->slb_shadow_ptr = &slb_shadow[cpu];
+ new_paca->__current = &init_task;
+
+ }
+}
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 31ada9f..5e382ac 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -170,6 +170,9 @@ void __init setup_paca(int cpu)
void __init early_setup(unsigned long dt_ptr)
{
+ /* Fill in any unititialised pacas */
+ initialise_pacas();
+
/* Identify CPU type */
identify_cpu(0, mfspr(SPRN_PVR));
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 5fc
[PATCH 3/3] atyfb: Fix 64 bits resources on 32 bits archs
This fixes atyfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/video/aty/atyfb_base.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
--- linux-work.orig/drivers/video/aty/atyfb_base.c 2008-04-22
11:21:46.0 +1000
+++ linux-work/drivers/video/aty/atyfb_base.c 2008-04-22 11:23:58.0
+1000
@@ -2842,7 +2842,7 @@ static int atyfb_setcolreg(u_int regno,
#ifdef __sparc__
static int __devinit atyfb_setup_sparc(struct pci_dev *pdev,
- struct fb_info *info, unsigned long addr)
+ struct fb_info *info, resource_size_t addr)
{
struct atyfb_par *par = info->par;
struct device_node *dp;
@@ -3334,11 +3334,11 @@ static int __devinit init_from_bios(stru
}
#endif /* __i386__ */
-static int __devinit atyfb_setup_generic(struct pci_dev *pdev, struct fb_info
*info, unsigned long addr)
+static int __devinit atyfb_setup_generic(struct pci_dev *pdev, struct fb_info
*info, resource_size_t addr)
{
struct atyfb_par *par = info->par;
u16 tmp;
- unsigned long raddr;
+ resource_size_t raddr;
struct resource *rrp;
int ret = 0;
@@ -3351,8 +3351,8 @@ static int __devinit atyfb_setup_generic
PRINTKI("using auxiliary register aperture\n");
}
- info->fix.mmio_start = raddr;
- par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000);
+ info->fix.mmio_start = (unsigned long)raddr;
+ par->ati_regbase = ioremap(raddr, 0x1000);
if (par->ati_regbase == 0)
return -ENOMEM;
@@ -3374,7 +3374,7 @@ static int __devinit atyfb_setup_generic
#endif
/* Map in frame buffer */
- info->fix.smem_start = addr;
+ info->fix.smem_start = (unsigned long)addr;
info->screen_base = ioremap(addr, 0x80);
if (info->screen_base == NULL) {
ret = -ENOMEM;
@@ -3411,7 +3411,7 @@ atyfb_setup_generic_fail:
static int __devinit atyfb_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
{
- unsigned long addr, res_start, res_size;
+ resource_size_t addr, res_start, res_size;
struct fb_info *info;
struct resource *rp;
struct atyfb_par *par;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] aty128fb: Fix 64 bits resources on 32 bits archs
This fixes aty128fb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/video/aty/aty128fb.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- linux-work.orig/drivers/video/aty/aty128fb.c2008-04-22
11:18:41.0 +1000
+++ linux-work/drivers/video/aty/aty128fb.c 2008-04-22 11:19:31.0
+1000
@@ -2011,7 +2011,7 @@ static int __devinit aty128_init(struct
/* register a card++ajoshi */
static int __devinit aty128_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
{
- unsigned long fb_addr, reg_addr;
+ resource_size_t fb_addr, reg_addr;
struct aty128fb_par *par;
struct fb_info *info;
int err;
@@ -2052,7 +2052,6 @@ static int __devinit aty128_probe(struct
info->pseudo_palette = par->pseudo_palette;
/* Virtualize mmio region */
- info->fix.mmio_start = reg_addr;
par->regbase = ioremap(reg_addr, pci_resource_len(pdev, 2));
if (!par->regbase)
goto err_free_info;
@@ -2068,9 +2067,9 @@ static int __devinit aty128_probe(struct
/* Set up info->fix */
info->fix = aty128fb_fix;
- info->fix.smem_start = fb_addr;
+ info->fix.smem_start = (unsigned long)fb_addr;
info->fix.smem_len = par->vram_size;
- info->fix.mmio_start = reg_addr;
+ info->fix.mmio_start = (unsigned long)reg_addr;
/* If we can't test scratch registers, something is seriously wrong */
if (!register_test(par)) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_base.c |4 ++--
drivers/video/aty/radeonfb.h|4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- linux-work.orig/drivers/video/aty/radeon_base.c 2008-04-22
11:04:19.0 +1000
+++ linux-work/drivers/video/aty/radeon_base.c 2008-04-22 11:05:00.0
+1000
@@ -1886,7 +1886,7 @@ static int __devinit radeon_set_fbinfo (
info->screen_size = rinfo->mapped_vram;
/* Fill fix common fields */
strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
-info->fix.smem_start = rinfo->fb_base_phys;
+info->fix.smem_start = (unsigned long)rinfo->fb_base_phys;
info->fix.smem_len = rinfo->video_ram;
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
@@ -1894,7 +1894,7 @@ static int __devinit radeon_set_fbinfo (
info->fix.ypanstep = 1;
info->fix.ywrapstep = 0;
info->fix.type_aux = 0;
-info->fix.mmio_start = rinfo->mmio_base_phys;
+info->fix.mmio_start = (unsigned long)rinfo->mmio_base_phys;
info->fix.mmio_len = RADEON_REGSIZE;
info->fix.accel = FB_ACCEL_ATI_RADEON;
Index: linux-work/drivers/video/aty/radeonfb.h
===
--- linux-work.orig/drivers/video/aty/radeonfb.h2008-04-22
11:03:17.0 +1000
+++ linux-work/drivers/video/aty/radeonfb.h 2008-04-22 11:03:27.0
+1000
@@ -287,8 +287,8 @@ struct radeonfb_info {
charname[DEVICE_NAME_SIZE];
- unsigned long mmio_base_phys;
- unsigned long fb_base_phys;
+ resource_size_t mmio_base_phys;
+ resource_size_t fb_base_phys;
void __iomem*mmio_base;
void __iomem*fb_base;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
On Mon, Apr 21, 2008 at 11:25:29PM +0200, Segher Boessenkool wrote: > >> The last time arch/ppc built for me (a few days ago), it got > >> 535 warnings. Heh. > >> I don't think anyone would notice one more. Well, it wouldn't be one more, it'd be one per file that includes the header. If we choose something like asm/system.h, and scream in *** ALL CAPS!!one!11! ***, it should get through the noise. > >> Also, whoever doesn't yet know arch/ppc will be going away has been > >> living under a rock for the last two years. > > > >You say that as if it is an uncommon living condition. > > Oh sorry. "Under a rock without any connection to the intertubes". I guess you missed the recent patch someone posted with style cleanup in arch/ppc/8xx_io? :-P -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [PPC] Add strncmp to arch/ppc
Commit 0119536cd314ef95553604208c25bc35581f7f0a added an assembly version of strncmp to PowerPC. However, it changed a common header file between arch/ppc and arch/powerpc without adding strncmp to arch/ppc. This fixes that omission so that arch/ppc links again. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/ppc/kernel/ppc_ksyms.c |1 + arch/ppc/lib/string.S | 14 ++ 2 files changed, 15 insertions(+) --- linux-2.6.orig/arch/ppc/kernel/ppc_ksyms.c +++ linux-2.6/arch/ppc/kernel/ppc_ksyms.c @@ -89,6 +89,7 @@ EXPORT_SYMBOL(strncpy); EXPORT_SYMBOL(strcat); EXPORT_SYMBOL(strlen); EXPORT_SYMBOL(strcmp); +EXPORT_SYMBOL(strncmp); EXPORT_SYMBOL(csum_partial); EXPORT_SYMBOL(csum_partial_copy_generic); --- linux-2.6.orig/arch/ppc/lib/string.S +++ linux-2.6/arch/ppc/lib/string.S @@ -121,6 +121,20 @@ _GLOBAL(strcmp) beq 1b blr +_GLOBAL(strncmp) + PPC_LCMPI r5,0 + beqlr + mtctr r5 + addir5,r3,-1 + addir4,r4,-1 +1: lbzur3,1(r5) + cmpwi 1,r3,0 + lbzur0,1(r4) + subf. r3,r0,r3 + beqlr 1 + bdnzt eq,1b + blr + _GLOBAL(strlen) addir4,r3,-1 1: lbzur0,1(r4) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [PPC] 4xx: Fix duplicate phys_addr_t definition
Commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0 moved phys_addr_t definitions to include/asm-powerpc/types.h. However, arch/ppc 440 builds had a duplicate definition in include/asm-ppc/mmu.h that caused the build to fail. This removes the duplicate definition in arch/ppc. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- include/asm-ppc/mmu.h |2 -- 1 file changed, 2 deletions(-) --- linux-2.6.orig/include/asm-ppc/mmu.h +++ linux-2.6/include/asm-ppc/mmu.h @@ -15,10 +15,8 @@ * physical need a larger than native word size type. -Matt */ #ifndef CONFIG_PHYS_64BIT -typedef unsigned long phys_addr_t; #define PHYS_FMT "%.8lx" #else -typedef unsigned long long phys_addr_t; extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t); #define PHYS_FMT "%16Lx" #endif ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/6] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Valentine Barshak <[EMAIL PROTECTED]>
This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC
attached to a PHY which doesn't generate RX clock if there is no link.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock separately as opposed to global clock
selection for 440GX.
BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't
exist for MMIO type DCRs like Cell. Some future rework & improvements of the
DCR infrastructure will make that cleaner but for now, this makes it work.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c | 43 -
drivers/net/ibm_newemac/core.h |6 -
2 files changed, 47 insertions(+), 2 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22
10:31:18.0 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:38:49.0
+1000
@@ -129,10 +129,35 @@ static struct device_node *emac_boot_lis
static inline void emac_report_timeout_error(struct emac_instance *dev,
const char *error)
{
- if (net_ratelimit())
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX |
+ EMAC_FTR_440EP_PHY_CLK_FIX))
+ DBG(dev, "%s" NL, error);
+ else if (net_ratelimit())
printk(KERN_ERR "%s: %s\n", dev->ndev->name, error);
}
+/* EMAC PHY clock workaround:
+ * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX,
+ * which allows controlling each EMAC clock
+ */
+static inline void emac_rx_clk_tx(struct emac_instance *dev)
+{
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR,
+ 0, SDR0_MFR_ECS >> dev->cell_index);
+#endif
+}
+
+static inline void emac_rx_clk_default(struct emac_instance *dev)
+{
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR,
+ SDR0_MFR_ECS >> dev->cell_index, 0);
+#endif
+}
+
/* PHY polling intervals */
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
@@ -1099,9 +1124,11 @@ static int emac_open(struct net_device *
int link_poll_interval;
if (dev->phy.def->ops->poll_link(&dev->phy)) {
dev->phy.def->ops->read_link(&dev->phy);
+ emac_rx_clk_default(dev);
netif_carrier_on(dev->ndev);
link_poll_interval = PHY_POLL_LINK_ON;
} else {
+ emac_rx_clk_tx(dev);
netif_carrier_off(dev->ndev);
link_poll_interval = PHY_POLL_LINK_OFF;
}
@@ -1179,6 +1206,7 @@ static void emac_link_timer(struct work_
if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
+ emac_rx_clk_default(dev);
/* Get new link parameters */
dev->phy.def->ops->read_link(&dev->phy);
@@ -1191,6 +1219,7 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_ON;
} else {
if (netif_carrier_ok(dev->ndev)) {
+ emac_rx_clk_tx(dev);
netif_carrier_off(dev->ndev);
netif_tx_disable(dev->ndev);
emac_reinitialize(dev);
@@ -2340,6 +2369,14 @@ static int __devinit emac_init_phy(struc
if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
#endif
+ /* PHY clock workaround */
+ emac_rx_clk_tx(dev);
+
+ /* Enable internal clock source on 440GX*/
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+#endif
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2507,6 +2544,10 @@ static int __devinit emac_init_config(st
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-440gx"))
dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ } else {
+ if (of_device_is_compatible(np, "ibm,emac-440ep") ||
+ of_device_is_compatible(np, "ibm,emac-440gr"))
+ dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
}
/* Fixup some feature bits based on the device tree */
Index: linux-work/drivers/net/ibm_newemac/core.h
===
--- linux-wor
[PATCH 0/2] Fix 440 arch/ppc builds
The following two patches fix arch/ppc 440 builds. Unless some miracle occurs and people stop breaking arch/ppc with commits, this will likely be the last kernel where it builds. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/6] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Valentine Barshak <[EMAIL PROTECTED]>
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
if there's no link. Because of that it fails to find PHY chip. The older
ibm_emac
driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL
macros,
which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
does the same for "ibm,emac-440gx" compatible chips. The workaround forces
clock on -all- EMACs, so we select clock under global emac_phy_map_lock.
BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't
exist for MMIO type DCRs like Cell. Some future rework & improvements of the
DCR infrastructure will make that cleaner but for now, this makes it work.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c | 18 +-
drivers/net/ibm_newemac/core.h |8 ++--
2 files changed, 23 insertions(+), 3 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22
10:11:59.0 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:31:18.0
+1000
@@ -43,6 +43,8 @@
#include
#include
#include
+#include
+#include
#include "core.h"
@@ -2333,6 +2335,11 @@ static int __devinit emac_init_phy(struc
dev->phy.mdio_read = emac_mdio_read;
dev->phy.mdio_write = emac_mdio_write;
+ /* Enable internal clock source */
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+#endif
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2365,6 +2372,12 @@ static int __devinit emac_init_phy(struc
if (!emac_mii_phy_probe(&dev->phy, i))
break;
}
+
+ /* Enable external clock source */
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, SDR0_MFR_ECS, 0);
+#endif
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
@@ -2490,8 +2503,11 @@ static int __devinit emac_init_config(st
}
/* Check EMAC version */
- if (of_device_is_compatible(np, "ibm,emac4"))
+ if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
+ if (of_device_is_compatible(np, "ibm,emac-440gx"))
+ dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ }
/* Fixup some feature bits based on the device tree */
if (of_get_property(np, "has-inverted-stacr-oc", NULL))
Index: linux-work/drivers/net/ibm_newemac/core.h
===
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2008-04-22
10:06:31.0 +1000
+++ linux-work/drivers/net/ibm_newemac/core.h 2008-04-22 10:30:03.0
+1000
@@ -301,6 +301,10 @@ struct emac_instance {
* Set if we have new type STACR with STAOPC
*/
#define EMAC_FTR_HAS_NEW_STACR 0x0040
+/*
+ * Set if we need phy clock workaround for 440gx
+ */
+#define EMAC_FTR_440GX_PHY_CLK_FIX 0x0080
/* Right now, we don't quite handle the always/possible masks on the
@@ -312,8 +316,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR|
- EMAC_FTR_STACR_OC_INVERT|
+ EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
EMAC_FTR_HAS_TAH|
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/6] ibm_newemac Use status property for unused/unwired EMACs
From: Josh Boyer <[EMAIL PROTECTED]> Convert ibm_newemac to use the of_device_is_available function when checking for unused/unwired EMACs. We leave the current check for an "unused" property to maintain backwards compatibility for older device trees. Newer device trees should simply use the standard "status" property in the EMAC node. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) --- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22 10:42:42.0 +1000 +++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:43:01.0 +1000 @@ -2562,8 +2562,11 @@ static int __devinit emac_probe(struct o struct device_node **blist = NULL; int err, i; - /* Skip unused/unwired EMACS */ - if (of_get_property(np, "unused", NULL)) + /* Skip unused/unwired EMACS. We leave the check for an unused +* property here for now, but new flat device trees should set a +* status property to "disabled" instead. +*/ + if (of_get_property(np, "unused", NULL) || !of_device_is_available(np)) return -ENODEV; /* Find ourselves in the bootlist if we are there */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/6] ibm_newemac: Fix section mismatch warnings
From: Josh Boyer <[EMAIL PROTECTED]>
This patch fixes several section mismatch warnings in the
ibm_newemac driver similar to:
WARNING: vmlinux.o(.devinit.text+0x3a04): Section mismatch in reference from
the function emac_probe() to the function .devexit.text:tah_detach()
The function __devinit emac_probe() references
a function __devexit tah_detach().
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |2 +-
drivers/net/ibm_newemac/mal.c |4 ++--
drivers/net/ibm_newemac/rgmii.c |2 +-
drivers/net/ibm_newemac/tah.c |2 +-
drivers/net/ibm_newemac/zmii.c |2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2008-04-22
10:02:32.0 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:02:53.0
+1000
@@ -2240,7 +2240,7 @@ static int __devinit emac_of_bus_notify(
return 0;
}
-static struct notifier_block emac_of_bus_notifier = {
+static struct notifier_block emac_of_bus_notifier __devinitdata = {
.notifier_call = emac_of_bus_notify
};
Index: linux-work/drivers/net/ibm_newemac/mal.c
===
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2008-04-22
10:02:42.0 +1000
+++ linux-work/drivers/net/ibm_newemac/mal.c2008-04-22 10:02:53.0
+1000
@@ -61,8 +61,8 @@ int __devinit mal_register_commac(struct
return 0;
}
-void __devexit mal_unregister_commac(struct mal_instance *mal,
-struct mal_commac *commac)
+void mal_unregister_commac(struct mal_instance *mal,
+ struct mal_commac *commac)
{
unsigned long flags;
Index: linux-work/drivers/net/ibm_newemac/rgmii.c
===
--- linux-work.orig/drivers/net/ibm_newemac/rgmii.c 2008-03-19
13:52:35.0 +1100
+++ linux-work/drivers/net/ibm_newemac/rgmii.c 2008-04-22 10:02:53.0
+1000
@@ -179,7 +179,7 @@ void rgmii_put_mdio(struct of_device *of
mutex_unlock(&dev->lock);
}
-void __devexit rgmii_detach(struct of_device *ofdev, int input)
+void rgmii_detach(struct of_device *ofdev, int input)
{
struct rgmii_instance *dev = dev_get_drvdata(&ofdev->dev);
struct rgmii_regs __iomem *p = dev->base;
Index: linux-work/drivers/net/ibm_newemac/tah.c
===
--- linux-work.orig/drivers/net/ibm_newemac/tah.c 2008-03-26
10:39:25.0 +1100
+++ linux-work/drivers/net/ibm_newemac/tah.c2008-04-22 10:02:53.0
+1000
@@ -35,7 +35,7 @@ int __devinit tah_attach(struct of_devic
return 0;
}
-void __devexit tah_detach(struct of_device *ofdev, int channel)
+void tah_detach(struct of_device *ofdev, int channel)
{
struct tah_instance *dev = dev_get_drvdata(&ofdev->dev);
Index: linux-work/drivers/net/ibm_newemac/zmii.c
===
--- linux-work.orig/drivers/net/ibm_newemac/zmii.c 2008-03-03
11:58:49.0 +1100
+++ linux-work/drivers/net/ibm_newemac/zmii.c 2008-04-22 10:02:53.0
+1000
@@ -189,7 +189,7 @@ void zmii_set_speed(struct of_device *of
mutex_unlock(&dev->lock);
}
-void __devexit zmii_detach(struct of_device *ofdev, int input)
+void zmii_detach(struct of_device *ofdev, int input)
{
struct zmii_instance *dev = dev_get_drvdata(&ofdev->dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/6] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
From: Stefan Roese <[EMAIL PROTECTED]>
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/mal.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 6869f08..fb9c9eb 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -136,6 +136,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int
channel)
{
unsigned long flags;
+ /*
+* On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+* of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+* for the bitmask
+*/
+ if (!(channel % 8))
+ channel >>= 3;
+
spin_lock_irqsave(&mal->lock, flags);
MAL_DBG(mal, "enable_rx(%d)" NL, channel);
@@ -148,6 +156,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int
channel)
void mal_disable_rx_channel(struct mal_instance *mal, int channel)
{
+ /*
+* On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+* of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+* for the bitmask
+*/
+ if (!(channel % 8))
+ channel >>= 3;
+
set_mal_dcrn(mal, MAL_RXCARR, MAL_CHAN_MASK(channel));
MAL_DBG(mal, "disable_rx(%d)" NL, channel);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/6] ibm_newemac: Fix problem with jumbo frame support and EMAC V4.patch
From: Stefan Roese <[EMAIL PROTECTED]>
This fixes the jumbo frame support on EMAC V4 systems. Now the correct
bit is set depending on the EMAC version configured.
Tested on Kilauea (405EX) and Canyonlands (460EX).
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0789802..486901f 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -524,7 +524,10 @@ static int emac_configure(struct emac_instance *dev)
rx_size = dev->rx_fifo_size_gige;
if (dev->ndev->mtu > ETH_DATA_LEN) {
- mr1 |= EMAC_MR1_JPSM;
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4))
+ mr1 |= EMAC4_MR1_JPSM;
+ else
+ mr1 |= EMAC_MR1_JPSM;
dev->stop_timeout = STOP_TIMEOUT_1000_JUMBO;
} else
dev->stop_timeout = STOP_TIMEOUT_1000;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git master and powerpc-next branches
Kumar Gala writes: > > Once again I want to go through it carefully and understand how it all > > works, and in particular understand things like the way it ensures > > that the base address for the kmap region is aligned to a 4M boundary > > so all the kmap ptes are in a single page (assuming it does :). > > I'm not clear on why this is needed. I can see value in having the > PGD entry in place but the pte PAs would be changing all the time so I > don't see what benefit there is in keeping them in one page. Have a look at map_new_virtual in mm/highmem.c. In particular: set_pte_at(&init_mm, vaddr, &(pkmap_page_table[last_pkmap_nr]), mk_pte(page, kmap_prot)); assumes that the ptes that kmap uses are in a contiguous array whose base is pkmap_page_table. > For normal kmap ptes we cover things in one PGD via: > > #define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE*(LAST_PKMAP + > 1)) & PMD_MASK) OK, that probably does the trick ... ... yes it does. We seem to have a distinction without a difference between FIXADDR_START and FIXADDR_BOOT_START, and similarly between __FIXADDR_SIZE and __FIXADDR_BOOT_SIZE. Is there any actual difference and if not why do we have two names for the same thing? Also, we seem to have an unnecessary distinction (and unnecessary casting) between __FIXADDR_TOP and FIXADDR_TOP. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote: > > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects > > the internal loopback mode. Clear these bits so that both EMACs > > don't use loopback mode as default. > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > --- > > I'm not sure if this should be done here in the board platform code, > > or in the newemac driver or perhaps in some code common for 405EX. > > > > Any thoughts on this welcome. > > This should be done in EMAC since we also need to force internal > loopback & clocking when probing the PHY or we might not probe > it properly (and fail reset) if there is no link. Is that patch still needed if I apply Valentine patches ? I'm fixing them up so they don't break DCR MMIO anymore. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
On Mon, Apr 21, 2008 at 12:39 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
>
> > > +r) Freescale General-purpose Timers Module
> > > +
> > > +Required properties:
> > > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for
> QE
> > > + GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
> >
> > I don't think this is specific enough. It is a very real possibility
> > for Freescale to produce another part with a "general purpose timers
> > module" that isn't register level compatible (and fsl,i2c is an
> > example of what not to do).
>
> If that happens, we'll make up "fsl,gtm2". :-)
:-P
> > The compatible string should include the
> > exact chip version. Newer parts can also claim compatibility with
> > older ones.
> >
> > Defining a 'generic' compatible value is also known as "making stuff up".
> :-)
>
> Nothing wrong with making stuff up as long as we do it sanely.
>
> How about something like fsl,gtm-1.0?
The problem I have with that is that there is always the potential
that some rogue hardware will appear that messes up your sane scheme.
Plus there is pretty much no downside to just choosing a device that
the more recent parts reference.
Example: consider 3 chips using the same i2c core; say MPC8313,
MPC5200 & MPC8548. compatible lines could look like this:
compatible = "fsl,mpc8313-i2c","fsl-i2c";
compatible = "fsl,mpc5200-i2c","fsl-i2c";
compatible = "fsl,mpc8548-i2c","fsl-i2c";
Or; (assuming 8313 is where it first appeared) it could look like this:
compatible = "fsl,mpc8313-i2c";
compatible = "fsl,mpc5200-i2c","fsl,mpc8313-i2c";
compatible = "fsl,mpc8548-i2c","fsl,mpc8313-i2c";
To the driver it's just a different string ("fsl,mpc8313-i2c" instead
of "fsl-i2c"), but with the second you *always* know what an
mpc8131-i2c core is; the mpc8131 user guide tells you. Even if you
are strict about your sane naming scheme, you cannot look into the
future and someone will do something wonky on you.
The other benefit is it avoids the temptation to define generic
compatible values for things which will *never* be generic parts.
Case in point; when I did the original mpc5200 bindings I did things
like "mpc52xx-". However, there probably never will be another
mpc52xx part; and if there is it will look vastly different from the
current 5200. So I wasted all kinds of effort trying to be generic
about stuff when it is almost certainly wasted effort and additional
complexity to the naming conventions.
> > > +static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16 events)
> > > +{
> > > + out_be16(tmr->gtevr, events);
> > > +}
> >
> > Drop 'inline' and expect gcc to do the right thing.
>
> Not in a header...
Oops, yeah; not sure what I was smoking.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
On Mon, 2008-04-21 at 17:31 -0500, Kumar Gala wrote: > Ok, but we'd also need to fix setup_750_7400_hid0 and > setup_745x_specifics to test. > > There's a bit more cleanup that needs to be done here. I'm not > going > to worry about it for this patch since it covers handling a chip > errata and isn't any more "broken" than other bits of code in this fi True. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
On Apr 21, 2008, at 5:12 PM, Benjamin Herrenschmidt wrote: On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote: On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote: _GLOBAL(__setup_cpu_603) - b setup_common_caches + mflrr4 +BEGIN_FTR_SECTION + bl __init_fpu_registers +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) + bl __init_fpu_registers + bl setup_common_caches + mtlrr4 + blr _GLOBAL(__setup_cpu_604) mflrr4 bl setup_common_cache Has the feature fixup been perform yet when __setup_* is called ? Yes. We call do_feature_fixups() in early_init and call call_setup_cpu() after than on 6xx (in head_32.S). Hrm. I think that may be the other way around on 64 bits... damn, I need to consolidate these. I'd rather have the init code explicitely test for the features. Ok, but we'd also need to fix setup_750_7400_hid0 and setup_745x_specifics to test. There's a bit more cleanup that needs to be done here. I'm not going to worry about it for this patch since it covers handling a chip errata and isn't any more "broken" than other bits of code in this file. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Monday 21 April 2008, Anton Vorontsov wrote:
> On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
> > The way other platforms do this is to hav SOC-specific
> > init code, and have board-specific initcalls call the
> > relevant SOC-specific setup.
>
> I don't know about other platforms other than PowerPC and some ARM,
> of course. For example, PXA boards don't call any SOC specific code.
> Instead, looking into reworked PXA code, I can see that there are
> separate arch_initcalls() for the pxa25x, pxa27x, and pxa3xx SOCs.
Exactly: SOC-specific initcalls.
> > Among other things that facilitates kernels that handle
> > multiple SOCs (if they're closely-enough related). That
> > may not be used by many distros (handhelds.org being at
> > least a partial exception), but it certainly helps cut
> > the number of configurations that need build-testing.
>
> Is this about QE_GPIO being user-selectable?
No. It's about "kernels that handle multiple SOCs". Like
for example pxa{25,27,3x}x ... or omap{16xx,17xx,5912}.
Consider several ways to support a family of SOCs.
- One way supports only one board at a time. Testing
builds after arch level changes means rebuilding kernels
for each board ... quite possibly several dozen.
- Another supports several boards, but only if they use
the same SOC. Testing builds here takes fewer kernels;
one per SOC; better, but still routinely shortchanged.
- Yet another way supports any number of boards, using
a variety of mostly-compatible SOCs. This allows test
builds that support entire SOC families (e.g. OMAP1,
or OMAP2/OMAP3, or PXA XScale, etc).
Test builds are a quality control thing. If they're done
regularly, it's less likely you'll push code upstream
that can't build in some configuration.
> And well, I'm not objecting for placing qe gpio code under arch/, too.
> I'll resend this patch once again reverting its placement to arch/.
OK, good. Then I don't really have to be involved with that.
- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote: > On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote: > > > >> > >> _GLOBAL(__setup_cpu_603) > >> - b setup_common_caches > >> + mflrr4 > >> +BEGIN_FTR_SECTION > >> + bl __init_fpu_registers > >> +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) > >> + bl __init_fpu_registers > >> + bl setup_common_caches > >> + mtlrr4 > >> + blr > >> _GLOBAL(__setup_cpu_604) > >>mflrr4 > >>bl setup_common_cache > > > > Has the feature fixup been perform yet when __setup_* is called ? > > Yes. We call do_feature_fixups() in early_init and call > call_setup_cpu() after than on 6xx (in head_32.S). Hrm. I think that may be the other way around on 64 bits... damn, I need to consolidate these. I'd rather have the init code explicitely test for the features. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] [POWERPC] 83xx: new board support: MPC8360E-RDK
On Mon, Apr 21, 2008 at 03:05:25PM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:10 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > This is patch adds board file, device tree, and defconfig for the new
> > board, made by Freescale Semiconductor Inc. and Logic Product Development.
>
> > arch/powerpc/platforms/83xx/mpc836x_rdk.c | 106 +++
>
> I don't see anything exotic in here. This can be merged with one of
> the other non-exotic mpc83xx board files. The dts parsing takes care
> of the differences.
Please name the board file in which you think I'll easily merge this
indeed non-exotic board.
The only QE boards there are: mpc832x_{rdb,mds} and mpc836x_mds. All of
them have board-specific fixups either in the machine_device_initcall()s
or setup_arch()s.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote: _GLOBAL(__setup_cpu_603) - b setup_common_caches + mflrr4 +BEGIN_FTR_SECTION + bl __init_fpu_registers +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) + bl __init_fpu_registers + bl setup_common_caches + mtlrr4 + blr _GLOBAL(__setup_cpu_604) mflrr4 bl setup_common_cache Has the feature fixup been perform yet when __setup_* is called ? Yes. We call do_feature_fixups() in early_init and call call_setup_cpu() after than on 6xx (in head_32.S). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote: > On Monday 21 April 2008, Anton Vorontsov wrote: > > From: J. Random Hacker > > Subject: [POWERPC] cleanup board initialization code > > > > This patch removes vast amount of machine_arch_initcall()s that were > > used to solely initialize some hardware, like this: > > > > qe_add_gpio_chips(); > > fsl_gtm_init(); > > fsl_spi_init(); > > ... > > > > So, instead of calling this stuff from the board files, we implement > > own arch_initcalls for these functions. > > The way other platforms do this is to hav SOC-specific > init code, and have board-specific initcalls call the > relevant SOC-specific setup. I don't know about other platforms other than PowerPC and some ARM, of course. For example, PXA boards don't call any SOC specific code. Instead, looking into reworked PXA code, I can see that there are separate arch_initcalls() for the pxa25x, pxa27x, and pxa3xx SOCs. The same for s3c. So, at least not every platform out there doing this. Yes, I can see AVR32. But there are only two boards, and when you'll have more, probably later you'd want to eliminate some repetitive code, if possible. Here, with OF, it's quite simple because we have methods of "probing" SOC devices instead of placing init code into board files (think arch/ppc/). > Among other things that facilitates kernels that handle > multiple SOCs (if they're closely-enough related). That > may not be used by many distros (handhelds.org being at > least a partial exception), but it certainly helps cut > the number of configurations that need build-testing. Is this about QE_GPIO being user-selectable? Yes, verbose Konfig option have its own drawbacks. Though, I don't actually have any objections for making it silent. And well, I'm not objecting for placing qe gpio code under arch/, too. I'll resend this patch once again reverting its placement to arch/. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sysdev,mv64x60: early console fix
On Mon, Apr 21, 2008 at 02:02:56PM -0700, Remi Machet wrote: > The MPSC driver and prpmc2800.dts have been modified to > use property 'cell-index' as the serial port number but > the early serial console driver for the mv64x60 has not > been modified to use this new property. > > Signed-off-by: Remi Machet ([EMAIL PROTECTED]) Acked-by: Dale Farnsworth <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
The last time arch/ppc built for me (a few days ago), it got 535 warnings. I don't think anyone would notice one more. Also, whoever doesn't yet know arch/ppc will be going away has been living under a rock for the last two years. You say that as if it is an uncommon living condition. Oh sorry. "Under a rock without any connection to the intertubes". :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
> > _GLOBAL(__setup_cpu_603) > - b setup_common_caches > + mflrr4 > +BEGIN_FTR_SECTION > + bl __init_fpu_registers > +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) > + bl __init_fpu_registers > + bl setup_common_caches > + mtlrr4 > + blr > _GLOBAL(__setup_cpu_604) > mflrr4 > bl setup_common_cache Has the feature fixup been perform yet when __setup_* is called ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote: > -- > - As suggested by Benjamin Herrenschmidt, don't determine endpoint mode > by looking at the already configured PCIe port state, but evaluate > the device_type property instead. This makes it possible for boards > without a previously run PCIe configuration (e.g. U-Boot) to configure > a port as endpoint as well. > > - Don't map the big external config space upon endpoint configuration. > > - Introduce "vendor-id" and "device-id" properties to be written to > the host bridge. and class-code too ? Appart from that, I'll have a quick look at the patch later today but at first it looks good. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
On Mon, Apr 21, 2008 at 3:10 PM, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > > Speaking of making it obvious, is it time to put a #warning in some > > prominent arch/ppc header? > > > > The last time arch/ppc built for me (a few days ago), it got > 535 warnings. I don't think anyone would notice one more. > Also, whoever doesn't yet know arch/ppc will be going away > has been living under a rock for the last two years. You say that as if it is an uncommon living condition. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Mon, Apr 21, 2008 at 10:41 AM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote: > > Its not great. It has a boot time impact for every platform compiled > > into the kernel. The problem gets worse every time another block of > > code uses this method. Personally I prefer platform code calling it > > explicitly. > > > > Making it an of_platform device would also eliminate that problem, but > > you'd need a method to synchronize the driver with its users. > > > > I'm not going to raise a big stink about it, but the issue should not > > be ignored. > > Heh.. how QE GPIO is different from FSL GTM then? Should I call > fsl_gtm_init() from the board file too? For the every board? I do > believe that years later someone will show up with something like this: > > > From: J. Random Hacker > Subject: [POWERPC] cleanup board initialization code > > This patch removes vast amount of machine_arch_initcall()s that were > used to solely initialize some hardware, like this: > > qe_add_gpio_chips(); > fsl_gtm_init(); > fsl_spi_init(); Or have a soc-level helper function for calling them for you; but yes. And, no, we shouldn't have a vast array of individual initcalls because the platform code shouldn't be that large. As much as possible, multiple boards should be supported by the same platform code. I argue that most boards using the same SoC should use the same platform code. (see platforms/52xx/mpc5200_simple.c) Individual calls has the added advantage that if a board port needs those functions to *not* be called (for whatever reason) then it has the ability to not call them. It is for the same reason that the platform code is responsible for calling of_platform_bus_probe() instead of it being an initcall; it give the platform code control over the device registrations. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci issue - wrong detection of pci ressources
On Mon, 2008-04-21 at 13:55 +0200, Christian Ehrhardt wrote: > Benjamin Herrenschmidt wrote: > >> Yes you're right. Early at the pci initialization are errors of the > >> allocation for pi ressources. > >> And that are exactly the ressources failing later, so that pci > >> initialization seem to be the reason for my problem. > >> Was there any simple solution (e.g. just somehow increase memory reserved > >> for pci) when you came across that issue Johan ? > > > > Hrm... I was expecting to see a lot more output here, make sure you have > > "debug" on your command line (or enable early debug output, same > > effect). > > There is nothing more even with debug in kernel command line. Weird. pcibios_fixup_resources() should have printed things that I didn't see in your log, which is why I asked... I -think- your card is just asking too much, more than what we know how to assign, but that doesn't explain why it used to work. I'll have to dig a bit more. You can assign more by changing the "ranges" property in the .dts, I would expect the 44x PCI code I wrote to automatically adjust. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
Speaking of making it obvious, is it time to put a #warning in some prominent arch/ppc header? The last time arch/ppc built for me (a few days ago), it got 535 warnings. I don't think anyone would notice one more. Also, whoever doesn't yet know arch/ppc will be going away has been living under a rock for the last two years. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] [POWERPC] 83xx: new board support: MPC8360E-RDK
On Fri, Apr 18, 2008 at 1:10 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> This is patch adds board file, device tree, and defconfig for the new
> board, made by Freescale Semiconductor Inc. and Logic Product Development.
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 106 +++
I don't see anything exotic in here. This can be merged with one of
the other non-exotic mpc83xx board files. The dts parsing takes care
of the differences.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
> 5 files changed, 1601 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc836x_rdk.dts
> create mode 100644 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/mpc836x_rdk.c
>
> diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
> b/arch/powerpc/boot/dts/mpc836x_rdk.dts
> new file mode 100644
> index 000..39a7dcb
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
> @@ -0,0 +1,394 @@
> +/*
> + * MPC8360E RDK Device Tree Source
> + *
> + * Copyright 2006 Freescale Semiconductor Inc.
> + * Copyright 2007-2008 MontaVista Software, Inc.
> + *
> + * Author: Anton Vorontsov <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8360rdk";
> +
> + aliases {
> + serial0 = &serial0;
> + serial1 = &serial1;
> + serial2 = &serial2;
> + serial3 = &serial3;
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + pci0 = &pci0;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + d-cache-size = <32768>;
> + i-cache-size = <32768>;
> + /* filled by u-boot */
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + /* filled by u-boot */
> + reg = <0 0>;
> + };
> +
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "fsl,mpc8360-immr", "fsl,immr", "fsl,soc",
> +"simple-bus";
> + ranges = <0 0xe000 0x20>;
> + reg = <0xe000 0x200>;
> + /* filled by u-boot */
> + bus-frequency = <0>;
> +
> + [EMAIL PROTECTED] {
> + compatible = "mpc83xx_wdt";
> + reg = <0x200 0x100>;
> + };
> +
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <1>;
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <16 8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
> + serial0: [EMAIL PROTECTED] {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4500 0x100>;
> + interrupts = <9 8>;
> + interrupt-parent = <&ipic>;
> + /* filled by u-boot */
> + clock-frequency = <0>;
> + };
> +
> + serial1: [EMAIL PROTECTED] {
> + device_type = "serial";
> + compatible = "ns16550";
> +
[PATCH] sysdev,mv64x60: early console fix
The MPSC driver and prpmc2800.dts have been modified to use property 'cell-index' as the serial port number but the early serial console driver for the mv64x60 has not been modified to use this new property. Signed-off-by: Remi Machet ([EMAIL PROTECTED]) --- arch/powerpc/sysdev/mv64x60_udbg.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/mv64x60_udbg.c b/arch/powerpc/sysdev/mv64x60_udbg.c index ccdb3b0..2792dc8 100644 --- a/arch/powerpc/sysdev/mv64x60_udbg.c +++ b/arch/powerpc/sysdev/mv64x60_udbg.c @@ -94,7 +94,7 @@ static void mv64x60_udbg_init(void) if (!np) return; - block_index = of_get_property(np, "block-index", NULL); + block_index = of_get_property(np, "cell-index", NULL); if (!block_index) goto error; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
On Apr 21, 2008, at 3:19 PM, Gabriel Paubert wrote: On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote: 603 CPUs have the same issue that some 750 CPUs have in that they can crash in funny ways if a store from an FPU register instruction is executed on a register that has never been initialized since power on. This patch fixes it by making sure all FP registers have been properly initialized at kernel boot. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- Paul, I've put this into my powerpc-next tree since its a pretty trivial patch. - k arch/powerpc/kernel/cpu_setup_6xx.S |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/ kernel/cpu_setup_6xx.S index f1ee0b3..4a1c3cd 100644 --- a/arch/powerpc/kernel/cpu_setup_6xx.S +++ b/arch/powerpc/kernel/cpu_setup_6xx.S @@ -17,7 +17,14 @@ #include _GLOBAL(__setup_cpu_603) - b setup_common_caches + mflrr4 +BEGIN_FTR_SECTION + bl __init_fpu_registers +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) + bl __init_fpu_registers I don't understand that code. What does the second bl __init_fpu_regiters do? that was a copy/paste error. (see v2 of the patch). As I understand it, the first one is conditional on the presence of an FPU (reasonable). But the secone one makes no sense. Finally wouldn't it be simpler to initialize the FPU on all CPU that have it? that would require a change to the entry point of all these functions. Its not worth the savings. + bl setup_common_caches + mtlrr4 + blr You can use tail call elimination and save one instruction there :-) I think we can find better places to save code size. :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote: > 603 CPUs have the same issue that some 750 CPUs have in that they can crash > in funny ways if a store from an FPU register instruction is executed on a > register that has never been initialized since power on. This patch fixes > it by making sure all FP registers have been properly initialized at kernel > boot. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > > Paul, I've put this into my powerpc-next tree since its a pretty trivial > patch. > > - k > > arch/powerpc/kernel/cpu_setup_6xx.S |9 - > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S > b/arch/powerpc/kernel/cpu_setup_6xx.S > index f1ee0b3..4a1c3cd 100644 > --- a/arch/powerpc/kernel/cpu_setup_6xx.S > +++ b/arch/powerpc/kernel/cpu_setup_6xx.S > @@ -17,7 +17,14 @@ > #include > > _GLOBAL(__setup_cpu_603) > - b setup_common_caches > + mflrr4 > +BEGIN_FTR_SECTION > + bl __init_fpu_registers > +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) > + bl __init_fpu_registers I don't understand that code. What does the second bl __init_fpu_regiters do? As I understand it, the first one is conditional on the presence of an FPU (reasonable). But the secone one makes no sense. Finally wouldn't it be simpler to initialize the FPU on all CPU that have it? > + bl setup_common_caches > + mtlrr4 > + blr You can use tail call elimination and save one instruction there :-) Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] ppc32: Fix errata for 603 CPUs
603 CPUs have the same issue that some 750 CPUs have in that they can crash in funny ways if a store from an FPU register instruction is executed on a register that has never been initialized since power on. This patch fixes it by making sure all FP registers have been properly initialized at kernel boot. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- Becky pointed out that I had a copy/paste issue (duplicated the call to __init_fpu_registers). Going to find the brown paper bag now. Paul, (the update) is also in my powerpc-tree since its a pretty trivial patch. - k arch/powerpc/kernel/cpu_setup_6xx.S |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S index f1ee0b3..72d1d73 100644 --- a/arch/powerpc/kernel/cpu_setup_6xx.S +++ b/arch/powerpc/kernel/cpu_setup_6xx.S @@ -17,7 +17,13 @@ #include _GLOBAL(__setup_cpu_603) - b setup_common_caches + mflrr4 +BEGIN_FTR_SECTION + bl __init_fpu_registers +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) + bl setup_common_caches + mtlrr4 + blr _GLOBAL(__setup_cpu_604) mflrr4 bl setup_common_caches -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Monday 21 April 2008, Anton Vorontsov wrote: > From: J. Random Hacker > Subject: [POWERPC] cleanup board initialization code > > This patch removes vast amount of machine_arch_initcall()s that were > used to solely initialize some hardware, like this: > > qe_add_gpio_chips(); > fsl_gtm_init(); > fsl_spi_init(); > ... > > So, instead of calling this stuff from the board files, we implement > own arch_initcalls for these functions. The way other platforms do this is to hav SOC-specific init code, and have board-specific initcalls call the relevant SOC-specific setup. Among other things that facilitates kernels that handle multiple SOCs (if they're closely-enough related). That may not be used by many distros (handhelds.org being at least a partial exception), but it certainly helps cut the number of configurations that need build-testing. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] ppc32: Fix errata for 603 CPUs
603 CPUs have the same issue that some 750 CPUs have in that they can crash in funny ways if a store from an FPU register instruction is executed on a register that has never been initialized since power on. This patch fixes it by making sure all FP registers have been properly initialized at kernel boot. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- Paul, I've put this into my powerpc-next tree since its a pretty trivial patch. - k arch/powerpc/kernel/cpu_setup_6xx.S |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S index f1ee0b3..4a1c3cd 100644 --- a/arch/powerpc/kernel/cpu_setup_6xx.S +++ b/arch/powerpc/kernel/cpu_setup_6xx.S @@ -17,7 +17,14 @@ #include _GLOBAL(__setup_cpu_603) - b setup_common_caches + mflrr4 +BEGIN_FTR_SECTION + bl __init_fpu_registers +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE) + bl __init_fpu_registers + bl setup_common_caches + mtlrr4 + blr _GLOBAL(__setup_cpu_604) mflrr4 bl setup_common_caches -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2 v3] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
On Mon, Apr 21, 2008 at 11:46:12AM -0700, Remi Machet wrote: > If one of the devices of the mv64x60 init fails, the remaining > devices are not initialized => This patch changes the code to > display an error and continue the initialization. > > Signed-off-by: Remi Machet ([EMAIL PROTECTED]) Acked by: Dale Farnsworth <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2 v3] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized => This patch changes the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
Integrated the few format changes requested by Dale in the
previous version of this patch.
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -431,9 +431,13 @@ static int __init mv64x60_device_setup(v
int err;
id = 0;
- for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
- if ((err = mv64x60_mpsc_device_setup(np, id++)))
- goto error;
+ for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") {
+ err = mv64x60_mpsc_device_setup(np, id++);
+ if (err)
+ printk(KERN_ERR "Failed to initialize MV64x60 "
+ "serial device %s: error %d.\n",
+ np->full_name, err);
+ }
id = 0;
id2 = 0;
@@ -441,38 +445,44 @@ static int __init mv64x60_device_setup(v
pdev = mv64x60_eth_register_shared_pdev(np, id++);
if (IS_ERR(pdev)) {
err = PTR_ERR(pdev);
- goto error;
+ printk(KERN_ERR "Failed to initialize MV64x60 "
+ "network block %s: error %d.\n",
+ np->full_name, err);
+ continue;
}
for_each_child_of_node(np, np2) {
if (!of_device_is_compatible(np2,
"marvell,mv64360-eth"))
continue;
err = mv64x60_eth_device_setup(np2, id2++, pdev);
- if (err) {
- of_node_put(np2);
- goto error;
- }
+ if (err)
+ printk(KERN_ERR "Failed to initialize "
+ "MV64x60 network device %s: "
+ "error %d.\n",
+ np2->full_name, err);
}
}
id = 0;
- for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c")
- if ((err = mv64x60_i2c_device_setup(np, id++)))
- goto error;
+ for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") {
+ err = mv64x60_i2c_device_setup(np, id++);
+ if (err)
+ printk(KERN_ERR "Failed to initialize MV64x60 I2C "
+ "bus %s: error %d.\n",
+ np->full_name, err);
+ }
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt");
if (np) {
if ((err = mv64x60_wdt_device_setup(np, id)))
- goto error;
+ printk(KERN_ERR "Failed to initialize MV64x60 "
+ "Watchdog %s: error %d.\n",
+ np->full_name, err);
of_node_put(np);
}
return 0;
-
-error:
- of_node_put(np);
- return err;
}
arch_initcall(mv64x60_device_setup);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
> > +r) Freescale General-purpose Timers Module
> > +
> > +Required properties:
> > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > + GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
>
> I don't think this is specific enough. It is a very real possibility
> for Freescale to produce another part with a "general purpose timers
> module" that isn't register level compatible (and fsl,i2c is an
> example of what not to do).
If that happens, we'll make up "fsl,gtm2". :-)
> The compatible string should include the
> exact chip version. Newer parts can also claim compatibility with
> older ones.
>
> Defining a 'generic' compatible value is also known as "making stuff up". :-)
Nothing wrong with making stuff up as long as we do it sanely.
How about something like fsl,gtm-1.0?
> > +/**
> > + * gtm_ack_timer16 - acknowledge timer event (free-run timers only)
> > + * @tmr: pointer to the gtm_timer structure obtained from
> > gtm_get_timer
> > + * @events:events mask to ack
> > + *
> > + * Thus function used to acknowledge timer interrupt event, use it inside
> > the
> > + * interrupt handler.
> > + */
> > +static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16 events)
> > +{
> > + out_be16(tmr->gtevr, events);
> > +}
>
> Drop 'inline' and expect gcc to do the right thing.
Not in a header...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
On Mon, Apr 21, 2008 at 10:25:09AM -0500, Kumar Gala wrote: > > On Apr 19, 2008, at 1:14 PM, Grant Likely wrote: > >On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala > ><[EMAIL PROTECTED]> wrote: > >>We have a board port in arch/powerpc so we dont need this one > >>anymore. > >> > >>Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > > > >Personally, I'd rather not do the piecemeal removal of board ports > >from arch/ppc. We've only got one release left anyway. Removing them > >just generates more churn and has the risk of causing other side > >effects. > > I can understand it, but I think removing them makes it obvious to > anyone that's lurking. Call in maintainer prerogative :) Speaking of making it obvious, is it time to put a #warning in some prominent arch/ppc header? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7] [POWERPC] 85xx: Add support for relocatable kernel (and booting at non-zero)
Added support to allow an 85xx kernel to be run from a non-zero physical address (useful for cooperative asymmetric multiprocessing situations and kdump). The support can be configured at compile time by setting CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as desired. Alternatively, the kernel build can set CONFIG_RELOCATABLE. Setting this config option causes the kernel to determine at runtime the physical addresses of CONFIG_PAGE_OFFSET and CONFIG_KERNEL_START. If CONFIG_RELOCATABLE is set, then CONFIG_PHYSICAL_START has no meaning. However, CONFIG_PHYSICAL_START will always be used to set the LOAD program header physical address field in the resulting ELF image. Currently we are limited to running at a physical address that is modulo 256M. This is due to how we map TLBs to cover lowmem. This should be fixed to allow 64M or maybe even 16M alignment in the future. It is considered an error to try and run a kernel at a non-aligned physical address. All the magic for this support is accomplished by proper initialization of the kernel memory subsystem and use of ARCH_PFN_OFFSET. The use of ARCH_PFN_OFFSET only affects normal memory and not IO mappings. ioremap uses map_page and isn't affected by ARCH_PFN_OFFSET. /dev/mem continues to allow access to any physical address in the system regardless of how CONFIG_PHYSICAL_START is set. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- Improved the grammar of the commit message. - k arch/powerpc/Kconfig | 69 - arch/powerpc/kernel/head_fsl_booke.S | 11 + arch/powerpc/kernel/prom.c |4 ++ arch/powerpc/kernel/setup_64.c |2 +- arch/powerpc/mm/fsl_booke_mmu.c |2 +- arch/powerpc/mm/init_32.c|5 ++- arch/powerpc/mm/init_64.c|3 +- arch/powerpc/mm/mem.c|5 +- include/asm-powerpc/kdump.h |5 -- include/asm-powerpc/page.h | 45 ++ include/asm-powerpc/page_32.h|6 +++ 11 files changed, 135 insertions(+), 22 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 4bb2e93..fdc755a 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -656,21 +656,76 @@ config LOWMEM_SIZE hex "Maximum low memory size (in bytes)" if LOWMEM_SIZE_BOOL default "0x3000" +config RELOCATABLE + bool "Build a relocatable kernel (EXPERIMENTAL)" + depends on EXPERIMENTAL && ADVANCED_OPTIONS && FLATMEM && FSL_BOOKE + help + This builds a kernel image that is capable of running at the + location the kernel is loaded at (some alignment restrictions may + exist). + + One use is for the kexec on panic case where the recovery kernel + must live at a different physical address than the primary + kernel. + + Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address + it has been loaded at and the compile time physical addresses + CONFIG_PHYSICAL_START is ignored. However CONFIG_PHYSICAL_START + setting can still be useful to bootwrappers that need to know the + load location of the kernel (eg. u-boot/mkimage). + +config PAGE_OFFSET_BOOL + bool "Set custom page offset address" + depends on ADVANCED_OPTIONS + help + This option allows you to set the kernel virtual address at which + the kernel will map low memory. This can be useful in optimizing + the virtual memory layout of the system. + + Say N here unless you know what you are doing. + +config PAGE_OFFSET + hex "Virtual address of memory base" if PAGE_OFFSET_BOOL + default "0xc000" + config KERNEL_START_BOOL bool "Set custom kernel base address" depends on ADVANCED_OPTIONS help This option allows you to set the kernel virtual address at which - the kernel will map low memory (the kernel image will be linked at - this address). This can be useful in optimizing the virtual memory - layout of the system. + the kernel will be loaded. Normally this should match PAGE_OFFSET + however there are times (like kdump) that one might not want them + to be the same. Say N here unless you know what you are doing. config KERNEL_START hex "Virtual address of kernel base" if KERNEL_START_BOOL + default PAGE_OFFSET if PAGE_OFFSET_BOOL + default "0xc200" if CRASH_DUMP default "0xc000" +config PHYSICAL_START_BOOL + bool "Set physical address where the kernel is loaded" + depends on ADVANCED_OPTIONS && FLATMEM && FSL_BOOKE + help + This gives the physical address where the kernel is loaded. + + Say N here unless you know what you are doing. + +config PHYSICAL_START + hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL +
Re: [PATCH 2/2 v2] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
On Mon, Apr 21, 2008 at 10:37:14AM -0700, Remi Machet wrote:
> If one of the devices of the mv64x60 init fails, the remaining
> devices are not initialized => This patch change the code to
> display an error and continue the initialization.
>
> Signed-off-by: Remi Machet ([EMAIL PROTECTED])
> ---
> This is the second part of the re-submission of my patch of 4/17/2008
> titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet,
> serial and I2C"
>
> --- a/arch/powerpc/sysdev/mv64x60_dev.c
> +++ b/arch/powerpc/sysdev/mv64x60_dev.c
> @@ -431,9 +431,14 @@ static int __init mv64x60_device_setup(void)
> int err;
>
> id = 0;
> - for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
> - if ((err = mv64x60_mpsc_device_setup(np, id++)))
> - goto error;
> + for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") {
> + err = mv64x60_mpsc_device_setup(np, id++);
> + if (err) {
> + printk(KERN_ERR "Failed to initialize MV64x60 " \
No need for the backslash continuation above. Also below.
> + "serial device %s: error %d.\n",
> + np->full_name, err);
> + };
You don't need the braces around the single printk statement.
> + };
No need for the semi-colon following closing brace, also below.
>
> id = 0;
> id2 = 0;
> @@ -441,38 +446,46 @@ static int __init mv64x60_device_setup(void)
> pdev = mv64x60_eth_register_shared_pdev(np, id++);
> if (IS_ERR(pdev)) {
> err = PTR_ERR(pdev);
> - goto error;
> - }
> + printk(KERN_ERR "Failed to initialize MV64x60 " \
> + "network block %s: error %d.\n",
> + np->full_name, err);
> + continue;
> + };
> for_each_child_of_node(np, np2) {
> if (!of_device_is_compatible(np2,
> "marvell,mv64360-eth"))
> continue;
> err = mv64x60_eth_device_setup(np2, id2++, pdev);
> if (err) {
> - of_node_put(np2);
> - goto error;
> + printk(KERN_ERR "Failed to initialize " \
> + "MV64x60 network device %s: " \
> + "error %d.\n",
> + np2->full_name, err);
> }
> }
> }
>
> id = 0;
> - for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c")
> - if ((err = mv64x60_i2c_device_setup(np, id++)))
> - goto error;
> + for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") {
> + err = mv64x60_i2c_device_setup(np, id++);
> + if (err) {
> + printk(KERN_ERR "Failed to initialize MV64x60 I2C " \
> + "bus %s: error %d.\n",
> + np->full_name, err);
> + };
> + };
>
> /* support up to one watchdog timer */
> np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt");
> if (np) {
> if ((err = mv64x60_wdt_device_setup(np, id)))
> - goto error;
> + printk(KERN_ERR "Failed to initialize MV64x60 " \
> + "Watchdog %s: error %d.\n",
> + np->full_name, err);
> of_node_put(np);
> }
>
> return 0;
> -
> -error:
> - of_node_put(np);
> - return err;
> }
> arch_initcall(mv64x60_device_setup);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] sysdev,mv64x60: I2C defaults
On Mon, Apr 21, 2008 at 10:36:48AM -0700, Remi Machet wrote: > I2C parameters freq_m and freq_n are assigned default in the code > but if those properties are not found in the open firmware description > the init returns an error => the code now uses the default > values if the properties are not found. > > Signed-off-by: Remi Machet ([EMAIL PROTECTED]) Acked-by: Dale Farnsworth <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote: > Scott Wood was concerned in > http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib might > be an unnecessary burden for memory-constraint platforms. Should we keep two > mdio bitbang drivers, one with direct access to the ports and one using gpio > lib ? The later solves the concurrent access issues present in the current > fs_enet mdio bitbang driber. The memory-constrained platform I had in mind was 8xx, which doesn't use bitbanged MDIO. It might nice to keep the gpiolib bit separate to avoid situations such as ep8248e where mdiobb would be the only thing requiring a gpiolib binding, though -- but it shouldn't be two separate bitbang drivers, just the existing bitbang driver plus some glue code that binds it to gpiolib. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git master and powerpc-next branches
On Apr 19, 2008, at 7:18 AM, Paul Mackerras wrote: Kumar Gala writes: [POWERPC] 85xx: Add support for relocatble kernel (and booting at non- zero) Should be OK to go though probably not in the first batch. I want to look through it carefully again since it's touching code that is common to a lot of platforms. The patch description looks reasonable as to what it explains but the english could use a touch-up here or there (e.g. "a physical address that is module 256M" doesn't actually mean anything; "a physical address that is 0 modulo 256M" would be correct). Ok. I'll have my grammar police review it and repost. [POWERPC] Port fixmap from x86 and use for kmap_atomic Once again I want to go through it carefully and understand how it all works, and in particular understand things like the way it ensures that the base address for the kmap region is aligned to a 4M boundary so all the kmap ptes are in a single page (assuming it does :). I'm not clear on why this is needed. I can see value in having the PGD entry in place but the pte PAs would be changing all the time so I don't see what benefit there is in keeping them in one page. For normal kmap ptes we cover things in one PGD via: #define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE*(LAST_PKMAP + 1)) & PMD_MASK) The kmap_atomic ptes do NOT have a similar guarantee as they are controlled via fixmap. However we do "pre-allocate" the PGD via calling map_page() on all fixmap addresses. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic
On Apr 19, 2008, at 6:07 AM, Gerhard Pircher wrote: Original-Nachricht Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT) Von: Kumar Gala <[EMAIL PROTECTED]> An: Paul Mackerras <[EMAIL PROTECTED]> CC: linuxppc-dev@ozlabs.org Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic The fixmap code from x86 allows us to have compile time virtual addresses that we change the physical addresses of at run time. ... +/* + * Here we define all the compile-time 'special' virtual + * addresses. The point is to have a constant address at + * compile time, but to set the physical address only + * in the boot process. We allocate these special addresses + * from the end of virtual memory (0xf000) backwards. + * Also this lets us do fail-safe vmalloc(), we + * can guarantee that these special addresses and + * vmalloc()-ed addresses never overlap. I don't understand how highmem works, but I'm just interested to know, if this implementation could conflict somehow with the non coherent DMA implementation in dma-noncoherent.c (which uses address space from 0xff10 to 0xff30 for DMA memory). if the size is fixed we can easily change it so the Kconfig options aren't needed anymore. On the other side could dma-noncoherent.c benefit from fixmaps so that it isn't necessary to configure a start address for DMA allocations? Its possible however the fixmap is all about keeping the VA the same while changing the PA. I think some work that is being done for the SW IOMMU might be more useful to your needs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2 v2] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized => This patch change the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
This is the second part of the re-submission of my patch of 4/17/2008
titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet,
serial and I2C"
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -431,9 +431,14 @@ static int __init mv64x60_device_setup(void)
int err;
id = 0;
- for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
- if ((err = mv64x60_mpsc_device_setup(np, id++)))
- goto error;
+ for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") {
+ err = mv64x60_mpsc_device_setup(np, id++);
+ if (err) {
+ printk(KERN_ERR "Failed to initialize MV64x60 " \
+ "serial device %s: error %d.\n",
+ np->full_name, err);
+ };
+ };
id = 0;
id2 = 0;
@@ -441,38 +446,46 @@ static int __init mv64x60_device_setup(void)
pdev = mv64x60_eth_register_shared_pdev(np, id++);
if (IS_ERR(pdev)) {
err = PTR_ERR(pdev);
- goto error;
- }
+ printk(KERN_ERR "Failed to initialize MV64x60 " \
+ "network block %s: error %d.\n",
+ np->full_name, err);
+ continue;
+ };
for_each_child_of_node(np, np2) {
if (!of_device_is_compatible(np2,
"marvell,mv64360-eth"))
continue;
err = mv64x60_eth_device_setup(np2, id2++, pdev);
if (err) {
- of_node_put(np2);
- goto error;
+ printk(KERN_ERR "Failed to initialize " \
+ "MV64x60 network device %s: " \
+ "error %d.\n",
+ np2->full_name, err);
}
}
}
id = 0;
- for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c")
- if ((err = mv64x60_i2c_device_setup(np, id++)))
- goto error;
+ for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") {
+ err = mv64x60_i2c_device_setup(np, id++);
+ if (err) {
+ printk(KERN_ERR "Failed to initialize MV64x60 I2C " \
+ "bus %s: error %d.\n",
+ np->full_name, err);
+ };
+ };
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt");
if (np) {
if ((err = mv64x60_wdt_device_setup(np, id)))
- goto error;
+ printk(KERN_ERR "Failed to initialize MV64x60 " \
+ "Watchdog %s: error %d.\n",
+ np->full_name, err);
of_node_put(np);
}
return 0;
-
-error:
- of_node_put(np);
- return err;
}
arch_initcall(mv64x60_device_setup);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2 v2] sysdev,mv64x60: I2C defaults
I2C parameters freq_m and freq_n are assigned default in the code but if those properties are not found in the open firmware description the init returns an error => the code now uses the default values if the properties are not found. Signed-off-by: Remi Machet ([EMAIL PROTECTED]) --- This is the first part of the re-submission of my patch of 4/17/2008 titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C" --- a/arch/powerpc/sysdev/mv64x60_dev.c +++ b/arch/powerpc/sysdev/mv64x60_dev.c @@ -338,15 +338,13 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id) pdata.freq_m = 8; /* default */ prop = of_get_property(np, "freq_m", NULL); - if (!prop) - return -ENODEV; - pdata.freq_m = *prop; + if (prop) + pdata.freq_m = *prop; pdata.freq_m = 3; /* default */ prop = of_get_property(np, "freq_n", NULL); - if (!prop) - return -ENODEV; - pdata.freq_n = *prop; + if (prop) + pdata.freq_n = *prop; pdata.timeout = 1000; /* default: 1 second */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: Possible section mismatch problem in ibm_newemac?
On Mon, 21 Apr 2008 12:02:25 -0400 "Steven A. Falco" <[EMAIL PROTECTED]> wrote: > I am using a recent DENX git tree. I want to enable debugging in > prom_parse.c. > When I do that, I see link warnings like: I already sent a patch a month and a half ago to clean all these warnings up. It never got pushed upstream. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
Juergen Beisert wrote:
Please don't forget what Sylvian said about this driver: "I also completely
skipped the 5200 (not B) support ..." and your own "I think it should be left
noted here that the CCR size changed from 16 bits to 32 bits from 5200 to
5200B in order to reduce confusion.". Its not solved yet. So any user of an
old MPC5200 will be surprised...
+static struct of_device_id mpc52xx_ac97_of_match[] = {
+ {
+ .type = "sound",
+ .compatible = "mpc5200b-psc-ac97",/* B only for now
*/
+ },
+};
It shouldn't even load, the matchlist is 5200b only..? No alarms and no
surprises.. :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
On Mon, Apr 21, 2008 at 10:55 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Grant Likely wrote: > > > On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> > wrote: > > > > > Bartlomiej Sieka wrote: > > > > > > > > > > Board-specific defconfigs based on current mpc5200_defconfig, archival > > > > lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the > > > > linux-2.6-denx tree. Kernels build using these defconfigs were > verified > > > > to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200 > > > > and Lite5200B boards. CM5200 target was not tested due to hardware > > > > unavailability. > > > > > > > > > > > Hello Grant, > > > > > > There hasn't been any negitve comments on the above patch -- will you > > > push it upstream via your tree? > > > > > > > Yes, of course. > > > > Thanks -- is it safe to assume that the patch will make it into 2.6.26 > then? Yes; defconfigs are easy to get merged. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
Grant Likely wrote: On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: Bartlomiej Sieka wrote: Board-specific defconfigs based on current mpc5200_defconfig, archival lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the linux-2.6-denx tree. Kernels build using these defconfigs were verified to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200 and Lite5200B boards. CM5200 target was not tested due to hardware unavailability. Hello Grant, There hasn't been any negitve comments on the above patch -- will you push it upstream via your tree? Yes, of course. Thanks -- is it safe to assume that the patch will make it into 2.6.26 then? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Xilinx network trouble (mostly solved)
The easiest way is to edit the .mhs by hand. Steve > -Original Message- > From: [EMAIL PROTECTED] [mailto:linuxppc-dev- > [EMAIL PROTECTED] On Behalf Of Guillaume Dargaud > Sent: Monday, April 21, 2008 9:16 AM > To: Rick Moleres; linuxppc-dev@ozlabs.org > Subject: Re: Xilinx network trouble (mostly solved) > > Hi Rick, > > > You might try v1.00a of the xps_ll_temac core. There are a couple of > > issues with v1.00b (posted previously on this list) that may (or may > > not) be causing the problem you see. > > Thanks for the answer... but I can't figure out how to revert to 1.00a. Is > the option accessible from xps ? > > As for the EmacLite, it works rather imperfectly: > ping -s 2952 works > ping -s 2953 doesn't...: > [ 2340.664293] Badness at net/core/skbuff.c:317 > [ 2340.668479] NIP: c015bd24 LR: c015b3f4 CTR: > [ 2340.673410] REGS: c7d0fd20 TRAP: 0700 Not tainted (2.6.24-rc8-xlnx) > [ 2340.679876] MSR: 00029030 CR: 2848 XER: 2000 > [ 2340.686189] TASK = c7c35810[243] 'ping' THREAD: c7d0e000 > [ 2340.691279] GPR00: 0001 c7d0fdd0 c7c35810 c7d318e0 8009 0004 > c027bd38 0200 > [ 2340.699571] GPR08: c7d0fdb8 c7d0e000 c027bd1c c0159910 c7d0fdb8 100b46f4 > > [ 2340.707864] GPR16: 1009 100bd6e0 100b 100b 0c11 7fbcf9a0 > 10004634 > [ 2340.716158] GPR24: 1007d370 7fbced90 10003fbc 100adf18 > c7c9e000 c7d318e0 > [ 2340.724625] NIP [c015bd24] skb_release_all+0x6c/0x94 > [ 2340.729551] LR [c015b3f4] __kfree_skb+0x18/0xc0 > [ 2340.734042] Call Trace: > [ 2340.736465] [c7d0fdd0] [c0161b6c] netif_rx+0x124/0x158 (unreliable) > [ 2340.742684] [c7d0fde0] [c015b3f4] __kfree_skb+0x18/0xc0 > [ 2340.747866] [c7d0fdf0] [c01466a0] SendHandler+0x44/0x94 > [ 2340.753050] [c7d0fe10] [c0147284] XEmacLite_InterruptHandler+0x12c/0x140 > [ 2340.759702] [c7d0fe20] [c0146078] xemaclite_interrupt+0x20/0x34 > [ 2340.765577] [c7d0fe30] [c003c98c] handle_IRQ_event+0x4c/0xa0 > [ 2340.771193] [c7d0fe50] [c003ca94] __do_IRQ+0xb4/0x130 > [ 2340.776203] [c7d0fe70] [c0006990] do_IRQ+0x6c/0xa4 > [ 2340.780954] [c7d0fe80] [c000329c] ret_from_except+0x0/0x18 > [ 2340.786397] [c7d0ff40] [c0002c50] ret_from_syscall+0x0/0x3c > [ 2340.791923] Instruction dump: > [ 2340.794865] 3000 7c005a2c 7c00592d 40a2fff0 817f006c 54290024 > 2f8b 419e0024 > [ 2340.802549] 8009000c 5400011e 7cd0 54000ffe <0f00> 7fe3fb78 > 7d6903a6 4e800421 > (192.168.1.185): 2953 data bytes > -- > Guillaume Dargaud > http://www.gdargaud.net/ > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote: > On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov > <[EMAIL PROTECTED]> wrote: > > > > Should this really be a arch_initcall()? Would it be better for > > > > platforms needing it to call it explicitly from one of the platform's > > > > machine_arch_initcall()? Otherwise it gets called for all platforms > > > > in a multiplatform kernel. > > > > > > Ok, I'll place it into qe_reset(). > > > > Ugh, no, I can't. qe_reset() is called too early. And I don't like > > having every QE board file to call this through machine_arch_initcall... > > Hmm, what to do.. well, is this thaat bad to call this for every > > platform?.. > > Its not great. It has a boot time impact for every platform compiled > into the kernel. The problem gets worse every time another block of > code uses this method. Personally I prefer platform code calling it > explicitly. > > Making it an of_platform device would also eliminate that problem, but > you'd need a method to synchronize the driver with its users. > > I'm not going to raise a big stink about it, but the issue should not > be ignored. Heh.. how QE GPIO is different from FSL GTM then? Should I call fsl_gtm_init() from the board file too? For the every board? I do believe that years later someone will show up with something like this: From: J. Random Hacker Subject: [POWERPC] cleanup board initialization code This patch removes vast amount of machine_arch_initcall()s that were used to solely initialize some hardware, like this: qe_add_gpio_chips(); fsl_gtm_init(); fsl_spi_init(); ... So, instead of calling this stuff from the board files, we implement own arch_initcalls for these functions. This causes negligible run-time overhead for the boards that aren't using that hardware, but this overhead isn't measurable anyway. Also, this patch shrinks .text size a bit, and produces nice looking diffstat. 12 file changed, 6 insertions(+), 140 deletions(-) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
Also, why is encoded in compatible? Do the different banks have different register interfaces? Yes, they could. For example, interrupt pins are bank-specific. In what way? If different banks just have different IRQ #s, there are easier ways to express this. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
+static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16
events)
+{
+ out_be16(tmr->gtevr, events);
+}
Drop 'inline' and expect gcc to do the right thing.
Not sure about newer gccs, but older complained about "defined but not
used" functions w/o inline keyword. I'm almost sure that this is still
true.
It is. So why is it unused? Because you put the code in the header
file. Can't you move it to the .c file instead?
I can surely use __maybe_unused, but "static inline" is pretty
settled tradition, plus this function is small enough anyway.
All code in header files should be inline. Code in implementation
files should only be inline if you have a very good reason for
doing so. Same goes for __maybe_unused.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci issue - wrong detection of pci ressources
Hello, I wrote: Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 265 MiB of the PCI memory space (128+128), so no place is left for other memory BARs. What's interesting, the Sequoia/Rainier board user manual says that PCI memory is 0x8000 thru 0xbfff (i.e. 1 GiB), while the Linux code seem to always have assumed only 0x[1]8 thru 0x[1]8fff... WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RFC: Possible section mismatch problem in ibm_newemac?
I am using a recent DENX git tree. I want to enable debugging in prom_parse.c.
When I do that, I see link warnings like:
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.data+0x6e0): Section mismatch
in reference from the variable emac_of_bus_notifier to the function
.devinit.text:emac_of_bus_notify()
The variable emac_of_bus_notifier references
the function __devinit emac_of_bus_notify()
WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x14d4): Section
mismatch in reference from the function emac_probe() to the function
.devexit.text:rgmii_detach()
The function __devinit emac_probe() references
a function __devexit rgmii_detach().
I've made the following changes, which clean up the link warnings, but I'm not
sure this is the right way to fix the problem. If it is correct, I'd like to
submit the patch.
Signed-off-by: Steve Falco <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 5153901..d54393e 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2241,7 +2241,7 @@ static int __devinit emac_of_bus_notify(struct
notifier_block *nb,
return 0;
}
-static struct notifier_block emac_of_bus_notifier = {
+static struct notifier_block __devinitdata emac_of_bus_notifier = {
.notifier_call = emac_of_bus_notify
};
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index fb9c9eb..e9dbd6b 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -61,7 +61,7 @@ int __devinit mal_register_commac(struct mal_instance *mal,
return 0;
}
-void __devexit mal_unregister_commac(struct mal_instance *mal,
+void mal_unregister_commac(struct mal_instance *mal,
struct mal_commac *commac)
{
unsigned long flags;
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 5757788..e32da3d 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -179,7 +179,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
mutex_unlock(&dev->lock);
}
-void __devexit rgmii_detach(struct of_device *ofdev, int input)
+void rgmii_detach(struct of_device *ofdev, int input)
{
struct rgmii_instance *dev = dev_get_drvdata(&ofdev->dev);
struct rgmii_regs __iomem *p = dev->base;
diff --git a/drivers/net/ibm_newemac/zmii.c b/drivers/net/ibm_newemac/zmii.c
index 2ea472a..17b1541 100644
--- a/drivers/net/ibm_newemac/zmii.c
+++ b/drivers/net/ibm_newemac/zmii.c
@@ -189,7 +189,7 @@ void zmii_set_speed(struct of_device *ofdev, int input, int
speed)
mutex_unlock(&dev->lock);
}
-void __devexit zmii_detach(struct of_device *ofdev, int input)
+void zmii_detach(struct of_device *ofdev, int input)
{
struct zmii_instance *dev = dev_get_drvdata(&ofdev->dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx network trouble (mostly solved)
Hi Rick, You might try v1.00a of the xps_ll_temac core. There are a couple of issues with v1.00b (posted previously on this list) that may (or may not) be causing the problem you see. Thanks for the answer... but I can't figure out how to revert to 1.00a. Is the option accessible from xps ? As for the EmacLite, it works rather imperfectly: ping -s 2952 works ping -s 2953 doesn't...: [ 2340.664293] Badness at net/core/skbuff.c:317 [ 2340.668479] NIP: c015bd24 LR: c015b3f4 CTR: [ 2340.673410] REGS: c7d0fd20 TRAP: 0700 Not tainted (2.6.24-rc8-xlnx) [ 2340.679876] MSR: 00029030 CR: 2848 XER: 2000 [ 2340.686189] TASK = c7c35810[243] 'ping' THREAD: c7d0e000 [ 2340.691279] GPR00: 0001 c7d0fdd0 c7c35810 c7d318e0 8009 0004 c027bd38 0200 [ 2340.699571] GPR08: c7d0fdb8 c7d0e000 c027bd1c c0159910 c7d0fdb8 100b46f4 [ 2340.707864] GPR16: 1009 100bd6e0 100b 100b 0c11 7fbcf9a0 10004634 [ 2340.716158] GPR24: 1007d370 7fbced90 10003fbc 100adf18 c7c9e000 c7d318e0 [ 2340.724625] NIP [c015bd24] skb_release_all+0x6c/0x94 [ 2340.729551] LR [c015b3f4] __kfree_skb+0x18/0xc0 [ 2340.734042] Call Trace: [ 2340.736465] [c7d0fdd0] [c0161b6c] netif_rx+0x124/0x158 (unreliable) [ 2340.742684] [c7d0fde0] [c015b3f4] __kfree_skb+0x18/0xc0 [ 2340.747866] [c7d0fdf0] [c01466a0] SendHandler+0x44/0x94 [ 2340.753050] [c7d0fe10] [c0147284] XEmacLite_InterruptHandler+0x12c/0x140 [ 2340.759702] [c7d0fe20] [c0146078] xemaclite_interrupt+0x20/0x34 [ 2340.765577] [c7d0fe30] [c003c98c] handle_IRQ_event+0x4c/0xa0 [ 2340.771193] [c7d0fe50] [c003ca94] __do_IRQ+0xb4/0x130 [ 2340.776203] [c7d0fe70] [c0006990] do_IRQ+0x6c/0xa4 [ 2340.780954] [c7d0fe80] [c000329c] ret_from_except+0x0/0x18 [ 2340.786397] [c7d0ff40] [c0002c50] ret_from_syscall+0x0/0x3c [ 2340.791923] Instruction dump: [ 2340.794865] 3000 7c005a2c 7c00592d 40a2fff0 817f006c 54290024 2f8b 419e0024 [ 2340.802549] 8009000c 5400011e 7cd0 54000ffe <0f00> 7fe3fb78 7d6903a6 4e800421 (192.168.1.185): 2953 data bytes -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
On Apr 19, 2008, at 1:14 PM, Grant Likely wrote: On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala <[EMAIL PROTECTED]> wrote: We have a board port in arch/powerpc so we dont need this one anymore. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Personally, I'd rather not do the piecemeal removal of board ports from arch/ppc. We've only got one release left anyway. Removing them just generates more churn and has the risk of causing other side effects. I can understand it, but I think removing them makes it obvious to anyone that's lurking. Call in maintainer prerogative :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci issue - wrong detection of pci ressources
Christian Ehrhardt wrote:
+else {
+printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__,
(this->end + 1), this->sibling);
+}
new->start = this->end + 1;
this = this->sibling;
And here. Yet it's not clear why you call resource's 'end' 'start'...
It's the new->start that get's calculated one line after that new else
part.
I printed that one to to see a bit how the loop iterates the resource
elements.
Yeah, I figured that out right after sending mail. :-)
With DEBUG in arch/powerpc/kernel/pci-common.c, debug in commandline and a patch with
some printk's (I attached the patch because it is the usual "put printk's
everywhere" so the diff helps to understand where the prints come from). Corrected
prinf format specifiers according to the comments from Sergei Shtylyov.
PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges:
MEM 0x00018000..0x00018fff -> 0x8000
IO 0x0001e800..0x0001e80f -> 0x
4xx PCI DMA offset set to 0x
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources :00:00.0
Try to map irq for :00:00.0...
-> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for :00:0a.0...
-> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for :00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: -000f [0x100],
parent c0365060 (PCI IO)
__request_resource - request 0xcf8045b0 name '/plb/[EMAIL PROTECTED]' start 0x0
end 0xf
__request_resource - no conflict parent 0xc0365060 sibling 0x
PCI: PHB (bus 0) bridge rsrc 1: 00018000-00018fff [0x200],
parent c0365038 (PCI mem)
__request_resource - request 0xcf8045d8 name '/plb/[EMAIL PROTECTED]' start
0x18000 end 0x18fff
__request_resource - no conflict parent 0xc0365038 sibling 0x
PCI: Assigning unassigned resouces...
pci_assign_unassigned_resources -#1- bus 0xcf82d400
pci_assign_unassigned_resources -#2- bus 0xcf82d400
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x800 startcalc
0x, align 0x800
find_resource - size 0x800, min 0x18000, max 0x
find_resource - found start 0x18000 end 0x187ff
__request_resource - request 0xcf810578 name ':00:0a.0' start 0x18000
end 0x187ff
__request_resource - no conflict parent 0xcf8045d8 sibling 0x
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x800 startcalc
0x, align 0x800
find_resource - size 0x800, min 0x18000, max 0x
find_resource - continue with start 0x18800 on 0x
find_resource - found start 0x18800 end 0x18fff
__request_resource - request 0xcf810178 name ':00:0a.1' start 0x18800
end 0x18fff
__request_resource - no conflict parent 0xcf8045d8 sibling 0x
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 265
MiB of the PCI memory space (128+128), so no place is left for other memory BARs.
pci_bus_alloc_resource - call allocate ressource size 0x2 startcalc
0x, align 0x2
find_resource - size 0x2, min 0x18000, max 0x
find_resource - continue with start 0x18800 on 0xcf810178
find_resource - continue with start 0x19000 on 0x
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #6:[EMAIL PROTECTED]
for :00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x1 startcalc
0x, align 0x1
find_resource - size 0x1, min 0x18000, max 0x
find_resource - continue with start 0x18800 on 0xcf810178
find_resource - continue with start 0x19000 on 0x
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #2:[EMAIL PROTECTED]
for :00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
Hm, BAR2 shouldn't be allocated in theprefetchable space -- it corresponds
to non-prefetchable (from lspci's output) MMIO register region...
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-d
[PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking the device_type property of the PCIe
device node ("pci" for root-complex and "pci-endpoint" for endpoint
configuration).
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
Changes in v2:
--
- As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
by looking at the already configured PCIe port state, but evaluate
the device_type property instead. This makes it possible for boards
without a previously run PCIe configuration (e.g. U-Boot) to configure
a port as endpoint as well.
- Don't map the big external config space upon endpoint configuration.
- Introduce "vendor-id" and "device-id" properties to be written to
the host bridge.
arch/powerpc/sysdev/ppc4xx_pci.c | 180 +++--
1 files changed, 131 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 1087196..acdc309 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1390,28 +1390,59 @@ static void __init ppc4xx_configure_pciex_PIMs(struct
ppc4xx_pciex_port *port,
resource_size_t size = res->end - res->start + 1;
u64 sa;
- /* Calculate window size */
- sa = (0xull << ilog2(size));;
- if (res->flags & IORESOURCE_PREFETCH)
- sa |= 0x8;
+ if (port->endpoint) {
+ resource_size_t ep_addr = 0;
+ resource_size_t ep_size = 32 << 20;
+
+ /* Currently we map a fixed 64MByte window to PLB address
+* 0 (SDRAM). This should probably be configurable via a dts
+* property.
+*/
+
+ /* Calculate window size */
+ sa = (0xull << ilog2(ep_size));;
+
+ /* Setup BAR0 */
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa) |
+PCI_BASE_ADDRESS_MEM_TYPE_64);
- out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
- out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+ /* Disable BAR1 & BAR2 */
+ out_le32(mbase + PECFG_BAR1MPA, 0);
+ out_le32(mbase + PECFG_BAR2HMPA, 0);
+ out_le32(mbase + PECFG_BAR2LMPA, 0);
- /* The setup of the split looks weird to me ... let's see if it works */
- out_le32(mbase + PECFG_PIM0LAL, 0x);
- out_le32(mbase + PECFG_PIM0LAH, 0x);
- out_le32(mbase + PECFG_PIM1LAL, 0x);
- out_le32(mbase + PECFG_PIM1LAH, 0x);
- out_le32(mbase + PECFG_PIM01SAH, 0x);
- out_le32(mbase + PECFG_PIM01SAL, 0x);
+ out_le32(mbase + PECFG_PIM01SAH, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_PIM01SAL, RES_TO_U32_LOW(sa));
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(ep_addr));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(ep_addr));
+ } else {
+ /* Calculate window size */
+ sa = (0xull << ilog2(size));;
+ if (res->flags & IORESOURCE_PREFETCH)
+ sa |= 0x8;
+
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+
+ /* The setup of the split looks weird to me ... let's see
+* if it works
+*/
+ out_le32(mbase + PECFG_PIM0LAL, 0x);
+ out_le32(mbase + PECFG_PIM0LAH, 0x);
+ out_le32(mbase + PECFG_PIM1LAL, 0x);
+ out_le32(mbase + PECFG_PIM1LAH, 0x);
+ out_le32(mbase + PECFG_PIM01SAH, 0x);
+ out_le32(mbase + PECFG_PIM01SAL, 0x);
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0,
RES_TO_U32_LOW(res->start));
+ out_le32(mbase + PCI_BASE_ADDRESS_1,
RES_TO_U32_HIGH(res->start));
+ }
/* Enable inbound mapping */
out_le32(mbase + PECFG_PIMEN, 0x1);
- out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
- out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
-
/* Enable I/O, Mem, and Busmaster cycles */
out_le16(mbase + PCI_COMMAND,
in_le16(mbase + PCI_COMMAND) |
@@ -1425,13 +1456,8 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
const int *bus_range;
int primary = 0, busses;
void __iomem *mbase = NULL, *cfg_data = NULL;
-
- /* XXX FIXME: Handle endpoint mode properly */
- if (port->endpoint) {
- print
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > > Should this really be a arch_initcall()? Would it be better for > > > platforms needing it to call it explicitly from one of the platform's > > > machine_arch_initcall()? Otherwise it gets called for all platforms > > > in a multiplatform kernel. > > > > Ok, I'll place it into qe_reset(). > > Ugh, no, I can't. qe_reset() is called too early. And I don't like > having every QE board file to call this through machine_arch_initcall... > Hmm, what to do.. well, is this thaat bad to call this for every > platform?.. Its not great. It has a boot time impact for every platform compiled into the kernel. The problem gets worse every time another block of code uses this method. Personally I prefer platform code calling it explicitly. Making it an of_platform device would also eliminate that problem, but you'd need a method to synchronize the driver with its users. I'm not going to raise a big stink about it, but the issue should not be ignored. Cheers, g. > > > > -- > Anton Vorontsov > email: [EMAIL PROTECTED] > irc://irc.freenode.net/bd2 > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Mon, Apr 21, 2008 at 06:33:13PM +0400, Anton Vorontsov wrote:
[...]
> > > +static int __init qe_add_gpiochips(void)
> > > +{
> > > + int ret;
> > > + struct device_node *np;
> > > +
> > > + for_each_compatible_node(np, NULL, "fsl,qe-pario-bank") {
> > > + struct qe_gpio_chip *qe_gc;
> > > + struct of_mm_gpio_chip *mm_gc;
> > > + struct of_gpio_chip *of_gc;
> > > + struct gpio_chip *gc;
> > > +
> > > + qe_gc = kzalloc(sizeof(*qe_gc), GFP_KERNEL);
> > > + if (!qe_gc) {
> > > + ret = -ENOMEM;
> > > + goto err;
> > > + }
> > > +
> > > + spin_lock_init(&qe_gc->lock);
> > > +
> > > + mm_gc = &qe_gc->mm_gc;
> > > + of_gc = &mm_gc->of_gc;
> > > + gc = &of_gc->gc;
> > > +
> > > + mm_gc->save_regs = qe_gpio_save_regs;
> > > + of_gc->gpio_cells = 2;
> > > + gc->ngpio = QE_PIO_PINS;
> > > + gc->direction_input = qe_gpio_dir_in;
> > > + gc->direction_output = qe_gpio_dir_out;
> > > + gc->get = qe_gpio_get;
> > > + gc->set = qe_gpio_set;
> > > +
> > > + ret = of_mm_gpiochip_add(np, mm_gc);
> > > + if (ret)
> > > + goto err;
> > > + }
> > > +
> > > + return 0;
> > > +err:
> > > + pr_err("%s: registration failed with status %d\n",
> > > np->full_name, ret);
> > > + of_node_put(np);
> > > + return ret;
> > > +}
> > > +arch_initcall(qe_add_gpiochips);
> >
> > Should this really be a arch_initcall()? Would it be better for
> > platforms needing it to call it explicitly from one of the platform's
> > machine_arch_initcall()? Otherwise it gets called for all platforms
> > in a multiplatform kernel.
>
> Ok, I'll place it into qe_reset().
Ugh, no, I can't. qe_reset() is called too early. And I don't like
having every QE board file to call this through machine_arch_initcall...
Hmm, what to do.. well, is this thaat bad to call this for every
platform?..
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Mon, Apr 21, 2008 at 08:19:05AM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > This is needed to access QE GPIOs via Linux GPIO API.
> >
> > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> > ---
> > diff --git a/Documentation/powerpc/booting-without-of.txt
> > b/Documentation/powerpc/booting-without-of.txt
> > index 827b630..5c9cfab 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -1721,24 +1721,32 @@ platforms are moved over to use the
> > flattened-device-tree model.
> > information.
> >
> > Required properties:
> > - - device_type : should be "par_io".
> > + - #gpio-cells : should be "2".
> > + - compatible : should be "fsl,qe-pario-bank-",
> > "fsl,qe-pario-bank"
>
> Once again; I don't like the generic compatible values. Please
> include the exact chip name in the string. ie: "fsl,-qe-pario".
>
> "fsl,qe-pario-bank" is not a real thing. If you want a common
> compatible string that the driver can bind against, then choose one
> real part and add it to the compatible list for all the other parts.
>
> Also, why is encoded in compatible? Do the different banks
> have different register interfaces?
Yes, they could. For example, interrupt pins are bank-specific.
> > - reg : offset to the register set and its length.
> > - - num-ports : number of Parallel I/O ports
> > + - gpio-controller : node to identify gpio controllers.
> >
> > - Example:
> > - [EMAIL PROTECTED] {
> > - reg = <1400 100>;
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > - device_type = "par_io";
> > - num-ports = <7>;
> > - [EMAIL PROTECTED] {
> > - ..
> > - };
> > + For example, two QE Par I/O banks:
> > + qe_pio_a: [EMAIL PROTECTED] {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> > + reg = <0x1400 0x18>;
> > + gpio-controller;
> > + };
> >
> > + qe_pio_e: [EMAIL PROTECTED] {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> > + reg = <0x1460 0x18>;
> > + gpio-controller;
> > + };
> >
> > vi) Pin configuration nodes
> >
> > + NOTE: pin configuration nodes are obsolete. Usually, their existance
> > + is an evidence of the firmware shortcomings. Such fixups are
> > + better handled by the Linux board file, not the device tree.
> > +
> > Required properties:
> > - linux,phandle : phandle of this node; likely referenced by a QE
> > device.
> > diff --git a/arch/powerpc/platforms/Kconfig
> > b/arch/powerpc/platforms/Kconfig
> > index f38c50b..f6eecd1 100644
> > --- a/arch/powerpc/platforms/Kconfig
> > +++ b/arch/powerpc/platforms/Kconfig
> > @@ -270,6 +270,8 @@ config QUICC_ENGINE
> > bool
> > select PPC_LIB_RHEAP
> > select CRC32
> > + select GENERIC_GPIO
> > + select HAVE_GPIO_LIB
> > help
> > The QUICC Engine (QE) is a new generation of communications
> > coprocessors on Freescale embedded CPUs (akin to CPM in older
> > chips).
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index bbd2834..cee56f9 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -25,6 +25,15 @@ config DEBUG_GPIO
> >
> > # put expanders in the right section, in alphabetical order
> >
> > +comment "On-chip GPIOs:"
> > +
> > +config GPIO_QE
> > + bool "QUICC Engine GPIOs"
> > + depends on QUICC_ENGINE
> > + help
> > + Say Y here to use GPIOs on the Freescale PowerPC CPUs with
> > + QUICC Engine block.
> > +
> > comment "I2C GPIO expanders:"
> >
> > config GPIO_PCA953X
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > index fdde992..fd0a41f 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -7,3 +7,4 @@ obj-$(CONFIG_HAVE_GPIO_LIB) += gpiolib.o
> > obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
> > obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
> > obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
> > +obj-$(CONFIG_GPIO_QE) += qe.o
>
> Since this isn't an of_platform or a platform driver; I'd put it into
> arch/powerpc instead.
Heh.
> > diff --git a/drivers/gpio/qe.c b/drivers/gpio/qe.c
> > new file mode 100644
> > index 000..474bc44
> > --- /dev/null
> > +++ b/drivers/gpio/qe.c
> > +static int __init qe_add_gpiochips(void)
> > +{
> > + int ret;
> > + struct device_node *np;
> > +
> > + for_each_compatible_node(np, NULL, "fsl,qe-pario-bank") {
> > + struct qe_gpio_chip *qe_gc;
> > +
Re: [PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC.
On Fri, Apr 18, 2008 at 11:10 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> This patch implement GPIO LIB support for the CPM1 GPIOs.
>
> Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/8xx/Kconfig | 10 ++
> arch/powerpc/sysdev/cpm1.c | 261
> +++-
> 2 files changed, 266 insertions(+), 5 deletions(-)
2 quick comments:
1. You need to include binding documentation to booting without of
2. You need to specifiy exact chip names in your compatible string.
"fsl,cpm1-pario-" is a made up thing.
Cheers,
g.
>
> diff --git a/arch/powerpc/platforms/8xx/Kconfig
> b/arch/powerpc/platforms/8xx/Kconfig
> index 6fc849e..3488bb7 100644
> --- a/arch/powerpc/platforms/8xx/Kconfig
> +++ b/arch/powerpc/platforms/8xx/Kconfig
> @@ -105,6 +105,16 @@ config 8xx_COPYBACK
>
> If in doubt, say Y here.
>
> +config 8xx_GPIO
> + bool "GPIO API Support"
> + select GENERIC_GPIO
> + select HAVE_GPIO_LIB
> + help
> + Saying Y here will cause the ports on an MPC8xx processor to be
> used
> + with the GPIO API. If you say N here, the kernel needs less
> memory.
> +
> + If in doubt, say Y here.
> +
> config 8xx_CPU6
> bool "CPU6 Silicon Errata (860 Pre Rev. C)"
> help
> diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
> index 58292a0..01ae3ae 100644
> --- a/arch/powerpc/sysdev/cpm1.c
> +++ b/arch/powerpc/sysdev/cpm1.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -42,6 +43,10 @@
>
> #include
>
> +#ifdef CONFIG_8xx_GPIO
> +#include
> +#endif
> +
> #define CPM_MAP_SIZE(0x4000)
>
> cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */
> @@ -290,20 +295,24 @@ struct cpm_ioport16 {
> __be16 res[3];
> };
>
> -struct cpm_ioport32 {
> - __be32 dir, par, sor;
> +struct cpm_ioport32b {
> + __be32 dir, par, odr, dat;
> +};
> +
> +struct cpm_ioport32e {
> + __be32 dir, par, sor, odr, dat;
> };
>
> static void cpm1_set_pin32(int port, int pin, int flags)
> {
> - struct cpm_ioport32 __iomem *iop;
> + struct cpm_ioport32e __iomem *iop;
> pin = 1 << (31 - pin);
>
> if (port == CPM_PORTB)
> - iop = (struct cpm_ioport32 __iomem *)
> + iop = (struct cpm_ioport32e __iomem *)
> &mpc8xx_immr->im_cpm.cp_pbdir;
> else
> - iop = (struct cpm_ioport32 __iomem *)
> + iop = (struct cpm_ioport32e __iomem *)
> &mpc8xx_immr->im_cpm.cp_pedir;
>
> if (flags & CPM_PIN_OUTPUT)
> @@ -498,3 +507,245 @@ int cpm1_clk_setup(enum cpm_clk_target target, int
> clock, int mode)
>
> return 0;
> }
> +
> +/*
> + * GPIO LIB API implementation
> + */
> +#ifdef CONFIG_8xx_GPIO
> +
> +struct cpm1_gpio16_chip {
> + struct of_mm_gpio_chip mm_gc;
> + spinlock_t lock;
> +
> + /* shadowed data register to clear/set bits safely */
> + u16 cpdata;
> +};
> +
> +static inline struct cpm1_gpio16_chip *
> +to_cpm1_gpio16_chip(struct of_mm_gpio_chip *mm_gc)
> +{
> + return container_of(mm_gc, struct cpm1_gpio16_chip, mm_gc);
> +}
> +
> +static void cpm1_gpio16_save_regs(struct of_mm_gpio_chip *mm_gc)
> +{
> + struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
> + struct cpm_ioport16 __iomem *iop = mm_gc->regs;
> +
> + cpm1_gc->cpdata = in_be16(&iop->dat);
> +}
> +
> +static int cpm1_gpio16_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct cpm_ioport16 __iomem *iop = mm_gc->regs;
> + u16 pin_mask;
> +
> + pin_mask = 1 << (15 - gpio);
> +
> + return !!(in_be16(&iop->dat) & pin_mask);
> +}
> +
> +static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int
> value)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
> + struct cpm_ioport16 __iomem *iop = mm_gc->regs;
> + unsigned long flags;
> + u16 pin_mask = 1 << (15 - gpio);
> +
> + spin_lock_irqsave(&cpm1_gc->lock, flags);
> +
> + if (value)
> + cpm1_gc->cpdata |= pin_mask;
> + else
> + cpm1_gc->cpdata &= ~pin_mask;
> +
> + out_be16(&iop->dat, cpm1_gc->cpdata);
> +
> + spin_unlock_irqrestore(&cpm1_gc->lock, flags);
> +}
> +
> +static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int
> val)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct cpm_ioport16 __iomem *iop = mm_gc->regs;
> + u16 pin_mask;
> +
> + pin_mask = 1 << (15 - gpio);
> +
> + setbits16(&iop->dir, pin_m
Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
> 2008/4/18 Anton Vorontsov <[EMAIL PROTECTED]>:
> > GTM stands for General-purpose Timers Module and able to generate
> > timer{1,2,3,4} interrupts. These timers are used by the drivers that
> > need time precise interrupts (like for USB transactions scheduling for
> > the Freescale USB Host controller as found in some QE and CPM chips),
> > or these timers could be used as wakeup events from the CPU deep-sleep
> > mode.
>
> Comments below.
>
> > diff --git a/Documentation/powerpc/booting-without-of.txt
> > b/Documentation/powerpc/booting-without-of.txt
> > index 4cc7800..827b630 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -57,7 +57,8 @@ Table of Contents
> >n) 4xx/Axon EMAC ethernet nodes
> >o) Xilinx IP cores
> >p) Freescale Synchronous Serial Interface
> > - q) USB EHCI controllers
> > + q) USB EHCI controllers
> > + r) Freescale General-purpose Timers Module
> >
> >VII - Marvell Discovery mv64[345]6x System Controller chips
> > 1) The /system-controller node
> > @@ -2825,6 +2826,35 @@ platforms are moved over to use the
> > flattened-device-tree model.
> >big-endian;
> >};
> >
> > +r) Freescale General-purpose Timers Module
> > +
> > +Required properties:
> > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > + GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
>
> I don't think this is specific enough. It is a very real possibility
> for Freescale to produce another part with a "general purpose timers
> module" that isn't register level compatible (and fsl,i2c is an
> example of what not to do). The compatible string should include the
> exact chip version. Newer parts can also claim compatibility with
> older ones.
Ok, I'll expand this to fsl,-gtm and
fsl,-{qe,cpm2}-gtm.
> Defining a 'generic' compatible value is also known as "making stuff up". :-)
>
> > + - reg : should contain gtm registers location and length (0x40).
> > + - interrupts : should contain four interrupts.
> > + - interrupt-parent : interrupt source phandle.
> > + - clock-frequency : specifies the frequency driving the timer.
> > +
> > +Example:
> > +
> > +[EMAIL PROTECTED] {
> > + compatible = "fsl,gtm";
> > + reg = <0x500 0x40>;
> > + interrupts = <90 8 78 8 84 8 72 8>;
> > + interrupt-parent = <&ipic>;
> > + /* filled by u-boot */
> > + clock-frequency = <0>;
> > +};
> > +
> > +[EMAIL PROTECTED] {
> > + compatible = "fsl,qe-gtm", "fsl,gtm";
> > + reg = <0x440 0x40>;
> > + interrupts = <12 13 14 15>;
> > + interrupt-parent = <&qeic>;
> > + /* filled by u-boot */
> > + clock-frequency = <0>;
> > +};
> >
> > VII - Marvell Discovery mv64[345]6x System Controller chips
> > ===
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 7f2f126..ad874e4 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -525,6 +525,11 @@ config FSL_LBC
> > help
> > Freescale Localbus support
> >
> > +config FSL_GTM
> > + bool
> > + help
> > + Freescale General-purpose Timers support
> > +
> > # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
> > config MCA
> > bool
> > diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> > index 6d386d0..9d3ddd2 100644
> > --- a/arch/powerpc/sysdev/Makefile
> > +++ b/arch/powerpc/sysdev/Makefile
> > @@ -13,6 +13,7 @@ obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
> > obj-$(CONFIG_FSL_SOC) += fsl_soc.o
> > obj-$(CONFIG_FSL_PCI) += fsl_pci.o
> > obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
> > +obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
> > obj-$(CONFIG_RAPIDIO) += fsl_rio.o
> > obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
> > obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
> > diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
> > new file mode 100644
> > index 000..d29df56
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/fsl_gtm.c
> > @@ -0,0 +1,365 @@
> > +/*
> > + * Freescale General-purpose Timers Module
> > + *
> > + * Copyright (c) Freescale Semicondutor, Inc. 2006.
> > + * Shlomi Gridish <[EMAIL PROTECTED]>
> > + * Jerry Huang <[EMAIL PROTECTED]>
> > + * Copyright (c) MontaVista Software, Inc. 2008.
> > + * Anton Vorontsov <[EMAIL PROTECTED]>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > it
> > + * under the terms of the GNU General Public License as published by
> > the
> > + * Free Software Foundation;
Re: [PATCH 3/5] [POWERPC] QE: prepare QE PIO code for GPIO LIB support
On Mon, Apr 21, 2008 at 08:08:39AM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > - split and export __par_io_config_pin() out of par_io_config_pin(), so we
> > could use the prefixed version with GPIO LIB API;
> > - rename struct port_regs to qe_pio_regs, and place it into qe.h;
> > - rename #define NUM_OF_PINS to QE_PIO_PINS, and place it into qe.h.
> >
> > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>
> I don't see any mutual exclusion here. How is __par_io_config_pin()
> protected when there are multiple callers?
The idea is to not have multiple callers.
Today most callers of par_io_config_pin() is various board fixups,
e.g. this in the setup_arch():
for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
par_io_of_config(np);
Which calls par_io_config_pin(). But we're safe here, setup_arch called
very early.
The only abuser of this is mpc832x_rdb.c, but it will be converted
to the GPIO API.
> > ---
> > arch/powerpc/sysdev/qe_lib/qe_io.c | 94
> > +---
> > include/asm-powerpc/qe.h | 19 +++
> > 2 files changed, 64 insertions(+), 49 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c
> > b/arch/powerpc/sysdev/qe_lib/qe_io.c
> > index 93916a4..7c87460 100644
> > --- a/arch/powerpc/sysdev/qe_lib/qe_io.c
> > +++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
> > @@ -28,21 +28,7 @@
> >
> > #undef DEBUG
> >
> > -#define NUM_OF_PINS32
> > -
> > -struct port_regs {
> > - __be32 cpodr; /* Open drain register */
> > - __be32 cpdata; /* Data register */
> > - __be32 cpdir1; /* Direction register */
> > - __be32 cpdir2; /* Direction register */
> > - __be32 cppar1; /* Pin assignment register */
> > - __be32 cppar2; /* Pin assignment register */
> > -#ifdef CONFIG_PPC_85xx
> > - u8 pad[8];
> > -#endif
> > -};
> > -
> > -static struct port_regs __iomem *par_io;
> > +static struct qe_pio_regs __iomem *par_io;
> > static int num_par_io_ports = 0;
> >
> > int par_io_init(struct device_node *np)
> > @@ -64,69 +50,79 @@ int par_io_init(struct device_node *np)
> > return 0;
> > }
> >
> > -int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
> > - int assignment, int has_irq)
> > +void __par_io_config_pin(struct qe_pio_regs __iomem *par_io, u8 pin, int
> > dir,
> > +int open_drain, int assignment, int has_irq)
> > {
> > - u32 pin_mask1bit, pin_mask2bits, new_mask2bits, tmp_val;
> > -
> > - if (!par_io)
> > - return -1;
> > + u32 pin_mask1bit;
> > + u32 pin_mask2bits;
> > + u32 new_mask2bits;
> > + u32 tmp_val;
> >
> > /* calculate pin location for single and 2 bits information */
> > - pin_mask1bit = (u32) (1 << (NUM_OF_PINS - (pin + 1)));
> > + pin_mask1bit = (u32) (1 << (QE_PIO_PINS - (pin + 1)));
> >
> > /* Set open drain, if required */
> > - tmp_val = in_be32(&par_io[port].cpodr);
> > + tmp_val = in_be32(&par_io->cpodr);
> > if (open_drain)
> > - out_be32(&par_io[port].cpodr, pin_mask1bit | tmp_val);
> > + out_be32(&par_io->cpodr, pin_mask1bit | tmp_val);
> > else
> > - out_be32(&par_io[port].cpodr, ~pin_mask1bit & tmp_val);
> > + out_be32(&par_io->cpodr, ~pin_mask1bit & tmp_val);
> >
> > /* define direction */
> > - tmp_val = (pin > (NUM_OF_PINS / 2) - 1) ?
> > - in_be32(&par_io[port].cpdir2) :
> > - in_be32(&par_io[port].cpdir1);
> > + tmp_val = (pin > (QE_PIO_PINS / 2) - 1) ?
> > + in_be32(&par_io->cpdir2) :
> > + in_be32(&par_io->cpdir1);
> >
> > /* get all bits mask for 2 bit per port */
> > - pin_mask2bits = (u32) (0x3 << (NUM_OF_PINS -
> > - (pin % (NUM_OF_PINS / 2) + 1) * 2));
> > + pin_mask2bits = (u32) (0x3 << (QE_PIO_PINS -
> > + (pin % (QE_PIO_PINS / 2) + 1) * 2));
> >
> > /* Get the final mask we need for the right definition */
> > - new_mask2bits = (u32) (dir << (NUM_OF_PINS -
> > - (pin % (NUM_OF_PINS / 2) + 1) * 2));
> > + new_mask2bits = (u32) (dir << (QE_PIO_PINS -
> > + (pin % (QE_PIO_PINS / 2) + 1) * 2));
> >
> > /* clear and set 2 bits mask */
> > - if (pin > (NUM_OF_PINS / 2) - 1) {
> > - out_be32(&par_io[port].cpdir2,
> > + if (pin > (QE_PIO_PINS / 2) - 1) {
> > + out_be32(&par_io->cpdir2,
> > ~pin_mask2bits & tmp_val);
> > tmp_val &= ~pin_mask2bits;
> > - out_be32(&par_io[port].c
Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Bartlomiej Sieka wrote: > > > Board-specific defconfigs based on current mpc5200_defconfig, archival > > lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the > > linux-2.6-denx tree. Kernels build using these defconfigs were verified > > to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200 > > and Lite5200B boards. CM5200 target was not tested due to hardware > > unavailability. > > > > Hello Grant, > > There hasn't been any negitve comments on the above patch -- will you > push it upstream via your tree? Yes, of course. I would have acked it, but I never saw it (not cc'd). Acked-by: Grant Likely <[EMAIL PROTECTED]> Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: x86-latest/powerpc-next merge conflict
On Mon, 21 Apr 2008 15:36:06 +0200, "Gabriel Paubert" <[EMAIL PROTECTED]>
said:
> On Mon, Apr 21, 2008 at 03:07:13PM +0200, Alexander van Heukelum wrote:
> > On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
> > said:
> > > Alexander van Heukelum writes:
> > > > Powerpc would pick up an optimized version via this chain: generic fls64
> > > > ->
> > > > powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r"
> > > > (x)).
> > >
> > > Why wouldn't powerpc continue to use the fls64 that I have in there
> > > now?
> >
> > In Linus' tree that would be the generic one that uses (the 32-bit)
> > fls():
> >
> > static inline int fls64(__u64 x)
> > {
> > __u32 h = x >> 32;
> > if (h)
> > return fls(h) + 32;
> > return fls(x);
> > }
> >
> > > > However, the generic version of fls64 first tests the argument for zero.
> > > > From
> > > > your code I derive that the count-leading-zeroes instruction for
> > > > argument zero
> > > > is defined as cntlzl(0) == BITS_PER_LONG.
> > >
> > > That is correct. If the argument is 0 then all of the zero bits are
> > > leading zeroes. :)
> >
> > So... for 64-bit powerpc it makes sense to have its own implementation
> > and ignore the (improved) generic one and for 32-bit powerpc the generic
> > implementation of fls64 is fine. The current situation in linux-next
> > seems
> > optimal to me.
>
>
> Not so sure, the optimal version of fls64 for 32 bit PPC seems to be:
>
> cntlzw ch,h ; ch = fls32(h) where h = x>>32
> cntlzw cl,l ; cl = fls32(l) where l = (__u32)x
> srwit1,ch,5
> neg t1,t1 ; t1 = (h==0) ? -1 : 0
> and cl,t1,cl ; cl = (h==0) ? cl : 0
> add result,ch,cl
>
> That's only 6 instructions without any branch, although the dependency
> chain is 5 instructions long. Good luck getting the compiler to
> generate something as compact as this.
I should not have said the magic word optimal, I guess ;). The code
you show would fit nicely as an arch-specific optimized version of
fls64 for 32-bit powerpc in include/arch-powerpc/bitops.h.
Greetings,
Alexander
(who is not going to write and test a patch with
powerpc inline assembly soon. srwi?)
> Don't worry about the number of cntlzw, it's one clock on all 32 bit
> PPC processors I know, some may even be able to perform 2 or 3 cntlzw
> per clock.
>
> Regards,
> Gabriel
>
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Same, same, but different
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> This is needed to access QE GPIOs via Linux GPIO API.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index 827b630..5c9cfab 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1721,24 +1721,32 @@ platforms are moved over to use the
> flattened-device-tree model.
> information.
>
> Required properties:
> - - device_type : should be "par_io".
> + - #gpio-cells : should be "2".
> + - compatible : should be "fsl,qe-pario-bank-", "fsl,qe-pario-bank"
Once again; I don't like the generic compatible values. Please
include the exact chip name in the string. ie: "fsl,-qe-pario".
"fsl,qe-pario-bank" is not a real thing. If you want a common
compatible string that the driver can bind against, then choose one
real part and add it to the compatible list for all the other parts.
Also, why is encoded in compatible? Do the different banks
have different register interfaces?
> - reg : offset to the register set and its length.
> - - num-ports : number of Parallel I/O ports
> + - gpio-controller : node to identify gpio controllers.
>
> - Example:
> - [EMAIL PROTECTED] {
> - reg = <1400 100>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - device_type = "par_io";
> - num-ports = <7>;
> - [EMAIL PROTECTED] {
> - ..
> - };
> + For example, two QE Par I/O banks:
> + qe_pio_a: [EMAIL PROTECTED] {
> + #gpio-cells = <2>;
> + compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> + reg = <0x1400 0x18>;
> + gpio-controller;
> + };
>
> + qe_pio_e: [EMAIL PROTECTED] {
> + #gpio-cells = <2>;
> + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> + reg = <0x1460 0x18>;
> + gpio-controller;
> + };
>
> vi) Pin configuration nodes
>
> + NOTE: pin configuration nodes are obsolete. Usually, their existance
> + is an evidence of the firmware shortcomings. Such fixups are
> + better handled by the Linux board file, not the device tree.
> +
> Required properties:
> - linux,phandle : phandle of this node; likely referenced by a QE
> device.
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index f38c50b..f6eecd1 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -270,6 +270,8 @@ config QUICC_ENGINE
> bool
> select PPC_LIB_RHEAP
> select CRC32
> + select GENERIC_GPIO
> + select HAVE_GPIO_LIB
> help
> The QUICC Engine (QE) is a new generation of communications
> coprocessors on Freescale embedded CPUs (akin to CPM in older
> chips).
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index bbd2834..cee56f9 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -25,6 +25,15 @@ config DEBUG_GPIO
>
> # put expanders in the right section, in alphabetical order
>
> +comment "On-chip GPIOs:"
> +
> +config GPIO_QE
> + bool "QUICC Engine GPIOs"
> + depends on QUICC_ENGINE
> + help
> + Say Y here to use GPIOs on the Freescale PowerPC CPUs with
> + QUICC Engine block.
> +
> comment "I2C GPIO expanders:"
>
> config GPIO_PCA953X
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index fdde992..fd0a41f 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_HAVE_GPIO_LIB) += gpiolib.o
> obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
> obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
> obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
> +obj-$(CONFIG_GPIO_QE) += qe.o
Since this isn't an of_platform or a platform driver; I'd put it into
arch/powerpc instead.
> diff --git a/drivers/gpio/qe.c b/drivers/gpio/qe.c
> new file mode 100644
> index 000..474bc44
> --- /dev/null
> +++ b/drivers/gpio/qe.c
> +static int __init qe_add_gpiochips(void)
> +{
> + int ret;
> + struct device_node *np;
> +
> + for_each_compatible_node(np, NULL, "fsl,qe-pario-bank") {
> + struct qe_gpio_chip *qe_gc;
> + struct of_mm_gpio_chip *mm_gc;
> + struct of_gpio_chip *of_gc;
> + struct gpio_chip *gc;
> +
> + qe_gc = kzalloc(sizeof(*qe_gc), GFP_KERNEL);
> + if (!qe_gc) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + spin_lock_init(&qe_gc->lock);
> +
> +
Re: [PATCH 3/5] [POWERPC] QE: prepare QE PIO code for GPIO LIB support
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> - split and export __par_io_config_pin() out of par_io_config_pin(), so we
> could use the prefixed version with GPIO LIB API;
> - rename struct port_regs to qe_pio_regs, and place it into qe.h;
> - rename #define NUM_OF_PINS to QE_PIO_PINS, and place it into qe.h.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
I don't see any mutual exclusion here. How is __par_io_config_pin()
protected when there are multiple callers?
> ---
> arch/powerpc/sysdev/qe_lib/qe_io.c | 94
> +---
> include/asm-powerpc/qe.h | 19 +++
> 2 files changed, 64 insertions(+), 49 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c
> b/arch/powerpc/sysdev/qe_lib/qe_io.c
> index 93916a4..7c87460 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe_io.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
> @@ -28,21 +28,7 @@
>
> #undef DEBUG
>
> -#define NUM_OF_PINS32
> -
> -struct port_regs {
> - __be32 cpodr; /* Open drain register */
> - __be32 cpdata; /* Data register */
> - __be32 cpdir1; /* Direction register */
> - __be32 cpdir2; /* Direction register */
> - __be32 cppar1; /* Pin assignment register */
> - __be32 cppar2; /* Pin assignment register */
> -#ifdef CONFIG_PPC_85xx
> - u8 pad[8];
> -#endif
> -};
> -
> -static struct port_regs __iomem *par_io;
> +static struct qe_pio_regs __iomem *par_io;
> static int num_par_io_ports = 0;
>
> int par_io_init(struct device_node *np)
> @@ -64,69 +50,79 @@ int par_io_init(struct device_node *np)
> return 0;
> }
>
> -int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
> - int assignment, int has_irq)
> +void __par_io_config_pin(struct qe_pio_regs __iomem *par_io, u8 pin, int
> dir,
> +int open_drain, int assignment, int has_irq)
> {
> - u32 pin_mask1bit, pin_mask2bits, new_mask2bits, tmp_val;
> -
> - if (!par_io)
> - return -1;
> + u32 pin_mask1bit;
> + u32 pin_mask2bits;
> + u32 new_mask2bits;
> + u32 tmp_val;
>
> /* calculate pin location for single and 2 bits information */
> - pin_mask1bit = (u32) (1 << (NUM_OF_PINS - (pin + 1)));
> + pin_mask1bit = (u32) (1 << (QE_PIO_PINS - (pin + 1)));
>
> /* Set open drain, if required */
> - tmp_val = in_be32(&par_io[port].cpodr);
> + tmp_val = in_be32(&par_io->cpodr);
> if (open_drain)
> - out_be32(&par_io[port].cpodr, pin_mask1bit | tmp_val);
> + out_be32(&par_io->cpodr, pin_mask1bit | tmp_val);
> else
> - out_be32(&par_io[port].cpodr, ~pin_mask1bit & tmp_val);
> + out_be32(&par_io->cpodr, ~pin_mask1bit & tmp_val);
>
> /* define direction */
> - tmp_val = (pin > (NUM_OF_PINS / 2) - 1) ?
> - in_be32(&par_io[port].cpdir2) :
> - in_be32(&par_io[port].cpdir1);
> + tmp_val = (pin > (QE_PIO_PINS / 2) - 1) ?
> + in_be32(&par_io->cpdir2) :
> + in_be32(&par_io->cpdir1);
>
> /* get all bits mask for 2 bit per port */
> - pin_mask2bits = (u32) (0x3 << (NUM_OF_PINS -
> - (pin % (NUM_OF_PINS / 2) + 1) * 2));
> + pin_mask2bits = (u32) (0x3 << (QE_PIO_PINS -
> + (pin % (QE_PIO_PINS / 2) + 1) * 2));
>
> /* Get the final mask we need for the right definition */
> - new_mask2bits = (u32) (dir << (NUM_OF_PINS -
> - (pin % (NUM_OF_PINS / 2) + 1) * 2));
> + new_mask2bits = (u32) (dir << (QE_PIO_PINS -
> + (pin % (QE_PIO_PINS / 2) + 1) * 2));
>
> /* clear and set 2 bits mask */
> - if (pin > (NUM_OF_PINS / 2) - 1) {
> - out_be32(&par_io[port].cpdir2,
> + if (pin > (QE_PIO_PINS / 2) - 1) {
> + out_be32(&par_io->cpdir2,
> ~pin_mask2bits & tmp_val);
> tmp_val &= ~pin_mask2bits;
> - out_be32(&par_io[port].cpdir2, new_mask2bits | tmp_val);
> + out_be32(&par_io->cpdir2, new_mask2bits | tmp_val);
> } else {
> - out_be32(&par_io[port].cpdir1,
> + out_be32(&par_io->cpdir1,
> ~pin_mask2bits & tmp_val);
> tmp_val &= ~pin_mask2bits;
> - out_be32(&par_io[port].cpdir1, new_mask2bits | tmp_val);
> + out_be32(&par_io->cpdir1, new_mask2bits | tmp_val);
> }
> /* define pin assignment */
> - tmp_val = (pin > (NUM_OF_PINS / 2) - 1) ?
> - in_be32(&par_io[port].cppar2) :
> - in_be32(&par_io[port].cppar1);
> + tmp_val = (pin > (QE_PIO_PIN
Re: pci issue - wrong detection of pci ressources
Sergei Shtylyov wrote:
Hello.
Christian Ehrhardt wrote:
Cheers,
Ben.
For comparison I defined DEBUG in the good kernel (arch=ppc) and that
is what the initialization prints (pci ...:0a:1 is the secondary head
of the same graphic card an it's not an issue if thats not allocated):
[...]
You've changed fb_base_phys and mmio_base_phys to resource_size_t
which is 64-bit, so use %llx to print them.
Thanks your absolutely right, I sometimes forget that I need long long for
64bit on 32bit archs (and ignored the warnings :-( ).
I corrected the printk format strings and attached the new logs.
[...]
+else {
+printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__, (this->end +
1), this->sibling);
+}
new->start = this->end + 1;
this = this->sibling;
And here. Yet it's not clear why you call resource's 'end' 'start'...
It's the new->start that get's calculated one line after that new else part.
I printed that one to to see a bit how the loop iterates the resource elements.
WBR, Sergei
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
With DEBUG in arch/powerpc/kernel/pci-common.c, debug in commandline and a
patch with some printk's (I attached the patch because it is the usual "put
printk's everywhere" so the diff helps to understand where the prints come
from). Corrected prinf format specifiers according to the comments from Sergei
Shtylyov.
PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges:
MEM 0x00018000..0x00018fff -> 0x8000
IO 0x0001e800..0x0001e80f -> 0x
4xx PCI DMA offset set to 0x
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources :00:00.0
Try to map irq for :00:00.0...
-> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for :00:0a.0...
-> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for :00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: -000f [0x100],
parent c0365060 (PCI IO)
__request_resource - request 0xcf8045b0 name '/plb/[EMAIL PROTECTED]' start 0x0
end 0xf
__request_resource - no conflict parent 0xc0365060 sibling 0x
PCI: PHB (bus 0) bridge rsrc 1: 00018000-00018fff [0x200],
parent c0365038 (PCI mem)
__request_resource - request 0xcf8045d8 name '/plb/[EMAIL PROTECTED]' start
0x18000 end 0x18fff
__request_resource - no conflict parent 0xc0365038 sibling 0x
PCI: Assigning unassigned resouces...
pci_assign_unassigned_resources -#1- bus 0xcf82d400
pci_assign_unassigned_resources -#2- bus 0xcf82d400
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x800 startcalc
0x, align 0x800
find_resource - size 0x800, min 0x18000, max 0x
find_resource - found start 0x18000 end 0x187ff
__request_resource - request 0xcf810578 name ':00:0a.0' start 0x18000
end 0x187ff
__request_resource - no conflict parent 0xcf8045d8 sibling 0x
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x800 startcalc
0x, align 0x800
find_resource - size 0x800, min 0x18000, max 0x
find_resource - continue with start 0x18800 on 0x
find_resource - found start 0x18800 end 0x18fff
__request_resource - request 0xcf810178 name ':00:0a.1' start 0x18800
end 0x18fff
__request_resource - no conflict parent 0xcf8045d8 sibling 0x
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x2 startcalc
0x, align 0x2
find_resource - size 0x2, min 0x18000, max 0x
find_resource - continue with start 0x18800 on 0xcf810178
find_resource - continue with start 0x19000 on 0x
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #6:[EMAIL PROTECTED]
for :00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x1 startcalc
0x, align 0x1
find_resource - size 0x1, min 0x18000, max 0x
find_resource - continue with start 0x18800 on 0xcf810178
find_resource - continue with start 0x19000 on 0x
find_resource - no this - exit
PCI: pci
Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
2008/4/18 Anton Vorontsov <[EMAIL PROTECTED]>:
> GTM stands for General-purpose Timers Module and able to generate
> timer{1,2,3,4} interrupts. These timers are used by the drivers that
> need time precise interrupts (like for USB transactions scheduling for
> the Freescale USB Host controller as found in some QE and CPM chips),
> or these timers could be used as wakeup events from the CPU deep-sleep
> mode.
Comments below.
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index 4cc7800..827b630 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -57,7 +57,8 @@ Table of Contents
>n) 4xx/Axon EMAC ethernet nodes
>o) Xilinx IP cores
>p) Freescale Synchronous Serial Interface
> - q) USB EHCI controllers
> + q) USB EHCI controllers
> + r) Freescale General-purpose Timers Module
>
>VII - Marvell Discovery mv64[345]6x System Controller chips
> 1) The /system-controller node
> @@ -2825,6 +2826,35 @@ platforms are moved over to use the
> flattened-device-tree model.
>big-endian;
>};
>
> +r) Freescale General-purpose Timers Module
> +
> +Required properties:
> + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> + GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
I don't think this is specific enough. It is a very real possibility
for Freescale to produce another part with a "general purpose timers
module" that isn't register level compatible (and fsl,i2c is an
example of what not to do). The compatible string should include the
exact chip version. Newer parts can also claim compatibility with
older ones.
Defining a 'generic' compatible value is also known as "making stuff up". :-)
> + - reg : should contain gtm registers location and length (0x40).
> + - interrupts : should contain four interrupts.
> + - interrupt-parent : interrupt source phandle.
> + - clock-frequency : specifies the frequency driving the timer.
> +
> +Example:
> +
> +[EMAIL PROTECTED] {
> + compatible = "fsl,gtm";
> + reg = <0x500 0x40>;
> + interrupts = <90 8 78 8 84 8 72 8>;
> + interrupt-parent = <&ipic>;
> + /* filled by u-boot */
> + clock-frequency = <0>;
> +};
> +
> +[EMAIL PROTECTED] {
> + compatible = "fsl,qe-gtm", "fsl,gtm";
> + reg = <0x440 0x40>;
> + interrupts = <12 13 14 15>;
> + interrupt-parent = <&qeic>;
> + /* filled by u-boot */
> + clock-frequency = <0>;
> +};
>
> VII - Marvell Discovery mv64[345]6x System Controller chips
> ===
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 7f2f126..ad874e4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -525,6 +525,11 @@ config FSL_LBC
> help
> Freescale Localbus support
>
> +config FSL_GTM
> + bool
> + help
> + Freescale General-purpose Timers support
> +
> # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
> config MCA
> bool
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 6d386d0..9d3ddd2 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
> obj-$(CONFIG_FSL_SOC) += fsl_soc.o
> obj-$(CONFIG_FSL_PCI) += fsl_pci.o
> obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
> +obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
> obj-$(CONFIG_RAPIDIO) += fsl_rio.o
> obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
> obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
> diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
> new file mode 100644
> index 000..d29df56
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_gtm.c
> @@ -0,0 +1,365 @@
> +/*
> + * Freescale General-purpose Timers Module
> + *
> + * Copyright (c) Freescale Semicondutor, Inc. 2006.
> + * Shlomi Gridish <[EMAIL PROTECTED]>
> + * Jerry Huang <[EMAIL PROTECTED]>
> + * Copyright (c) MontaVista Software, Inc. 2008.
> + * Anton Vorontsov <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * gtm_get_timer - request GTM timer to use it with the rest of GTM API
> + * @width: timer width (only 16 bits wide timers implemented so far)
> + *
Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
Bartlomiej Sieka wrote: Board-specific defconfigs based on current mpc5200_defconfig, archival lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the linux-2.6-denx tree. Kernels build using these defconfigs were verified to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200 and Lite5200B boards. CM5200 target was not tested due to hardware unavailability. Hello Grant, There hasn't been any negitve comments on the above patch -- will you push it upstream via your tree? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: x86-latest/powerpc-next merge conflict
On Mon, Apr 21, 2008 at 03:07:13PM +0200, Alexander van Heukelum wrote:
> On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
> said:
> > Alexander van Heukelum writes:
> > > Powerpc would pick up an optimized version via this chain: generic fls64
> > > ->
> > > powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r"
> > > (x)).
> >
> > Why wouldn't powerpc continue to use the fls64 that I have in there
> > now?
>
> In Linus' tree that would be the generic one that uses (the 32-bit)
> fls():
>
> static inline int fls64(__u64 x)
> {
> __u32 h = x >> 32;
> if (h)
> return fls(h) + 32;
> return fls(x);
> }
>
> > > However, the generic version of fls64 first tests the argument for zero.
> > > From
> > > your code I derive that the count-leading-zeroes instruction for
> > > argument zero
> > > is defined as cntlzl(0) == BITS_PER_LONG.
> >
> > That is correct. If the argument is 0 then all of the zero bits are
> > leading zeroes. :)
>
> So... for 64-bit powerpc it makes sense to have its own implementation
> and ignore the (improved) generic one and for 32-bit powerpc the generic
> implementation of fls64 is fine. The current situation in linux-next
> seems
> optimal to me.
Not so sure, the optimal version of fls64 for 32 bit PPC seems to be:
cntlzw ch,h ; ch = fls32(h) where h = x>>32
cntlzw cl,l ; cl = fls32(l) where l = (__u32)x
srwit1,ch,5
neg t1,t1 ; t1 = (h==0) ? -1 : 0
and cl,t1,cl ; cl = (h==0) ? cl : 0
add result,ch,cl
That's only 6 instructions without any branch, although the dependency
chain is 5 instructions long. Good luck getting the compiler to
generate something as compact as this.
Don't worry about the number of cntlzw, it's one clock on all 32 bit
PPC processors I know, some may even be able to perform 2 or 3 cntlzw
per clock.
Regards,
Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
On Mon, Apr 21, 2008 at 2:43 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote:
>
>
> > Update dts files to current format
> >
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> > ---
> >
> > arch/powerpc/boot/dts/cm5200.dts| 98 +++
> > arch/powerpc/boot/dts/lite5200.dts | 132
>
> > arch/powerpc/boot/dts/lite5200b.dts | 146
> +--
> > arch/powerpc/boot/dts/motionpro.dts | 118 ++--
> > arch/powerpc/boot/dts/tqm5200.dts | 80 ++-
> > 5 files changed, 286 insertions(+), 288 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/cm5200.dts
> b/arch/powerpc/boot/dts/cm5200.dts
> > index c6ca631..2f74cc4 100644
> > --- a/arch/powerpc/boot/dts/cm5200.dts
> > +++ b/arch/powerpc/boot/dts/cm5200.dts
> > @@ -10,11 +10,7 @@
> > * option) any later version.
> > */
> >
> > -/*
> > - * WARNING: Do not depend on this tree layout remaining static just yet.
> > - * The MPC5200 device tree conventions are still in flux
> > - * Keep an eye on the linuxppc-dev mailing list for more details
> > - */
> > +/dts-v1/;
> >
> > / {
> > model = "schindler,cm5200";
> > @@ -29,10 +25,10 @@
> > PowerPC,[EMAIL PROTECTED] {
> > device_type = "cpu";
> > reg = <0>;
> > - d-cache-line-size = <20>;
> > - i-cache-line-size = <20>;
> > - d-cache-size = <4000>; // L1, 16K
> > - i-cache-size = <4000>; // L1, 16K
> > + d-cache-line-size = <32>;
> > + i-cache-line-size = <32>;
>
> Has the standard number format changed to decimal lately? Otherwise this
> looks wrong. There are more occurences of this in the other dts files.
Yes, that is the major change in v1 of the dts format. It uses C
style number format.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [v3][POWERPC] refactor dcr code
On Sun, 20 Apr 2008 20:56:20 -0700
"Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote:
>
>
> > > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > > +{
> > > + if (host.type == NATIVE)
> > > + dcr_unmap_native(host.host.native, dcr_c);
> > > + else
> > > + dcr_unmap_mmio(host.host.mmio, dcr_c);
> >
> > What happens if host.type == INVALID? Same question for the other
> > accessors in dcr_*_generic.
>
> I guess looking back on it, I assumed that MAP_OK would return 0, meaning
> that behavior was undefined,
> but I agree it's probably safer to have some error reporting there... There
> starts to become a speed tradeoff
> at some point, which would make function pointers more attractive. If the
> ioremap does fail, or the
> dcr-access-method can't be determined, then dcr_unmap_mmio would probably
> SEGV anyway, although that's
> not something I'd really want to rely on. I'll put an error case in there.
Well, MAP_OK would return 0, and the caller of the original dcr_map
should probably return an error or something. But there's nothing to
enforce that. Which is true for the current code today as well, so
it's not something you've introduced.
I just thought that if you were going to go to the trouble of defining
an invalid host type, that you'd check for it in the accessor
functions. There is the concern of the speed tradeoffs. I suppose you
could just omit INVALID altogether and have it match the existing code
in behavior if it was too big of a deal.
Ben, any thoughts?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: x86-latest/powerpc-next merge conflict
On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
said:
> Alexander van Heukelum writes:
> > Powerpc would pick up an optimized version via this chain: generic fls64
> > ->
> > powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r"
> > (x)).
>
> Why wouldn't powerpc continue to use the fls64 that I have in there
> now?
In Linus' tree that would be the generic one that uses (the 32-bit)
fls():
static inline int fls64(__u64 x)
{
__u32 h = x >> 32;
if (h)
return fls(h) + 32;
return fls(x);
}
> > However, the generic version of fls64 first tests the argument for zero.
> > From
> > your code I derive that the count-leading-zeroes instruction for
> > argument zero
> > is defined as cntlzl(0) == BITS_PER_LONG.
>
> That is correct. If the argument is 0 then all of the zero bits are
> leading zeroes. :)
So... for 64-bit powerpc it makes sense to have its own implementation
and ignore the (improved) generic one and for 32-bit powerpc the generic
implementation of fls64 is fine. The current situation in linux-next
seems
optimal to me.
Greetings,
Alexander
> Regards,
> Paul.
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - I mean, what is it about a decent email service?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci issue - wrong detection of pci ressources
Hello. Christian Ehrhardt wrote: Cheers, Ben. For comparison I defined DEBUG in the good kernel (arch=ppc) and that is what the initialization prints (pci ...:0a:1 is the secondary head of the same graphic card an it's not an issue if thats not allocated): good case: PCI: Probing PCI hardware PCI: bridge rsrc 0.. (100), parent c0354624 PCI: bridge rsrc 8000..8fff (200), parent c0354608 PCI::00:0a.0: Resource 0: 8800-8fff (f=1208) PCI::00:0a.0: Resource 1: ff00- (f=101) PCI::00:0a.0: Resource 2: 87ff-87ff (f=200) PCI::00:0a.1: Resource 0: 7800-7fff (f=1208) PCI: Cannot allocate resource region 0 of device :00:0a.1 PCI::00:0a.1: Resource 1: 77ff-77ff (f=200) PCI: Cannot allocate resource region 1 of device :00:0a.1 PCI: Failed to allocate mem resource #0:[EMAIL PROTECTED] for :00:0a.1 PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x00018000..0x00018fff -> 0x8000 IO 0x0001e800..0x0001e80f -> 0x 4xx PCI DMA offset set to 0x PCI: Probing PCI hardware PCI: Hiding 4xx host bridge resources :00:00.0 Try to map irq for :00:00.0... -> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2 -> mapped to linux irq 16 Try to map irq for :00:0a.0... -> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2 -> mapped to linux irq 16 Try to map irq for :00:0a.1... PCI: PHB (bus 0) bridge rsrc 0: -000f [0x100], parent c0365060 (PCI IO) __request_resource - request cf8045b0 name '/plb/[EMAIL PROTECTED]' start 0x0 end 0x0 __request_resource - no conflict parent c0365060 sibling PCI: PHB (bus 0) bridge rsrc 1: 00018000-00018fff [0x200], parent c0365038 (PCI mem) __request_resource - request cf8045d8 name '/plb/[EMAIL PROTECTED]' start 0x1 end 0x8000 Bogus start/end value because you're not printing them right... __request_resource - no conflict parent c0365038 sibling PCI: Assigning unassigned resouces... pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_assign_resource - second pci_bus_alloc_resource call pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1 find_resource - size 0, min 0x800, max 0x1 find_resource - found start 0x1 end 0x8000 __request_resource - request cf810578 name ':00:0a.0' start 0x1 end 0x8000 The start/end values are bogus -- not printed right. __request_resource - no conflict parent cf8045d8 sibling pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_assign_resource - second pci_bus_alloc_resource call pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1 find_resource - size 0, min 0x800, max 0x1 find_resource - continue with start 0x1 on 8800 find_resource - found start 0x1 end 0x8800 __request_resource - request cf810178 name ':00:0a.1' start 0x1 end 0x8800 Same here. __request_resource - no conflict parent cf8045d8 sibling pci_assign_resource - allocate with IORESOURCE_PREFETCH It's not clear why the register space is prefetchable. pci_bus_alloc_resource - enter pci_assign_resource - second pci_bus_alloc_resource call pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 131072, align -1 find_resource - size 0, min 0x2, max 0x1 find_resource - continue with start 0x1 on 8800 find_resource - continue with start 0x1 on 9000 find_resource - no this - exit ... and here. It's not clear why it failed with 18800... maybe we ran out of prefetchable space? PCI: pci_assign_resource - Failed to allocate mem resource #6:[EMAIL PROTECTED] for :00:0a.0 pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1 find_resource - size 0, min 0x1, max 0x1 find_resource - continue with start 0x1 on 8800 find_resource - continue with start 0x1 on 9000 find_resource - no this - exit PCI: pci_assign_resource - Failed to allocate mem resource #2:[EMAIL PROTECTED] for :00:0a.0 pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1 find_resource - size 0, min 0x1, max 0x1 find_resource - continue with start 0x1 on 8800 find_resource - continue with start 0x1 on 9000 find_resource - no this - exit PCI: pci_assign_resource - Failed to allocate mem resou
Re: [PATCH] rtc-pcf8563: Add device ids table
On Monday 21 April 2008, Laurent Pinchart wrote: > > > > Is there any chance they will got to 2.6.26? > > > > > > I'm not sure. I didn't have the time to look at it myself, but I am > > > under the impression that the powerpc folks are tired of having to wait > > > for me and may push it to Linus through their tree? That would be fine > > > with me, as I don't want to be the one delaying something many > > > developers want (but I also can't sign patches I've not even read.) > > The patches are required for long awaited I2C support on various PowerPC > boards. As the ppc architecture support is going away in 2.6.27, it would > be nice to have them applied in 2.6.26. Yes, please. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: x86-latest/powerpc-next merge conflict
Ingo Molnar writes: > Paul, do you agree with those generic bitops changes? Just in case it's Well, it looks OK, but I'm sure people are going to get confused with fls vs. fls64 vs. __fls all being subtly different. I'd say it's worth putting a little file in the Documentation directory to explain it all. > not obvious from previous discussions: we'll push them upstream via a > separate pull request, not via usual x86.git changes. They originated > from x86.git but grew into a more generic improvement for all. They sit > in x86.git for tester convenience but are of course not pure x86 changes > anymore. I'm not sure why the "add __fls to all 64-bit architectures" change has to be done as a single patch rather than a patch per architecture going through the architecture maintainers. I suppose that avoids any problem with some maintainers not sending it upstream quickly. I would expect that if it is a single cross-architecture patch that it would go through Andrew Morton, though. But if Andrew wants you to handle it then I'm happy to give you an Acked-by for it. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: x86-latest/powerpc-next merge conflict
Alexander van Heukelum writes: > Powerpc would pick up an optimized version via this chain: generic fls64 > -> > powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" > (x)). Why wouldn't powerpc continue to use the fls64 that I have in there now? > However, the generic version of fls64 first tests the argument for zero. > From > your code I derive that the count-leading-zeroes instruction for > argument zero > is defined as cntlzl(0) == BITS_PER_LONG. That is correct. If the argument is 0 then all of the zero bits are leading zeroes. :) Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] rtc-pcf8563: Add device ids table
On Saturday 19 April 2008 18:43, Jochen Friedrich wrote: > Jean Delvare wrote: > > On Sat, 19 Apr 2008 15:09:55 +0200, Jochen Friedrich wrote: > > > Hi Jean, > > > > > > > > > Is the new-style driver conversion patch in 2.6.25-rc8-mm2 > > > > > > scheduled for 2.6.26 ? > > > > > hope so! :) > > > > Note that this patch depends on i2c patches which aren't upstream yet. > > > Is there any chance they will got to 2.6.26? > > > > I'm not sure. I didn't have the time to look at it myself, but I am > > under the impression that the powerpc folks are tired of having to wait > > for me and may push it to Linus through their tree? That would be fine > > with me, as I don't want to be the one delaying something many > > developers want (but I also can't sign patches I've not even read.) The patches are required for long awaited I2C support on various PowerPC boards. As the ppc architecture support is going away in 2.6.27, it would be nice to have them applied in 2.6.26. > The required patches are: > > http://patchwork.ozlabs.org/linuxppc/patch?id=17833 > http://patchwork.ozlabs.org/linuxppc/patch?id=17834 > > which are just the forward ported patches you sent to the poweprc mailing > list some time ago: > > http://patchwork.ozlabs.org/linuxppc/patch?id=16282 > http://patchwork.ozlabs.org/linuxppc/patch?id=16283 > > Thanks, > Jochen -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpvzrMvppmyt.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci issue - wrong detection of pci ressources
Benjamin Herrenschmidt wrote: Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources. And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem. Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ? Hrm... I was expecting to see a lot more output here, make sure you have "debug" on your command line (or enable early debug output, same effect). There is nothing more even with debug in kernel command line. But I added some printk's around the resource handling to get a better feeling what's happening. I attached the new extended bootlog and the patch with the printk's for a better understanding where which message is printed. I tried to understand how I might e.g. increase the number of available resources or their size, but unfortunately that is not the simplest code when working with it the first time ;-) Cheers, Ben. For comparison I defined DEBUG in the good kernel (arch=ppc) and that is what the initialization prints (pci ...:0a:1 is the secondary head of the same graphic card an it's not an issue if thats not allocated): good case: PCI: Probing PCI hardware PCI: bridge rsrc 0.. (100), parent c0354624 PCI: bridge rsrc 8000..8fff (200), parent c0354608 PCI::00:0a.0: Resource 0: 8800-8fff (f=1208) PCI::00:0a.0: Resource 1: ff00- (f=101) PCI::00:0a.0: Resource 2: 87ff-87ff (f=200) PCI::00:0a.1: Resource 0: 7800-7fff (f=1208) PCI: Cannot allocate resource region 0 of device :00:0a.1 PCI::00:0a.1: Resource 1: 77ff-77ff (f=200) PCI: Cannot allocate resource region 1 of device :00:0a.1 PCI: Failed to allocate mem resource #0:[EMAIL PROTECTED] for :00:0a.1 -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x00018000..0x00018fff -> 0x8000 IO 0x0001e800..0x0001e80f -> 0x 4xx PCI DMA offset set to 0x PCI: Probing PCI hardware PCI: Hiding 4xx host bridge resources :00:00.0 Try to map irq for :00:00.0... -> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2 -> mapped to linux irq 16 Try to map irq for :00:0a.0... -> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2 -> mapped to linux irq 16 Try to map irq for :00:0a.1... PCI: PHB (bus 0) bridge rsrc 0: -000f [0x100], parent c0365060 (PCI IO) __request_resource - request cf8045b0 name '/plb/[EMAIL PROTECTED]' start 0x0 end 0x0 __request_resource - no conflict parent c0365060 sibling PCI: PHB (bus 0) bridge rsrc 1: 00018000-00018fff [0x200], parent c0365038 (PCI mem) __request_resource - request cf8045d8 name '/plb/[EMAIL PROTECTED]' start 0x1 end 0x8000 __request_resource - no conflict parent c0365038 sibling PCI: Assigning unassigned resouces... pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_assign_resource - second pci_bus_alloc_resource call pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1 find_resource - size 0, min 0x800, max 0x1 find_resource - found start 0x1 end 0x8000 __request_resource - request cf810578 name ':00:0a.0' start 0x1 end 0x8000 __request_resource - no conflict parent cf8045d8 sibling pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_assign_resource - second pci_bus_alloc_resource call pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1 find_resource - size 0, min 0x800, max 0x1 find_resource - continue with start 0x1 on 8800 find_resource - found start 0x1 end 0x8800 __request_resource - request cf810178 name ':00:0a.1' start 0x1 end 0x8800 __request_resource - no conflict parent cf8045d8 sibling pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_assign_resource - second pci_bus_alloc_resource call pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 131072, align -1 find_resource - size 0, min 0x2, max 0x1 find_resource - continue with start 0x1 on 8800 find_resource - continue with start 0x1 on 9000 find_resource - no this - exit PCI: pci_assign_resource - Failed to allocate mem resource #6:[EMAIL PROTECTED] for :00:0a.0 pci_assign_resource - allocate with IORESOURCE_PREFETCH pci_bus_alloc_resource - enter pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1 find_resource - size 0, m
Re: linux-next: x86-latest/powerpc-next merge conflict
On Mon, 21 Apr 2008 13:19:50 +0200, "Alexander van Heukelum"
<[EMAIL PROTECTED]> said:
> On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" <[EMAIL PROTECTED]> said:
> > * Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> >
> > > Hi all,
> > >
> > > Today's linux-next merge of the x86-latest tree got a conflict in
> > > include/asm-powerpc/bitops.h between commit
> > > cd008c0f03f3d451e5fbd108b8e74079d402be64 ("generic: implement __fls on
> > > all 64-bit archs") from the x86-latest tree and commit
> > > 9f264be6101c42cb9e471c58322fb83a5cde1461 ("[POWERPC] Optimize fls64()
> > > on 64-bit processors") from the powerpc-next tree. The fixup was not
> > > quite trivial and is worth a look to see if I got it right.
>
> [...]
>
> I've tried to take a look if you got it right, but the linux-next tree
> on git.kernel.org is 5 days old. If that's the current state then it's
> not merged right ;).
And it just started showing the new version. The merge went fine.
> Greetings,
> Alexander
>
> > Paul, do you agree with those generic bitops changes? Just in case it's
> > not obvious from previous discussions: we'll push them upstream via a
> > separate pull request, not via usual x86.git changes. They originated
> > from x86.git but grew into a more generic improvement for all. They sit
> > in x86.git for tester convenience but are of course not pure x86 changes
> > anymore.
> >
> > Ingo
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - A fast, anti-spam email service.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: x86-latest/powerpc-next merge conflict
On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" <[EMAIL PROTECTED]> said:
>
> * Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the x86-latest tree got a conflict in
> > include/asm-powerpc/bitops.h between commit
> > cd008c0f03f3d451e5fbd108b8e74079d402be64 ("generic: implement __fls on
> > all 64-bit archs") from the x86-latest tree and commit
> > 9f264be6101c42cb9e471c58322fb83a5cde1461 ("[POWERPC] Optimize fls64()
> > on 64-bit processors") from the powerpc-next tree. The fixup was not
> > quite trivial and is worth a look to see if I got it right.
Powerpc would pick up an optimized version via this chain: generic fls64
->
powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r"
(x)).
However, the generic version of fls64 first tests the argument for zero.
From
your code I derive that the count-leading-zeroes instruction for
argument zero
is defined as cntlzl(0) == BITS_PER_LONG. In that case the explicit test
for zero is not needed, which makes the powerpc-specific one added here
an improvement over the generic one.
I've tried to take a look if you got it right, but the linux-next tree
on git.kernel.org is 5 days old. If that's the current state then it's
not merged right ;).
Greetings,
Alexander
> Paul, do you agree with those generic bitops changes? Just in case it's
> not obvious from previous discussions: we'll push them upstream via a
> separate pull request, not via usual x86.git changes. They originated
> from x86.git but grew into a more generic improvement for all. They sit
> in x86.git for tester convenience but are of course not pure x86 changes
> anymore.
>
> Ingo
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - A fast, anti-spam email service.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
Hi, Michael,
Thank you very much for you input, please see my inline answer.
B.R
Jason
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 21, 2008 2:22 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org; Gala Kumar
> Subject: Re: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
>
> > This MSI driver can be used on 83xx/85xx/86xx board.
> > In this driver, virtual interrupt host and chip were
> > setup. There are 256 MSI interrupts in this host, Every 32
> > MSI interrupts cascaded to one IPIC/MPIC interrupt.
> > The chip was treated as edge sensitive and some necessary
> > functions were setup for this chip.
> >
> > Before using the MSI interrupt, PCI/PCIE device need to
> > ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
> > bitmap show which MSI interrupt was used, reserve bit in
> > the bitmap can be used to force the device use some designate
> > MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
> > for testing the all the MSI interrupts. The msi-available-ranges
> > property in the dts file was used for this purpose.
>
>
> Hi Jason, some comments inline ...
>
>
> > diff --git a/arch/powerpc/sysdev/Makefile
> b/arch/powerpc/sysdev/Makefile
> > index 6d386d0..bfd3fe4 100644
> > --- a/arch/powerpc/sysdev/Makefile
> > +++ b/arch/powerpc/sysdev/Makefile
> > @@ -4,6 +4,7 @@ endif
> >
> > mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o
> mpic_u3msi.o mpic_pasemi_msi.o
> > obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
> > +obj-$(CONFIG_PCI_MSI) += fsl_msi.o
>
> Do we really always want to build this if we have MSI? Might it depend
> on something else as well? CONFIG_FSL_PCI maybe?
>
I'll try to change the depend.
> > diff --git a/arch/powerpc/sysdev/fsl_msi.c
> b/arch/powerpc/sysdev/fsl_msi.c
> > new file mode 100644
> > index 000..e8132cf
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/fsl_msi.c
> > @@ -0,0 +1,457 @@
> > +/*
> > + * Copyright (C) 2007-2008 Freescale Semiconductor, Inc.
> All rights reserved.
> > + *
> > + * Author: Tony Li <[EMAIL PROTECTED]>
> > + *Jason Jin <[EMAIL PROTECTED]>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; version 2 of the
> > + * License.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include "fsl_msi.h"
>
> People consider it good style to have the linux includes before the
> asm includes.
>
OK
> > +#ifdef DEBUG
> > +#define pr_debug(fmt...) printk(fmt)
> > +#else
> > +#define pr_debug(fmt...)
> > +#endif
>
> Please don't do this, just use pr_debug(). In fact I don't
> see where you
> do use it :)
>
OK.
> > +/* A bit ugly, can we get this from the pci_dev somehow? */
> > +static struct fsl_msi *fsl_msi;
>
> I recognise that comment :) The answer is "no" we can't (easily) get
> this from the pci_dev.
>
> > +static inline u32 fsl_msi_read(u32 __iomem *base,
> > + unsigned int reg)
>
> This would fit in 80 chars wouldn't it?
>
OK
> > +{
> > + return in_be32(base + (reg >> 2));
> > +}
> > +
> > +static inline void fsl_msi_write(u32 __iomem *base,
> > + unsigned int reg, u32 value)
> > +{
> > + out_be32(base + (reg >> 2), value);
> > +}
> > +
> > +#definefsl_msi_irq_to_hw(virq) ((unsigned
> int)irq_map[virq].hwirq)
>
> I can't see where this is used, you probably don't need it.
>
I'll remove this.
> > +/*
> > + * We do not need this actually. The MSIR register has
> been read once
> > + * in the cascade interrupt. So, this MSI interrupt has been acked
> > +*/
> > +static void fsl_msi_end_irq(unsigned int virq)
> > +{
> > +}
>
> I guess the generic code assumes you have an ack, bummer.
>
Yes, the generic code did not check it.
> > +static struct irq_chip fsl_msi_chip = {
> > + .mask = mask_msi_irq,
> > + .unmask = unmask_msi_irq,
> > + .ack= fsl_msi_end_irq,
> > + .typename = " FSL-MSI ",
>
> I'd rather you didn't try and pad the name by hand, if we
> want /proc/interrupts
> to look pretty we should do that in show_interrupts().
>
Thanks, but I feel it's easier and cleaner to add the typename here to
make
the /proc/interrupts clear.
> > +static int fsl_msi_host_match(struct irq_host *h, struct
> device_node *node)
> > +{
> > + struct fsl_msi *msi = h->host_data;
> > +
> > + /* Exact match, unless node is NULL */
> > + return msi->of_node == NULL || msi->of_node == node;
> > +}
>
> Do you really want the MSI to be the default irq host?
>
Thanks. I'll change the host match function.
> > +static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
> > + irq_hw_number_t hw)
> > +{
