* Re: boot time scheduling hile atomic
From: Benjamin Herrenschmidt @ 2005-03-16 22:28 UTC (permalink / raw)
To: Takeharu KATO; +Cc: linuxppc-dev list
In-Reply-To: <42383D85.7050108@ybb.ne.jp>
On Wed, 2005-03-16 at 23:07 +0900, Takeharu KATO wrote:
> Hi Benjamin:
>
> I can not figure out why my previous patch is more preferable than
> later one.
> Could you explain the reason of that please.
There may be other kernel bits calling syscall, it sounds saner to
always make sure we don't reschedule when in atomic (though it's dubious
that it's allowed to do syscalls in atomic regions, let's be safe
there).
In fact, we are thinking about consolidating the syscall return path and
the normal irq return path like we did on ppc64.
Ben.
^ permalink raw reply
* Re: [PATCH] compilation failure due to confliction of time_offset
From: Tom Rini @ 2005-03-16 22:22 UTC (permalink / raw)
To: Takeharu KATO; +Cc: galak, linuxppc-embedded
In-Reply-To: <42331CA8.3030400@ybb.ne.jp>
On Sun, Mar 13, 2005 at 01:45:28AM +0900, Takeharu KATO wrote:
> Hi all:
>
> I send carbon copy of the mail to maintainers of Embedded PowerPC,
> because I can not figure out who is responsible for arch/ppc/kernel/time.c.
>
> I found a trivial bug made compilation fail.
> I show error log as follows:
>
> -- error log
> arch/ppc/kernel/time.c:92: error: static declaration of 'time_offset'
> follows non-static declaration
> include/linux/timex.h:236: error: previous declaration of 'time_offset'
> was heremake[1]: *** [arch/ppc/kernel/time.o] Error 1
> make: *** [arch/ppc/kernel] Error 2
Are you certain that the 'time_offset' referenced in <linux/timex.h> is
what wants to be used in arch/ppc/kernel/time.c ? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] boot time scheduling w hile atomic fix
From: Tom Rini @ 2005-03-16 22:19 UTC (permalink / raw)
To: Takeharu KATO; +Cc: linuxppc-dev, tmm
In-Reply-To: <4236B7E5.8030402@jp.fujitsu.com>
On Tue, Mar 15, 2005 at 07:24:37PM +0900, Takeharu KATO wrote:
[snip]
> As I mentioned before, it was caused by calling kernel_thread function via
> trap call.
>
> So, I've replaced the implementation of kernel_thread with function call like as
> other architectures.
>
> I tested this patch on PowerPC440GP (ebony evaluation board).
This is a great first start. But please see
Documentation/SubmittingPatches and provide a Signed-off-by line and
resubmit. Thanks!
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: 440EP FPU patch
From: Tom Rini @ 2005-03-16 22:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <dfbb0a3397338a3abfc2f93450311b9b@freescale.com>
On Wed, Mar 16, 2005 at 01:22:48AM -0600, Kumar Gala wrote:
> Jason,
>
> Is it possible to make this against a newer tree (like a current bk
> pull). The patch doesn't apply cleanly against head.S, which I'm
> guessing is due to the SPRN changes pushed upstream recently.
>
> If I can apply it cleanly, I will get it pushed upstream.
Can one of you run say LTP on a classic box, just as a sanity test
before pushing? If not, lemme know and I'll do it :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: building ppc_htab?
From: Tom Rini @ 2005-03-16 22:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4e44f753c3a197eff3b584f24a239f06@freescale.com>
On Wed, Mar 16, 2005 at 12:57:24AM -0600, Kumar Gala wrote:
> Is there any reason not to make the following change so we build
> ppc_htab only on PPC STD MMU? This would also require fixing up
> fs/proc/proc_misc.c.
I could have sworn, but maybe my memory sucks, that we no longer messed
w/ fs/proc/proc_misc.c for any of the PPC-specific things (since in 2.6
you can do all of that proc magic in your 'driver'). So this patch
would make a great deal of sense to do, and if it lacks what I'm talking
about, we should do that part as well :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* porting linux & u-boot on Mdp Pro 8xx board
From: veikko romppainen @ 2005-03-16 21:22 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I have currently running wxWorks on Mdp Pro 823 board. Now i'm trying port
Linux on it. Firstable i have to get u-boot working on it. I hope someone
has done this.
Is there working configuration from u-boot to this board?
I have modified QS823 conf, because it looks quite similar.
Can I use VisionIce 2 and SingleStep to flash u-boot?
We dont't have BDI in our school, shame. I flashed u-boot by using Ice
starting at 0xfff00000. It seemed that it went correct place but nothing
happened when i started my board.
I suppose that I can't debug it with Ice and SingleStep.
Do i have to flash more than just u-boot.bin in right address?
(Environment?)
Do i need some reg files or prj files?
I would appreciate if someone could help me with these addresses and
configs.
Board specs:
MPC 823 66 Mhz
4Mb flash
128 Mb RAM
512 K SRAM
8 K eeprom
Mika Nieminen
_________________________________________________________________
Nopeampi kuin sähköposti. Henkilökohtaisempi kuin chat. Lataa ilmainen MSN
Messenger. http://messenger.msn.fi Lataa nyt koneellesi ilmainen MSN
Messenger.
^ permalink raw reply
* Re: [patch] fix unitilized spinlock in cpm driver when used as console
From: Greg Weeks @ 2005-03-16 18:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <f37ebc53776184342f4eb01eb23efcac@freescale.com>
Kumar Gala wrote:
> This may already be resolved by this patch which is in the latest bk
> tree.
>
> http://ozlabs.org/ppc32-patches/patch.pl?id=280
>
> - kumar
>
> On Mar 16, 2005, at 10:44 AM, Greg Weeks wrote:
>
>> Fix unitilized spinlock in the cpm scc driver when used as console.
>>
>> Signed-off-by: Greg Weeks <greg.weeks@timesys.com>
>>
>> <cpm.console.spinlock.patch><ATT247771.txt>
>
>
Yes that fixes it.
Greg Weeks
^ permalink raw reply
* Re: [PATCH 1/3] PPC440EP SoC and Bamboo board support
From: Wade Farnsworth @ 2005-03-16 18:04 UTC (permalink / raw)
To: Jason McMullan; +Cc: linuxppc-embedded
In-Reply-To: <1110993985.2987.2.camel@ad.doubleclick.net>
On Wed, 2005-03-16 at 10:26, Jason McMullan wrote:
> Do you need a 'special' toolchain to work around Errata 42 (isync before
> blrl) for user-space, or are the kernel-land fixes sufficient?
Yes, this work around also needs to be in gcc. I know this has been
fixed in MontaVista's toolchain, but I don't know if the work around has
been pushed up to the main gcc tree.
-Wade Farnsworth
^ permalink raw reply
* Re: building ppc_htab?
From: Dan Malek @ 2005-03-16 17:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4e44f753c3a197eff3b584f24a239f06@freescale.com>
On Mar 16, 2005, at 1:57 AM, Kumar Gala wrote:
> Is there any reason not to make the following change so we build
> ppc_htab only on PPC STD MMU? This would also require fixing up
> fs/proc/proc_misc.c.
Does it actually build properly this way? There used to be
functions/variables
defined there, needed for linking resolution at least. There were also
some
generally called functions, that usually didn't do anything unless
there was
a hash table used. If that is fixed up, then this is fine :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 1/3] PPC440EP SoC and Bamboo board support
From: Jason McMullan @ 2005-03-16 17:26 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <1110989349.24673.99.camel@rhino.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
Do you need a 'special' toolchain to work around Errata 42 (isync before
blrl) for user-space, or are the kernel-land fixes sufficient?
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* looking for a model for building CRAMFS(?)-based system
From: Robert P. J. Day @ 2005-03-16 16:33 UTC (permalink / raw)
To: Embedded PPC Linux list
i'm hoping someone has an example of the following that they're
willing to share.
currently, the system i've built for our 850 board incorporates
- boot loader (sadly, not u-boot, but i'm working on it)
- standard zImage.initrd.bin kernel+initrd image
... mountable JFFS2 filesystem with persistent stuff ...
obviously, with this layout, it's kind of a nuisance to update
anything individually in the initrd portion of the system, so i'd like
to at least experiment with a layout that has separate
- boot loader (ideally, u-boot)
- kernel image
- updateable (normally mounted read-only?) root filesystem
... rest of stuff the same ...
i'm going to start over at DENX with their docs since that seems to
be the canonical place to get the scoop on this but, in the meantime,
if anyone has built something like this and is willing to share, say,
their makefile so i can see how it goes together, i'd be thrilled.
if your example happens to *require* u-boot, well, perhaps so much
the better since that will give me the incentive to switch. :-)
thanks.
rday
^ permalink raw reply
* Re: [patch] fix unitilized spinlock in cpm driver when used as console
From: Kumar Gala @ 2005-03-16 16:52 UTC (permalink / raw)
To: Greg Weeks; +Cc: linuxppc-embedded
In-Reply-To: <42386274.2020504@timesys.com>
This may already be resolved by this patch which is in the latest bk
tree.
http://ozlabs.org/ppc32-patches/patch.pl?id=280
- kumar
On Mar 16, 2005, at 10:44 AM, Greg Weeks wrote:
> Fix unitilized spinlock in the cpm scc driver when used as console.
>
> Signed-off-by: Greg Weeks <greg.weeks@timesys.com>
>
> <cpm.console.spinlock.patch><ATT247771.txt>
^ permalink raw reply
* Re: [patch] fix gianfar unitilized spinlock.
From: Kumar Gala @ 2005-03-16 16:51 UTC (permalink / raw)
To: Greg Weeks; +Cc: linuxppc-embedded
In-Reply-To: <42386209.2070407@timesys.com>
Greg,
This has already been fixed in the current bk tree.
http://ozlabs.org/ppc32-patches/patch.pl?id=279
- kumar
On Mar 16, 2005, at 10:42 AM, Greg Weeks wrote:
> Fix unitilized spinlock in the gianfar tsec etherenet driver.
>
> Signed-off-by: Greg Weeks <greg.weeks@timesys.com>
> <gianfar.spinlock.patch><ATT152677.txt>
^ permalink raw reply
* [patch] fix unitilized spinlock in cpm driver when used as console
From: Greg Weeks @ 2005-03-16 16:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 122 bytes --]
Fix unitilized spinlock in the cpm scc driver when used as console.
Signed-off-by: Greg Weeks <greg.weeks@timesys.com>
[-- Attachment #2: cpm.console.spinlock.patch --]
[-- Type: text/x-patch, Size: 316 bytes --]
--- all/drivers/serial/cpm_uart/cpm_uart_core.c-orig
+++ all/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1038,6 +1038,7 @@
port =
(struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
+ spin_lock_init(&(port->lock));
pinfo = (struct uart_cpm_port *)port;
pinfo->flags |= FLAG_CONSOLE;
^ permalink raw reply
* [patch] fix gianfar unitilized spinlock.
From: Greg Weeks @ 2005-03-16 16:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 115 bytes --]
Fix unitilized spinlock in the gianfar tsec etherenet driver.
Signed-off-by: Greg Weeks <greg.weeks@timesys.com>
[-- Attachment #2: gianfar.spinlock.patch --]
[-- Type: text/x-patch, Size: 287 bytes --]
--- all/drivers/net/gianfar.c-orig
+++ all/drivers/net/gianfar.c
@@ -384,6 +384,8 @@
mii_info->mdio_read = &read_phy_reg;
mii_info->mdio_write = &write_phy_reg;
+ spin_lock_init(&mii_info->mdio_lock);
+
priv->mii_info = mii_info;
/* Reset the management interface */
^ permalink raw reply
* Re: [PATCH 1/3] PPC440EP SoC and Bamboo board support
From: Wade Farnsworth @ 2005-03-16 16:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1110937421.28218.27.camel@jdub.homelinux.org>
On Tue, 2005-03-15 at 18:43, Josh Boyer wrote:
> On Tue, 2005-03-15 at 10:17 -0700, Wade Farnsworth wrote:
> > Hello all,
> >
> > This adds support for the IBM/AMCC PPC440EP SoC and the Bamboo reference
> > board. Any comments would be appreciated.
>
> Isn't the NAND chip on that board a 64MiB chip? If so, the
> BAMBOO_NAND_FLASH_SIZE define is wrong. It should be 0x4000000.
>
> Also, are there any plans to add MTD support for the NAND controller
> found on those boards?
>
> thx,
> josh
Yes, you're right. I'll fix that.
I'm working on MTD support, including support for the NAND controller.
Thanks,
Wade Farnsworth
^ permalink raw reply
* Re: boot time scheduling hile atomic
From: Takeharu KATO @ 2005-03-16 14:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1110954539.5272.0.camel@gaston>
Hi Benjamin:
I can not figure out why my previous patch is more preferable than
later one.
Could you explain the reason of that please.
Regards,
>>
>>http://ozlabs.org/ppc32-patches/
>>
>>It changes the implementation of kernel_thread function
>>to be performed with function call.
>
>
> I prefer your previous patch. Paul hacked it a bit and will commit his
> modified version.
>
> Ben.
>
--
Takeharu KATO
^ permalink raw reply
* idma in mpc850
From: Wojciech Kromer @ 2005-03-16 11:57 UTC (permalink / raw)
To: linuxppc-embedded
is there any example of using idma channels on mpc850?
i need to speedup connection to DSP
^ permalink raw reply
* Re: [PATCH 2.6.11] ppc32: update Radstone ppc7d platform
From: James Chapman @ 2005-03-16 9:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
In-Reply-To: <20050315225050.4a236b3e.akpm@osdl.org>
Andrew Morton wrote:
> "Mark A. Greer" <mgreer@mvista.com> wrote:
>
>> +ppc7d_fixup_i2c_pdata(struct platform_device *pdev)
>> +{
>> + struct mv64xxx_i2c_pdata *pdata;
>> + int i;
>> +
>> + pdata = pdev->dev.platform_data;
>> + if (pdata == NULL) {
>> + pdata = kmalloc(GFP_KERNEL, sizeof(*pdata));
>
>
> I'll switch those kmalloc args around for you.
Wow, I'm surprised it ever worked! Thanks!
^ permalink raw reply
* Re: Newer laptops & CPU speed
From: Joerg Dorchain @ 2005-03-16 7:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1110929735.24296.38.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
On Wed, Mar 16, 2005 at 10:35:35AM +1100, Benjamin Herrenschmidt wrote:
> > My ibook G4 boots at low speed. /proc/cpuinfo shows 666MHz and a smiliar
> > bogomips value. Nevertheless, the cpu frequency scaler works, i.e. set
> > it to performance to be at high speed after boot up, or, as I currently
> > do, use the userspace governor and powernowd. All this is without your
> > patch (Did not try it yet, my ibook lacks internet) on linus' 2.6.11.
>
> Sure, I already had support for some models :) The patch extends it to
> all present and future models that are MacRISC3 and have a 7447A CPU.
When I remember my usbstick tonight, I'll give it a try.
Bye,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 440EP FPU patch
From: Kumar Gala @ 2005-03-16 7:22 UTC (permalink / raw)
To: Jason McMullan; +Cc: linuxppc-embedded
In-Reply-To: <1110925103.5937.107.camel@ad.doubleclick.net>
Jason,
Is it possible to make this against a newer tree (like a current bk
pull). The patch doesn't apply cleanly against head.S, which I'm
guessing is due to the SPRN changes pushed upstream recently.
If I can apply it cleanly, I will get it pushed upstream.
- kumar
On Mar 15, 2005, at 4:18 PM, Jason McMullan wrote:
> On Tue, 2005-03-15 at 15:09 -0600, Kumar Gala wrote:
>> 1. Change config option to CONFIG_PPC_FPU
>> 2. split out altivec support into a separate file, most likely just
>> move it into vector.S
>> 3. Get ride of the C++ comments
>
> Changes made, as per your suggestions, and new patch attached.
>
> --
> Jason McMullan <jason.mcmullan@timesys.com>
> TimeSys Corporation
>
> <cpu-ppc-fpu.patch>
^ permalink raw reply
* [PATCH] ppc32: Fix FEC ethernet intialization on MPC8540 ADS board
From: Kumar Gala @ 2005-03-16 7:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Andrew,
The PHY interrupt for the DM9121 PHY connected to the FEC ethernet port
does not work on the MPC8540 ADS board. If we tell the driver that the
PHY does not have an interrupt the FEC works properly on the MPC8540 ADS
board.
Signed-off-by: Roy Zang
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-03-16 01:08:48 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-03-16 01:08:48 -06:00
@@ -109,7 +109,7 @@
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_FEC);
- pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->board_flags = 0;
pdata->interruptPHY = MPC85xx_IRQ_EXT5;
pdata->phyid = 3;
/* fixup phy address */
^ permalink raw reply
* building ppc_htab?
From: Kumar Gala @ 2005-03-16 6:57 UTC (permalink / raw)
To: linuxppc-dev list
Is there any reason not to make the following change so we build
ppc_htab only on PPC STD MMU? This would also require fixing up
fs/proc/proc_misc.c.
--- 1.52/arch/ppc/kernel/Makefile 2005-03-13 17:29:44 -06:00
+++ edited/Makefile 2005-03-16 00:44:17 -06:00
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-extra-$(CONFIG_PPC_STD_MMU) := head.o
+extra-$(CONFIG_PPC_STD_MMU) := head.o ppc_htab.o
extra-$(CONFIG_40x) := head_4xx.o
extra-$(CONFIG_44x) := head_44x.o
extra-$(CONFIG_E500) := head_e500.o
@@ -14,7 +14,7 @@
obj-y := entry.o traps.o irq.o idle.o time.o
misc.o \
process.o signal.o ptrace.o
align.o \
semaphore.o syscalls.o setup.o \
- cputable.o ppc_htab.o perfmon.o
+ cputable.o perfmon.o
obj-$(CONFIG_6xx) += l2cr.o cpu_setup_6xx.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
obj-$(CONFIG_POWER4) += cpu_setup_power4.o
- kumar
^ permalink raw reply
* Re: [PATCH 2.6.11] ppc32: update Radstone ppc7d platform
From: Andrew Morton @ 2005-03-16 6:50 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <42376A46.2090605@mvista.com>
"Mark A. Greer" <mgreer@mvista.com> wrote:
>
> +ppc7d_fixup_i2c_pdata(struct platform_device *pdev)
> +{
> + struct mv64xxx_i2c_pdata *pdata;
> + int i;
> +
> + pdata = pdev->dev.platform_data;
> + if (pdata == NULL) {
> + pdata = kmalloc(GFP_KERNEL, sizeof(*pdata));
I'll switch those kmalloc args around for you.
^ permalink raw reply
* Re: boot time scheduling hile atomic
From: Benjamin Herrenschmidt @ 2005-03-16 6:28 UTC (permalink / raw)
To: Takeharu KATO; +Cc: linuxppc-dev list
In-Reply-To: <4237C8F0.1010605@jp.fujitsu.com>
On Wed, 2005-03-16 at 14:49 +0900, Takeharu KATO wrote:
> Hi Benjamin:
>
> I forgot writing that I've sent the revised edition of
> the patch to the PPC-Dev ML.
> Please see the patch as ``boot time scheduling w hile atomic fix''
> which I posted in 2005-03-15 from Patch tracking
> system for PowerPC Linux as follows.
>
> http://ozlabs.org/ppc32-patches/
>
> It changes the implementation of kernel_thread function
> to be performed with function call.
I prefer your previous patch. Paul hacked it a bit and will commit his
modified version.
Ben.
^ 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