* Re: [PATCH] spi/mpc52xx: replace printk with dev_err
From: Grant Likely @ 2009-11-09 19:12 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <1257328160-24955-1-git-send-email-w.sang@pengutronix.de>
On Wed, Nov 4, 2009 at 2:49 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> To easily identify which device has problems.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0drivers/spi/mpc52xx_psc_spi.c | =A0 =A05 ++---
> =A01 files changed, 2 insertions(+), 3 deletions(-)
picked up. Thanks
g.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Grant Likely @ 2009-11-09 21:21 UTC (permalink / raw)
To: Richard Röjfors
Cc: spi-devel-general, Andrew Morton, dbrownell, John Linn,
linuxppc-dev
In-Reply-To: <4AC0C699.2070506@mocean-labs.com>
Oops, I replied to the original version, but missed the subsequent
versions. Looks like some of my comments still apply though.
Overall, the patch changes too many things all at once. You should
look at splitting it up. At the very least the io accessor changes
should be done in a separate patch.
On Mon, Sep 28, 2009 at 7:22 AM, Richard R=F6jfors
<richard.rojfors@mocean-labs.com> wrote:
> @@ -227,6 +227,21 @@ config SPI_XILINX
> =A0 =A0 =A0 =A0 =A0See the "OPB Serial Peripheral Interface (SPI) (v1.00e=
)"
> =A0 =A0 =A0 =A0 =A0Product Specification document (DS464) for hardware de=
tails.
>
> + =A0 =A0 =A0 =A0 Or for the DS570, see "XPS Serial Peripheral Interface =
(SPI) (v2.00b)"
> +
> +config SPI_XILINX_OF
> + =A0 =A0 =A0 tristate "Xilinx SPI controller OF device"
> + =A0 =A0 =A0 depends on SPI_XILINX && XILINX_VIRTEX
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 This is the OF driver for the SPI controller IP from th=
e Xilinx EDK.
> +
> +config SPI_XILINX_PLTFM
> + =A0 =A0 =A0 tristate "Xilinx SPI controller platform device"
> + =A0 =A0 =A0 depends on SPI_XILINX
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 This is the platform driver for the SPI controller IP
> + =A0 =A0 =A0 =A0 from the Xilinx EDK.
> +
Personally, I don't think it is necessary to present these options to
the user. I think they can be auto-selected depending on CONFIG_OF
and CONFIG_PLATFORM.
> +struct xilinx_spi {
> + =A0 =A0 =A0 /* bitbang has to be first */
> + =A0 =A0 =A0 struct spi_bitbang bitbang;
> + =A0 =A0 =A0 struct completion done;
> + =A0 =A0 =A0 struct resource mem; /* phys mem */
> + =A0 =A0 =A0 void __iomem =A0 =A0*regs; =A0/* virt. address of the contr=
ol registers */
> + =A0 =A0 =A0 u32 irq;
> + =A0 =A0 =A0 u8 *rx_ptr; =A0 =A0 =A0 =A0 =A0 =A0 /* pointer in the Tx bu=
ffer */
> + =A0 =A0 =A0 const u8 *tx_ptr; =A0 =A0 =A0 /* pointer in the Rx buffer *=
/
> + =A0 =A0 =A0 int remaining_bytes; =A0 =A0/* the number of bytes left to =
transfer */
> + =A0 =A0 =A0 /* offset to the XSPI regs, these might vary... */
> + =A0 =A0 =A0 u8 bits_per_word;
> + =A0 =A0 =A0 bool big_endian; =A0 =A0 =A0 =A0/* The device could be acce=
ssed big or little
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* endian
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> +};
> +
Why is the definition of xilinx_spi moved?
> =A0/* Register definitions as per "OPB Serial Peripheral Interface (SPI) =
(v1.00e)
> =A0* Product Specification", DS464
> =A0*/
> -#define XSPI_CR_OFFSET =A0 =A0 =A0 =A0 0x62 =A0 =A0/* 16-bit Control Reg=
ister */
> +#define XSPI_CR_OFFSET =A0 =A0 =A0 =A0 0x60 =A0 =A0/* Control Register *=
/
>
> =A0#define XSPI_CR_ENABLE =A0 =A0 =A0 =A0 0x02
> =A0#define XSPI_CR_MASTER_MODE =A0 =A00x04
> @@ -40,8 +53,9 @@
> =A0#define XSPI_CR_RXFIFO_RESET =A0 0x40
> =A0#define XSPI_CR_MANUAL_SSELECT 0x80
> =A0#define XSPI_CR_TRANS_INHIBIT =A00x100
> +#define XSPI_CR_LSB_FIRST =A0 =A0 =A00x200
>
> -#define XSPI_SR_OFFSET =A0 =A0 =A0 =A0 0x67 =A0 =A0/* 8-bit Status Regis=
ter */
> +#define XSPI_SR_OFFSET =A0 =A0 =A0 =A0 0x64 =A0 =A0/* Status Register */
>
> =A0#define XSPI_SR_RX_EMPTY_MASK =A00x01 =A0 =A0/* Receive FIFO is empty =
*/
> =A0#define XSPI_SR_RX_FULL_MASK =A0 0x02 =A0 =A0/* Receive FIFO is full *=
/
> @@ -49,8 +63,8 @@
> =A0#define XSPI_SR_TX_FULL_MASK =A0 0x08 =A0 =A0/* Transmit FIFO is full =
*/
> =A0#define XSPI_SR_MODE_FAULT_MASK =A0 =A0 =A0 =A00x10 =A0 =A0/* Mode fau=
lt error */
>
> -#define XSPI_TXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x6b =A0 =A0/* 8-=
bit Data Transmit Register */
> -#define XSPI_RXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x6f =A0 =A0/* 8-=
bit Data Receive Register */
> +#define XSPI_TXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x68 =A0 =A0/* Da=
ta Transmit Register */
> +#define XSPI_RXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x6C =A0 =A0/* Da=
ta Receive Register */
>
> =A0#define XSPI_SSR_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x70 =A0 =A0/* =
32-bit Slave Select Register */
>
> @@ -70,43 +84,72 @@
> =A0#define XSPI_INTR_TX_UNDERRUN =A0 =A0 =A0 =A0 =A00x08 =A0 =A0/* TxFIFO=
was underrun */
> =A0#define XSPI_INTR_RX_FULL =A0 =A0 =A0 =A0 =A0 =A0 =A00x10 =A0 =A0/* Rx=
FIFO is full */
> =A0#define XSPI_INTR_RX_OVERRUN =A0 =A0 =A0 =A0 =A0 0x20 =A0 =A0/* RxFIFO=
was overrun */
> +#define XSPI_INTR_TX_HALF_EMPTY =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x40 =A0 =
=A0/* TxFIFO is half empty */
>
> =A0#define XIPIF_V123B_RESETR_OFFSET =A0 =A0 =A00x40 =A0 =A0/* IPIF reset=
register */
> =A0#define XIPIF_V123B_RESET_MASK =A0 =A0 =A0 =A0 0x0a =A0 =A0/* the valu=
e to write */
>
> -struct xilinx_spi {
> - =A0 =A0 =A0 /* bitbang has to be first */
> - =A0 =A0 =A0 struct spi_bitbang bitbang;
> - =A0 =A0 =A0 struct completion done;
> +/* to follow are some functions that does little of big endian read and
> + * write depending on the config of the device.
> + */
> +static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 val=
)
> +{
> + =A0 =A0 =A0 iowrite8(val, xspi->regs + offs + ((xspi->big_endian) ? 3 :=
0));
> +}
>
> - =A0 =A0 =A0 void __iomem =A0 =A0*regs; =A0/* virt. address of the contr=
ol registers */
> +static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u16 v=
al)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite16be(val, xspi->regs + offs + 2);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite16(val, xspi->regs + offs);
> +}
>
> - =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 irq;
> +static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u32 v=
al)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite32be(val, xspi->regs + offs);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite32(val, xspi->regs + offs);
> +}
>
> - =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 speed_hz; /* SCK has a fixed fr=
equency of speed_hz Hz */
> +static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
> +{
> + =A0 =A0 =A0 return ioread8(xspi->regs + offs + ((xspi->big_endian) ? 3 =
: 0));
> +}
>
> - =A0 =A0 =A0 u8 *rx_ptr; =A0 =A0 =A0 =A0 =A0 =A0 /* pointer in the Tx bu=
ffer */
> - =A0 =A0 =A0 const u8 *tx_ptr; =A0 =A0 =A0 /* pointer in the Rx buffer *=
/
> - =A0 =A0 =A0 int remaining_bytes; =A0 =A0/* the number of bytes left to =
transfer */
> -};
> +static inline u16 xspi_read16(struct xilinx_spi *xspi, u32 offs)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread16be(xspi->regs + offs + 2);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread16(xspi->regs + offs);
> +}
> +
> +static inline u32 xspi_read32(struct xilinx_spi *xspi, u32 offs)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread32be(xspi->regs + offs);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread32(xspi->regs + offs);
> +}
Ah, you changed these to functions instead of macros. I like.
However, as you suggested elsewhere in this thread, you could change
these to callbacks and then eliminate the if/else statements. I think
that is the approach you should use. I don't think you need to worry
about it being slower. Any extra cycles for jumping to a callback
will be far dwarfed by the number of cycles it takes to complete an
SPI transfer.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Invalidate Data Cache from User Space
From: Jonathan Haws @ 2009-11-09 18:10 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I have a routine to invalidate the data cache from user space (since I do n=
ot believe there is a standard routine I can use outside of kernel space??)=
.
Here is the code:
.text;
.globl cacheInvalidate405;
cacheInvalidate405:
/*
* r3 =3D Data cache
* r4 =3D address
* r5 =3D number of bytes
*/
cmpwi r5,0 /* make sure number of bytes is > 0 */
beq invalDone
add r6,r4,r5
addi r6,r6,31
rlwinm r6,r6,0,0,26 /* end addr to start of next cache line=
*/
rlwinm r7,r4,0,0,26 /* start address back to start of line =
*/
sub r6,r6,r7
srawi r6,r6,5 /* divide by 32 to get number of lines =
*/
mtctr r6
invalLoop:
dcbi r0,r4 /* THIS INSTRUCTION FAILS! */
addi r4,r4,32
bdnz invalLoop
sync
invalDone:
blr
.size cacheInvalidate405, . - cacheInvalidate405
What is happening is the dcbi instruction will fail. I get an Illegal Inst=
ruction message on the console and my program exits.
Is there a reason I cannot call dbci from a user space application, or is t=
here something wrong in my code? Even better, is there a working and teste=
d function that I can call from user space to invalidate a portion of the d=
ata cache?
Thanks!
Jonathan
^ permalink raw reply
* Disable Caching for mmap() address
From: Jonathan Haws @ 2009-11-09 23:21 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I would like to disable caching for an address that was returned from a cal=
l to mmap(). I am using this address for DMA operations in user space and =
want to make sure that the data cache is turned off for that buffer.
The way this works is the driver simply takes an address I provide and begi=
ns a DMA operation to that location in RAM (I have ensured that this is a p=
hysical address I am passing already). When the DMA is complete, an interr=
upt fires and the ISR gives a semaphore that the user space application is =
pending on (RT_SEM from Xenomai). I have tried simply calling a cache inva=
lidate routine in the ISR before I give the semaphore, but the kernel crash=
es when I try to call that routine - my guess it because the kernel does no=
t have direct access to that location in memory (only my application does, =
according to the MMU).
Anyway, all I want to do is make sure that the buffer is never stored in th=
e cache and that I always fetch it from RAM. How can I specify that using =
mmap() on the /dev/mem device, or is there a better way to accomplish this?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Fix non-modular build
From: Hollis Blanchard @ 2009-11-09 18:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, kvmppc
In-Reply-To: <1257401928.13611.105.camel@pasglop>
On Thu, 2009-11-05 at 17:18 +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kvm/timing.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
> index 2aa371e..7037855 100644
> --- a/arch/powerpc/kvm/timing.c
> +++ b/arch/powerpc/kvm/timing.c
> @@ -23,6 +23,7 @@
> #include <linux/seq_file.h>
> #include <linux/debugfs.h>
> #include <linux/uaccess.h>
> +#include <linux/module.h>
>
> #include <asm/time.h>
> #include <asm-generic/div64.h>
FYI, Olof submitted this patch already, but Avi didn't take it or
comment. Feel free to batch it in the agraf bundle (it is required to
make that build, after all).
Acked-by: Hollis Blanchard <hollisb@us.ibm.com>
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: c67x00 with mpc85xx
From: Grant Likely @ 2009-11-09 19:23 UTC (permalink / raw)
To: Jeff Angielski; +Cc: Joel Lord, Linuxppc-dev
In-Reply-To: <4AD8CD30.6020003@theptrgroup.com>
On Fri, Oct 16, 2009 at 12:44 PM, Jeff Angielski <jeff@theptrgroup.com> wrote:
>
> We are using the Cypress USB Host (CY7C67300) with a Freescale MPC8544 and
> can only get it to work if we add a delay after writing to the hardware
> registers through the HPI.
>
> We tried playing with the SCY settings in the GPCM but nothing helps. It is
> only when we add usecs of delay after our write() functions that the
> hardware works.
>
> The datasheets make no mention of any write-then-read requirements and the
> FAEs are stumped right now.
>
> I was just hoping somebody had some experiencing interfacing this chip to
> the PowerPC and that they could offer some suggestions or ideas.
I've worked with the part attached to the ppc440 inside a Xilinx FPGA.
Though I ran into many problems, I haven't seen the problem that you
describe. Sorry.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Fwd: [PATCH] arch/powerpc: Improve _memcpy
From: Grant Likely @ 2009-11-09 17:06 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Dirk Eibach, Linux kernel, linuxppc-dev list
In-Reply-To: <1257358349.2489.0@antares>
On Wed, Nov 4, 2009 at 11:12 AM, Albrecht Dre=DF <albrecht.dress@arcor.de> =
wrote:
> See <http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html>=
.
> =A0Any chance to get this one into the tree? =A0Grant?
Even though it is generic ppc code, I picked it up into my 5200 -next
tree because it's such a simple patch. I expect Ben will pull it into
his any day now.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] ASoC/mpc5200: remove duplicate identical IRQ handler
From: Grant Likely @ 2009-11-09 16:40 UTC (permalink / raw)
To: linuxppc-dev, alsa-devel, broonie; +Cc: lrg
The TX and RX irq handlers are identical. Merge them
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Hi Mark. Here's one more cleanup patch.
sound/soc/fsl/mpc5200_dma.c | 33 +++------------------------------
1 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index ee5a606..440b749 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -66,32 +66,7 @@ static void psc_dma_bcom_enqueue_next_buffer(struct psc_dma_stream *s)
}
/* Bestcomm DMA irq handler */
-static irqreturn_t psc_dma_bcom_irq_tx(int irq, void *_psc_dma_stream)
-{
- struct psc_dma_stream *s = _psc_dma_stream;
-
- spin_lock(&s->psc_dma->lock);
- /* For each finished period, dequeue the completed period buffer
- * and enqueue a new one in it's place. */
- while (bcom_buffer_done(s->bcom_task)) {
- bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
-
- s->period_current = (s->period_current+1) % s->runtime->periods;
- s->period_count++;
-
- psc_dma_bcom_enqueue_next_buffer(s);
- }
- spin_unlock(&s->psc_dma->lock);
-
- /* If the stream is active, then also inform the PCM middle layer
- * of the period finished event. */
- if (s->active)
- snd_pcm_period_elapsed(s->stream);
-
- return IRQ_HANDLED;
-}
-
-static irqreturn_t psc_dma_bcom_irq_rx(int irq, void *_psc_dma_stream)
+static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
{
struct psc_dma_stream *s = _psc_dma_stream;
@@ -486,11 +461,9 @@ int mpc5200_audio_dma_create(struct of_device *op)
rc = request_irq(psc_dma->irq, &psc_dma_status_irq, IRQF_SHARED,
"psc-dma-status", psc_dma);
- rc |= request_irq(psc_dma->capture.irq,
- &psc_dma_bcom_irq_rx, IRQF_SHARED,
+ rc |= request_irq(psc_dma->capture.irq, &psc_dma_bcom_irq, IRQF_SHARED,
"psc-dma-capture", &psc_dma->capture);
- rc |= request_irq(psc_dma->playback.irq,
- &psc_dma_bcom_irq_tx, IRQF_SHARED,
+ rc |= request_irq(psc_dma->playback.irq, &psc_dma_bcom_irq, IRQF_SHARED,
"psc-dma-playback", &psc_dma->playback);
if (rc) {
ret = -ENODEV;
^ permalink raw reply related
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: Anton Vorontsov @ 2009-11-09 13:41 UTC (permalink / raw)
To: David Miller
Cc: jdl, netdev, linuxppc-dev, afleming, jason.wessel, shemminger,
buytenh
In-Reply-To: <20091108.010848.116517157.davem@davemloft.net>
On Sun, Nov 08, 2009 at 01:08:48AM -0800, David Miller wrote:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date: Thu, 5 Nov 2009 19:57:38 +0300
>
> > But that basically means that with skb recycling we can't safely
> > use KGDBoE, though we can add something like this:
>
> Please stop adding special logic only to your driver to handle these
> things.
>
> Either it's a non-issue, or it's going to potentially be an issue for
> everyone using skb_recycle_check() in a NAPI driver, right?
>
> So why not add the "in_interrupt()" or whatever check to
> skb_recycle_check() and if the context is unsuitable return false (0)
> ok?
I think the check is needed, yes. But if we add just that check,
then we'll never do skb recycling in the tx path (since gianfar
always grabs irqsave spinlock during tx ring cleanup, so the check
will always return false).
So we must add the check to keep polling with disabled IRQs safe,
but we also should get rid of irqsave spinlock in the gianfar
driver (to make the skb recycling actually work in most cases).
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Make polling safe with IRQs disabled
From: Anton Vorontsov @ 2009-11-09 13:32 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev, afleming, jason.wessel
In-Reply-To: <20091108.010533.212571001.davem@davemloft.net>
On Sun, Nov 08, 2009 at 01:05:33AM -0800, David Miller wrote:
...
> > When using KGDBoE, gianfar driver spits 'Interrupt problem' messages,
> > which appears to be a legitimate warning, i.e. we may end up calling
> > netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled.
> >
> > This patch reworks the RX path so that if netpoll is enabled (the
> > only case when the driver don't know from what context the polling
> > may be called), we check whether IRQs are disabled, and if so we
> > fall back to safe variants of skb receiving functions.
>
> This is bogus, I'll tell you why.
>
> When you go into netif_receive_skb() we have a special check,
> "if (netpoll_receive_skb(..." that takes care of all of the
> details concerning doing a ->poll() from IRQ disabled context
> via netpoll.
>
> So this code you're adding should not be necessary.
>
> Or, explain to me why no other driver needs special logic in their
> ->poll() handler like this and does not run into any kinds of netpoll
> problems :-)
Hm, I was confused by the following note:
/**
* netif_receive_skb - process receive buffer from network
* @skb: buffer to process
...
* This function may only be called from softirq context and interrupts
* should be enabled.
Looking into the code though, I can indeed see that there
are netpoll checks, and __netpoll_rx() is actually called with
irqs disabled. So, in the end it appears that we should just
remove the 'Interrupt problem' message.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [microblaze-uclinux] [PATCH 00/11] More OF merge patches
From: Michal Simek @ 2009-11-09 10:35 UTC (permalink / raw)
To: microblaze-uclinux
Cc: sfr, monstr, devicetree-discuss, sparclinux, linuxppc-dev, davem
In-Reply-To: <20091105073728.10460.6061.stgit@angua>
Hi Grant,
Grant Likely wrote:
> Round 2. Here is my 2nd set of merging OF code between PowerPC and
> Microblaze (no SPARC changes this time). Compile tested on ppc,
> microblaze and sparc. Boot tested on MPC5200 powerpc platform.
I tested your test-device-tree branch - boot tested on ml505 for MMU and
noMMU kernels.
I expect that you will add these patches to next branch. I test it every
day - if is any problem with Microblaze, I will let you know.
Tested-by: Michal Simek <monstr@monstr.eu>
Thanks for this work,
Michal
>
> I've also pushed this series out to the test-devicetree branch on my
> git server if anyone cares to pull and test:
>
> git://git.secretlab.ca/git/linux-2.6 test-devicetree
>
> This is based on the next-devicetree branch which contains the first
> round of patches and is being pulled into linux-next.
>
> Cheers,
> g.
>
> ---
>
> Grant Likely (11):
> of/flattree: Merge early_init_dt_check_for_initrd()
> of: remove special case definition of of_read_ulong()
> of: merge prom_{add,remove,modify}_property
> of/flattree: Merge unflatten_device_tree
> of/flattree: Merge unflatten_dt_node
> of/flattree: Merge of_flat_dt_is_compatible
> of/flattree: merge of_get_flat_dt_prop
> of/flattree: remove __init annotations from the header file
> of/flattree: merge of_get_flat_dt_root
> of/flattree: merge of_scan_flat_dt
> of/flattree: merge find_flat_dt_string and initial_boot_params
>
>
> arch/microblaze/Kconfig | 1
> arch/microblaze/include/asm/prom.h | 1
> arch/microblaze/kernel/prom.c | 531 ------------------------------------
> arch/powerpc/Kconfig | 1
> arch/powerpc/kernel/prom.c | 534 ------------------------------------
> drivers/of/Kconfig | 4
> drivers/of/Makefile | 1
> drivers/of/base.c | 116 ++++++++
> drivers/of/fdt.c | 458 +++++++++++++++++++++++++++++++
> include/linux/of.h | 10 -
> include/linux/of_fdt.h | 21 +
> 11 files changed, 598 insertions(+), 1080 deletions(-)
> create mode 100644 drivers/of/fdt.c
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
^ permalink raw reply
* Re: [patch 09/16] powerpc: Replace old style lock initializer
From: Benjamin Herrenschmidt @ 2009-11-09 8:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, linuxppc-dev, Thomas Gleixner, Ingo Molnar, LKML
In-Reply-To: <20091109161502.ab064092.sfr@canb.auug.org.au>
On Mon, 2009-11-09 at 16:15 +1100, Stephen Rothwell wrote:
> Hi Thomas,
>
> On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > On Fri, 2009-11-06 at 22:41 +0000, Thomas Gleixner wrote:
> > > plain text document attachment
> > > (power-replace-old-style-lock-init.patch)
> > > SPIN_LOCK_UNLOCKED is deprecated. Init the lock array at runtime
> > > instead.
> > >
> > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: linuxppc-dev@ozlabs.org
> > > ---
> >
> > Looks reasonable. But iseries can be a bitch, so we do need to test it
> > on monday.
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [patch 09/16] powerpc: Replace old style lock initializer
From: Stephen Rothwell @ 2009-11-09 5:15 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Peter Zijlstra, Ingo Molnar, LKML, linuxppc-dev
In-Reply-To: <1257548144.13611.267.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Hi Thomas,
On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2009-11-06 at 22:41 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (power-replace-old-style-lock-init.patch)
> > SPIN_LOCK_UNLOCKED is deprecated. Init the lock array at runtime
> > instead.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: linuxppc-dev@ozlabs.org
> > ---
>
> Looks reasonable. But iseries can be a bitch, so we do need to test it
> on monday.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Allow overriding of CC in powerpc kernel build
From: David Gibson @ 2009-11-09 2:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
arch/powerpc/Makefile uses make 'override' directives to add -m32 or
-m64 depending on config to the CC variable, and matching options to
the AS, LD and AR variables to correctly use a biarch compiler.
Unfortunately this doesn't work as intended if you actually attempt to
set CC from the make command line. They correctly augment the given
CC variable in the top-level make instance, but at least some of the
second-level make invocations don't include arch/powerpc/Makefile, so
the command line override is used directly, and we attempt to compile
without the correct -m64 or similar option.
This patch alters the way we set up the biarch flags so that CC can be
overriden from the command line as expected (this is useful when using
ccontrol as a compiler wrapper). The approach is based roughly on the
way x86 handles the analagous problem for i386/x86_64 biarch
compilers, with some additional hacks to make the VDSO compilation
work.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: linux-a2/arch/powerpc/Makefile
===================================================================
--- linux-a2.orig/arch/powerpc/Makefile 2009-11-06 14:17:15.000000000 +1100
+++ linux-a2/arch/powerpc/Makefile 2009-11-06 15:36:05.000000000 +1100
@@ -57,10 +57,10 @@ endif
UTS_MACHINE := $(OLDARCH)
ifeq ($(HAS_BIARCH),y)
-override AS += -a$(CONFIG_WORD_SIZE)
-override LD += -m elf$(CONFIG_WORD_SIZE)ppc
-override CC += -m$(CONFIG_WORD_SIZE)
-override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
+ KBUILD_AFLAGS += -m$(CONFIG_WORD_SIZE)
+ KBUILD_CFLAGS += -m$(CONFIG_WORD_SIZE)
+ LDFLAGS := -m elf$(CONFIG_WORD_SIZE)ppc
+ override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
endif
LDFLAGS_vmlinux-yy := -Bstatic
Index: linux-a2/arch/powerpc/kernel/vdso32/Makefile
===================================================================
--- linux-a2.orig/arch/powerpc/kernel/vdso32/Makefile 2009-11-06 15:45:36.000000000 +1100
+++ linux-a2/arch/powerpc/kernel/vdso32/Makefile 2009-11-06 15:47:03.000000000 +1100
@@ -40,10 +40,13 @@ $(obj-vdso32): %.o: %.S
$(call if_changed_dep,vdso32as)
# actual build commands
+biarch := $(call cc-option, -m32)
+c_flags_32 = $(filter-out -m64,$(c_flags)) $(biarch)
+a_flags_32 = $(filter-out -m64,$(a_flags)) $(biarch)
quiet_cmd_vdso32ld = VDSO32L $@
- cmd_vdso32ld = $(CROSS32CC) $(c_flags) -Wl,-T $^ -o $@
+ cmd_vdso32ld = $(CROSS32CC) $(c_flags_32) -Wl,-T $^ -o $@
quiet_cmd_vdso32as = VDSO32A $@
- cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
+ cmd_vdso32as = $(CROSS32CC) $(a_flags_32) -c -o $@ $<
# install commands for the unstripped file
quiet_cmd_vdso_install = INSTALL $@
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [GIT PULL] perf_event/tracing/powerpc patches from Anton Blanchard
From: Ingo Molnar @ 2009-11-08 9:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, linuxppc-dev, Paul Mackerras, linux-kernel,
Anton Blanchard
In-Reply-To: <1256882649.6372.65.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2009-10-29 at 07:55 +0100, Ingo Molnar wrote:
> > * Paul Mackerras <paulus@samba.org> wrote:
> >
> > > Here is a series of patches from Anton Blanchard that implement some
> > > nice tracing and perf_event features on powerpc. One of them is
> > > generic perf_event stuff (adding software events for alignment faults
> > > and instruction emulation faults).
> > >
> > > Since this touches the perf_event and tracing subsystems as well as
> > > the powerpc architecture code, I think the best way forward is for
> > > both Ingo and Ben to pull it into their trees. I have based it on the
> > > most recent point in Linus' tree that Ingo had pulled into his perf
> > > branches (as of yesterday or so).
> >
> > The generic perf bits look good to me - can pull it if Ben OKs the
> > PowerPC bits.
>
> Yup. Just went through all of them, they look fine. I also test built on
> a number of default configs and it seems to pass.
Pulled into tip:perf/powerpc (will keep it in a separate branch for a
few days then it can go into perf/core), thanks guys!
Ingo
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Do not call skb recycling with disabled IRQs
From: David Miller @ 2009-11-08 9:08 UTC (permalink / raw)
To: avorontsov
Cc: jdl, netdev, linuxppc-dev, afleming, jason.wessel, shemminger,
buytenh
In-Reply-To: <20091105165738.GA31923@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 19:57:38 +0300
> But that basically means that with skb recycling we can't safely
> use KGDBoE, though we can add something like this:
Please stop adding special logic only to your driver to handle these
things.
Either it's a non-issue, or it's going to potentially be an issue for
everyone using skb_recycle_check() in a NAPI driver, right?
So why not add the "in_interrupt()" or whatever check to
skb_recycle_check() and if the context is unsuitable return false (0)
ok?
^ permalink raw reply
* Re: [PATCH RFC] gianfar: Make polling safe with IRQs disabled
From: David Miller @ 2009-11-08 9:05 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, netdev, afleming, jason.wessel
In-Reply-To: <20091104225711.GA30844@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:57:11 +0300
> When using KGDBoE, gianfar driver spits 'Interrupt problem' messages,
> which appears to be a legitimate warning, i.e. we may end up calling
> netif_receive_skb() or vlan_hwaccel_receive_skb() with IRQs disabled.
>
> This patch reworks the RX path so that if netpoll is enabled (the
> only case when the driver don't know from what context the polling
> may be called), we check whether IRQs are disabled, and if so we
> fall back to safe variants of skb receiving functions.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
This is bogus, I'll tell you why.
When you go into netif_receive_skb() we have a special check,
"if (netpoll_receive_skb(..." that takes care of all of the
details concerning doing a ->poll() from IRQ disabled context
via netpoll.
So this code you're adding should not be necessary.
Or, explain to me why no other driver needs special logic in their
->poll() handler like this and does not run into any kinds of netpoll
problems :-)
^ permalink raw reply
* Re: [PATCH 3/3] gianfar: Fix compiler and sparse warnings
From: David Miller @ 2009-11-08 8:44 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Sandeep.Kumar, afleming, netdev
In-Reply-To: <20091104225300.GC29537@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:53:00 +0300
> commit fba4ed030cfae7efdb6b79a57b0c5a9d72c9de83 ("gianfar: Add Multiple
> Queue Support") introduced the following warnings:
...
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] fsl_pq_mdio: Fix compiler/sparse warnings (part 2)
From: David Miller @ 2009-11-08 8:43 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Sandeep.Kumar, afleming, netdev
In-Reply-To: <20091104225257.GB29537@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:52:57 +0300
> This patch fixes following warnings:
>
> fsl_pq_mdio.c:112:38: warning: cast adds address space to expression (<asn:2>)
> fsl_pq_mdio.c:124:38: warning: cast adds address space to expression (<asn:2>)
> fsl_pq_mdio.c:133:38: warning: cast adds address space to expression (<asn:2>)
> fsl_pq_mdio.c:414:11: warning: cast adds address space to expression (<asn:2>)
>
> Instead of adding __force all over the place, introduce convenient
> fsl_pq_mdio_get_regs() call that does the ugly casting just once.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] fsl_pq_mdio: Fix compiler/sparse warnings (part 1)
From: David Miller @ 2009-11-08 8:43 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Sandeep.Kumar, afleming, netdev
In-Reply-To: <20091104225256.GA29537@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 5 Nov 2009 01:52:56 +0300
> commit 1d2397d742b7a2b39b2f09dd9da3b9d1463f55e9 ("fsl_pq_mdio: Add
> Suport for etsec2.0 devices") introduced the following warnings:
...
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [patch 09/16] powerpc: Replace old style lock initializer
From: Stephen Rothwell @ 2009-11-08 7:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, linuxppc-dev, Thomas Gleixner, Ingo Molnar, LKML
In-Reply-To: <1257548144.13611.267.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
Hi Ben,
On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Looks reasonable. But iseries can be a bitch, so we do need to test it
> on monday.
It should be safe as the spinlocks cannot be access until after the
following ppc_md pointer initialisations are done (and all this happens
before the secondary CPUs are started).
But, you are right that there is nothing like actually testing with
iSeries. :-)
> > void __init hpte_init_iSeries(void)
> > {
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(iSeries_hlocks); i++)
> > + spin_lock_init(&iSeries_hlocks[i]);
> > +
> > ppc_md.hpte_invalidate = iSeries_hpte_invalidate;
> > ppc_md.hpte_updatepp = iSeries_hpte_updatepp;
> > ppc_md.hpte_updateboltedpp = iSeries_hpte_updateboltedpp;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense
From: Mark Brown @ 2009-11-07 20:12 UTC (permalink / raw)
To: Grant Likely; +Cc: John Bonesio, alsa-devel, linuxppc-dev, lrg
In-Reply-To: <fa686aa40911071051y3cf63e55ibe7fbc65c30bd15e@mail.gmail.com>
On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> current period. My understanding of ALSA is that the application is
> supposed to make sure there is enough silence in the buffer to handle
> the lag between notification that the last period with valid data has
> been played out and the stop trigger.
This is certainly the most robust approach for applications. For a
large proportion of hardware it won't matter too much since they're able
to shut down the audio very quickly but that can't be entirely relied
upon, especially at higher rates on slower machines.
> occur. That says to me that the real problem is an unbounded latency
> caused by another part of the kernel (the tty console in this case).
That's certainly not going to help anything here - if a delay is
introduced in telling the hardware to shut down the DMA then that
increases the chance for the DMA controller to start pushing valid audio
data from the buffer to the audio interface.
> > A much cleaner solution would be for ALSA to provide a field that
> > indicates the last valid address in the ring buffer system. Then in
> > the driver's buffer complete callback I could get that value and
> > reprogram the DMA engine not to run off the end of valid data. As each
> > buffer completes I would reread the value and update the DMA stop
> > address. You also need the last valid address field when DMA is first
> > started.
> ... assuming that audio needs to stop exactly at the end of valid
> data. But if the last few periods are silence, then this assumption
> isn't true.
Indeed, it makes the whole thing much more reliable.
Providing a final valid data point to the driver would possibly even
make things worse since if it were used then you'd have the equivalent
race where the application has initialised some data but not yet managed
to update the driver to tell it it's being handed over; if the driver
just carries on running through the data there's a reasonable chance
nobody will notice that case.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()
From: Grant Likely @ 2009-11-07 19:46 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <20091107193318.GB31789@sirena.org.uk>
On Sat, Nov 7, 2009 at 12:33 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote:
>> On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
>
>> > It occurs to me that in terms of dealing with what's going on here this
>> > probably is achieving exactly the same effect as Jon's code in that it
>> > tells ALSA that things are a bit ahead of where the buffer started.
>
>> Possibly, but I can both reproduce and eliminate the problem Jon is
>> seeing regardless of whether or not this patch, so I'm not yet
>> convinced.
>
> That doesn't entirely surprise me; I'm not convinced that the original
> approach entirely deals with the issue rather than just making it much
> harder to see.
Indeed. I'm at the point where I'm far more interested in achieving
"correctness" than trying to hobble together a set of conditions that
appears to work most of the time.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()
From: Mark Brown @ 2009-11-07 19:33 UTC (permalink / raw)
To: Grant Likely; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <fa686aa40911071019y6be8283bu8d36d96420deefab@mail.gmail.com>
On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
> > It occurs to me that in terms of dealing with what's going on here this
> > probably is achieving exactly the same effect as Jon's code in that it
> > tells ALSA that things are a bit ahead of where the buffer started.
> Possibly, but I can both reproduce and eliminate the problem Jon is
> seeing regardless of whether or not this patch, so I'm not yet
> convinced.
That doesn't entirely surprise me; I'm not convinced that the original
approach entirely deals with the issue rather than just making it much
harder to see.
^ permalink raw reply
* Re: [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense
From: Grant Likely @ 2009-11-07 18:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: alsa-devel, broonie, linuxppc-dev, lrg
In-Reply-To: <9e4733910911070504g13bce539w92120b8124e3e8e9@mail.gmail.com>
On Sat, Nov 7, 2009 at 6:04 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 7:51 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely <grant.likely@secretlab.ca>=
wrote:
>>> Sound drivers PCM DMA is supposed to free-run until told to stop
>>> by the trigger callback. =A0The current code tries to track appl_ptr,
>>> to avoid stale buffer data getting played out at the end of the
>>> data stream. =A0Unfortunately it also results in race conditions
>>> which can cause the audio to stall.
>>
>> I leave in an hour and I will be off net for a week so I can't look at t=
hese.
>
> There is a surefire way to fix this but I have resisted doing it
> because it is fixing a symptom not a cause.
>
> Simply have the driver zero out the buffer in the completion interrupt
> before handing it back to ALSA. Then if ALSA lets us play invalid data
> the invalid data will be silence. I implemented this and it works
> every time.
>
> Downside is a big memset() in an IRQ handler.
... and then the driver may as well manually copy the audio data from
the buffer into the PSC FIFO. No win here.
The other option (which I think is how ALSA is designed) is for
userspace to insert silence at the end of playback data so that the
stop trigger lands in a safe place.
g.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox