Re: State of the MPC5200 PSC AC97 driver
Hi Matt, On Thu, Apr 10, 2008 at 04:25:20PM +0100, Matt Sealey wrote: > I have a copy of the driver I hacked to work with the new PSC > framework but it doesn't "work" anymore - I have no idea why. > > Mail me privately if you want it, I have no time to make patches or > look for a good reason for the breakages, but it compiles at least. > The Efika hack should be gone now (irrelevant since we released a > firmware that obseletes it) and the other fixmes should be by the > wayside considering the fscking thing doesn't play sound anymore... I'd be interested as well; do I read your mail right that you have already managed to hear sound coming out of the MPC5200B PSC AC97 interface? You would be the first one I've heared of, so it would definitely be interesting to see your code. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v5] Add idle wait support for 44x platforms
On Fri, Apr 11, 2008 at 02:18:22AM +0200, Arnd Bergmann wrote: > On Thursday 10 April 2008, Jerone Young wrote: > > Well it could be this simple. But the current code leaves a lot more > > room to add different type waits or spins if need be (if they are ever > > needed ... though none off the top of my head at the moment)...but it > > does allow you to create another wait state for whatever reason a lot > > easier. > > > > So I really don't think this needs to change. Unless everyone really > > feels that it just has to be. > > No, it doesn't need to change, the current patch is entirely correct, > just a little bit more complicated than it needs to be, and I try > not to have code in anticipation of something getting more complicated > in the future, you can always add the complexity at the point where you > need it. That piece of code came across from the platforms/pasemi version, where we for a while had more than two kinds of idle loops (doze/nap/sleep/rvwinkle). Turns out doze does well enough that the others weren't really needed so I never submitted support for the deeper sleep modes. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
In message: Re: [PATCH 0/5] dynamic detection of gianfar TPIPA on 10/04/2008 Andy Fleming wrote: > > I may be missing something, but I don't think this quite right. > > If you have a PHY at 0x1f, this patchset will cause no PHY device to be > allocated for that address, and you'll actually end up assigning TBIPA to > be 0x1f again, since there's no PHY there. Right? Were you able to use > this code with a PHY at 0x1f? I tested on several "normal" boards and on a board with the PHY @ 0x1f, and it did what I expected it to do. It was when I was testing on the normal boards (8540MDS, 8360MDS, HPCN) that I observed we were showing a PHY ID of 0x0 at 0x1f during the routine PHY scan, because the autodetect code was skipping 0x1f even on those boards. I backed out all my patches and the situation was the same, hence why I decided to skip IDs of either 0x or 0x0. > I like the idea of passing around priv->mii_bus instead of regs, but I > think it won't work without becoming unnecessarily unwieldy. The > problem is that the TBI PHY is not necessarily accessed through the same > bus as the PHY. Each controller has its own TBI PHY, and that PHY can > only be accessed from *that* controller's MDIO bus. So if you want to > configure TSEC2's TBI PHY, you use TSEC2's MDIO regs. That's what > gfar_local_mdio_* allowed; they write the *local* controller's MDIO regs. > It looks like this code sets up priv->mii_bus to point at the bus which > holds the PHY, but only TSEC0's bus (on most SoCs) is connected to actual > PHYs. So you will only ever be able to configure the TBI PHY on TSEC0, > which will not allow any of the other TSECs to use an SGMII PHY. Were > you able to use other TSECs to connect to an SGMII PHY? Okay -- that explanation helps me understand the role of the *_local_* variants -- it wasn't obvious to me that they were being used to jump the device --> bus association and go right at MDIO bus of tsec0. I think this can still be handled sanely though -- we'd have to simply say that if you wanted the bus of the TBI of the controller, you would go at dev->priv->mii_bus, and if you wanted the bus of the PHY of the controller, you'd go at dev->priv->phydev->bus. I'd have to think a bit to see if that would afford the same or similar cleanups, but the distinction at least seems clearer to me now. > We could still pass around an mii_bus reference, but this would require > creating an mii_bus instance for every single TSEC, which is a little > heavyweight when we just want to configure the TBI PHY once on startup. Yep. Is there any boards out there with more than 4 tsec? I'd have to go look at the size of mii_bus to see what the per bus cost is. > > After some thinking, I went ahead and implemented a patch which isn't > ideal, but should solve the problems your patches set out to solve. > I've sent it in a separate message. If you have some systems with SGMII > and/or a PHY at 0x1f, please test this patch on them. I don't currently > have either. I'll go have a look. I've only got the SBC8641D with the PHY @ 0x1f to be the oddball guniea pig. Paul. > > Andy > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
Kumar Gala wrote: but there is no reason not to make it work properly. For example I believe libata uses devm_* and the fsl SATA driver (non-PCI) will need to work in cases similar to the 44x. Well, as for sata_fsl, it calls of_iomap() which does The Right Thing. Fair, but I don't see why we should introduce new APIs that are already "broken". We went through a lot of effort to clean up and introduce resource_t (and clearly still have some bugs) for the >32-bit physical address problem. Yes, please go ahead. In case it wasn't clear, I wasn't objecting to the fix at all. I was just curious what could actually happen on x86. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc TLF_RESTORE_SIGMASK
On Thu, 10 Apr 2008 18:36:35 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]> wrote: > > This crashes my powerpc mac g5. > > It worked fine on mine. > > > It happens after the boot, during the first login-over-ssh. > > Mine did lots of stuff fine. > > > This is with most of the rest of the -mm poopile applied. i386 and x86_64 > > seem OK. > > I had only tested with Linus's tree plus the small handful of post-2.6.25 > cleanup patches I've posted in the last few weeks. To be precise it was > 9597362d354f8655ece324b01d0c640a0e99c077 plus several of my cleanup patches > (that are probably all in -mm, but I'm not sure off hand). > > I'd rebased my tree today to 783e391b7b5b273cd20856d8f6f4878da8ec31b3 > anyway. I just tried the new kernel with the sigmask cleanups and only > a few other patches, and have no problems. > > The details of your crash make it look pretty unrelated to this code. > Off hand I would guess that it's some other bug from other -mm patches > that just happens only to bite you on powerpc. If the crash is not > intermittent and you bisected it to this one change, then I am at a > loss to see what might be happening. I'd have to leave it to Paul et > al to figure out if there is some strange powerpc juju going on. It's 100% repeatable and I bisected it to this change. I expect you could repeat it by applying it to http://userweb.kernel.org/~akpm/mmotm/ (or to -rc6-mm2, if I ever manage to get it to boot on something) and using http://userweb.kernel.org/~akpm/config-g5.txt ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: Add support for Wind River SBC8641D board
On Thu, Apr 10, 2008 at 07:22:17PM -0400, Paul Gortmaker wrote:
> This adds support for the Wind River SBC8641D board, based
> largely on the mpc86xx_hpcn support. The biggest difference is
> the lack of the Uli and the i8259 cascade, which simplifies things.
Hi Paul,
A couple issues. (These should be fixed in the mpc86xx_hpcn.c as well.)
> +void __init
> +sbc8641_init_irq(void)
Make this function static.
> +void
> +sbc8641_show_cpuinfo(struct seq_file *m)
This one too.
> +static int __init sbc8641_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (of_flat_dt_is_compatible(root, "mpc86xx"))
"mpc86xx" is too generic. You should make the compatible field
in your devtree something like "WIND,sbc8641d", to differentiate
it from the mpc86xx_hpcn.
> +long __init
> +mpc86xx_time_init(void)
Another static function.
Regards,
-Dale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc TLF_RESTORE_SIGMASK
> This crashes my powerpc mac g5. It worked fine on mine. > It happens after the boot, during the first login-over-ssh. Mine did lots of stuff fine. > This is with most of the rest of the -mm poopile applied. i386 and x86_64 > seem OK. I had only tested with Linus's tree plus the small handful of post-2.6.25 cleanup patches I've posted in the last few weeks. To be precise it was 9597362d354f8655ece324b01d0c640a0e99c077 plus several of my cleanup patches (that are probably all in -mm, but I'm not sure off hand). I'd rebased my tree today to 783e391b7b5b273cd20856d8f6f4878da8ec31b3 anyway. I just tried the new kernel with the sigmask cleanups and only a few other patches, and have no problems. The details of your crash make it look pretty unrelated to this code. Off hand I would guess that it's some other bug from other -mm patches that just happens only to bite you on powerpc. If the crash is not intermittent and you bisected it to this one change, then I am at a loss to see what might be happening. I'd have to leave it to Paul et al to figure out if there is some strange powerpc juju going on. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc64 build issue
Hi Kumar, On Thu, 10 Apr 2008 10:01:27 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > > anyone looking into this? > > http://kisskb.ellerman.id.au/kisskb/buildresult/23299/ > > Its really a Kconfig issue. Just posted a patch. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpeFP09h3snx.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix MAX_ORDER config problem
The allyesconfig (among others) build was giving this: In file included from include/linux/gfp.h:4, from include/linux/slab.h:14, from include/linux/percpu.h:5, from include2/asm/time.h:18, from include2/asm/cputime.h:26, from include/linux/sched.h:67, from arch/powerpc/kernel/asm-offsets.c:17: include/linux/mmzone.h:791:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Kconfig options are order depenendent, so move the setting of FORCE_MAX_ZONEORDER to after the setting of PPC_64K_PAGES. Also add an explicit !PPC_64K_PAGES. Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig | 40 1 files changed, 20 insertions(+), 20 deletions(-) Paul, this is a bug in the powerpc next tree. diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 625342e..1d4d19f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -211,26 +211,6 @@ source kernel/Kconfig.hz source kernel/Kconfig.preempt source "fs/Kconfig.binfmt" -config FORCE_MAX_ZONEORDER - int "Maximum zone order" - default "9" if PPC_64K_PAGES - default "13" if PPC64 - default "11" - help - The kernel memory allocator divides physically contiguous memory - blocks into "zones", where each zone is a power of two number of - pages. This option selects the largest power of two that the kernel - keeps in the memory allocator. If you need to allocate very large - blocks of physically contiguous memory, then you may need to - increase this value. - - This config option is actually maximum order plus one. For example, - a value of 11 means that the largest free memory block is 2^10 pages. - - The page size is not necessarily 4KB. For example, on 64-bit - systems, 64KB pages can be enabled via CONFIG_PPC_64K_PAGES. Keep - this in mind when choosing a value for this option. - config HUGETLB_PAGE_SIZE_VARIABLE bool depends on HUGETLB_PAGE @@ -403,6 +383,26 @@ config PPC_64K_PAGES while on hardware with such support, it will be used to map normal application pages. +config FORCE_MAX_ZONEORDER + int "Maximum zone order" + default "9" if PPC_64K_PAGES + default "13" if PPC64 && !PPC_64K_PAGES + default "11" + help + The kernel memory allocator divides physically contiguous memory + blocks into "zones", where each zone is a power of two number of + pages. This option selects the largest power of two that the kernel + keeps in the memory allocator. If you need to allocate very large + blocks of physically contiguous memory, then you may need to + increase this value. + + This config option is actually maximum order plus one. For example, + a value of 11 means that the largest free memory block is 2^10 pages. + + The page size is not necessarily 4KB. For example, on 64-bit + systems, 64KB pages can be enabled via CONFIG_PPC_64K_PAGES. Keep + this in mind when choosing a value for this option. + config PPC_SUBPAGE_PROT bool "Support setting protections for 4k subpages" depends on PPC_64K_PAGES -- 1.5.4.5 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v5] Add idle wait support for 44x platforms
On Fri, 2008-04-11 at 02:18 +0200, Arnd Bergmann wrote:
> > > static int __init idle_param(char *p)
> > > {
> > > if (!strcmp(modes[i].name, "spin"))
> > > ppc_md.power_save = NULL;
> > > }
> > > early_param("idle", idle_param);
> > >
> > > if you statically initialize the ppc_md.power_save function to ppc44x_idle
> > > in the platform setup files?
> >
> > The idea is to not statically initialize ppc_md.power_save to
> > ppc44x_idle in each platform setup file.
> >
>
> Why not? Unlike the platform_initcall, it wouldn't cost anything and your
> current code has the same effect in the end, but in a less obvious way.
This is likely something that has evolved from the original patch which
added a machine_late_initcall(, ppc44x_idle_init) to every
platform.c file. It made the original patch overly complicated as
opposed to adding a single arch_initcall in a common file. That was
also before we decided to make "wait" the default, which made things
much easier to deal with.
I'll take the blame for the way the minorly suboptimal state the patch
is, as Jerone had to jump through several hoops already at my request.
I agree it's cleaner to do as you suggest in the long run, and may well
make some changes along those lines myself.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: Add support for Wind River SBC8641D board
On Fri, 2008-04-11 at 10:05 +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> Just a couple of comments.
>
> On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/platforms/86xx/sbc8641d.c
> > +#undef DEBUG
> > +
> > +#ifdef DEBUG
> > +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
>
> Not KERN_DEBUG? Also, if you include linux/kernel.h you can use pr_debug()
> instead.
s/Also, if you include/Please include/
We don't need more hand-rolled debug macros :)
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] [v5] Add idle wait support for 44x platforms
On Thursday 10 April 2008, Jerone Young wrote:
> Well it could be this simple. But the current code leaves a lot more
> room to add different type waits or spins if need be (if they are ever
> needed ... though none off the top of my head at the moment)...but it
> does allow you to create another wait state for whatever reason a lot
> easier.
>
> So I really don't think this needs to change. Unless everyone really
> feels that it just has to be.
No, it doesn't need to change, the current patch is entirely correct,
just a little bit more complicated than it needs to be, and I try
not to have code in anticipation of something getting more complicated
in the future, you can always add the complexity at the point where you
need it.
> >
> > static int __init idle_param(char *p)
> > {
> > if (!strcmp(modes[i].name, "spin"))
> > ppc_md.power_save = NULL;
> > }
> > early_param("idle", idle_param);
> >
> > if you statically initialize the ppc_md.power_save function to ppc44x_idle
> > in the platform setup files?
>
> The idea is to not statically initialize ppc_md.power_save to
> ppc44x_idle in each platform setup file.
>
Why not? Unlike the platform_initcall, it wouldn't cost anything and your
current code has the same effect in the end, but in a less obvious way.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: Add support for Wind River SBC8641D board
Hi Paul,
Just a couple of comments.
On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/platforms/86xx/sbc8641d.c
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
Not KERN_DEBUG? Also, if you include linux/kernel.h you can use pr_debug()
instead.
> +sbc8641_init_irq(void)
> +{
> + struct mpic *mpic1;
> + struct device_node *np;
> + struct resource res;
> +
> + /* Determine PIC address. */
> + np = of_find_node_by_type(NULL, "open-pic");
> + if (np == NULL)
> + return;
> + of_address_to_resource(np, 0, &res);
> +
> + /* Alloc mpic structure and per isu has 16 INT entries. */
> + mpic1 = mpic_alloc(np, res.start,
> + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> + 0, 256, " MPIC ");
> + BUG_ON(mpic1 == NULL);
> +
> + mpic_init(mpic1);
You need an of_node_put(np) in here somewhere (probably after the mpic_alloc).
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpfQKgnHez3S.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] CPM: Always use new binding.
On Apr 10, 2008, at 3:45 PM, Scott Wood wrote: The kconfig entry can go away once arch/ppc and references to the config in drivers are removed. just to be clear. arch/powerpc will always just use the new binding and arch/ppc uses the old (or has the option)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/5] dynamic detection of gianfar TPIPA
This patch series consists of some minor cleanups that eventually allow us to implement a dynamic assignment of the gianfar TBIPA. This was the implementation that Andy and Scott indicated was the most desireable solution at the bottom of this discussion: http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=12902 The lead up patches are as follows: -dont allocate a phydev for the "ghost" phy that seems to appear on ID 0x1f of all the MDIO bus scans. -add in the missing assignment to priv->mii_bus when we assign a phy to the device. -cleanup of unnecessary externs that the above change allows us. -make the mii_bus->priv point to struct gianfar_mdio_data At this point, we can then actually use the phy_map of the mii_bus to tell us which MDIO ID we can use for the TBIPA, instead of just hard coding 0x1f. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Fix kernel stack allocation alignment
The powerpc kernel stacks need to be naturally aligned, as they
contain the thread info at the bottom, which is obtained by
clearing the low bits of the stack pointer.
However, when using 64K pages (the stack is smaller than a page),
we use kmalloc to allocate it, which doesn't provide that guarantee.
It appeared to work so far... until one enables SLUB debugging
which then returns unaligned pointers. Ooops...
This patch fixes it by using a slab cache with enforced alignment
for those. It replies on my previous patch that adds a
thread_info_cache_init() callback.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
Note that m32r seems to also have this problem.
arch/powerpc/kernel/process.c | 31 +++
include/asm-powerpc/thread_info.h | 10 --
2 files changed, 35 insertions(+), 6 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/process.c 2008-04-10
13:11:05.0 +1000
+++ linux-work/arch/powerpc/kernel/process.c2008-04-10 13:14:29.0
+1000
@@ -1052,3 +1052,34 @@ void ppc64_runlatch_off(void)
}
}
#endif
+
+#if THREAD_SHIFT < PAGE_SHIFT
+
+static struct kmem_cache *thread_info_cache;
+
+struct thread_info *alloc_thread_info(struct task_struct *tsk)
+{
+ struct thread_info *ti;
+
+ ti = kmem_cache_alloc(thread_info_cache, GFP_KERNEL);
+ if (unlikely(ti == NULL))
+ return NULL;
+#ifdef CONFIG_DEBUG_STACK_USAGE
+ memset(ti, 0, THREAD_SIZE);
+#endif
+ return ti;
+}
+
+void free_thread_info(struct thread_info *ti)
+{
+ kmem_cache_free(thread_info_cache, ti);
+}
+
+void thread_info_cache_init(void)
+{
+ thread_info_cache = kmem_cache_create("thread_info", THREAD_SIZE,
+ THREAD_SIZE, 0, NULL);
+ BUG_ON(thread_info_cache == NULL);
+}
+
+#endif /* THREAD_SHIFT < PAGE_SHIFT */
Index: linux-work/include/asm-powerpc/thread_info.h
===
--- linux-work.orig/include/asm-powerpc/thread_info.h 2008-04-10
13:11:05.0 +1000
+++ linux-work/include/asm-powerpc/thread_info.h2008-04-10
13:14:47.0 +1000
@@ -80,12 +80,10 @@ struct thread_info {
#else /* THREAD_SHIFT < PAGE_SHIFT */
-#ifdef CONFIG_DEBUG_STACK_USAGE
-#define alloc_thread_info(tsk) kzalloc(THREAD_SIZE, GFP_KERNEL)
-#else
-#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL)
-#endif
-#define free_thread_info(ti) kfree(ti)
+extern struct thread_info *alloc_thread_info(struct task_struct *tsk);
+extern void free_thread_info(struct thread_info *ti);
+extern void thread_info_cache_init(void);
+#define thread_info_cache_init thread_info_cache_init
#endif /* THREAD_SHIFT < PAGE_SHIFT */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] Add thread_info_cache_init() to all archs
Some architecture need to maintain a kmem cache for thread info
structures. (next patch adds that to powerpc to fix an alignment
problem).
There is no good arch callback to use to initialize that cache
that I can find, so this adds a new one and adds an empty macro
for when it's not implemented.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
So we have the choice here between:
- the ifdef on the func name that I did, consistent with what
I did before for iomap, which iirc Linus liked
- add some more ARCH_HAS_* or HAVE_* (yuck)
- add an empty definition to all archs .h (pain in the neck but I
can do it, though it will be an annoying patch to keep around)
- do a weak function (will slightly bloat everybody for no good reason)
So unless there is strong complaints, I'd like to stick to my
current approach.
(This one fixes a stupid typo, missing () in the macro def.)
include/linux/sched.h |4
init/main.c |1 +
2 files changed, 5 insertions(+)
--- linux-work.orig/init/main.c 2008-04-10 13:11:06.0 +1000
+++ linux-work/init/main.c 2008-04-10 13:11:19.0 +1000
@@ -623,6 +623,7 @@ asmlinkage void __init start_kernel(void
if (efi_enabled)
efi_enter_virtual_mode();
#endif
+ thread_info_cache_init();
fork_init(num_physpages);
proc_caches_init();
buffer_init();
Index: linux-work/include/linux/sched.h
===
--- linux-work.orig/include/linux/sched.h 2008-04-10 13:11:44.0
+1000
+++ linux-work/include/linux/sched.h2008-04-11 09:35:58.0 +1000
@@ -1893,6 +1893,10 @@ static inline unsigned long *end_of_stac
#endif
+#ifndef thread_info_cache_init
+#define thread_info_cache_init() do { } while(0)
+#endif
+
/* set thread flags in other task's structures
* - see asm/thread_info.h for TIF_ flags available
*/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2.6.26] gianfar: Determine TBIPA value dynamically
TBIPA needs to be set to a value (on connected MDIO buses) that doesn't
conflict with PHYs on the bus. By hardcoding it to 0x1f, we were preventing
boards with PHYs at 0x1f from working properly. Instead, scan the bus when
it comes up, and find an address that doesn't have a PHY on it. The TBI PHY
configuration code then trusts that the value in TBIPA is either safe, or
doesn't matter (ie - it's not an active bus with other PHYs).
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
I think this should go in, but I'd like to see some testing first. I don't
have hardware which is affected by this. I've only confirmed that it doesn't
break current hardware.
drivers/net/gianfar.c | 25 +--
drivers/net/gianfar_mii.c | 47
drivers/net/gianfar_mii.h |3 ++
3 files changed, 59 insertions(+), 16 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index c8c3df7..6661015 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -476,24 +476,30 @@ static int init_phy(struct net_device *dev)
return 0;
}
+/*
+ * Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * "normal" PHY at the address found in the TBIPA register. We assume
+ * that the TBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
static void gfar_configure_serdes(struct net_device *dev)
{
struct gfar_private *priv = netdev_priv(dev);
struct gfar_mii __iomem *regs =
(void __iomem *)&priv->regs->gfar_mii_regs;
+ int tbipa = gfar_read(&priv->regs->tbipa);
- /* Initialise TBI i/f to communicate with serdes (lynx phy) */
+ /* Single clk mode, mii mode off(for serdes communication) */
+ gfar_local_mdio_write(regs, tbipa, MII_TBICON, TBICON_CLK_SELECT);
- /* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
-
- /* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_local_mdio_write(regs, tbipa, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
- /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_local_mdio_write(regs, tbipa, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -540,9 +546,6 @@ static void init_registers(struct net_device *dev)
/* Initialize the Minimum Frame Length Register */
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
-
- /* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
}
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index b889892..e061738 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -78,7 +78,6 @@ int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int
mii_id,
* same as system mdio bus, used for controlling the external PHYs, for eg.
*/
int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum)
-
{
u16 value;
@@ -122,7 +121,7 @@ int gfar_mdio_read(struct mii_bus *bus, int mii_id, int
regnum)
}
/* Reset the MIIM registers, and wait for the bus to free */
-int gfar_mdio_reset(struct mii_bus *bus)
+static int gfar_mdio_reset(struct mii_bus *bus)
{
struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
unsigned int timeout = PHY_INIT_TIMEOUT;
@@ -152,14 +151,15 @@ int gfar_mdio_reset(struct mii_bus *bus)
}
-int gfar_mdio_probe(struct device *dev)
+static int gfar_mdio_probe(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct gianfar_mdio_data *pdata;
struct gfar_mii __iomem *regs;
+ struct gfar __iomem *enet_regs;
struct mii_bus *new_bus;
struct resource *r;
- int err = 0;
+ int i, err = 0;
if (NULL == dev)
return -EINVAL;
@@ -199,6 +199,43 @@ int gfar_mdio_probe(struct device *dev)
new_bus->dev = dev;
dev_set_drvdata(dev, new_bus);
+ /*
+* This is mildly evil, but so is our hardware for doing this.
+* Also, we have to cast back to struct gfar_mii because of
+* definition weirdness done in gianfar.h.
+*/
+ enet_regs = (struct gfar __iomem *)
+ ((char *)regs - offsetof(struct gfar, gfar_mii_regs));
+
+ /* Scan the bus, looking for
Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
On Apr 10, 2008, at 12:51, Paul Gortmaker wrote: This patch series consists of some minor cleanups that eventually allow us to implement a dynamic assignment of the gianfar TBIPA. This was the implementation that Andy and Scott indicated was the most desireable solution at the bottom of this discussion: http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=12902 The lead up patches are as follows: -dont allocate a phydev for the "ghost" phy that seems to appear on ID 0x1f of all the MDIO bus scans. -add in the missing assignment to priv->mii_bus when we assign a phy to the device. -cleanup of unnecessary externs that the above change allows us. -make the mii_bus->priv point to struct gianfar_mdio_data At this point, we can then actually use the phy_map of the mii_bus to tell us which MDIO ID we can use for the TBIPA, instead of just hard coding 0x1f. I may be missing something, but I don't think this quite right. If you have a PHY at 0x1f, this patchset will cause no PHY device to be allocated for that address, and you'll actually end up assigning TBIPA to be 0x1f again, since there's no PHY there. Right? Were you able to use this code with a PHY at 0x1f? I like the idea of passing around priv->mii_bus instead of regs, but I think it won't work without becoming unnecessarily unwieldy. The problem is that the TBI PHY is not necessarily accessed through the same bus as the PHY. Each controller has its own TBI PHY, and that PHY can only be accessed from *that* controller's MDIO bus. So if you want to configure TSEC2's TBI PHY, you use TSEC2's MDIO regs. That's what gfar_local_mdio_* allowed; they write the *local* controller's MDIO regs. It looks like this code sets up priv->mii_bus to point at the bus which holds the PHY, but only TSEC0's bus (on most SoCs) is connected to actual PHYs. So you will only ever be able to configure the TBI PHY on TSEC0, which will not allow any of the other TSECs to use an SGMII PHY. Were you able to use other TSECs to connect to an SGMII PHY? We could still pass around an mii_bus reference, but this would require creating an mii_bus instance for every single TSEC, which is a little heavyweight when we just want to configure the TBI PHY once on startup. After some thinking, I went ahead and implemented a patch which isn't ideal, but should solve the problems your patches set out to solve. I've sent it in a separate message. If you have some systems with SGMII and/or a PHY at 0x1f, please test this patch on them. I don't currently have either. Andy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/5] gianfar: don't hard code the TBIPA MDIO address
Currently the MDIO address for the gianfar Ten Bit
Interface is hard coded to be 0x1f, which can conflit
with some boards if they happen to put a PHY there.
Previous discussions indicated that the proper approach
here would be to dynamically allocate it, based on
picking the highest MDIO address that is not in use
by a PHY.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c | 20
drivers/net/gianfar.h |1 -
drivers/net/gianfar_mii.c | 11 ++-
include/linux/fsl_devices.h |1 +
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 9173784..684c97b 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -123,6 +123,7 @@ static irqreturn_t gfar_transmit(int irq, void *dev_id);
static irqreturn_t gfar_interrupt(int irq, void *dev_id);
static void adjust_link(struct net_device *dev);
static void init_registers(struct net_device *dev);
+static void gfar_set_tbipa(struct net_device *dev);
static int init_phy(struct net_device *dev);
static int gfar_probe(struct platform_device *pdev);
static int gfar_remove(struct platform_device *pdev);
@@ -469,6 +470,8 @@ static int init_phy(struct net_device *dev)
priv->mii_bus = phydev->bus;
priv->phydev = phydev;
+ gfar_set_tbipa(dev);
+
if (interface == PHY_INTERFACE_MODE_SGMII)
gfar_configure_serdes(dev);
@@ -479,19 +482,20 @@ static void gfar_configure_serdes(struct net_device *dev)
{
struct gfar_private *priv = netdev_priv(dev);
struct mii_bus *bus = priv->mii_bus;
+ struct gianfar_mdio_data *mdata = (struct gianfar_mdio_data *)bus->priv;
/* Initialise TBI i/f to communicate with serdes (lynx phy) */
/* Single clk mode, mii mode off(for aerdes communication) */
- gfar_mdio_write(bus, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
+ gfar_mdio_write(bus, mdata->tbi_pa, MII_TBICON, TBICON_CLK_SELECT);
/* Supported pause and full-duplex, no half-duplex */
- gfar_mdio_write(bus, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_mdio_write(bus, mdata->tbi_pa, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_mdio_write(bus, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_mdio_write(bus, mdata->tbi_pa, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -539,8 +543,16 @@ static void init_registers(struct net_device *dev)
/* Initialize the Minimum Frame Length Register */
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
+}
+
+static void gfar_set_tbipa(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct mii_bus *bus = priv->mii_bus;
+ struct gianfar_mdio_data *mdata = (struct gianfar_mdio_data *)bus->priv;
+
/* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
+ gfar_write(&priv->regs->tbipa, mdata->tbi_pa);
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 46cd773..771aa5e 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -130,7 +130,6 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE0x1f
#define MIIMCFG_INIT_VALUE 0x0007
#define MIIMCFG_RESET 0x8000
#define MIIMIND_BUSY0x0001
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 806df3f..41ff8c4 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -160,7 +160,7 @@ int gfar_mdio_probe(struct device *dev)
struct gfar_mii __iomem *regs;
struct mii_bus *new_bus;
struct resource *r;
- int err = 0;
+ int i, err = 0;
if (NULL == dev)
return -EINVAL;
@@ -209,6 +209,15 @@ int gfar_mdio_probe(struct device *dev)
goto bus_register_fail;
}
+ /* mdiobus_register has populated the phy_map, so we now know
+ which doghouses have wild dogs living in them. Search
+ backwards for the 1st vacant one for the Ten Bit Interface */
+ for (i = PHY_MAX_ADDR - 1; i >= 0; i--)
+ if (new_bus->phy_map[i] == NULL) break;
+
+ printk(KERN_INFO "Gianfar MDIO: using ID 0x%x for TBIPA\n", i);
+ pdata->tbi_pa = i;
+
return 0;
bus_register_fail:
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 4b304b6..285bd80 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -60,6 +60,7 @@ struct gianfar_mdio_data {
/* board specific information */
struct gfar_mii __iomem *regs;
int irq[32];
+
[PATCH 3/5] gianfar: limit scope of gfar_local_mdio functions
The gfar_local_mdio_read/write functions were brought in via
extern since they go right at the regs vs. going via the normal
gfar_mdio_read/write functions. With the priv->mii_bus properly
set, we can get rid of the externs, the casts etc. and use the
normal gfar_mdio_read/write. We just need to move the call to the
gfar_configure_serdes down slightly to after where priv->mii_bus
is set to a sane value.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c | 17 +++--
drivers/net/gianfar_mii.c |4 ++--
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 0ad74c1..9173784 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -130,8 +130,6 @@ static void free_skb_resources(struct gfar_private *priv);
static void gfar_set_multi(struct net_device *dev);
static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
static void gfar_configure_serdes(struct net_device *dev);
-extern int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id,
int regnum, u16 value);
-extern int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int
regnum);
#ifdef CONFIG_GFAR_NAPI
static int gfar_poll(struct napi_struct *napi, int budget);
#endif
@@ -459,9 +457,6 @@ static int init_phy(struct net_device *dev)
phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
- if (interface == PHY_INTERFACE_MODE_SGMII)
- gfar_configure_serdes(dev);
-
if (IS_ERR(phydev)) {
printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
return PTR_ERR(phydev);
@@ -474,27 +469,29 @@ static int init_phy(struct net_device *dev)
priv->mii_bus = phydev->bus;
priv->phydev = phydev;
+ if (interface == PHY_INTERFACE_MODE_SGMII)
+ gfar_configure_serdes(dev);
+
return 0;
}
static void gfar_configure_serdes(struct net_device *dev)
{
struct gfar_private *priv = netdev_priv(dev);
- struct gfar_mii __iomem *regs =
- (void __iomem *)&priv->regs->gfar_mii_regs;
+ struct mii_bus *bus = priv->mii_bus;
/* Initialise TBI i/f to communicate with serdes (lynx phy) */
/* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
+ gfar_mdio_write(bus, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
/* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_mdio_write(bus, TBIPA_VALUE, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_mdio_write(bus, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 2432762..d5efa9c 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -51,7 +51,7 @@
* the local mdio pins, which may not be the same as system mdio bus, used for
* controlling the external PHYs, for example.
*/
-int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id,
+static int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id,
int regnum, u16 value)
{
/* Set the PHY address and the register address we want to write */
@@ -77,7 +77,7 @@ int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int
mii_id,
* and are always tied to the local mdio pins, which may not be the
* same as system mdio bus, used for controlling the external PHYs, for eg.
*/
-int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum)
+static int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int
regnum)
{
u16 value;
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/5] gianfar: dont hog the mii_bus->priv with just the regs.
The gfar was previously using the mii_bus->priv to directly
store the gfar_mii regs, which leaves no room/flexibility to
store anything else there. I believe it makes more sense to
have mii_bus->priv point at a struct gianfar_mdio_data and
then have the regs stored as a field within that. It makes
the code easier to read too.
This isn't in a hot path, so there should be no performance
penalty associated with this.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
drivers/net/gianfar_mii.c | 17 ++---
include/linux/fsl_devices.h |1 +
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index d5efa9c..806df3f 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -104,10 +104,10 @@ static int gfar_local_mdio_read(struct gfar_mii __iomem
*regs, int mii_id, int r
* All PHY configuration is done through the TSEC1 MIIM regs */
int gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value)
{
- struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
+ struct gianfar_mdio_data *mdata = (struct gianfar_mdio_data *)bus->priv;
/* Write to the local MII regs */
- return(gfar_local_mdio_write(regs, mii_id, regnum, value));
+ return(gfar_local_mdio_write(mdata->regs, mii_id, regnum, value));
}
/* Read the bus for PHY at addr mii_id, register regnum, and
@@ -115,16 +115,17 @@ int gfar_mdio_write(struct mii_bus *bus, int mii_id, int
regnum, u16 value)
* configuration has to be done through the TSEC1 MIIM regs */
int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
{
- struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
+ struct gianfar_mdio_data *mdata = (struct gianfar_mdio_data *)bus->priv;
/* Read the local MII regs */
- return(gfar_local_mdio_read(regs, mii_id, regnum));
+ return(gfar_local_mdio_read(mdata->regs, mii_id, regnum));
}
/* Reset the MIIM registers, and wait for the bus to free */
int gfar_mdio_reset(struct mii_bus *bus)
{
- struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
+ struct gianfar_mdio_data *mdata = (struct gianfar_mdio_data *)bus->priv;
+ struct gfar_mii __iomem *regs = mdata->regs;
unsigned int timeout = PHY_INIT_TIMEOUT;
mutex_lock(&bus->mdio_lock);
@@ -192,7 +193,8 @@ int gfar_mdio_probe(struct device *dev)
goto reg_map_fail;
}
- new_bus->priv = (void __force *)regs;
+ new_bus->priv = pdata;
+ pdata->regs = (void __force *)regs;
new_bus->irq = pdata->irq;
@@ -221,12 +223,13 @@ reg_map_fail:
int gfar_mdio_remove(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
+ struct gianfar_mdio_data *mdata = (struct gianfar_mdio_data *)bus->priv;
mdiobus_unregister(bus);
dev_set_drvdata(dev, NULL);
- iounmap((void __iomem *)bus->priv);
+ iounmap(mdata->regs);
bus->priv = NULL;
kfree(bus);
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 1831b19..4b304b6 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -58,6 +58,7 @@ struct gianfar_platform_data {
struct gianfar_mdio_data {
/* board specific information */
+ struct gfar_mii __iomem *regs;
int irq[32];
};
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/5] phylib: don't create a phydev for ID-less PHYs.
I've tested on 8360, 8540 and 8641D and in all cases, the PHY
ID returned for bus addr 0x1f is all zeros, and not all 0xf.
This means we've been allocating a phydev for this "ghost".
In addition to marking 0x0 as an invalid PHY ID, I've also
changed the existing somewhat useless printk to actually
list the bus IDs where it found a PHY so we get a basic
bus summary.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
drivers/net/phy/mdio_bus.c |4 +++-
drivers/net/phy/phy_device.c |5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 963630c..e33a119 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -59,6 +59,7 @@ int mdiobus_register(struct mii_bus *bus)
if (bus->reset)
bus->reset(bus);
+ pr_info("%s: PHY(s) at:", bus->name);
for (i = 0; i < PHY_MAX_ADDR; i++) {
struct phy_device *phydev;
@@ -97,12 +98,13 @@ int mdiobus_register(struct mii_bus *bus)
phy_device_free(phydev);
phydev = NULL;
}
+ printk(" 0x%x", i);
}
bus->phy_map[i] = phydev;
}
- pr_info("%s: probed\n", bus->name);
+ printk("\n");
return err;
}
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index f4c4fd8..740dd2e 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -116,8 +116,9 @@ struct phy_device * get_phy_device(struct mii_bus *bus, int
addr)
phy_id |= (phy_reg & 0x);
- /* If the phy_id is all Fs, there is no device there */
- if (0x == phy_id)
+ /* If the phy_id is all Fs, there is no device there. Similarly
+ it seems common to get an ID of zero at addr 0x1f */
+ if (0x == phy_id || 0 == phy_id)
return NULL;
dev = phy_device_create(bus, addr, phy_id);
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] gianfar: assign mii_bus value in dev->priv
The gianfar priv struct has an entry for the mii_bus, but it isn't being populated. Assign a value for it at the same time as we assign the phydev, so that it can be used in calls like gianfar_mdio_read/write. Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> --- drivers/net/gianfar.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 718cf77..0ad74c1 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -471,6 +471,7 @@ static int init_phy(struct net_device *dev) phydev->supported &= (GFAR_SUPPORTED | gigabit_support); phydev->advertising = phydev->supported; + priv->mii_bus = phydev->bus; priv->phydev = phydev; return 0; -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Add defconfig for Wind River SBC8641D board
This adds a sample defconfig for the Wind River SBC8641D board, with SMP, PCI and NFS root enabled. Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> --- arch/powerpc/configs/sbc8641d_defconfig | 1342 +++ 1 files changed, 1342 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/sbc8641d_defconfig diff --git a/arch/powerpc/configs/sbc8641d_defconfig b/arch/powerpc/configs/sbc8641d_defconfig new file mode 100644 index 000..3180125 --- /dev/null +++ b/arch/powerpc/configs/sbc8641d_defconfig @@ -0,0 +1,1342 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.25-rc6 +# Thu Apr 10 18:03:25 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +CONFIG_ALTIVEC=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_GENERIC_LOCKBREAK=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +CONFIG_GENERIC_TBSYNC=y +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +CONFIG_DEFAULT_UIMAGE=y +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +CONFIG_RELAY=y +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_STOP_MACHINE=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="cfq" +CONFIG_CLASSIC_RCU=y + +# +# Platform support +# +# CONFIG_PPC_MULTIPLATFORM is not set +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +CONFIG_PPC_86xx=y +# CONFIG_PPC_MPC512x is not set +# CONFIG_PPC_MPC5121 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_MPC8641_HPCN is not set +CONFIG_SBC8641D=y +# CONFIG_MPC8610_HPCD is not set +CONFIG_MPC8641=y +# CONFIG_IPIC is not set +CONFIG_MPIC=y +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_FSL_ULI1575 is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +CONFIG_TICK_ONESHOT=y +
[PATCH 2/3] powerpc: Add device tree source for Wind River SBC8641D
This adds in the device tree source for the SBC8641D, based
largely on the mpc8641_hpcn.dts. The biggest differences are
the lack of a complex IRQ mapping (since no Uli/i8259 cascade)
and the different layout of devices on the localbus node.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sbc8641d.dts | 352
1 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/sbc8641d.dts
diff --git a/arch/powerpc/boot/dts/sbc8641d.dts
b/arch/powerpc/boot/dts/sbc8641d.dts
new file mode 100644
index 000..27b5a3d
--- /dev/null
+++ b/arch/powerpc/boot/dts/sbc8641d.dts
@@ -0,0 +1,352 @@
+/*
+ * SBC8641D Device Tree Source
+ *
+ * Copyright 2008 Wind River Systems Inc.
+ *
+ * Paul Gortmaker (see MAINTAINERS for contact information)
+ *
+ * Based largely on the mpc8641_hpcn.dts by Freescale Semiconductor Inc.
+ *
+ * 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/;
+
+/ {
+ model = "SBC8641D";
+ compatible = "mpc86xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
+ 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>; // L1
+ i-cache-size = <32768>; // L1
+ timebase-frequency = <0>; // From uboot
+ bus-frequency = <0>;// From uboot
+ clock-frequency = <0>; // From uboot
+ };
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <1>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>;
+ i-cache-size = <32768>;
+ timebase-frequency = <0>; // From uboot
+ bus-frequency = <0>;// From uboot
+ clock-frequency = <0>; // From uboot
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>; // 512M at 0x0
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8641-localbus", "simple-bus";
+ reg = <0xf8005000 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+
+ ranges = <0 0 0xff00 0x0100 // 16MB Boot flash
+ 1 0 0xf000 0x0001 // 64KB EEPROM
+ 2 0 0xf100 0x0010 // EPLD (1MB)
+ 3 0 0xe000 0x0400 // 64MB LB SDRAM (CS3)
+ 4 0 0xe400 0x0400 // 64MB LB SDRAM (CS4)
+ 6 0 0xf400 0x0010 // LCD display (1MB)
+ 7 0 0xe800 0x0400>; // 64MB OneNAND
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x0100>;
+ bank-width = <2>;
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "dtb";
+ reg = <0x 0x0010>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "kernel";
+ reg = <0x0010 0x0040>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "fs";
+ reg = <0x0050 0x00a0>;
+ };
+ [EMAIL PROTECTED] {
+ label = "firmware";
+ reg = <0x00f0 0x0010>;
+ read-only;
+ };
+
[PATCH 1/3] powerpc: Add support for Wind River SBC8641D board
This adds support for the Wind River SBC8641D board, based
largely on the mpc86xx_hpcn support. The biggest difference is
the lack of the Uli and the i8259 cascade, which simplifies things.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/86xx/Kconfig|8 ++-
arch/powerpc/platforms/86xx/Makefile |1 +
arch/powerpc/platforms/86xx/sbc8641d.c | 171
3 files changed, 179 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/86xx/sbc8641d.c
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 21d1135..7442c58 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -11,6 +11,12 @@ config MPC8641_HPCN
help
This option enables support for the MPC8641 HPCN board.
+config SBC8641D
+ bool "Wind River SBC8641D"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the WRS SBC8641D board.
+
config MPC8610_HPCD
bool "Freescale MPC8610 HPCD"
select DEFAULT_UIMAGE
@@ -24,7 +30,7 @@ config MPC8641
select FSL_PCI if PCI
select PPC_UDBG_16550
select MPIC
- default y if MPC8641_HPCN
+ default y if MPC8641_HPCN || SBC8641D
config MPC8610
bool
diff --git a/arch/powerpc/platforms/86xx/Makefile
b/arch/powerpc/platforms/86xx/Makefile
index c967063..1b9b4a9 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_SMP) += mpc86xx_smp.o
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
+obj-$(CONFIG_SBC8641D) += sbc8641d.o
obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/arch/powerpc/platforms/86xx/sbc8641d.c
b/arch/powerpc/platforms/86xx/sbc8641d.c
new file mode 100644
index 000..c7516be
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/sbc8641d.c
@@ -0,0 +1,171 @@
+/*
+ * SBC8641D board specific routines
+ *
+ * Copyright 2008 Wind River Systems Inc.
+ *
+ * By Paul Gortmaker (see MAINTAINERS for contact information)
+ *
+ * Based largely on the 8641 HPCN support by Freescale Semiconductor Inc.
+ *
+ * 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
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "mpc86xx.h"
+
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
+#else
+#define DBG(fmt...) do { } while(0)
+#endif
+
+void __init
+sbc8641_init_irq(void)
+{
+ struct mpic *mpic1;
+ struct device_node *np;
+ struct resource res;
+
+ /* Determine PIC address. */
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (np == NULL)
+ return;
+ of_address_to_resource(np, 0, &res);
+
+ /* Alloc mpic structure and per isu has 16 INT entries. */
+ mpic1 = mpic_alloc(np, res.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
+ 0, 256, " MPIC ");
+ BUG_ON(mpic1 == NULL);
+
+ mpic_init(mpic1);
+}
+
+static void __init
+sbc8641_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+
+ if (ppc_md.progress)
+ ppc_md.progress("sbc8641_setup_arch()", 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,mpc8641-pcie")
+ fsl_add_bridge(np, 0);
+#endif
+
+ printk("SBC8641 board from Wind River\n");
+
+#ifdef CONFIG_SMP
+ mpc86xx_smp_init();
+#endif
+}
+
+
+void
+sbc8641_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ uint memsize = total_memory;
+ const char *model = "";
+ uint svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, "Vendor\t\t: Wind River Systems\n");
+
+ root = of_find_node_by_path("/");
+ if (root)
+ model = of_get_property(root, "model", NULL);
+ seq_printf(m, "Machine\t\t: %s\n", model);
+ of_node_put(root);
+
+ seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+ seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
+}
+
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init sbc8641_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "mpc86xx"))
+ return 1; /* Looks good */
+
+ return 0;
+}
+
+long __init
+mpc86xx_time_init(void)
+{
+ unsigned int temp;
+
+ /* Set the time base to zero */
+ mtspr(SPRN_TBWL, 0);
+ mtspr(SPRN_TBWU, 0);
+
+ temp = mfspr(SPRN_HID0);
+ temp |= H
[PATCH 0/3] Support for Wind River SBC8641D board
The following patches add support for the Wind River SBC8641D board. I've done it by starting with the current mpc8641_hpcn support and then making the changes from there, so it should be 1:1 comparable with the HPCN platform, which aids in tracking/applying future changes. The SBC8641D support essentially boils down to trimming back stuff from the HPCN platform, as this board doesn't have the Uli and all the devices/busses etc. that the HPCN cascades from that. Plus of course, the dts changes for the localbus specifics. Patches that aren't included here, but submitted separately are the support for the Broadcom 5464 quad PHY and the ability to have the Gianfar TBIPA be auto assigned (since this board puts a PHY at 0x1f). I expect the defconfig will probably be in an 86xx subdir, based on what Kumar sent today, but for now it is still in configs. I'm hoping to see this queued up for 26, if all goes well. Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patches for 2.6.26
On Thu, 2008-04-10 at 15:16 -0700, David Miller wrote: > From: Laurent Pinchart <[EMAIL PROTECTED]> > Date: Thu, 10 Apr 2008 17:20:36 +0200 > > > On Thursday 10 April 2008 16:21, Kumar Gala wrote: > > > Guy's > > > > > > if you have work you want in 2.6.26 related to Freescale PPC's let me > > > know. Ideally you can provide links to the patches in > > > http://patchwork.ozlabs.org/linuxppc/ > > > > Could you please add this one ? > > > > fs_enet: Don't call NAPI functions when NAPI is not used. > > http://patchwork.ozlabs.org/linuxppc/patch?id=17055 > > I kindly request that PPC folks send networking driver patches through > the normal channels so that the networking experts on netdev and > people like Jeff Garzik can review such changes. Normally we do. But we appreciate the reminder. Particularly since it reminded me that I need to chase Jeff down about the ibm_newemac patches that were sent a while ago. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
Please use [EMAIL PROTECTED] for patch and development discussion, linux-net is for user discussions only. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patches for 2.6.26
From: Laurent Pinchart <[EMAIL PROTECTED]> Date: Thu, 10 Apr 2008 17:20:36 +0200 > On Thursday 10 April 2008 16:21, Kumar Gala wrote: > > Guy's > > > > if you have work you want in 2.6.26 related to Freescale PPC's let me > > know. Ideally you can provide links to the patches in > > http://patchwork.ozlabs.org/linuxppc/ > > Could you please add this one ? > > fs_enet: Don't call NAPI functions when NAPI is not used. > http://patchwork.ozlabs.org/linuxppc/patch?id=17055 I kindly request that PPC folks send networking driver patches through the normal channels so that the networking experts on netdev and people like Jeff Garzik can review such changes. In fact this patch here is a bug fix and belongs in the tree right now, instead of waiting for 2.6.26 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Thu, 2008-04-10 at 15:37 +0200, Stefan Roese wrote: > > Now I have to re-check to see what you really have in mind. Do you think > about > creating two different PCIe nodes, one for root-complex and one for endpoint > functionality? Or is your idea to add a property to the existing PCIe > device-tree node (like "mode = endpoint"), or perhaps change the device_type > from "pci" to "pci-endpoint"? I would vote for the latter. Make the name and type of the node different. The rest can mostly stay the same. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
> +#ifndef thread_info_cache_init
> +#define thread_info_cache_init do { } while(0)
> +#endif
> +
Blah ! Missing a pair of () here. Ooops. I'll send a fixed patch.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] CPM: Always use new binding.
The kconfig entry can go away once arch/ppc and references to the config in drivers are removed. Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- arch/powerpc/platforms/82xx/Kconfig |3 - arch/powerpc/platforms/85xx/Kconfig |8 - arch/powerpc/platforms/8xx/Kconfig |4 - arch/powerpc/platforms/Kconfig |8 +- arch/powerpc/sysdev/cpm1.c | 112 --- arch/powerpc/sysdev/cpm2.c | 97 --- arch/powerpc/sysdev/cpm_common.c|3 - arch/powerpc/sysdev/fsl_soc.c | 541 --- 8 files changed, 1 insertions(+), 775 deletions(-) diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig index 4fad6c7..917ac88 100644 --- a/arch/powerpc/platforms/82xx/Kconfig +++ b/arch/powerpc/platforms/82xx/Kconfig @@ -11,7 +11,6 @@ config MPC8272_ADS select 8260 select FSL_SOC select PQ2_ADS_PCI_PIC if PCI - select PPC_CPM_NEW_BINDING help This option enables support for the MPC8272 ADS board @@ -22,7 +21,6 @@ config PQ2FADS select 8260 select FSL_SOC select PQ2_ADS_PCI_PIC if PCI - select PPC_CPM_NEW_BINDING help This option enables support for the PQ2FADS board @@ -31,7 +29,6 @@ config EP8248E select 8272 select 8260 select FSL_SOC - select PPC_CPM_NEW_BINDING select MDIO_BITBANG help This enables support for the Embedded Planet EP8248E board. diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 28bc6e5..7ff29d5 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -19,7 +19,6 @@ config MPC8540_ADS config MPC8560_ADS bool "Freescale MPC8560 ADS" select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING select CPM2 help This option enables support for the MPC 8560 ADS board @@ -48,7 +47,6 @@ config MPC85xx_DS config KSI8560 bool "Emerson KSI8560" -select PPC_CPM_NEW_BINDING select DEFAULT_UIMAGE help This option enables support for the Emerson KSI8560 board @@ -60,14 +58,12 @@ config STX_GP3 board. select CPM2 select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING config TQM8540 bool "TQ Components TQM8540" help This option enables support for the TQ Components TQM8540 board. select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING select TQM85xx config TQM8541 @@ -75,7 +71,6 @@ config TQM8541 help This option enables support for the TQ Components TQM8541 board. select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING select TQM85xx select CPM2 @@ -84,7 +79,6 @@ config TQM8555 help This option enables support for the TQ Components TQM8555 board. select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING select TQM85xx select CPM2 @@ -93,7 +87,6 @@ config TQM8560 help This option enables support for the TQ Components TQM8560 board. select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING select TQM85xx select CPM2 @@ -106,7 +99,6 @@ config SBC8548 config SBC8560 bool "Wind River SBC8560" select DEFAULT_UIMAGE - select PPC_CPM_NEW_BINDING if CPM2 help This option enables support for the Wind River SBC8560 board diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig index 7fd224c..6fc849e 100644 --- a/arch/powerpc/platforms/8xx/Kconfig +++ b/arch/powerpc/platforms/8xx/Kconfig @@ -18,7 +18,6 @@ config MPC8XXFADS config MPC86XADS bool "MPC86XADS" select CPM1 - select PPC_CPM_NEW_BINDING help MPC86x Application Development System by Freescale Semiconductor. The MPC86xADS is meant to serve as a platform for s/w and h/w @@ -27,7 +26,6 @@ config MPC86XADS config MPC885ADS bool "MPC885ADS" select CPM1 - select PPC_CPM_NEW_BINDING help Freescale Semiconductor MPC885 Application Development System (ADS). Also known as DUET. @@ -37,7 +35,6 @@ config MPC885ADS config PPC_EP88XC bool "Embedded Planet EP88xC (a.k.a. CWH-PPC-885XN-VE)" select CPM1 - select PPC_CPM_NEW_BINDING help This enables support for the Embedded Planet EP88xC board. @@ -47,7 +44,6 @@ config PPC_EP88XC config PPC_ADDER875 bool "Analogue & Micro Adder 875" select CPM1 - select PPC_CPM_NEW_BINDING select REDBOOT help This enables support for the Analogue & Micro Adder 875 diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index a578b96..f38c50b 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -290,13 +290,7 @@ con
Re: [PATCH] [v5] Add idle wait support for 44x platforms
On Thu, 2008-04-10 at 15:44 +0200, Arnd Bergmann wrote:
> On Tuesday 08 April 2008, Jerone Young wrote:
> > +static struct sleep_mode modes[] = {
> > + { .name = "wait", .entry = &ppc44x_idle },
> > + { .name = "spin", .entry = NULL },
> > +};
> > +
> > +int __init ppc44x_idle_init(void)
> > +{
> > + void *func = modes[current_mode].entry;
> > + ppc_md.power_save = func;
> > + return 0;
> > +}
> > +
> > +arch_initcall(ppc44x_idle_init);
> > +
> > +static int __init idle_param(char *p)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(modes); i++) {
> > + if (!strcmp(modes[i].name, p)) {
> > + current_mode = i;
> > + break;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +early_param("idle", idle_param);
>
> ok, sorry to steal the show again, now that everyone seems to be happy
> with the current code, but isn't this equivalent to the simple
Well it could be this simple. But the current code leaves a lot more
room to add different type waits or spins if need be (if they are ever
needed ... though none off the top of my head at the moment)...but it
does allow you to create another wait state for whatever reason a lot
easier.
So I really don't think this needs to change. Unless everyone really
feels that it just has to be.
>
> static int __init idle_param(char *p)
> {
> if (!strcmp(modes[i].name, "spin"))
> ppc_md.power_save = NULL;
> }
> early_param("idle", idle_param);
>
> if you statically initialize the ppc_md.power_save function to ppc44x_idle
> in the platform setup files?
The idea is to not statically initialize ppc_md.power_save to
ppc44x_idle in each platform setup file.
>
> Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
On Apr 10, 2008, at 1:24 PM, Sergei Shtylyov wrote: Kumar Gala wrote: Those functions are going to break on 32-bit platforms with extended physical address (well, that's starting with Pentiums which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should have used resource_size_t for the 'offset' parameter. As this most probably means that libata is broken on such platforms, I'm going to submit a patch... It's broken with drivers using MMIO, I meant to say. Oops, I meant PCI drivers here, at least for the time being. And it looks like that was a false alarm. :-] Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called from ioremap() which help create an illusion that the PCI memory space on such platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence this newly encountered issue. I thought that pcim_iomap() used devm_ioremap() or something -- which of course turned to be wrong. devm_ioremap() alone is yet safe since there are no users for it amongst PPC 44x platform device drivers... but there is no reason not to make it work properly. For example I believe libata uses devm_* and the fsl SATA driver (non-PCI) will need to work in cases similar to the 44x. Well, as for sata_fsl, it calls of_iomap() which does The Right Thing. Fair, but I don't see why we should introduce new APIs that are already "broken". We went through a lot of effort to clean up and introduce resource_t (and clearly still have some bugs) for the >32- bit physical address problem. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
Kumar Gala wrote: Those functions are going to break on 32-bit platforms with extended physical address (well, that's starting with Pentiums which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should have used resource_size_t for the 'offset' parameter. As this most probably means that libata is broken on such platforms, I'm going to submit a patch... It's broken with drivers using MMIO, I meant to say. Oops, I meant PCI drivers here, at least for the time being. And it looks like that was a false alarm. :-] Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called from ioremap() which help create an illusion that the PCI memory space on such platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence this newly encountered issue. I thought that pcim_iomap() used devm_ioremap() or something -- which of course turned to be wrong. devm_ioremap() alone is yet safe since there are no users for it amongst PPC 44x platform device drivers... but there is no reason not to make it work properly. For example I believe libata uses devm_* and the fsl SATA driver (non-PCI) will need to work in cases similar to the 44x. Well, as for sata_fsl, it calls of_iomap() which does The Right Thing. - k WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc440 caches - change proposal [RFC]
On Wed, 9 Apr 2008 13:50:43 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote: > On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <[EMAIL PROTECTED]> wrote: > > I understand that many people are using a bootloader that already sets up > > the > > cache for the kernel, but I'm wondering if Xilinx boards are really a > > special > > case, or if there may be other non-Xilinx related systems that would also > > not > > be using a bootloader. > > I think there are very few cases of platforms not using some form of firmware. Indeed. > > I also understand the desire to avoid code that does the same work more > > than > > once, but I wonder if in this case, it's creating too strong a dependence on > > the specific behavior of a certain bootloader. > > I also wonder if arch/powerpc is being made more complex by trying to split > > out this code change into a Xilinx specific area, when the change could > > just > > be rolled into head_40x.S and we could do away with virtex405-head.S. > > In general, I think that the wrapper does not want to touch the cache > settings. In the common case where firmware exists and sets up the > cache then to turn off the cache again would throw away what firmware > already had in cache and slow down the boot. > > That being said, I'm not the bootwrapper expert. If other think that > it belongs in head_40x.S then I have no objections. > > Josh, any thoughts? This may or may not be OK. In the general case, I think Grant is right in that the wrapper tends to avoid mucking with cache settings that were already setup by the firmware. For 405 specifically, it could go either way. And we actually already ignore the cache settings for real mode anyway once it gets to MMU_init_hw, but I wouldn't be surprised if an assumption was made there as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
On Apr 10, 2008, at 11:56 AM, Sergei Shtylyov wrote: Hello, I wrote: Those functions are going to break on 32-bit platforms with extended physical address (well, that's starting with Pentiums which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should have used resource_size_t for the 'offset' parameter. As this most probably means that libata is broken on such platforms, I'm going to submit a patch... It's broken with drivers using MMIO, I meant to say. Oops, I meant PCI drivers here, at least for the time being. And it looks like that was a false alarm. :-] Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called from ioremap() which help create an illusion that the PCI memory space on such platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence this newly encountered issue. I thought that pcim_iomap() used devm_ioremap() or something -- which of course turned to be wrong. devm_ioremap() alone is yet safe since there are no users for it amongst PPC 44x platform device drivers... but there is no reason not to make it work properly. For example I believe libata uses devm_* and the fsl SATA driver (non-PCI) will need to work in cases similar to the 44x. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to pass information from the bootloader to the kernel ?
On Apr 10, 2008, at 10:50 AM, Laurent Pinchart wrote: Hi everybody, I need to pass a limited amount of information from the boot loader to the Linux kernel, such as the boot mode chosen by the user or the last boot reason (power up, reset, watchdog, ...). What is the best way to pass that kind of information from the boot loader to the kernel ? Should I use the device tree ? I thought about populating the chosen node with the data I need. This could make sense for the boot mode, but I feel like I would abuse the chosen node if I used it to pass other "non user chosen" information. using chosen is fine, just remember to prefix properties with some vendor prefix. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
Hello, I wrote: Those functions are going to break on 32-bit platforms with extended physical address (well, that's starting with Pentiums which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should have used resource_size_t for the 'offset' parameter. As this most probably means that libata is broken on such platforms, I'm going to submit a patch... It's broken with drivers using MMIO, I meant to say. Oops, I meant PCI drivers here, at least for the time being. And it looks like that was a false alarm. :-] Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called from ioremap() which help create an illusion that the PCI memory space on such platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence this newly encountered issue. I thought that pcim_iomap() used devm_ioremap() or something -- which of course turned to be wrong. devm_ioremap() alone is yet safe since there are no users for it amongst PPC 44x platform device drivers... MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2 of 3] [KVM] Add DCR access information to struct kvm_run
On Tue, 8 Apr 2008 13:54:41 +1000 David Gibson <[EMAIL PROTECTED]> wrote: > On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote: > > On Monday 07 April 2008 20:11:28 David Gibson wrote: > > > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote: > > > > 1 file changed, 7 insertions(+) > > > > include/linux/kvm.h |7 +++ > > > > > > > > > > > > Device Control Registers are essentially another address space found on > > > > PowerPC 4xx processors, analogous to PIO on x86. DCRs are always 32 > > > > bits, > > > > and are identified by a 32-bit number. > > > > > > Well... 10-bit, actually. > > > > The mtdcrux description in the ppc440x6 user manual says the following: > > > > Let the contents of register RA denote a Device Control Register. > > The contents of GPR[RS] are placed into the designated Device Control > > Register. > > > > I take that to mean that we must worry about 32 bits worth of DCR numbers. > > Perhaps I should say "no more than" rather than "always". > > I think that's less misleading. mtdcrux is very new, anything which > only has the mtdcr instruction certainly can't take DCR numbers above > 10 bits, and I would expect that even on chips with mtdcrux the DCR > bus is probably still only 10-bits, although it could be extended. http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/C94B06BE313211B887257110006EFFBD/$file/460migrate.pdf page 4. "DCR Address Space Increased to 32 bits". I realize that the above is for 460 cores, but I would not be surprised at all if that shows up in a future 440 core. 440x6 already seems to be a conglomeration of some of the features 460 has. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] FCC: fix confused base / offset
Sascha Hauer wrote:
See bottom of this mail. The board really is a 8260 based board. Our
bootloader does not fill in the clock values, so they are hardcoded. I'm
not very sure about the muram entries because the dpram is organized
slightly different on the 8260. It has some dedicated FCC space and I
don't know how to properly encode this in the device tree.
I think the FCC space should just be left out.
Does the PHY negotiate OK?
Well I put some printks into the phy_read/write functions so I can say
that it at least properly talks to the phy.
Do you get a console message indicating that the link came up?
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
Change the 8272 references to 8260.
// Temporary -- will go away once kernel uses ranges for
get_immrbase().
reg = ;
This can go away now.
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 1>;
[EMAIL PROTECTED] {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 8000 800>;
reg should be <0 4000>. Don't include parameter RAM here.
[EMAIL PROTECTED] {
[EMAIL PROTECTED]
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 30>;
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 80 10 20 30 40 50 ];
interrupts = <21 2>;
interrupts = <21 8>;
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to pass information from the bootloader to the kernel ?
On Thu, Apr 10, 2008 at 9:50 AM, Laurent Pinchart <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I need to pass a limited amount of information from the boot loader to the > Linux kernel, such as the boot mode chosen by the user or the last boot > reason (power up, reset, watchdog, ...). > > What is the best way to pass that kind of information from the boot loader to > the kernel ? Should I use the device tree ? > > I thought about populating the chosen node with the data I need. This could > make sense for the boot mode, but I feel like I would abuse the chosen node > if I used it to pass other "non user chosen" information. Using the chosen node should be fine. Just prefix your new properties with your company name or something so that you don't get namespace collisions. However, whatever you do; document it first and post your documentation to the mailing list for review. Cheers, g. > > Best regards, > > -- > 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 > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- 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
How to pass information from the bootloader to the kernel ?
Hi everybody, I need to pass a limited amount of information from the boot loader to the Linux kernel, such as the boot mode chosen by the user or the last boot reason (power up, reset, watchdog, ...). What is the best way to pass that kind of information from the boot loader to the kernel ? Should I use the device tree ? I thought about populating the chosen node with the data I need. This could make sense for the boot mode, but I feel like I would abuse the chosen node if I used it to pass other "non user chosen" information. Best regards, -- 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 pgpAliL3T9l90.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patches for 2.6.26
On Apr 10, 2008, at 10:20 AM, Laurent Pinchart wrote: On Thursday 10 April 2008 16:21, Kumar Gala wrote: Guy's if you have work you want in 2.6.26 related to Freescale PPC's let me know. Ideally you can provide links to the patches in http://patchwork.ozlabs.org/linuxppc/ Could you please add this one ? fs_enet: Don't call NAPI functions when NAPI is not used. http://patchwork.ozlabs.org/linuxppc/patch?id=17055 Jeff Garzik should ack this first. (you'll want to send to netdev and Jeff). (also ask him if he want it to go via netdev or ppc tree's). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] E500 Make steal_context SMP-safe.
On Apr 3, 2008, at 11:46 AM, Randy Vinson wrote: When steal_context is used on SMP systems, it can steal a context in use by one of the other processors. This patch adds context tracking to prevent this as suggested by BenH. Can we be more descriptive in the problem/bug symptom in the description. otherwise this looks ok to me. I'd like BenH to ack as well since he's been look at this code recently. Signed-off-by: Randy Vinson <[EMAIL PROTECTED]> --- The previous version of this patch had some unnecessary code which has been removed in this version. Note: This is a proof-of-concept patch. This isn't my area of expertise, so I'd greatly appreciate any guidance I can get. I'm considering the use of for_each_online_cpu() instead of for_each_possible_cpu() and possibly putting the changes under a CONFIG_SMP switch to prevent unnecessary overhead in the non-SMP case. for_each_online_cpu() is probably better. I'm guessing this optimizes pretty well in the !CONFIG_SMP case. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: State of the MPC5200 PSC AC97 driver
I have a copy of the driver I hacked to work with the new PSC framework but it doesn't "work" anymore - I have no idea why. Mail me privately if you want it, I have no time to make patches or look for a good reason for the breakages, but it compiles at least. The Efika hack should be gone now (irrelevant since we released a firmware that obseletes it) and the other fixmes should be by the wayside considering the fscking thing doesn't play sound anymore... -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Marian Balakowicz wrote: Hi Sylvain, Last year you have posted a MPC5200 PSC AC97 driver patch "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface." with the following comment: Not quite a clean driver, but it get things done (well, mostly). Only included to be able to test functionalityi/usage of the BestComm driver. There are various FIXMEs and commented out code here and there. Could you elaborate a bit on the overall state of the driver's functionality, which areas need improvement and attention? Seems that you mainly tested BestComm with this driver, what was the overall BestComm performance, any issues here? Did you use any specific test setup involving some dedicated application, etc.? Did anyone else tried it and/or has a updated version or can share experience? Thanks in advance. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patches for 2.6.26
On Thursday 10 April 2008 16:21, Kumar Gala wrote: > Guy's > > if you have work you want in 2.6.26 related to Freescale PPC's let me > know. Ideally you can provide links to the patches in > http://patchwork.ozlabs.org/linuxppc/ Could you please add this one ? fs_enet: Don't call NAPI functions when NAPI is not used. http://patchwork.ozlabs.org/linuxppc/patch?id=17055 -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv4 0/5] cpm2: Reset the CPM at startup and fix the cpm_uart driver accordingly.
On Apr 1, 2008, at 7:33 AM, Laurent Pinchart wrote: Hi everybody, these 5 patches reset the CPM in cpm2_reset() and fix the cpm_uart driver to initialise SMC ports correctly without relying on any initialisation performed by the boot loader/wrapper. They update the boot wrapper code and the EP8248E device tree to match the new SMC registers description. Patches 2/5, 3/5 and 4/5 (boot wrapper and EP8248E device tree updates) haven't been tested due to lack of hardware. applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ppc64 build issue
anyone looking into this? http://kisskb.ellerman.id.au/kisskb/buildresult/23299/ Its really a Kconfig issue. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote: Hi Paul, could you please add the following patches ? [PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2- based platforms. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html [PATCHv4 2/5] powerpc: Add bootwrapper function to get virtual reg from the device tree. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053859.html [PATCHv4 3/5] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053860.html [PATCHv4 4/5] ep8248e: Reference SMC parameter RAM base in the device tree. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053862.html [PATCHv4 5/5] cpm2: Reset the CPM when early debugging is not enabled. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053861.html Your patches still have mailer issues when I try to apply them. If you want to go back and forth privately so we can figure out what's going on. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
On Apr 10, 2008, at 9:28 AM, Laurent Pinchart wrote: On Thursday 10 April 2008 16:11, Kumar Gala wrote: On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote: Laurent Pinchart writes: could you please add the following patches ? Sure, if Kumar acks them, since they are all 8xxx-related as far as I can see (with the exception of the part of 2/5 that adds the new dt_get_virtual_reg function). Or Kumar can put them in his tree. I'll deal with them. There are a larger number of CPM/8xxx related patches that I need to go through. Is there a chance they could go in 2.6.26 ? Yes that's the idea :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1 of 3] [POWERPC 44x] Export tlb_44x_hwater for KVM
On Mon, 07 Apr 2008 15:53:32 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> 1 file changed, 2 insertions(+)
> include/asm-powerpc/mmu-44x.h |2 ++
>
>
> PowerPC 440 KVM needs to know how many TLB entries are used for the host
> kernel
> linear mapping (it does not modify these mappings when switching between guest
> and host execution).
>
> Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
Acked-by: Josh Boyer <[EMAIL PROTECTED]>
>
> diff --git a/include/asm-powerpc/mmu-44x.h b/include/asm-powerpc/mmu-44x.h
> --- a/include/asm-powerpc/mmu-44x.h
> +++ b/include/asm-powerpc/mmu-44x.h
> @@ -53,6 +53,8 @@
>
> #ifndef __ASSEMBLY__
>
> +extern unsigned int tlb_44x_hwater;
> +
> typedef unsigned long long phys_addr_t;
>
> typedef struct {
> ___
> 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: Patches added to powerpc.git powerpc-next and master branches
On Thursday 10 April 2008 16:11, Kumar Gala wrote: > > On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote: > > Laurent Pinchart writes: > > > >> could you please add the following patches ? > > > > Sure, if Kumar acks them, since they are all 8xxx-related as far as I > > can see (with the exception of the part of 2/5 that adds the new > > dt_get_virtual_reg function). Or Kumar can put them in his tree. > > I'll deal with them. There are a larger number of CPM/8xxx related > patches that I need to go through. Is there a chance they could go in 2.6.26 ? Best regards, -- 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 pgpRczIVbEETZ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0 of 3] KVM for PowerPC 440
On Thursday 10 April 2008 06:55:18 Josh Boyer wrote: > On Mon, 07 Apr 2008 15:53:31 -0500 > > Hollis Blanchard <[EMAIL PROTECTED]> wrote: > > Implement initial support for KVM for PowerPC 440. There are just two > > small prerequisite patches, and then the bulk of the code can't be split > > easily. > > > > Please review; I would like to submit these for 2.6.26. There is plenty > > of work to do, both functional and optimization, but this code is > > sufficient to run unmodified 440 Linux guests on a 440 Linux host. What's > > your favorite bike shed color? > > Who's tree are you looking to get this patch set into? Since the only PPC-specific change is patch 1, if I can get your Acked-by for it I will send it via Avi. -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patches for 2.6.26
Guy's if you have work you want in 2.6.26 related to Freescale PPC's let me know. Ideally you can provide links to the patches in http://patchwork.ozlabs.org/linuxppc/ thanks - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
Hi Kumar, On Thursday 10 April 2008 16:10, Kumar Gala wrote: > Laurent, > > The cpm/82xx ones should go via me. Sorry, I didn't know that. I'll e-mail you directly next time. Best regards, -- 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 pgpmAYR2CWJoq.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote: Laurent Pinchart writes: could you please add the following patches ? Sure, if Kumar acks them, since they are all 8xxx-related as far as I can see (with the exception of the part of 2/5 that adds the new dt_get_virtual_reg function). Or Kumar can put them in his tree. I'll deal with them. There are a larger number of CPM/8xxx related patches that I need to go through. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
Laurent, The cpm/82xx ones should go via me. - k On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote: Hi Paul, could you please add the following patches ? [PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2- based platforms. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html [PATCHv4 2/5] powerpc: Add bootwrapper function to get virtual reg from the device tree. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053859.html [PATCHv4 3/5] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053860.html [PATCHv4 4/5] ep8248e: Reference SMC parameter RAM base in the device tree. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053862.html [PATCHv4 5/5] cpm2: Reset the CPM when early debugging is not enabled. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053861.html Thanks. Best regards, -- 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 ___ 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] [v5] Add idle wait support for 44x platforms
On Tuesday 08 April 2008, Jerone Young wrote:
> +static struct sleep_mode modes[] = {
> + { .name = "wait", .entry = &ppc44x_idle },
> + { .name = "spin", .entry = NULL },
> +};
> +
> +int __init ppc44x_idle_init(void)
> +{
> + void *func = modes[current_mode].entry;
> + ppc_md.power_save = func;
> + return 0;
> +}
> +
> +arch_initcall(ppc44x_idle_init);
> +
> +static int __init idle_param(char *p)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(modes); i++) {
> + if (!strcmp(modes[i].name, p)) {
> + current_mode = i;
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +early_param("idle", idle_param);
ok, sorry to steal the show again, now that everyone seems to be happy
with the current code, but isn't this equivalent to the simpler
static int __init idle_param(char *p)
{
if (!strcmp(modes[i].name, "spin"))
ppc_md.power_save = NULL;
}
early_param("idle", idle_param);
if you statically initialize the ppc_md.power_save function to ppc44x_idle
in the platform setup files?
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: State of the MPC5200 PSC AC97 driver
On Thu, Apr 10, 2008 at 12:44:43PM +0200, Marian Balakowicz wrote: > Last year you have posted a MPC5200 PSC AC97 driver patch > "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface." > with the following comment: > > > Not quite a clean driver, but it get things done (well, mostly). > > Only included to be able to test functionalityi/usage of > > the BestComm driver. > > There are various FIXMEs and commented out code here and there. > Could you elaborate a bit on the overall state of the driver's > functionality, > which areas need improvement and attention? > > Seems that you mainly tested BestComm with this driver, what was the > overall > BestComm performance, any issues here? Did you use any specific test setup > involving some dedicated application, etc.? > > Did anyone else tried it and/or has a updated version or can share > experience? Sidenote: last time we tried (2.6.23.1), the AC97 driver didn't work, tested on the phyCORE-MPC5200B-tiny board. No sound, just a little bit noise which can be muted with the mixer. And music finishes about 7 times as fast as it usually should. So we didn't manage to make it work yet. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote: > > Understood. But for this "dynamic" root-complex/endpoint configuration as > > implemented with the current version of the patch, I can't change the > > PCIe node in the dts from root-complex mode to endpoint mode, since I > > would loose root-complex functionality. Perhaps I'm missing something > > here. > > Well, I would expect the firmware (ie. uboot) to provide the right > device-node type... Now I have to re-check to see what you really have in mind. Do you think about creating two different PCIe nodes, one for root-complex and one for endpoint functionality? Or is your idea to add a property to the existing PCIe device-tree node (like "mode = endpoint"), or perhaps change the device_type from "pci" to "pci-endpoint"? I would vote for the latter. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc405ep emac driver loading problem
On Thu, Apr 10, 2008 at 1:52 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > You have to call of_platform_bus_probe with the various bus types for > your board. See the top few functions of: > > arch/powerpc/platforms/40x/walnut.c Well I did this, but I made a typo (plb4 instead of plb3). So thanks a lot for making me recheck this section. I don't know how long I would have searched for this else. Regards Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
Laurent Pinchart writes: > could you please add the following patches ? Sure, if Kumar acks them, since they are all 8xxx-related as far as I can see (with the exception of the part of 2/5 that adds the new dt_get_virtual_reg function). Or Kumar can put them in his tree. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Thu, 2008-04-10 at 13:59 +0200, Stefan Roese wrote: > Understood. But for this "dynamic" root-complex/endpoint configuration as > implemented with the current version of the patch, I can't change the PCIe > node in the dts from root-complex mode to endpoint mode, since I would loose > root-complex functionality. Perhaps I'm missing something here. Well, I would expect the firmware (ie. uboot) to provide the right device-node type... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
On Thu, 2008-04-10 at 12:56 +0200, Christoph Hellwig wrote: > On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote: > > I don't think there's any difference between the _ONSTACK variant > > and the normal one without lockdep, is there ? > > No there's not. Thus it's a guaranteed no-op and can easily go in. Heh, I won't argue either way :-) It's Paul's call at this stage. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote: > On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote: > > Sure, this would be optimal. But frankly, I currently have no need for > > this > > non U-Boot mode, and therefore I didn't implement it. This can be > > added later > > when really needed don't you think? > > It can... but on the other hand, it's not hard :-) But it takes time. And time is as always short. :) > > Good. But again, I would really prefer to first include this U-Boot > > style > > endpoint support and later add this independent device tree endpoint > > configuration when really needed. > > Well, you are the one with a use case... but I do think we should > differenciate a PCI in host mode vs. endpoint mode right away. We don't > want the PCI stack from kicking in at all in endpoint mode, we don't > want to bother with creating the PCI infrastructure and config space > accessors etc... Understood. But for this "dynamic" root-complex/endpoint configuration as implemented with the current version of the patch, I can't change the PCIe node in the dts from root-complex mode to endpoint mode, since I would loose root-complex functionality. Perhaps I'm missing something here. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0 of 3] KVM for PowerPC 440
On Mon, 07 Apr 2008 15:53:31 -0500 Hollis Blanchard <[EMAIL PROTECTED]> wrote: > Implement initial support for KVM for PowerPC 440. There are just two small > prerequisite patches, and then the bulk of the code can't be split easily. > > Please review; I would like to submit these for 2.6.26. There is plenty of > work > to do, both functional and optimization, but this code is sufficient to run > unmodified 440 Linux guests on a 440 Linux host. What's your favorite bike > shed > color? Who's tree are you looking to get this patch set into? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v5] Add idle wait support for 44x platforms
On Tue, 08 Apr 2008 11:49:14 -0500 Jerone Young <[EMAIL PROTECTED]> wrote: > 2 files changed, 77 insertions(+), 1 deletion(-) > arch/powerpc/platforms/44x/Makefile |2 > arch/powerpc/platforms/44x/idle.c | 76 +++ > > > Updates: Now setting MSR_WE is now default > Tested on hardware platforms bamboo & sequioa and appears > things are working fine on actually hardware! > > This patch adds the ability for the CPU to go into wait state while in > cpu_idle loop. This helps virtulization solutions know when the guest Linux > kernel is in an idle state. There are two ways to do it. > > Command line > idle=spin <-- CPU will spin > idle=wait <-- set CPU into wait state when idle (default) > > > Signed-off-by: Jerone Young <[EMAIL PROTECTED]> Looks great. I'll add it to my tree shortly. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc405ep emac driver loading problem
On Thu, 10 Apr 2008 12:37:45 +0200 "M B" <[EMAIL PROTECTED]> wrote: > Hi, > I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is > already working in the kernel and Uboot with UART and ethernet is also > working. > But I can't get the emac driver (ibm_newemac) working under Linux. > On boot emac_init get's called and exits normally, but no probe or > open will get called and no network devices (except lo) are known to > the kernel. > > Do I have to do something more, than adding the mals and emacs to the > device tree? I haven't seen any 40x or 44x board in the platforms > folder doing something special for the emac. > > Any hints? You have to call of_platform_bus_probe with the various bus types for your board. See the top few functions of: arch/powerpc/platforms/40x/walnut.c for an example. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
Hi Paul, could you please add the following patches ? [PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html [PATCHv4 2/5] powerpc: Add bootwrapper function to get virtual reg from the device tree. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053859.html [PATCHv4 3/5] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053860.html [PATCHv4 4/5] ep8248e: Reference SMC parameter RAM base in the device tree. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053862.html [PATCHv4 5/5] cpm2: Reset the CPM when early debugging is not enabled. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053861.html Thanks. Best regards, -- 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 pgpgSJbdTyqet.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote: > > Sure, this would be optimal. But frankly, I currently have no need for > this > non U-Boot mode, and therefore I didn't implement it. This can be > added later > when really needed don't you think? It can... but on the other hand, it's not hard :-) > Good. But again, I would really prefer to first include this U-Boot > style > endpoint support and later add this independent device tree endpoint > configuration when really needed. Well, you are the one with a use case... but I do think we should differenciate a PCI in host mode vs. endpoint mode right away. We don't want the PCI stack from kicking in at all in endpoint mode, we don't want to bother with creating the PCI infrastructure and config space accessors etc... > Good idea. How about "vendor-id" and "device-id"? And we probably need > some > for endpoint mode too now. "vendor-id-endpoint" and > "device-id-endpoint"? If the host bridge in EP mode has a different name/type than the host bridge one, just 'vendor-id' and 'device-id' will do there too. > And how should we handle the backward compatibility? Should I set the > old > values as default when those properties are not available? Yup. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc405ep emac driver loading problem
On Thursday 10 April 2008, M B wrote: > I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is > already working in the kernel and Uboot with UART and ethernet is also > working. > But I can't get the emac driver (ibm_newemac) working under Linux. > On boot emac_init get's called and exits normally, but no probe or > open will get called and no network devices (except lo) are known to > the kernel. > > Do I have to do something more, than adding the mals and emacs to the > device tree? I haven't seen any 40x or 44x board in the platforms > folder doing something special for the emac. > > Any hints? How does your .config look? Please send the EMAC defines only. And send the emac/mal related dts nodes. And the current kernel boot log. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
Hi Kumar, On Thu, 10 Apr 2008 03:51:42 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > > We should probably add mpc83xx_defconfig to kisskb. However, > mpc885_ads_defconfig is an 8xx (extreme low end) and mpc85xx_defconfig > (higher end) cover two different processor families so we shouldn't > drop mpc885_ads_defconfig. Ah, ok. I misread the name as one of those that was moved (which it obviously wasn't). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpYxgpvK1Ep8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next and master branches
Paul Mackerras <[EMAIL PROTECTED]> wrote: > The following patches have been added to the master and powerpc-next > branches of the powerpc.git repository. There is a bunch that I Paul-san, Could you apply my "take 2" patchset? [PATCH 0/11] celleb: patchset for 2.6.26 (take 2) http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052989.html [PATCH 1/11] celleb: coding style cleanup http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052990.html [PATCH 2/11] cell: generalize io-workarounds code http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052991.html [PATCH 3/11] celleb: consolidate io-workarounds code http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052992.html [PATCH 4/11] celleb: move the base part for celleb support http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052993.html [PATCH 5/11] celleb: move the SCC related code for celleb http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052994.html [PATCH 6/11] celleb: move files for Beat hvcall interfaces http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052995.html [PATCH 7/11] celleb: move files for Beat mmu and iommu http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052996.html [PATCH 8/11] celleb: move a file for SPU on Beat http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052997.html [PATCH 9/11] celleb: move miscellaneous files for Beat http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052998.html [PATCH 10/11] celleb: add support for PCI Express http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052999.html [PATCH 11/11] hvcbeat: fix buffer manipulation http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053025.html Best regards, Kou Ishizaki ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
State of the MPC5200 PSC AC97 driver
Hi Sylvain, Last year you have posted a MPC5200 PSC AC97 driver patch "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface." with the following comment: > Not quite a clean driver, but it get things done (well, mostly). > Only included to be able to test functionalityi/usage of > the BestComm driver. There are various FIXMEs and commented out code here and there. Could you elaborate a bit on the overall state of the driver's functionality, which areas need improvement and attention? Seems that you mainly tested BestComm with this driver, what was the overall BestComm performance, any issues here? Did you use any specific test setup involving some dedicated application, etc.? Did anyone else tried it and/or has a updated version or can share experience? Thanks in advance. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote: > I don't think there's any difference between the _ONSTACK variant > and the normal one without lockdep, is there ? No there's not. Thus it's a guaranteed no-op and can easily go in. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
On Apr 9, 2008, at 9:25 PM, Paul Mackerras wrote:
Kumar Gala writes:
So now we can look at the vmlinux and determine the physical offset.
The question is how best to do that. Here are the options I see:
* readelf, grep and parse output
* objdump grep and parse output
* simple C program that read's the elf and reports back
Either readelf or objdump for now, and if that proves to be fragile we
can look at a C program. You could do:
readelf -l $vmlinux | grep -m 1 LOAD | awk '{print $4}'
or
objdump -p $vmlinux | grep -m 1 LOAD | awk '{print $7}'
There's not a lot of difference. Since the wrapper already uses
objdump, I think we should use objdump rather than making the wrapper
depend on an additional program (readelf).
The other questions is if we'd ever have a vmlinux with more than one
PT_LOAD PHDR. If so which one do we use (the one with the lowest
physical address)?
I think we would take the first one.
Ok. I've reworked this patch and sent in the new patch series.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 12/12] [POWERPC] 85xx: Add support for relocatble 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 either be at compile time or runtime (CONFIG_RELOCATABLE). Currently we are limited to running at a physical address that is module 256M. This is due to how we map TLBs to cover lowmem and should be fixed up to allow 64M or maybe even 16M alignment in the future. All the magic for this support is accomplished by proper initializating of the kernel memory subsystem properly and ARCH_PFN_OFFSET. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- 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/init_32.c|4 +- 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 +++ include/asm-powerpc/pgtable-ppc32.h |5 +-- 11 files changed, 134 insertions(+), 25 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index c12111d..9f35569 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -633,21 +633,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 + default "0x0200" if PPC_STD_MMU && CRASH_DUMP + default "0x" + +config PHYSICAL_ALIGN + hex + default "0x1000" if FSL_BOOKE + help + This value puts the alignment restrictions on physical address + where kernel is loaded and run from. Kernel is compiled for an + address which meets above alignment restriction. + config TASK_SIZE_BOOL bool "Set custom user task size" depends on ADVANCED_OPTIONS @@ -694,9 +749,17 @@ config PIN_TLB endmenu if PPC64 +config PAGE_OFFSET + hex + default "0xc000" config KERNEL_START hex + default "0xc200" if CRASH_DUMP default "0xc000" +config PHYSICAL_START + hex + default "0x0200" if CRASH_DUMP + default "0x" endif source "net/
[PATCH 10/12] [POWERPC] Update linker script to properly set physical addresses
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much stolen from how x86 does things in their linker
scripts.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/vmlinux.lds.S | 47 ++---
include/asm-powerpc/page.h|1 +
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index b5a76bc..0c3000b 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -31,7 +31,7 @@ SECTIONS
*/
/* Text and gots */
- .text : {
+ .text : AT(ADDR(.text) - LOAD_OFFSET) {
ALIGN_FUNCTION();
*(.text.head)
_text = .;
@@ -56,7 +56,7 @@ SECTIONS
RODATA
/* Exception & bug tables */
- __ex_table : {
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
*(__ex_table)
__stop___ex_table = .;
@@ -72,7 +72,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
- .init.text : {
+ .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
_einittext = .;
@@ -81,11 +81,11 @@ SECTIONS
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
*/
- .exit.text : {
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
EXIT_TEXT
}
- .init.data : {
+ .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
INIT_DATA
__vtop_table_begin = .;
*(.vtop_fixup);
@@ -101,19 +101,19 @@ SECTIONS
}
. = ALIGN(16);
- .init.setup : {
+ .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
__setup_start = .;
*(.init.setup)
__setup_end = .;
}
- .initcall.init : {
+ .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
__initcall_start = .;
INITCALLS
__initcall_end = .;
}
- .con_initcall.init : {
+ .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
@@ -122,14 +122,14 @@ SECTIONS
SECURITY_INIT
. = ALIGN(8);
- __ftr_fixup : {
+ __ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
__start___ftr_fixup = .;
*(__ftr_fixup)
__stop___ftr_fixup = .;
}
#ifdef CONFIG_PPC64
. = ALIGN(8);
- __fw_ftr_fixup : {
+ __fw_ftr_fixup : AT(ADDR(__fw_ftr_fixup) - LOAD_OFFSET) {
__start___fw_ftr_fixup = .;
*(__fw_ftr_fixup)
__stop___fw_ftr_fixup = .;
@@ -137,14 +137,14 @@ SECTIONS
#endif
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(PAGE_SIZE);
- .init.ramfs : {
+ .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
}
#endif
. = ALIGN(PAGE_SIZE);
- .data.percpu : {
+ .data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) {
__per_cpu_start = .;
*(.data.percpu)
*(.data.percpu.shared_aligned)
@@ -152,7 +152,7 @@ SECTIONS
}
. = ALIGN(8);
- .machine.desc : {
+ .machine.desc : AT(ADDR(.machine.desc) - LOAD_OFFSET) {
__machine_desc_start = . ;
*(.machine.desc)
__machine_desc_end = . ;
@@ -170,25 +170,24 @@ SECTIONS
_sdata = .;
#ifdef CONFIG_PPC32
- .data:
- {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.sdata)
*(.got.plt) *(.got)
}
#else
- .data : {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.data.rel*)
*(.toc1)
*(.branch_lt)
}
- .opd : {
+ .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
*(.opd)
}
- .got : {
+ .got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
*(.got)
*(.toc)
@@ -205,26 +204,26 @@ SECTIONS
#else
. = ALIGN(16384);
#endif
- .data.init_task : {
+ .data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
*(.data.init_task)
}
. = ALIGN(PAGE_SIZE);
- .data.page_aligned : {
+ .
[PATCH 11/12] [POWERPC] bootwrapper: use physical address in PHDR for uImage
Now that we properly set the physical address in the program header of the
vmlinux ELF we can extract it to properly set the load and entry point for
u-boot uImages. Before we always hard coded the laod & entry point to 0.
However there are situations that the kernel may be built with a non-zero
physical address.
We use objdump to extract the PHDR. We assume that there is only one
PHDR in the vmlinux of type LOAD.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/boot/wrapper |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 14a0182..d6c96d9 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -230,10 +230,13 @@ if [ -n "$version" ]; then
uboot_version="-n Linux-$version"
fi
+# physical offset of kernel image
+membase=`${CROSS}objdump -p "$kernel" | grep -m 1 LOAD | awk '{print $7}'`
+
case "$platform" in
uboot)
rm -f "$ofile"
-mkimage -A ppc -O linux -T kernel -C gzip -a -e \
+mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
$uboot_version -d "$vmz" "$ofile"
if [ -z "$cacheit" ]; then
rm -f "$vmz"
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 09/12] [POWERPC] Move phys_addr_t definition into asm/types.h
Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
places that before would have caused recursive includes.
For example to use phys_addr_t in we would have included
which would have possibly included which
includes . Wh recursive include.
CONFIG_PHYS_64BIT is a bit counterintuitive in light of ppc64 systems
and thus the config option is only used for ppc32 systems with >32-bit
physical addresses (44x, 85xx, 745x, etc.).
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/asm-powerpc/mmu-40x.h |2 --
include/asm-powerpc/mmu-44x.h |2 --
include/asm-powerpc/mmu-8xx.h |2 --
include/asm-powerpc/mmu-fsl-booke.h |6 --
include/asm-powerpc/mmu-hash32.h|2 --
include/asm-powerpc/mmu-hash64.h|3 ---
include/asm-powerpc/types.h |7 +++
7 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/include/asm-powerpc/mmu-40x.h b/include/asm-powerpc/mmu-40x.h
index 7d37f77..3d10867 100644
--- a/include/asm-powerpc/mmu-40x.h
+++ b/include/asm-powerpc/mmu-40x.h
@@ -53,8 +53,6 @@
#ifndef __ASSEMBLY__
-typedef unsigned long phys_addr_t;
-
typedef struct {
unsigned long id;
unsigned long vdso_base;
diff --git a/include/asm-powerpc/mmu-44x.h b/include/asm-powerpc/mmu-44x.h
index 62772ae..c8b02d9 100644
--- a/include/asm-powerpc/mmu-44x.h
+++ b/include/asm-powerpc/mmu-44x.h
@@ -53,8 +53,6 @@
#ifndef __ASSEMBLY__
-typedef unsigned long long phys_addr_t;
-
typedef struct {
unsigned long id;
unsigned long vdso_base;
diff --git a/include/asm-powerpc/mmu-8xx.h b/include/asm-powerpc/mmu-8xx.h
index 952bd88..9db877e 100644
--- a/include/asm-powerpc/mmu-8xx.h
+++ b/include/asm-powerpc/mmu-8xx.h
@@ -136,8 +136,6 @@
#define SPRN_M_TW 799
#ifndef __ASSEMBLY__
-typedef unsigned long phys_addr_t;
-
typedef struct {
unsigned long id;
unsigned long vdso_base;
diff --git a/include/asm-powerpc/mmu-fsl-booke.h
b/include/asm-powerpc/mmu-fsl-booke.h
index 3758000..925d93c 100644
--- a/include/asm-powerpc/mmu-fsl-booke.h
+++ b/include/asm-powerpc/mmu-fsl-booke.h
@@ -73,12 +73,6 @@
#ifndef __ASSEMBLY__
-#ifndef CONFIG_PHYS_64BIT
-typedef unsigned long phys_addr_t;
-#else
-typedef unsigned long long phys_addr_t;
-#endif
-
typedef struct {
unsigned long id;
unsigned long vdso_base;
diff --git a/include/asm-powerpc/mmu-hash32.h b/include/asm-powerpc/mmu-hash32.h
index 4bd735b..6e21ca6 100644
--- a/include/asm-powerpc/mmu-hash32.h
+++ b/include/asm-powerpc/mmu-hash32.h
@@ -84,8 +84,6 @@ typedef struct {
unsigned long vdso_base;
} mm_context_t;
-typedef unsigned long phys_addr_t;
-
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_POWERPC_MMU_HASH32_H_ */
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 2864fa3..0dff767 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -469,9 +469,6 @@ static inline unsigned long get_vsid(unsigned long context,
unsigned long ea,
VSID_MODULUS_256M)
#define KERNEL_VSID(ea)VSID_SCRAMBLE(GET_ESID(ea))
-/* Physical address used by some IO functions */
-typedef unsigned long phys_addr_t;
-
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_MMU_HASH64_H_ */
diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/types.h
index 903fd19..d853cf0 100644
--- a/include/asm-powerpc/types.h
+++ b/include/asm-powerpc/types.h
@@ -50,6 +50,13 @@ typedef struct {
__u32 u[4];
} __attribute__((aligned(16))) __vector128;
+/* Physical address used by some IO functions */
+#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
+typedef __u64 phys_addr_t;
+#else
+typedef __u32 phys_addr_t;
+#endif
+
#endif /* __ASSEMBLY__ */
#ifdef __KERNEL__
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 08/12] [POWERPC] Clean up some linker and symbol usage
* PAGE_OFFSET is not always the start of code, use _stext instead. * grab PAGE_SIZE and KERNELBASE from asm/page.h like ppc64 does. Makes the code a bit more common and provide a single place to manipulate the defines for things like kdump. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/kernel/setup_32.c|2 +- arch/powerpc/kernel/setup_64.c|2 +- arch/powerpc/kernel/vmlinux.lds.S |4 +--- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c index eac936e..d813c39 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -289,7 +289,7 @@ void __init setup_arch(char **cmdline_p) if (ppc_md.panic) setup_panic(); - init_mm.start_code = PAGE_OFFSET; + init_mm.start_code = (unsigned long)_stext; init_mm.end_code = (unsigned long) _etext; init_mm.end_data = (unsigned long) _edata; init_mm.brk = klimit; diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index 2c2d831..0205d40 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -510,7 +510,7 @@ void __init setup_arch(char **cmdline_p) if (ppc_md.panic) setup_panic(); - init_mm.start_code = PAGE_OFFSET; + init_mm.start_code = (unsigned long)_stext; init_mm.end_code = (unsigned long) _etext; init_mm.end_data = (unsigned long) _edata; init_mm.brk = klimit; diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S index 0afb9e3..b5a76bc 100644 --- a/arch/powerpc/kernel/vmlinux.lds.S +++ b/arch/powerpc/kernel/vmlinux.lds.S @@ -1,11 +1,9 @@ #ifdef CONFIG_PPC64 -#include #define PROVIDE32(x) PROVIDE(__unused__##x) #else -#define PAGE_SIZE 4096 -#define KERNELBASE CONFIG_KERNEL_START #define PROVIDE32(x) PROVIDE(x) #endif +#include #include #include -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 07/12] [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/fsl_booke_mmu.c |2 +-
arch/powerpc/mm/init_32.c | 10 +-
arch/powerpc/mm/mmu_decl.h |2 +-
arch/powerpc/mm/ppc_mmu_32.c|2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 59f6649..ada249b 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -227,5 +227,5 @@ adjust_total_lowmem(void)
__cam0 >> 20, __cam1 >> 20, __cam2 >> 20,
(total_lowmem - __cam0 - __cam1 - __cam2) >> 20);
__max_low_memory = __cam0 + __cam1 + __cam2;
- __initial_memory_limit = memstart_addr + __max_low_memory;
+ __initial_memory_limit_addr = memstart_addr + __max_low_memory;
}
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 38273e1..53e82ae 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -96,10 +96,10 @@ int __map_without_ltlbs;
unsigned long __max_low_memory = MAX_LOW_MEM;
/*
- * limit of what is accessible with initial MMU setup -
+ * address of the limit of what is accessible with initial MMU setup -
* 256MB usually, but only 16MB on 601.
*/
-unsigned long __initial_memory_limit = 0x1000;
+phys_addr_t __initial_memory_limit_addr = (phys_addr_t)0x1000;
/*
* Check for command-line options that affect what MMU_init will do.
@@ -132,10 +132,10 @@ void __init MMU_init(void)
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
- __initial_memory_limit = 0x0100;
+ __initial_memory_limit_addr = 0x0100;
/* 8xx can only access 8MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 0x50)
- __initial_memory_limit = 0x0080;
+ __initial_memory_limit_addr = 0x0080;
/* parse args from command line */
MMU_setup();
@@ -210,7 +210,7 @@ void __init *early_get_page(void)
p = alloc_bootmem_pages(PAGE_SIZE);
} else {
p = __va(lmb_alloc_base(PAGE_SIZE, PAGE_SIZE,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
}
return p;
}
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 67477e7..0480225 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -48,7 +48,7 @@ extern unsigned int num_tlbcam_entries;
extern unsigned long ioremap_bot;
extern unsigned long __max_low_memory;
-extern unsigned long __initial_memory_limit;
+extern phys_addr_t __initial_memory_limit_addr;
extern unsigned long total_memory;
extern unsigned long total_lowmem;
extern phys_addr_t memstart_addr;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 65f915c..cef9f15 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -233,7 +233,7 @@ void __init MMU_init_hw(void)
*/
if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
Hash = __va(lmb_alloc_base(Hash_size, Hash_size,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
cacheable_memzero(Hash, Hash_size);
_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 06/12] [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
Now that we have a proper variable that is the address of the top of low memory we can use it to limit the lmb allocations. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- include/asm-powerpc/lmb.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h index 028184b..6f5fdf0 100644 --- a/include/asm-powerpc/lmb.h +++ b/include/asm-powerpc/lmb.h @@ -6,8 +6,8 @@ #define LMB_DBG(fmt...) udbg_printf(fmt) #ifdef CONFIG_PPC32 -extern unsigned long __max_low_memory; -#define LMB_REAL_LIMIT __max_low_memory +extern phys_addr_t lowmem_end_addr; +#define LMB_REAL_LIMIT lowmem_end_addr #else #define LMB_REAL_LIMIT 0 #endif -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 05/12] [POWERPC] 85xx: Cleanup TLB initialization
* Determine the RPN we are running the kernel at runtime rather
than using compile time constant for initial TLB
* Cleanup adjust_total_lowmem() to respect memstart_addr and
be a bit more clear on variables that are sizes vs addresses.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_fsl_booke.S | 34 --
arch/powerpc/mm/fsl_booke_mmu.c | 37 ++---
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index d9cc2c2..9f40b3e 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -68,7 +68,9 @@ _ENTRY(_start);
mr r29,r5
mr r28,r6
mr r27,r7
+ li r25,0 /* phys kernel start (low) */
li r24,0 /* CPU number */
+ li r23,0 /* phys kernel start (high) */
/* We try to not make any assumptions about how the boot loader
* setup or used the TLBs. We invalidate all mappings from the
@@ -167,7 +169,28 @@ skpinv:addir6,r6,1 /*
Increment */
mtspr SPRN_MAS0,r7
tlbre
- /* Just modify the entry ID, EPN and RPN for the temp mapping */
+ /* grab and fixup the RPN */
+ mfspr r6,SPRN_MAS1/* extract MAS1[SIZE] */
+ rlwinm r6,r6,25,27,30
+ li r8,-1
+ addir6,r6,10
+ slw r6,r8,r6/* convert to mask */
+
+ bl 1f /* Find our address */
+1: mflrr7
+
+ mfspr r8,SPRN_MAS3
+#ifdef CONFIG_PHYS_64BIT
+ mfspr r23,SPRN_MAS7
+#endif
+ and r8,r6,r8
+ subfic r9,r6,-4096
+ and r9,r9,r7
+
+ or r25,r8,r9
+ ori r8,r25,(MAS3_SX|MAS3_SW|MAS3_SR)
+
+ /* Just modify the entry ID and EPN for the temp mapping */
lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */
rlwimi r7,r5,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r5) */
mtspr SPRN_MAS0,r7
@@ -177,12 +200,10 @@ skpinv: addir6,r6,1 /*
Increment */
ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_4K))@l
mtspr SPRN_MAS1,r6
mfspr r6,SPRN_MAS2
- lis r7,[EMAIL PROTECTED]
+ li r7,0/* temp EPN = 0 */
rlwimi r7,r6,0,20,31
mtspr SPRN_MAS2,r7
- mfspr r6,SPRN_MAS3
- rlwimi r7,r6,0,20,31
- mtspr SPRN_MAS3,r7
+ mtspr SPRN_MAS3,r8
tlbwe
xorir6,r4,1
@@ -232,8 +253,7 @@ skpinv: addir6,r6,1 /*
Increment */
ori r6,r6,[EMAIL PROTECTED]
rlwimi r6,r7,0,20,31
mtspr SPRN_MAS2,r6
- li r7,(MAS3_SX|MAS3_SW|MAS3_SR)
- mtspr SPRN_MAS3,r7
+ mtspr SPRN_MAS3,r8
tlbwe
/* 7. Jump to KERNELBASE mapping */
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 3dd0c81..59f6649 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -49,7 +49,6 @@
#include
#include
#include
-#include
#include
#include
@@ -59,7 +58,6 @@ extern void loadcam_entry(unsigned int index);
unsigned int tlbcam_index;
unsigned int num_tlbcam_entries;
static unsigned long __cam0, __cam1, __cam2;
-#define MAX_LOW_MEMCONFIG_LOWMEM_SIZE
#define NUM_TLBCAMS(16)
@@ -195,35 +193,32 @@ unsigned long __init mmu_mapin_ram(void)
void __init
adjust_total_lowmem(void)
{
- unsigned long max_low_mem = MAX_LOW_MEM;
- unsigned long cam_max = 0x1000;
- unsigned long ram;
+ phys_addr_t max_lowmem_size = __max_low_memory;
+ phys_addr_t cam_max_size = 0x1000;
+ phys_addr_t ram;
- /* adjust CAM size to max_low_mem */
- if (max_low_mem < cam_max)
- cam_max = max_low_mem;
+ /* adjust CAM size to max_lowmem_size */
+ if (max_lowmem_size < cam_max_size)
+ cam_max_size = max_lowmem_size;
- /* adjust lowmem size to max_low_mem */
- if (max_low_mem < total_lowmem)
- ram = max_low_mem;
- else
- ram = total_lowmem;
+ /* adjust lowmem size to max_lowmem_size */
+ ram = min(max_lowmem_size, total_lowmem);
/* Calculate CAM values */
__cam0 = 1UL << 2 * (__ilog2(ram) / 2);
- if (__cam0 > cam_max)
- __cam0 = cam_max;
+ if (__cam0 > cam_max_size)
+ __cam0 = cam_max_size;
ram -= __cam0;
if (ram) {
__cam1 = 1UL << 2 * (__ilog2(ram) / 2);
- if (__cam1 > cam_max)
- __cam1 = cam_max;
+ if (__cam1 > cam_max_size)
+ __cam1 = cam_max_size;
ram -= __cam1;
}
if (ram) {
__cam2 = 1UL << 2 * (__ilog2(ram) / 2);
- if (__cam2 > c
[PATCH 04/12] [POWERPC] Introduce lowmem_end_addr to distiguish from total_lowmem
total_lowmem represents the amount of low memory not the physical address
that low memory ends at. If the start of memory is at 0 it happends that
total_lowmem can be used as both the size and the address that lowmem
ends at. (technical its one byte beyond the end)
To make the code a bit more clear and deal with the case when the start of
memory isn't at physical 0, we introduce lowmem_end_addr that represents
one byte beyond the last physical address in the lowmem region.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/44x_mmu.c |2 +-
arch/powerpc/mm/init_32.c |4 +++-
arch/powerpc/mm/init_64.c |2 ++
arch/powerpc/mm/mem.c | 16 +---
arch/powerpc/mm/mmu_decl.h |1 +
5 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index 04dc087..953fb91 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -67,7 +67,7 @@ unsigned long __init mmu_mapin_ram(void)
/* Pin in enough TLBs to cover any lowmem not covered by the
* initial 256M mapping established in head_44x.S */
- for (addr = PPC_PIN_SIZE; addr < total_lowmem;
+ for (addr = PPC_PIN_SIZE; addr < lowmem_end_addr;
addr += PPC_PIN_SIZE)
ppc44x_pin_tlb(addr + PAGE_OFFSET, addr);
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index fdeadcc..38273e1 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -147,6 +147,7 @@ void __init MMU_init(void)
}
total_lowmem = total_memory = lmb_end_of_DRAM() - memstart_addr;
+ lowmem_end_addr = memstart_addr + total_lowmem;
#ifdef CONFIG_FSL_BOOKE
/* Freescale Book-E parts expect lowmem to be mapped by fixed TLB
@@ -157,9 +158,10 @@ void __init MMU_init(void)
if (total_lowmem > __max_low_memory) {
total_lowmem = __max_low_memory;
+ lowmem_end_addr = memstart_addr + total_lowmem;
#ifndef CONFIG_HIGHMEM
total_memory = total_lowmem;
- lmb_enforce_memory_limit(total_lowmem);
+ lmb_enforce_memory_limit(lowmem_end_addr);
lmb_analyze();
#endif /* CONFIG_HIGHMEM */
}
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 5f55399..9ea65d9 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -75,6 +75,8 @@
/* max amount of RAM to use */
unsigned long __max_memory;
+phys_addr_t memstart_addr;
+
void free_initmem(void)
{
unsigned long addr;
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index e3349ea..16def4d 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -216,9 +216,11 @@ void __init do_init_bootmem(void)
unsigned long total_pages;
int boot_mapsize;
- max_pfn = total_pages = lmb_end_of_DRAM() >> PAGE_SHIFT;
+ max_pfn = lmb_end_of_DRAM() >> PAGE_SHIFT;
+ total_pages = (lmb_end_of_DRAM() - memstart_addr) >> PAGE_SHIFT;
#ifdef CONFIG_HIGHMEM
total_pages = total_lowmem >> PAGE_SHIFT;
+ max_low_pfn = lowmem_end_addr >> PAGE_SHIFT;
#endif
/*
@@ -244,18 +246,18 @@ void __init do_init_bootmem(void)
* present.
*/
#ifdef CONFIG_HIGHMEM
- free_bootmem_with_active_regions(0, total_lowmem >> PAGE_SHIFT);
+ free_bootmem_with_active_regions(0, lowmem_end_addr >> PAGE_SHIFT);
/* reserve the sections we're already using */
for (i = 0; i < lmb.reserved.cnt; i++) {
unsigned long addr = lmb.reserved.region[i].base +
lmb_size_bytes(&lmb.reserved, i) - 1;
- if (addr < total_lowmem)
+ if (addr < lowmem_end_addr)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(&lmb.reserved, i),
BOOTMEM_DEFAULT);
- else if (lmb.reserved.region[i].base < total_lowmem) {
- unsigned long adjusted_size = total_lowmem -
+ else if (lmb.reserved.region[i].base < lowmem_end_addr) {
+ unsigned long adjusted_size = lowmem_end_addr -
lmb.reserved.region[i].base;
reserve_bootmem(lmb.reserved.region[i].base,
adjusted_size, BOOTMEM_DEFAULT);
@@ -325,7 +327,7 @@ void __init paging_init(void)
(top_of_ram - total_ram) >> 20);
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
- max_zone_pfns[ZONE_DMA] = total_lowmem >> PAGE_SHIFT;
+ max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
max_zone_pfns[ZONE_HIGHMEM] = top_of_ram >> PAGE_SHIFT;
#else
max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
@@ -380,7 +382,7 @@ void __init mem_init(void)
{
unsigned lon
[PATCH 03/12] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
A number of users of PPC_MEMSTART (40x, ppc_mmu_32) can just always use
0 as we don't support booting these kernels at non-zero physical addresses
since their exception vectors must be at 0 (or 0xfffx_).
For the sub-arches that support relocatable interrupt vectors (book-e) its
reasonable to have memory start at a non-zero physical address. For those
cases use the variable memstart_addr instead of the #define PPC_MEMSTART
since the only uses of PPC_MEMSTART are for initialization and in the
future we can set memstart_addr at runtime to have a relocatable kernel.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/40x_mmu.c |2 +-
arch/powerpc/mm/fsl_booke_mmu.c | 11 +--
arch/powerpc/mm/init_32.c |8
arch/powerpc/mm/mmu_decl.h |1 +
arch/powerpc/mm/pgtable_32.c|5 +++--
arch/powerpc/mm/ppc_mmu_32.c| 11 ++-
include/asm-powerpc/page_32.h |2 --
7 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index 3899ea9..cecbbc7 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -97,7 +97,7 @@ unsigned long __init mmu_mapin_ram(void)
phys_addr_t p;
v = KERNELBASE;
- p = PPC_MEMSTART;
+ p = 0;
s = total_lowmem;
if (__map_without_ltlbs)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index c93a966..3dd0c81 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -53,13 +53,12 @@
#include
#include
+#include "mmu_decl.h"
+
extern void loadcam_entry(unsigned int index);
unsigned int tlbcam_index;
unsigned int num_tlbcam_entries;
static unsigned long __cam0, __cam1, __cam2;
-extern unsigned long total_lowmem;
-extern unsigned long __max_low_memory;
-extern unsigned long __initial_memory_limit;
#define MAX_LOW_MEMCONFIG_LOWMEM_SIZE
#define NUM_TLBCAMS(16)
@@ -165,15 +164,15 @@ void invalidate_tlbcam_entry(int index)
void __init cam_mapin_ram(unsigned long cam0, unsigned long cam1,
unsigned long cam2)
{
- settlbcam(0, PAGE_OFFSET, PPC_MEMSTART, cam0, _PAGE_KERNEL, 0);
+ settlbcam(0, PAGE_OFFSET, memstart_addr, cam0, _PAGE_KERNEL, 0);
tlbcam_index++;
if (cam1) {
tlbcam_index++;
- settlbcam(1, PAGE_OFFSET+cam0, PPC_MEMSTART+cam0, cam1,
_PAGE_KERNEL, 0);
+ settlbcam(1, PAGE_OFFSET+cam0, memstart_addr+cam0, cam1,
_PAGE_KERNEL, 0);
}
if (cam2) {
tlbcam_index++;
- settlbcam(2, PAGE_OFFSET+cam0+cam1, PPC_MEMSTART+cam0+cam1,
cam2, _PAGE_KERNEL, 0);
+ settlbcam(2, PAGE_OFFSET+cam0+cam1, memstart_addr+cam0+cam1,
cam2, _PAGE_KERNEL, 0);
}
}
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 0c66a9f..fdeadcc 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -59,8 +59,9 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
unsigned long total_memory;
unsigned long total_lowmem;
-unsigned long ppc_memstart;
-unsigned long ppc_memoffset = PAGE_OFFSET;
+phys_addr_t memstart_addr;
+EXPORT_SYMBOL(memstart_addr);
+phys_addr_t lowmem_end_addr;
int boot_mapsize;
#ifdef CONFIG_PPC_PMAC
@@ -145,8 +146,7 @@ void __init MMU_init(void)
printk(KERN_WARNING "Only using first contiguous memory
region");
}
- total_memory = lmb_end_of_DRAM();
- total_lowmem = total_memory;
+ total_lowmem = total_memory = lmb_end_of_DRAM() - memstart_addr;
#ifdef CONFIG_FSL_BOOKE
/* Freescale Book-E parts expect lowmem to be mapped by fixed TLB
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index ebfd13d..5bc11f5 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -51,6 +51,7 @@ extern unsigned long __max_low_memory;
extern unsigned long __initial_memory_limit;
extern unsigned long total_memory;
extern unsigned long total_lowmem;
+extern phys_addr_t memstart_addr;
/* ...and now those things that may be slightly different between processor
* architectures. -- Dan
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index ac3390f..64c44bc 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -281,12 +281,13 @@ int map_page(unsigned long va, phys_addr_t pa, int flags)
*/
void __init mapin_ram(void)
{
- unsigned long v, p, s, f;
+ unsigned long v, s, f;
+ phys_addr_t p;
int ktext;
s = mmu_mapin_ram();
v = KERNELBASE + s;
- p = PPC_MEMSTART + s;
+ p = memstart_addr + s;
for (; s < total_lowmem; s += PAGE_SIZE) {
ktext = ((char *) v >= _stext && (char *) v < etext);
f = ktext ?_PAGE_RAM_TEXT : _PAGE_RAM;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 72de3c7..65f915c 10064
[PATCH 02/12] [POWERPC] Provide access to arch/powerpc include path on ppc64
There does not appear to be any reason that we shouldn't just have -Iarch/$(ARCH) on both ppc32 and ppc64 builds. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/Makefile | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index dd80825..e2ec4a9 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -71,13 +71,11 @@ endif LDFLAGS_vmlinux:= -Bstatic -CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -AFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc -CFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -ffixed-r2 -mmultiple -KBUILD_CPPFLAGS+= $(CPPFLAGS-y) -KBUILD_AFLAGS += $(AFLAGS-y) -KBUILD_CFLAGS += -msoft-float -pipe $(CFLAGS-y) +CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple +KBUILD_CPPFLAGS+= -Iarch/$(ARCH) +KBUILD_AFLAGS += -Iarch/$(ARCH) +KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y) CPP= $(CC) -E $(KBUILD_CFLAGS) CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__ -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 01/12] [POWERPC] Remove Kconfig option BOOT_LOAD
Nothing appears to use BOOT_LOAD so remove it as a configurable option. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig | 16 1 files changed, 0 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 625342e..c12111d 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -688,22 +688,6 @@ config CONSISTENT_SIZE hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL default "0x0020" if NOT_COHERENT_CACHE -config BOOT_LOAD_BOOL - bool "Set the boot link/load address" - depends on ADVANCED_OPTIONS && !PPC_MULTIPLATFORM - help - This option allows you to set the initial load address of the zImage - or zImage.initrd file. This can be useful if you are on a board - which has a small amount of memory. - - Say N here unless you know what you are doing. - -config BOOT_LOAD - hex "Link/load address for booting" if BOOT_LOAD_BOOL - default "0x0040" if 40x || 8xx || 8260 - default "0x0100" if 44x - default "0x0080" - config PIN_TLB bool "Pinned Kernel TLBs (860 ONLY)" depends on ADVANCED_OPTIONS && 8xx -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 00/12 v3] [POWERPC] ppc32 mm init clean and 85xx kernel reloc
* Updated the phys_addr_t patch to be a bit cleaner * reworked order of patches a bit (bootwrapper now second to last) * added patch to properly set physical address of PHDR * reverted change in prom.c to use PHYSICAL_START & klimit for lmb_reserve These patches exist in the following git tree: master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git ppc32_mm_init - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] FCC: fix confused base / offset
On Wed, Apr 09, 2008 at 12:39:48PM -0500, Scott Wood wrote:
> Sascha Hauer wrote:
>> Right, so it's probably not worth the effort. I stumbled on this while
>> porting my board to the new binding code. I was quite confused when
>> seeing this so I made this fix to understand what's going on here.
>>
>> BTW have you tested the FCC driver with the new binding code?
>
> Yes.
>
>> I do not
>> manage to get it working. Everything seems to be fine but
>> fs_enet_start_xmit does not send a packet and no interrupts are
>> arriving.
>
> What does your device tree look like?
See bottom of this mail. The board really is a 8260 based board. Our
bootloader does not fill in the clock values, so they are hardcoded. I'm
not very sure about the muram entries because the dpram is organized
slightly different on the 8260. It has some dedicated FCC space and I
don't know how to properly encode this in the device tree.
> Are all the pins and clocks set up properly?
should be. I temporarily removed all gpio setup code from the board
file, so it should be same as the bootloader leaves it.
> Does the PHY negotiate OK?
Well I put some printks into the phy_read/write functions so I can say
that it at least properly talks to the phy.
> Is any error reported in the descriptor?
No
>
> arch/ppc is going away entirely in June or so.
I'm looking forward to it ;)
Sascha
/*
* MPC8272 ADS Device Tree Source
*
* Copyright 2005 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "rsdproto";
compatible = "fsl,rsdproto";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,[EMAIL PROTECTED] {
device_type = "cpu";
reg = <0>;
d-cache-line-size = ;
i-cache-line-size = ;
d-cache-size = ;
i-cache-size = ;
timebase-frequency = ;
bus-frequency = ;
clock-frequency = ;
};
};
memory {
device_type = "memory";
reg = <0 800>;
};
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = < f000 00053000>;
// Temporary -- will go away once kernel uses ranges for
get_immrbase().
reg = ;
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 1>;
[EMAIL PROTECTED] {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 8000 800>;
};
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
clock-frequency = ;
};
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0080>;
};
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2b 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
ppc405ep emac driver loading problem
Hi, I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is already working in the kernel and Uboot with UART and ethernet is also working. But I can't get the emac driver (ibm_newemac) working under Linux. On boot emac_init get's called and exits normally, but no probe or open will get called and no network devices (except lo) are known to the kernel. Do I have to do something more, than adding the mals and emacs to the device tree? I haven't seen any 40x or 44x board in the platforms folder doing something special for the emac. Any hints? Regards Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
>
>../..
>
> Overall looks good, just a few things:
Ben, thanks for the review.
> In general, while I have nothing against the idea of reading the HW
> setup left by uboot, I wonder if it wouldn't be best to have this file
> capable of fully configuring it in either mode based on DT properties
> instead.
Sure, this would be optimal. But frankly, I currently have no need for this
non U-Boot mode, and therefore I didn't implement it. This can be added later
when really needed don't you think?
> The PCI node in endpoint mode would be called something
> different, such as "pci-endpoint" and would contain some kind of
> "endpoint-mode" property, maybe ? That way people using other
> bootloaders or even booting of straight flash kernels can still use
> this.
Good. But again, I would really prefer to first include this U-Boot style
endpoint support and later add this independent device tree endpoint
configuration when really needed.
> > +
> > + 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)); -
>
> does it work properly to setup the BARs before enabling the inbound
> mapping ?
Yes. At least I have seen no problems so far.
> > * OMRs are already reset, also disable PIMs
> > @@ -1531,14 +1569,26 @@ static void __init
> > ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port) * and device
> > IDs into it. Those are the same bogus one that the * initial code in
> > arch/ppc add. We might want to change that. */
> > - out_le16(mbase + 0x200, 0xaaa0 + port->index);
> > - out_le16(mbase + 0x202, 0xbed0 + port->index);
> > + if (!port->endpoint) {
> > + out_le16(mbase + 0x200, 0xaaa0 + port->index);
> > + out_le16(mbase + 0x202, 0xbed0 + port->index);
>
> We should probably setup the config space IDs based on some device-tree
> properties no ?
Good idea. How about "vendor-id" and "device-id"? And we probably need some
for endpoint mode too now. "vendor-id-endpoint" and "device-id-endpoint"?
And how should we handle the backward compatibility? Should I set the old
values as default when those properties are not available?
Thanks.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Status of patches (ppc32 mm init clean and 85xx kernel reloc)
[POWERPC] Clean up some linker and symbol usage No comments. Straight forward patch. Well, it is changing behaviour. In particular, klimit is not necessarily the same as _end. It starts out initialized to &_end but then gets advanced by some allocations very early in the boot IIRC. It might be true by now that nothing reserves memory by advancing klimit any more, but if that is true then the patch description needs to mention that klimit is no longer used and this patch makes it no longer usable. In fact in that case you should remove all mention of klimit. Also, this patch means that the region from PHYSICAL_START to __pa(stext) is no longer reserved, which is another behaviour change that deserves to be mentioned. so I see iseries updating klimit. [POWERPC] Update linker script to properly set physical addresses You felt LOAD_OFFSET should be (CONFIG_PAGE_OFFSET - CONFIG_PHYSICAL_START). I disagreed. We need to resolve. I think you're right, actually, now, assuming that CONFIG_PHYSICAL_START is the physical address of the start of the kernel (actually, why don't you use that instead of __pa(stext) in your patch [9/11]?). I think I can just drop that change in the patch now that I look at it. My previous plan had been to get ride of PHYSICAL_START but now that we still have it I don't see any reason I need to change that particular lmb reserve. (i'll repost the full series with a minor bit of re-ordering). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Move opcodes common to CPM1 and CPM2 to include/asm-powerpc/cpm.h
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
include/asm-powerpc/cpm.h | 14 ++
include/asm-powerpc/cpm1.h | 13 -
include/asm-powerpc/cpm2.h | 11 +--
3 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index 77e39da..ede38ff 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -4,6 +4,20 @@
#include
#include
+/* Opcodes common to CPM1 and CPM2
+*/
+#define CPM_CR_INIT_TRX((ushort)0x)
+#define CPM_CR_INIT_RX ((ushort)0x0001)
+#define CPM_CR_INIT_TX ((ushort)0x0002)
+#define CPM_CR_HUNT_MODE ((ushort)0x0003)
+#define CPM_CR_STOP_TX ((ushort)0x0004)
+#define CPM_CR_GRA_STOP_TX ((ushort)0x0005)
+#define CPM_CR_RESTART_TX ((ushort)0x0006)
+#define CPM_CR_CLOSE_RX_BD ((ushort)0x0007)
+#define CPM_CR_SET_GADDR ((ushort)0x0008)
+#define CPM_CR_SET_TIMER ((ushort)0x0008)
+#define CPM_CR_STOP_IDMA ((ushort)0x000b)
+
/* Buffer descriptors used by many of the CPM protocols. */
typedef struct cpm_buf_desc {
ushort cbd_sc; /* Status and Control */
diff --git a/include/asm-powerpc/cpm1.h b/include/asm-powerpc/cpm1.h
index b2ebd6a..3df4396 100644
--- a/include/asm-powerpc/cpm1.h
+++ b/include/asm-powerpc/cpm1.h
@@ -28,19 +28,6 @@
#define CPM_CR_CHAN((ushort)0x00f0)
#define CPM_CR_FLG ((ushort)0x0001)
-/* Some commands (there are more...later)
-*/
-#define CPM_CR_INIT_TRX((ushort)0x)
-#define CPM_CR_INIT_RX ((ushort)0x0001)
-#define CPM_CR_INIT_TX ((ushort)0x0002)
-#define CPM_CR_HUNT_MODE ((ushort)0x0003)
-#define CPM_CR_STOP_TX ((ushort)0x0004)
-#define CPM_CR_GRA_STOP_TX ((ushort)0x0005)
-#define CPM_CR_RESTART_TX ((ushort)0x0006)
-#define CPM_CR_CLOSE_RX_BD ((ushort)0x0007)
-#define CPM_CR_SET_GADDR ((ushort)0x0008)
-#define CPM_CR_SET_TIMER CPM_CR_SET_GADDR
-
/* Channel numbers.
*/
#define CPM_CR_CH_SCC1 ((ushort)0x)
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index b93a53e..4c85ed9 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -71,18 +71,9 @@
#define CPM_CR_FCC_PAGE(x) (x + 0x04)
-/* Some opcodes (there are more...later)
+/* CPM2-specific opcodes (see cpm.h for common opcodes)
*/
-#define CPM_CR_INIT_TRX((ushort)0x)
-#define CPM_CR_INIT_RX ((ushort)0x0001)
-#define CPM_CR_INIT_TX ((ushort)0x0002)
-#define CPM_CR_HUNT_MODE ((ushort)0x0003)
-#define CPM_CR_STOP_TX ((ushort)0x0004)
-#define CPM_CR_GRA_STOP_TX ((ushort)0x0005)
-#define CPM_CR_RESTART_TX ((ushort)0x0006)
-#define CPM_CR_SET_GADDR ((ushort)0x0008)
#define CPM_CR_START_IDMA ((ushort)0x0009)
-#define CPM_CR_STOP_IDMA ((ushort)0x000b)
#define mk_cr_cmd(PG, SBC, MCN, OP) \
((PG << 26) | (SBC << 21) | (MCN << 6) | OP)
--
1.5.0
--
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
pgp2uZLiL9ASM.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
../..
Overall looks good, just a few things:
In general, while I have nothing against the idea of reading the HW
setup left by uboot, I wonder if it wouldn't be best to have this file
capable of fully configuring it in either mode based on DT properties
instead. The PCI node in endpoint mode would be called something
different, such as "pci-endpoint" and would contain some kind of
"endpoint-mode" property, maybe ? That way people using other
bootloaders or even booting of straight flash kernels can still use
this.
> +
> + 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));
> -
does it work properly to setup the BARs before enabling the inbound
mapping ?
> * OMRs are already reset, also disable PIMs
> @@ -1531,14 +1569,26 @@ static void __init
> ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
> * and device IDs into it. Those are the same bogus one that the
> * initial code in arch/ppc add. We might want to change that.
> */
> - out_le16(mbase + 0x200, 0xaaa0 + port->index);
> - out_le16(mbase + 0x202, 0xbed0 + port->index);
> + if (!port->endpoint) {
> + out_le16(mbase + 0x200, 0xaaa0 + port->index);
> + out_le16(mbase + 0x202, 0xbed0 + port->index);
>
We should probably setup the config space IDs based on some device-tree
properties no ?
> - /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
> - out_le32(mbase + 0x208, 0x06040001);
> + /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
> + out_le32(mbase + 0x208, 0x06040001);
> +
> + printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
> + port->index);
> + } else {
> + out_le16(mbase + 0x200, 0xeee0 + port->index);
> + out_le16(mbase + 0x202, 0xfed0 + port->index);
> +
> + /* Set Class Code to Processor/PPC */
> + out_le32(mbase + 0x208, 0x0b21);
> +
> + printk(KERN_INFO "PCIE%d: successfully set as endpoint\n",
> + port->index);
> + }
>
> - printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
> - port->index);
> return;
> fail:
> if (hose)
> @@ -1586,8 +1636,17 @@ static void __init ppc4xx_probe_pciex_bridge(struct
> device_node *np)
> }
> port->sdr_base = *pval;
>
> - /* XXX Currently, we only support root complex mode */
> - port->endpoint = 0;
> + /* Check whether the PCIe port is already configured as root-complex
> +* or as endpoint. This has been done previously in U-Boot and can
> +* be configured there dynamically by setting the "pcie_mode"
> +* environment variable (reboot necessary of course). Here an example:
> +*
> +* pcie_mode = 'RP:RP:EP'
> +*
> +* Port 0 & 1 are configured as root-complex and port 2 as endpoint.
> +* This mode will now be used in the Linux driver too.
> +*/
> + port->endpoint = is_endpoint(port);
>
> /* Fetch config space registers address */
> if (of_address_to_resource(np, 0, &port->cfg_space)) {
> --
> 1.5.4.5
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 19 5/5] Convert pfc8563 i2c driver from old style to new style
Hi Jon,
On Saturday 12 January 2008 03:47, Jon Smirl wrote:
> Convert pfc8563 i2c driver from old style to new style. The
> driver is also modified to support device tree names via the
> i2c mod alias mechanism.
The patch breaks the pfc8563 driver.
The old style driver allocated memory for a pcf8563 structure that
encapsulated an i2c_client instance. Various functions use container_of
on an i2c_client instance to get a pointer to the pcf8563 structure.
The new style driver gets rid of the pcf8563 structure allocation, as the
i2c_client structure is now allocated by I2C code.
Here is an incremental patch that fixes the issue.
From 1eac5a8e10e085c3a77c6ba7ed9dac9a39024915 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 11:12:25 +0200
Subject: [PATCH] Fix pcf8563 breakage introduced by the conversion from old
style to new style
The old style I2C driver used to allocate a pcf8563 instance that encapsulated
an i2c_client instance. The i2c_client instance is now allocated by I2C core.
This patch fixes the driver by storing the pcf8563 instance in the I2C client
data field.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
drivers/rtc/rtc-pcf8563.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index e1ea2a0..7aab24e 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -50,7 +50,7 @@
#define PCF8563_MO_C 0x80 /* century */
struct pcf8563 {
- struct i2c_client client;
+ struct rtc_device *rtc;
/*
* The meaning of MO_C bit varies by the chip type.
* From PCF8563 datasheet: this bit is toggled when the years
@@ -74,7 +74,7 @@ struct pcf8563 {
*/
static int pcf8563_get_datetime(struct i2c_client *client, struct rtc_time *tm)
{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
+ struct pcf8563 *pcf8563 = i2c_get_clientdata(client);
unsigned char buf[13] = { PCF8563_REG_ST1 };
struct i2c_msg msgs[] = {
@@ -131,7 +131,7 @@ static int pcf8563_get_datetime(struct i2c_client *client,
struct rtc_time *tm)
static int pcf8563_set_datetime(struct i2c_client *client, struct rtc_time *tm)
{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
+ struct pcf8563 *pcf8563 = i2c_get_clientdata(client);
int i, err;
unsigned char buf[9];
@@ -252,10 +252,10 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
static int pcf8563_remove(struct i2c_client *client)
{
- struct rtc_device *rtc = i2c_get_clientdata(client);
+ struct pcf8563 *pcf8563 = i2c_get_clientdata(client);
- if (rtc)
- rtc_device_unregister(rtc);
+ if (pcf8563->rtc)
+ rtc_device_unregister(pcf8563->rtc);
return 0;
}
@@ -274,26 +274,33 @@ static struct i2c_driver pcf8563_driver = {
.name = "rtc-pcf8563",
},
.id = I2C_DRIVERID_PCF8563,
- .probe = &pcf8563_probe,
- .remove = &pcf8563_remove,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
.id_table = pcf8563_id,
};
static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
- int result;
+ struct pcf8563 *pcf8563;
struct rtc_device *rtc;
+ int result;
result = pcf8563_validate_client(client);
if (result)
return result;
+ if ((pcf8563 = kzalloc(sizeof(*pcf8563), GFP_KERNEL)) == NULL)
+ return -ENOMEM;
+
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
- if (IS_ERR(rtc))
+ if (IS_ERR(rtc)) {
+ kfree(pcf8563);
return PTR_ERR(rtc);
+ }
- i2c_set_clientdata(client, rtc);
+ pcf8563->rtc = rtc;
+ i2c_set_clientdata(client, pcf8563);
return 0;
}
--
1.5.0
--
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
pgpvywGdinsP6.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - "unable to handle paging request @ 0"
Scott Wood schrieb: Andre Schwarz wrote: Scott Wood schrieb: Andre Schwarz wrote: -> find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] It looks like you have some memory corruption between here... clocksource: timebase mult[3c1] shift[22] registered !! -> check_legacy_serial_console() can't find stdout package /[EMAIL PROTECTED]/[EMAIL PROTECTED] ! !!! ...and here. -Scott Scott, are you talking about a possible hardware problem or misbehaving code ? Either. The same OF call is done in both places with the same argument, but is getting different results. Does it look like something gets overwritten during initrd extraction/movement ? Don't know. The system has 512MB RAM which means that we need 2 BAT regs to map the memory. I've found comments in Freescale u-boot header files that currently a max of 256MB is supported. I never understood why ? Could this problem be related to this ? Kim's probably be the best one to answer u-boot questions. -Scott Scott + Kim, as mentioned before I have re-built u-boot with the following modifications : - Reduce Memsize from 512 to 256MB - Skipped 2nd BAT setup dtb looks the same but memory size set to 256MB. System boots fine - this is weird ! I'm not really familiar with the powerpc tree of the kernel and far out of sync with the current development. Could you have a look at this ? Any ideas right now ? Thanks, Andre ## Booting kernel from Legacy Image at ff81 ... Image Name: 2.6.25 mvBL-M7 MPC8343 #12 Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size:2494236 Bytes = 2.4 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK ## Flattened Device Tree blob at Booting using the fdt blob at 0x60 ## Loading init Ramdisk from Legacy Image at 0100 ... Image Name: mvBC-1G uInitrd #1.1.03 Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:2654208 Bytes = 2.5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb7000, end 0ff3f000 ... OK -> early_init_devtree(c060) search "chosen", depth: 0, uname: search "chosen", depth: 1, uname: chosen Looking for initrd properties... <3>initrd_start=0xcfcb7000 initrd_end=0xcff3f000 Command line is: root=/dev/ram ro rootfstype=squashfs dt_root_size_cells = 1 dt_root_addr_cells = 1 memory scan node memory, reg size 8, data: 0 1000 2 1, - 0 , 1000 reserving: fcb7000 -> 288001 Phys. mem: 1000 -> move_device_tree <- move_device_tree Scanning CPUs ... boot cpu: logical 0 physical 0 <- early_init_devtree() Using mvBlueLYNX-M7 machine description Linux version 2.6.25-rc8-01197-g1de15bb-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #12 PREEMPT Wed Apr 9 14:40:48 CEST 2008 -> unflatten_device_tree() size is 192c, allocating... unflattening cfffe6d0... fixed up name for -> fixed up name for chosen -> chosen fixed up name for [EMAIL PROTECTED] -> wdt fixed up name for [EMAIL PROTECTED] -> ethernet-phy fixed up name for [EMAIL PROTECTED] -> ethernet-phy fixed up name for [EMAIL PROTECTED] -> ethernet fixed up name for [EMAIL PROTECTED] -> ethernet fixed up name for [EMAIL PROTECTED] -> serial fixed up name for [EMAIL PROTECTED] -> serial fixed up name for [EMAIL PROTECTED] -> pic fixed up name for [EMAIL PROTECTED] -> ppcboot_env fixed up name for [EMAIL PROTECTED] -> ppcboot_env_red fixed up name for [EMAIL PROTECTED] -> u-boot_autoscript fixed up name for [EMAIL PROTECTED] -> u-boot_autoscript_red fixed up name for [EMAIL PROTECTED] -> dtb fixed up name for [EMAIL PROTECTED] -> dtb_red fixed up name for [EMAIL PROTECTED] -> kernel fixed up name for [EMAIL PROTECTED] -> rfs fixed up name for [EMAIL PROTECTED] -> u-boot fixed up name for [EMAIL PROTECTED] -> fpga <- unflatten_device_tree() Found initrd at 0xcfcb7000:0xcff3f000 -> find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] legacy_serial_console = 0 default console speed = 115740 <- find_legacy_serial_port() console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() Adding PCI host bridge /[EMAIL PROTECTED] Found MPC83xx PCI host bridge at 0xe0008500. Firmware bus number: 0->0 ->Hose at 0xc0281000, cfg_addr=0xfdffd300,cfg_data=0xfdffd304 PCI host bridge /[EMAIL PROTECTED] (primary) ranges: MEM 0x9000..0x9fff -> 0x9000 MEM 0x8000..0x8fff -> 0x8000 Prefetch IO 0xe200..0xe20f -> 0x arch: exit Zone PFN ranges: DMA 0 ->65536 Normal 65536 ->65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->65536 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 6
