Hi Sean,
On Sun, 20 Jul 2008 23:47:56 -0400 Sean MacLennan <[EMAIL PROTECTED]> wrote:
>
> I guess I am too x86 centric. On the x86 an msleep does not give up the
> CPU. It does a busy wait.
I think you must be thinking of mdelay().
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED
On Sun, 20 Jul 2008 15:17:08 -0500
"Nathan Lynch" <[EMAIL PROTECTED]> wrote:
> Sean MacLennan wrote:
>
> > Why can you not msleep within a spinlock? And when was this change
> > brought in?
>
> Giving up the cpu while holding a spinlock risks locking up the system
> in the worst case -- if anothe
On Mon, 21 Jul 2008 13:24:15 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Fri, 2008-07-18 at 13:28 -0500, Nathan Lynch wrote:
> > John Reiser wrote:
> > > Andrew Morton wrote:
> > > > On Thu, 17 Jul 2008 17:19:32 -0500
> > > > Nathan Lynch <[EMAIL PROTECTED]> wrote:
> > > >
> > >
On Fri, 2008-07-18 at 13:28 -0500, Nathan Lynch wrote:
> John Reiser wrote:
> > Andrew Morton wrote:
> > > On Thu, 17 Jul 2008 17:19:32 -0500
> > > Nathan Lynch <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >> [snip]
> > >> A new aux vector entry, AT_BASE_PLATFORM, will denote the actual
> > >> har
On Thu, 2008-07-17 at 09:10 -0700, Linus Torvalds wrote:
>
> On Thu, 17 Jul 2008, Benjamin Herrenschmidt wrote:
> >
> > Should I seek somebody's ack before merging a patch like the one below ?
> >
> > I'm a bit reluctant to merge via the powerpc.git tree some changes to
> > generic files without
On Sun, 2008-07-20 at 18:16 -0700, Andrew Morton wrote:
> On Mon, 21 Jul 2008 10:57:55 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 2008-07-17 at 12:44 +0200, Nick Piggin wrote:
> > > This can be folded into powerpc-implement-pte_special.patch
> > >
> > > --
> > > Ben
On Mon, 21 Jul 2008 10:57:55 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-07-17 at 12:44 +0200, Nick Piggin wrote:
> > This can be folded into powerpc-implement-pte_special.patch
> >
> > --
> > Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
> >
On Thu, 2008-07-17 at 12:44 +0200, Nick Piggin wrote:
> This can be folded into powerpc-implement-pte_special.patch
>
> --
> Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
>
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> ---
Ack.
Andrew, will you merge this or do y
On Thu, 2008-07-17 at 21:18 +0300, Adrian Bunk wrote:
> For C code spaces versus tabs is just a religious issue,
> but for Makefiles it actually matters.
>
> This patch fixes he following errors:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:166: ***
> missing separator.
On Thu, 2008-07-17 at 21:18 +0300, Adrian Bunk wrote:
> The real option is above in the same Kconfig file.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Thanks, I'll pick that up.
Cheers,
Ben.
> ---
> 2251e74345df51309579a0a5fd8339e2f14762b9
> diff --git a/arch/powerpc/platforms/Kconfi
2008/7/20 Nathan Lynch <[EMAIL PROTECTED]>:
> Mike Mason wrote:
>>
>> This patch changes the EEH_MAX_FAILS action from panic to printing
>> an error message. Panicking under under this condition is too
>> harsh.
>> /* re-read the slot reset state */
>>
On Sun, 2008-07-20 at 20:36 +0200, Stefan Richter wrote:
> Hi all,
>
> I have to implement a workaround for a PCI device which gets into
> trouble if descriptors are located at 32bit addresses, while 31bit
> addresses are fine. I would like to avoid this workaround on machines
> on which dma_a
Mike Mason wrote:
>
> This patch changes the EEH_MAX_FAILS action from panic to printing
> an error message. Panicking under under this condition is too
> harsh. Although performance will be affected and the device may not
> recover, the system is still running, which at the very least,
> should
Sean MacLennan wrote:
> On Sun, 20 Jul 2008 11:28:36 -0700
> "Mike Mason" <[EMAIL PROTECTED]> wrote:
>
> > This patch changes the EEH_MAX_FAILS action from panic to printing an
> > error message. Panicking under under this condition is too harsh.
> > Although performance will be affected and the
Arjan van de Ven wrote:
> On Sun, 20 Jul 2008 21:25:51 +0200
> Stefan Richter <[EMAIL PROTECTED]> wrote:
>> if (dev->needs_dma_mask_workaround)
>> pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
>> allocate_something_special;
>> if (dev->needs_dma_mask_workaround)
>>
Arjan van de Ven wrote:
> On Sun, 20 Jul 2008 20:36:23 +0200
> Stefan Richter <[EMAIL PROTECTED]> wrote:
>
>> PS: I don't want to set the DMA mask of this device to
>> DMA_31BIT_MASK because that would be detrimental to other functions
>> of the device. It's a TI TSB43AB22A FireWire controller.
>
On Sun, 20 Jul 2008 21:25:51 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sun, 20 Jul 2008 20:36:23 +0200
> > Stefan Richter <[EMAIL PROTECTED]> wrote:
> >
> >> PS: I don't want to set the DMA mask of this device to
> >> DMA_31BIT_MASK because that would be de
On Sun, 20 Jul 2008 21:25:51 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
>
> Later on:
>
> if (dev->needs_dma_mask_workaround)
> pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
> allocate_something_special;
> if (dev->needs_dma_mask_workaround)
>
On Sun, 20 Jul 2008 11:28:36 -0700
"Mike Mason" <[EMAIL PROTECTED]> wrote:
> This patch changes the EEH_MAX_FAILS action from panic to printing an
> error message. Panicking under under this condition is too harsh.
> Although performance will be affected and the device may not recover,
> the syst
Hi all,
I have to implement a workaround for a PCI device which gets into
trouble if descriptors are located at 32bit addresses, while 31bit
addresses are fine. I would like to avoid this workaround on machines
on which dma_alloc_coherent() won't ever go at memory above 2 GB.
Is defined(CON
On Sun, 20 Jul 2008 20:36:23 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> PS: I don't want to set the DMA mask of this device to
> DMA_31BIT_MASK because that would be detrimental to other functions
> of the device. It's a TI TSB43AB22A FireWire controller.
Hi,
just want to mention that yo
This patch changes the EEH_MAX_FAILS action from panic to printing an error
message. Panicking under under this condition is too harsh. Although
performance will be affected and the device may not recover, the system is
still running, which at the very least, should allow for a more graceful
Can't make it but wish you guys all the best at official and unofficial
PPC BoFs/beers... I'll be heading for Linux Plumbers this autumn though.
--
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listin
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
Radeo
24 matches
Mail list logo
