On 12/08/2011 05:27 PM, Tony Breeds wrote:
> Commit 4f5ca836bef3 (HID: hid-input: add support for HID devices
> reporting Battery Strength) went into linux-next on Dec 1st since then a
> ppc6xx_defconfig has been failing with:
>
> ---
> drivers/built-in.o: In function `hidinput_cleanup_battery':
>
On 03/31/2011 01:38 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2011-03-31 at 10:21 -0700, Jeremy Fitzhardinge wrote:
>> No, its the same accessors for both, since the need to distinguish them
>> hasn't really come up. Could you put a "if (preemptable()) return;"
&g
On 03/30/2011 05:52 PM, Benjamin Herrenschmidt wrote:
> We deal with preemption already since the PTL turns into a mutex on -rt,
> so we could bring that patch into mainline. The easiest approach however
> for now would be to not do the kernel batched updates on kernel
> (solution 4), and I can sor
On 03/30/2011 01:53 PM, Andrew Morton wrote:
> On Mon, 21 Mar 2011 13:22:30 +1100
> Benjamin Herrenschmidt wrote:
>
>> On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote:
As long as the races to avoid are between map/unmap vs. access, yes, it
-should- be fine, and we used to not do de
On 03/21/2011 10:52 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-03-21 at 11:24 +0000, Jeremy Fitzhardinge wrote:
>> I'm very sorry about that, I didn't realize power was also using that
>> interface. Unfortunately, the "no preemption" definition was an
On 03/20/2011 11:53 PM, Benjamin Herrenschmidt wrote:
> On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
>> As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
>> patches in mmotm, which again assault PowerPC's expectations, and
>> cause lots of noise with CONFIG_PREEMPT=y CONF
On 12/30/2010 09:54 AM, Hugh Dickins wrote:
> With recent 2.6.37-rc, with CONFIG_PREEMPT=y CONFIG_DEBUG_PREEMPT=y
> on the PowerPC G5, I get spammed by BUG warnings each time I swapoff:
>
> BUG: using smp_processor_id() in preemptible [] code: swapoff/3974
> caller is .hpte_need_flush+0x4c/
On 03/10/2010 09:42 AM, Eric W. Biederman wrote:
All we need between the Xen and the rest of x86 is a convention
so that we never manage the same irqs. At least for domU we are
in an either/or situation so I don't see even that being a problem.
Dom0 too. This is part of the work implemen
Ian Campbell wrote:
static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
volatile void *address)
{
- return swiotlb_phys_to_bus(hwdev, virt_to_phys(address));
+ return phys_to_dma(hwdev, virt_to_phys(address));
}
void * __weak swiotlb_
contents taken from the PowerPC swiotlb patchset by
Becky Bruce.
Signed-off-by: Ian Campbell
Cc: Becky Bruce
Cc: Benjamin Herrenschmidt
Cc: Kumar Gala
Cc: FUJITA Tomonori
Cc: Ingo Molnar
Cc: Jeremy Fitzhardinge
Cc: linuxppc-dev@ozlabs.org
---
lib/swiotlb.c | 14 +-
1 files changed
Ian Campbell wrote:
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need
Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need in the calling code as well. Can we pass in both the
phys_ad
Becky Bruce wrote:
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev,
dma_addr_t addr, size_t size)
then we don't need two checking functions, address_needs_mapping and
range_needs_mapping.
It's never been clear
Ingo Molnar wrote:
* Stephen Rothwell <[EMAIL PROTECTED]> wrote:
Hi all,
Today's linux-next build (powerpc allyesconfig) failed like this:
In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
from arch/powerpc/include/asm/mmu.h:8,
from arch/powe
Benjamin Herrenschmidt wrote:
>> Ok, there are two cases where it's ok :
>>
>> 1 - in stop_machine, considering we are not touching code executed in
>> NMI handlers.
>> 2 - when using my replace_instruction_safe() which uses a temporary
>> breakpoint when doing the instruction replacement.
>>
>> In
Andi Kleen wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
>> For one thing, it looks like we're returning the wrong thing (EINVAL
>> rather than ENOTTY) across the board. This was unfortunately a common
>> misunderstanding with non-tty-related ioctls in the early days of Linux.
>>
H. Peter Anvin wrote:
> The union of things that are not typewriters and not giraffes are rather
> large, indeed.
>
> This is getting philosophical.
>
I think my point is that we're rather short of good quality open source
giraffe drivers.
J
___
17 matches
Mail list logo
