* radeonfb, dedicate memory to something else
From: Matt Sealey @ 2008-07-20 10:03 UTC (permalink / raw)
To: ppc-dev
Hi guys,
I know this isn't a PPC question, but since some of the RadeonFB developers
live here I thought best (and it's about a PPC platform).
Is there any way to hack up the RadeonFB driver - or anything related - to
reserve portions of the memory for a "fake" MTD or so, and still use the
Radeon as a graphics device? What I am talking about basically is turning
a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB
card..
I think this can be done by hacking a PCI fixup perhaps, for Efika only
in my case, whereby the memory ranges are fiddled.
Perhaps, a better solution is to use some kind of in-kernel subsystem to
"allocate" and return a 32MB segment of PCI memory (and put it in an
named rheap) but I assume other drivers can and will simply walk all
over it?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: linux BSP
From: Jerry Van Baren @ 2008-07-19 22:20 UTC (permalink / raw)
To: VenkataKrishna; +Cc: linuxppc-dev
In-Reply-To: <20080719093455.4740BDDDE9@ozlabs.org>
VenkataKrishna wrote:
> Dear Friends,
>
> I want to ………
>
> 1. How to develop linux BSP to MPC8260.
The term "BSP" (Board Support Package) is not used much in linux-land.
By BSP you are probably referring to a boot program (bootrom) and a
linux configuration (kernel/drivers).
For a bootrom, I recommend u-boot. There are several 8260 boards in the
standard u-boot repository that you can start from and customize for
your board.
If you go this route, you will want to subscribe to the u-boot-users list
https://lists.sourceforge.net/lists/listinfo/u-boot-users
For more information, sorted from general to specific:
http://www.denx.de/
http://www.denx.de/en/Software/WebHome
http://www.denx.de/wiki/UBoot/WebHome
http://www.denx.de/wiki/UBoot/Documentation
http://www.denx.de/wiki/DULG/Manual
Browse the source:
http://git.denx.de/
> 2. where can I start to develop linux BSP.
Right from the comfort of your own linux computer! (Developing under
Windows/cygwin/colinux is possible, but everything is between five times
more difficult and infinitely more difficult. NOT recommended!)
> 3. what are tools available in market to develop linux BSP.
I would recommend downloading and installing ELDK from Denx. It is a
reliable and painless cross compiler (THANKS, Wolfgang & Co.!)
ftp://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/
in particular:
ftp://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/iso/ppc-2008-04-01_freescale.iso
> Thanks Regards
> Venkatakrishna Pari
You are welcome.
gvb
^ permalink raw reply
* Re: PIXIS gpio controller and gpio flags
From: Trent Piepho @ 2008-07-19 21:08 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080718100549.GA28741@polina.dev.rtsoft.ru>
On Fri, 18 Jul 2008, Anton Vorontsov wrote:
> +int px_gpio_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
> + const void *gpio_spec)
> +{
> + if (gpio[1] & PX_GPIO_FLAG_ACTIVE_LOW)
> + px_gc->active_low |= pin2mask(*gpio);
You have a race here. What if px_gpio_xlate() is called at the same time
for different gpios? This is an easy one to fix, since you can use the
atomic bitops.
It doesn't look like you have any way to unset the active low flag. What if
I unload the leds-gpio driver (or another gpio user) and then try to use the
gpio with something else? The active low flag is stuck on! It doesn't show
in sysfs or debugfs either. That could be very confusing.
I also wonder if it's ok to have the xlate function do flag setting?
of_get_property() just gets the property, it doesn't allocate it. Same with
of_get_address() and of_get_pci_address(), they don't actually allocate or
map an address, they just get the value. of_get_gpio() doesn't allocate the
gpio, that gets done later with gpio_request(). It seems like what it's
supposed to do is just get the translated value of the gpio property.
Except, your pixis gpio xlate function sets the gpio's flags. What if one
wants to just look up a gpio number, but not allocate it? The flags will
still get set.
Most gpio users, including leds-gpio, can handle gpios being busy. If
leds-gpio can't get one of the gpios, it rolls back all the leds it did
create, doesn't drive the device and returns EBUSY. Except with
of_get_gpio() setting the flags, it will change the flags out from under
whatever had the gpio already allocated!
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Josh Boyer @ 2008-07-19 13:44 UTC (permalink / raw)
To: Victor Gallardo; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <18538794.post@talk.nabble.com>
On Fri, 18 Jul 2008 15:31:33 -0700 (PDT)
Victor Gallardo <vgallardo@amcc.com> wrote:
>
> > From what I can tell, you don't even need this patch or the defconfig.
> > Nothing differs at this point from Glacier other than the DTS. Since
> > U-Boot is your loader, it should be able to pass the different DTS to a
> > kernel that supports Cayonlands and have no issues.
> >
> > ...
> >
> > If you do want to have explicit support for Arches, that's fine. Look
> > at how Yosemite is supported. It just reuses Bamboo. You could do the
> > same.
>
> Yes, I like this idea. I'll do this.
As you might have noticed, this has generated quite a bit of discussion
on whether this is the right approach or not. If you can wait for a
week, we plan on talking it over at OLS. Then I can give you a better
idea as to whether we're going to stick with this or use a different
approach.
Overall your patches are fairly clean, so you've done a good job so
far. Have a little patience with us as we figure out the right way to
go :).
josh
^ permalink raw reply
* Re: [RFC] 4xx hardware watchpoint support
From: Josh Boyer @ 2008-07-19 13:37 UTC (permalink / raw)
To: luisgpm; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <1213992894.6635.41.camel@gargoyle>
On Fri, 20 Jun 2008 17:14:53 -0300
Luis Machado <luisgpm@linux.vnet.ibm.com> wrote:
>
> Follows a re-worked patch that unifies the handling of hardware
> watchpoint structures for DABR-based and DAC-based processors.
>
> The flow is exactly the same for DABR-based processors.
>
> As for the DAC-based code, i've eliminated the "dac" field from the
> thread structure, since now we use the "dabr" field to represent DAC1 of
> the DAC-based processors. As a consequence, i removed all the
> occurrences of "dac" throughout the code, using "dabr" in those cases.
>
> The function "set_dabr" sets the correct register (DABR OR DAC) for each
> specific processor now, instead of only setting the value for DABR-based
> processors.
>
> "do_dac" was merged with "do_dabr" as they were mostly equivalent pieces
> of code. I've moved "do_dabr" to "arch/powerpc/kernel/process.c" so it
> is visible for DAC-based code as well.
>
> Tested on a Taishan 440GX with success.
>
> Is it OK to leave it as "dabr" for both DABR and DAC? What do you think
> of the patch overall?
Aside from the comment I mention below (which really does need fixing),
the overall look of the patch seems good.
> Index: linux-2.6.25-oldpatch/arch/powerpc/kernel/process.c
> ===================================================================
> --- linux-2.6.25-oldpatch.orig/arch/powerpc/kernel/process.c 2008-06-20 02:48:19.000000000 -0700
> +++ linux-2.6.25-oldpatch/arch/powerpc/kernel/process.c 2008-06-20 02:51:16.000000000 -0700
> @@ -241,6 +241,35 @@
> }
> #endif /* CONFIG_SMP */
>
> +void do_dabr(struct pt_regs *regs, unsigned long address,
> + unsigned long error_code)
> +{
> + siginfo_t info;
> +
> +#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
> + if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
> + 11, SIGSEGV) == NOTIFY_STOP)
> + return;
> +
> + if (debugger_dabr_match(regs))
> + return;
> +#else
> + /* Clear the DAC and struct entries. One shot trigger. */
> + mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
> + | DBCR0_IDM));
This doesn't look right for how it's coded. This would be the
CONFIG_4xx || CONFIG_BOOKE case, but CONFIG_4xx includes PowerPC 405.
That has a different bit layout among the DBCR registers. Namely, on
405 you would be clearing the TDE and IAC1 events because the DAC
events are in DBCR1, not DBCR0.
<snip>
> Index: linux-2.6.25-oldpatch/arch/powerpc/kernel/signal.c
> ===================================================================
> --- linux-2.6.25-oldpatch.orig/arch/powerpc/kernel/signal.c 2008-06-20 02:48:19.000000000 -0700
> +++ linux-2.6.25-oldpatch/arch/powerpc/kernel/signal.c 2008-06-20 02:51:16.000000000 -0700
> @@ -144,8 +144,12 @@
> * user space. The DABR will have been cleared if it
> * triggered inside the kernel.
> */
> - if (current->thread.dabr)
> + if (current->thread.dabr) {
> set_dabr(current->thread.dabr);
> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> + mtspr(SPRN_DBCR0, current->thread.dbcr0);
> +#endif
This has the same problem I mention above, as the 44x bit layout is
stored in dbcr0 throughout the code.
> + }
>
> if (is32) {
> if (ka.sa.sa_flags & SA_SIGINFO)
> Index: linux-2.6.25-oldpatch/arch/powerpc/kernel/traps.c
> ===================================================================
> --- linux-2.6.25-oldpatch.orig/arch/powerpc/kernel/traps.c 2008-06-20 02:48:19.000000000 -0700
> +++ linux-2.6.25-oldpatch/arch/powerpc/kernel/traps.c 2008-06-20 02:54:37.000000000 -0700
> @@ -1045,6 +1045,21 @@
> return;
> }
> _exception(SIGTRAP, regs, TRAP_TRACE, 0);
> + } else if (debug_status & (DBSR_DAC1R | DBSR_DAC1W)) {
> + regs->msr &= ~MSR_DE;
> + printk("\nWatchpoint Triggered\n");
> + if (user_mode(regs)) {
> + current->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W |
> + DBCR0_IDM);
> + } else {
> + /* Disable DAC interupts. */
> + mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R |
> + DBSR_DAC1W | DBCR0_IDM));
> + /* Clear the DAC event. */
> + mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W));
And again here.
josh
^ permalink raw reply
* Re: No filesystem could mount root
From: mahendra varman @ 2008-07-19 13:02 UTC (permalink / raw)
To: selvamuthukumar v; +Cc: linuxppc-embedded
In-Reply-To: <790896390807190452n7197924ma07bfd4c3431eb89@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
> There are no messages from the kernel that it's trying NFS. You can
> check the boot arguments you are passing to the kernel.
>
The boot arguments are passed correctly only.
setenv bootargs console=ttyS0,57600 root=/dev/nfs
nfsroot=192.168.0.6:/root/FILESYSTEM/target/target-minimal
ip=192.168.0.200:192.168.0.6:192.168.0.1:255.255.255.0::eth0
still Iam getting the above said error
Any clue??
[-- Attachment #2: Type: text/html, Size: 639 bytes --]
^ permalink raw reply
* Re: going to OLS?
From: Josh Boyer @ 2008-07-19 12:55 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200807182355.35854.arnd@arndb.de>
On Fri, 2008-07-18 at 23:55 +0200, Arnd Bergmann wrote:
> On Friday 18 July 2008, Kumar Gala wrote:
> > Since OLS is next week I figured I see who around here is going.
> >
> > I'm always interested in putting faces to names and having a lively
> > discussions over beer.
> >
> > So if your headed to OLS respond to this thread and maybe we'll have
> > an inform PPC BoF @ a pub.
>
> I'm not going this time, but I wish you all a great time at the PPC BoF,
There is no PPC BoF (officially) this time.
josh
^ permalink raw reply
* Re: No filesystem could mount root
From: selvamuthukumar v @ 2008-07-19 11:52 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0807180700u6184562duc128049245e37fdc@mail.gmail.com>
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module
> List of all partitions:
> No filesystem could mount root, tried: ext3 ext2 msdos ntfs
There are no messages from the kernel that it's trying NFS. You can
check the boot arguments you are passing to the kernel.
^ permalink raw reply
* linux BSP
From: VenkataKrishna @ 2008-07-18 21:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
Dear Friends,
I want to ...
1. How to develop linux BSP to MPC8260.
2. where can I start to develop linux BSP.
3. what are tools available in market to develop linux BSP.
Plz suggest me about this one.
Thanks Regards
Venkatakrishna Pari
[-- Attachment #2: Type: text/html, Size: 2932 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code
From: Arnd Bergmann @ 2008-07-19 8:36 UTC (permalink / raw)
To: Jeremy Kerr
Cc: Roland Dreier, Hans Boettiger, linuxppc-dev, Peter Altevogt,
cbe-oss-dev
In-Reply-To: <200807191729.22067.jk@ozlabs.org>
On Saturday 19 July 2008, Jeremy Kerr wrote:
>
> > Ok, this is the previous version of the patch from Mark, which
> > does exactly that. Please use this one instead.
>
> So, should we add a:
>
> From: Mark Nelson <markn@au1.ibm.com>
>
Yes, of course. I keep losing this line when sending patches through
quilt and kmail.
Arnd <><
^ permalink raw reply
* Re: 32-bit kernel on PPC64 supported?
From: Marvin @ 2008-07-19 7:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann
In-Reply-To: <1216419275.7740.459.camel@pasglop>
Hi,
On Saturday 19 July 2008 00:14:35 Benjamin Herrenschmidt wrote:
> On Fri, 2008-07-18 at 20:43 +0200, Marvin wrote:
> > Hi,
> >
> > while trying to cleanup some configs/makefiles for ppc64 I noticed, that
> > CONFIG_POWER4 implies CONFIG_PPC64 and vice versa in all defconfigs.
> > So I want to boldly replace CONFIG_POWER4 by CONFIG_PPC64 - ugh.
>
> No, those are different.
>
> CONFIG_PPC64 means a 64 bits kernel.
>
> CONFIG_POWER4 means a 64 bits kernel that only runs on IBM POWER4 and
> later (ie, processors conforming to, iirc, version 2.01 or later of
> the architecture).
>
> That is, it's legal to have CONFIG_PPC64 and !CONFIG_POWER4, and this
> is even necessary if you want to boot on a POWER3 or an RS64 processor.
I don't want to replace CONFIG_POWER4 by void, but by something like
CONFIG_TUNE_POWER4 (see my previous post, one week ago). So there is
no "feature loss". CONFIG_POWER3 is used only to define HAVE_BATS, so I
thought I can clean this up.
> Now, there also used to be some 32 bits support for POWER4 and G5 but
> that has been dropped a while ago.
Ok - that's fine.
I hope to finish my patches during the weekend, so things will become more
clear.
Greetings
Marvin
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code
From: Jeremy Kerr @ 2008-07-19 7:29 UTC (permalink / raw)
To: cbe-oss-dev
Cc: Arnd Bergmann, Roland Dreier, linuxppc-dev, Peter Altevogt,
Hans Boettiger
In-Reply-To: <200807181503.35445.arnd@arndb.de>
> Ok, this is the previous version of the patch from Mark, which
> does exactly that. Please use this one instead.
So, should we add a:
From: Mark Nelson <markn@au1.ibm.com>
?
Jeremy
^ permalink raw reply
* Linux not booting on MPC8313ERDB
From: Vijay Nikam @ 2008-07-19 4:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <f234e2140807180128o13e4db1bt1db9b043c7859234@mail.gmail.com>
Hello,
I am trying to port everything (u-boot-nand.bin, uImage(kernel), jffs2
and dtb) on NAND of MPC8313ERDB board ...
I loaded u-boot-nand.bin to boot the board from NAND and it is
successful ... but the problem is in loading kernel ... the kernel
version and location is detected properly and it starts loading it but
at mounting file system it gives Magic bit mask error and finally says
kernel panic and wait for reboot ...
Could any one please provide some information to proceed ... thank you
Kind Regards,
Vijay Nikam
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Benjamin Herrenschmidt @ 2008-07-19 3:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-rt-users, Josh Triplett, linuxppc-dev, Nivedita Singhvi,
Chirag Jog, Timothy R. Chavez, Thomas Gleixner, paulmck,
linux.kernel
In-Reply-To: <Pine.LNX.4.58.0807182123510.4932@gandalf.stny.rr.com>
> There's lots of semantics that are changed with -rt that should make
> everything still work ;-) Some spinlocks remain real spinlocks, but we
> shouldn't have a problem with most being mutexes.
>
> There's some cases that uses per CPU variables or other per cpu actions
> that require a special CPU_LOCK that protects the data in a preemption
> mode. The slab.c code in -rt handles this.
Well, there is at least in my case a whole class of code that assumes
that because the whole thing happens within a spinlock section at the
toplevel, it could not only access per_cpu variables using the
__variants, that's easy, but it also assumes that it can add things bit
by bit as it gets called at the lower level to that per-cpu cache. It's
not actually prepared for possibly migrating to another CPU right in the
middle.
I need to review that stuff a bit. I think we fixed some of that at one
point, and we made sure that the context switch itself would flush
pending MMU batches, so it -may- be fine in that specific case.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Steven Rostedt @ 2008-07-19 1:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-rt-users, Josh Triplett, linuxppc-dev, Nivedita Singhvi,
Chirag Jog, Timothy R. Chavez, Thomas Gleixner, paulmck,
linux.kernel
In-Reply-To: <1216418730.7740.451.camel@pasglop>
On Sat, 19 Jul 2008, Benjamin Herrenschmidt wrote:
>
> > With the original patch, the pending batch does get flushed
> > in a non-preemptable region.
> > I am resending the original with just adding the necesary comments.
>
> Your comment isn't what I meant. What I meant is that if the process
> is context switched while walking the page tables, the low level powerpc
> context switch code should also perform a =EF=BB=BF__flush_tlb_pending.
>
> BTW. Is the pte_lock also not a real spinlock anymore ? That may break
> other assumptions the powerpc mm code is doing.
>
> This -rt stuff is just too scary, it changes some fundamental semantics
> of the spinlocks. yuck.
There's lots of semantics that are changed with -rt that should make
everything still work ;-) Some spinlocks remain real spinlocks, but we
shouldn't have a problem with most being mutexes.
There's some cases that uses per CPU variables or other per cpu actions
that require a special CPU_LOCK that protects the data in a preemption
mode. The slab.c code in -rt handles this.
-- Steve
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Victor Gallardo @ 2008-07-18 22:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080716075025.0bca152c@zod.rchland.ibm.com>
> From what I can tell, you don't even need this patch or the defconfig.
> Nothing differs at this point from Glacier other than the DTS. Since
> U-Boot is your loader, it should be able to pass the different DTS to a
> kernel that supports Cayonlands and have no issues.
>
> ...
>
> If you do want to have explicit support for Arches, that's fine. Look
> at how Yosemite is supported. It just reuses Bamboo. You could do the
> same.
Yes, I like this idea. I'll do this.
>> +config 460GT
>> + bool
>> + select PPC_FPU
>> + select IBM_NEW_EMAC_EMAC4
>> + select IBM_NEW_EMAC_RGMII
>> + select IBM_NEW_EMAC_ZMII
>> + select IBM_NEW_EMAC_TAH
>
> I don't see a reason to add this at all. 460EX and 460GT select the
> same set of options.
OK. I agree.
> Here you would just have:
>
> obj-$(CONFIG_ARCHES) += cayonlands.o
>> diff --git a/arch/powerpc/platforms/44x/arches.c
>> b/arch/powerpc/platforms/44x/arches.c
>> new file mode 100644
>> index 0000000..6d6aa66
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/44x/arches.c
>
> And then you don't need this file at all. Just add a
> "amcc,canyonlands" string to your root node compatible property.
OK. Will update
Thanks,
Victor Gallardo
--
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18538794.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Victor Gallardo @ 2008-07-18 22:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200807181624.43715.sr@denx.de>
OK, will do.
-Victor Gallardo
Stefan Roese wrote:
>
> On Wednesday 16 July 2008, fkan@amcc.com wrote:
>> From: Victor Gallardo <vgallard@amcc.com>
>>
>> ppc4xx: Add AMCC Arches 460GT eval board support
>>
>> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
>
> Please put a brief description of Arches in the patch description.
>
> Best regards,
> Stefan
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18538706.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 32-bit kernel on PPC64 supported?
From: Benjamin Herrenschmidt @ 2008-07-18 22:14 UTC (permalink / raw)
To: Marvin; +Cc: linuxppc-dev
In-Reply-To: <200807182043.08991.marvin24@gmx.de>
On Fri, 2008-07-18 at 20:43 +0200, Marvin wrote:
> Hi,
>
> while trying to cleanup some configs/makefiles for ppc64 I noticed, that
> CONFIG_POWER4 implies CONFIG_PPC64 and vice versa in all defconfigs.
> So I want to boldly replace CONFIG_POWER4 by CONFIG_PPC64 - ugh.
No, those are different.
CONFIG_PPC64 means a 64 bits kernel.
CONFIG_POWER4 means a 64 bits kernel that only runs on IBM POWER4 and
later (ie, processors conforming to, iirc, version 2.01 or later of
the architecture).
That is, it's legal to have CONFIG_PPC64 and !CONFIG_POWER4, and this
is even necessary if you want to boot on a POWER3 or an RS64 processor.
Now, there also used to be some 32 bits support for POWER4 and G5 but
that has been dropped a while ago.
Cheers,
Ben.
^ permalink raw reply
* Re: going to OLS?
From: Benjamin Herrenschmidt @ 2008-07-18 22:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
On Fri, 2008-07-18 at 08:35 -0500, Kumar Gala wrote:
> Since OLS is next week I figured I see who around here is going.
>
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
>
> So if your headed to OLS respond to this thread and maybe we'll have
> an inform PPC BoF @ a pub.
Won't be there, I'll drink to you guys :-) I'll be in Portland though in
Sept. for the Plumbers conf.
Ben.
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches DTS
From: Victor Gallardo @ 2008-07-18 22:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200807181624.10338.sr@denx.de>
> So its a S29GL256 with 32MBytes...
Yes.
> ... and this partition scheme is for 64MByte.
You, you are correct. I'll fix this.
> <snip>
>
>> + EMAC0: ethernet@ef600e00 {
>> + device_type = "network";
>> + compatible = "ibm,emac-460gt", "ibm,emac4";
>
>That's not correct anymore. A recent patch from Grant Erickson
[ibm_newemac:
>Parameterize EMAC Multicast Match Handling] changed these compatible
entries.
>You should use "ibm_emac4sync" here now.
OK. Will change.
>> + interrupt-parent = <&EMAC0>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*Status*/ 0 &UIC2 10 4
>> + /*Wake*/ 1 &UIC2 14 4>;
>> + reg = <ef600e00 70>;
>
> The patch mentioned above also fixed the incorrect size here. Please fix
> this
> too.
Ok. Will fix.
>SGMII, right?
Yes, that is correct. I will fix this also.
Thanks Stefan,
Victor Gallardo
--
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-DTS-tp18480767p18538522.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Benjamin Herrenschmidt @ 2008-07-18 22:05 UTC (permalink / raw)
To: Chirag Jog
Cc: linux-rt-users, Josh Triplett, Steven Rostedt, linuxppc-dev,
Nivedita Singhvi, Timothy R. Chavez, Thomas Gleixner, paulmck,
linux.kernel
In-Reply-To: <20080718101133.GO20277@linux.vnet.ibm.com>
> With the original patch, the pending batch does get flushed
> in a non-preemptable region.
> I am resending the original with just adding the necesary comments.
Your comment isn't what I meant. What I meant is that if the process
is context switched while walking the page tables, the low level powerpc
context switch code should also perform a __flush_tlb_pending.
BTW. Is the pte_lock also not a real spinlock anymore ? That may break
other assumptions the powerpc mm code is doing.
This -rt stuff is just too scary, it changes some fundamental semantics
of the spinlocks. yuck.
Ben.
^ permalink raw reply
* Re: going to OLS?
From: Arnd Bergmann @ 2008-07-18 21:55 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
On Friday 18 July 2008, Kumar Gala wrote:
> Since OLS is next week I figured I see who around here is going.
>=20
> I'm always interested in putting faces to names and having a lively =A0
> discussions over beer.
>=20
> So if your headed to OLS respond to this thread and maybe we'll have =A0
> an inform PPC BoF @ a pub.
I'm not going this time, but I wish you all a great time at the PPC BoF,
and hope to see some of you at the Linux Plumbers Conference in Portland.
Arnd <><
^ permalink raw reply
* Re: 32-bit kernel on PPC64 supported?
From: Arnd Bergmann @ 2008-07-18 21:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200807182043.08991.marvin24@gmx.de>
On Friday 18 July 2008, Marvin wrote:
> in which POWER4 is always undefined, e.g. in
> include/asm-powerpc/mmu_context.h. Maybe this is a leftover from times, where
> 64-bit kernels where not supported on Powermacs. Is this 32-bit support still
> necessary?
There is currently no 64-bit machine that is supported by current kernels,
and I don't think there is any reason to add this again.
I'm not sure what the point of your plan to replace CONFIG_POWER4 is, but
it sounds like this case is slightly different, as you remove a potential
feature, so I guess it should be a separate patch.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches DTS
From: Victor Gallardo @ 2008-07-18 21:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4880F21E.4070506@freescale.com>
>> I used the glacier.dts file as a base line. Is the
>> glacier.dts file in dts-v1 format?
>
>Does it start with a /dts-v1/ declaration?
>
>jdl
I see. I will make this change.
-Victor Gallardo
--
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-DTS-tp18480767p18537791.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: going to OLS?
From: Becky Bruce @ 2008-07-18 21:10 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev list, Gala Kumar
In-Reply-To: <20080718163338.D87BF2488A@gemini.denx.de>
On Jul 18, 2008, at 11:33 AM, Wolfgang Denk wrote:
> In message <20080718162731.GD10317@secretlab.ca> you wrote:
>>
>> If anybody wants to email me their cell phone # privately then I'll
>> collect a list and send it out to all the repliers to this thread.
>> That way you don't need to post your cell # to the mailing list for
>> the
>> world to see.
>
> BTW: will there a pre-OLS beer evening on Tuesday, or will Stefan and
> me have to sit alone in some bar?
Gosh, that would be so sad :)
I'll probably be available - have to go to FSL's Ottawa site during
the day, and might get pulled into dinner, but I hope to be free after
that. Kumar's in the same boat AFAIK.
If someone can pick a place and time, and just announce it, maybe we
can all hook up. I'd give it a go, but I've only been to Ottawa once,
and I'm afraid my drinking habits during said trip left me with
unreliable memories of drinking establishments :)
Cheers,
B
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox