* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Benjamin Herrenschmidt @ 2009-10-16 4:46 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, Linux Kernel Mailing List, Christian Borntraeger,
brueckner, Timur Tabi, Alan Cox
In-Reply-To: <4AD770A9.6070509@freescale.com>
On Thu, 2009-10-15 at 13:57 -0500, Scott Wood wrote:
> I'd say the dropping approach is quite undesirable (significant
> potential for output loss unless the buffer is huge), unless there's
> simply no way to safely spin. Hopefully there are no such backends, but
> if there are perhaps we can have them return some special code to
> indicate that.
Should never spin. Best is to keep a copy in the upper layer of the
pending data and throttle (not accept further data from tty layer) until
we have managed to flush out that "pending" buffer.
> > If we just busy loop, it actually does not matter how we let hvc_console react
> > on 0, as long as we adopt all backends to use that interface consistent.
> >
> > On the other hand, backends might want to do special magic on congestion so I
> > personally tend to let the backend loop instead of hvc_console. But I am really
> > not sure.
>
> Doing it in the backend requires the backend to know whether it's being
> called for printk or for user I/O. In the latter case, we don't want to
> spin, but rather wait for an IRQ (or poll with a timer if there's no IRQ).
Ben.
^ permalink raw reply
* Re: Problem when disabled interrupt in system call (ppc8270)
From: Benjamin Herrenschmidt @ 2009-10-16 4:43 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420910151812m3de16f67hdb756bcd1f40ddc@mail.gmail.com>
On Fri, 2009-10-16 at 09:12 +0800, wilbur.chan wrote:
> static inline unsigned long local_irq_disable(void)
> {
> unsigned long flags, zero;
>
> __asm__ __volatile__("li %1,0; lbz %0,%2(13); stb %1,%2(13)"
> : "=r" (flags), "=&r" (zero)
> : "i" (offsetof(struct paca_struct, soft_enabled))
> : "memory");
>
> return flags;
> }
This is not the variant of local_irq_disable() used on that machine :-)
The above is the 64-bit version.
Ben.
^ permalink raw reply
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Grant Likely @ 2009-10-16 3:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091016103829.323c89d7.sfr@canb.auug.org.au>
On Thu, Oct 15, 2009 at 5:38 PM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Grant,
>
> On Thu, 15 Oct 2009 11:06:15 -0600 Grant Likely <grant.likely@secretlab.c=
a> wrote:
>>
>> In the mean time, I've pushed out the current series with acked-bys
>> added to my git server. =A0I think I'm ready for things to start going
>> into linux-next. =A0Since this is the first time I've asked for a tree
>> to be added to linux-next, please let me know if you see anything
>> troublesome or problematic. =A0Here's the tree:
>>
>> The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b5=
9e9:
>> =A0 Grant Likely (1):
>> =A0 =A0 =A0 =A0 powerpc/5200: Update defconfigs
>
> Um, that commit is in no tree but yours ...
It should be in Ben's merge tree shortly, and Linus' shortly after
that, but yeah that was lazy. It was the tree that I tested my
commits on, and I should have either rebased or waited until it
actually hit mainline. I just wanted to get the ball rolling before
heading out the door for Japan.
>> are available in the git repository at:
>>
>> =A0 git://git.secretlab.ca/git/linux-2.6 next-devicetree
>
> I have added this for today, but note that it contains stuff that is not
> devicetree related. =A0Trees in linux-next should be based on other trees
> in linux-next (almost always Linus' tree, but any other nonrebasing tree
> is fine).
Thanks.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v0 1/2] DMA: fsldma: Disable DMA_INTERRUPT when Async_tx enabled
From: Dan Williams @ 2009-10-16 1:25 UTC (permalink / raw)
To: Vishnu Suresh
Cc: herbert, linux-kernel, linux-raid, linuxppc-dev, linux-crypto,
Timur Tabi
In-Reply-To: <1255588866-4133-1-git-send-email-Vishnu@freescale.com>
[ added Leo and Timur to the Cc ]
On Wed, Oct 14, 2009 at 11:41 PM, Vishnu Suresh <Vishnu@freescale.com> wrot=
e:
> This patch disables the use of DMA_INTERRUPT capability with Async_tx
>
> The fsldma produces a null transfer with DMA_INTERRUPT
> capability when used with Async_tx. When RAID devices queue
> a transaction via Async_tx, this =A0results in a hang.
>
> Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> ---
> =A0drivers/dma/fsldma.c | =A0 =A06 ++++++
> =A01 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 296f9e7..66d9b39 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1200,7 +1200,13 @@ static int __devinit of_fsl_dma_probe(struct of_de=
vice *dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0- fdev->reg.start + 1);
>
> =A0 =A0 =A0 =A0dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> +#ifndef CONFIG_ASYNC_CORE
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* The DMA_INTERRUPT async_tx is a NULL transfer, which w=
ill
> + =A0 =A0 =A0 =A0* triger a PE interrupt.
> + =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
> +#endif
> =A0 =A0 =A0 =A0dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
> =A0 =A0 =A0 =A0fdev->common.device_alloc_chan_resources =3D fsl_dma_alloc=
_chan_resources;
> =A0 =A0 =A0 =A0fdev->common.device_free_chan_resources =3D fsl_dma_free_c=
han_resources;
You are basically saying that fsl_dma_prep_interrupt() is buggy. Can
that routine be fixed rather than this piecemeal solution? If it
cannot be fixed (i.e. hardware issue) then fsl_dma_prep_interrupt()
should just be disabled/deleted altogether.
--
Dan
^ permalink raw reply
* Problem when disabled interrupt in system call (ppc8270)
From: wilbur.chan @ 2009-10-16 1:12 UTC (permalink / raw)
To: linuxppc-dev
ppc 8270, kernel 2.6.21.7
I took the following steps:
In a system call function , say , sys_reboot, interrupt was disabled
by local_irq_disable.
Then , value at the address of 0xc000050 was set to a value , say ,
0x1234. Code was like this :
sys_reboot()
{
local_irq_disable();
*(volatile unsigned long * )0xc1000050 = 0x1234;
while(1)
{
;
}
}
Finally, I reset the board (with power still on) into uboot,using
'md 0x1000050' to display the content at physical address 0x1000050,
and found that , it was not 0x1234.
However, if I delete the local_irq_disable() in sys_reboot, everything
went well---After I reset the board, 'md 0x1000050' return the value
0x1234.
So, this really puzzled me , could someone explain why this happed? Thank you.
PS:
static inline unsigned long local_irq_disable(void)
{
unsigned long flags, zero;
__asm__ __volatile__("li %1,0; lbz %0,%2(13); stb %1,%2(13)"
: "=r" (flags), "=&r" (zero)
: "i" (offsetof(struct paca_struct, soft_enabled))
: "memory");
return flags;
}
^ permalink raw reply
* Re: [PATCH 5/5 v2] kernel handling of CPU DLPAR
From: Michael Ellerman @ 2009-10-16 0:52 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AD74261.9040504@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
On Thu, 2009-10-15 at 10:40 -0500, Nathan Fontenot wrote:
> Michael Ellerman wrote:
> > On Tue, 2009-10-13 at 13:14 -0500, Nathan Fontenot wrote:
> >> This adds the capability to DLPAR add and remove CPUs from the kernel. The
> >> creates two new files /sys/devices/system/cpu/probe and
> >> /sys/devices/system/cpu/release to handle the DLPAR addition and removal of
> >> CPUs respectively.
> >
> > How does this relate to the existing cpu hotplug mechanism? Or is this
> > making the cpu exist (possible), vs marking it as online?
>
> This update makes the cpu exist, it does not mark the cpu online.
>
> >
> > Is some other platform going to want to do the same? ie. should the
> > probe/release part be in generic code?
>
> I thought about making this generic code, perhaps a follow-on patch to move
> the creation of the probe/release files to generic code to see what the
> community thinks. I would assume there would still need to be a arch and/or
> platforms specific callout to do the real work.
I'm not so worried about the code being generic, there's not much that
would be generic. More the mechanism. We don't want to add probe/release
to powerpc, and then have a different mechanism get added later by some
other platform, or generically.
But I guess you CC'ed lkml and there's not much more to do, I don't know
specifically who'd care about it.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Stephen Rothwell @ 2009-10-15 23:38 UTC (permalink / raw)
To: Grant Likely
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <fa686aa40910151006k43b07c30q1e43c3b1ae4af561@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]
Hi Grant,
On Thu, 15 Oct 2009 11:06:15 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> In the mean time, I've pushed out the current series with acked-bys
> added to my git server. I think I'm ready for things to start going
> into linux-next. Since this is the first time I've asked for a tree
> to be added to linux-next, please let me know if you see anything
> troublesome or problematic. Here's the tree:
>
> The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9:
> Grant Likely (1):
> powerpc/5200: Update defconfigs
Um, that commit is in no tree but yours ...
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux-2.6 next-devicetree
I have added this for today, but note that it contains stuff that is not
devicetree related. Trees in linux-next should be based on other trees
in linux-next (almost always Linus' tree, but any other nonrebasing tree
is fine).
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Wolfgang Denk @ 2009-10-15 23:10 UTC (permalink / raw)
To: Paul Gibson; +Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org
In-Reply-To: <26b052040910151603y8fc9b00g678d6a873083f1e7@mail.gmail.com>
Dear Paul,
In message <26b052040910151603y8fc9b00g678d6a873083f1e7@mail.gmail.com> you wrote:
>
> > The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
> > kernel contained in the LTIB with this name (dated July 2009, despite
> > the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
>
> I have diff'ed this and it is very similar to the ltib in the BSP.
> The MBX patches may be missing though. These patches can be obtained
> via the Freescale SDK for the OpenGL on the MPC5121e webpage.
Who cares. This code is about 8 (!) kernel releases behind. Scrap
it.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Were there fewer fools, knaves would starve. - Anonymous
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Paul Gibson @ 2009-10-15 23:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org
In-Reply-To: <20091015183039.A577EECA6BE@gemini.denx.de>
>> The kernel from the BSP on Freescale site is crashing on the CAN in my c=
ase
>> =A0(might be a hardware bug).
>
> I don;t think so. There are some problems in this code, for example
> the clocks seem to be wrong. Not toi menthin that the whole code is
> hoplessly old and without chance of ever being merged into mainline.
The clocks are definitely wrong, but should not cause the crashing.
The only fix I needed for the ADS512101 board was to set the clock to
66MHz, instead of 100MHz in drivers/can/mscan/mscan.c:
clk->rate =3D 66000000;
Its a hack I know.
> The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
> kernel contained in the LTIB with this name (dated July 2009, despite
> the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
I have diff'ed this and it is very similar to the ltib in the BSP.
The MBX patches may be missing though. These patches can be obtained
via the Freescale SDK for the OpenGL on the MPC5121e webpage.
Paul
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Scott Wood @ 2009-10-15 22:04 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1255597466-30976-1-git-send-email-Joakim.Tjernlund@transmode.se>
Joakim Tjernlund wrote:
> Now updated with Scott's remarks.
> There is still(probably) a trivial conflict in pte-8xx.h
>
> Joakim Tjernlund (8):
> 8xx: invalidate non present TLBs
> 8xx: Update TLB asm so it behaves as linux mm expects.
> 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
> 8xx: Fixup DAR from buggy dcbX instructions.
> 8xx: Add missing Guarded setting in DTLB Error.
> 8xx: Restore _PAGE_WRITETHRU
> 8xx: start using dcbX instructions in various copy routines
> 8xx: Remove DIRTY pte handling in DTLB Error.
>
> arch/powerpc/include/asm/pte-8xx.h | 14 +-
> arch/powerpc/kernel/head_8xx.S | 341 +++++++++++++++++++++++------------
> arch/powerpc/kernel/misc_32.S | 18 --
> arch/powerpc/lib/copy_32.S | 24 ---
> arch/powerpc/mm/fault.c | 8 +-
> 5 files changed, 238 insertions(+), 167 deletions(-)
I still see the lockup with the dcbX patch. Reverting that (and with
Rex's patch) things look OK.
-Scott
^ permalink raw reply
* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Benjamin Herrenschmidt @ 2009-10-15 20:00 UTC (permalink / raw)
To: Tim Abbott
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <alpine.DEB.1.10.0910151229340.25434@dr-wily.mit.edu>
On Thu, 2009-10-15 at 12:37 -0400, Tim Abbott wrote:
> Just to make sure I understand the nature of the problem, is the
> current
> breakage that gcc < 4.3 will _warn_ on any compilation units on ppc64
> that
> use __page_aligned data, or something worse?
>
> The cropping is clearly a potential problem, but I read the rest of
> your
> email as saying that the cropping of the alignment isn't actually a
> problem with the current kernel because the kernel is currently only
> using
> the macro with things whose size is divisible by PAGE_SIZE. However,
> I am
> not sure how to reconcile that with using the word "break" above...
Break is because we use -Werror on arch/powerpc :-)
Ben.
^ permalink raw reply
* [patch 2/5] macintosh: Remove BKL from nvram driver
From: Thomas Gleixner @ 2009-10-15 20:28 UTC (permalink / raw)
To: LKML; +Cc: Arnd Bergmann, ALan Cox, linuxppc-dev
In-Reply-To: <20091015202722.372890083@linutronix.de>
Drop the bkl from nvram_llseek() as it obviously protects nothing. The
file offset is safe in essence.
The ioctl can be converted to unlocked_ioctl because it just calls
pmac_get_partition() which reads a value from an array which was
initialized at early boot time. No need for serialization.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
---
drivers/macintosh/nvram.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6-tip/drivers/macintosh/nvram.c
===================================================================
--- linux-2.6-tip.orig/drivers/macintosh/nvram.c
+++ linux-2.6-tip/drivers/macintosh/nvram.c
@@ -13,7 +13,6 @@
#include <linux/fcntl.h>
#include <linux/nvram.h>
#include <linux/init.h>
-#include <linux/smp_lock.h>
#include <asm/uaccess.h>
#include <asm/nvram.h>
@@ -21,7 +20,6 @@
static loff_t nvram_llseek(struct file *file, loff_t offset, int origin)
{
- lock_kernel();
switch (origin) {
case 1:
offset += file->f_pos;
@@ -30,12 +28,10 @@ static loff_t nvram_llseek(struct file *
offset += NVRAM_SIZE;
break;
}
- if (offset < 0) {
- unlock_kernel();
+ if (offset < 0)
return -EINVAL;
- }
+
file->f_pos = offset;
- unlock_kernel();
return file->f_pos;
}
@@ -76,8 +72,7 @@ static ssize_t write_nvram(struct file *
return p - buf;
}
-static int nvram_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg)
+static long nvram_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
switch(cmd) {
case PMAC_NVRAM_GET_OFFSET:
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Scott Wood @ 2009-10-15 20:07 UTC (permalink / raw)
To: Felix Radensky
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Adrian Hunter
In-Reply-To: <4AD614E4.6030005@freescale.com>
Scott Wood wrote:
> Felix Radensky wrote:
>> Yes, NAND and NOR are on the same local bus controller.
>>
>> Maybe powerpc folks can provide some insight here.
>> Is it possible that simultaneous access to NOR and NAND
>> on MPC8536 can result in NAND timeouts ?
>
> I've heard other reports of such problems with eLBC, but was unable to
> reproduce it myself last time I tried. Could you reduce this down to a
> minimal set of specific reproduction instructions (e.g. eliminate UBI if
> possible, or else explain how to set up UBI)?
OK, I was able to reproduce the problem on mpc8572 simply by sticking a
read to NOR flash inside fsl_elbc_run_command -- I'm not sure what
happened last time I tried.
I suppose we'll need a special NOR mapping driver that does some sync
with the NAND driver.
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Scott Wood @ 2009-10-15 19:32 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <200910152126.28024.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> About the backends, there are some that spin until the text is delivered (e.g.
> virtio) , others can drop (e.g. iucv is a connection oriented protocol and it
> will (and has to) drop if there is no connection).
Sure, dropping due to not having a connection makes sense. That's
different from merely being busy. Can the iucv code tell the difference
between those two states?
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Christian Borntraeger @ 2009-10-15 19:26 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <4AD770A9.6070509@freescale.com>
Am Donnerstag 15 Oktober 2009 20:57:45 schrieb Scott Wood:
> Doing it in the backend requires the backend to know whether it's being
> called for printk or for user I/O. In the latter case, we don't want to
> spin, but rather wait for an IRQ (or poll with a timer if there's no IRQ).
Right. Now you have me convinced that we really should have some logic in
hvc_console because, its the only place that knows if it came from printk or
user.
About the backends, there are some that spin until the text is delivered (e.g.
virtio) , others can drop (e.g. iucv is a connection oriented protocol and it
will (and has to) drop if there is no connection).
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Scott Wood @ 2009-10-15 18:57 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <200910152041.26646.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Right. Looking at more drivers it seems that both ways (waiting and dropping)
> are used.
>
> Hmmm, if we are ok with having both options, we should let the hvc backend
> decide if it wants to drain or to discard.
I'd say the dropping approach is quite undesirable (significant
potential for output loss unless the buffer is huge), unless there's
simply no way to safely spin. Hopefully there are no such backends, but
if there are perhaps we can have them return some special code to
indicate that.
> If we just busy loop, it actually does not matter how we let hvc_console react
> on 0, as long as we adopt all backends to use that interface consistent.
>
> On the other hand, backends might want to do special magic on congestion so I
> personally tend to let the backend loop instead of hvc_console. But I am really
> not sure.
Doing it in the backend requires the backend to know whether it's being
called for printk or for user I/O. In the latter case, we don't want to
spin, but rather wait for an IRQ (or poll with a timer if there's no IRQ).
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Timur Tabi @ 2009-10-15 18:55 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Scott Wood, linuxppc-dev, brueckner, Linux Kernel Mailing List,
Alan Cox
In-Reply-To: <200910152041.26646.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Hmmm, if we are ok with having both options, we should let the hvc backend
> decide if it wants to drain or to discard.
>
> If we just busy loop, it actually does not matter how we let hvc_console react
> on 0, as long as we adopt all backends to use that interface consistent.
>
> On the other hand, backends might want to do special magic on congestion so I
> personally tend to let the backend loop instead of hvc_console. But I am really
> not sure.
The reason that we're asking for this change is that I have an hvc client driver that drops characters during heavy printk() output. hvc calls my driver, but the output buffer is still full, so the driver just returns 0.
If I add a spin-loop in the driver, then we don't need to change hvc, but now the driver is blocking during user-space print operations (via hvc_write and hvc_push).
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Christian Borntraeger @ 2009-10-15 18:41 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <20091015160906.GA3730@loki.buserror.net>
Am Donnerstag 15 Oktober 2009 18:09:06 schrieb Scott Wood:
> On Thu, Oct 15, 2009 at 01:05:47PM +0200, Christian Borntraeger wrote:
> > The fact that struct console->write returns void indicates that the
> > console layer is not interested in errors. We have two policies we can
> > implement:
> >
> > 1. drop console messages if case of congestion but keep the system going
> > 2. dont drop messages and wait, even if the system might come to a
> > complete stop
> >
> > Looking at drivers/char/vt.c
> > /* console busy or not yet initialized */
> > if (!printable)
> > return;
> > if (!spin_trylock(&printing_lock))
> > return;
> > could mean that Linux consoles should not block.
>
> That's a bit different -- the code above is testing for potential deadlocks
> within Linux (or a not-yet-initialized console), not a device that has yet
> to process the last batch of characters we threw at it. Plus, given the
> "console must be locked when we get here" comment, I'm not sure that you'll
> ever see contention on printing_lock?
>
> Serial consoles currently block when waiting for the buffer to drain:
Right. Looking at more drivers it seems that both ways (waiting and dropping)
are used.
Hmmm, if we are ok with having both options, we should let the hvc backend
decide if it wants to drain or to discard.
If we just busy loop, it actually does not matter how we let hvc_console react
on 0, as long as we adopt all backends to use that interface consistent.
On the other hand, backends might want to do special magic on congestion so I
personally tend to let the backend loop instead of hvc_console. But I am really
not sure.
Christian
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Wolfgang Denk @ 2009-10-15 18:30 UTC (permalink / raw)
To: Kári Davíðsson
Cc: linuxppc-dev@ozlabs.org, paul.gibson2074@gmail.com
In-Reply-To: <4AD70927.3030401@marel.com>
Dear =?ISO-8859-1?Q?K=E1ri_Dav=ED=F0sson?=,
In message <4AD70927.3030401@marel.com> you wrote:
>
> The kernel from the BSP on Freescale site is crashing on the CAN in my case
> (might be a hardware bug).
I don;t think so. There are some problems in this code, for example
the clocks seem to be wrong. Not toi menthin that the whole code is
hoplessly old and without chance of ever being merged into mainline.
> I could not find the source for the kernel in the BSP or on the freescale site.
Extracting just the sources from LTIB (without actually building all
of it) is indeed not exactly easy.
> I had not looked at http://git.denx.de/?p=linux-2.6-denx.git;a=shortlog;h=refs/heads/ltib-mpc5121ads-20090602
Be careful. There are several branches that are intended for reference
only, or reflect work in progress. These are usually not intended for
use real use in a project:
The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
kernel contained in the LTIB with this name (dated July 2009, despite
the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
The "mpc512x" branch contains a much smaller subset of drivers, but is
based on a more recent kernel tree (2.6.31-rc5) and is the base of our
(currently dozing) attempts to push this code into mainline.
> I am now in the progress of cloning the linux-mpc512x git from denx and building from it.
> Hopefully that will help me.
Do not do this. This old repository was intended for co-operation
with John Rigby, when he was still working for Freescale. It is a
dead end and totally unsupported. Guess I should remove it. Indeed.
Removed now. Sorry for the confusion.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy arrangement for
the people. - Eleanor Roosevelt
^ permalink raw reply
* Re: [PATCH 2/2][v2] powerpc: Make the CMM memory hotplug aware
From: Gerald Schaefer @ 2009-10-15 18:21 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev, Robert Jennings
Cc: Nick Piggin, Christoph Lameter, Mel Gorman, Martin Schwidefsky,
Badari Pulavarty, KAMEZAWA Hiroyuki, Brian King, Paul Mackerras,
Ingo Molnar, gerald.schaefer
In-Reply-To: <20091008131355.GA22118@austin.ibm.com>
Robert Jennings wrote:
>>> @@ -110,6 +125,9 @@ static long cmm_alloc_pages(long nr)
>>> cmm_dbg("Begin request for %ld pages\n", nr);
>>>
>>> while (nr) {
>>> + if (atomic_read(&hotplug_active))
>>> + break;
>>> +
>>> addr = __get_free_page(GFP_NOIO | __GFP_NOWARN |
>>> __GFP_NORETRY | __GFP_NOMEMALLOC);
>>> if (!addr)
>>> @@ -119,8 +137,10 @@ static long cmm_alloc_pages(long nr)
>>> if (!pa || pa->index >= CMM_NR_PAGES) {
>>> /* Need a new page for the page list. */
>>> spin_unlock(&cmm_lock);
>>> - npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO | __GFP_NOWARN |
>>> - __GFP_NORETRY | __GFP_NOMEMALLOC);
>>> + npa = (struct cmm_page_array *)__get_free_page(
>>> + GFP_NOIO | __GFP_NOWARN |
>>> + __GFP_NORETRY | __GFP_NOMEMALLOC |
>>> + __GFP_MOVABLE);
>>> if (!npa) {
>>> pr_info("%s: Can not allocate new page list\n", __func__);
>>> free_page(addr);
>> Why is the __GFP_MOVABLE added here, for the page list alloc, and not
>> above for the balloon page alloc?
>
> The pages allocated as __GFP_MOVABLE are used to store the list of pages
> allocated by the balloon. They reference virtual addresses and it would
> be fine for the kernel to migrate the physical pages for those, the
> balloon would not notice this.
Does page migration really work for kernel pages that were allocated
with __get_free_page()? I was wondering if we can do this on s390, where
we have a 1:1 mapping of kernel virtual to physical addresses, but
looking at migrate_pages() and friends, it seems that kernel pages
w/o mapping and rmap should not be migrateable at all. Any thoughts from
the memory migration experts?
BTW, since we have real memory hotplug support on s390, allowing us
to add and remove memory chunks to/from ZONE_MOVABLE, this basically
makes cmm ballooning in ZONE_NORMAL obsolete, so we decided not to
support memory hotplug aware cmm on s390.
Regards,
Gerald
^ permalink raw reply
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Grant Likely @ 2009-10-15 17:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091015120007.3780c59b.sfr@canb.auug.org.au>
On Wed, Oct 14, 2009 at 7:00 PM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Grant,
>
> On Tue, 06 Oct 2009 22:29:57 -0600 Grant Likely <grant.likely@secretlab.c=
a> wrote:
>>
>> Well, I've got to start somewhere...
>>
>> So here goes. =A0I've begun the work to merge and clean up the OF device
>> tree handling code and this is my first set of patches. =A0Not fully
>> tested yet, but I'm getting them out to the lists so that I can start
>> responding to comments and collecting acks. =A0This first batch isn't
>> anything exciting, just a merge of common code
>
> This all looks OK to me. =A0One thing: =A0I started in this as well some =
time
> ago and in my attempt I was hoping to avoid the ARCH ifdefs in linux/of.h
> by creating asm/of.h and moving the differing bits in there ...
Thanks Stephen.
At the moment I'm purposefully experimenting with doing arch #ifdefs
in the hope that it will lead to obvious places where the code can be
generalized even further. I'll see how it looks before I commit down
that path though.
In the mean time, I've pushed out the current series with acked-bys
added to my git server. I think I'm ready for things to start going
into linux-next. Since this is the first time I've asked for a tree
to be added to linux-next, please let me know if you see anything
troublesome or problematic. Here's the tree:
The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9=
:
Grant Likely (1):
powerpc/5200: Update defconfigs
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next-devicetree
Grant Likely (12):
of: Rework linux/of.h and asm/prom.h include ordering
of: merge phandle, ihandle and struct property
of: merge struct device_node
of: Move OF_IS_DYNAMIC and OF_MARK_DYNAMIC macros to of.h
of: add common header for flattened device tree representation
of: merge struct boot_param_header from Microblaze and PowerPC
of: merge of_node_*_flag() and set_node_proc_entry()
of: merge of_read_number() an of_read_ulong()
of: merge of_node_get(), of_node_put() and of_find_all_nodes()
of: merge of_*_flat_dt*() functions
of: merge other miscellaneous prototypes
of: merge of_find_all_nodes() implementations
arch/microblaze/include/asm/prom.h | 135 +-------------------------------=
-
arch/microblaze/kernel/head.S | 2 +-
arch/microblaze/kernel/prom.c | 23 ------
arch/powerpc/include/asm/prom.h | 147 +-------------------------------=
----
arch/powerpc/kernel/prom.c | 23 ------
arch/sparc/include/asm/prom.h | 55 +-------------
drivers/of/base.c | 26 ++++++-
include/linux/of.h | 103 +++++++++++++++++++++++++
include/linux/of_fdt.h | 86 +++++++++++++++++++++
9 files changed, 221 insertions(+), 379 deletions(-)
create mode 100644 include/linux/of_fdt.h
> I'll send out the two patches I did just to show what I mean (these are
> from before microblaze was using the OF stuff).
Got them, thanks.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Rex Feany @ 2009-10-15 16:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-1-git-send-email-Joakim.Tjernlund@transmode.se>
arch/powerpc/kernel/head_8xx.o: In function `FixupDAR':
/home/rfeany/src/lnxnm/linux-dev/arch/powerpc/kernel/head_8xx.S:576: undefined reference to `DARfix'
With all of your patches applied I have this problem:
open("/proc/mounts", O_RDONLY) = 3
fstat64(0x3, 0x7fc6ad58) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000
read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address)
exit_group(0) = ?
but it works fine with /dev/zero:
open("/dev/zero", O_RDONLY) = 3
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30001000
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
If I revert "8xx: start using dcbX instructions in various copy
routines" then it works again. I think it is the cache instructions
added to __copy_tofrom_user: reading from /dev/zero is OK (it uses
__clear_user, no dcbX), but copy_to_user() fails.
It seems stable with all but the dcbX patch applied. I haven't been able
to crash it yet, anyway :)
take care!
/rex.
^ permalink raw reply
* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Tim Abbott @ 2009-10-15 16:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <1255584772.2347.86.camel@pasglop>
On Thu, 15 Oct 2009, Benjamin Herrenschmidt wrote:
> What do you recommend I do ?
> I can ban gcc < 4.3 but that's a bit harsh :-)
Yeah, let's try to avoid that.
> I know a few people that won't be happy to be unable to build newer
> kernels with current distro gccs.
>
> Or can do the above making the macro definition drop the alignment part
> on powerpc. Will work for now, but will require great care to avoid
> subtle and nasty breakage (basically same as before)
Yeah, I'd be afraid that changing the generic __page_aligned_data might
cause unexpected problems on some other architecture.
> Or maybe I can do the above but only when using gcc < 4.3 so at least if
> the breakage happen, that will only be with older gccs ...
It sounds like from your grepping, you don't believe that dropping the
alignment part will actually cause any problems on powerpc currently?
If so, dropping the alignment part on powerpc with gcc < 4.3 seems best to
me. It limits the workaround in time (eventually gcc < 4.3 will be
history). It also limits it in scope (to powerpc), where at least you're
well aware of the issue and can pay attention to new code being added that
uses __page_aligned_data. Since most code that has page-aligned data
structures is architecture-specific, there's a good chance that any new
code that would break will be at least looked at by you (and given how few
places it is used currently, this seems pretty unlikely to actually come
up).
-Tim Abbott
^ permalink raw reply
* Please pull mpc5200 and OF changes
From: Grant Likely @ 2009-10-15 16:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Hi Ben.
Here are some OF and MPC5200 changes needed for 2.6.32. Mostly
defconfig updates and a couple of new board dts files.
Cheers,
g.
The following changes since commit 161291396e76e0832c08f617eb9bd364d1648148=
:
Linus Torvalds (1):
Linux 2.6.32-rc4
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 merge
Grant Likely (1):
powerpc/5200: Update defconfigs
Heiko Schocher (2):
mpc5200: support for the MAN mpc5200 based board uc101
mpc5200: support for the MAN mpc5200 based board mucmc52
Julia Lawall (1):
drivers/serial/mpc52xx_uart.c: Use UPIO_MEM rather than SERIAL_IO_MEM
J=E9r=F4me Pouiller (1):
of: Remove nested function
Wolfram Sang (1):
powerpc/boot/dts: drop obsolete 'fsl5200-clocking'
arch/powerpc/boot/dts/cm5200.dts | 1 -
arch/powerpc/boot/dts/digsy_mtc.dts | 1 -
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/boot/dts/media5200.dts | 2 -
arch/powerpc/boot/dts/motionpro.dts | 1 -
arch/powerpc/boot/dts/mpc5121ads.dts | 3 -
arch/powerpc/boot/dts/mucmc52.dts | 332 +++++++++++++++++++++=
++++
arch/powerpc/boot/dts/pcm030.dts | 2 -
arch/powerpc/boot/dts/pcm032.dts | 2 -
arch/powerpc/boot/dts/tqm5200.dts | 1 -
arch/powerpc/boot/dts/uc101.dts | 284 +++++++++++++++++++++
arch/powerpc/configs/52xx/cm5200_defconfig | 136 ++++++----
arch/powerpc/configs/52xx/lite5200b_defconfig | 153 ++++++++----
arch/powerpc/configs/52xx/motionpro_defconfig | 146 +++++++----
arch/powerpc/configs/52xx/pcm030_defconfig | 142 ++++++-----
arch/powerpc/configs/52xx/tqm5200_defconfig | 148 +++++++----
arch/powerpc/configs/mpc5200_defconfig | 192 ++++++++++-----
arch/powerpc/platforms/52xx/mpc5200_simple.c | 2 +
drivers/of/of_mdio.c | 13 +-
drivers/serial/mpc52xx_uart.c | 2 +-
21 files changed, 1196 insertions(+), 371 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mucmc52.dts
create mode 100644 arch/powerpc/boot/dts/uc101.dts
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Tim Abbott @ 2009-10-15 16:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <1255584772.2347.86.camel@pasglop>
On Thu, 15 Oct 2009, Benjamin Herrenschmidt wrote:
> For some weird reason, our gcc until 4.3 (fixed in 4.3) had the weird
> idea that the alignment attribute should not be allowed to force an
> alignment greater than 32k. If attempted, it would warn -and- crop the
> alignment to 32k.
[...]
> This has a few issues for us:
>
> - The patch that converted bits of powerpc to the new macro break since
> it now hits that bug
Hi Ben,
Just to make sure I understand the nature of the problem, is the current
breakage that gcc < 4.3 will _warn_ on any compilation units on ppc64 that
use __page_aligned data, or something worse?
The cropping is clearly a potential problem, but I read the rest of your
email as saying that the cropping of the alignment isn't actually a
problem with the current kernel because the kernel is currently only using
the macro with things whose size is divisible by PAGE_SIZE. However, I am
not sure how to reconcile that with using the word "break" above...
-Tim Abbott
^ 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