* Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-05-06 15:19 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Scott Wood, linuxppc-dev list, Linux I2C, Kernel, Linux
In-Reply-To: <20080506135113.GA4265@pengutronix.de>
Hi Wolfram,
>> + /* Begin transmission */
>> + setbits8(&i2c_reg->i2com, 0x80);
> Hardcoded value. (I also wonder if 0x81 might be more suitable, as it
> keeps the "be-a-master"-bit set. Still, both values work with my setup.)
>> +#ifdef I2C_CHIP_ERRATA
>> + /*
>> + * Chip errata, clear enable. This is not needed on rev D4 CPUs.
>> + * Disabling I2C too early may cause too short stop condition
>> + */
>> + udelay(4);
>> + clrbits8(&i2c_reg->i2mod, 1);
> I was unable to find the corresponding errata document, still I wonder
> if it is a 0 which should have been written? The text says "clear" and
> according to the reference manual, this means the bit should be 0.
setbits8() and clrbits8() use a bitmask as second argument.
setbits8(&i2c_reg->i2com, 0x80) will set bit 7 on the i2com register but
leave bit 0 untouched. Likewise, clrbits8(&i2c_reg->i2mod, 1) will clear bit 0.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
From: Josh Boyer @ 2008-05-06 15:01 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1209970399-4464-1-git-send-email-sr@denx.de>
On Mon, 5 May 2008 08:53:19 +0200
Stefan Roese <sr@denx.de> wrote:
> The new 440x6 core used on AMCC 460EX/GT introduces new storage attibure
> fields to the TLB2 word. Those are:
>
> Bit 11 12 13 14 15
> WL1 IL1I IL1D IL2I IL2D
>
> With these bits the cache (L1 and L2) can be configured in a more flexible
> way, instruction- and data-cache independently now. The "old" I and W bits
> are still available and setting these old bits will automically set these
> new bits too (for backward compatibilty).
>
> The current code does not clear these fields resulting in disabling the cache
> by chance. This patch now makes sure that these new bits are cleared when
> the TLB2 word is written.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Finally catching back up with email. This looks like .26 material,
correct?
josh
^ permalink raw reply
* Re: [Fwd: fix for drivers/serial/mpc52xx_uart.c]
From: Grant Likely @ 2008-05-06 14:39 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-dev
In-Reply-To: <481FFDF5.7060208@246tnt.com>
On Tue, May 6, 2008 at 12:43 AM, Sylvain Munaut <tnt@246tnt.com> wrote:
> Patch, obviously correct, sent to me personally instead of the list.
>
> Sylvain
>
> Here is a fix for the unterminated mpc52xx_uart_of_match array when CONFIG_PPC_MPC512x is not defined. Should be quite self explonary, but if not feel free to bug me about it.
>
> Patch applies against 2.6.25 and 2.6.25.1 at least.
Already fixed in mainline; it needs to be back ported to 2.6.25. I'll
poke GregKH
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Wolfram Sang @ 2008-05-06 13:51 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev list, Linux I2C, Kernel, Linux
In-Reply-To: <47FF71A9.4010907@scram.de>
[-- Attachment #1: Type: text/plain, Size: 23684 bytes --]
Hi Jochen,
I just had a debug session with a MPC8260 + eeprom and got some
questions:
> This driver uses the port of 2.4 code from Vitaly Bordug
> <vitb@kernel.crashing.org> and the actual algorithm used by the i2c
> driver of the DBox code on cvs.tuxboc.org from Felix Domke
> (tmbinc@gmx.net) and Gillem (htoa@gmx.net) converted to an
> of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and
> CPM2 (MPC8272).
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-cpm.c | 728 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 739 insertions(+), 0 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-cpm.c
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 5fa9c3c..5c4f270 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -114,6 +114,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
> help
> The unit of the TWI clock is kHz.
>
> +config I2C_CPM
> + tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
> + depends on (CPM1 || CPM2) && PPC_OF
> + help
> + This supports the use of the I2C interface on Freescale
> + processors with CPM1 or CPM2.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-cpm.
> +
> config I2C_DAVINCI
> tristate "DaVinci I2C driver"
> depends on ARCH_DAVINCI
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index ea7068f..1291e2b 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
> obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
> +obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
> obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
> obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
> obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
> diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
> new file mode 100644
> index 0000000..e6e8317
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-cpm.c
> @@ -0,0 +1,728 @@
> +/*
> + * Freescale CPM1/CPM2 I2C interface.
> + * Copyright (c) 1999 Dan Malek (dmalek@jlc.net).
> + *
> + * moved into proper i2c interface;
> + * Brad Parker (brad@heeltoe.com)
> + *
> + * (C) 2007 Montavista Software, Inc.
> + * Vitaly Bordug <vitb@kernel.crashing.org>
> + *
> + * Parts from dbox2_i2c.c (cvs.tuxbox.org)
> + * (C) 2000-2001 Felix Domke (tmbinc@gmx.net), Gillem (htoa@gmx.net)
> + *
> + * Converted to of_platform_device. Renamed to i2c-cpm.c.
> + * (C) 2007,2008 Jochen Friedrich <jochen@scram.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/errno.h>
> +#include <linux/stddef.h>
> +#include <linux/i2c.h>
> +#include <linux/io.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_i2c.h>
> +#include <sysdev/fsl_soc.h>
> +#include <asm/cpm.h>
> +
> +/* Try to define this if you have an older CPU (earlier than rev D4) */
> +/* However, better use a GPIO based bitbang driver in this case :/ */
> +#undef I2C_CHIP_ERRATA
> +
> +#define CPM_MAX_READ 513
> +#define CPM_MAXBD 4
> +
> +#define CPM_CR_INIT_TRX (0x00)
> +#define CPM_CR_CLOSE_RX_BD (0x07)
> +
> +#define I2C_EB (0x10) /* Big endian mode */
> +#define I2C_EB_CPM2 (0x30) /* Big endian mode, memory snoop */
> +
> +#define DPRAM_BASE ((u8 __iomem __force *)cpm_muram_addr(0))
> +
> +/* I2C parameter RAM. */
> +struct i2c_ram {
> + ushort rbase; /* Rx Buffer descriptor base address */
> + ushort tbase; /* Tx Buffer descriptor base address */
> + u_char rfcr; /* Rx function code */
> + u_char tfcr; /* Tx function code */
> + ushort mrblr; /* Max receive buffer length */
> + uint rstate; /* Internal */
> + uint rdp; /* Internal */
> + ushort rbptr; /* Rx Buffer descriptor pointer */
> + ushort rbc; /* Internal */
> + uint rxtmp; /* Internal */
> + uint tstate; /* Internal */
> + uint tdp; /* Internal */
> + ushort tbptr; /* Tx Buffer descriptor pointer */
> + ushort tbc; /* Internal */
> + uint txtmp; /* Internal */
> + char res1[4]; /* Reserved */
> + ushort rpbase; /* Relocation pointer */
> + char res2[2]; /* Reserved */
> +};
> +
> +/* I2C Registers */
> +struct i2c_reg {
> + u8 i2mod;
> + u8 res1[3];
> + u8 i2add;
> + u8 res2[3];
> + u8 i2brg;
> + u8 res3[3];
> + u8 i2com;
> + u8 res4[3];
> + u8 i2cer;
> + u8 res5[3];
> + u8 i2cmr;
> +};
> +
> +struct cpm_i2c {
> + char *base;
> + struct of_device *ofdev;
> + struct i2c_adapter adap;
> + uint dp_addr;
> + int version; /* CPM1=1, CPM2=2 */
> + int irq;
> + int cp_command;
> + struct i2c_reg __iomem *i2c_reg;
> + struct i2c_ram __iomem *i2c_ram;
> + u16 i2c_addr;
> + wait_queue_head_t i2c_wait;
> + struct mutex i2c_mutex; /* Protects struct i2c_ram */
> + cbd_t __iomem *tbase;
> + cbd_t __iomem *rbase;
> + u_char *txbuf[CPM_MAXBD];
> + u_char *rxbuf[CPM_MAXBD];
> + u32 txdma[CPM_MAXBD];
> + u32 rxdma[CPM_MAXBD];
> +};
> +
> +static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)
> +{
> + struct cpm_i2c *cpm;
> + struct i2c_reg __iomem *i2c_reg;
> + struct i2c_adapter *adap = dev_id;
> + int i;
> +
> + cpm = i2c_get_adapdata(dev_id);
> + i2c_reg = cpm->i2c_reg;
> +
> + /* Clear interrupt. */
> + i = in_8(&i2c_reg->i2cer);
> + out_8(&i2c_reg->i2cer, i);
> +
> + dev_dbg(&adap->dev, "Interrupt: %x\n", i);
> +
> + /* Get me going again. */
> + wake_up_interruptible(&cpm->i2c_wait);
> +
> + return i ? IRQ_HANDLED : IRQ_NONE;
> +}
> +
> +static void cpm_reset_i2c_params(struct cpm_i2c *cpm)
> +{
> + struct i2c_ram __iomem *i2c_ram = cpm->i2c_ram;
> +
> + /* Set up the IIC parameters in the parameter ram. */
> + out_be16(&i2c_ram->tbase, (u8 __iomem *)cpm->tbase - DPRAM_BASE);
> + out_be16(&i2c_ram->rbase, (u8 __iomem *)cpm->rbase - DPRAM_BASE);
> +
> + if (cpm->version == 1) {
> + out_8(&i2c_ram->tfcr, I2C_EB);
> + out_8(&i2c_ram->rfcr, I2C_EB);
> + } else {
> + out_8(&i2c_ram->tfcr, I2C_EB_CPM2);
> + out_8(&i2c_ram->rfcr, I2C_EB_CPM2);
> + }
> +
> + out_be16(&i2c_ram->mrblr, CPM_MAX_READ);
> +
> + out_be32(&i2c_ram->rstate, 0);
> + out_be32(&i2c_ram->rdp, 0);
> + out_be16(&i2c_ram->rbptr, 0);
> + out_be16(&i2c_ram->rbc, 0);
> + out_be32(&i2c_ram->rxtmp, 0);
> + out_be32(&i2c_ram->tstate, 0);
> + out_be32(&i2c_ram->tdp, 0);
> + out_be16(&i2c_ram->tbptr, 0);
> + out_be16(&i2c_ram->tbc, 0);
> + out_be32(&i2c_ram->txtmp, 0);
> +}
> +
> +static void cpm_i2c_force_close(struct i2c_adapter *adap)
> +{
> + struct cpm_i2c *cpm = i2c_get_adapdata(adap);
> + struct i2c_reg __iomem *i2c_reg = cpm->i2c_reg;
> +
> + dev_dbg(&adap->dev, "cpm_i2c_force_close()\n");
> +
> + cpm_command(cpm->cp_command, CPM_CR_CLOSE_RX_BD);
> +
> + out_8(&i2c_reg->i2cmr, 0x00); /* Disable all interrupts */
> + out_8(&i2c_reg->i2cer, 0xff);
> +}
> +
> +static void cpm_i2c_parse_message(struct i2c_adapter *adap,
> + struct i2c_msg *pmsg, int num, int tx, int rx)
> +{
> + cbd_t __iomem *tbdf;
> + cbd_t __iomem *rbdf;
> + u_char addr;
> + u_char *tb;
> + u_char *rb;
> + struct cpm_i2c *cpm = i2c_get_adapdata(adap);
> +
> + tbdf = cpm->tbase + tx;
> + rbdf = cpm->rbase + rx;
> +
> + addr = pmsg->addr << 1;
> + if (pmsg->flags & I2C_M_RD)
> + addr |= 1;
> +
> + tb = cpm->txbuf[tx];
> + rb = cpm->rxbuf[rx];
> +
> + /* Align read buffer */
> + rb = (u_char *) (((ulong) rb + 1) & ~1);
> +
> + tb[0] = addr; /* Device address byte w/rw flag */
> +
> + out_be16(&tbdf->cbd_datlen, pmsg->len + 1);
> + out_be16(&tbdf->cbd_sc, 0);
> +
> + if (!(pmsg->flags & I2C_M_NOSTART))
> + setbits16(&tbdf->cbd_sc, BD_I2C_START);
> +
> + if (tx + 1 == num)
> + setbits16(&tbdf->cbd_sc, BD_SC_LAST | BD_SC_WRAP);
> +
> + if (pmsg->flags & I2C_M_RD) {
> + /*
> + * To read, we need an empty buffer of the proper length.
> + * All that is used is the first byte for address, the remainder
> + * is just used for timing (and doesn't really have to exist).
> + */
> +
> + dev_dbg(&adap->dev, "cpm_i2c_read(abyte=0x%x)\n", addr);
> +
> + out_be16(&rbdf->cbd_datlen, 0);
> + out_be16(&rbdf->cbd_sc, BD_SC_EMPTY | BD_SC_INTRPT);
> +
> + if (rx + 1 == CPM_MAXBD)
> + setbits16(&rbdf->cbd_sc, BD_SC_WRAP);
> +
> + eieio();
> + setbits16(&tbdf->cbd_sc, BD_SC_READY);
> + } else {
> + dev_dbg(&adap->dev, "cpm_iic_write(abyte=0x%x)\n", addr);
> +
> + memcpy(tb+1, pmsg->buf, pmsg->len);
> +
> + eieio();
> + setbits16(&tbdf->cbd_sc, BD_SC_READY | BD_SC_INTRPT);
> + }
> +}
> +
> +static int cpm_i2c_check_message(struct i2c_adapter *adap,
> + struct i2c_msg *pmsg, int tx, int rx)
> +{
> + cbd_t __iomem *tbdf;
> + cbd_t __iomem *rbdf;
> + u_char *tb;
> + u_char *rb;
> + struct cpm_i2c *cpm = i2c_get_adapdata(adap);
> +
> + tbdf = cpm->tbase + tx;
> + rbdf = cpm->rbase + rx;
> +
> + tb = cpm->txbuf[tx];
> + rb = cpm->rxbuf[rx];
> +
> + /* Align read buffer */
> + rb = (u_char *) (((uint) rb + 1) & ~1);
> +
> + eieio();
> + if (pmsg->flags & I2C_M_RD) {
> + dev_dbg(&adap->dev, "tx sc 0x%04x, rx sc 0x%04x\n",
> + in_be16(&tbdf->cbd_sc), in_be16(&rbdf->cbd_sc));
> +
> + if (in_be16(&tbdf->cbd_sc) & BD_SC_NAK) {
> + dev_err(&adap->dev, "IIC read; No ack\n");
> + return -EIO;
> + }
> + if (in_be16(&rbdf->cbd_sc) & BD_SC_EMPTY) {
> + dev_err(&adap->dev,
> + "IIC read; complete but rbuf empty\n");
> + return -EREMOTEIO;
> + }
> + if (in_be16(&rbdf->cbd_sc) & BD_SC_OV) {
> + dev_err(&adap->dev, "IIC read; Overrun\n");
> + return -EREMOTEIO;
> + }
> + memcpy(pmsg->buf, rb, pmsg->len);
> + } else {
> + dev_dbg(&adap->dev, "tx sc %d 0x%04x\n", tx,
> + in_be16(&tbdf->cbd_sc));
> +
> + if (in_be16(&tbdf->cbd_sc) & BD_SC_NAK) {
> + dev_err(&adap->dev, "IIC write; No ack\n");
> + return -EIO;
> + }
> + if (in_be16(&tbdf->cbd_sc) & BD_SC_UN) {
> + dev_err(&adap->dev, "IIC write; Underrun\n");
> + return -EIO;
> + }
> + if (in_be16(&tbdf->cbd_sc) & BD_SC_CL) {
> + dev_err(&adap->dev, "IIC write; Collision\n");
> + return -EIO;
> + }
> + }
> + return 0;
> +}
> +
> +static int cpm_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +{
> + struct cpm_i2c *cpm = i2c_get_adapdata(adap);
> + struct i2c_reg __iomem *i2c_reg = cpm->i2c_reg;
> + struct i2c_ram __iomem *i2c_ram = cpm->i2c_ram;
> + struct i2c_msg *pmsg;
> + int ret, i;
> + int tptr;
> + int rptr;
> + cbd_t __iomem *tbdf;
> + cbd_t __iomem *rbdf;
> +
> + if (num > CPM_MAXBD)
> + return -EINVAL;
> +
> + /* Check if we have any oversized READ requests */
> + for (i = 0; i < num; i++) {
> + pmsg = &msgs[i];
> + if (pmsg->len >= CPM_MAX_READ)
> + return -EINVAL;
> + }
> +
> + mutex_lock(&cpm->i2c_mutex);
> +
> + /* Reset to use first buffer */
> + out_be16(&i2c_ram->rbptr, in_be16(&i2c_ram->rbase));
> + out_be16(&i2c_ram->tbptr, in_be16(&i2c_ram->tbase));
> +
> + tbdf = cpm->tbase;
> + rbdf = cpm->rbase;
> +
> + tptr = 0;
> + rptr = 0;
> +
> + while (tptr < num) {
> + pmsg = &msgs[tptr];
> + dev_dbg(&adap->dev, "R: %d T: %d\n", rptr, tptr);
> +
> + cpm_i2c_parse_message(adap, pmsg, num, tptr, rptr);
> + if (pmsg->flags & I2C_M_RD)
> + rptr++;
> + tptr++;
> + }
> + /* Start transfer now */
> + /* Chip bug, set enable here */
> + out_8(&i2c_reg->i2cmr, 0x13); /* Enable RX/TX/Error interupts */
Hardcoded value. Some OR-ed defines should be more readable.
> + out_8(&i2c_reg->i2cer, 0xff); /* Clear interrupt status */
> + setbits8(&i2c_reg->i2mod, 1); /* Enable */
Hardcoded value.
> + /* Begin transmission */
> + setbits8(&i2c_reg->i2com, 0x80);
Hardcoded value. (I also wonder if 0x81 might be more suitable, as it
keeps the "be-a-master"-bit set. Still, both values work with my setup.)
> +
> + tptr = 0;
> + rptr = 0;
> +
> + while (tptr < num) {
> + /* Check for outstanding messages */
> + dev_dbg(&adap->dev, "test ready.\n");
> + pmsg = &msgs[tptr];
> + if (pmsg->flags & I2C_M_RD)
> + ret = wait_event_interruptible_timeout(cpm->i2c_wait,
> + !(in_be16(&rbdf[rptr].cbd_sc) & BD_SC_EMPTY),
> + 1 * HZ);
> + else
> + ret = wait_event_interruptible_timeout(cpm->i2c_wait,
> + !(in_be16(&tbdf[tptr].cbd_sc) & BD_SC_READY),
> + 1 * HZ);
> + if (ret == 0) {
> + ret = -EREMOTEIO;
> + dev_dbg(&adap->dev, "I2C read: timeout!\n");
> + goto out_err;
> + }
> + if (ret > 0) {
> + dev_dbg(&adap->dev, "ready.\n");
> + ret = cpm_i2c_check_message(adap, pmsg, tptr, rptr);
> + tptr++;
> + if (pmsg->flags & I2C_M_RD)
> + rptr++;
> + if (ret)
> + goto out_err;
> + }
> + }
> +#ifdef I2C_CHIP_ERRATA
> + /*
> + * Chip errata, clear enable. This is not needed on rev D4 CPUs.
> + * Disabling I2C too early may cause too short stop condition
> + */
> + udelay(4);
> + clrbits8(&i2c_reg->i2mod, 1);
I was unable to find the corresponding errata document, still I wonder
if it is a 0 which should have been written? The text says "clear" and
according to the reference manual, this means the bit should be 0.
> +#endif
> + mutex_unlock(&cpm->i2c_mutex);
> + return (num);
> +
> +out_err:
> + cpm_i2c_force_close(adap);
> +#ifdef I2C_CHIP_ERRATA
> + /*
> + * Chip errata, clear enable. This is not needed on rev D4 CPUs.
> + */
> + clrbits8(&i2c_reg->i2mod, 1);
write 0? see above.
> +#endif
> + mutex_unlock(&cpm->i2c_mutex);
> + return ret;
> +}
> +
> +static u32 cpm_i2c_func(struct i2c_adapter *adap)
> +{
> + return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
> +}
> +
> +/* -----exported algorithm data: ------------------------------------- */
> +
> +static const struct i2c_algorithm cpm_i2c_algo = {
> + .master_xfer = cpm_i2c_xfer,
> + .functionality = cpm_i2c_func,
> +};
> +
> +static const struct i2c_adapter cpm_ops = {
> + .owner = THIS_MODULE,
> + .name = "i2c-cpm",
> + .algo = &cpm_i2c_algo,
> + .class = I2C_CLASS_HWMON,
> +};
> +
> +static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)
> +{
> + struct of_device *ofdev = cpm->ofdev;
> + const u32 *data;
> + int len, ret, i;
> + void __iomem *i2c_base;
> + cbd_t __iomem *tbdf;
> + cbd_t __iomem *rbdf;
> + unsigned char brg;
> +
> + dev_dbg(&cpm->ofdev->dev, "cpm_i2c_setup()\n");
> +
> + init_waitqueue_head(&cpm->i2c_wait);
> + mutex_init(&cpm->i2c_mutex);
> +
> + cpm->irq = of_irq_to_resource(ofdev->node, 0, NULL);
> + if (cpm->irq == NO_IRQ)
> + return -EINVAL;
> +
> + /* Install interrupt handler. */
> + ret = request_irq(cpm->irq, cpm_i2c_interrupt, 0, "cpm_i2c",
> + &cpm->adap);
> + if (ret)
> + goto out_irq;
> +
> + /* IIC parameter RAM */
> + i2c_base = of_iomap(ofdev->node, 1);
> + if (i2c_base == NULL) {
> + ret = -EINVAL;
> + goto out_irq;
> + }
> +
> + if (of_device_is_compatible(ofdev->node, "fsl,cpm1-i2c")) {
> +
> + /* Check for and use a microcode relocation patch. */
> + cpm->i2c_ram = i2c_base;
> + cpm->i2c_addr = in_be16(&cpm->i2c_ram->rpbase);
> +
> + /*
> + * Maybe should use cpm_muram_alloc instead of hardcoding
> + * this in micropatch.c
> + */
> + if (cpm->i2c_addr) {
> + cpm->i2c_ram = cpm_muram_addr(cpm->i2c_addr);
> + iounmap(i2c_base);
> + }
> +
> + cpm->version = 1;
> +
> + } else if (of_device_is_compatible(ofdev->node, "fsl,cpm2-i2c")) {
> + cpm->i2c_addr = cpm_muram_alloc(sizeof(struct i2c_ram), 64);
> + cpm->i2c_ram = cpm_muram_addr(cpm->i2c_addr);
> + out_be16(i2c_base, cpm->i2c_addr);
> + iounmap(i2c_base);
> +
> + cpm->version = 2;
> +
> + } else {
> + iounmap(i2c_base);
> + ret = -EINVAL;
> + goto out_irq;
> + }
> +
> + /* I2C control/status registers */
> + cpm->i2c_reg = of_iomap(ofdev->node, 0);
> + if (cpm->i2c_reg == NULL) {
> + ret = -EINVAL;
> + goto out_ram;
> + }
> +
> + data = of_get_property(ofdev->node, "fsl,cpm-command", &len);
> + if (!data || len != 4) {
> + ret = -EINVAL;
> + goto out_reg;
> + }
> + cpm->cp_command = *data;
> +
> + data = of_get_property(ofdev->node, "linux,i2c-class", &len);
> + if (data && len == 4)
> + cpm->adap.class = *data;
> +
> + /*
> + * Allocate space for CPM_MAXBD transmit and receive buffer
> + * descriptors in the DP ram.
> + */
> + cpm->dp_addr = cpm_muram_alloc(sizeof(cbd_t) * 2 * CPM_MAXBD, 8);
> + if (!cpm->dp_addr) {
> + ret = -ENOMEM;
> + goto out_reg;
> + }
> +
> + cpm->tbase = cpm_muram_addr(cpm->dp_addr);
> + cpm->rbase = cpm_muram_addr(cpm->dp_addr + sizeof(cbd_t) * CPM_MAXBD);
> +
> + /* Allocate TX and RX buffers */
> +
> + tbdf = cpm->tbase;
> + rbdf = cpm->rbase;
> +
> + for (i = 0; i < CPM_MAXBD; i++) {
> + cpm->rxbuf[i] = dma_alloc_coherent(
> + NULL, CPM_MAX_READ + 1, &cpm->rxdma[i], GFP_KERNEL);
> + if (!cpm->rxbuf[i]) {
> + ret = -ENOMEM;
> + goto out_muram;
> + }
> + out_be32(&rbdf[i].cbd_bufaddr, ((cpm->rxdma[i] + 1) & ~1));
> +
> + cpm->txbuf[i] = (unsigned char *)dma_alloc_coherent(
> + NULL, CPM_MAX_READ + 1, &cpm->txdma[i], GFP_KERNEL);
> + if (!cpm->txbuf[i]) {
> + ret = -ENOMEM;
> + goto out_muram;
> + }
> + out_be32(&tbdf[i].cbd_bufaddr, cpm->txdma[i]);
> + }
> +
> + /* Initialize Tx/Rx parameters. */
> +
> + cpm_reset_i2c_params(cpm);
> +
> + dev_dbg(&cpm->ofdev->dev, "i2c_ram %p, i2c_addr 0x%04x\n",
> + cpm->i2c_ram, cpm->i2c_addr);
> + dev_dbg(&cpm->ofdev->dev, "tbase 0x%04x, rbase 0x%04x\n",
> + (u8 __iomem *)cpm->tbase - DPRAM_BASE,
> + (u8 __iomem *)cpm->rbase - DPRAM_BASE);
> +
> + cpm_command(cpm->cp_command, CPM_CR_INIT_TRX);
> +
> + /*
> + * Select an invalid address. Just make sure we don't use loopback mode
> + */
> + out_8(&cpm->i2c_reg->i2add, 0xfe);
Maybe 0x7f << 1 is a tiny bit more obvious?
> +
> + /* Make clock run at 60 kHz. */
> +
> + brg = get_brgfreq() / (32 * 2 * 60000) - 3;
> + out_8(&cpm->i2c_reg->i2brg, brg);
> +
> + out_8(&cpm->i2c_reg->i2mod, 0x00);
> + out_8(&cpm->i2c_reg->i2com, 0x01); /* Master mode */
Hardcoded value.
> +
> + /* Disable interrupts. */
> + out_8(&cpm->i2c_reg->i2cmr, 0);
> + out_8(&cpm->i2c_reg->i2cer, 0xff);
> +
> + return 0;
> +
> +out_muram:
> + for (i = 0; i < CPM_MAXBD; i++) {
> + if (cpm->rxbuf[i])
> + dma_free_coherent(NULL, CPM_MAX_READ + 1,
> + cpm->rxbuf[i], cpm->rxdma[i]);
> + if (cpm->txbuf[i])
> + dma_free_coherent(NULL, CPM_MAX_READ + 1,
> + cpm->txbuf[i], cpm->txdma[i]);
> + }
> + cpm_muram_free(cpm->dp_addr);
> +out_reg:
> + iounmap(cpm->i2c_reg);
> +out_ram:
> + if ((cpm->version == 1) && (!cpm->i2c_addr))
> + iounmap(cpm->i2c_ram);
> + if (cpm->version == 2)
> + cpm_muram_free(cpm->i2c_addr);
> +out_irq:
> + free_irq(cpm->irq, &cpm->adap);
> + return ret;
> +}
> +
> +static void cpm_i2c_shutdown(struct cpm_i2c *cpm)
> +{
> + int i;
> +
> + /* Shut down I2C. */
> + clrbits8(&cpm->i2c_reg->i2mod, 1);
write 0? see above.
> +
> + /* Disable interrupts */
> + out_8(&cpm->i2c_reg->i2cmr, 0);
> + out_8(&cpm->i2c_reg->i2cer, 0xff);
> +
> + free_irq(cpm->irq, &cpm->adap);
> +
> + /* Free all memory */
> + for (i = 0; i < CPM_MAXBD; i++) {
> + dma_free_coherent(NULL, CPM_MAX_READ + 1,
> + cpm->rxbuf[i], cpm->rxdma[i]);
> + dma_free_coherent(NULL, CPM_MAX_READ + 1,
> + cpm->txbuf[i], cpm->txdma[i]);
> + }
> +
> + cpm_muram_free(cpm->dp_addr);
> + iounmap(cpm->i2c_reg);
> +
> + if ((cpm->version == 1) && (!cpm->i2c_addr))
> + iounmap(cpm->i2c_ram);
> + if (cpm->version == 2)
> + cpm_muram_free(cpm->i2c_addr);
> +
> + return;
> +}
> +
> +static int __devinit cpm_i2c_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + int result;
> + struct cpm_i2c *cpm;
> +
> + cpm = kzalloc(sizeof(struct cpm_i2c), GFP_KERNEL);
> + if (!cpm)
> + return -ENOMEM;
> +
> + cpm->ofdev = ofdev;
> +
> + dev_set_drvdata(&ofdev->dev, cpm);
> +
> + cpm->adap = cpm_ops;
> + i2c_set_adapdata(&cpm->adap, cpm);
> + cpm->adap.dev.parent = &ofdev->dev;
> +
> + result = cpm_i2c_setup(cpm);
> + if (result) {
> + dev_err(&ofdev->dev, "Unable to init hardware\n");
> + goto out_free;
> + }
> +
> + /* register new adapter to i2c module... */
> +
> + result = i2c_add_adapter(&cpm->adap);
> + if (result < 0) {
> + dev_err(&ofdev->dev, "Unable to register with I2C\n");
> + goto out_shut;
> + }
> +
> + dev_dbg(&ofdev->dev, "hw routines for %s registered.\n",
> + cpm->adap.name);
> +
> + /*
> + * register OF I2C devices
> + */
> + of_register_i2c_devices(&cpm->adap, ofdev->node);
> +
> + return 0;
> +out_shut:
> + cpm_i2c_shutdown(cpm);
> +out_free:
> + dev_set_drvdata(&ofdev->dev, NULL);
> + kfree(cpm);
> +
> + return result;
> +}
> +
> +static int __devexit cpm_i2c_remove(struct of_device *ofdev)
> +{
> + struct cpm_i2c *cpm = dev_get_drvdata(&ofdev->dev);
> +
> + i2c_del_adapter(&cpm->adap);
> +
> + cpm_i2c_shutdown(cpm);
> +
> + dev_set_drvdata(&ofdev->dev, NULL);
> + kfree(cpm);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id cpm_i2c_match[] = {
> + {
> + .compatible = "fsl,cpm-i2c",
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, cpm_i2c_match);
> +
> +static struct of_platform_driver cpm_i2c_driver = {
> + .match_table = cpm_i2c_match,
> + .probe = cpm_i2c_probe,
> + .remove = __devexit_p(cpm_i2c_remove),
> + .driver = {
> + .name = "fsl-i2c-cpm",
> + .owner = THIS_MODULE,
> + }
> +};
> +
> +static int __init cpm_i2c_init(void)
> +{
> + return of_register_platform_driver(&cpm_i2c_driver);
> +}
> +
> +static void __exit cpm_i2c_exit(void)
> +{
> + of_unregister_platform_driver(&cpm_i2c_driver);
> +}
> +
> +module_init(cpm_i2c_init);
> +module_exit(cpm_i2c_exit);
> +
> +MODULE_AUTHOR("Jochen Friedrich <jochen@scram.de>");
> +MODULE_DESCRIPTION("I2C-Bus adapter routines for CPM boards");
> +MODULE_LICENSE("GPL");
> --
> 1.5.4.5
>
>
>
>
> _______________________________________________
> i2c mailing list
> i2c@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c
In general, the driver works well for me (just had to disable broadcast
responses; eeprom at 00-1f \o/).
Kind regards,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add support for Analogue & Micro ASP837E board
From: Kumar Gala @ 2008-05-06 13:37 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-dev
In-Reply-To: <20080506032813.19e2d07a@neuromancer.mindspace>
>
> @@ -0,0 +1,247 @@
> +/*
> + * Analogue & Micro ASP8347 Device Tree Source
> + *
> + * Copyright 2008 Codehermit
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "ASP8347E";
> + compatible = "ASP8347E";
"analogue-and-micro, ASP8347E";
>
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8347@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + d-cache-size = <32768>;
> + i-cache-size = <32768>;
> + timebase-frequency = <0>; // from bootloader
> + bus-frequency = <0>; // from bootloader
> + clock-frequency = <0>; // from bootloader
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x8000000>; // 128MB at 0
is memory really fixed on this board or does the bootloader set this
if, dynamic make it <0 0>
>
> + };
> +
> + localbus@ff005000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8347e-localbus",
> + "fsl,pq2pro-localbus",
> + "simple-bus";
> + reg = <0xff005000 0x1000>;
> + interrupts = <77 0x8>;
> + interrupt-parent = <&ipic>;
> +
> + ranges = <
> + 0 0 0xf0000000 0x02000000
> + >;
> +
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 0x02000000>;
> + bank-width = <2>;
> + device-width = <2>;
> + };
> + };
> +
> + soc8349@ff000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0x0 0xff000000 0xff100000>;
this is wrong, size should be like 0x100000
>
> + reg = <0xff000000 0x00000200>;
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
> + compatible = "mpc83xx_wdt";
> + reg = <0x200 0x100>;
> + };
> +
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> +
> + rtc@68 {
> + compatible = "dallas,ds1374";
> + reg = <0x68>;
> + };
> + };
> +
> + i2c@3100 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <1>;
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <15 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
> + spi@7000 {
> + cell-index = <0>;
> + compatible = "fsl,spi";
> + reg = <0x7000 0x1000>;
> + interrupts = <16 0x8>;
> + interrupt-parent = <&ipic>;
> + mode = "cpu";
> + };
> +
> + /* phy type (ULPI or SERIAL) are only types supported for MPH */
> + /* port = 0 or 1 */
> + usb@22000 {
> + compatible = "fsl-usb2-mph";
> + reg = <0x22000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupt-parent = <&ipic>;
> + interrupts = <39 0x8>;
> + phy_type = "ulpi";
> + port1;
> + };
> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> + usb@23000 {
> + compatible = "fsl-usb2-dr";
> + reg = <0x23000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupt-parent = <&ipic>;
> + interrupts = <38 0x8>;
> + dr_mode = "otg";
> + phy_type = "ulpi";
> + };
> +
> + mdio@24520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-mdio";
> + reg = <0x24520 0x20>;
> +
> + phy0: ethernet-phy@0 {
> + interrupt-parent = <&ipic>;
> + interrupts = <17 0x8>;
> + reg = <0x1>;
> + device_type = "ethernet-phy";
> + };
> + phy1: ethernet-phy@1 {
> + interrupt-parent = <&ipic>;
> + interrupts = <18 0x8>;
> + reg = <0x2>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + enet0: ethernet@24000 {
> + cell-index = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <0x24000 0x1000>;
> + local-mac-address = [ 00 08 e5 11 32 33 ];
> + interrupts = <32 0x8 33 0x8 34 0x8>;
> + interrupt-parent = <&ipic>;
> + phy-handle = <&phy0>;
> + linux,network-index = <0>;
you shouldn't need this anymore. we should be using the aliases.
>
> + };
> +
> + enet1: ethernet@25000 {
> + cell-index = <1>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <0x25000 0x1000>;
> + local-mac-address = [ 00 08 e5 11 32 34 ];
> + interrupts = <35 0x8 36 0x8 37 0x8>;
> + interrupt-parent = <&ipic>;
> + phy-handle = <&phy1>;
> + linux,network-index = <1>;
ditto.
>
> + };
> +
> + serial0: serial@4500 {
> + cell-index = <0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4500 0x100>;
> + clock-frequency = <400000000>;
> + interrupts = <9 0x8>;
> + interrupt-parent = <&ipic>;
> + };
> +
> + serial1: serial@4600 {
> + cell-index = <1>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4600 0x100>;
> + clock-frequency = <400000000>;
> + interrupts = <10 0x8>;
> + interrupt-parent = <&ipic>;
> + };
> +
> + /* May need to remove if on a part without crypto engine */
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
> + reg = <0x30000 0x10000>;
> + interrupts = <11 0x8>;
> + interrupt-parent = <&ipic>;
> + num-channels = <4>;
> + channel-fifo-len = <24>;
> + exec-units-mask = <0x0000007e>;
> + /* desc mask is for rev2.0,
> + * we need runtime fixup for >2.0 */
> + descriptor-types-mask = <0x01010ebf>;
> + };
> +
> + /* IPIC
> + * interrupts cell = <intr #, sense>
> + * sense values match linux IORESOURCE_IRQ_* defines:
> + * sense == 8: Level, low assertion
> + * sense == 2: Edge, high-to-low change
> + */
> + ipic: pic@700 {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
> + };
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,38400 root=/dev/mtdblock3
> rootfstype=jffs2";
> + linux,stdout-path = &serial0;
> + };
> +
> +};
- k
^ permalink raw reply
* Re: [PATCH] add Phytec pcm030 board support
From: Jon Smirl @ 2008-05-06 12:47 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080506080811.GB4326@pengutronix.de>
On 5/6/08, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, May 05, 2008 at 01:22:40PM -0400, Jon Smirl wrote:
> > On 5/5/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On Mon, May 5, 2008 at 11:01 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > Did this get fixed somehow? I used to need this to boot a pcm030.
> > >
> > >
> > > I'm sorry; I'm at a lost as to context. Are you asking for this patch
> > > to be applied? Or are you asking if this has been addressed in
> > > another way?
> >
> > Sascha said the pcm030 was working with the simple dts. I always
> > needed that patch to get a pcm030 to boot. Sasha's company wrote the
> > patch. I'm just wondering how it got handled, do we still need the
> > patch or did he come up with some other solution.
>
>
> Yes, it is working with the simple dts except for the flash support. For
> this we need the Flash description in the oftree.
>
>
> > > >
> > > > diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
> > > > index 272872d..c982adc 100644
> > > > --- a/fs/jffs2/scan.c
> > > > +++ b/fs/jffs2/scan.c
> > > > @@ -16,6 +16,7 @@
> > > > #include <linux/pagemap.h>
> > > > #include <linux/crc32.h>
> > > > #include <linux/compiler.h>
> > > > +#include <asm/io.h>
> > > > #include "nodelist.h"
> > > > #include "summary.h"
> > > > #include "debug.h"
> > > > @@ -505,7 +506,7 @@ static int jffs2_scan_eraseblock (struct
> > > > jffs2_sb_info *c, struct jffs2_eraseblo
> > > > sumptr = kmalloc(sumlen, GFP_KERNEL);
> > > > if (!sumptr)
> > > > return -ENOMEM;
> > > > - memcpy(sumptr + sumlen -
> > > > buf_len, buf + buf_size - buf_len, buf_len);
> > > > + memcpy_fromio(sumptr + sumlen
> > > > - buf_len, buf + buf_size - buf_len, buf_len);
> > > > }
> > > > if (buf_len < sumlen) {
> > > > /* Need to read more so that
> > > > the entire summary node is present */
> > > > @@ -1035,7 +1036,7 @@ static int jffs2_scan_dirent_node(struct
> > > > jffs2_sb_info *c, struct jffs2_eraseblo
> > > > if (!fd) {
> > > > return -ENOMEM;
> > > > }
> > > > - memcpy(&fd->name, rd->name, checkedlen);
> > > > + memcpy_fromio(&fd->name, rd->name, checkedlen);
>
>
> This patch is needed because memcpy uses unaligned accesses whereas
> memcpy_fromio only uses aligned accesses on the io side. See this
> thread: http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022544.html
Can you submit it for inclusion? That's the last thing needed to boot
a pcm030 on a standard kernel, right?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Benjamin Herrenschmidt @ 2008-05-06 11:34 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, cjg
In-Reply-To: <s5hiqxrd5yg.wl%tiwai@suse.de>
On Tue, 2008-05-06 at 13:31 +0200, Takashi Iwai wrote:
> > I don't think we can easily update the DMA API at this stage. What
> we
> > could do is provide a way to retrieve the struct page array from the
> > result of dma_alloc_coherent...
>
> In most cases, it can be obtained via pfn_to_page(), I suppose. But,
> it's definitely arch-specific thingy, and a generic solution would be
> really appreciated.
You can't get a pfn out of the result of dma_alloc_coherent on
non-coherent powerpc at least. It's a virtual mapping created from the
underlying pages set to be non-cacheable. virt_to_* will do no good.
> Alternatively, we can change the ALSA PCM core code that accesses the
> virtual linear buffer and handles SG-buffers as they are. Maybe it'll
> give a bit more useful clean-up in the whole memory-management codes
> in ALSA in the end.
I need to get my head around what the exact usage in Alsa is, and it's a
bit too late for me to thing right now :-)
Ben.
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Takashi Iwai @ 2008-05-06 11:31 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, cjg
In-Reply-To: <1210073153.21644.175.camel@pasglop>
At Tue, 06 May 2008 21:25:53 +1000,
Benjamin Herrenschmidt wrote:
>
>
> On Tue, 2008-05-06 at 13:14 +0200, Takashi Iwai wrote:
> > > sg allocations are usually lists of page, so virt_to_page shouldn't
> > be a
> > > problem in the first place, though we still need some way to get the
> > > right prot attributes.
> >
> > The problem is that ALSA SG buffer is composed from pages allocated
> > via dma_alloc_coherent(), and the pages are retrieved via virt_to_page
> > for DMA pages, as found in sound/core/sgbuf.c.
> >
> > I didn't care about SG-buffer cases in my initial patch, and it's a
> > bit messy. The current code requires page lists becasue it calls
> > vmap() to get a virtually linear buffer.
>
> Hrm... the problem is that you aren't supposed to make up sglists with
> the result of dma_alloc_coherent... It might be a limitation of our core
> DMA API, but that's we have to deal with today..
>
> If you're going to make up sglists and call vmap, you should allocate
> pages with normal GFP. If that is a problem vs. DMA'bility of those
> pages, then ... we have a problem :-)
>
> I don't think we can easily update the DMA API at this stage. What we
> could do is provide a way to retrieve the struct page array from the
> result of dma_alloc_coherent...
In most cases, it can be obtained via pfn_to_page(), I suppose. But,
it's definitely arch-specific thingy, and a generic solution would be
really appreciated.
Alternatively, we can change the ALSA PCM core code that accesses the
virtual linear buffer and handles SG-buffers as they are. Maybe it'll
give a bit more useful clean-up in the whole memory-management codes
in ALSA in the end.
Takashi
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Benjamin Herrenschmidt @ 2008-05-06 11:27 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, cjg
In-Reply-To: <1210073153.21644.175.camel@pasglop>
> Hrm... the problem is that you aren't supposed to make up sglists with
> the result of dma_alloc_coherent... It might be a limitation of our core
> DMA API, but that's we have to deal with today..
>
> If you're going to make up sglists and call vmap, you should allocate
> pages with normal GFP. If that is a problem vs. DMA'bility of those
> pages, then ... we have a problem :-)
>
> I don't think we can easily update the DMA API at this stage. What we
> could do is provide a way to retrieve the struct page array from the
> result of dma_alloc_coherent...
Another option is to allocate the pages with gfp, and then dma_map_sg
the result... However, if we do that, we do need to add a way to vmap
with the right protection in order to get a coherent (ie. non cacheable)
mapping. I'm not even sure all archs can do that....
Ben.
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Benjamin Herrenschmidt @ 2008-05-06 11:25 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, cjg
In-Reply-To: <s5hlk2nd6r5.wl%tiwai@suse.de>
On Tue, 2008-05-06 at 13:14 +0200, Takashi Iwai wrote:
> > sg allocations are usually lists of page, so virt_to_page shouldn't
> be a
> > problem in the first place, though we still need some way to get the
> > right prot attributes.
>
> The problem is that ALSA SG buffer is composed from pages allocated
> via dma_alloc_coherent(), and the pages are retrieved via virt_to_page
> for DMA pages, as found in sound/core/sgbuf.c.
>
> I didn't care about SG-buffer cases in my initial patch, and it's a
> bit messy. The current code requires page lists becasue it calls
> vmap() to get a virtually linear buffer.
Hrm... the problem is that you aren't supposed to make up sglists with
the result of dma_alloc_coherent... It might be a limitation of our core
DMA API, but that's we have to deal with today..
If you're going to make up sglists and call vmap, you should allocate
pages with normal GFP. If that is a problem vs. DMA'bility of those
pages, then ... we have a problem :-)
I don't think we can easily update the DMA API at this stage. What we
could do is provide a way to retrieve the struct page array from the
result of dma_alloc_coherent...
Ben.
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Takashi Iwai @ 2008-05-06 11:14 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, cjg
In-Reply-To: <1210068747.21644.164.camel@pasglop>
At Tue, 06 May 2008 20:12:27 +1000,
Benjamin Herrenschmidt wrote:
>
>
> On Tue, 2008-05-06 at 11:16 +0200, Gerhard Pircher wrote:
> > I can't answer this question. *ducked* :-) Takashi?
> >
> > FYI: I posted the results of the test with Takashi's dma_mmap_coherent
> > patch here:
> > http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html
> >
> > On the other side it looks like this problem does not only affect
> > ALSA.
> > As far as I can tell also some V4L(2) drivers have a problem with
> > mmaping
> > non coherent DMA allocations, but I'm not sure (it's a long time since
> > I
> > did some tests with video cards on my AmigaOne).
> >
> > Naturally I can do some tests, if you or Takashi come up with a new
> > patch.
>
> Time that we sort that stuff out once for all..
>
> sg allocations are usually lists of page, so virt_to_page shouldn't be a
> problem in the first place, though we still need some way to get the
> right prot attributes.
The problem is that ALSA SG buffer is composed from pages allocated
via dma_alloc_coherent(), and the pages are retrieved via virt_to_page
for DMA pages, as found in sound/core/sgbuf.c.
I didn't care about SG-buffer cases in my initial patch, and it's a
bit messy. The current code requires page lists becasue it calls
vmap() to get a virtually linear buffer.
Takashi
^ permalink raw reply
* Re: ALSA vs. non coherent DMA
From: Takashi Iwai @ 2008-05-06 11:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, alsa-devel, Linux Kernel list
In-Reply-To: <1210032508.21644.129.camel@pasglop>
Hi Ben,
thanks for signaling this long-standing issue again.
At Tue, 06 May 2008 10:08:28 +1000,
Benjamin Herrenschmidt wrote:
>
> Hi Takashi !
>
> I'm bringing up an old thread as I'm just discovering that the problem
> still hasn't been fixed.
>
> There seem to be a few issues with ALSA current usage of mmap vs. non
> cache coherent architecture, such as embedded PowerPC's.
Yep. And on MIPS, obviously.
> I can see at least two with a quick look to pcm-native.c, one I don't
> understand and one I think I do:
>
> - The control/status mapping. Can you elaborate a bit on what this is
> actually doing and why it shouldn't be done on "non coherent"
> architectures ?
This is a mmap of the data record to be shared in realtime with apps.
The app updates its data pointer (appl_ptr) on the mmapped buffer
while the driver updates the data (e.g. DMA position, called hwptr) on
the fly on the mmapped record. Due to its real-time nature, it has to
be coherent -- at least, it was a problem on ARM.
> Currently this -is- done on all powerpc's, whether they
> are coherent or not and I want to understand what the underlying issue
> is.
It's actually buggy. Should check more precisely.
> - The mmap of DMA pages. Here, the problem appears two fold:
>
> * Use of virt_to_page() on virtual addresses returned by
> dma_alloc_coherent().
>
> * No using the appropriate page protection for a DMA coherent mapping
> to userspace.
>
> It seems like you have solved that in part with implementing a generic
> dma_mmap_coherent() in the past that for some reason you never merged
> upstream (I can track that to about 2 years ago). Is there a reason ?
IIRC, dma_mmap_coherent() cannot be implemented properly on some
architectures. This is no big problem for ALSA as long as it returns
an error or make it out via ifdef. But, the fact that this API cannot
be done for all archs discourage arch maintainers, and the idea faded
out again.
> I think we need to at least apply a band-aid today as it's becoming a
> nasty issue for several non-coherent powerpc platforms. It could be in
> the form of implementing dma_mmap_coherent() and changing Alsa to use it
> with the appropriate ifdef, or just adding an ifdef CONFIG_PPC with the
> right code in there for now until a better solution is found.
Agreed.
> It should be trivial though. Getting the PFN from the DMA address is
> easy if we have the dma handle and the virtual address, though that -is-
> definitely platform specific. I can implement a function for that if you
> need.
That'll be great. dma_mmap_coherent() and friends would be then
really helpful to solve this issue.
> As for the pgprot, we can come up with something like
> pgprot_mmap_dma(). Either that or I can fold it all in a powerpc wide
> implementation of a dma_mmap_coherent() like we envisioned initially.
In principle, pgprot_*() isn't actually needed in the driver side at
all. We use pgprot_noncached() in one part, and it's for hacky way to
mmap the ioremapped pages. It's not available on all architectures,
and I'm not sure whether it works on all PPC models although it's
enabled right now: in include/sound/pcm.h,
/* mmap for io-memory area */
#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA)
#define SNDRV_PCM_INFO_MMAP_IOMEM SNDRV_PCM_INFO_MMAP
int snd_pcm_lib_mmap_iomem(struct snd_pcm_substream *substream, struct vm_area_struct *area);
#else
#define SNDRV_PCM_INFO_MMAP_IOMEM 0
#define snd_pcm_lib_mmap_iomem NULL
#endif
Highly likely we need to fix this, too. In the easiest way, disable
this except for X86...
> Let me know what approach is preferred here and I'll come up with
> patches ASAP. As far as I'm concerned, this is a bug and thus must be
> fixed now for .26 and possibly backported to stable even if we can come
> up with a non invasive solution). I'm annoyed because it represents a
> trivial amount of code, this problem should have been fixed a long time
> ago.
As a pragmatic solution, as you mentioned in the above, we can disable
or change the problematic code with ifdefs. At best, use
dma_mmap_coherent() if it's available. If not, and if the arch is
known to have not-simply-mappable DMA pages (like MIPS), we can simply
disable the mmap feature.
Once after we have dma_mmap_*() generally, we can clean up codes.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.
From: Segher Boessenkool @ 2008-05-06 10:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080506061444.GB17798@yookeroo.seuss>
> Current standard practice is not to represent the DCR bus as node with
> subnodes for the DCR-controlled devices. That's because the DCR bus
> tends to run in addition to other on-chip busses, and some things have
> to go on another on-chip bus to make sense, but still have DCR control
> registers (for example the internal bus bridges on 4xx).
Yeah.
> Arguably for DCR-only devices we should instead have a node
> representing the DCR bus and just put the devices under it with the
> DCR number encoded in reg in the normal way.
Right.
> But then its
> inconsistent with the devices that need the other DCR representation.
OTOH, it _is_ consistent with all other (non-DCR) devices that way.
What you could do right now is to give such DCR-only devices both
normal "reg" etc., and the "dcr-reg" etc. properties, containing
both the same info. If you do that, your device tree will be
correct (because you got all the standard stuff right), and the
kernel will like it as well (because it looks for the "dcr-reg"
stuff).
Then maybe later, if/when the kernel supports the standard addressing
for DCR as well, you could drop the "dcr-reg" things from your DTS.
Or you could just keep it.
David, will this work, do you think?
> Segher and I did toss around some ideas for generalizing the DCR
> representation to a way of representing that any node has some
> presence on a bus other than its "primary" parent (e.g. other-bus-reg
> = <&dcr-bus 0x0d0 0x010 &strange-i2c-control-bus 0xabc>). Then
> DCR-only devices would use normal "reg", devices that sit on another
> bus would sit on that bus and use this representation to show their
> DCR control registers. Maybe one day.
One day perhaps, yes :-)
It sounds cleaner to split such a prop into separate props per bus.
Maybe I said the opposite before, heh :-)
Segher
^ permalink raw reply
* Re: [patch 5/5] PS3: Update ps3_defconfig
From: Michael Ellerman @ 2008-05-06 10:51 UTC (permalink / raw)
To: Marvin; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <200805061014.16229.marvin24@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
On Tue, 2008-05-06 at 10:14 +0200, Marvin wrote:
> Hi Geoff,
>
> On Monday 05 May 2008 21:00:47 you wrote:
> > Marvin wrote:
> > > what about adding these defaults:
> > > - CONFIG_SCHED_SMT
> > > - CONFIG_HUGETLBFS (needed by ibm cell sdk)
>
> I'm using these for years now ;-)
>
> > > not sure about:
> > > - CONFIG_SPU_FS_64K_LS
>
> I also have this option enabled. I think you can forget about it, as it seems
> to improve performance only in some corner cases. I'm not an expert, so maybe
> asking at cbe-oss-dev would be a better place.
Assuming it works on PS3 (the HV lets us use 64k pages I take it?) I
think it should be enabled.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] booting-without-of for Freescale MSI
From: Segher Boessenkool @ 2008-05-06 10:44 UTC (permalink / raw)
To: Jin Zhengxiong; +Cc: linuxppc-dev
In-Reply-To: <CC27DED0F8F39E48A7E75FD768688B7A8C1399@zch01exm27.fsl.freescale.net>
>>> + - compatible : should be "fsl,MPIC-MSI" for 85xx/86xx cpu,
>>> + and "fsl,IPIC-MSI" for 83xx cpu.
>>
>> Please use a more specific name, "fsl,8599-msi" or similar?
>>
>
> Thanks for your input. I think the name "fsl,MPIC-MSI" and
> "fsl,IPIC-MSI"
> is somethind specific.
This is the third MSI-on-MPIC I've seen, and I doubt it will be the
last. It is likely FSL will make some different one in the future,
as well.
Please don't use generic names for specific devices.
Segher
^ permalink raw reply
* Re: [PATCH] Add support for Analogue & Micro ASP837E board
From: Bryan O'Donoghue @ 2008-05-06 10:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080506161110.02c2f974.sfr@canb.auug.org.au>
On Tue, 6 May 2008 16:11:10 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Bryan,
>
> On Tue, 6 May 2008 03:28:13 +0100 Bryan O'Donoghue <bodonoghue@codehermit.ie>
> wrote:
> >
> > +static void __init asp834x_init_IRQ(void)
> > +{
> > + struct device_node *np;
> > +
> > + np = of_find_node_by_type(NULL, "ipic");
> > + if (!np)
> > + return;
> > +
> > + ipic_init(np, 0);
>
> You need an "of_node_put(np)" here to drop the reference gained in
> "of_find_node_by_type".
>
> > +static struct of_device_id asp8347_ids[] = {
>
> Please make this __initdata.
>
Hey Stephen.
Thanks for spotting that. Will do.
Cheers,
Bryan
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Benjamin Herrenschmidt @ 2008-05-06 10:12 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: tiwai, linuxppc-dev, cjg
In-Reply-To: <20080506091622.269180@gmx.net>
On Tue, 2008-05-06 at 11:16 +0200, Gerhard Pircher wrote:
> I can't answer this question. *ducked* :-) Takashi?
>
> FYI: I posted the results of the test with Takashi's dma_mmap_coherent
> patch here:
> http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html
>
> On the other side it looks like this problem does not only affect
> ALSA.
> As far as I can tell also some V4L(2) drivers have a problem with
> mmaping
> non coherent DMA allocations, but I'm not sure (it's a long time since
> I
> did some tests with video cards on my AmigaOne).
>
> Naturally I can do some tests, if you or Takashi come up with a new
> patch.
Time that we sort that stuff out once for all..
sg allocations are usually lists of page, so virt_to_page shouldn't be a
problem in the first place, though we still need some way to get the
right prot attributes.
Ben.
^ permalink raw reply
* Re: [Cbe-oss-dev] Xorg crash when PCI not enabled (was [patch 5/5] PS3: Update ps3_defconfig)
From: Dan Munckton @ 2008-05-06 9:44 UTC (permalink / raw)
To: Marvin; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <200805061014.16229.marvin24@gmx.de>
Hi
On Tue, 2008-05-06 at 10:14 +0200, Marvin wrote:
> p.s. I installed fc9 last week and Xorg crashes when PCI is not
> enabled. just
> in case someone has the same problem.
The Ubuntu PS3 team is also working on an a couple of bugs relating to
lack of PCI info. I don't know if these are the same issues you're
facing. We're tracking them here at [0] and [2].
We had an initial crash was simple to fix [1]. Now we need to get X to
automatically load the fbdev driver instead of vesa [2].
Cheers
Dan
[0] https://bugs.launchpad.net/ubuntu-ps3-port/+bug/217647
[1] http://launchpadlibrarian.net/13569440/closedir.patch
[2] https://bugs.launchpad.net/ubuntu-ps3-port/+bug/219424
^ permalink raw reply
* RE: [PATCH 1/4 V3] MSI support on 83xx/85xx/86xx board
From: Jin Zhengxiong @ 2008-05-06 9:23 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1209986666.7163.14.camel@localhost>
Hi Micheal,
Thank you for your comments.
I'll send the new version according to feedback.
Jason
> -----Original Message-----
> From: Michael Ellerman [mailto:michael@ellerman.id.au]=20
> Sent: Monday, May 05, 2008 7:24 PM
> To: Jin Zhengxiong
> Cc: galak@kernel.crashing.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/4 V3] MSI support on 83xx/85xx/86xx board
>=20
> On Mon, 2008-05-05 at 15:47 +0800, Jason Jin wrote:
> > This MSI driver can be used on 83xx/85xx/86xx board.
> > In this driver, virtual interrupt host and chip were setup.=20
> There are=20
> > 256 MSI interrupts in this host, Every 32 MSI interrupts=20
> cascaded to=20
> > one IPIC/MPIC interrupt.
> > The chip was treated as edge sensitive and some necessary functions=20
> > were setup for this chip.
> >=20
> > Before using the MSI interrupt, PCI/PCIE device need to ask=20
> for a MSI=20
> > interrupt in the 256 MSI interrupts. A 256bit bitmap show which MSI=20
> > interrupt was used, reserve bit in the bitmap can be used=20
> to force the=20
> > device use some designate MSI interrupt in the 256 MSI interrupts.=20
> > Sometimes this is useful for testing the all the MSI=20
> interrupts. The=20
> > msi-available-ranges property in the dts file was used for this=20
> > purpose.
> >=20
> > Signed-off-by: Jason Jin <Jason.jin@freescale.com>
>=20
>=20
> Hi Jason,
>=20
> Just a couple of comments below:
>=20
> > diff --git a/arch/powerpc/sysdev/fsl_msi.c=20
> > b/arch/powerpc/sysdev/fsl_msi.c new file mode 100644 index=20
> > 0000000..c53f716
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/fsl_msi.c
> > @@ -0,0 +1,442 @@
> > +/*
> > + * Copyright (C) 2007-2008 Freescale Semiconductor, Inc.=20
> All rights reserved.
> > + *
> > + * Author: Tony Li <tony.li@freescale.com>
> > + * Jason Jin <Jason.jin@freescale.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; version 2 of the
> > + * License.
> > + *
> > + */
> > +#include <linux/irq.h>
> > +#include <linux/bootmem.h>
> > +#include <linux/bitmap.h>
> > +#include <linux/msi.h>
> > +#include <linux/pci.h>
> > +#include <linux/of_platform.h>
> > +#include <sysdev/fsl_soc.h>
> > +#include <asm/prom.h>
> > +#include <asm/hw_irq.h>
> > +#include <asm/ppc-pci.h>
> > +#include "fsl_msi.h"
> > +
> > +struct fsl_msi_feature {
> > + u32 fsl_pic_ip;
> > + u32 msiir_offset;
> > +};
> > +
> > +/* A bit ugly, can we get this from the pci_dev somehow? */
>=20
> This comment is old (from my code) and should go.
>=20
> > +static struct fsl_msi *fsl_msi;
> > +
> > +static inline u32 fsl_msi_read(u32 __iomem *base, unsigned=20
> int reg) {
> > + return in_be32(base + (reg >> 2));
> > +}
> > +
> > +static inline void fsl_msi_write(u32 __iomem *base,
> > + unsigned int reg, u32 value)
> > +{
> > + out_be32(base + (reg >> 2), value);
> > +}
> > +
> > +/*
> > + * We do not need this actually. The MSIR register has=20
> been read once
> > + * in the cascade interrupt. So, this MSI interrupt has=20
> been acked */=20
> > +static void fsl_msi_end_irq(unsigned int virq) { }
> > +
> > +static struct irq_chip fsl_msi_chip =3D {
> > + .mask =3D mask_msi_irq,
> > + .unmask =3D unmask_msi_irq,
> > + .ack =3D fsl_msi_end_irq,
> > + .typename =3D " FSL-MSI ",
> > +};
> > +
> > +static int fsl_msi_host_match(struct irq_host *h, struct=20
> device_node=20
> > +*node) {
> > + /* Exact match, unless node is NULL */
> > + return h->of_node =3D=3D NULL || h->of_node =3D=3D node; }
>=20
> Are you sure you want this as your match routine? It looks=20
> wrong to me.
> You won't ever create a fsl_msi in your probe routine unless=20
> you have a device node, so AFAICT the of_node =3D=3D NULL is only=20
> ever going to match some _other_ irqhost.
>=20
>=20
> > diff --git a/arch/powerpc/sysdev/fsl_msi.h=20
> > b/arch/powerpc/sysdev/fsl_msi.h new file mode 100644 index=20
> > 0000000..0449c96
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/fsl_msi.h
> > @@ -0,0 +1,31 @@
> > +#ifndef _POWERPC_SYSDEV_FSL_MSI_H
> > +#define _POWERPC_SYSDEV_FSL_MSI_H
>=20
>=20
> This should have a copyright header.
>=20
> > +#define NR_MSI_REG 8
> > +#define IRQS_PER_MSI_REG 32
> > +#define NR_MSI_IRQS (NR_MSI_REG * IRQS_PER_MSI_REG)
> > +
> > +#define FSL_PIC_IP_MASK 0x0000000F
> > +#define FSL_PIC_IP_MPIC 0x00000001
> > +#define FSL_PIC_IP_IPIC 0x00000002
> > +
> > +struct fsl_msi {
> > + /* Device node of the MSI interrupt*/
> > + struct device_node *of_node;
> > +
> > + struct irq_host *irqhost;
> > +
> > + unsigned long cascade_irq;
> > +
> > + u32 msi_addr_lo;
> > + u32 msi_addr_hi;
> > + void __iomem *msi_regs;
> > + u32 feature;
> > +
> > + unsigned long *fsl_msi_bitmap;
> > + spinlock_t bitmap_lock;
> > + const char *name;
>=20
> I don't see where this is used?
>=20
>=20
> cheers
>=20
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>=20
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>=20
> We do not inherit the earth from our ancestors, we borrow it=20
> from our children. - S.M.A.R.T Person
>=20
^ permalink raw reply
* RE: [PATCH 4/4] booting-without-of for Freescale MSI
From: Jin Zhengxiong @ 2008-05-06 9:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <79f7e810cc79d5912587296c4f44b419@kernel.crashing.org>
=20
>=20
> > + - compatible : should be "fsl,MPIC-MSI" for 85xx/86xx cpu,
> > + and "fsl,IPIC-MSI" for 83xx cpu.
>=20
> Please use a more specific name, "fsl,8599-msi" or similar?
>
Thanks for your input. I think the name "fsl,MPIC-MSI" and
"fsl,IPIC-MSI"
is somethind specific. Actually, from the hardware point, MSI is just
part
of MPIC of IPIC for Freescale CPU. the name "fsl,MPIC-MSI" can describe
the MSI is based on the MPIC controller.
=20
> > + - interrupts : should contain the msi interrupts cascade to the
> > host
> > + interrupt controller.
>=20
> You should describe that it is one "interrupts" entry per 32=20
> MSIs; also, it would be nice to say they need "0" as the sense.
>=20
> > + - interrupt-parent: should be "&mpic" for 85xx/86xx cpu and
> > "&ipic"
> > + for 83xx cpu.
>=20
> &Xpic are labels, so something local to specific DTS files;=20
> instead, say that the interrupts are routed to the MPIC/IPIC=20
> (it doesn't have to be via "interrupt-parent", either).
>=20
Thank you, I'll rewrite these description.=20
> Segher
>=20
> p.s. On a meta-note, please put the binding doc first in the=20
> series, it makes things easier to review in-order.
Ok, I'll put it first next time.
Jason
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Gerhard Pircher @ 2008-05-06 9:16 UTC (permalink / raw)
To: benh; +Cc: tiwai, linuxppc-dev, cjg
In-Reply-To: <1210063719.21644.162.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Tue, 06 May 2008 18:48:39 +1000
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, Takashi Iwai <tiwai@suse.de>, cjg@cruxppc.org, galak@kernel.crashing.org
> Betreff: Re: [PATCH] Sam440ep support
>
> On Tue, 2008-05-06 at 09:51 +0200, Gerhard Pircher wrote:
> > Takashi Iwai posted a preliminary patch a long time ago. I tested it
> > on my machine and it failed with non coherent scatter-gather DMA
> > allocations (I guess almost all ALSA PCI drivers use SG DMA?).
>
> How does Alsa allocate such SG ?
I can't answer this question. *ducked* :-) Takashi?
FYI: I posted the results of the test with Takashi's dma_mmap_coherent
patch here:
http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html
On the other side it looks like this problem does not only affect ALSA.
As far as I can tell also some V4L(2) drivers have a problem with mmaping
non coherent DMA allocations, but I'm not sure (it's a long time since I
did some tests with video cards on my AmigaOne).
Naturally I can do some tests, if you or Takashi come up with a new
patch.
Thanks!
Gerhard
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Benjamin Herrenschmidt @ 2008-05-06 8:48 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: Takashi Iwai, linuxppc-dev, cjg
In-Reply-To: <20080506075115.269150@gmx.net>
On Tue, 2008-05-06 at 09:51 +0200, Gerhard Pircher wrote:
> Takashi Iwai posted a preliminary patch a long time ago. I tested it
> on my
> machine and it failed with non coherent scatter-gather DMA allocations
> (I guess almost all ALSA PCI drivers use SG DMA?).
How does Alsa allocate such SG ?
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if there is i8259 PIC
From: Gerhard Pircher @ 2008-05-06 8:19 UTC (permalink / raw)
To: Anton Vorontsov, galak; +Cc: linuxppc-dev
In-Reply-To: <20080505185538.GA4906@polina.dev.rtsoft.ru>
-------- Original-Nachricht --------
> Datum: Mon, 5 May 2008 22:55:38 +0400
> Von: Anton Vorontsov <avorontsov@ru.mvista.com>
> An: Kumar Gala <galak@kernel.crashing.org>
> CC: linuxppc-dev@ozlabs.org
> Betreff: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if there is i8259 PIC
> Sometimes (particularly on MPC8610HPCD) we want IRQ-less CMOS RTC for
> the boards without (or disabled) i8259 PICs.
>
> We lookup the device tree for "chrp,iic" compatible devices, and if not
> found we do not assign RTC IRQ.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/rtc_cmos_setup.c | 21 +++++++++++++++------
> 1 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c
> b/arch/powerpc/sysdev/rtc_cmos_setup.c
> index c09ddc0..e5d0bcb 100644
> --- a/arch/powerpc/sysdev/rtc_cmos_setup.c
> +++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
> @@ -21,6 +21,7 @@ static int __init add_rtc(void)
> struct device_node *np;
> struct platform_device *pd;
> struct resource res[2];
> + unsigned int num_res = 1;
> int ret;
>
> memset(&res, 0, sizeof(res));
> @@ -41,14 +42,22 @@ static int __init add_rtc(void)
> if (res[0].start != RTC_PORT(0))
> return -EINVAL;
>
> - /* Use a fixed interrupt value of 8 since on PPC if we are using this
> - * its off an i8259 which we ensure has interrupt numbers 0..15. */
> - res[1].start = 8;
> - res[1].end = 8;
> - res[1].flags = IORESOURCE_IRQ;
> + np = of_find_compatible_node(NULL, NULL, "chrp,iic");
Could you add a check for "pnpPNP,000" (PNP ID for i8259), as not all
platforms use the CHRP names?
Gerhard
--
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
^ permalink raw reply
* Re: [patch 5/5] PS3: Update ps3_defconfig
From: Marvin @ 2008-05-06 8:14 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <481F595F.2090407@am.sony.com>
Hi Geoff,
On Monday 05 May 2008 21:00:47 you wrote:
> Marvin wrote:
> > what about adding these defaults:
> > - CONFIG_SCHED_SMT
> > - CONFIG_HUGETLBFS (needed by ibm cell sdk)
I'm using these for years now ;-)
> > not sure about:
> > - CONFIG_SPU_FS_64K_LS
I also have this option enabled. I think you can forget about it, as it seems
to improve performance only in some corner cases. I'm not an expert, so maybe
asking at cbe-oss-dev would be a better place.
Thanks
Marvin
p.s. I installed fc9 last week and Xorg crashes when PCI is not enabled. just
in case someone has the same problem.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if there is i8259 PIC
From: Gabriel Paubert @ 2008-05-06 8:06 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080505185538.GA4906@polina.dev.rtsoft.ru>
On Mon, May 05, 2008 at 10:55:38PM +0400, Anton Vorontsov wrote:
> Sometimes (particularly on MPC8610HPCD) we want IRQ-less CMOS RTC for
> the boards without (or disabled) i8259 PICs.
>
> We lookup the device tree for "chrp,iic" compatible devices, and if not
> found we do not assign RTC IRQ.
I suspect this will break on machines which have an RTC and the
interrupt line is not connected.
These are PreP machines like MVME2[467]xxx (I have a bunch of them,
stilll running 2.2 kernels but on a private network).
Interrupt 8 is connected, but not to the RTC...
I have no problems with the patch going in for now, it will have
to be revisited whenever (if ever) support for these machines is added
to the kernel (what is really needed to support these machines is a
residual data->device tree converter).
Gabriel
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/rtc_cmos_setup.c | 21 +++++++++++++++------
> 1 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c b/arch/powerpc/sysdev/rtc_cmos_setup.c
> index c09ddc0..e5d0bcb 100644
> --- a/arch/powerpc/sysdev/rtc_cmos_setup.c
> +++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
> @@ -21,6 +21,7 @@ static int __init add_rtc(void)
> struct device_node *np;
> struct platform_device *pd;
> struct resource res[2];
> + unsigned int num_res = 1;
> int ret;
>
> memset(&res, 0, sizeof(res));
> @@ -41,14 +42,22 @@ static int __init add_rtc(void)
> if (res[0].start != RTC_PORT(0))
> return -EINVAL;
>
> - /* Use a fixed interrupt value of 8 since on PPC if we are using this
> - * its off an i8259 which we ensure has interrupt numbers 0..15. */
> - res[1].start = 8;
> - res[1].end = 8;
> - res[1].flags = IORESOURCE_IRQ;
> + np = of_find_compatible_node(NULL, NULL, "chrp,iic");
> + if (np) {
> + of_node_put(np);
> + /*
> + * Use a fixed interrupt value of 8 since on PPC if we are
> + * using this its off an i8259 which we ensure has interrupt
> + * numbers 0..15.
> + */
> + res[1].start = 8;
> + res[1].end = 8;
> + res[1].flags = IORESOURCE_IRQ;
> + num_res++;
> + }
>
> pd = platform_device_register_simple("rtc_cmos", -1,
> - &res[0], 2);
> + &res[0], num_res);
>
> if (IS_ERR(pd))
> return PTR_ERR(pd);
> --
> 1.5.5.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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