* still nfs problems [Was: Linux 2.6.37-rc8]
From: Marc Kleine-Budde @ 2011-01-05 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294241369.3014.15.camel@heimdal.trondhjem.org>
On 01/05/2011 04:29 PM, Trond Myklebust wrote:
> On Wed, 2011-01-05 at 10:14 -0500, Trond Myklebust wrote:
>> OK. So,the new behaviour in 2.6.37 is that we're writing to a series of
>> pages via the usual kmap_atomic()/kunmap_atomic() and kmap()/kunmap()
>> interfaces, but we can end up reading them via a virtual address range
>> that gets set up via vm_map_ram() (that range gets set up before the
>> write occurs).
>>
>> Do we perhaps need an invalidate_kernel_vmap_range() before we can read
>> the data on ARM in this kind of scenario?
>
> IOW: Does something like the following patch fix the problem?
>
> -------------------------------------------------------------------------------
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> NFS: Ensure we clean the TLB cache in nfs_readdir_xdr_to_array
>
> After calling nfs_readdir_xdr_filler(), we need a call to
> invalidate_kernel_vmap_range() before we can proceed to read
> the data back through the virtual address range.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index 996dd89..4640470 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -587,6 +587,9 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
> if (status < 0)
> break;
> pglen = status;
> +
> + invalidate_kernel_vmap_range(pages_ptr, pglen);
> +
> status = nfs_readdir_page_filler(desc, &entry, pages_ptr, page, pglen);
> if (status < 0) {
> if (status == -ENOSPC)
\o/ - Works for me (at91, armv5)
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
This is a candidate for stable (Cc'd).
Regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110105/2804eb32/attachment.sig>
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294240457.3014.13.camel@heimdal.trondhjem.org>
On Wed, Jan 05, 2011 at 10:14:17AM -0500, Trond Myklebust wrote:
> OK. So,the new behaviour in 2.6.37 is that we're writing to a series of
> pages via the usual kmap_atomic()/kunmap_atomic() and kmap()/kunmap()
> interfaces, but we can end up reading them via a virtual address range
> that gets set up via vm_map_ram() (that range gets set up before the
> write occurs).
kmap of lowmem pages will always reuses the existing kernel direct
mapping, so there won't be a problem there.
> Do we perhaps need an invalidate_kernel_vmap_range() before we can read
> the data on ARM in this kind of scenario?
Firstly, vm_map_ram() does no cache maintainence of any sort, nor does
it take care of page colouring - so any architecture where cache aliasing
can occur will see this problem. It should not limited to ARM.
Secondly, no, invalidate_kernel_vmap_range() probably isn't sufficient.
There's two problems here:
addr = kmap(lowmem_page);
*addr = stuff;
kunmap(lowmem_page);
Such lowmem pages are accessed through their kernel direct mapping.
ptr = vm_map_ram(lowmem_page);
read = *ptr;
This creates a new mapping which can alias with the kernel direct mapping.
Now, as this is a new mapping, there should be no cache lines associated
with it. (Looking at vm_unmap_ram(), it calls free_unmap_vmap_area_addr(),
free_unmap_vmap_area(), which then calls flush_cache_vunmap() on the
region. vb_free() also calls flush_cache_vunmap() too.)
If the write after kmap() hits an already present cache line, the cache
line will be updated, but it won't be written back to memory. So, on
a subsequent vm_map_ram(), with any kind of aliasing cache, there's
no guarantee that you'll hit that cache line and read the data just
written there.
The kernel direct mapping would need to be flushed.
I'm really getting to the point of hating the poliferation of RAM
remapping interfaces - it's going to (and is) causing nothing but lots
of pain on virtual cache architectures, needing more and more cache
flushing interfaces to be created.
Is there any other solution to this?
^ permalink raw reply
* mmci: U300 "sync with blockend" broken for multi-block?
From: Linus Walleij @ 2011-01-05 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimYb6TxLj4SamxRwUgykf9JyW5y9gbejOUXqZ7K@mail.gmail.com>
2011/1/1 Rabin Vincent <rabin@rab.in>:
> In MMCI, there is some code to sync between the MCI_DATABLOCKEND and the
> MCI_DATAEND for U300 variants, which ensures that the transfer
> terminates only when both MCI_DATABLOCKEND and MCI_DATAEND occurs:
>
> ? ? ? ? * In the U300, the IRQs can arrive out-of-order,
> ? ? ? ? * e.g. MCI_DATABLOCKEND sometimes arrives after MCI_DATAEND,
> ? ? ? ? * so for this case we use the flags "blockend" and
> ? ? ? ? * "dataend" to make sure both IRQs have arrived before
> ? ? ? ? * concluding the transaction.
>
> It seems to me that this code won't work correctly for multi-block
> transfers, because there MCI_DATABLOCKEND will hit for the earlier
> blocks and the blockend flag will be set, and if on the last block the
> MCI_DATABLOCKEND hits after the MCI_DATAEND, this synching code won't do
> what it's trying to do and will instead just terminate the transfer
> after MCI_DATAEND.
Yes Ulf Hansson has spotted this problem...
Actually, there is this patch in the public ST-Ericsson git:
http://git.linaro.org/gitweb?p=bsp/st-ericsson/linux-2.6.35-ux500.git;a=commitdiff;h=2f0534d9527540a0a28e124f4e827f146f3bc128
The intention is to send out patches ASAP right now the
vacations have been holding things back a bit. (Else I
would have done it myself.)
Ulf would you like to submit this patch to the maillist?
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
for what's in the public git.
Yours,
Linus Walleij
^ permalink raw reply
* mmci: U300 "sync with blockend" broken for multi-block?
From: Linus Walleij @ 2011-01-05 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110101121048.GB25924@n2100.arm.linux.org.uk>
2011/1/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> It would be good to characterize what's actually going on with U300 some
> more, especially the timing between these signals and the FIFO interrupts,
> rather than just stating that they occur "out of order".
I will try to document more closely. OTOMH it was like
for reads they would come in one order first one then
another and for writes the other way around. That was
why the older quirk for U300 was working, wiring the
DATAEND high, though it was no good in modeling
what was actually happening.
> Is the data block end interrupt being triggered when you've read the
> required data from the FIFO, and the data end interrupt triggered when
> the card has transferred the required amount of data (iow, data into
> the FIFO)?
>
> Once they have been properly characterized, then it may be possible to
> come up with an alternative solution. ?At the moment, it's very had to
> guess what's going on from the descriptions given.
Ulf, do you know the details of what is happening here?
I think you have the most up-to-date knowledge.
I've been trying to determine this a number of times,
empirically mostly, probably failing to understand the
most important variables. The current solution is as
far as I've been able to model what's actually happening.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Jamie Iles @ 2011-01-05 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294236457-17476-9-git-send-email-shawn.guo@freescale.com>
Hi Shawn,
On Wed, Jan 05, 2011 at 10:07:35PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v2:
> - Add mutex locking for mxs_read_ocotp()
> - Use type size_t for count and i
> - Add comment for clk_enable/disable skipping
> - Add ERROR bit clearing and polling step
>
> arch/arm/mach-mxs/Makefile | 2 +-
> arch/arm/mach-mxs/include/mach/common.h | 1 +
> arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> 3 files changed, 81 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-mxs/ocotp.c
>
[...]
> diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
> new file mode 100644
> index 0000000..902ef59
> --- /dev/null
> +++ b/arch/arm/mach-mxs/ocotp.c
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * 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.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/mutex.h>
> +
> +#include <mach/mxs.h>
> +
> +#define BM_OCOTP_CTRL_BUSY (1 << 8)
> +#define BM_OCOTP_CTRL_ERROR (1 << 9)
> +#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
> +
> +static DEFINE_MUTEX(ocotp_mutex);
> +
> +int mxs_read_ocotp(unsigned offset, size_t count, u32 *values)
> +{
> + void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
> + int timeout = 0x400;
> + size_t i;
> +
> + mutex_lock(&ocotp_mutex);
> +
> + /*
> + * clk_enable(hbus_clk) for ocotp can be skipped
> + * as it must be on when system is running.
> + */
> +
> + /* try to clear ERROR bit */
> + __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
> +
> + /* check both BUSY and ERROR cleared */
> + while ((__raw_readl(ocotp_base) &
> + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> + /* nothing */;
Is it worth using cpu_relax() in these polling loops?
Jamie
^ permalink raw reply
* [PATCH v3 05/10] net/fec: add dual fec support for mx28
From: Uwe Kleine-König @ 2011-01-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294236457-17476-6-git-send-email-shawn.guo@freescale.com>
Hello,
On Wed, Jan 05, 2011 at 10:07:32PM +0800, Shawn Guo wrote:
> This patch is to add mx28 dual fec support. Here are some key notes
> for mx28 fec controller.
>
> - The mx28 fec controller naming ENET-MAC is a different IP from FEC
> used on other i.mx variants. But they are basically compatible
> on software interface, so it's possible to share the same driver.
> - ENET-MAC design made an improper assumption that it runs on a
> big-endian system. As the result, driver has to swap every frame
> going to and coming from the controller.
> - The external phys can only be configured by fec0, which means fec1
> can not work independently and both phys need to be configured by
> mii_bus attached on fec0.
> - ENET-MAC reset will get mac address registers reset too.
> - ENET-MAC MII/RMII mode and 10M/100M speed are configured
> differently FEC.
> - ETHER_EN bit must be set to get ENET-MAC interrupt work.
>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v3:
> - Move v2 changes into patch #3
> - Use device name to check if it's running on ENET-MAC
>
> drivers/net/Kconfig | 7 ++-
> drivers/net/fec.c | 140 +++++++++++++++++++++++++++++++++++++++++++++------
> drivers/net/fec.h | 5 +-
> 3 files changed, 131 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4f1755b..f34629b 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1944,18 +1944,19 @@ config 68360_ENET
> config FEC
> bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
> depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
> - MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5
> + MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5 || SOC_IMX28
> select PHYLIB
> help
> Say Y here if you want to use the built-in 10/100 Fast ethernet
> controller on some Motorola ColdFire and Freescale i.MX processors.
>
> config FEC2
> - bool "Second FEC ethernet controller (on some ColdFire CPUs)"
> + bool "Second FEC ethernet controller"
> depends on FEC
> help
> Say Y here if you want to use the second built-in 10/100 Fast
> - ethernet controller on some Motorola ColdFire processors.
> + ethernet controller on some Motorola ColdFire and Freescale
> + i.MX processors.
>
> config FEC_MPC52xx
> tristate "MPC52xx FEC driver"
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 8a1c51f..67ba263 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -17,6 +17,8 @@
> *
> * Bug fixes and cleanup by Philippe De Muyter (phdm at macqel.be)
> * Copyright (c) 2004-2006 Macq Electronique SA.
> + *
> + * Copyright (C) 2010 Freescale Semiconductor, Inc.
> */
>
> #include <linux/module.h>
> @@ -45,20 +47,33 @@
>
> #include <asm/cacheflush.h>
>
> -#ifndef CONFIG_ARCH_MXC
> +#if !defined(CONFIG_ARCH_MXC) && !defined(CONFIG_SOC_IMX28)
maybe !defined(CONFIG_ARM)?
> #include <asm/coldfire.h>
> #include <asm/mcfsim.h>
> #endif
>
> #include "fec.h"
>
> -#ifdef CONFIG_ARCH_MXC
> -#include <mach/hardware.h>
> +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
> #define FEC_ALIGNMENT 0xf
> #else
> #define FEC_ALIGNMENT 0x3
> #endif
>
> +#define DRIVER_NAME "fec"
> +#define ENET_MAC_NAME "enet-mac"
> +
> +static struct platform_device_id fec_devtype[] = {
> + {
> + .name = DRIVER_NAME,
> + }, {
> + .name = ENET_MAC_NAME,
> + }
I'd done it differently:
{
.name = "fec",
.driver_data = 0,
}, {
.name = "imx28-fec",
.driver_data = HAS_ENET_MAC | ...,
}
and then test the bits in driver_data (which you get using
platform_get_device_id() when you need to distinguish.
Comparing names doesn't scale, assume there are three further features
to distinguish, then you need to use strtok or index and get device
names like enet-mac-with-feature1-but-without-feature2-and-feature3.
> +};
> +
> +static unsigned fec_is_enetmac;
> +static struct mii_bus *fec_mii_bus;
In practice this might work, but actually these are per-device
properties, not driver-global. So it should go into the private data
struct.
> +
> static unsigned char macaddr[ETH_ALEN];
> module_param_array(macaddr, byte, NULL, 0);
> MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
> @@ -129,7 +144,8 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
> * account when setting it.
> */
> #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
> - defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARCH_MXC)
> + defined(CONFIG_M520x) || defined(CONFIG_M532x) || \
> + defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
> #define OPT_FRAME_SIZE (PKT_MAXBUF_SIZE << 16)
> #else
> #define OPT_FRAME_SIZE 0
> @@ -208,6 +224,17 @@ static void fec_stop(struct net_device *dev);
> /* Transmitter timeout */
> #define TX_TIMEOUT (2 * HZ)
>
> +static void *swap_buffer(void *bufaddr, int len)
> +{
> + int i;
> + unsigned int *buf = bufaddr;
> +
> + for (i = 0; i < (len + 3) / 4; i++, buf++)
> + *buf = __swab32(*buf);
Would it better to use cpu_to_be32 here? Then the compiler might
be smart enough to optimize it away on BE. (Currently the code
generated for a BE build would be wrong with your patch, wouldn't it?)
> +
> + return bufaddr;
> +}
> +
> static netdev_tx_t
> fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> @@ -256,6 +283,14 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> bufaddr = fep->tx_bounce[index];
> }
>
> + /*
> + * enet-mac design made an improper assumption that it's running
> + * on a big endian system. As the result, driver has to swap
if he was really aware that he limits the performant use of the fec to
big endian systems, can you please make him stop designing hardware!?
> + * every frame going to and coming from the controller.
> + */
> + if (fec_is_enetmac)
> + swap_buffer(bufaddr, skb->len);
> +
> /* Save skb pointer */
> fep->tx_skbuff[fep->skb_cur] = skb;
>
> @@ -487,6 +522,9 @@ fec_enet_rx(struct net_device *dev)
> dma_unmap_single(NULL, bdp->cbd_bufaddr, bdp->cbd_datlen,
> DMA_FROM_DEVICE);
>
> + if (fec_is_enetmac)
> + swap_buffer(data, pkt_len);
> +
> /* This does 16 byte alignment, exactly what we need.
> * The packet length includes FCS, but we don't want to
> * include that when passing upstream as it messes up
> @@ -689,6 +727,7 @@ static int fec_enet_mii_probe(struct net_device *dev)
> char mdio_bus_id[MII_BUS_ID_SIZE];
> char phy_name[MII_BUS_ID_SIZE + 3];
> int phy_id;
> + int dev_id = fep->pdev->id;
>
> fep->phy_dev = NULL;
>
> @@ -700,6 +739,8 @@ static int fec_enet_mii_probe(struct net_device *dev)
> continue;
> if (fep->mii_bus->phy_map[phy_id]->phy_id == 0)
> continue;
> + if (fec_is_enetmac && dev_id--)
> + continue;
> strncpy(mdio_bus_id, fep->mii_bus->id, MII_BUS_ID_SIZE);
> break;
> }
> @@ -741,6 +782,28 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> struct fec_enet_private *fep = netdev_priv(dev);
> int err = -ENXIO, i;
>
> + /*
> + * The dual fec interfaces are not equivalent with enet-mac.
> + * Here are the differences:
> + *
> + * - fec0 supports MII & RMII modes while fec1 only supports RMII
> + * - fec0 acts as the 1588 time master while fec1 is slave
> + * - external phys can only be configured by fec0
> + *
> + * That is to say fec1 can not work independently. It only works
> + * when fec0 is working. The reason behind this design is that the
> + * second interface is added primarily for Switch mode.
> + *
> + * Because of the last point above, both phys are attached on fec0
> + * mdio interface in board design, and need to be configured by
> + * fec0 mii_bus.
> + */
> + if (fec_is_enetmac && pdev->id) {
> + /* fec1 uses fec0 mii_bus */
> + fep->mii_bus = fec_mii_bus;
> + return 0;
> + }
> +
> fep->mii_timeout = 0;
>
> /*
> @@ -777,6 +840,10 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> if (mdiobus_register(fep->mii_bus))
> goto err_out_free_mdio_irq;
>
> + /* save fec0 mii_bus */
> + if (fec_is_enetmac)
> + fec_mii_bus = fep->mii_bus;
> +
> return 0;
>
> err_out_free_mdio_irq:
> @@ -1149,11 +1216,22 @@ fec_restart(struct net_device *dev, int duplex)
> {
> struct fec_enet_private *fep = netdev_priv(dev);
> int i;
> + u32 val, temp_mac[2];
>
> /* Whack a reset. We should wait for this. */
> writel(1, fep->hwp + FEC_ECNTRL);
> udelay(10);
>
> + /*
> + * enet-mac reset will reset mac address registers too,
> + * so need to reconfigure it.
> + */
> + if (fec_is_enetmac) {
> + memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
> + writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
> + writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
where is the value saved to temp_mac[]? For me it looks you write
uninitialized data into the mac registers.
> + }
> +
> /* Clear any outstanding interrupt. */
> writel(0xffc00000, fep->hwp + FEC_IEVENT);
>
> @@ -1200,20 +1278,45 @@ fec_restart(struct net_device *dev, int duplex)
> /* Set MII speed */
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> -#ifdef FEC_MIIGSK_ENR
> - if (fep->phy_interface == PHY_INTERFACE_MODE_RMII) {
> - /* disable the gasket and wait */
> - writel(0, fep->hwp + FEC_MIIGSK_ENR);
> - while (readl(fep->hwp + FEC_MIIGSK_ENR) & 4)
> - udelay(1);
> + /*
> + * The phy interface and speed need to get configured
> + * differently on enet-mac.
> + */
> + if (fec_is_enetmac) {
> + val = readl(fep->hwp + FEC_R_CNTRL);
>
> - /* configure the gasket: RMII, 50 MHz, no loopback, no echo */
> - writel(1, fep->hwp + FEC_MIIGSK_CFGR);
> + /* MII or RMII */
> + if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
> + val |= (1 << 8);
> + else
> + val &= ~(1 << 8);
>
> - /* re-enable the gasket */
> - writel(2, fep->hwp + FEC_MIIGSK_ENR);
> - }
> + /* 10M or 100M */
> + if (fep->phy_dev && fep->phy_dev->speed == SPEED_100)
> + val &= ~(1 << 9);
> + else
> + val |= (1 << 9);
> +
> + writel(val, fep->hwp + FEC_R_CNTRL);
> + } else {
> +#ifdef FEC_MIIGSK_ENR
> + if (fep->phy_interface == PHY_INTERFACE_MODE_RMII) {
> + /* disable the gasket and wait */
> + writel(0, fep->hwp + FEC_MIIGSK_ENR);
> + while (readl(fep->hwp + FEC_MIIGSK_ENR) & 4)
> + udelay(1);
> +
> + /*
> + * configure the gasket:
> + * RMII, 50 MHz, no loopback, no echo
> + */
> + writel(1, fep->hwp + FEC_MIIGSK_CFGR);
> +
> + /* re-enable the gasket */
> + writel(2, fep->hwp + FEC_MIIGSK_ENR);
> + }
> #endif
> + }
>
> /* And last, enable the transmit and receive processing */
> writel(2, fep->hwp + FEC_ECNTRL);
> @@ -1301,6 +1404,10 @@ fec_probe(struct platform_device *pdev)
> }
> }
>
> + /* check if it's ENET-MAC controller via device name */
> + if (!strcmp(pdev->name, ENET_MAC_NAME))
> + fec_is_enetmac = 1;
> +
> fep->clk = clk_get(&pdev->dev, "fec_clk");
> if (IS_ERR(fep->clk)) {
> ret = PTR_ERR(fep->clk);
> @@ -1410,12 +1517,13 @@ static const struct dev_pm_ops fec_pm_ops = {
>
> static struct platform_driver fec_driver = {
> .driver = {
> - .name = "fec",
> + .name = DRIVER_NAME,
> .owner = THIS_MODULE,
> #ifdef CONFIG_PM
> .pm = &fec_pm_ops,
> #endif
> },
> + .id_table = fec_devtype,
> .probe = fec_probe,
> .remove = __devexit_p(fec_drv_remove),
> };
> diff --git a/drivers/net/fec.h b/drivers/net/fec.h
> index 2c48b25..ace318d 100644
> --- a/drivers/net/fec.h
> +++ b/drivers/net/fec.h
> @@ -14,7 +14,8 @@
> /****************************************************************************/
>
> #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
> - defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARCH_MXC)
> + defined(CONFIG_M520x) || defined(CONFIG_M532x) || \
> + defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
> /*
> * Just figures, Motorola would have to change the offsets for
> * registers in the same peripheral device on different models
> @@ -78,7 +79,7 @@
> /*
> * Define the buffer descriptor structure.
> */
> -#ifdef CONFIG_ARCH_MXC
> +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
> struct bufdesc {
> unsigned short cbd_datlen; /* Data length */
> unsigned short cbd_sc; /* Control and status info */
> --
> 1.7.1
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] arm: mach-omap2: mux: fix buffer overrun
From: Aaro Koskinen @ 2011-01-05 16:42 UTC (permalink / raw)
To: linux-arm-kernel
memcpy() copies 8 bytes too much (omap_mux_entry vs. omap_mux). Correct
by replacing memcpy() with struct assignment, which is safer.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
---
arch/arm/mach-omap2/mux.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 17bd639..df8d2f2 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -893,7 +893,7 @@ static struct omap_mux * __init omap_mux_list_add(
return NULL;
m = &entry->mux;
- memcpy(m, src, sizeof(struct omap_mux_entry));
+ entry->mux = *src;
#ifdef CONFIG_OMAP_MUX
if (omap_mux_copy_names(src, m)) {
--
1.5.6.5
^ permalink raw reply related
* mmci: U300 "sync with blockend" broken for multi-block?
From: Russell King - ARM Linux @ 2011-01-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=4SrxX-oCx-XXd+oib64j8RhMLdsQD1oWGxgU1@mail.gmail.com>
On Wed, Jan 05, 2011 at 05:15:04PM +0100, Linus Walleij wrote:
> 2011/1/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> > It would be good to characterize what's actually going on with U300 some
> > more, especially the timing between these signals and the FIFO interrupts,
> > rather than just stating that they occur "out of order".
>
> I will try to document more closely. OTOMH it was like
> for reads they would come in one order first one then
> another and for writes the other way around. That was
> why the older quirk for U300 was working, wiring the
> DATAEND high, though it was no good in modeling
> what was actually happening.
Any chance of pr_debug'ing the complete status register each time you
service an interrupt? You'll probably need to set the kernel log
buffer fairly large to ensure that you capture everything.
I wouldn't recommend dumping the messages through the serial port
directly as that'd put far too much latency on the servicing of them,
but using dmesg after the accesses to retrieve them. (IOW, don't
pass 'debug' to the kernel...)
^ permalink raw reply
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Uwe Kleine-König @ 2011-01-05 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105161235.GA2112@gallagher>
Hello Jamie,
On Wed, Jan 05, 2011 at 04:16:46PM +0000, Jamie Iles wrote:
> On Wed, Jan 05, 2011 at 10:07:35PM +0800, Shawn Guo wrote:
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > Changes for v2:
> > - Add mutex locking for mxs_read_ocotp()
> > - Use type size_t for count and i
> > - Add comment for clk_enable/disable skipping
> > - Add ERROR bit clearing and polling step
> >
> > arch/arm/mach-mxs/Makefile | 2 +-
> > arch/arm/mach-mxs/include/mach/common.h | 1 +
> > arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> > 3 files changed, 81 insertions(+), 1 deletions(-)
> > create mode 100644 arch/arm/mach-mxs/ocotp.c
> >
> [...]
> > diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
> > new file mode 100644
> > index 0000000..902ef59
> > --- /dev/null
> > +++ b/arch/arm/mach-mxs/ocotp.c
> > @@ -0,0 +1,79 @@
> > +/*
> > + * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/err.h>
> > +#include <linux/mutex.h>
> > +
> > +#include <mach/mxs.h>
> > +
> > +#define BM_OCOTP_CTRL_BUSY (1 << 8)
> > +#define BM_OCOTP_CTRL_ERROR (1 << 9)
> > +#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
> > +
> > +static DEFINE_MUTEX(ocotp_mutex);
> > +
> > +int mxs_read_ocotp(unsigned offset, size_t count, u32 *values)
> > +{
> > + void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
> > + int timeout = 0x400;
> > + size_t i;
> > +
> > + mutex_lock(&ocotp_mutex);
> > +
> > + /*
> > + * clk_enable(hbus_clk) for ocotp can be skipped
> > + * as it must be on when system is running.
> > + */
> > +
> > + /* try to clear ERROR bit */
> > + __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
> > +
> > + /* check both BUSY and ERROR cleared */
> > + while ((__raw_readl(ocotp_base) &
> > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > + /* nothing */;
>
> Is it worth using cpu_relax() in these polling loops?
I don't know what cpu_relax does for other platforms, but on ARM it's
just a memory barrier which AFAICT doesn't help here at all (which
doesn't need to be correct). Why do you think it would be better?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Hit BUG_ON in dma-mapping.c:425
From: Nicolas Ferre @ 2011-01-05 16:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
While running mtd_stresstest on a dataflash (atmel_spi
+ mtd_dataflash drivers) I hit the BUG_ON directive that
is at the beginning of ___dma_single_cpu_to_dev() function.
This function is called from the SPI driver that do a
dma_map_single() before DMA operations on the buffer
transmitted from upper layers.
It seems that this address is above "high_memory" limit because
it is allocated by vmalloc (in mtd_stresstest.c:285)...
The question is: where the bug is relying? Is there a
configuration that I must modify in AT91 Linux to be able
to modify this behavior or is this an error in the use of
dma_map_single() in the atmel_spi.c driver?
After searching the web, it seems it is quite common after
2.6.34 kernels... But I cannot figure out what is the issue.
Here is the Oops output:
root at at91sam9m10g45ek:~# insmod ../n/mtd_stresstest.ko dev=3
=================================================
mtd_stresstest: MTD device: 3
mtd_stresstest: MTD device size 4325376, eraseblock size 528, page size 528, count of eraseblocks 8192, pages per eraseblock 1, OOB size 0
mtd_stresstest: doing operations
mtd_stresstest: 0 operations done
kernel BUG at /home/nferre/workspace/linux/linux-2.6-arm/arch/arm/mm/dma-mapping.c:425!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c31bc000
[00000000] *pgd=732b1031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
last sysfs file: /sys/devices/platform/atmel-ehci/usb1/1-2/1-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/size
Modules linked in: mtd_stresstest(+)
CPU: 0 Not tainted (2.6.37+ #2)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<c0030374>] lr : [<c0030370>] psr: 20000093
sp : c3b09df8 ip : 00000200 fp : 00601c00
r10: c4886000 r9 : 00001807 r8 : 74886000
r7 : c38d37a0 r6 : c39660e8 r5 : c3b09ebc r4 : c3b09e98
r3 : 00000000 r2 : c3b09dec r1 : c02ef2c1 r0 : 0000005e
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 731bc000 DAC: 00000015
Process insmod (pid: 1649, stack limit = 0xc3b08270)
Stack: (0xc3b09df8 to 0xc3b0a000)
9de0: ffffffff c0032b1c
9e00: c3b09e98 c01817c4 c3966000 c3b09e3c 00000000 c38d37a0 c3966000 c018070c
9e20: 60000013 c3b09e3c 00000000 c018076c c3b09ebc c0180914 c38d37a0 00000000
9e40: c3b09e40 c3b09e40 c3979e00 00000420 c3b09f2c 00000210 00601c00 c0179ba8
9e60: 00100100 00318e70 c38d37a0 c3979e24 00000000 c3979e00 00000000 00000004
9e80: 73979e00 ffffffff 00000000 00000000 c3b09eb4 c3b09ebc c4886000 00000000
9ea0: 00000210 ffffffff ffffffff 00000000 00000000 c3b09ebc c3b09e90 c3b09e90
9ec0: c3b09eb4 c38d37a0 00000000 c0180ab8 c3b09e3c 00000000 ffffff8d 00000000
9ee0: 00000000 00000000 00000000 00000000 00000000 00001807 00000000 0000601c
9f00: 00318e70 00000420 00001808 bf0034b0 00000420 c3b09f2c c4886000 00000001
9f20: 00000000 00000000 00000000 00000000 0000002e bf0005fc bf003000 00012008
9f40: 00000000 c002cfa8 c3b08000 00000000 00012008 c002740c c035ecf4 00000001
9f60: bf0005fc 00000000 00012008 bf0005fc 00000000 00012008 00011d23 c002cfa8
9f80: 00000000 c0062dec 00012018 00011d23 00012008 00000000 00012008 00020000
9fa0: 00000080 c002ce00 00000000 00012008 00012018 00011d23 00012008 00000001
9fc0: 00000000 00012008 00020000 00000080 bec09efb bec09ef4 00012018 00012008
9fe0: 00000003 bec09c94 00008d77 401c0054 60000010 00012018 657a6973 69657700
[<c0030374>] (__bug+0x1c/0x28) from [<c0032b1c>] (___dma_single_cpu_to_dev+0x34/0x5c)
[<c0032b1c>] (___dma_single_cpu_to_dev+0x34/0x5c) from [<c01817c4>] (atmel_spi_transfer+0xc8/0x1c4)
[<c01817c4>] (atmel_spi_transfer+0xc8/0x1c4) from [<c018070c>] (__spi_async+0x94/0xa0)
[<c018070c>] (__spi_async+0x94/0xa0) from [<c018076c>] (spi_async_locked+0x14/0x2c)
[<c018076c>] (spi_async_locked+0x14/0x2c) from [<c0180914>] (__spi_sync+0x5c/0x9c)
[<c0180914>] (__spi_sync+0x5c/0x9c) from [<c0179ba8>] (dataflash_write+0x180/0x1fc)
[<c0179ba8>] (dataflash_write+0x180/0x1fc) from [<bf0034b0>] (mtd_stresstest_init+0x4b0/0x604 [mtd_stresstest])
[<bf0034b0>] (mtd_stresstest_init+0x4b0/0x604 [mtd_stresstest]) from [<c002740c>] (do_one_initcall+0xcc/0x1a8)
[<c002740c>] (do_one_initcall+0xcc/0x1a8) from [<c0062dec>] (sys_init_module+0x90/0x1a4)
[<c0062dec>] (sys_init_module+0x90/0x1a4) from [<c002ce00>] (ret_fast_syscall+0x0/0x2c)
Code: e59f0010 e1a01003 eb0916de e3a03000 (e5833000)
---[ end trace 0f2f3786a6a31f57 ]---
Segmentation fault
This append on 2.6.37 kernel.
Thanks for your help. Best regards,
--
Nicolas Ferre
^ permalink raw reply
* I2C support for CE4100, v3
From: Sebastian Andrzej Siewior @ 2011-01-05 16:50 UTC (permalink / raw)
To: linux-arm-kernel
The I2C core inside CE4100 is very much the same as in PXA25x.
I Cc the ARM folks because patch 2 reorganizes some files so that they
can be accessed from x86.
The I2C device is behind a PCI bus. The PCI probe code simply creates
three platform devices so we don't have much changes to the platform
driver. There is no clock framework on x86 and the peripherals don't
support changing their clocks or to enable/disable them. So I provided
dummy function which keep the driver happy.
This series indirectly depends on the SPI series because both modify
include files and spi & i2c includes are sometimes too close to each
other.
History:
v1: Initial post
v2: - ISAR is still touched if not in SLAVE mode except on X86 where it
is not touched at all.
- There are no files created in include/asm
- register defines are in common code
- the PCI controller now requires a device tree. It is used to obtain
an id (which is used as device & i2c bus id).
- the PCI part now uses ARRAY_SIZE(). As it turns out pci_select_bars()
is not useable.
- the patch which resetted the chip if the i2c bus was not available
has been dropped.
v3: - introduced dynamic register mapping. With this change I can avoid
accessing the unavailable ISAR register without an #ifdef around
it.
- modified the DT part of the pci driver to address latest DT review
comments.
The patch series has been created with the -M option so file moves can
be easily noticed. The whole series (including the spi rename) is also
available at
git://git.linutronix.de/users/bigeasy/soda.git spi-i2c
Sebastian Andrzej Siewior (6):
i2c/pxa: use dynamic register layout
arm/pxa2xx: reorganize I2C files
i2c/pxa2xx: Add PCI support for PXA I2C controller
i2c/pxa2xx: add support for shared IRQ handler
i2c/pxa2xx: check timeout correctly
i2c/pxa2xx: pass of_node from platform driver to adapter and publish
arch/arm/mach-mmp/include/mach/mmp2.h | 2 +-
arch/arm/mach-mmp/include/mach/pxa168.h | 2 +-
arch/arm/mach-mmp/include/mach/pxa910.h | 2 +-
arch/arm/mach-pxa/balloon3.c | 3 +-
arch/arm/mach-pxa/cm-x300.c | 2 +-
arch/arm/mach-pxa/colibri-pxa270-income.c | 3 +-
arch/arm/mach-pxa/corgi.c | 2 +-
arch/arm/mach-pxa/csb726.c | 2 +-
arch/arm/mach-pxa/devices.c | 2 +-
arch/arm/mach-pxa/em-x270.c | 2 +-
arch/arm/mach-pxa/ezx.c | 2 +-
arch/arm/mach-pxa/hx4700.c | 2 +-
arch/arm/mach-pxa/littleton.c | 2 +-
arch/arm/mach-pxa/magician.c | 2 +-
arch/arm/mach-pxa/mainstone.c | 2 +-
arch/arm/mach-pxa/mioa701.c | 2 +-
arch/arm/mach-pxa/mxm8x10.c | 2 +-
arch/arm/mach-pxa/palm27x.c | 3 +-
arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
arch/arm/mach-pxa/poodle.c | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
arch/arm/mach-pxa/pxa3xx.c | 2 +-
arch/arm/mach-pxa/raumfeld.c | 2 +-
arch/arm/mach-pxa/saar.c | 2 +-
arch/arm/mach-pxa/spitz.c | 3 +-
arch/arm/mach-pxa/stargate2.c | 2 +-
arch/arm/mach-pxa/tavorevb3.c | 3 +-
arch/arm/mach-pxa/tosa.c | 2 +-
arch/arm/mach-pxa/trizeps4.c | 2 +-
arch/arm/mach-pxa/viper.c | 2 +-
arch/arm/mach-pxa/vpac270.c | 3 +-
arch/arm/mach-pxa/xcep.c | 3 +-
arch/arm/mach-pxa/z2.c | 3 +-
arch/arm/mach-pxa/zeus.c | 3 +-
arch/arm/mach-pxa/zylonite_pxa300.c | 2 +-
drivers/i2c/busses/Kconfig | 7 +-
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-pxa-pci.c | 173 ++++++++++++++++++++
drivers/i2c/busses/i2c-pxa.c | 116 ++++++++++---
.../plat/i2c.h => include/linux/i2c/pxa-i2c.h | 0
40 files changed, 304 insertions(+), 72 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-pxa-pci.c
rename arch/arm/plat-pxa/include/plat/i2c.h => include/linux/i2c/pxa-i2c.h (100%)
Sebastian
^ permalink raw reply
* [PATCH 1/6] i2c/pxa: use dynamic register layout
From: Sebastian Andrzej Siewior @ 2011-01-05 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
This will prepare the driver to handle register layouts where certain
registers are not available at all.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/i2c/busses/i2c-pxa.c | 70 ++++++++++++++++++++++++++++++------------
1 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index f4c19a9..a011455 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -38,29 +38,49 @@
#include <asm/irq.h>
#include <plat/i2c.h>
+struct pxa_reg_layout {
+ u32 ibmr;
+ u32 idbr;
+ u32 icr;
+ u32 isr;
+ u32 isar;
+};
+
+enum pxa_i2c_types {
+ REGS_PXA2XX,
+ REGS_PXA3XX,
+};
+
/*
- * I2C register offsets will be shifted 0 or 1 bit left, depending on
- * different SoCs
+ * I2C registers definitions
*/
-#define REG_SHIFT_0 (0 << 0)
-#define REG_SHIFT_1 (1 << 0)
-#define REG_SHIFT(d) ((d) & 0x1)
+static struct pxa_reg_layout pxa_reg_layout[] = {
+ [REGS_PXA2XX] = {
+ .ibmr = 0x00,
+ .idbr = 0x10,
+ .icr = 0x20,
+ .isr = 0x30,
+ .isar = 0x40,
+ },
+ [REGS_PXA3XX] = {
+ .ibmr = 0x00,
+ .idbr = 0x08,
+ .icr = 0x10,
+ .isr = 0x18,
+ .isar = 0x20,
+ },
+};
static const struct platform_device_id i2c_pxa_id_table[] = {
- { "pxa2xx-i2c", REG_SHIFT_1 },
- { "pxa3xx-pwri2c", REG_SHIFT_0 },
+ { "pxa2xx-i2c", REGS_PXA2XX },
+ { "pxa3xx-pwri2c", REGS_PXA3XX },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
/*
- * I2C registers and bit definitions
+ * I2C bit definitions
*/
-#define IBMR (0x00)
-#define IDBR (0x08)
-#define ICR (0x10)
-#define ISR (0x18)
-#define ISAR (0x20)
#define ICR_START (1 << 0) /* start bit */
#define ICR_STOP (1 << 1) /* stop bit */
@@ -111,7 +131,11 @@ struct pxa_i2c {
u32 icrlog[32];
void __iomem *reg_base;
- unsigned int reg_shift;
+ void __iomem *reg_ibmr;
+ void __iomem *reg_idbr;
+ void __iomem *reg_icr;
+ void __iomem *reg_isr;
+ void __iomem *reg_isar;
unsigned long iobase;
unsigned long iosize;
@@ -121,11 +145,11 @@ struct pxa_i2c {
unsigned int fast_mode :1;
};
-#define _IBMR(i2c) ((i2c)->reg_base + (0x0 << (i2c)->reg_shift))
-#define _IDBR(i2c) ((i2c)->reg_base + (0x4 << (i2c)->reg_shift))
-#define _ICR(i2c) ((i2c)->reg_base + (0x8 << (i2c)->reg_shift))
-#define _ISR(i2c) ((i2c)->reg_base + (0xc << (i2c)->reg_shift))
-#define _ISAR(i2c) ((i2c)->reg_base + (0x10 << (i2c)->reg_shift))
+#define _IBMR(i2c) ((i2c)->reg_ibmr)
+#define _IDBR(i2c) ((i2c)->reg_idbr)
+#define _ICR(i2c) ((i2c)->reg_icr)
+#define _ISR(i2c) ((i2c)->reg_isr)
+#define _ISAR(i2c) ((i2c)->reg_isar)
/*
* I2C Slave mode address
@@ -1001,6 +1025,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
struct resource *res;
struct i2c_pxa_platform_data *plat = dev->dev.platform_data;
const struct platform_device_id *id = platform_get_device_id(dev);
+ enum pxa_i2c_types i2c_type = id->driver_data;
int ret;
int irq;
@@ -1044,7 +1069,12 @@ static int i2c_pxa_probe(struct platform_device *dev)
ret = -EIO;
goto eremap;
}
- i2c->reg_shift = REG_SHIFT(id->driver_data);
+
+ i2c->reg_ibmr = i2c->reg_base + pxa_reg_layout[i2c_type].ibmr;
+ i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
+ i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
+ i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
+ i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
i2c->iobase = res->start;
i2c->iosize = resource_size(res);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/6] arm/pxa2xx: reorganize I2C files
From: Sebastian Andrzej Siewior @ 2011-01-05 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
This patch moves the platform data definition from
arch/arm/plat-pxa/include/plat/i2c.h to include/linux/i2c/pxa-i2c.h so
it can be accessed from x86 the same way as on ARM.
This change should make no functional change to the PXA code. The move
is verified by building the following defconfigs:
cm_x2xx_defconfig corgi_defconfig em_x270_defconfig ezx_defconfig
imote2_defconfig pxa3xx_defconfig spitz_defconfig zeus_defconfig
raumfeld_defconfig magician_defconfig mmp2_defconfig pxa168_defconfig
pxa910_defconfig
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/arm/mach-mmp/include/mach/mmp2.h | 2 +-
arch/arm/mach-mmp/include/mach/pxa168.h | 2 +-
arch/arm/mach-mmp/include/mach/pxa910.h | 2 +-
arch/arm/mach-pxa/balloon3.c | 3 +--
arch/arm/mach-pxa/cm-x300.c | 2 +-
arch/arm/mach-pxa/colibri-pxa270-income.c | 3 +--
arch/arm/mach-pxa/corgi.c | 2 +-
arch/arm/mach-pxa/csb726.c | 2 +-
arch/arm/mach-pxa/devices.c | 2 +-
arch/arm/mach-pxa/em-x270.c | 2 +-
arch/arm/mach-pxa/ezx.c | 2 +-
arch/arm/mach-pxa/hx4700.c | 2 +-
arch/arm/mach-pxa/littleton.c | 2 +-
arch/arm/mach-pxa/magician.c | 2 +-
arch/arm/mach-pxa/mainstone.c | 2 +-
arch/arm/mach-pxa/mioa701.c | 2 +-
arch/arm/mach-pxa/mxm8x10.c | 2 +-
arch/arm/mach-pxa/palm27x.c | 3 +--
arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
arch/arm/mach-pxa/poodle.c | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
arch/arm/mach-pxa/pxa3xx.c | 2 +-
arch/arm/mach-pxa/raumfeld.c | 2 +-
arch/arm/mach-pxa/saar.c | 2 +-
arch/arm/mach-pxa/spitz.c | 3 +--
arch/arm/mach-pxa/stargate2.c | 2 +-
arch/arm/mach-pxa/tavorevb3.c | 3 +--
arch/arm/mach-pxa/tosa.c | 2 +-
arch/arm/mach-pxa/trizeps4.c | 2 +-
arch/arm/mach-pxa/viper.c | 2 +-
arch/arm/mach-pxa/vpac270.c | 3 +--
arch/arm/mach-pxa/xcep.c | 3 +--
arch/arm/mach-pxa/z2.c | 3 +--
arch/arm/mach-pxa/zeus.c | 3 +--
arch/arm/mach-pxa/zylonite_pxa300.c | 2 +-
drivers/i2c/busses/i2c-pxa.c | 2 +-
.../plat/i2c.h => include/linux/i2c/pxa-i2c.h | 0
37 files changed, 36 insertions(+), 45 deletions(-)
rename arch/arm/plat-pxa/include/plat/i2c.h => include/linux/i2c/pxa-i2c.h (100%)
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index dbba6e8..95adfea 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -9,8 +9,8 @@ extern void __init mmp2_init_irq(void);
extern void mmp2_clear_pmic_int(void);
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/devices.h>
-#include <plat/i2c.h>
extern struct pxa_device_desc mmp2_device_uart1;
extern struct pxa_device_desc mmp2_device_uart2;
diff --git a/arch/arm/mach-mmp/include/mach/pxa168.h b/arch/arm/mach-mmp/include/mach/pxa168.h
index 1801e42..a52b3d2 100644
--- a/arch/arm/mach-mmp/include/mach/pxa168.h
+++ b/arch/arm/mach-mmp/include/mach/pxa168.h
@@ -8,8 +8,8 @@ extern void __init pxa168_init_irq(void);
extern void pxa168_clear_keypad_wakeup(void);
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/devices.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
#include <video/pxa168fb.h>
#include <plat/pxa27x_keypad.h>
diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index f13c49d..91be755 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -7,8 +7,8 @@ extern struct sys_timer pxa910_timer;
extern void __init pxa910_init_irq(void);
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/devices.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
extern struct pxa_device_desc pxa910_device_uart1;
diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index 21e1889..c137e45 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -27,6 +27,7 @@
#include <linux/mtd/partitions.h>
#include <linux/types.h>
#include <linux/i2c/pcf857x.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/physmap.h>
#include <linux/regulator/max1586.h>
@@ -51,8 +52,6 @@
#include <mach/irda.h>
#include <mach/ohci.h>
-#include <plat/i2c.h>
-
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/cm-x300.c b/arch/arm/mach-pxa/cm-x300.c
index 922b107..fb12504 100644
--- a/arch/arm/mach-pxa/cm-x300.c
+++ b/arch/arm/mach-pxa/cm-x300.c
@@ -29,6 +29,7 @@
#include <linux/i2c.h>
#include <linux/i2c/pca953x.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/mfd/da903x.h>
#include <linux/regulator/machine.h>
@@ -48,7 +49,6 @@
#include <mach/pxafb.h>
#include <mach/mmc.h>
#include <mach/ohci.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
#include <mach/audio.h>
#include <mach/pxa3xx-u2d.h>
diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c b/arch/arm/mach-pxa/colibri-pxa270-income.c
index 37f0f3e..c2e1955 100644
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -21,6 +21,7 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/pwm_backlight.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/sysdev.h>
#include <asm/irq.h>
@@ -33,8 +34,6 @@
#include <mach/pxa27x-udc.h>
#include <mach/pxafb.h>
-#include <plat/i2c.h>
-
#include "devices.h"
#include "generic.h"
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 3b8dcac..c96c37b 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -24,6 +24,7 @@
#include <linux/gpio.h>
#include <linux/backlight.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/io.h>
#include <linux/spi/spi.h>
#include <linux/spi/ads7846.h>
@@ -45,7 +46,6 @@
#include <asm/mach/irq.h>
#include <mach/pxa25x.h>
-#include <plat/i2c.h>
#include <mach/irda.h>
#include <mach/mmc.h>
#include <mach/udc.h>
diff --git a/arch/arm/mach-pxa/csb726.c b/arch/arm/mach-pxa/csb726.c
index 57cacaf..7cdc8e0 100644
--- a/arch/arm/mach-pxa/csb726.c
+++ b/arch/arm/mach-pxa/csb726.c
@@ -17,12 +17,12 @@
#include <linux/mtd/partitions.h>
#include <linux/sm501.h>
#include <linux/smsc911x.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <mach/csb726.h>
#include <mach/mfp-pxa27x.h>
-#include <plat/i2c.h>
#include <mach/mmc.h>
#include <mach/ohci.h>
#include <mach/pxa2xx-regs.h>
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index c4f9c71..0af4119 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -4,6 +4,7 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/spi/pxa2xx_spi.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/pmu.h>
#include <mach/udc.h>
@@ -16,7 +17,6 @@
#include <mach/camera.h>
#include <mach/audio.h>
#include <mach/hardware.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
#include "devices.h"
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index b20b944..c89eaf7 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -31,6 +31,7 @@
#include <linux/apm-emulation.h>
#include <linux/i2c.h>
#include <linux/i2c/pca953x.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/regulator/userspace-consumer.h>
#include <media/soc_camera.h>
@@ -45,7 +46,6 @@
#include <mach/ohci.h>
#include <mach/mmc.h>
#include <plat/pxa27x_keypad.h>
-#include <plat/i2c.h>
#include <mach/camera.h>
#include "generic.h"
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 142c711..15cbf6b 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -20,6 +20,7 @@
#include <linux/gpio.h>
#include <linux/gpio_keys.h>
#include <linux/leds-lp3944.h>
+#include <linux/i2c/pxa-i2c.h>
#include <media/soc_camera.h>
@@ -30,7 +31,6 @@
#include <mach/pxa27x.h>
#include <mach/pxafb.h>
#include <mach/ohci.h>
-#include <plat/i2c.h>
#include <mach/hardware.h>
#include <plat/pxa27x_keypad.h>
#include <mach/camera.h>
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index f09526f..0f48649 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -35,6 +35,7 @@
#include <linux/spi/spi.h>
#include <linux/spi/pxa2xx_spi.h>
#include <linux/usb/gpio_vbus.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/hardware.h>
#include <asm/mach-types.h>
@@ -42,7 +43,6 @@
#include <mach/pxa27x.h>
#include <mach/hx4700.h>
-#include <plat/i2c.h>
#include <mach/irda.h>
#include <video/platform_lcd.h>
diff --git a/arch/arm/mach-pxa/littleton.c b/arch/arm/mach-pxa/littleton.c
index 8051925..abed4ef 100644
--- a/arch/arm/mach-pxa/littleton.c
+++ b/arch/arm/mach-pxa/littleton.c
@@ -28,6 +28,7 @@
#include <linux/leds.h>
#include <linux/mfd/da903x.h>
#include <linux/i2c/max732x.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/types.h>
#include <asm/setup.h>
@@ -45,7 +46,6 @@
#include <mach/mmc.h>
#include <plat/pxa27x_keypad.h>
#include <mach/littleton.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
#include "generic.h"
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index 9066376..e025dd3 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -28,6 +28,7 @@
#include <linux/regulator/bq24022.h>
#include <linux/regulator/machine.h>
#include <linux/usb/gpio_vbus.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/hardware.h>
#include <asm/mach-types.h>
@@ -36,7 +37,6 @@
#include <mach/pxa27x.h>
#include <mach/magician.h>
#include <mach/pxafb.h>
-#include <plat/i2c.h>
#include <mach/mmc.h>
#include <mach/irda.h>
#include <mach/ohci.h>
diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
index a980a5c..7740148 100644
--- a/arch/arm/mach-pxa/mainstone.c
+++ b/arch/arm/mach-pxa/mainstone.c
@@ -27,6 +27,7 @@
#include <linux/gpio_keys.h>
#include <linux/pwm_backlight.h>
#include <linux/smc91x.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/types.h>
#include <asm/setup.h>
@@ -46,7 +47,6 @@
#include <mach/mainstone.h>
#include <mach/audio.h>
#include <mach/pxafb.h>
-#include <plat/i2c.h>
#include <mach/mmc.h>
#include <mach/irda.h>
#include <mach/ohci.h>
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index f5fb915..3b851f7 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -39,6 +39,7 @@
#include <linux/usb/gpio_vbus.h>
#include <linux/regulator/max1586.h>
#include <linux/slab.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -50,7 +51,6 @@
#include <mach/mmc.h>
#include <mach/udc.h>
#include <mach/pxa27x-udc.h>
-#include <plat/i2c.h>
#include <mach/camera.h>
#include <mach/audio.h>
#include <media/soc_camera.h>
diff --git a/arch/arm/mach-pxa/mxm8x10.c b/arch/arm/mach-pxa/mxm8x10.c
index 462167a..7cb415a 100644
--- a/arch/arm/mach-pxa/mxm8x10.c
+++ b/arch/arm/mach-pxa/mxm8x10.c
@@ -22,8 +22,8 @@
#include <linux/serial_8250.h>
#include <linux/dm9000.h>
#include <linux/gpio.h>
+#include <linux/i2c/pxa-i2c.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
#include <mach/pxafb.h>
diff --git a/arch/arm/mach-pxa/palm27x.c b/arch/arm/mach-pxa/palm27x.c
index 405b92a..ad077e8 100644
--- a/arch/arm/mach-pxa/palm27x.c
+++ b/arch/arm/mach-pxa/palm27x.c
@@ -22,6 +22,7 @@
#include <linux/power_supply.h>
#include <linux/usb/gpio_vbus.h>
#include <linux/regulator/max1586.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -36,8 +37,6 @@
#include <mach/palmasoc.h>
#include <mach/palm27x.h>
-#include <plat/i2c.h>
-
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
index f33647a..8d3c7a9 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -23,12 +23,12 @@
#include <linux/irq.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/pwm_backlight.h>
#include <media/soc_camera.h>
#include <asm/gpio.h>
-#include <plat/i2c.h>
#include <mach/camera.h>
#include <asm/mach/map.h>
#include <mach/pxa27x.h>
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index c05eee3..90c265f 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -23,6 +23,7 @@
#include <linux/mtd/physmap.h>
#include <linux/gpio.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/spi/spi.h>
#include <linux/spi/ads7846.h>
#include <linux/spi/pxa2xx_spi.h>
@@ -44,7 +45,6 @@
#include <mach/irda.h>
#include <mach/poodle.h>
#include <mach/pxafb.h>
-#include <plat/i2c.h>
#include <asm/hardware/scoop.h>
#include <asm/hardware/locomo.h>
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index d1fbf29..1c77e89 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -17,6 +17,7 @@
#include <linux/suspend.h>
#include <linux/platform_device.h>
#include <linux/sysdev.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/hardware.h>
#include <asm/irq.h>
@@ -27,7 +28,6 @@
#include <mach/ohci.h>
#include <mach/pm.h>
#include <mach/dma.h>
-#include <plat/i2c.h>
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index d1c747c..c9d9729 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -21,6 +21,7 @@
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/sysdev.h>
+#include <linux/i2c/pxa-i2c.h>
#include <mach/hardware.h>
#include <mach/gpio.h>
@@ -30,7 +31,6 @@
#include <mach/pm.h>
#include <mach/dma.h>
#include <mach/regs-intc.h>
-#include <plat/i2c.h>
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c
index 4121d03..dc35d85 100644
--- a/arch/arm/mach-pxa/raumfeld.c
+++ b/arch/arm/mach-pxa/raumfeld.c
@@ -32,6 +32,7 @@
#include <linux/sched.h>
#include <linux/pwm_backlight.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/spi/spi.h>
#include <linux/spi/spi_gpio.h>
#include <linux/lis3lv02d.h>
@@ -53,7 +54,6 @@
#include <mach/ohci.h>
#include <mach/pxafb.h>
#include <mach/mmc.h>
-#include <plat/i2c.h>
#include <plat/pxa3xx_nand.h>
#include "generic.h"
diff --git a/arch/arm/mach-pxa/saar.c b/arch/arm/mach-pxa/saar.c
index ffa50e6..6f65b79 100644
--- a/arch/arm/mach-pxa/saar.c
+++ b/arch/arm/mach-pxa/saar.c
@@ -20,6 +20,7 @@
#include <linux/delay.h>
#include <linux/fb.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/smc91x.h>
#include <linux/mfd/da903x.h>
#include <linux/mtd/mtd.h>
@@ -31,7 +32,6 @@
#include <asm/mach/flash.h>
#include <mach/pxa930.h>
-#include <plat/i2c.h>
#include <mach/pxafb.h>
#include "devices.h"
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 4fd5572..109a2a4 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -19,6 +19,7 @@
#include <linux/gpio.h>
#include <linux/leds.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/i2c/pca953x.h>
#include <linux/spi/spi.h>
#include <linux/spi/ads7846.h>
@@ -44,8 +45,6 @@
#include <mach/spitz.h>
#include <mach/sharpsl_pm.h>
-#include <plat/i2c.h>
-
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/stargate2.c b/arch/arm/mach-pxa/stargate2.c
index 325f6ac..797471c 100644
--- a/arch/arm/mach-pxa/stargate2.c
+++ b/arch/arm/mach-pxa/stargate2.c
@@ -25,6 +25,7 @@
#include <linux/mtd/plat-ram.h>
#include <linux/mtd/partitions.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/i2c/pcf857x.h>
#include <linux/i2c/at24.h>
#include <linux/smc91x.h>
@@ -43,7 +44,6 @@
#include <asm/mach/flash.h>
#include <mach/pxa27x.h>
-#include <plat/i2c.h>
#include <mach/mmc.h>
#include <mach/udc.h>
#include <mach/pxa27x-udc.h>
diff --git a/arch/arm/mach-pxa/tavorevb3.c b/arch/arm/mach-pxa/tavorevb3.c
index dc30116..11b8c3e 100644
--- a/arch/arm/mach-pxa/tavorevb3.c
+++ b/arch/arm/mach-pxa/tavorevb3.c
@@ -15,6 +15,7 @@
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/gpio.h>
#include <linux/mfd/88pm860x.h>
@@ -23,8 +24,6 @@
#include <mach/pxa930.h>
-#include <plat/i2c.h>
-
#include "devices.h"
#include "generic.h"
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 7b5765d..d48881d 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -34,6 +34,7 @@
#include <linux/spi/spi.h>
#include <linux/spi/pxa2xx_spi.h>
#include <linux/input/matrix_keypad.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
@@ -41,7 +42,6 @@
#include <mach/pxa25x.h>
#include <mach/reset.h>
#include <mach/irda.h>
-#include <plat/i2c.h>
#include <mach/mmc.h>
#include <mach/udc.h>
#include <mach/tosa_bt.h>
diff --git a/arch/arm/mach-pxa/trizeps4.c b/arch/arm/mach-pxa/trizeps4.c
index bdb02a0..995e671 100644
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -26,6 +26,7 @@
#include <linux/dm9000.h>
#include <linux/mtd/physmap.h>
#include <linux/mtd/partitions.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/types.h>
#include <asm/setup.h>
@@ -46,7 +47,6 @@
#include <mach/mmc.h>
#include <mach/irda.h>
#include <mach/ohci.h>
-#include <plat/i2c.h>
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 438fc9a..d36baac 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -36,6 +36,7 @@
#include <linux/gpio.h>
#include <linux/jiffies.h>
#include <linux/i2c-gpio.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/serial_8250.h>
#include <linux/smc91x.h>
#include <linux/pwm_backlight.h>
@@ -47,7 +48,6 @@
#include <mach/pxa25x.h>
#include <mach/audio.h>
#include <mach/pxafb.h>
-#include <plat/i2c.h>
#include <mach/regs-uart.h>
#include <mach/arcom-pcmcia.h>
#include <mach/viper.h>
diff --git a/arch/arm/mach-pxa/vpac270.c b/arch/arm/mach-pxa/vpac270.c
index f45ac09..4c812f9 100644
--- a/arch/arm/mach-pxa/vpac270.c
+++ b/arch/arm/mach-pxa/vpac270.c
@@ -26,6 +26,7 @@
#include <linux/ucb1400.h>
#include <linux/ata_platform.h>
#include <linux/regulator/max1586.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -40,8 +41,6 @@
#include <mach/udc.h>
#include <mach/pata_pxa.h>
-#include <plat/i2c.h>
-
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/xcep.c b/arch/arm/mach-pxa/xcep.c
index 3260ce7..e2bd5ce 100644
--- a/arch/arm/mach-pxa/xcep.c
+++ b/arch/arm/mach-pxa/xcep.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/smc91x.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -26,8 +27,6 @@
#include <asm/mach/irq.h>
#include <asm/mach/map.h>
-#include <plat/i2c.h>
-
#include <mach/hardware.h>
#include <mach/pxa2xx-regs.h>
#include <mach/mfp-pxa25x.h>
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 1b8b71b..07c93a7 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -29,6 +29,7 @@
#include <linux/gpio_keys.h>
#include <linux/delay.h>
#include <linux/regulator/machine.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -40,8 +41,6 @@
#include <mach/mmc.h>
#include <plat/pxa27x_keypad.h>
-#include <plat/i2c.h>
-
#include "generic.h"
#include "devices.h"
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index f5c9f30..838cafb 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -25,6 +25,7 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/i2c/pca953x.h>
#include <linux/apm-emulation.h>
#include <linux/can/platform/mcp251x.h>
@@ -33,8 +34,6 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
-#include <plat/i2c.h>
-
#include <mach/pxa2xx-regs.h>
#include <mach/regs-uart.h>
#include <mach/ohci.h>
diff --git a/arch/arm/mach-pxa/zylonite_pxa300.c b/arch/arm/mach-pxa/zylonite_pxa300.c
index 3aa73b3..93c64d8 100644
--- a/arch/arm/mach-pxa/zylonite_pxa300.c
+++ b/arch/arm/mach-pxa/zylonite_pxa300.c
@@ -17,11 +17,11 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/i2c.h>
+#include <linux/i2c/pxa-i2c.h>
#include <linux/i2c/pca953x.h>
#include <linux/gpio.h>
#include <mach/pxa300.h>
-#include <plat/i2c.h>
#include <mach/zylonite.h>
#include "generic.h"
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index a011455..fc2a90e 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -34,9 +34,9 @@
#include <linux/clk.h>
#include <linux/slab.h>
#include <linux/io.h>
+#include <linux/i2c/pxa-i2c.h>
#include <asm/irq.h>
-#include <plat/i2c.h>
struct pxa_reg_layout {
u32 ibmr;
diff --git a/arch/arm/plat-pxa/include/plat/i2c.h b/include/linux/i2c/pxa-i2c.h
similarity index 100%
rename from arch/arm/plat-pxa/include/plat/i2c.h
rename to include/linux/i2c/pxa-i2c.h
--
1.7.3.2
^ permalink raw reply related
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Sebastian Andrzej Siewior @ 2011-01-05 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
The Sodaville I2C controller is almost the same as found on PXA2xx. The
difference:
- the register are at a different spot
- no slave support
The PCI probe code adds three platform devices which are probed then by
the platform code.
The X86 part also adds dummy clock defines because we don't have HW
clock support.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
drivers/i2c/busses/Kconfig | 7 +-
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-pxa-pci.c | 173 ++++++++++++++++++++++++++++++++++++++
drivers/i2c/busses/i2c-pxa.c | 27 +++++-
4 files changed, 203 insertions(+), 5 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-pxa-pci.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 3a6321c..9ee3e60 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -525,15 +525,18 @@ config I2C_PNX
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP
+ depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
will be called i2c-pxa.
+config I2C_PXA_PCI
+ def_bool I2C_PXA && X86_32 && PCI && OF
+
config I2C_PXA_SLAVE
bool "Intel PXA2XX I2C Slave comms support"
- depends on I2C_PXA
+ depends on I2C_PXA && !X86_32
help
Support I2C slave mode communications on the PXA I2C bus. This
is necessary for systems where the PXA may be a target on the
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 84cb16a..78db2e3 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_I2C_PCA_PLATFORM) += i2c-pca-platform.o
obj-$(CONFIG_I2C_PMCMSP) += i2c-pmcmsp.o
obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
+obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o
obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o
obj-$(CONFIG_I2C_S6000) += i2c-s6000.o
obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
diff --git a/drivers/i2c/busses/i2c-pxa-pci.c b/drivers/i2c/busses/i2c-pxa-pci.c
new file mode 100644
index 0000000..f8709d3
--- /dev/null
+++ b/drivers/i2c/busses/i2c-pxa-pci.c
@@ -0,0 +1,173 @@
+/*
+ * The CE4100's I2C device is more or less the same one as found on PXA.
+ * It does not support slave mode, the register slightly moved. This PCI
+ * device provides three bars, every contains a single I2C controller.
+ */
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/i2c/pxa-i2c.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+
+#define CE4100_PCI_I2C_DEVS 3
+
+struct ce4100_i2c_device {
+ struct platform_device pdev;
+ struct resource res[2];
+ struct i2c_pxa_platform_data pdata;
+};
+
+struct ce4100_devices {
+ struct ce4100_i2c_device sd[CE4100_PCI_I2C_DEVS];
+};
+
+static void plat_dev_release(struct device *dev)
+{
+ struct ce4100_i2c_device *sd = container_of(dev,
+ struct ce4100_i2c_device, pdev.dev);
+
+ of_device_node_put(&sd->pdev.dev);
+}
+static int add_i2c_device(struct pci_dev *dev, int bar,
+ struct ce4100_i2c_device *sd)
+{
+ struct platform_device *pdev = &sd->pdev;
+ struct i2c_pxa_platform_data *pdata = &sd->pdata;
+ struct device_node *child;
+ int found = 0;
+ static int devnum;
+
+ pdev->name = "ce4100-i2c";
+ pdev->dev.release = plat_dev_release;
+ pdev->dev.parent = &dev->dev;
+
+ pdev->dev.platform_data = pdata;
+ pdev->resource = sd->res;
+
+ sd->res[0].flags = IORESOURCE_MEM;
+ sd->res[0].start = pci_resource_start(dev, bar);
+ sd->res[0].end = pci_resource_end(dev, bar);
+
+ sd->res[1].flags = IORESOURCE_IRQ;
+ sd->res[1].start = dev->irq;
+ sd->res[1].end = dev->irq;
+ pdev->num_resources = 2;
+
+ for_each_child_of_node(dev->dev.of_node, child) {
+ const void *prop;
+ struct resource r;
+ int ret;
+
+ ret = of_address_to_resource(child, 0, &r);
+ if (ret < 0)
+ continue;
+ if (r.start != sd->res[0].start)
+ continue;
+ if (r.end != sd->res[0].end)
+ continue;
+ if (r.flags != sd->res[0].flags)
+ continue;
+
+ pdev->dev.of_node = child;
+ prop = of_get_property(child, "fast-mode", NULL);
+ if (prop)
+ pdata->fast_mode = 1;
+
+ pdev->id = devnum++;
+ found = 1;
+ break;
+ }
+
+ if (found)
+ return platform_device_register(pdev);
+
+ dev_err(&dev->dev, "Missing a DT node at %s for controller bar %d.\n",
+ dev->dev.of_node->full_name, bar);
+ dev_err(&dev->dev, "Its memory space is 0x%08x - 0x%08x.\n",
+ sd->res[0].start, sd->res[0].end);
+ return -EINVAL;
+}
+
+static int __devinit ce4100_i2c_probe(struct pci_dev *dev,
+ const struct pci_device_id *ent)
+{
+ int ret;
+ int i;
+ struct ce4100_devices *sds;
+
+ ret = pci_enable_device_mem(dev);
+ if (ret)
+ return ret;
+
+ if (!dev->dev.of_node) {
+ dev_err(&dev->dev, "Missing device tree node.\n");
+ return -EINVAL;
+ }
+ sds = kzalloc(sizeof(*sds), GFP_KERNEL);
+ if (!sds)
+ goto err_mem;
+
+ pci_set_drvdata(dev, sds);
+
+ for (i = 0; i < ARRAY_SIZE(sds->sd); i++) {
+ ret = add_i2c_device(dev, i, &sds->sd[i]);
+ if (ret) {
+ while (--i >= 0)
+ platform_device_unregister(&sds->sd[i].pdev);
+ goto err_dev_add;
+ }
+ }
+ return 0;
+
+err_dev_add:
+ pci_set_drvdata(dev, NULL);
+ kfree(sds);
+err_mem:
+ pci_disable_device(dev);
+ return ret;
+}
+
+static void __devexit ce4100_i2c_remove(struct pci_dev *dev)
+{
+ struct ce4100_devices *sds;
+ unsigned int i;
+
+ sds = pci_get_drvdata(dev);
+ pci_set_drvdata(dev, NULL);
+
+ for (i = 0; i < ARRAY_SIZE(sds->sd); i++)
+ platform_device_unregister(&sds->sd[i].pdev);
+
+ pci_disable_device(dev);
+ kfree(sds);
+}
+
+static struct pci_device_id ce4100_i2c_devices[] __devinitdata = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x2e68)},
+ { },
+};
+MODULE_DEVICE_TABLE(pci, ce4100_i2c_devices);
+
+static struct pci_driver ce4100_i2c_driver = {
+ .name = "ce4100_i2c",
+ .id_table = ce4100_i2c_devices,
+ .probe = ce4100_i2c_probe,
+ .remove = __devexit_p(ce4100_i2c_remove),
+};
+
+static int __init ce4100_i2c_init(void)
+{
+ return pci_register_driver(&ce4100_i2c_driver);
+}
+module_init(ce4100_i2c_init);
+
+static void __exit ce4100_i2c_exit(void)
+{
+ pci_unregister_driver(&ce4100_i2c_driver);
+}
+module_exit(ce4100_i2c_exit);
+
+MODULE_DESCRIPTION("CE4100 PCI-I2C glue code for PXA's driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Sebastian Andrzej Siewior <bigeasy@linutronix.de>");
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index fc2a90e..225e9a5 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -38,6 +38,13 @@
#include <asm/irq.h>
+#ifdef CONFIG_X86
+#define clk_get(dev, id) NULL
+#define clk_put(clk) do { } while (0)
+#define clk_disable(clk) do { } while (0)
+#define clk_enable(clk) do { } while (0)
+#endif
+
struct pxa_reg_layout {
u32 ibmr;
u32 idbr;
@@ -49,6 +56,7 @@ struct pxa_reg_layout {
enum pxa_i2c_types {
REGS_PXA2XX,
REGS_PXA3XX,
+ REGS_CE4100,
};
/*
@@ -69,11 +77,19 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.isr = 0x18,
.isar = 0x20,
},
+ [REGS_CE4100] = {
+ .ibmr = 0x14,
+ .idbr = 0x0c,
+ .icr = 0x00,
+ .isr = 0x04,
+ /* no isar register */
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa2xx-i2c", REGS_PXA2XX },
{ "pxa3xx-pwri2c", REGS_PXA3XX },
+ { "ce4100-i2c", REGS_CE4100 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -442,7 +458,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(I2C_ISR_INIT, _ISR(i2c));
writel(readl(_ICR(i2c)) & ~ICR_UR, _ICR(i2c));
- writel(i2c->slave_addr, _ISAR(i2c));
+ if (i2c->reg_isar)
+ writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
@@ -1074,7 +1091,8 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
- i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
+ if (i2c_type != REGS_CE4100)
+ i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
i2c->iobase = res->start;
i2c->iosize = resource_size(res);
@@ -1113,7 +1131,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->adap.algo_data = i2c;
i2c->adap.dev.parent = &dev->dev;
- ret = i2c_add_numbered_adapter(&i2c->adap);
+ if (i2c_type == REGS_CE4100)
+ ret = i2c_add_adapter(&i2c->adap);
+ else
+ ret = i2c_add_numbered_adapter(&i2c->adap);
if (ret < 0) {
printk(KERN_INFO "I2C: Failed to add bus\n");
goto eadapt;
--
1.7.3.2
^ permalink raw reply related
* [PATCH 4/6] i2c/pxa2xx: add support for shared IRQ handler
From: Sebastian Andrzej Siewior @ 2011-01-05 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
Sodaville has three of them on a single IRQ. IRQF_DISABLED is removed
because it is a NOP allready and scheduled for removal.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
drivers/i2c/busses/i2c-pxa.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 225e9a5..e566f8c 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -956,11 +956,17 @@ static void i2c_pxa_irq_rxfull(struct pxa_i2c *i2c, u32 isr)
writel(icr, _ICR(i2c));
}
+#define VALID_INT_SOURCE (ISR_SSD | ISR_ALD | ISR_ITE | ISR_IRF | \
+ ISR_SAD | ISR_BED)
static irqreturn_t i2c_pxa_handler(int this_irq, void *dev_id)
{
struct pxa_i2c *i2c = dev_id;
u32 isr = readl(_ISR(i2c));
+ isr &= VALID_INT_SOURCE;
+ if (!isr)
+ return IRQ_NONE;
+
if (i2c_debug > 2 && 0) {
dev_dbg(&i2c->adap.dev, "%s: ISR=%08x, ICR=%08x, IBMR=%02x\n",
__func__, isr, readl(_ICR(i2c)), readl(_IBMR(i2c)));
@@ -975,7 +981,7 @@ static irqreturn_t i2c_pxa_handler(int this_irq, void *dev_id)
/*
* Always clear all pending IRQs.
*/
- writel(isr & (ISR_SSD|ISR_ALD|ISR_ITE|ISR_IRF|ISR_SAD|ISR_BED), _ISR(i2c));
+ writel(isr, _ISR(i2c));
if (isr & ISR_SAD)
i2c_pxa_slave_start(i2c, isr);
@@ -1120,7 +1126,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->adap.algo = &i2c_pxa_pio_algorithm;
} else {
i2c->adap.algo = &i2c_pxa_algorithm;
- ret = request_irq(irq, i2c_pxa_handler, IRQF_DISABLED,
+ ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
i2c->adap.name, i2c);
if (ret)
goto ereqirq;
--
1.7.3.2
^ permalink raw reply related
* [PATCH] ARM: SMDK6410: Enable suspend support for WM1192 PMIC board
From: Mark Brown @ 2011-01-05 16:51 UTC (permalink / raw)
To: linux-arm-kernel
The Samsung port requires explicit enable of suspend for each board,
do so for SMDK6410 when using the WM1192 PMIC board where the WM8312
can generate wake events.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/mach-smdk6410.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 0b55771..19f9d3f 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -69,6 +69,7 @@
#include <plat/adc.h>
#include <plat/ts.h>
#include <plat/keypad.h>
+#include <plat/pm.h>
#define UCON S3C2410_UCON_DEFAULT | S3C2410_UCON_UCLK
#define ULCON S3C2410_LCON_CS8 | S3C2410_LCON_PNONE | S3C2410_LCON_STOPB
@@ -535,6 +536,9 @@ static int wm1192_pre_init(struct wm831x *wm831x)
{
int ret;
+ /* The WM8312 can generate wake signals */
+ s3c_pm_init();
+
/* Configure the IRQ line */
s3c_gpio_setpull(S3C64XX_GPN(12), S3C_GPIO_PULL_UP);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/6] i2c/pxa2xx: check timeout correctly
From: Sebastian Andrzej Siewior @ 2011-01-05 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
timeout here maybe 0 if the event occured and a task with a higher
priority stole the cpu and we were sleeping longer than the timeout
value we specified.
In case of a real timeout I changed the error code to I2C_RETRY so we
retry the transfer.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
drivers/i2c/busses/i2c-pxa.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e566f8c..bfd115d 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -770,8 +770,10 @@ static int i2c_pxa_do_xfer(struct pxa_i2c *i2c, struct i2c_msg *msg, int num)
*/
ret = i2c->msg_idx;
- if (timeout == 0)
+ if (!timeout && i2c->msg_num) {
i2c_pxa_scream_blue_murder(i2c, "timeout");
+ ret = I2C_RETRY;
+ }
out:
return ret;
--
1.7.3.2
^ permalink raw reply related
* [PATCH 6/6] i2c/pxa2xx: pass of_node from platform driver to adapter and publish
From: Sebastian Andrzej Siewior @ 2011-01-05 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
the of_node will auto-publish devices which are added to the device
tree.
Commit 925bb9c6 aka ("of/i2c: Fix module load order issue caused by
of_i2c.c) moved the of_i2c_register_devices() function from the i2c core
back to the drivers. This patch does the same thing for the pxa driver.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
drivers/i2c/busses/i2c-pxa.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index bfd115d..a90739b 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -29,6 +29,7 @@
#include <linux/errno.h>
#include <linux/interrupt.h>
#include <linux/i2c-pxa.h>
+#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/err.h>
#include <linux/clk.h>
@@ -1138,6 +1139,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->adap.algo_data = i2c;
i2c->adap.dev.parent = &dev->dev;
+#ifdef CONFIG_OF
+ i2c->adap.dev.of_node = dev->dev.of_node;
+#endif
if (i2c_type == REGS_CE4100)
ret = i2c_add_adapter(&i2c->adap);
@@ -1147,6 +1151,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
printk(KERN_INFO "I2C: Failed to add bus\n");
goto eadapt;
}
+ of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(dev, i2c);
--
1.7.3.2
^ permalink raw reply related
* [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
From: Kevin Hilman @ 2011-01-05 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=-9soJBeSGGUmcKNckzV651y=uJ9co9rByJyQB@mail.gmail.com>
Hi Charu,
"Varadarajan, Charulatha" <charu@ti.com> writes:
> On Wed, Jan 5, 2011 at 04:47, Tony Lindgren <tony@atomide.com> wrote:
>> * Kevin Hilman <khilman@ti.com> [110104 14:45]:
>>> On Tue, 2011-01-04 at 09:52 -0800, Kevin Hilman wrote:
>>> > Mika Westerberg <ext-mika.1.westerberg@nokia.com> writes:
>>> >
>>> > > In case on OMAP2+ we call set_24xx_gpio_triggering() instead of
>>> > > updating reg and l values. However, at the end of the function we
>>> > > perform a write:
>>> > >
>>> > > ? __raw_writel(l, reg);
>>> > >
>>> > > So on OMAP2+ we end up writing 0 to the bank->base which is not
>>> > > correct (typically this points to GPIO_REVISION register).
>>> > >
>>> > > Fix this by returning immediately after call to
>>> > > set_24xx_gpio_triggering().
>>> > >
>>> > > Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
>>> >
>>> > Acked-by: Kevin Hilman <khilman@ti.com>
>>> >
>>> > Tony, this should be added to omap-for-linus as it fixes a problem in
>>> > the recently merged GPIO omap_device/hwmod conversion.
>
> One clarification - This problem should be existing since the following commit
> 92105bb70634abacc08bbe12bf6f888fbd7dad38
> which was introduced on Sep 7, 2005
>
> FYI, this part of the code remained untouched during GPIO omap_device/hwmod
> conversion.
>
OK, thanks for the clarification.
I had assumed it was recent changes since the patch didn't apply
cleanly, but am glad to be wrong. :)
Kevin
^ permalink raw reply
* Hit BUG_ON in dma-mapping.c:425
From: Russell King - ARM Linux @ 2011-01-05 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D24A108.2080609@atmel.com>
On Wed, Jan 05, 2011 at 05:49:12PM +0100, Nicolas Ferre wrote:
> Hi,
>
> While running mtd_stresstest on a dataflash (atmel_spi
> + mtd_dataflash drivers) I hit the BUG_ON directive that
> is at the beginning of ___dma_single_cpu_to_dev() function.
> This function is called from the SPI driver that do a
> dma_map_single() before DMA operations on the buffer
> transmitted from upper layers.
>
> It seems that this address is above "high_memory" limit because
> it is allocated by vmalloc (in mtd_stresstest.c:285)...
Well, its telling you is that you're not allowed to DMA to vmalloc
addresses. Whether that's the fault of the map driver or not is a
question for mtd folk.
^ permalink raw reply
* [RFC 1/5] ARM: P2V: separate PHYS_OFFSET from platform definitions
From: H Hartley Sweeten @ 2011-01-05 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1PaDOb-00023Z-CR@rmk-PC.arm.linux.org.uk>
On Tuesday, January 04, 2011 1:22 PM, Russell King wrote:
> This uncouple PHYS_OFFSET from the platform definitions, thereby
> facilitating run-time computation of the physical memory offset.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h
> index 554064e..c9400cf 100644
> --- a/arch/arm/mach-ep93xx/include/mach/memory.h
> +++ b/arch/arm/mach-ep93xx/include/mach/memory.h
> @@ -6,15 +6,15 @@
> #define __ASM_ARCH_MEMORY_H
>
> #if defined(CONFIG_EP93XX_SDCE3_SYNC_PHYS_OFFSET)
> -#define PHYS_OFFSET UL(0x00000000)
> +#define PLAT_PHYS_OFFSET UL(0x00000000)
> #elif defined(CONFIG_EP93XX_SDCE0_PHYS_OFFSET)
> -#define PHYS_OFFSET UL(0xc0000000)
> +#define PLAT_PHYS_OFFSET UL(0xc0000000)
> #elif defined(CONFIG_EP93XX_SDCE1_PHYS_OFFSET)
> -#define PHYS_OFFSET UL(0xd0000000)
> +#define PLAT_PHYS_OFFSET UL(0xd0000000)
> #elif defined(CONFIG_EP93XX_SDCE2_PHYS_OFFSET)
> -#define PHYS_OFFSET UL(0xe0000000)
> +#define PLAT_PHYS_OFFSET UL(0xe0000000)
> #elif defined(CONFIG_EP93XX_SDCE3_ASYNC_PHYS_OFFSET)
> -#define PHYS_OFFSET UL(0xf0000000)
> +#define PLAT_PHYS_OFFSET UL(0xf0000000)
> #else
> #error "Kconfig bug: No EP93xx PHYS_OFFSET set"
> #endif
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly
From: Kevin Hilman @ 2011-01-05 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105064722.GC2458@legolas.emea.dhcp.ti.com>
Felipe Balbi <balbi@ti.com> writes:
> On Tue, Jan 04, 2011 at 04:24:58PM -0800, Kevin Hilman wrote:
>> Felipe Balbi <balbi@ti.com> writes:
>>
>> > Instead of accessing the irq_desc array directly
>> > we can use irq_to_desc(irq). That will allow us to,
>> > if wanted, select SPARSE_IRQ and irq_descs will be
>> > added to a radix tree, instead of a array.
>> >
>> > Signed-off-by: Felipe Balbi <balbi@ti.com>
>>
>> Can you refresh this one against Tony's omap-for-linus branch. The GPIO
>> omap_device/hwmod conversion changed things around a bit and this patch
>> doesn't apply.
>>
>> After that, you can send separately, and I'll queue this one along with
>> some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
>> out.
>
> Sure, it's attached to this mail.
Thanks. Queueing for 2.6.38-rc
Kevin
>
> From 8d216ccac14e4eebf259d5b40ed2d239248710e1 Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <balbi@ti.com>
> Date: Wed, 5 Jan 2011 08:46:18 +0200
> Subject: [PATCH] arm: omap: gpio: don't access irq_desc array directly
> Organization: Texas Instruments\n
>
> Instead of accessing the irq_desc array directly
> we can use irq_to_desc(irq). That will allow us to,
> if wanted, select SPARSE_IRQ and irq_descs will be
> added to a radix tree, instead of a array.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> arch/arm/plat-omap/gpio.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 1f98e0b..197a6c0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -756,8 +756,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
> spin_lock_irqsave(&bank->lock, flags);
> retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
> if (retval == 0) {
> - irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
> - irq_desc[irq].status |= type;
> + struct irq_desc *d = irq_to_desc(irq);
> +
> + d->status &= ~IRQ_TYPE_SENSE_MASK;
> + d->status |= type;
> }
> spin_unlock_irqrestore(&bank->lock, flags);
>
> @@ -1671,7 +1673,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank *bank)
>
> for (j = bank->virtual_irq_start;
> j < bank->virtual_irq_start + bank_width; j++) {
> - lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
> + struct irq_desc *d = irq_to_desc(j);
> +
> + lockdep_set_class(&d->lock, &gpio_lock_class);
> set_irq_chip_data(j, bank);
> if (bank_is_mpuio(bank))
> set_irq_chip(j, &mpuio_irq_chip);
^ permalink raw reply
* [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
From: Daniel Walker @ 2011-01-05 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294216917.2179.11.camel@koala>
On Wed, 2011-01-05 at 10:41 +0200, Artem Bityutskiy wrote:
> On Fri, 2010-12-31 at 14:24 +0530, Murali Nalajala wrote:
> > From: Arve Hj?nnev?g <arve@android.com>
> >
> > Add initial msm nand driver support for Qualcomm MSM and QSD platforms.
> > This driver is currently capable of handling 2K page nand devices.
> >
> > This driver is originally
> > developed by Google and its source is available at
> > http://android.git.kernel.org/?p=kernel/experimental.git
> >
> > CC: Brian Swetland <swetland@google.com>
> > Signed-off-by: Arve Hj?nnev?g <arve@android.com>
> > Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
>
> Pushed to l2-mtd-2.6.git.
This patch had incorrect authorship .. Can you replace it with the
second one that was sent ?
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-05 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105155230.GC8638@n2100.arm.linux.org.uk>
On Wed, 2011-01-05 at 15:52 +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 10:14:17AM -0500, Trond Myklebust wrote:
> > OK. So,the new behaviour in 2.6.37 is that we're writing to a series of
> > pages via the usual kmap_atomic()/kunmap_atomic() and kmap()/kunmap()
> > interfaces, but we can end up reading them via a virtual address range
> > that gets set up via vm_map_ram() (that range gets set up before the
> > write occurs).
>
> kmap of lowmem pages will always reuses the existing kernel direct
> mapping, so there won't be a problem there.
>
> > Do we perhaps need an invalidate_kernel_vmap_range() before we can read
> > the data on ARM in this kind of scenario?
>
> Firstly, vm_map_ram() does no cache maintainence of any sort, nor does
> it take care of page colouring - so any architecture where cache aliasing
> can occur will see this problem. It should not limited to ARM.
>
> Secondly, no, invalidate_kernel_vmap_range() probably isn't sufficient.
> There's two problems here:
>
> addr = kmap(lowmem_page);
> *addr = stuff;
> kunmap(lowmem_page);
>
> Such lowmem pages are accessed through their kernel direct mapping.
>
> ptr = vm_map_ram(lowmem_page);
> read = *ptr;
>
> This creates a new mapping which can alias with the kernel direct mapping.
> Now, as this is a new mapping, there should be no cache lines associated
> with it. (Looking at vm_unmap_ram(), it calls free_unmap_vmap_area_addr(),
> free_unmap_vmap_area(), which then calls flush_cache_vunmap() on the
> region. vb_free() also calls flush_cache_vunmap() too.)
>
> If the write after kmap() hits an already present cache line, the cache
> line will be updated, but it won't be written back to memory. So, on
> a subsequent vm_map_ram(), with any kind of aliasing cache, there's
> no guarantee that you'll hit that cache line and read the data just
> written there.
>
> The kernel direct mapping would need to be flushed.
We should already be flushing the kernel direct mapping after writing by
means of the calls to flush_dcache_page() in xdr_partial_copy_from_skb()
and all the helpers in net/sunrpc/xdr.c.
The only new thing is the read access through the virtual address
mapping. That mapping is created outside the loop in
nfs_readdir_xdr_to_array(), which is why I'm thinking we do need the
invalidate_kernel_vmap_range(): we're essentially doing a series of
writes through the kernel direct mapping (i.e. readdir RPC calls), then
reading the results through the virtual mapping.
i.e. we're doing
ptr = vm_map_ram(lowmem_pages);
while (need_more_data) {
for (i = 0; i < npages; i++) {
addr = kmap_atomic(lowmem_page[i]);
*addr = rpc_stuff;
flush_dcache_page(lowmem_page[i]);
kunmap_atomic(lowmem_page[i]);
}
invalidate_kernel_vmap_range(ptr); // Needed here?
read = *ptr;
}
vm_unmap_ram(lowmem_pages)
> I'm really getting to the point of hating the poliferation of RAM
> remapping interfaces - it's going to (and is) causing nothing but lots
> of pain on virtual cache architectures, needing more and more cache
> flushing interfaces to be created.
>
> Is there any other solution to this?
Arbitrary sized pages. :-)
The problem here is that we want to read variable sized records (i.e.
readdir() records) from a multi-page buffer. We could do that by copying
those particular records that overlap with page boundaries, but that
would make for a fairly intrusive rewrite too.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH 0/5] omap2plus: Trivial build break fixes
From: Kevin Hilman @ 2011-01-05 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a39d0124306a5ac6b567edca88f0671@mail.gmail.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
[...]
>> Minor nit in your git-send-email config.
>>
>> Can you add the following to your ~/.gitconfig, or update to newer
>> git
>> where this is now the default:
>>
>> [sendemail]
>> chainreplyto = false
>>
>> This will make all patches a reply to PATCH 0 instead of to the
>> previous
>> patch.
>>
> Have tried this in v2 I posted but it didn't appear to be a
> reply for PATCH 0.
You didn't have (or I didn't see) a PATCH 0 in your v2 version. After
patch 1, all patches are replies to patch 1 (using In-Reply-To: and
References:) resulting in proper threading.
> May be I missed something.
I don't think so, it looks right now.
Kevin
^ 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