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,
From: Liu Shuo b35...@freescale.com
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 b35...@freescale.com
Signed-off-by: Li Yang
From: Liu Shuo b35...@freescale.com
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 b35...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
From: Liu Shuo shuo@freescale.com
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:
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.
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
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
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
+#define
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
each
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,
0LL)
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*.h
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
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 overflow with actual
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 and
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
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 paul.gortma...@windriver.com
---
drivers/tty/serial/8250.c |
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
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 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
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
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 don't
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 of
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 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.
+
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
From: Liu Shuo b35...@freescale.com
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.
+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 an
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
defined
27 matches
Mail list logo
