* [PATCH] mfd: Convert to DEFINE_PCI_DEVICE_TABLE
From: Axel Lin @ 2011-12-01 1:41 UTC (permalink / raw)
To: linux-kernel
Cc: Andres Salomon, Denis Turischev, Ben Dooks, Vincent Sanders,
Mocean Laboratories, Harald Welte, Samuel Ortiz
Convert static struct pci_device_id *[] to static DEFINE_PCI_DEVICE_TABLE
tables.
Cc: Andres Salomon <dilinger@queued.net>
Cc: Denis Turischev <denis@compulab.co.il>
Cc: Ben Dooks <ben@simtec.co.uk>
Cc: Vincent Sanders <vince@simtec.co.uk>
Cc: Mocean Laboratories <info@mocean-labs.com>
Cc: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/mfd/cs5535-mfd.c | 2 +-
drivers/mfd/lpc_sch.c | 2 +-
drivers/mfd/sm501.c | 2 +-
drivers/mfd/timberdale.c | 2 +-
drivers/mfd/vx855.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/cs5535-mfd.c b/drivers/mfd/cs5535-mfd.c
index 155fa04..3d968a7 100644
--- a/drivers/mfd/cs5535-mfd.c
+++ b/drivers/mfd/cs5535-mfd.c
@@ -172,7 +172,7 @@ static void __devexit cs5535_mfd_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
-static struct pci_device_id cs5535_mfd_pci_tbl[] = {
+static DEFINE_PCI_DEVICE_TABLE(cs5535_mfd_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_CS5535_ISA) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA) },
{ 0, }
diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
index ea1169b..abc4213 100644
--- a/drivers/mfd/lpc_sch.c
+++ b/drivers/mfd/lpc_sch.c
@@ -74,7 +74,7 @@ static struct mfd_cell tunnelcreek_cells[] = {
},
};
-static struct pci_device_id lpc_sch_ids[] = {
+static DEFINE_PCI_DEVICE_TABLE(lpc_sch_ids) = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC) },
{ 0, }
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index df3702c..f4d8611 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -1720,7 +1720,7 @@ static int sm501_plat_remove(struct platform_device *dev)
return 0;
}
-static struct pci_device_id sm501_pci_tbl[] = {
+static DEFINE_PCI_DEVICE_TABLE(sm501_pci_tbl) = {
{ 0x126f, 0x0501, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0, },
};
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 02d6569..0ba26fb 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -857,7 +857,7 @@ static void __devexit timb_remove(struct pci_dev *dev)
kfree(priv);
}
-static struct pci_device_id timberdale_pci_tbl[] = {
+static DEFINE_PCI_DEVICE_TABLE(timberdale_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_TIMB, PCI_DEVICE_ID_TIMB) },
{ 0 }
};
diff --git a/drivers/mfd/vx855.c b/drivers/mfd/vx855.c
index d698703..b73cc15 100644
--- a/drivers/mfd/vx855.c
+++ b/drivers/mfd/vx855.c
@@ -118,7 +118,7 @@ static void __devexit vx855_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
-static struct pci_device_id vx855_pci_tbl[] = {
+static DEFINE_PCI_DEVICE_TABLE(vx855_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VX855) },
{ 0, }
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH/RFC 2/2] merge, pull: Document the --no-ff-only merge option
From: Samuel Bronson @ 2011-12-01 1:38 UTC (permalink / raw)
To: git; +Cc: Samuel Bronson
In-Reply-To: <1322703537-3914-1-git-send-email-naesten@gmail.com>
Now that --no-ff-only will work with pull and not just with merge, we
should probably tell the users about it.
Signed-off-by: Samuel Bronson <naesten@gmail.com>
---
Documentation/merge-options.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 6bd0b04..2adc4f5 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -56,9 +56,13 @@ With --no-squash perform the merge and commit the result. This
option can be used to override --squash.
--ff-only::
+--no-ff-only::
Refuse to merge and exit with a non-zero status unless the
current `HEAD` is already up-to-date or the merge can be
resolved as a fast-forward.
++
+With --no-ff-only, don't refuse. This is can be used to override
+--ff-only, or the "`only`" value for the `merge.ff` configuration option.
-s <strategy>::
--strategy=<strategy>::
--
1.7.7.3
^ permalink raw reply related
* [PATCH/RFC 1/2] pull: pass the --no-ff-only flag through to merge, not fetch
From: Samuel Bronson @ 2011-12-01 1:38 UTC (permalink / raw)
To: git; +Cc: Samuel Bronson
Without this, pull becomes unusable for merging branches when the config
option `merge.ff` is set to `only`.
Signed-off-by: Samuel Bronson <naesten@gmail.com>
---
git-pull.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 9868a0b..a09fcbc 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -76,6 +76,8 @@ do
no_ff=--no-ff ;;
--ff-only)
ff_only=--ff-only ;;
+ --no-ff-only)
+ ff_only=--no-ff-only ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
--
1.7.7.3
^ permalink raw reply related
* Re: [ANNOUNCE] 3.0.12-rt29
From: Steven Rostedt @ 2011-12-01 1:39 UTC (permalink / raw)
To: LKML; +Cc: linux-rt-users, Thomas Gleixner, Clark Williams, John Kacur
In-Reply-To: <1322702748.24563.33.camel@frodo>
[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]
I for got to sign this email, so I'm replying to it with a signed reply.
-- Steve
On Wed, 2011-11-30 at 20:25 -0500, Steven Rostedt wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.0.12-rt29 stable release.
>
>
> This release is just an update to the new stable 3.0.12 version
> and no RT specific changes have been made.
>
> Note, I did make and upload 3.0.11-rt28 that only merged in 3.0.11, but
> then saw that 3.0.12 was released, so I went back and merged in 3.0.12
> and started the testing scripts again.
>
>
> You can get this release via the git tree at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
>
> Head SHA1: 69a3235fcfb900e8c40a2044757903de7c15b1ef
>
>
> Or to build 3.0.12-rt29 directly, the following patches should be applied:
>
> http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
>
> http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.12.xz
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt29.patch.xz
>
>
> The broken out patches are available at:
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patches-3.0.12-rt29.tar.xz
>
> Enjoy,
>
> -- Steve
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support
From: bill4carson @ 2011-12-01 1:37 UTC (permalink / raw)
To: bill4carson, peter.maydell; +Cc: qemu-devel, android-virt
In-Reply-To: <1322703478-3292-1-git-send-email-bill4carson@gmail.com>
From: Bill Carson <bill4carson@gmail.com>
This patch adds minimal codes to support A15 which enables ARM KVM could
run Guest OS build with Versatile Express Cortex-A15x4 tile.
Signed-off-by: Bill Carson <bill4carson@gmail.com>
---
Makefile.target | 2 +-
hw/a15mpcore.c | 118 +++++++++++++++++++++++++++++++
hw/vexpress.c | 192 +++++++++++++++++++++++++++++++++++++++++++++++++++
target-arm/cpu.h | 1 +
target-arm/helper.c | 31 ++++++++
5 files changed, 343 insertions(+), 1 deletions(-)
create mode 100644 hw/a15mpcore.c
diff --git a/Makefile.target b/Makefile.target
index cce3554..69f0c4f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -343,7 +343,7 @@ endif
obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
-obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o a15mpcore.o
obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
obj-arm-y += pl061.o
obj-arm-y += arm-semi.o
diff --git a/hw/a15mpcore.c b/hw/a15mpcore.c
new file mode 100644
index 0000000..2518c17
--- /dev/null
+++ b/hw/a15mpcore.c
@@ -0,0 +1,118 @@
+/*
+ * ARM A15MPCore internal peripheral emulation (common code).
+ *
+ * Based on mpcore.c written by Paul Brook
+ * This code is licensed under the GPL.
+ */
+
+#include "sysbus.h"
+#include "qemu-timer.h"
+
+/* 64 external IRQ lines */
+#define GIC_NIRQ 96
+
+#define NCPU 4
+
+static inline int
+gic_get_current_cpu(void)
+{
+ return cpu_single_env->cpu_index;
+}
+
+#include "arm_gic.c"
+
+/* MPCore private memory region. */
+typedef struct a15mpcore_priv_state {
+ gic_state gic;
+ uint32_t scu_control;
+ int iomemtype;
+ uint32_t num_cpu;
+ MemoryRegion iomem;
+ MemoryRegion container;
+} a15mpcore_priv_state;
+
+/* TODO:Per-CPU Timers. */
+
+
+/* Per-CPU private memory mapped IO. */
+static uint64_t a15mpcore_priv_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
+{
+ a15mpcore_priv_state *s = (a15mpcore_priv_state *)opaque;
+ int id;
+
+ offset &= 0xfff;
+ /* Interrupt controller. */
+ if (offset < 0x200) {
+ id = gic_get_current_cpu();
+ } else {
+ id = (offset - 0x200) >> 8;
+ if (id >= s->num_cpu) {
+ return 0;
+ }
+ }
+ return gic_cpu_read(&s->gic, id, offset & 0xff);
+}
+
+static void a15mpcore_priv_write(void *opaque, target_phys_addr_t offset,
+ uint64_t value, unsigned size)
+{
+ a15mpcore_priv_state *s = (a15mpcore_priv_state *)opaque;
+ int id;
+
+ offset &= 0xfff;
+ /* Interrupt controller. */
+ if (offset < 0x200) {
+ id = gic_get_current_cpu();
+ } else {
+ id = (offset - 0x200) >> 8;
+ if (id >= s->num_cpu) {
+ return 0;
+ }
+ }
+ return gic_cpu_write(&s->gic, id, offset & 0xff, value);
+}
+
+static const MemoryRegionOps mpcore_priv_ops = {
+ .read = a15mpcore_priv_read,
+ .write = a15mpcore_priv_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void a15mpcore_priv_map_setup(a15mpcore_priv_state *s)
+{
+ memory_region_init(&s->container, "mpcode-priv-container", 0x3000);
+ memory_region_init_io(&s->iomem, &mpcore_priv_ops, s, "mpcode-priv",
+ 0x1000);
+ memory_region_add_subregion(&s->container, 0x2000, &s->iomem);
+ memory_region_add_subregion(&s->container, 0x1000, &s->gic.iomem);
+}
+
+static int a15mpcore_priv_init(SysBusDevice *dev)
+{
+ a15mpcore_priv_state *s = FROM_SYSBUSGIC(a15mpcore_priv_state, dev);
+ int i;
+
+ gic_init(&s->gic, s->num_cpu);
+ a15mpcore_priv_map_setup(s);
+ sysbus_init_mmio_region(dev, &s->container);
+ return 0;
+}
+
+static SysBusDeviceInfo a15mpcore_priv_info = {
+ .init = a15mpcore_priv_init,
+ .qdev.name = "a15mpcore_priv",
+ .qdev.size = sizeof(a15mpcore_priv_state),
+ .qdev.props = (Property[]) {
+ DEFINE_PROP_UINT32("num-cpu", a15mpcore_priv_state, num_cpu, 1),
+ DEFINE_PROP_END_OF_LIST(),
+ }
+};
+
+static void a15mpcore_register_devices(void)
+{
+ sysbus_register_withprop(&a15mpcore_priv_info);
+}
+
+device_init(a15mpcore_register_devices)
+
diff --git a/hw/vexpress.c b/hw/vexpress.c
index 0940a26..46a3c76 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -34,6 +34,10 @@ static struct arm_boot_info vexpress_binfo = {
.smp_loader_start = SMP_BOOT_ADDR,
};
+static struct arm_boot_info vexpress_a15_binfo = {
+ .smp_loader_start = SMP_BOOT_ADDR,
+};
+
static void vexpress_a9_init(ram_addr_t ram_size,
const char *boot_device,
const char *kernel_filename, const char *kernel_cmdline,
@@ -221,9 +225,197 @@ static QEMUMachine vexpress_a9_machine = {
.max_cpus = 4,
};
+static void vexpress_a15_init(ram_addr_t ram_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ CPUState *env = NULL;
+ ram_addr_t ram_offset, vram_offset, sram_offset;
+ DeviceState *dev, *sysctl, *pl041;
+ SysBusDevice *busdev;
+ qemu_irq *irqp;
+ qemu_irq pic[64];
+ int n;
+ qemu_irq cpu_irq[4];
+ uint32_t proc_id;
+ uint32_t sys_id;
+ ram_addr_t low_ram_size, vram_size, sram_size;
+
+ if (!cpu_model) {
+ cpu_model = "cortex-a15";
+ }
+
+ for (n = 0; n < smp_cpus; n++) {
+ env = cpu_init(cpu_model);
+ if (!env) {
+ fprintf(stderr, "Unable to find CPU definition\n");
+ exit(1);
+ }
+ irqp = arm_pic_init_cpu(env);
+ cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
+ }
+
+ if (ram_size > 0x40000000) {
+ /* 1GB is the maximum the address space permits */
+ fprintf(stderr, "vexpress: cannot model more than 1GB RAM\n");
+ exit(1);
+ }
+
+ ram_offset = qemu_ram_alloc(NULL, "vexpress.highmem", ram_size);
+ low_ram_size = ram_size;
+ if (low_ram_size > 0x4000000) {
+ low_ram_size = 0x4000000;
+ }
+ /* RAM is from 0x80000000 upwards. The bottom 64MB of the
+ * address space should in theory be remappable to various
+ * things including ROM or RAM; we always map the RAM there.
+ */
+ cpu_register_physical_memory(0x0, low_ram_size, ram_offset | IO_MEM_RAM);
+ cpu_register_physical_memory(0x80000000, ram_size,
+ ram_offset | IO_MEM_RAM);
+
+ /* 0x2c000000 A15MPCore (SCU) private memory region */
+ dev = qdev_create(NULL, "a15mpcore_priv");
+ qdev_prop_set_uint32(dev, "num-cpu", smp_cpus);
+ qdev_init_nofail(dev);
+ busdev = sysbus_from_qdev(dev);
+ vexpress_a15_binfo.smp_priv_base = 0x2c000000;
+ sysbus_mmio_map(busdev, 0, vexpress_a15_binfo.smp_priv_base);
+ for (n = 0; n < smp_cpus; n++) {
+ sysbus_connect_irq(busdev, n, cpu_irq[n]);
+ }
+ /* Interrupts [42:0] are from the motherboard;
+ * [47:43] are reserved; [63:48] are daughterboard
+ * peripherals. Note that some documentation numbers
+ * external interrupts starting from 32 (because the
+ * A9MP has internal interrupts 0..31).
+ */
+ for (n = 0; n < 64; n++) {
+ pic[n] = qdev_get_gpio_in(dev, n);
+ }
+
+ /* Motherboard peripherals CS7 : 0x10000000 .. 0x10020000 */
+ sys_id = 0x1190f500;
+ proc_id = 0x0c000000; /*depend on Fast module*/
+
+ /* 0x10000000 System registers */
+ sysctl = qdev_create(NULL, "realview_sysctl");
+ qdev_prop_set_uint32(sysctl, "sys_id", sys_id);
+ qdev_init_nofail(sysctl);
+ qdev_prop_set_uint32(sysctl, "proc_id", proc_id);
+
+ sysbus_mmio_map(sysbus_from_qdev(sysctl), 0, 0x1c010000);
+
+ /* 0x10001000 SP810 system control */
+ /* 0x10002000 serial bus PCI */
+ /* 0x10004000 PL041 audio */
+ pl041 = qdev_create(NULL, "pl041");
+ qdev_prop_set_uint32(pl041, "nc_fifo_depth", 512);
+ qdev_init_nofail(pl041);
+ sysbus_mmio_map(sysbus_from_qdev(pl041), 0, 0x10004000);
+ sysbus_connect_irq(sysbus_from_qdev(pl041), 0, pic[11]);
+ dev = sysbus_create_varargs("pl181", 0x10005000, pic[9], pic[10], NULL);
+ /* Wire up MMC card detect and read-only signals */
+ qdev_connect_gpio_out(dev, 0,
+ qdev_get_gpio_in(sysctl, ARM_SYSCTL_GPIO_MMC_WPROT));
+ qdev_connect_gpio_out(dev, 1,
+ qdev_get_gpio_in(sysctl, ARM_SYSCTL_GPIO_MMC_CARDIN));
+
+ sysbus_create_simple("pl050_keyboard", 0x1c060000, pic[12]);
+ sysbus_create_simple("pl050_mouse", 0x1c070000, pic[13]);
+
+ sysbus_create_simple("pl011", 0x1c090000, pic[5]);
+ sysbus_create_simple("pl011", 0x1c0a0000, pic[6]);
+ sysbus_create_simple("pl011", 0x1c0b0000, pic[7]);
+ sysbus_create_simple("pl011", 0x1c0c0000, pic[8]);
+
+ /* 0x1000f000 SP805 WDT */
+
+ sysbus_create_simple("sp804", 0x1c110000, pic[2]);
+ sysbus_create_simple("sp804", 0x1c120000, pic[3]);
+
+ /* 0x10016000 Serial Bus DVI */
+
+ sysbus_create_simple("pl031", 0x1c170000, pic[36]); /* RTC */
+
+ /* 0x1001a000 Compact Flash */
+
+ /* 0x1001f000 PL111 CLCD (motherboard) */
+
+ /* Daughterboard peripherals : 0x10020000 .. 0x20000000 */
+
+ /* 0x10020000 PL111 CLCD (daughterboard) */
+ sysbus_create_simple("pl111", 0x10020000, pic[44]);
+
+ /* 0x10060000 AXI RAM */
+ /* 0x100e0000 PL341 Dynamic Memory Controller */
+ /* 0x100e1000 PL354 Static Memory Controller */
+ /* 0x100e2000 System Configuration Controller */
+
+ sysbus_create_simple("sp804", 0x100e4000, pic[48]);
+ /* 0x100e5000 SP805 Watchdog module */
+ /* 0x100e6000 BP147 TrustZone Protection Controller */
+ /* 0x100e9000 PL301 'Fast' AXI matrix */
+ /* 0x100ea000 PL301 'Slow' AXI matrix */
+ /* 0x100ec000 TrustZone Address Space Controller */
+ /* 0x10200000 CoreSight debug APB */
+ /* 0x1e00a000 PL310 L2 Cache Controller */
+
+ /* CS0: NOR0 flash : 0x40000000 .. 0x44000000 */
+ /* CS4: NOR1 flash : 0x44000000 .. 0x48000000 */
+ /* CS2: SRAM : 0x48000000 .. 0x4a000000 */
+ sram_size = 0x2000000;
+ sram_offset = qemu_ram_alloc(NULL, "vexpress.sram", sram_size);
+ cpu_register_physical_memory(0x48000000, sram_size,
+ sram_offset | IO_MEM_RAM);
+
+ /* CS3: USB, ethernet, VRAM : 0x4c000000 .. 0x50000000 */
+
+ /* 0x4c000000 Video RAM */
+ vram_size = 0x2000000; /* 32MB */
+ vram_offset = qemu_ram_alloc(NULL, "vexpress.vram", vram_size);
+ cpu_register_physical_memory(0x18000000, vram_size,
+ vram_offset | IO_MEM_RAM);
+
+ /* 0x4e000000 LAN9118 Ethernet */
+ if (nd_table[0].vlan) {
+ lan9118_init(&nd_table[0], 0x4e000000, pic[15]);
+ }
+
+ /* 0x4f000000 ISP1761 USB */
+
+ /* ??? Hack to map an additional page of ram for the secondary CPU
+ startup code. I guess this works on real hardware because the
+ BootROM happens to be in ROM/flash or in memory that isn't clobbered
+ until after Linux boots the secondary CPUs. */
+ ram_offset = qemu_ram_alloc(NULL, "vexpress.hack", 0x1000);
+ cpu_register_physical_memory(SMP_BOOT_ADDR, 0x1000,
+ ram_offset | IO_MEM_RAM);
+
+ vexpress_a15_binfo.ram_size = ram_size;
+ vexpress_a15_binfo.kernel_filename = kernel_filename;
+ vexpress_a15_binfo.kernel_cmdline = kernel_cmdline;
+ vexpress_a15_binfo.initrd_filename = initrd_filename;
+ vexpress_a15_binfo.nb_cpus = smp_cpus;
+ vexpress_a15_binfo.board_id = VEXPRESS_BOARD_ID;
+ vexpress_a15_binfo.loader_start = 0x80000000;
+ arm_load_kernel(first_cpu, &vexpress_a15_binfo);
+}
+
+
+static QEMUMachine vexpress_a15_machine = {
+ .name = "vexpress-a15",
+ .desc = "ARM Versatile Express for Cortex-A15",
+ .init = vexpress_a15_init,
+ .use_scsi = 1,
+ .max_cpus = 4,
+};
+
static void vexpress_machine_init(void)
{
qemu_register_machine(&vexpress_a9_machine);
+ qemu_register_machine(&vexpress_a15_machine);
}
machine_init(vexpress_machine_init);
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 7e0a667..52334c5 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -438,6 +438,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
#define ARM_CPUID_CORTEXA8 0x410fc080
#define ARM_CPUID_CORTEXA8_R2 0x412fc083
#define ARM_CPUID_CORTEXA9 0x410fc090
+#define ARM_CPUID_CORTEXA15 0x410fc0f0
#define ARM_CPUID_CORTEXM3 0x410fc231
#define ARM_CPUID_ANY 0xffffffff
diff --git a/target-arm/helper.c b/target-arm/helper.c
index e712554..6a2c89d 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -217,6 +217,36 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
env->cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
env->cp15.c1_sys = 0x00c50078;
break;
+ case ARM_CPUID_CORTEXA15: /* most same as A9 */
+ set_feature(env, ARM_FEATURE_V4T);
+ set_feature(env, ARM_FEATURE_V5);
+ set_feature(env, ARM_FEATURE_V6);
+ set_feature(env, ARM_FEATURE_V6K);
+ set_feature(env, ARM_FEATURE_V7);
+ set_feature(env, ARM_FEATURE_AUXCR);
+ set_feature(env, ARM_FEATURE_THUMB2);
+ set_feature(env, ARM_FEATURE_VFP);
+ set_feature(env, ARM_FEATURE_VFP3);
+ set_feature(env, ARM_FEATURE_VFP_FP16);
+ set_feature(env, ARM_FEATURE_NEON);
+ set_feature(env, ARM_FEATURE_THUMB2EE);
+ /* Note that A9 supports the MP extensions even for
+ * A9UP and single-core A9MP (which are both different
+ * and valid configurations; we don't model A9UP).
+ */
+ set_feature(env, ARM_FEATURE_V7MP);
+ env->vfp.xregs[ARM_VFP_FPSID] = 0x41034000; /* Guess */
+ env->vfp.xregs[ARM_VFP_MVFR0] = 0x11110222;
+ env->vfp.xregs[ARM_VFP_MVFR1] = 0x01111111;
+ memcpy(env->cp15.c0_c1, cortexa9_cp15_c0_c1, 8 * sizeof(uint32_t));
+ memcpy(env->cp15.c0_c2, cortexa9_cp15_c0_c2, 8 * sizeof(uint32_t));
+ env->cp15.c0_cachetype = 0x80038003;
+ env->cp15.c0_clid = (1 << 27) | (1 << 24) | 3;
+ env->cp15.c0_ccsid[0] = 0xe00fe015; /* 16k L1 dcache. */
+ env->cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
+ env->cp15.c1_sys = 0x00c50078;
+ break;
+
case ARM_CPUID_CORTEXM3:
set_feature(env, ARM_FEATURE_V4T);
set_feature(env, ARM_FEATURE_V5);
@@ -460,6 +490,7 @@ static const struct arm_cpu_t arm_cpu_names[] = {
{ ARM_CPUID_CORTEXA8, "cortex-a8"},
{ ARM_CPUID_CORTEXA8_R2, "cortex-a8-r2"},
{ ARM_CPUID_CORTEXA9, "cortex-a9"},
+ { ARM_CPUID_CORTEXA15, "cortex-a15"},
{ ARM_CPUID_TI925T, "ti925t" },
{ ARM_CPUID_PXA250, "pxa250" },
{ ARM_CPUID_SA1100, "sa1100" },
--
1.7.1
^ permalink raw reply related
* [Qemu-devel] Add minimal support for Cortex A15 for ARM KVM
From: bill4carson @ 2011-12-01 1:37 UTC (permalink / raw)
To: bill4carson, peter.maydell; +Cc: qemu-devel, android-virt
This patch adds minimal support for Cortex A15 to run under ARM KVM as guest
os, and architecture timer is NOT supported yet.
Qemu based on:
git://git.linaro.org/qemu/qemu-linaro.git
Makefile.target | 2 +-
hw/a15mpcore.c | 118 +++++++++++++++++++++++++++++++
hw/vexpress.c | 192 +++++++++++++++++++++++++++++++++++++++++++++++++++
target-arm/cpu.h | 1 +
target-arm/helper.c | 31 ++++++++
5 files changed, 343 insertions(+), 1 deletions(-)
create mode 100644 hw/a15mpcore.c
^ permalink raw reply
* Re: [PATCH] netconsole: implement ipv4 tos support
From: Stephen Hemminger @ 2011-12-01 1:34 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Maciej Żenczykowski, netdev
In-Reply-To: <1322702330-31325-1-git-send-email-zenczykowski@gmail.com>
On Wed, 30 Nov 2011 17:18:50 -0800
Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Why make it an option? TOS should always be set to interactive
traffic (like telnet and slogin)
^ permalink raw reply
* Re: [PATCH 0/5] fix bugs of sub transid -- WARNING: at fs/btrfs/ctree.c:432
From: Liu Bo @ 2011-12-01 1:32 UTC (permalink / raw)
To: David Sterba, linux-btrfs, chris.mason, sensille
In-Reply-To: <20111129161729.GM12759@twin.jikos.cz>
On 11/30/2011 12:17 AM, David Sterba wrote:
> On Tue, Nov 29, 2011 at 09:18:35AM +0800, Liu Bo wrote:
>> a) For the first one (last_snapshot bug),
>>
>> The test involves three processes (derived from Chris):
>>
>> mkfs.btrfs /dev/xxx
>> mount /dev/xxx /mnt
>>
>> 1) run compilebench -i 30 --makej -D /mnt
>>
>> Let compilebench run until it starts the create phase.
>>
>> 2) run synctest -f -u -n 200 -t 3 /mnt
>> 3) for x in `seq 1 200` ; do btrfs subvol snap /mnt /mnt/snap$x ; sleep 0.5 ; done
>
> I have hit following 2 warnings during this test. Phase 1 was at compile
> stage, 2 and 3 were running. I did not see them during first run and other
> activity at the filestystem was 'du -sh /mnt'.
>
> mount options: compress-force=lzo,discard,space_cache,autodefrag,inode_cache
>
> Label: none uuid: 79f4160b-81f8-46ed-968c-968cb17a2e87
> Total devices 4 FS bytes used 7.76GB
> devid 4 size 13.96GB used 2.26GB path /dev/sdb4
> devid 3 size 13.96GB used 2.26GB path /dev/sdb3
> devid 2 size 13.96GB used 3.00GB path /dev/sdb2
> devid 1 size 13.96GB used 3.02GB path /dev/sdb1
>
> fresh and default mkfs
>
> 430 WARN_ON(root->ref_cows && trans->transaction->transid !=
> 431 root->fs_info->running_transaction->transid);
> 432 WARN_ON(root->ref_cows && trans->transid < root->last_trans);
>
Hi, David,
This should be a miss from me.
The warning is aimed to check whether this ref_cow root is in this transaction, so we can change it
to WARN_ON(root->ref_cows && trans->transaction->transid > root->last_trans);
BTW, did you catch any "parent transid mismatch" during the test? :)
thanks,
liubo
>
> 20433.473713] ------------[ cut here ]------------
> [20433.478825] WARNING: at fs/btrfs/ctree.c:432 __btrfs_cow_block+0x429/0x5e0 [btrfs]()
> [20433.487148] Hardware name: Santa Rosa platform
> [20433.487150] Modules linked in: btrfs aoe sr_mod ide_cd_mod cdrom loop [last unloaded: btrfs]
> [20433.487162] Pid: 12099, comm: btrfs Tainted: G W 3.1.0-default+ #80
> [20433.487165] Call Trace:
> [20433.487174] [<ffffffff81051c0f>] warn_slowpath_common+0x7f/0xc0
> [20433.487179] [<ffffffff81051c6a>] warn_slowpath_null+0x1a/0x20
> [20433.487190] [<ffffffffa00d6909>] __btrfs_cow_block+0x429/0x5e0 [btrfs]
> [20433.487196] [<ffffffff8108a429>] ? trace_hardirqs_off_caller+0x29/0xc0
> [20433.487201] [<ffffffff8108a7ed>] ? lock_release_holdtime+0x3d/0x1c0
> [20433.487218] [<ffffffffa0129cc0>] ? btrfs_set_lock_blocking_rw+0x50/0xb0 [btrfs]
> [20433.487230] [<ffffffffa00d6c66>] btrfs_cow_block+0x1a6/0x3d0 [btrfs]
> [20433.487236] [<ffffffff818b90cb>] ? _raw_write_unlock+0x2b/0x50
> [20433.487247] [<ffffffffa00dae70>] btrfs_search_slot+0x300/0xd20 [btrfs]
> [20433.487262] [<ffffffffa00eedcf>] btrfs_lookup_inode+0x2f/0xa0 [btrfs]
> [20433.487279] [<ffffffffa00fd186>] btrfs_update_inode_item+0x66/0x120 [btrfs]
> [20433.487296] [<ffffffffa00fe63b>] btrfs_update_inode+0xab/0xc0 [btrfs]
> [20433.487313] [<ffffffffa0134e61>] ? lookup_free_ino_inode+0x51/0xe0 [btrfs]
> [20433.487327] [<ffffffffa00ef515>] btrfs_save_ino_cache+0x145/0x2f0 [btrfs]
> [20433.487342] [<ffffffffa00f7464>] ? commit_fs_roots+0xa4/0x1c0 [btrfs]
> [20433.487357] [<ffffffffa00f7494>] commit_fs_roots+0xd4/0x1c0 [btrfs]
> [20433.487373] [<ffffffffa00f86a4>] btrfs_commit_transaction+0x454/0x900 [btrfs]
> [20433.487378] [<ffffffff8108a7ed>] ? lock_release_holdtime+0x3d/0x1c0
> [20433.487395] [<ffffffffa0126e08>] ? btrfs_mksubvol+0x298/0x360 [btrfs]
> [20433.487400] [<ffffffff81076550>] ? wake_up_bit+0x40/0x40
> [20433.487405] [<ffffffff8134738e>] ? do_raw_spin_unlock+0x5e/0xb0
> [20433.487421] [<ffffffffa0126ec8>] btrfs_mksubvol+0x358/0x360 [btrfs]
> [20433.487427] [<ffffffff8110ece3>] ? might_fault+0x53/0xb0
> [20433.487443] [<ffffffffa0126fd0>] btrfs_ioctl_snap_create_transid+0x100/0x160 [btrfs]
> [20433.487448] [<ffffffff8110ece3>] ? might_fault+0x53/0xb0
> [20433.487464] [<ffffffffa01271ad>] btrfs_ioctl_snap_create_v2.clone.0+0xfd/0x110 [btrfs]
> [20433.487482] [<ffffffffa0128a78>] btrfs_ioctl+0x588/0x1080 [btrfs]
> [20433.487487] [<ffffffff818bd9c0>] ? do_page_fault+0x2d0/0x580
> [20433.487492] [<ffffffff8107d6cf>] ? local_clock+0x6f/0x80
> [20433.487498] [<ffffffff811473e8>] do_vfs_ioctl+0x98/0x560
> [20433.487502] [<ffffffff818b9fd9>] ? retint_swapgs+0x13/0x1b
> [20433.487507] [<ffffffff811478ff>] sys_ioctl+0x4f/0x80
> [20433.487512] [<ffffffff818c21c2>] system_call_fastpath+0x16/0x1b
> [20433.487515] ---[ end trace d93007cf8d0a8eac ]---
> [20433.487576] ------------[ cut here ]------------
> [20433.487587] WARNING: at fs/btrfs/ctree.c:432 __btrfs_cow_block+0x429/0x5e0 [btrfs]()
> [20433.487590] Hardware name: Santa Rosa platform
> [20433.487592] Modules linked in: btrfs aoe sr_mod ide_cd_mod cdrom loop [last unloaded: btrfs]
> [20433.487601] Pid: 12099, comm: btrfs Tainted: G W 3.1.0-default+ #80
> [20433.487603] Call Trace:
> [20433.487608] [<ffffffff81051c0f>] warn_slowpath_common+0x7f/0xc0
> [20433.487613] [<ffffffff81051c6a>] warn_slowpath_null+0x1a/0x20
> [20433.487623] [<ffffffffa00d6909>] __btrfs_cow_block+0x429/0x5e0 [btrfs]
> [20433.487628] [<ffffffff8108a429>] ? trace_hardirqs_off_caller+0x29/0xc0
> [20433.487633] [<ffffffff8108a7ed>] ? lock_release_holdtime+0x3d/0x1c0
> [20433.487649] [<ffffffffa0129cc0>] ? btrfs_set_lock_blocking_rw+0x50/0xb0 [btrfs]
> [20433.487660] [<ffffffffa00d6c66>] btrfs_cow_block+0x1a6/0x3d0 [btrfs]
> [20433.487665] [<ffffffff818b90cb>] ? _raw_write_unlock+0x2b/0x50
> [20433.487676] [<ffffffffa00dae70>] btrfs_search_slot+0x300/0xd20 [btrfs]
> [20433.487691] [<ffffffffa00eedcf>] btrfs_lookup_inode+0x2f/0xa0 [btrfs]
> [20433.487707] [<ffffffffa00fd186>] btrfs_update_inode_item+0x66/0x120 [btrfs]
> [20433.487723] [<ffffffffa00fe63b>] btrfs_update_inode+0xab/0xc0 [btrfs]
> [20433.487739] [<ffffffffa0134e61>] ? lookup_free_ino_inode+0x51/0xe0 [btrfs]
> [20433.487753] [<ffffffffa00ef515>] btrfs_save_ino_cache+0x145/0x2f0 [btrfs]
> [20433.487769] [<ffffffffa00f7464>] ? commit_fs_roots+0xa4/0x1c0 [btrfs]
> [20433.487784] [<ffffffffa00f7494>] commit_fs_roots+0xd4/0x1c0 [btrfs]
> [20433.487800] [<ffffffffa00f86a4>] btrfs_commit_transaction+0x454/0x900 [btrfs]
> [20433.487805] [<ffffffff8108a7ed>] ? lock_release_holdtime+0x3d/0x1c0
> [20433.487821] [<ffffffffa0126e08>] ? btrfs_mksubvol+0x298/0x360 [btrfs]
> [20433.487826] [<ffffffff81076550>] ? wake_up_bit+0x40/0x40
> [20433.487830] [<ffffffff8134738e>] ? do_raw_spin_unlock+0x5e/0xb0
> [20433.487846] [<ffffffffa0126ec8>] btrfs_mksubvol+0x358/0x360 [btrfs]
> [20433.487851] [<ffffffff8110ece3>] ? might_fault+0x53/0xb0
> [20433.487867] [<ffffffffa0126fd0>] btrfs_ioctl_snap_create_transid+0x100/0x160 [btrfs]
> [20433.487872] [<ffffffff8110ece3>] ? might_fault+0x53/0xb0
> [20433.487888] [<ffffffffa01271ad>] btrfs_ioctl_snap_create_v2.clone.0+0xfd/0x110 [btrfs]
> [20433.487905] [<ffffffffa0128a78>] btrfs_ioctl+0x588/0x1080 [btrfs]
> [20433.487909] [<ffffffff818bd9c0>] ? do_page_fault+0x2d0/0x580
> [20433.487913] [<ffffffff8107d6cf>] ? local_clock+0x6f/0x80
> [20433.487918] [<ffffffff811473e8>] do_vfs_ioctl+0x98/0x560
> [20433.487922] [<ffffffff818b9fd9>] ? retint_swapgs+0x13/0x1b
> [20433.487926] [<ffffffff811478ff>] sys_ioctl+0x4f/0x80
> [20433.487931] [<ffffffff818c21c2>] system_call_fastpath+0x16/0x1b
> [20433.487934] ---[ end trace d93007cf8d0a8ead ]---
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [ANNOUNCE] 3.0.12-rt29
From: Steven Rostedt @ 2011-12-01 1:25 UTC (permalink / raw)
To: LKML, linux-rt-users; +Cc: Thomas Gleixner, Clark Williams, John Kacur
Dear RT Folks,
I'm pleased to announce the 3.0.12-rt29 stable release.
This release is just an update to the new stable 3.0.12 version
and no RT specific changes have been made.
Note, I did make and upload 3.0.11-rt28 that only merged in 3.0.11, but
then saw that 3.0.12 was released, so I went back and merged in 3.0.12
and started the testing scripts again.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
Head SHA1: 69a3235fcfb900e8c40a2044757903de7c15b1ef
Or to build 3.0.12-rt29 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.12.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt29.patch.xz
The broken out patches are available at:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patches-3.0.12-rt29.tar.xz
Enjoy,
-- Steve
^ permalink raw reply
* Re: [PATCH v3 3/5] clk: introduce the common clock framework
From: Paul Walmsley @ 2011-12-01 1:20 UTC (permalink / raw)
To: Mike Turquette
Cc: linux, linux-kernel, linux-omap, linux-arm-kernel, jeremy.kerr,
broonie, tglx, linus.walleij, amit.kucheria, dsaxena, patches,
linaro-dev, paul, grant.likely, sboyd, shawn.guo, skannan,
magnus.damm, arnd.bergmann, eric.miao, richard.zhao,
Mike Turquette
In-Reply-To: <1321926047-14211-4-git-send-email-mturquette@linaro.org>
Hello,
Here are some initial comments on clk_get_rate().
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +/**
> + * clk_get_rate - return the rate of clk
> + * @clk: the clk whose rate is being returned
> + *
> + * Simply returns the cached rate of the clk. Does not query the hardware. If
> + * clk is NULL then returns 0.
> + */
> +unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (!clk)
> + return 0;
> +
> + return clk->rate;
> +}
> +EXPORT_SYMBOL_GPL(clk_get_rate);
This implementation of clk_get_rate() is racy, and is, in general, unsafe.
The problem is that, in many cases, the clock's rate may change between
the time that clk_get_rate() is called and the time that the returned
rate is used. This is the case for many clocks which are part of a
larger DVFS domain, for example.
Several changes are needed to fix this:
1. When a clock user calls clk_enable() on a clock, the clock framework
should prevent other users of the clock from changing the clock's rate.
This should persist until the clock user calls clk_disable() (but see also
#2 below). This will ensure that clock users can rely on the rate
returned by clk_get_rate(), as long as it's called between clk_enable()
and clk_disable(). And since the clock's rate is guaranteed to remain the
same during this time, code that cannot tolerate clock rate changes
without special handling (such as driver code for external I/O devices)
will work safely without further modification.
2. Since the protocol described in #1 above will prevent DVFS from working
when the clock is part of a larger DVFS clock group, functions need to be
added to allow and prevent other clock users from changing the clock's
rate. I'll use the function names "clk_allow_rate_changes(struct clk *)"
and "clk_block_rate_changes(struct clk *)" for this discussion. These
functions can be used by clock users to define critical sections during
which other entities on the system are allowed to change a clock's rate -
even if the clock is currently enabled. (Note that when a clock is
prevented from changing its rate, all of the clocks from it up to the root
of the tree should also be prevented from changing rates, since parent
rate changes generally cause disruptions in downstream clocks.)
3. For the above changes to work, the clock framework will need to
discriminate between different clock users' calls to clock functions like
clk_{get,set}_rate(), etc. Luckily this should be possible within the
current clock interface. clk_get() can allocate and return a new struct
clk that clk_put() can later free. One useful side effect of doing this
is that the clock framework could catch unbalanced clk_{enable,disable}()
calls.
4. clk_get_rate() must return an error when it's called in situations
where the caller hasn't ensured that the clock's rate won't be changed by
other entities. For non-fixed rate clocks, these forbidden sections would
include code between a clk_get() and a clk_enable(), or between a
clk_disable() and a clk_put() or clk_enable(), or between a
clk_allow_rate_changes() and clk_block_rate_changes(). The first and
second of those three cases will require some code auditing of
clk_get_rate() users to ensure that they are only calling it after they've
enabled the clock. And presumably most of them are not checking for
error. include/linux/clk.h doesn't define an error return value, so this
needs to be explicitly defined in clk.h.
- Paul
^ permalink raw reply
* [PATCH v3 3/5] clk: introduce the common clock framework
From: Paul Walmsley @ 2011-12-01 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1321926047-14211-4-git-send-email-mturquette@linaro.org>
Hello,
Here are some initial comments on clk_get_rate().
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +/**
> + * clk_get_rate - return the rate of clk
> + * @clk: the clk whose rate is being returned
> + *
> + * Simply returns the cached rate of the clk. Does not query the hardware. If
> + * clk is NULL then returns 0.
> + */
> +unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (!clk)
> + return 0;
> +
> + return clk->rate;
> +}
> +EXPORT_SYMBOL_GPL(clk_get_rate);
This implementation of clk_get_rate() is racy, and is, in general, unsafe.
The problem is that, in many cases, the clock's rate may change between
the time that clk_get_rate() is called and the time that the returned
rate is used. This is the case for many clocks which are part of a
larger DVFS domain, for example.
Several changes are needed to fix this:
1. When a clock user calls clk_enable() on a clock, the clock framework
should prevent other users of the clock from changing the clock's rate.
This should persist until the clock user calls clk_disable() (but see also
#2 below). This will ensure that clock users can rely on the rate
returned by clk_get_rate(), as long as it's called between clk_enable()
and clk_disable(). And since the clock's rate is guaranteed to remain the
same during this time, code that cannot tolerate clock rate changes
without special handling (such as driver code for external I/O devices)
will work safely without further modification.
2. Since the protocol described in #1 above will prevent DVFS from working
when the clock is part of a larger DVFS clock group, functions need to be
added to allow and prevent other clock users from changing the clock's
rate. I'll use the function names "clk_allow_rate_changes(struct clk *)"
and "clk_block_rate_changes(struct clk *)" for this discussion. These
functions can be used by clock users to define critical sections during
which other entities on the system are allowed to change a clock's rate -
even if the clock is currently enabled. (Note that when a clock is
prevented from changing its rate, all of the clocks from it up to the root
of the tree should also be prevented from changing rates, since parent
rate changes generally cause disruptions in downstream clocks.)
3. For the above changes to work, the clock framework will need to
discriminate between different clock users' calls to clock functions like
clk_{get,set}_rate(), etc. Luckily this should be possible within the
current clock interface. clk_get() can allocate and return a new struct
clk that clk_put() can later free. One useful side effect of doing this
is that the clock framework could catch unbalanced clk_{enable,disable}()
calls.
4. clk_get_rate() must return an error when it's called in situations
where the caller hasn't ensured that the clock's rate won't be changed by
other entities. For non-fixed rate clocks, these forbidden sections would
include code between a clk_get() and a clk_enable(), or between a
clk_disable() and a clk_put() or clk_enable(), or between a
clk_allow_rate_changes() and clk_block_rate_changes(). The first and
second of those three cases will require some code auditing of
clk_get_rate() users to ensure that they are only calling it after they've
enabled the clock. And presumably most of them are not checking for
error. include/linux/clk.h doesn't define an error return value, so this
needs to be explicitly defined in clk.h.
- Paul
^ permalink raw reply
* [PATCH] netconsole: implement ipv4 tos support
From: Maciej Żenczykowski @ 2011-12-01 1:18 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: netdev, Maciej Żenczykowski
From: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
Documentation/networking/netconsole.txt | 1 +
drivers/net/netconsole.c | 28 ++++++++++++++++++++++++++++
include/linux/netpoll.h | 1 +
net/core/netpoll.c | 4 +++-
4 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 8d02207..a02374f 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -94,6 +94,7 @@ The interface exposes these parameters of a netconsole target to userspace:
remote_ip Remote agent's IP address (read-write)
local_mac Local interface's MAC address (read-only)
remote_mac Remote agent's MAC address (read-write)
+ tos TOS byte value to utilize (read-write)
The "enabled" attribute is also used to control whether the parameters of
a target can be updated or not -- you can modify the parameters of only
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index e888202..d24d5df 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -90,6 +90,7 @@ static DEFINE_SPINLOCK(target_list_lock);
* remote_ip (read-write)
* local_mac (read-only)
* remote_mac (read-write)
+ * tos (read-write)
*/
struct netconsole_target {
struct list_head list;
@@ -221,6 +222,7 @@ static void free_param_target(struct netconsole_target *nt)
* | remote_ip
* | local_mac
* | remote_mac
+ * | tos
* |
* <target>/...
*/
@@ -288,6 +290,11 @@ static ssize_t show_remote_mac(struct netconsole_target *nt, char *buf)
return snprintf(buf, PAGE_SIZE, "%pM\n", nt->np.remote_mac);
}
+static ssize_t show_tos(struct netconsole_target *nt, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "%d\n", nt->np.tos);
+}
+
/*
* This one is special -- targets created through the configfs interface
* are not enabled (and the corresponding netpoll activated) by default.
@@ -451,6 +458,25 @@ static ssize_t store_remote_mac(struct netconsole_target *nt,
return strnlen(buf, count);
}
+static ssize_t store_tos(struct netconsole_target *nt,
+ const char *buf,
+ size_t count)
+{
+ int rv;
+
+ if (nt->enabled) {
+ printk(KERN_ERR "netconsole: target (%s) is enabled, "
+ "disable to update parameters\n",
+ config_item_name(&nt->item));
+ return -EINVAL;
+ }
+
+ rv = kstrtou8(buf, 10, &nt->np.tos);
+ if (rv < 0)
+ return rv;
+ return strnlen(buf, count);
+}
+
/*
* Attribute definitions for netconsole_target.
*/
@@ -471,6 +497,7 @@ NETCONSOLE_TARGET_ATTR_RW(local_ip);
NETCONSOLE_TARGET_ATTR_RW(remote_ip);
NETCONSOLE_TARGET_ATTR_RO(local_mac);
NETCONSOLE_TARGET_ATTR_RW(remote_mac);
+NETCONSOLE_TARGET_ATTR_RW(tos);
static struct configfs_attribute *netconsole_target_attrs[] = {
&netconsole_target_enabled.attr,
@@ -481,6 +508,7 @@ static struct configfs_attribute *netconsole_target_attrs[] = {
&netconsole_target_remote_ip.attr,
&netconsole_target_local_mac.attr,
&netconsole_target_remote_mac.attr,
+ &netconsole_target_tos.attr,
NULL,
};
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 5dfa091..d659c8b 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -21,6 +21,7 @@ struct netpoll {
__be32 local_ip, remote_ip;
u16 local_port, remote_port;
u8 remote_mac[ETH_ALEN];
+ u8 tos;
struct list_head rx; /* rx_np list element */
};
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 0d38808..b01ce07 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -388,7 +388,7 @@ void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
/* iph->version = 4; iph->ihl = 5; */
put_unaligned(0x45, (unsigned char *)iph);
- iph->tos = 0;
+ iph->tos = np->tos;
put_unaligned(htons(ip_len), &(iph->tot_len));
iph->id = 0;
iph->frag_off = 0;
@@ -639,6 +639,8 @@ void netpoll_print_options(struct netpoll *np)
np->name, &np->remote_ip);
printk(KERN_INFO "%s: remote ethernet address %pM\n",
np->name, np->remote_mac);
+ printk(KERN_INFO "%s: tos value %d (0x%02x)\n",
+ np->name, np->tos, np->tos);
}
EXPORT_SYMBOL(netpoll_print_options);
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH-RESEND 4/4] pnfsblock: do not ask for layout in pg_init
From: Boaz Harrosh @ 2011-12-01 1:18 UTC (permalink / raw)
To: Peng Tao; +Cc: Benny Halevy, Trond.Myklebust, linux-nfs, Peng Tao
In-Reply-To: <CA+a=Yy5BYoxVWM+4C6ORex5aOZcLAbUmhY6XE=wBsreGVG7GAA@mail.gmail.com>
On 11/30/2011 05:17 AM, Peng Tao wrote:
>>>
>>> +/* While RFC doesn't limit maximum size of layout, we better limit it ourself. */
>>
>> Why is that?
>> What do these arbitrary numbers represent?
>> If these limits depend on some other system sizes they should reflect the dependency
>> as part of their calculation.
> What I wanted to add here is a limit to stop pg_test() (like object's
> max_io_size) and 2MB is just an experience value...
>
> Thanks,
> Tao
>>
>> Benny
>>
>>> +#define PNFSBLK_MAXRSIZE (0x1<<22)
>>> +#define PNFSBLK_MAXWSIZE (0x1<<21)
You see this is the basic principal flaw of your scheme. It is equating IO sizes
with lseg sizes.
Lets back up for a second
A. First thing to understand is that any segmenting server be it blocks objects
or files, will want the client to report to the best of it's knowledge
the intention of the writing application. Therefor a solution should be
good for all Three. What ever you are trying to do should not be private to
blocks and must not conflict with other LO needs.
Note: that the NFS-write-out stack since it holds back on writing until
sync time or memory pressure that in most cases at the point of IO has at
it's disposal the complete application IO in it's page collection per file.
(Exception is very large writes which is fine to split, given resources condition
on the client)
So below when I say application we can later mean the complete page list
available per inode at the time of write-out.
B. The *optimum* for any segmented server is:
(and addressing Trond's concern of seg list exploding and never freeing up)
B.1. If an application will write O..N of the file
1. Get one lo_seg of 0..N
2. IO at max_io from O to N until done.
3. Return or forget the lo_seg
B.2. In the case of random IO O1..N1, O2..N2,..., On..Nn
For objects and files (segmented) the optimum is still:
1. Get one lo_seg of 01..Nn
2. IO at max_io for each Ox..Nx until done.
(objects: max_io is a factor of BIO sizes group boundary and alignments.
files: max_io is stripe_unit)
3. Return or forget the 1 lo_seg
For blocks the optimum is
1. Get n lo_segs of O1..N1, O2..N2,..., On..Nn
2. IO at max_io for each Ox..Nx until done.
3. Return or forget any Ox..Nx who's IO is done
You can see that stage 2. for any kind of LO and in either B.1 or B.2 cases
is the same.
And this is, as the author intended, the .bg_init -> pg_test -> pg_IO.
For blocks with in .write_paglist there is an internal loop that re-slices the
requested linear pagelist to extents, possibly slicing each extent at bio_size
boundaries. At files and objects this slicing (though I admit very different)
actually happen at .pg_test, so at .write_paglist the request is sent in full.
C. So back to our problem:
C.1 NACK on your patchset. You are shouting to the roof how the client must
report to the Server (as hint) to the best of it's knowledge what the
application is going to do. And then you sneakily introduce an IO_MAX limitation.
This you MUST fix. Ether you send good server hint for the anticipated
application IO or not at all.
(The Server can always introduce it's own slicing and limits)
You did all this because you have circumvented the chance to do so at .pg_test
because you want the .bg_init -> pg_test -> pg_IO. loop to be your
O1..N1, O2..N2,...,On..Nn parser.
C.2 You must work out a system which will satisfy not only blocks (MPFS) server
But any segmenting server out there. blocks objects or files (segmented)
By reporting the best information you have and letting the Server do it's
decisions.
Now by postponing the report to after .pg_test -> .pg_IO you break the way
objects and files IO slicing works, and leaves them in the dark. I'm not sure
you really mean that each LO needs to do it's own private hacks?
C.3 Say we go back to the drawing board and want to do the stage 1 above of
sending the exact information to server, be it B.1 or B.2.
a. We want it at .pg_init so we have a layout at .pg_test to inspect.
Done properly will let you, in blocks, slice by extents at .pg_test
and .write_pages can send the complete paglist to md (bio chaining)
b. Say theoretically that we are willing to spend CPU and memory to collect
that information, like for example also pre-loop the page-list and/or
call the LO for the final decision.
So my all point is that b. above should eventually happen but efficiently by
pre-collecting some counters. (Remember that we already saw all these pages
in generic nfs at the vfs .write_pages vector)
Then since .pg_init is already called into LO, just change the API so the
LO have all the needed information available be it B.1 or B.2 and in return
will pass on to pnfs.c the actual lo_seg size optimal. In B.1 they all
send the same thing. In B.2 they differ.
We can start by doing all the API changes so .pg_init can specify and
return the suggested lo_size. And perhaps we add to the nfs_pageio_descriptor,
passed to .pg_init, a couple of members describing above
O1 - the index of the first page
N1 - The length up to the firs hole
Nn - Highest written page
At first version:
A good approximation which gives you an exact middle point
between blocks B.2 and objects/files B.2, is dirty count.
At later patch:
Have generic NFS collect the above O1, N1, and Nn for you and base
your decision on that.
And stop the private blocks hacks and the IO_MAX capping on the lo_seg
size.
Boaz
^ permalink raw reply
* [PATCH] [SCSI] mpt2sas: Fix leak on mpt2sas_base_attach() error path
From: Roland Dreier @ 2011-12-01 1:14 UTC (permalink / raw)
To: James E.J. Bottomley; +Cc: Nagalakshmi Nandigama, linux-scsi
From: Roland Dreier <roland@purestorage.com>
Commit 911ae9434f83 ("[SCSI] mpt2sas: Added NUNA IO support in driver
which uses multi-reply queue support of the HBA") added new
allocations to the beginning of mpt2sas_base_attach(), which means
directly returning an error on failure of mpt2sas_base_map_resources()
will leak those allocations.
Fix this by doing "goto out_free_resources" in this place too, as the
rest of the function does.
Signed-off-by: Roland Dreier <roland@purestorage.com>
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c
index beda04a..a7b2a16 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -4206,7 +4206,7 @@ mpt2sas_base_attach(struct MPT2SAS_ADAPTER *ioc)
r = mpt2sas_base_map_resources(ioc);
if (r)
- return r;
+ goto out_free_resources;
if (ioc->is_warpdrive) {
ioc->reply_post_host_index[0] =
--
1.7.5.4
^ permalink raw reply related
* Re: [patch 3/6] sched, nohz: sched group, domain aware nohz idle load balancing
From: Suresh Siddha @ 2011-12-01 1:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Venki Pallipadi, Srivatsa Vaddagiri, Mike Galbraith,
linux-kernel, Tim Chen, Shi, Alex, PaulTurner
In-Reply-To: <1322559859.2921.190.camel@twins>
On Tue, 2011-11-29 at 01:44 -0800, Peter Zijlstra wrote:
> On Mon, 2011-11-28 at 15:51 -0800, Suresh Siddha wrote:
> > Current mainline code kicks the idle load balancer if there are two busy
> > cpus in the system. Above mentioned modification makes this decision
> > some what better. For example, two busy cpu's in two different sockets
> > or two busy cpu's in a dual-core single socket system will never kick
> > idle load balancer (as there is no need).
>
> Except in power balance mode (although that's probably busted anyway),
It is already busted, no doubt about that.
> where we want to aggregate the two tasks over two sockets onto one
> socket.
So was there any discussion regarding restoring the power savings mode
at the recent scheduler bof? Even in the latest platforms, there is a
small power savings when we consolidate the two tasks in two sockets
onto one socket (though the power difference is shrinking). Turbo
headroom also plays some role in this. Two tasks in two sockets
potentially have more turbo headroom compared to the two tasks in one
socket and thus increased performance with increased power.
thanks,
suresh
^ permalink raw reply
* Re: [PATCH 1/6] 44x/pci: Continue pci setup even if there is no sdr-base in the device-tree
From: Tony Breeds @ 2011-12-01 1:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC-dev
In-Reply-To: <1322631973.21641.42.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Wed, Nov 30, 2011 at 04:46:13PM +1100, Benjamin Herrenschmidt wrote:
> If you don't expect an sdr-base as part of the normal operations of that
> bridge, don't bring a message that makes me think something is wrong :-)
>
> Just changing the severity isn't enough. you should just remove the
> message and later on, print/warn/error out if you decide you actually
> need an sdr-base (such as in the backend).
Okay no problem.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 2/2] ACPICA: support Generic Address Structure bit_offset in acpi_read/write
From: Huang Ying @ 2011-12-01 1:11 UTC (permalink / raw)
To: Luck, Tony
Cc: Rafael J. Wysocki, Russell King, Bjorn Helgaas, Thomas Renninger,
Len Brown, Moore, Robert, linux-acpi@vger.kernel.org,
bondd@us.ibm.com, Myron Stowe
In-Reply-To: <0207C53569FE594381A4F2EB66570B2A018ED45DCF@orsmsx508.amr.corp.intel.com>
On Thu, 2011-12-01 at 09:03 +0800, Luck, Tony wrote:
> > In the original acpi_read/write, we just call ioremap blindly, so the
> > code in the below patch will not introduce new issue for ia64. Do you
> > agree?
>
> See arch/ia64/mm/ioremap.c ... ioremap() on ia64 is smart and looks
> at attributes and makes new mapping match existing ones
>
> That doesn't deal with long-lived mappings and changes that I just
> mentioned in last e-mail - but it does mean that callers of ioremap()
> don't need to worry ... they can call "blindly".
I see. So you think it is better to enclose page_is_ram() with #ifndef
CONFIG_IA64 in the patch, so that only ioremap() is used?
Best Regards,
Huang Ying
^ permalink raw reply
* Re: [RFC PATCH 04/11] arm:omap:am33xx: Integrate powerdomain to OMAP power framework
From: Kevin Hilman @ 2011-12-01 1:04 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: linux-omap, tony, paul, linux-arm-kernel, b-cousson,
Afzal Mohammed
In-Reply-To: <1321809555-13833-5-git-send-email-hvaibhav@ti.com>
Vaibhav Hiremath <hvaibhav@ti.com> writes:
> From: Afzal Mohammed <afzal@ti.com>
>
> Hook up AM33XX power domain to OMAP framework.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Should be combined with previous patch.
Kevin
^ permalink raw reply
* [RFC PATCH 04/11] arm:omap:am33xx: Integrate powerdomain to OMAP power framework
From: Kevin Hilman @ 2011-12-01 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1321809555-13833-5-git-send-email-hvaibhav@ti.com>
Vaibhav Hiremath <hvaibhav@ti.com> writes:
> From: Afzal Mohammed <afzal@ti.com>
>
> Hook up AM33XX power domain to OMAP framework.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Should be combined with previous patch.
Kevin
^ permalink raw reply
* Re: [PATCH v4 06/10] e1000e: Support for byte queue limits
From: Tom Herbert @ 2011-12-01 1:04 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <20111129130137.000009ce@unknown>
> whats wrong with using total_tx_bytes or buffer_info->bytecount? it
> contains the "bytes on the wire" value which will be slightly larger
> than skb->len, but avoids warming the skb->len cacheline unnecessarily.
>
This makes sense. I made the changes, but the limits computed are
much higher than with using sbk->len. I suspect there may be a bug in
GSO path.
For instance, in the driver at:
bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;
I see cases like:
segs=34, skb_header_len(skb)=70, skb->len=49298 so bytecount=51608
Which seems reasonable... but, I also see things like:
segs=45, skb_header_len(skb)=1522, skb->len=65226, so bytecount= 132194
^^^^
Which doesn't seem right at all. I am thinking there may be a bug
setting skb->data_len improperly.
Tom
^ permalink raw reply
* Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
From: Kevin Hilman @ 2011-12-01 1:04 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: linux-omap, tony, paul, linux-arm-kernel, b-cousson,
Afzal Mohammed, Rachna Patil
In-Reply-To: <1321809555-13833-4-git-send-email-hvaibhav@ti.com>
Vaibhav Hiremath <hvaibhav@ti.com> writes:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch adds AM33XX power domain data,
> corresponding API's to access PRM module and
> PRM register offsets & bit fields.
>
> Signed-off-by: Rachna Patil <rachna@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
First some general comments:
At first glance, it seems like there could be much more reuse with OMAP4
code here. From what I see, AM33x has only one partition compared to
several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4
functions and just use a single partition.
IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4.
>From what I read (after an admittedly quick glance), the main thing you
need is a way to override the PRM offsets due to the fact that some
crazy person decided to make each instance different.
If you modified the OMAP4 base so that the _prminst_read_inst_reg()
could be customized, wouldn't that work for AM33xx?
> ---
> arch/arm/mach-omap2/powerdomain.h | 4 +-
> arch/arm/mach-omap2/powerdomain33xx.c | 155 ++++++++++++
> arch/arm/mach-omap2/powerdomains33xx_data.c | 115 +++++++++
> arch/arm/mach-omap2/prm-regbits-33xx.h | 357 +++++++++++++++++++++++++++
> arch/arm/mach-omap2/prm33xx.h | 123 +++++++++
> arch/arm/mach-omap2/prminst33xx.c | 74 ++++++
> arch/arm/mach-omap2/prminst33xx.h | 25 ++
> 7 files changed, 852 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
> create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
> create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
> create mode 100644 arch/arm/mach-omap2/prm33xx.h
> create mode 100644 arch/arm/mach-omap2/prminst33xx.c
> create mode 100644 arch/arm/mach-omap2/prminst33xx.h
>
> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index 0d72a8a..9efa823 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -69,7 +69,7 @@
> * Maximum number of clockdomains that can be associated with a powerdomain.
> * CORE powerdomain on OMAP4 is the worst case
> */
> -#define PWRDM_MAX_CLKDMS 9
> +#define PWRDM_MAX_CLKDMS 11
Comment before this needs update as well.
> /* XXX A completely arbitrary number. What is reasonable here? */
> #define PWRDM_TRANSITION_BAILOUT 100000
> @@ -223,10 +223,12 @@ bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
> extern void omap242x_powerdomains_init(void);
> extern void omap243x_powerdomains_init(void);
> extern void omap3xxx_powerdomains_init(void);
> +extern void am33xx_powerdomains_init(void);
> extern void omap44xx_powerdomains_init(void);
>
> extern struct pwrdm_ops omap2_pwrdm_operations;
> extern struct pwrdm_ops omap3_pwrdm_operations;
> +extern struct pwrdm_ops am33xx_pwrdm_operations;
> extern struct pwrdm_ops omap4_pwrdm_operations;
>
> /* Common Internal functions used across OMAP rev's */
[...]
> diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
> new file mode 100644
> index 0000000..0fd5c6e
> --- /dev/null
> +++ b/arch/arm/mach-omap2/prm33xx.h
> @@ -0,0 +1,123 @@
> +/*
> + * AM33XX PRM instance offset macros
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __ARCH_ARM_MACH_OMAP2_PRM33XX_H
> +#define __ARCH_ARM_MACH_OMAP2_PRM33XX_H
> +
> +#include "prcm-common.h"
> +#include "prm.h"
> +
> +#define AM33XX_PRM_BASE 0x44E00000
> +
> +#define AM33XX_PRM_REGADDR(inst, reg) \
> + AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE + (inst) + (reg))
> +
> +
> +/* PRM instances */
> +#define AM33XX_PRM_OCP_SOCKET_MOD 0x0B00
> +#define AM33XX_PRM_PER_MOD 0x0C00
> +#define AM33XX_PRM_WKUP_MOD 0x0D00
> +#define AM33XX_PRM_MPU_MOD 0x0E00
> +#define AM33XX_PRM_DEVICE_MOD 0x0F00
> +#define AM33XX_PRM_RTC_MOD 0x1000
> +#define AM33XX_PRM_GFX_MOD 0x1100
> +#define AM33XX_PRM_CEFUSE_MOD 0x1200
> +
> +/* Register offsets (used from OMAP4) */
Probably could just include prm44xx.h and use OMAP4_PM_... instead.
> +#define AM33XX_PM_PWSTCTRL 0x0000
> +#define AM33XX_PM_PWSTST 0x0004
However, since thes are just dummy offsets into a "fixup" table anyways,
maybe it's best to use use 0 and 1 here and have a comment here to that
effect. Otherwise, it's a bit confusing since one would assume these
are actual register offsets.
[...]
> diff --git a/arch/arm/mach-omap2/prminst33xx.c b/arch/arm/mach-omap2/prminst33xx.c
> new file mode 100644
> index 0000000..88382ba
> --- /dev/null
> +++ b/arch/arm/mach-omap2/prminst33xx.c
> @@ -0,0 +1,74 @@
> +/*
> + * AM33XX PRM instance functions
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/errno.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +
> +#include <plat/common.h>
> +
> +#include "prm33xx.h"
> +#include "prminst33xx.h"
> +#include "prm-regbits-33xx.h"
> +
> +#define AM33XX_PRM_MOD_SIZE 0x100
> +#define AM33XX_PRM_MOD_START AM33XX_PRM_PER_MOD
> +#define PRM_REG_SZ 0x4
> +
> +/*
> + * PRM Offsets are screwed up, and they are not consistent across modules.
> + * Below are the offsets for PWRSTCTRL and PWRSTST for respective modules.
> + */
> +static u16 off_fixup[][2] = {
> + { 0xC, 0x8 }, /* AM33XX_PRM_PER_MOD */
> + { 0x4, 0x8 }, /* AM33XX_PRM_WKUP_MOD */
> + { 0x0, 0x4 }, /* AM33XX_PRM_MPU_MOD */
> + /* XXX: PRM_DEVICE: offsets are invalid for powerdomain*/
> + { 0x0, 0x0 }, /* AM33XX_PRM_DEVICE_MOD */
> + { 0x0, 0x4 }, /* AM33XX_PRM_RTC_MOD */
> + { 0x0, 0x10 }, /* AM33XX_PRM_GFX_MOD */
> + { 0x0, 0x4 }, /* AM33XX_PRM_CEFUSE_MOD */
> +};
Please use the #define values from prm-regbits...h
[...]
Kevin
^ permalink raw reply
* Re: [PATCH 1/4] iommu: Add iommu_device_group callback and iommu_group sysfs entry
From: Chris Wright @ 2011-12-01 1:04 UTC (permalink / raw)
To: David Gibson, Chris Wright, Alex Williamson,
Benjamin Herrenschmidt, joerg.roedel, dwmw2, iommu, linux-kernel,
agraf, scottwood, B08248
In-Reply-To: <20111201005725.GE5427@truffala.fritz.box>
* David Gibson (dwg@au1.ibm.com) wrote:
> On Wed, Nov 30, 2011 at 04:52:20PM -0800, Chris Wright wrote:
> > * David Gibson (dwg@au1.ibm.com) wrote:
> > > On Tue, Nov 29, 2011 at 10:25:51PM -0700, Alex Williamson wrote:
> > > > Note that iommu drivers are registered per bus_type, so the unique pair
> > > > is {bus_type, groupid}, which seems sufficient for vfio.
> > >
> > > Hrm. That's.. far from obvious. And still breaks down if we have two
> > > separate iommus on the same bus type (e.g. two independent PCI host
> > > bridges with inbuilt IOMMUs).
> >
> > Happens to still work for Intel IOMMU on x86 the way Alex wrote the
> > Intel VT-d patch in this series, as well as AMD IOMMU. The caveat for
> > AMD IOMMU is that the groupid generation would break (as-is) once
> > there's support for multiple PCI segments. This is not an inherent
> > shortcoming of the groupid mechanism though, just a current limitation
> > of AMD IOMMU's implementation. Alex overloaded B:D.F for those which is
> > a convenient id since that maps to the device (or in the case of devices
> > behind a PCIe-to-PCI bridge, the requestor ID of all devices behind the
> > bridge, or "the group").
>
> "Happens to still work" is not exactly a ringing endorsement.
Heh. Put it another way. Generating the group ID is left up to the
IOMMU. This will break down when there's a system with multiple IOMMU's
on the same bus_type that don't have any awareness of one another. This
is not the case for the existing series and x86 hw.
I'm not opposed to doing the allocation and ptr as id (taking care for
possibility that PCI hotplug/unplug/replug could reuse the same memory
for group id, however). Just pointing out that the current system works
as is, and there's some value in it's simplicity (overloading ID ==
group structure + pretty printing ID in sysfs, for example).
thanks,
-chris
^ permalink raw reply
* [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
From: Kevin Hilman @ 2011-12-01 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1321809555-13833-4-git-send-email-hvaibhav@ti.com>
Vaibhav Hiremath <hvaibhav@ti.com> writes:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch adds AM33XX power domain data,
> corresponding API's to access PRM module and
> PRM register offsets & bit fields.
>
> Signed-off-by: Rachna Patil <rachna@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
First some general comments:
At first glance, it seems like there could be much more reuse with OMAP4
code here. From what I see, AM33x has only one partition compared to
several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4
functions and just use a single partition.
IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4.
>From what I read (after an admittedly quick glance), the main thing you
need is a way to override the PRM offsets due to the fact that some
crazy person decided to make each instance different.
If you modified the OMAP4 base so that the _prminst_read_inst_reg()
could be customized, wouldn't that work for AM33xx?
> ---
> arch/arm/mach-omap2/powerdomain.h | 4 +-
> arch/arm/mach-omap2/powerdomain33xx.c | 155 ++++++++++++
> arch/arm/mach-omap2/powerdomains33xx_data.c | 115 +++++++++
> arch/arm/mach-omap2/prm-regbits-33xx.h | 357 +++++++++++++++++++++++++++
> arch/arm/mach-omap2/prm33xx.h | 123 +++++++++
> arch/arm/mach-omap2/prminst33xx.c | 74 ++++++
> arch/arm/mach-omap2/prminst33xx.h | 25 ++
> 7 files changed, 852 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
> create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
> create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
> create mode 100644 arch/arm/mach-omap2/prm33xx.h
> create mode 100644 arch/arm/mach-omap2/prminst33xx.c
> create mode 100644 arch/arm/mach-omap2/prminst33xx.h
>
> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index 0d72a8a..9efa823 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -69,7 +69,7 @@
> * Maximum number of clockdomains that can be associated with a powerdomain.
> * CORE powerdomain on OMAP4 is the worst case
> */
> -#define PWRDM_MAX_CLKDMS 9
> +#define PWRDM_MAX_CLKDMS 11
Comment before this needs update as well.
> /* XXX A completely arbitrary number. What is reasonable here? */
> #define PWRDM_TRANSITION_BAILOUT 100000
> @@ -223,10 +223,12 @@ bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
> extern void omap242x_powerdomains_init(void);
> extern void omap243x_powerdomains_init(void);
> extern void omap3xxx_powerdomains_init(void);
> +extern void am33xx_powerdomains_init(void);
> extern void omap44xx_powerdomains_init(void);
>
> extern struct pwrdm_ops omap2_pwrdm_operations;
> extern struct pwrdm_ops omap3_pwrdm_operations;
> +extern struct pwrdm_ops am33xx_pwrdm_operations;
> extern struct pwrdm_ops omap4_pwrdm_operations;
>
> /* Common Internal functions used across OMAP rev's */
[...]
> diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
> new file mode 100644
> index 0000000..0fd5c6e
> --- /dev/null
> +++ b/arch/arm/mach-omap2/prm33xx.h
> @@ -0,0 +1,123 @@
> +/*
> + * AM33XX PRM instance offset macros
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __ARCH_ARM_MACH_OMAP2_PRM33XX_H
> +#define __ARCH_ARM_MACH_OMAP2_PRM33XX_H
> +
> +#include "prcm-common.h"
> +#include "prm.h"
> +
> +#define AM33XX_PRM_BASE 0x44E00000
> +
> +#define AM33XX_PRM_REGADDR(inst, reg) \
> + AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE + (inst) + (reg))
> +
> +
> +/* PRM instances */
> +#define AM33XX_PRM_OCP_SOCKET_MOD 0x0B00
> +#define AM33XX_PRM_PER_MOD 0x0C00
> +#define AM33XX_PRM_WKUP_MOD 0x0D00
> +#define AM33XX_PRM_MPU_MOD 0x0E00
> +#define AM33XX_PRM_DEVICE_MOD 0x0F00
> +#define AM33XX_PRM_RTC_MOD 0x1000
> +#define AM33XX_PRM_GFX_MOD 0x1100
> +#define AM33XX_PRM_CEFUSE_MOD 0x1200
> +
> +/* Register offsets (used from OMAP4) */
Probably could just include prm44xx.h and use OMAP4_PM_... instead.
> +#define AM33XX_PM_PWSTCTRL 0x0000
> +#define AM33XX_PM_PWSTST 0x0004
However, since thes are just dummy offsets into a "fixup" table anyways,
maybe it's best to use use 0 and 1 here and have a comment here to that
effect. Otherwise, it's a bit confusing since one would assume these
are actual register offsets.
[...]
> diff --git a/arch/arm/mach-omap2/prminst33xx.c b/arch/arm/mach-omap2/prminst33xx.c
> new file mode 100644
> index 0000000..88382ba
> --- /dev/null
> +++ b/arch/arm/mach-omap2/prminst33xx.c
> @@ -0,0 +1,74 @@
> +/*
> + * AM33XX PRM instance functions
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/errno.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +
> +#include <plat/common.h>
> +
> +#include "prm33xx.h"
> +#include "prminst33xx.h"
> +#include "prm-regbits-33xx.h"
> +
> +#define AM33XX_PRM_MOD_SIZE 0x100
> +#define AM33XX_PRM_MOD_START AM33XX_PRM_PER_MOD
> +#define PRM_REG_SZ 0x4
> +
> +/*
> + * PRM Offsets are screwed up, and they are not consistent across modules.
> + * Below are the offsets for PWRSTCTRL and PWRSTST for respective modules.
> + */
> +static u16 off_fixup[][2] = {
> + { 0xC, 0x8 }, /* AM33XX_PRM_PER_MOD */
> + { 0x4, 0x8 }, /* AM33XX_PRM_WKUP_MOD */
> + { 0x0, 0x4 }, /* AM33XX_PRM_MPU_MOD */
> + /* XXX: PRM_DEVICE: offsets are invalid for powerdomain*/
> + { 0x0, 0x0 }, /* AM33XX_PRM_DEVICE_MOD */
> + { 0x0, 0x4 }, /* AM33XX_PRM_RTC_MOD */
> + { 0x0, 0x10 }, /* AM33XX_PRM_GFX_MOD */
> + { 0x0, 0x4 }, /* AM33XX_PRM_CEFUSE_MOD */
> +};
Please use the #define values from prm-regbits...h
[...]
Kevin
^ permalink raw reply
* Re: [PATCH 02/10] powerpc: Consolidate mpic_alloc() OF address translation
From: Paul Mackerras @ 2011-12-01 1:04 UTC (permalink / raw)
To: Kyle Moffett; +Cc: linuxppc-dev
In-Reply-To: <1322593117-29938-3-git-send-email-Kyle.D.Moffett@boeing.com>
On Tue, Nov 29, 2011 at 01:58:29PM -0500, Kyle Moffett wrote:
> diff --git a/arch/powerpc/platforms/powermac/pic.c b/arch/powerpc/platforms/powermac/pic.c
> index 901bfbd..44f9774 100644
> --- a/arch/powerpc/platforms/powermac/pic.c
> +++ b/arch/powerpc/platforms/powermac/pic.c
> @@ -498,15 +498,10 @@ static struct mpic * __init pmac_setup_one_mpic(struct device_node *np,
> int master)
> {
> const char *name = master ? " MPIC 1 " : " MPIC 2 ";
> - struct resource r;
> struct mpic *mpic;
> unsigned int flags = master ? MPIC_PRIMARY : 0;
> int rc;
>
> - rc = of_address_to_resource(np, 0, &r);
> - if (rc)
> - return NULL;
> -
This gets me an unused variable warning, which because we compile
arch/powerpc with -Werror is fatal:
CC arch/powerpc/platforms/powermac/pic.o
/home/paulus/kernel/kvm-merge/arch/powerpc/platforms/powermac/pic.c: In function ‘pmac_setup_one_mpic’:
/home/paulus/kernel/kvm-merge/arch/powerpc/platforms/powermac/pic.c:491:6: error: unused variable ‘rc’ [-Werror=unused-variable]
cc1: all warnings being treated as errors
Need to remove the declaration of rc as well.
Paul.
^ permalink raw reply
* RE: [PATCH 2/2] ACPICA: support Generic Address Structure bit_offset in acpi_read/write
From: Luck, Tony @ 2011-12-01 1:03 UTC (permalink / raw)
To: Huang, Ying
Cc: Rafael J. Wysocki, Russell King, Bjorn Helgaas, Thomas Renninger,
Len Brown, Moore, Robert, linux-acpi@vger.kernel.org,
bondd@us.ibm.com, Myron Stowe
In-Reply-To: <1322701065.4849.69.camel@yhuang-dev>
> In the original acpi_read/write, we just call ioremap blindly, so the
> code in the below patch will not introduce new issue for ia64. Do you
> agree?
See arch/ia64/mm/ioremap.c ... ioremap() on ia64 is smart and looks
at attributes and makes new mapping match existing ones
That doesn't deal with long-lived mappings and changes that I just
mentioned in last e-mail - but it does mean that callers of ioremap()
don't need to worry ... they can call "blindly".
-Tony
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.