* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294256169.16957.18.camel@mulgrave.site>
On Wed, Jan 05, 2011 at 01:36:09PM -0600, James Bottomley wrote:
> On Wed, 2011-01-05 at 11:18 -0800, Linus Torvalds wrote:
> > On Wed, Jan 5, 2011 at 11:05 AM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > I think the solution for the kernel direct mapping problem is to take
> > > the expected flushes and invalidates into kmap/kunmap[_atomic].
> >
> > No, we really can't do that. Most of the time, the kmap() is the only
> > way we access the page anyway, so flushing things would just be
> > stupid. Why waste time and energy on doing something pointless?
>
> It's hardly pointless. The kmap sets up an inequivalent alias in the
> cache.
No it doesn't. For pages which are inaccessible, it sets up a mapping
for those pages. On aliasing cache architectures, when you tear down
such a mapping, you have to flush the cache before you do so (otherwise
you can end up with cache lines existing in the cache for inaccessible
mappings.)
For lowmem pages, kmap() (should always) bypass the 'setup mapping' stage
because all lowmem pages are already accessible. So kunmap() doesn't
do anything - just like the !HIGHMEM implementation for these macros.
So, for highmem-enabled systems:
low_addr = kmap_atomic(lowmem_page);
high_addr = kmap_atomic(highmem_page);
results in low_addr in the kernel direct-mapped region, and high_addr
in the kmap_atomic region.
^ permalink raw reply
* [PATCH] ARM: tegra: add tegra_defconfig
From: Olof Johansson @ 2011-01-05 20:03 UTC (permalink / raw)
To: linux-arm-kernel
Adding one single defconfig for the tegra family of boards, to over time
cover the superset of supported platform and drivers.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
I know ARM defconfigs have been a somewhat controversial topic, but:
1) One multiplatform defconfig per main class of SoC seems like an
reasonable amount to me, and the tegra platform code has so far been
merged without one.
2) With safedefconfig, this is just a 123 line file, so it's not like it's a
substantial amount of bloat.
arch/arm/configs/tegra_defconfig | 123 ++++++++++++++++++++++++++++++++++++++
1 files changed, 123 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/tegra_defconfig
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
new file mode 100644
index 0000000..7a9267e
--- /dev/null
+++ b/arch/arm/configs/tegra_defconfig
@@ -0,0 +1,123 @@
+CONFIG_EXPERIMENTAL=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_DEBUG=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EMBEDDED=y
+# CONFIG_SYSCTL_SYSCALL is not set
+# CONFIG_ELF_CORE is not set
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_TEGRA=y
+CONFIG_MACH_HARMONY=y
+CONFIG_TEGRA_DEBUG_UARTD=y
+CONFIG_ARM_ERRATA_742230=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_HIGHMEM=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_VFP=y
+CONFIG_PM=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_INET_ESP=y
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+CONFIG_IPV6=y
+CONFIG_IPV6_PRIVACY=y
+CONFIG_IPV6_ROUTER_PREF=y
+CONFIG_IPV6_OPTIMISTIC_DAD=y
+CONFIG_INET6_AH=y
+CONFIG_INET6_ESP=y
+CONFIG_INET6_IPCOMP=y
+CONFIG_IPV6_MIP6=y
+CONFIG_IPV6_TUNNEL=y
+CONFIG_IPV6_MULTIPLE_TABLES=y
+# CONFIG_WIRELESS is not set
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_MISC_DEVICES=y
+CONFIG_AD525X_DPOT=y
+CONFIG_AD525X_DPOT_I2C=y
+CONFIG_ICS932S401=y
+CONFIG_APDS9802ALS=y
+CONFIG_ISL29003=y
+CONFIG_NETDEVICES=y
+CONFIG_DUMMY=y
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_10000 is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+# CONFIG_HWMON is not set
+# CONFIG_MFD_SUPPORT is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_EXT3_FS_POSIX_ACL=y
+CONFIG_EXT3_FS_SECURITY=y
+# CONFIG_DNOTIFY is not set
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_PRINTK_TIME=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_SCHEDSTATS=y
+CONFIG_TIMER_STATS=y
+CONFIG_DEBUG_SLAB=y
+# CONFIG_DEBUG_PREEMPT is not set
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_SPINLOCK_SLEEP=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_VM=y
+CONFIG_DEBUG_SG=y
+# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_AES=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_TWOFISH=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRC_CCITT=y
+CONFIG_CRC16=y
--
1.7.3.GIT
^ permalink raw reply related
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Russell King - ARM Linux @ 2011-01-05 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105194418.GE12222@shareable.org>
On Wed, Jan 05, 2011 at 07:44:18PM +0000, Jamie Lokier wrote:
> 'git show 534be1d5' explains how it works: cpu_relax() flushes buffered
> writes from _this_ CPU, so that other CPUs which are polling can make
> progress, which avoids this CPU getting stuck if there is an indirect
> dependency (no matter how convoluted) between what it's polling and which
> it wrote just before.
>
> So cpu_relax() is *essential* in some polling loops, not a hint.
>
> In principle that could happen for I/O polling, if (a) buffered memory
> writes are delayed by I/O read transactions, and (b) the device state we're
> waiting on depends on I/O yet to be done on another CPU, which could be
> polling memory first (e.g. a spinlock).
>
> I doubt (a) in practice - but what about buses that block during I/O read?
> (I have a chip like that here, but it's ARMv4T.)
Let's be clear - ARMv5 and below generally are well ordered architectures
within the limits of caching. There are cases where the write buffer
allows two writes to pass each other. However, for IO we generally map
these - especially for ARMv4 and below - as 'uncacheable unbufferable'.
So on these, if the program says "read this location" the pipeline will
stall until the read has been issued - and if you use the result in the
next instruction, it will stall until the data is available. So really,
it's not a problem here.
ARMv6 and above have a weakly ordered memory model with speculative
prefetching, so memory reads/writes can be completely unordered. Device
accesses can pass memory accesses, but device accesses are always visible
in program order with respect to each other.
So, if you're spinning in a loop reading an IO device, all previous IO
accesses will be completed (in all ARM architectures) before the result
of your read is evaluated.
(But, let's make you squirm some more - mb() on ARMv6 and above may
equate to a CPU memory barrier _plus_ a few IO accesses to the external
L2 cache controller - which will be ordered wrt other IO accesses of
course.)
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Ben Dooks @ 2011-01-05 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-4-git-send-email-bigeasy@linutronix.de>
On Wed, Jan 05, 2011 at 05:51:00PM +0100, Sebastian Andrzej Siewior wrote:
> The Sodaville I2C controller is almost the same as found on PXA2xx. The
> difference:
> - the register are at a different spot
maybe 'offset' is a better word than 'spot' here.
> - 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);
> +
maybe add a little to_ce_dev() and use it?
> + 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);
hmm, could you copy the original resource to this?
> + 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);
Hmm, do you really need to print dev->dev.of_node->full_name here, or is
it missing from the dev_err() print?
> + dev_err(&dev->dev, "Its memory space is 0x%08x - 0x%08x.\n",
> + sd->res[0].start, sd->res[0].end);
No need for Its in this message. Also, why not print IRQ number?
> + 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>");
looks ok.
> 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;
do you really need to bother to checking i2c_type here?
>
> 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
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* [PATCH] arm: mm: Poison freed init memory
From: Russell King - ARM Linux @ 2011-01-05 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294256845-29517-1-git-send-email-sboyd@codeaurora.org>
On Wed, Jan 05, 2011 at 11:47:25AM -0800, Stephen Boyd wrote:
> Poisoning __init marked memory can be useful when tracking down
> obscure memory corruption bugs. When a pointer is 0xCCCCCCCC in an
That's a bad idea for a value. With a 3GB page offset and 256MB or
more memory, accesses to such an address will always succeed.
There's two things to be considered when selecting a possible poison
value:
1. what value is guaranteed to provoke an undefined instruction exception?
2. what value when used as an address and dereferenced is mostly always
going to abort?
1 for ARM mode implies an 0xe7fXXXfX value. For Thumb mode 0xdeXX. We
use this space for breakpoints.
2 unfortunately depends on the platform.
^ permalink raw reply
* [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
From: Russell King - ARM Linux @ 2011-01-05 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105192425.GA24729@besouro.research.nokia.com>
On Wed, Jan 05, 2011 at 09:24:25PM +0200, Eduardo Valentin wrote:
> > The way this works is that although it isn't disabled at that point,
> > if it never triggers, then everything remains happy. However, if it
> > does trigger, the genirq code will then mask the interrupt and won't
> > call the handler.
>
> Right.. I didn't see from this point. I will check how that gets unmasked.
> But even so, if I understood correctly what you described, it would still
> open a time window which the system would see at least 1 interrupt during
> the time it was not suppose to. And that can wakeup a system which is in
> deep sleep mode, either via dynamic idle or static suspend.
>
> It is unlikely, I know. But it can still happen. And can be avoided.
Maybe a system going into deep sleep mode should update the masked state
of the interrupts to reflect the lazy-disable state?
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-05 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105200008.GJ8638@n2100.arm.linux.org.uk>
On Wed, 2011-01-05 at 20:00 +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 01:36:09PM -0600, James Bottomley wrote:
> > On Wed, 2011-01-05 at 11:18 -0800, Linus Torvalds wrote:
> > > On Wed, Jan 5, 2011 at 11:05 AM, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > >
> > > > I think the solution for the kernel direct mapping problem is to take
> > > > the expected flushes and invalidates into kmap/kunmap[_atomic].
> > >
> > > No, we really can't do that. Most of the time, the kmap() is the only
> > > way we access the page anyway, so flushing things would just be
> > > stupid. Why waste time and energy on doing something pointless?
> >
> > It's hardly pointless. The kmap sets up an inequivalent alias in the
> > cache.
>
> No it doesn't. For pages which are inaccessible, it sets up a mapping
> for those pages. On aliasing cache architectures, when you tear down
> such a mapping, you have to flush the cache before you do so (otherwise
> you can end up with cache lines existing in the cache for inaccessible
> mappings.)
>
> For lowmem pages, kmap() (should always) bypass the 'setup mapping' stage
> because all lowmem pages are already accessible. So kunmap() doesn't
> do anything - just like the !HIGHMEM implementation for these macros.
well, that depends. For us on parisc, kmap of a user page in !HIGHMEM
sets up an inequivalent aliase still ... because the cache colour of the
user and kernel virtual addresses are different. Depending on the
return path to userspace, we still usually have to flush to get the user
to see the changes the kernel has made.
James
> So, for highmem-enabled systems:
>
> low_addr = kmap_atomic(lowmem_page);
> high_addr = kmap_atomic(highmem_page);
>
> results in low_addr in the kernel direct-mapped region, and high_addr
> in the kmap_atomic region.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-05 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTik214sj_wBJXhJMLRie34moG7ET1Xg62oQXsgxb@mail.gmail.com>
On Wed, 2011-01-05 at 11:49 -0800, Linus Torvalds wrote:
> 2011/1/5 James Bottomley <James.Bottomley@hansenpartnership.com>:
> >>
> >> No, we really can't do that. Most of the time, the kmap() is the only
> >> way we access the page anyway, so flushing things would just be
> >> stupid. Why waste time and energy on doing something pointless?
> >
> > It's hardly pointless. The kmap sets up an inequivalent alias in the
> > cache.
>
> NO IT DOES NOT.
Well, it does ... but not in this case because the page is freshly
allocated (which I missed before) so it has no use cache colour yet.
James
> Stop arguing, when you are so wrong.
>
> kmap() does not create any aliases. For low-memory, it just returns
> the physical address. No alias. And for high memory, there is no
> equivalent low memory address to alias _with_.
>
> Now, when you actually mix multiple kmap's and you have a virtually
> based cache, then the kmap's obviously need to flush that particular
> page when switching between each other. But that has nothing to do
> with the actual page being kmap'ed, it's entirely an internal issue
> about the particular virtual memory area being re-used. And ARM (and
> any other virtually based CPU) already does that in __kunmap_atomic().
>
> But notice the case of the low-mem. And understand that you are WRONG
> about the "inequivalent alias" thing.
>
> So I repeat: this has absolutely *NOTHING* to do with kmap(). Stop blathering.
>
> It's _purely_ an issue of vm_map_ram(). Nothing else.
>
> Linus
^ permalink raw reply
* [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
From: Artem Bityutskiy @ 2011-01-05 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294247531.16744.0.camel@c-dwalke-linux.qualcomm.com>
On Wed, 2011-01-05 at 09:12 -0800, Daniel Walker wrote:
> 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 ?
Yes, I did that actually, noticed the second one later.
--
Best Regards,
Artem Bityutskiy (???????? ?????)
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-05 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294259637.16957.25.camel@mulgrave.site>
On Wed, Jan 5, 2011 at 12:33 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> well, that depends. ?For us on parisc, kmap of a user page in !HIGHMEM
> sets up an inequivalent aliase still ... because the cache colour of the
> user and kernel virtual addresses are different. ?Depending on the
> return path to userspace, we still usually have to flush to get the user
> to see the changes the kernel has made.
Umm. Again, that has nothing to do with kmap().
This time it's about the user space mapping.
Repeat after me: even without the kmap(), the kernel access to that
mapping would have caused cache aliases.
See? Once more, the kmap() is entirely innocent. You can have a
non-highmem mapping that you never use kmap for, and that you map into
user space, and you'd see exactly the same aliases. Notice? Look ma,
no kmap().
So clearly kmap() is not the issue. The issue continues to be a
totally separate virtual mapping. Whether it's a user mapping or
vm_map_ram() is obviously immaterial - as far as the CPU is concerned,
there is no difference between the two (apart from the trivial
differences of virtual location and permissions).
(You can also force the problem with vmalloc() an then following the
kernel page tables, but I hope nobody does that any more. I suspect
I'm wrong, though, there's probably code that mixes vmalloc and
physical page accesses in various drivers)
Linus
^ permalink raw reply
* [PATCH 0/2] OMAP3: Beagle: enable 800MHz for xm
From: Nishanth Menon @ 2011-01-05 20:49 UTC (permalink / raw)
To: linux-arm-kernel
Source: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
branch: omap-for-linus (dc69d1a omap2: Make OMAP2PLUS select OMAP_DM_TIMER)
Nishanth Menon (2):
omap3|4: opp: make omapx_opp_init non-static
OMAP3: beagle xm: enable upto 800MHz OPP
arch/arm/mach-omap2/board-omap3beagle.c | 52 +++++++++++++++++++++++++++++++
arch/arm/mach-omap2/opp3xxx_data.c | 3 +-
arch/arm/mach-omap2/opp4xxx_data.c | 3 +-
3 files changed, 56 insertions(+), 2 deletions(-)
Tested: Beagle XM with Angstrom
Tested-by: Koen Kooi <koen@beagleboard.org>
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/2] omap3|4: opp: make omapx_opp_init non-static
From: Nishanth Menon @ 2011-01-05 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294260576-20237-1-git-send-email-nm@ti.com>
omap3 and omap4 opp_init should be made non-static to allow
for platform specific opp table tweaking. making these static
conflicts with the definition in pm.h(global) as well.
we include pm.h as well to ensure that there are no such prototype
conflicts with actual implementation in the future.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/opp3xxx_data.c | 3 ++-
arch/arm/mach-omap2/opp4xxx_data.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..fd3a1af 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -21,6 +21,7 @@
#include <plat/cpu.h>
#include "omap_opp_data.h"
+#include "pm.h"
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
@@ -88,7 +89,7 @@ static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
/**
* omap3_opp_init() - initialize omap3 opp table
*/
-static int __init omap3_opp_init(void)
+int __init omap3_opp_init(void)
{
int r = -ENODEV;
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
index a11fa56..f0e9939 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -22,6 +22,7 @@
#include <plat/cpu.h>
#include "omap_opp_data.h"
+#include "pm.h"
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
@@ -42,7 +43,7 @@ static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/**
* omap4_opp_init() - initialize omap4 opp table
*/
-static int __init omap4_opp_init(void)
+int __init omap4_opp_init(void)
{
int r = -ENODEV;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Nishanth Menon @ 2011-01-05 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294260576-20237-1-git-send-email-nm@ti.com>
Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
For the moment, we tweak the default table to allow for 800Mhz OPP usage.
Reported-by: Koen Kooi <koen@beagleboard.org>
Tested-by: Koen Kooi <koen@beagleboard.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 50 +++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..0b99b80 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -23,6 +23,7 @@
#include <linux/gpio.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
+#include <linux/opp.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -44,10 +45,12 @@
#include <plat/gpmc.h>
#include <plat/nand.h>
#include <plat/usb.h>
+#include <plat/omap_device.h>
#include "mux.h"
#include "hsmmc.h"
#include "timer-gp.h"
+#include "pm.h"
#define NAND_BLOCK_SIZE SZ_128K
@@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static void __init beagle_opp_init(void)
+{
+ int r = 0;
+
+ /* Initialize the omap3 opp table */
+ if (omap3_opp_init()) {
+ pr_err("%s: opp default init failed\n", __func__);
+ return;
+ }
+
+ /* Custom OPP enabled for XM */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
+ struct omap_hwmod *dh = omap_hwmod_lookup("iva");
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+ __func__, mh, dh);
+ r = -EINVAL;
+ } else {
+ /* Enable MPU 1GHz and lower opps */
+ dev = &mh->od->pdev.dev;
+ r = opp_enable(dev, 800000000);
+ /* TODO: MPU 1GHz needs SR and ABB */
+
+ /* Enable IVA 800MHz and lower opps */
+ dev = &dh->od->pdev.dev;
+ r |= opp_enable(dev, 660000000);
+ /* TODO: DSP 800MHz needs SR and ABB */
+ }
+ if (r) {
+ pr_err("%s: failed to enable higher opp %d\n",
+ __func__, r);
+ /*
+ * Cleanup - disable the higher freqs - we dont care
+ * about the results
+ */
+ dev = &mh->od->pdev.dev;
+ opp_disable(dev, 800000000);
+ dev = &dh->od->pdev.dev;
+ opp_disable(dev, 660000000);
+ }
+ }
+}
+
static void __init omap3_beagle_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
beagle_display_init();
+ beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
--
1.6.3.3
^ permalink raw reply related
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimzzBsdtWcZtP5E_CH1hUZugGMoaHOiMdQJf764@mail.gmail.com>
On Wed, Jan 05, 2011 at 12:48:32PM -0800, Linus Torvalds wrote:
> (You can also force the problem with vmalloc() an then following the
> kernel page tables, but I hope nobody does that any more. I suspect
> I'm wrong, though, there's probably code that mixes vmalloc and
> physical page accesses in various drivers)
Should vmalloc_to_page() (84 users)/vmalloc_to_pfn() (17 users) be
deprecated then? ;)
However, we seem have new ways of doing this - rather than asking
vmalloc() for some memory, and then getting at the pages by following
the page tables, we now have ways to create mappings using arrays of
struct pages and access them via their already known mappings:
- vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t prot)
- map_kernel_range_noflush(unsigned long addr, unsigned long size, pgprot_t prot, struct page **pages)
- map_vm_area(struct vm_struct *area, pgprot_t prot, struct page ***pages)
- vmap(struct page **pages, unsigned int count, unsigned long flags, pgprot_t prot)
So really it's the same problem, just created by some other easier
to use methods.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-05 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105210448.GM8638@n2100.arm.linux.org.uk>
On Wed, Jan 5, 2011 at 1:04 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 05, 2011 at 12:48:32PM -0800, Linus Torvalds wrote:
>> (You can also force the problem with vmalloc() an then following the
>> kernel page tables, but I hope nobody does that any more. I suspect
>> I'm wrong, though, there's probably code that mixes vmalloc and
>> physical page accesses in various drivers)
>
> Should vmalloc_to_page() (84 users)/vmalloc_to_pfn() (17 users) be
> deprecated then? ;)
I do think that the "modern" way of doing it is
"vmap()"/"vm_map_ram()" and friends, and it should be preferred over
using vmalloc() and then looking up the pages.
But in the end, the two approaches really are equivalent, so it's not
like it really matters. So I don't think we need to deprecate things
officially, but obviously we should make people more aware of the
whole virtual alias thing that crops up whenever you use any of these
approaches.
Linus
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-05 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimzzBsdtWcZtP5E_CH1hUZugGMoaHOiMdQJf764@mail.gmail.com>
On Wed, 2011-01-05 at 12:48 -0800, Linus Torvalds wrote:
> On Wed, Jan 5, 2011 at 12:33 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > well, that depends. For us on parisc, kmap of a user page in !HIGHMEM
> > sets up an inequivalent aliase still ... because the cache colour of the
> > user and kernel virtual addresses are different. Depending on the
> > return path to userspace, we still usually have to flush to get the user
> > to see the changes the kernel has made.
>
> Umm. Again, that has nothing to do with kmap().
>
> This time it's about the user space mapping.
>
> Repeat after me: even without the kmap(), the kernel access to that
> mapping would have caused cache aliases.
>
> See? Once more, the kmap() is entirely innocent. You can have a
> non-highmem mapping that you never use kmap for, and that you map into
> user space, and you'd see exactly the same aliases. Notice? Look ma,
> no kmap().
Yes, I understand that (we have no highmem on parisc, so kmap is a nop).
The problem (at least as I see it) is that once something within the
kernel (well, OK, mostly within drivers) touches a user page via its
kernel mapping, the flush often gets forgotten (mainly because it always
works on x86). What I was thinking about is that every time the kernel
touches a user space page, it has to be within a kmap/kunmap pair
(because the page might be highmem) ... so it's possible to make
kmap/kunmap do the flushing for this case so the driver writer can't
ever forget it.
I think the problem case is only really touching scatter/gather elements
outside of the DMA API (i.e. the driver pio case), so this may be
overkill. Russell also pointed out that a lot of the PIO iterators do
excessive kmap_atomic/kunmap_atomic on the same page, so adding a flush
could damage performance to the point where the flash root devices on
arm might not work. Plus the pio iterators already contain the
appropriate flush, so perhaps just using them in every case fixes the
problem.
> So clearly kmap() is not the issue. The issue continues to be a
> totally separate virtual mapping. Whether it's a user mapping or
> vm_map_ram() is obviously immaterial - as far as the CPU is concerned,
> there is no difference between the two (apart from the trivial
> differences of virtual location and permissions).
>
> (You can also force the problem with vmalloc() an then following the
> kernel page tables, but I hope nobody does that any more. I suspect
> I'm wrong, though, there's probably code that mixes vmalloc and
> physical page accesses in various drivers)
Yes, unfortunately, we have seen this quite a bit; mainly to get large
buffers. Its not just confined to drivers: xfs used to fail on both
arm and parisc because it used a vmalloc region for its log buffer which
it then had to do I/O on.
James
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-05 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=EXXBTW7oWHq3D+PHsx=thF1CpkRjn0ax2p5rm@mail.gmail.com>
On Wed, 2011-01-05 at 13:08 -0800, Linus Torvalds wrote:
> On Wed, Jan 5, 2011 at 1:04 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Jan 05, 2011 at 12:48:32PM -0800, Linus Torvalds wrote:
> >> (You can also force the problem with vmalloc() an then following the
> >> kernel page tables, but I hope nobody does that any more. I suspect
> >> I'm wrong, though, there's probably code that mixes vmalloc and
> >> physical page accesses in various drivers)
> >
> > Should vmalloc_to_page() (84 users)/vmalloc_to_pfn() (17 users) be
> > deprecated then? ;)
>
> I do think that the "modern" way of doing it is
> "vmap()"/"vm_map_ram()" and friends, and it should be preferred over
> using vmalloc() and then looking up the pages.
>
> But in the end, the two approaches really are equivalent, so it's not
> like it really matters. So I don't think we need to deprecate things
> officially, but obviously we should make people more aware of the
> whole virtual alias thing that crops up whenever you use any of these
> approaches.
So what should be the preferred way to ensure data gets flushed when
you've written directly to a page, and then want to read through the
vm_map_ram() virtual range? Should we be adding new semantics to
flush_kernel_dcache_page()?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-05 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294262208.2952.4.camel@heimdal.trondhjem.org>
On Wed, Jan 5, 2011 at 1:16 PM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
>
> So what should be the preferred way to ensure data gets flushed when
> you've written directly to a page, and then want to read through the
> vm_map_ram() virtual range? Should we be adding new semantics to
> flush_kernel_dcache_page()?
The "preferred way" is actually simple: "don't do that". IOW, if some
page is accessed through a virtual mapping you've set up, then
_always_ access it through that virtual mapping.
Now, when that is impossible (and yes, it sometimes is), then you
should flush after doing all writes. And if you do the write through
the regular kernel mapping, you should use flush_dcache_page(). And if
you did it through the virtual mapping, you should use
"flush_kernel_vmap_range()" or whatever.
NOTE! I really didn't look those up very closely, and if the accesses
can happen concurrently you are basically screwed, so you do need to
do locking or something else to guarantee that there is some nice
sequential order. And maybe I forgot something. Which is why I do
suggest "don't do that" as a primary approach to the problem if at all
possible.
Oh, and you may need to flush before reading too (and many writes do
end up being "read-modify-write" cycles) in case it's possible that
you have stale data from a previous read that was then invalidated by
a write to the aliasing address. Even if that write was flushed out,
the stale read data may exist at the virtual address. I forget what
all we required - in the end the only sane model is "virtual caches
suck so bad that anybody who does them should be laughed at for being
a retard".
Linus
^ permalink raw reply
* I2C support for CE4100, v3
From: Ben Dooks @ 2011-01-05 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-1-git-send-email-bigeasy@linutronix.de>
On Wed, Jan 05, 2011 at 05:50:57PM +0100, Sebastian Andrzej Siewior wrote:
> 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
please rename these i2c-pxa2xx
and for the ARM, use ARM: pxa2xx as the prefix
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
From: Russell King - ARM Linux @ 2011-01-05 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D231B5F.7030607@mvista.com>
On Tue, Jan 04, 2011 at 04:06:39PM +0300, Sergei Shtylyov wrote:
> Putting MUSB DMA enignes into drivers/dma/ is the same as taking *any*
> chip capable of bus-mastering DMA, "separating" its bus mastering related
> code from its driver and putting this code into drivers/dma/. This
> doesn't make sense, in my opinion. drivers/dma/ is for the dedicated DMA
> controllers (which can *optionally* serve the slave devices).
Then why is it already separated into its own self-contained driver?
If it's because the DMA engine is used for different peripherals (possibly
re-used for different peripherals), then it does seem to make sense to
have it separated via some API. And if possible that API might should
be something generic instead of specific.
Even more reason to do this is if the device being fed by the DMA has
been re-used with different DMA hardware (which I believe is the case
with MUSB.) What if this different DMA hardware then gets re-used for
other devices? Should they all implement the same custom API or try
for a generic API?
^ permalink raw reply
* [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
From: Russell King - ARM Linux @ 2011-01-05 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294234855-6623-1-git-send-email-santosh.shilimkar@ti.com>
On Wed, Jan 05, 2011 at 07:10:55PM +0530, Santosh Shilimkar wrote:
> Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism'
> introduced watchdog timer state state management using postsetup_state.
> This was done to allow some board files to support watchdog coverage
> throughout kernel initialization and it work as intended when RUNTIME_PM
> is enabled.
>
> With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog
> to remain enabled the omap_wdt_probe crashesh. This is because hwmod
> in absense of runtime PM unable to turn watchdog clocks because it's
> state is set to be disabled. For rest of the device, the state is
> set as enabled in absense of RUNTIME_PM
Err... wasn't this provoked by an attempt to fix the LDP issue, that is
(I believe) because the boot loader enables the watchdog and pre-hwmod
kernels used to disable it. Post-hwmod kernels stopped disabling the
watchdog, resulting in a few seconds booting userspace before the system
resets itself.
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Sebastian Andrzej Siewior @ 2011-01-05 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105202136.GI817@trinity.fluff.org>
* Ben Dooks | 2011-01-05 20:21:36 [+0000]:
>On Wed, Jan 05, 2011 at 05:51:00PM +0100, Sebastian Andrzej Siewior wrote:
>> The Sodaville I2C controller is almost the same as found on PXA2xx. The
>> difference:
>> - the register are at a different spot
>
>maybe 'offset' is a better word than 'spot' here.
okay.
>>
>> 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);
>> +
>
>maybe add a little to_ce_dev() and use it?
Well okay but it will be used only once.
>> + 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);
>
>hmm, could you copy the original resource to this?
something like
sd->res = &dev->resource[bar]
? This would work for res[0] but what about[1]? They have to be an array
don't they?
>> + 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);
>
>Hmm, do you really need to print dev->dev.of_node->full_name here, or is
>it missing from the dev_err() print?
dev_err shows the pci addreess while of_node->full_name is something
like /soc at 0/pci at 3fc/pci at av/i2c-controller at 15a00,0,0. And this node is
missing a child node or its address is wrong somewhere and the
translation went wrong and therefore there is no match. I just tried to
be accurate here.
>> + dev_err(&dev->dev, "Its memory space is 0x%08x - 0x%08x.\n",
>> + sd->res[0].start, sd->res[0].end);
>
>No need for Its in this message. Also, why not print IRQ number?
Okay. I don't think that the interrupt number is important here. I print
the physical memory address so the user can look it up in his device
tree. On the other hand I could be brief here and just mention the bar
number and the user would use lspci to lookup the memory address.
>> + return -EINVAL;
>> +}
>
>> 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
>> @@ -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;
>
>do you really need to bother to checking i2c_type here?
What would you prefer? I don't want to assign anything to ->reg_isar on
REGS_CE4100 so the NULL pointer can catch any accidental writes / reads.
And in i2c_pxa_reset() I'm going to skip writes to it.
Sebastian
^ permalink raw reply
* [RFC 1/5] ARM: P2V: separate PHYS_OFFSET from platform definitions
From: Russell King - ARM Linux @ 2011-01-05 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101041607110.22191@xanadu.home>
On Tue, Jan 04, 2011 at 04:10:44PM -0500, Nicolas Pitre wrote:
> On Tue, 4 Jan 2011, Russell King - ARM Linux 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>
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> This might even be a good time to merge such patch now even if the later
> patches don't make it into the next merge window as this would produce
> fewer conflicts later.
I think waiting might be in order - MXC conflicts with this patch set
and needs rechecking to make sure it's right. ATM, it's had no
visibility in linux-next.
However, it makes sense to get the likely to conflict bits in sooner
rather than later - or I need to publish them from my git tree in a
stable form so that people can include those changes in their patchsets.
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Russell King - ARM Linux @ 2011-01-05 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294246263-31960-4-git-send-email-bigeasy@linutronix.de>
On Wed, Jan 05, 2011 at 05:51:00PM +0100, Sebastian Andrzej Siewior wrote:
> +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;
...
> + pdev->name = "ce4100-i2c";
> + pdev->dev.release = plat_dev_release;
> + pdev->dev.parent = &dev->dev;
> +
> + pdev->dev.platform_data = pdata;
> + pdev->resource = sd->res;
...
> +static int __devinit ce4100_i2c_probe(struct pci_dev *dev,
> + const struct pci_device_id *ent)
> +{
> + 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);
...
> +static void __devexit ce4100_i2c_remove(struct pci_dev *dev)
...
> + for (i = 0; i < ARRAY_SIZE(sds->sd); i++)
> + platform_device_unregister(&sds->sd[i].pdev);
> +
> + pci_disable_device(dev);
> + kfree(sds);
> +}
I see we're still repeating the same mistakes with lifetime rules of
sysfs objects.
Any struct device which has been registered into the device model can
remain indefinitely live after it's been unregistered (by, eg, if
userspace holds a reference to it via sysfs.)
Only once the release method has been called is it safe to give up the
memory backing it - and that also goes for the code comprising the
function implementing the release.
This effectively prevents modules having release functions in them -
while you can put module use count manipulation in to prevent unloading,
it effectively prevents the module from being unloaded until you've
unbound the device.
I think you should be trying to use the platform_device_alloc()
interfaces here, rather than trying to reinvent them. The only issue I
see with that is the of_device_node_put() call. Maybe OF/DT/device model
people can provide some pointers? Adding Greg for the device model
maintainer view.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-05 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=3Gu-rz=-OdNtUXn4qw60Df6=YePnzvB=s-+Ov@mail.gmail.com>
On Wed, 2011-01-05 at 13:30 -0800, Linus Torvalds wrote:
> On Wed, Jan 5, 2011 at 1:16 PM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> >
> > So what should be the preferred way to ensure data gets flushed when
> > you've written directly to a page, and then want to read through the
> > vm_map_ram() virtual range? Should we be adding new semantics to
> > flush_kernel_dcache_page()?
>
> The "preferred way" is actually simple: "don't do that". IOW, if some
> page is accessed through a virtual mapping you've set up, then
> _always_ access it through that virtual mapping.
>
> Now, when that is impossible (and yes, it sometimes is), then you
> should flush after doing all writes. And if you do the write through
> the regular kernel mapping, you should use flush_dcache_page(). And if
> you did it through the virtual mapping, you should use
> "flush_kernel_vmap_range()" or whatever.
>
> NOTE! I really didn't look those up very closely, and if the accesses
> can happen concurrently you are basically screwed, so you do need to
> do locking or something else to guarantee that there is some nice
> sequential order. And maybe I forgot something. Which is why I do
> suggest "don't do that" as a primary approach to the problem if at all
> possible.
>
> Oh, and you may need to flush before reading too (and many writes do
> end up being "read-modify-write" cycles) in case it's possible that
> you have stale data from a previous read that was then invalidated by
> a write to the aliasing address. Even if that write was flushed out,
> the stale read data may exist at the virtual address. I forget what
> all we required - in the end the only sane model is "virtual caches
> suck so bad that anybody who does them should be laughed at for being
> a retard".
Yes. The fix I sent out was a call to invalidate_kernel_vmap_range(),
which takes care of invalidating the cache prior to a virtual address
read.
My question was specifically about the write through the regular kernel
mapping: according to Russell and my reading of the cachetlb.txt
documentation, flush_dcache_page() is only guaranteed to have an effect
on page cache pages.
flush_kernel_dcache_page() (not to be confused with flush_dcache_page)
would appear to be the closest fit according to my reading of the
documentation, however the ARM implementation appears to be a no-op...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ 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