RE: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

Hi, Leaping in here a little after the fact, to add a bit of background info on the hardware in case it helps. > -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: October-23-14 7:16 AM > To: Medve Emilian-EMMEDVE1 > > On Wed, Oct 22, 2014 at 09:04:54PM +0100,

RE: [PATCH 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan

Thought I'd comment too on the interrupt question for the block-level (not portal-level) node; > -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: October-23-14 7:26 AM > To: Medve Emilian-EMMEDVE1 > > [...] > > > > You also seem to have an interrupt in the e

[PATCH] powerpc: add pgprot_cached_noncoherent()

This adds a pgprot combination required by some cache-enabled IO device mappings, such as Freescale datapath (QMan and BMan) portals. Signed-off-by: Geoff Thorpe --- arch/powerpc/include/asm/pgtable.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc

[PATCH v2] powerpc: expose the multi-bit ops that underlie single-bit ops.

hese multi-bit forms is that they allow word-sized variables to essentially be their own spinlocks, eg. very useful for state machines where an atomic "flags" variable can obviate the need for any additional locking. Signed-off-by: Geoff Thorpe --- arch/powerpc/include

Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.

Benjamin Herrenschmidt wrote: > On Thu, 2009-06-18 at 16:30 -0400, Geoff Thorpe wrote: >> I've left the volatile qualifier in the generated API because I didn't >> feel so comfortable changing APIs, but I also added the "memory" clobber >> for all cases

[PATCH] powerpc: expose the multi-bit ops that underlie single-bit ops.

hese multi-bit forms is that they allow word-sized variables to essentially be their own spinlocks, eg. very useful for state machines where an atomic "flags" variable can obviate the need for any additional locking. Signed-off-by: Geoff Thorpe --- arch/powerpc/include

Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.

Hi Ben et al, Benjamin Herrenschmidt wrote: > On Tue, 2009-06-16 at 10:28 -0400, Geoff Thorpe wrote: [snip] >>> Maybe we can shrink that file significantly (and avoid the risk for >>> typos etc...) by generating them all from a macro. >>> >>> Somethi

Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.

Thanks for taking the time to look at this Ben, comments inline. Benjamin Herrenschmidt wrote: > On Tue, 2009-05-26 at 14:19 -0400, Geoff Thorpe wrote: >> NOT FOR COMMIT, THIS IS A REQUEST FOR FEEDBACK. >> >> The bitops.h functions that operate on a single bit in a bitfield

Re: [PATCH 1/2] [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()

Acked-by: Geoff Thorpe Not sure that it's the most consistent formulation, but it's definitely better than debating indefinitely. Cheers, Geoff Timur Tabi wrote: > The macro spin_event_timeout() takes a condition and timeout value > (in microseconds) as parameters. It spins

[PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.

is deemed appropriate. Feedback would be most welcome. Signed-off-by: Geoff Thorpe --- arch/powerpc/include/asm/bitops.h | 111 +++-- 1 files changed, 69 insertions(+), 42 deletions(-) diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bito

Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()

Timur Tabi wrote: > Geoff Thorpe wrote: > >> So from this user's perspective (FWIW), it would come as a surprise if >> the return value reflected the evaluated expression rather than what >> happened w.r.t. the spin/timeout. > > It shouldn't come as a sur

Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()

Timur Tabi wrote: > On Mon, May 25, 2009 at 12:46 PM, Jon Smirl wrote: > >> I just tried using this. The !rc has the effect of making the error >> return be zero instead the normal not zero. > > You're confused. It's not a "return code", it's a return value. I > guess I should have called the