On Monday 05 December 2011 09:41:55 Benjamin Herrenschmidt wrote:
> On Sun, 2011-12-04 at 22:18 +, Russell King - ARM Linux wrote:
>
> .../...
>
> > And really, I believe it would be a good cleanup if all the standard
> > definitions for atomic64 ops (like atomic64_add_negative) were also
>
+static inline int page_is_rtas_user_buf(unsigned long pfn)
+{
+ unsigned long paddr = (pfn << PAGE_SHIFT);
+ if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf +
RTAS_RMOBUF_MAX))
It probably cannot overflow with actual values of rtas_rmo_buf
and RTAS_RMOBUF_MAX, but otherwise it is
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
> From: Liu Shuo
>
> On both of large-page chip and small-page chip, we always should use
> 'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
> use a overflowed 'column' to set it.
>
> Signed-off-by: Liu Shuo
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
> + /*
> + * Freescale FCM controller has a 2K size limitation of buffer
> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> + * of chip is greater than 2048.
> +
Hi Iris,
>Remember, without barriers, CPU-B can observe CPU-A's memory accesses in *any
>possible order*. Memory accesses are not guaranteed to be *complete* by
>the time fsl_dma_tx_submit() returns!
fsl_dma_tx_submit is enclosed by spin_lock_irqsave/spin_unlock_irqrestore, when
this function
On Mon, Dec 05, 2011 at 07:52:01AM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 24, 2011 at 10:19:54PM +0200, Michael S. Tsirkin wrote:
> > > powerpc copied pci_iomap from generic code, probably to avoid
> > > pulling the rest o
On 12/04/2011 02:41 PM, Benjamin Herrenschmidt wrote:
>
> I agree with Russell, his approach is a lot easier to maintain long run,
> we should even consider converting existing definitions.
>
Thirded.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I do
Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
chips seems to cause a short lived IRQ storm (/proc/interrupts
typically shows somewhere between 300 and 1500 events). Unfortunately
this renders SysRQ over the serial console completely inoperable.
The suggested workaround in the e
The current 8250 timeout code duplicates the code path in
serial8250_default_handle_irq and then serial8250_handle_irq
i.e. reading iir, check for IIR_NO_INT, and then calling
serial8250_handle_port.
So the immediate thought is to replace the duplicated code
with a call to serial8250_default_handl
The receive_chars() was taking a pointer to a passed in LSR value
in status and knocking off bits as it processed them. But since
receive_chars isn't returning a value, we can instead pass in
a normal non-pointer value for LSR, and simply return the
residual (unprocessed) LSR once it is done.
The
Currently serial8250_handle_irq is a trivial wrapper around
serial8250_handle_port, which actually does all the work.
Since there are no other callers of serial8250_handle_port, we
can just move it inline into serial8250_handle_irq. This also
makes it more clear what functionality any custom IRQ
Since we want to promote sharing and move away from one single
uart driver with a bunch of platform specific bugfixes all
munged into one, relocate some header like material from
the C file to the header.
Signed-off-by: Paul Gortmaker
---
drivers/tty/serial/8250.c | 26
For drivers that need to construct their own IRQ handler, the
three components are seen in the current handle_port -- i.e.
Rx, Tx and modem_status.
Make these exported symbols so that "almost" 8250 UARTs can
construct their own IRQ handler with these shared components,
while working around their o
Alan wrote:
> Things like 8250_dw.c is perhaps more the style we want to be looking at
> for other devices and adjusting 8250.c as needed to export or split
> methods up so they can be used as helpers.
[...]
> Sorting out a ->handle_port override is probably ultimately the right
> thing to do a
On Sat, 2011-12-03 at 04:22 +0100, Segher Boessenkool wrote:
> > +static inline int page_is_rtas_user_buf(unsigned long pfn)
> > +{
> > + unsigned long paddr = (pfn << PAGE_SHIFT);
> > + if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf +
> > RTAS_RMOBUF_MAX))
>
> It probably cannot overflo
The minimum RMO size field in ibm,client-architecture is currently
ignored, but a future firmware version will rectify that. Since we
always get at least 128MB of RMO right now, asking for 64MB is
likely to result in boot failures.
We should bump it to at least 128MB, but considering all the boot
On Sun, 2011-12-04 at 22:18 +, Russell King - ARM Linux wrote:
.../...
> And really, I believe it would be a good cleanup if all the standard
> definitions for atomic64 ops (like atomic64_add_negative) were also
> defined in include/linux/atomic.h rather than individually in every
> atomic*.
On Sunday 04 December 2011 22:18:50 Russell King - ARM Linux wrote:
> On Sun, Dec 04, 2011 at 10:49:10PM +0100, Sven Eckelmann wrote:
> > On Sunday 04 December 2011 21:33:16 Russell King - ARM Linux wrote:
> > [...]
> >
> > > > +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL,
On Sun, Dec 04, 2011 at 10:49:10PM +0100, Sven Eckelmann wrote:
> On Sunday 04 December 2011 21:33:16 Russell King - ARM Linux wrote:
> [...]
> > > +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL, 0LL)
> >
> > I think this is rather silly - all these definitions are very similar to
On Sun, Dec 04, 2011 at 04:42:49PM +0100, Sven Eckelmann wrote:
> diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
> +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
> +#defin
On Sunday 04 December 2011 21:33:16 Russell King - ARM Linux wrote:
[...]
> > +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL, 0LL)
>
> I think this is rather silly - all these definitions are very similar to
> each other. Is there really no way to put this into include/linux/at
On Sun, 2011-12-04 at 12:48 +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 24, 2011 at 10:19:54PM +0200, Michael S. Tsirkin wrote:
> > powerpc copied pci_iomap from generic code, probably to avoid
> > pulling the rest of iomap.c in. Since that's in
> > a separate file now, we can reuse the common
Introduce an *_dec_not_zero operation. Make this a special case of
*_add_unless because batman-adv uses atomic_dec_not_zero in different
places like re-broadcast queue or aggregation queue management. There
are other non-final patches which may also want to use this macro.
Suggested-by: David S.
From: Liu Shuo
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip whose page size is larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Signed-off-by: Liu Shuo
---
v3:
-
From: Liu Shuo
When we do a non-full-page write, the length be set to FBCR should
not be 'elbc_fcm_ctrl->index', it should be 'elbc_fcm_ctrl->index -
elbc_fcm_ctrl->column'.
Signed-off-by: Liu Shuo
Signed-off-by: Li Yang
---
drivers/mtd/nand/fsl_elbc_nand.c |3 ++-
1 files changed, 2 inse
From: Liu Shuo
On both of large-page chip and small-page chip, we always should use
'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
use a overflowed 'column' to set it.
Signed-off-by: Liu Shuo
Signed-off-by: Li Yang
---
drivers/mtd/nand/fsl_elbc_nand.c | 18
On Thu, Nov 24, 2011 at 10:19:54PM +0200, Michael S. Tsirkin wrote:
> powerpc copied pci_iomap from generic code, probably to avoid
> pulling the rest of iomap.c in. Since that's in
> a separate file now, we can reuse the common implementation.
>
> The only difference is handling of nocache flag,
27 matches
Mail list logo
