* Re: [Qemu-devel] Question about intermediate code generation in qemu (tcg)
From: Carter Cheng @ 2011-10-24 9:59 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel
In-Reply-To: <CAFEAcA-Hja+bSoDy6ypQx3vsGbZS9L1gdz6UrM8FR5XbFhOq_w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
Thanks Peter.
On Mon, Oct 24, 2011 at 7:39 PM, Peter Maydell <peter.maydell@linaro.org>wrote:
> On 24 October 2011 07:46, Carter Cheng <cartercheng@gmail.com> wrote:
> > I was wondering if someone could help me understand some aspects of the
> > current qemu code generation routines. How are floating point and SSE ops
> > currently handled? I do not see specific tcg routines for these cases(the
> > README seems to indicate that FP and vector ops are not handled using the
> > current IL).
>
> FP instructions are generally turned into code which calls out to
> a "helper function" written in C which emulates the floating point
> arithmetic -- see target-i386/op_helper.c for the x87 ops and
> target-i386/ops_sse.h for the SSE ops. (Some simple arithmetic
> vector ops might be done by generating inline code; ARM does this
> but I haven't checked target-i386.) IEEE arithmetic emulation
> is done in fpu/ but you probably don't need to look at the actual
> implementation...
>
> In the TCG intermediate representation there's no special support
> for float/double types -- they're just passed around as i32/i64.
>
> -- PMM
>
[-- Attachment #2: Type: text/html, Size: 1589 bytes --]
^ permalink raw reply
* qemu-kvm guest which won't 'cont' (emulation failure?)
From: Chris Webb @ 2011-10-24 10:00 UTC (permalink / raw)
To: qemu-devel, kvm
I have a qemu-kvm guest (apparently a Ubuntu 11.04 x86-64 install) which has
stopped and refuses to continue:
(qemu) info status
VM status: paused
(qemu) cont
(qemu) info status
VM status: paused
The host is running linux 2.6.39.2 with qemu-kvm 0.14.1 on 24-core Opteron
6176 box, and has nine other 2GB production guests on it running absolutely
fine.
It's been a while since I've seen one of these. When I last saw a cluster of
them, they were emulation failures (big real mode instructions, maybe?). I
also remember a message about abnormal exit in the dmesg previously, but I
don't have that here. This time, there is no host kernel output at all, just
the paused guest.
I have qemu monitor access and can even strace the relevant qemu process if
necessary: is it possible to use this to diagnose what's caused this guest
to stop, e.g. the unsupported instruction if it's an emulation failure?
Cheers,
Chris.
^ permalink raw reply
* [Qemu-devel] qemu-kvm guest which won't 'cont' (emulation failure?)
From: Chris Webb @ 2011-10-24 10:00 UTC (permalink / raw)
To: qemu-devel, kvm
I have a qemu-kvm guest (apparently a Ubuntu 11.04 x86-64 install) which has
stopped and refuses to continue:
(qemu) info status
VM status: paused
(qemu) cont
(qemu) info status
VM status: paused
The host is running linux 2.6.39.2 with qemu-kvm 0.14.1 on 24-core Opteron
6176 box, and has nine other 2GB production guests on it running absolutely
fine.
It's been a while since I've seen one of these. When I last saw a cluster of
them, they were emulation failures (big real mode instructions, maybe?). I
also remember a message about abnormal exit in the dmesg previously, but I
don't have that here. This time, there is no host kernel output at all, just
the paused guest.
I have qemu monitor access and can even strace the relevant qemu process if
necessary: is it possible to use this to diagnose what's caused this guest
to stop, e.g. the unsupported instruction if it's an emulation failure?
Cheers,
Chris.
^ permalink raw reply
* [PATCH] arm/tegra: Add device-tree support for TrimSlice board
From: Stephen Warren @ 2011-10-24 10:01 UTC (permalink / raw)
To: Olof Johansson, Colin Cross
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Stephen Warren
* Add device-tree file for TrimSlice
* Add that to the list of .dts files to build
* Update board-dt.c to recognize TrimSlice board name
Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/tegra-trimslice.dts | 38 +++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 3 ++
3 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-trimslice.dts
diff --git a/arch/arm/boot/dts/tegra-trimslice.dts b/arch/arm/boot/dts/tegra-trimslice.dts
new file mode 100644
index 0000000..d3d0d20
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-trimslice.dts
@@ -0,0 +1,38 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "Compulab TrimSlice board";
+ compatible = "compulab,trimslice", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk0p1 rw rootwait";
+ };
+
+ memory@0 {
+ reg = < 0x00000000 0x40000000 >;
+ };
+
+ i2c@7000c000 {
+ clock-frequency = <400000>;
+ };
+
+ i2c@7000c400 {
+ clock-frequency = <400000>;
+ };
+
+ i2c@7000c500 {
+ clock-frequency = <400000>;
+ };
+
+ serial@70006000 {
+ clock-frequency = < 216000000 >;
+ };
+
+ sdhci@c8000600 {
+ cd-gpios = <&gpio 121 0>;
+ wp-gpios = <&gpio 122 0>;
+ };
+};
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index bd12c9f..9f177a4 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -4,4 +4,5 @@ initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
+dtb-$(CONFIG_MACH_TRIMSLICE) += tegra-trimslice.dtb
dtb-$(CONFIG_MACH_VENTANA) += tegra-ventana.dtb
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 0d22212..9ac4ed7 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -47,6 +47,7 @@
void harmony_pinmux_init(int is_dt);
void seaboard_pinmux_init(int is_dt);
+void trimslice_pinmux_init(int is_dt);
void ventana_pinmux_init(int is_dt);
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
@@ -84,6 +85,7 @@ static struct {
char *machine;
void (*init)(int is_dt);
} pinmux_configs[] = {
+ { "compulab,trimslice", trimslice_pinmux_init },
{ "nvidia,harmony", harmony_pinmux_init },
{ "nvidia,seaboard", seaboard_pinmux_init },
{ "nvidia,ventana", ventana_pinmux_init },
@@ -120,6 +122,7 @@ static void __init tegra_dt_init(void)
}
static const char * tegra_dt_board_compat[] = {
+ "compulab,trimslice",
"nvidia,harmony",
"nvidia,seaboard",
"nvidia,ventana",
--
1.7.4.1
^ permalink raw reply related
* [PATCH] arm/tegra: Add device-tree support for TrimSlice board
From: Stephen Warren @ 2011-10-24 10:01 UTC (permalink / raw)
To: linux-arm-kernel
* Add device-tree file for TrimSlice
* Add that to the list of .dts files to build
* Update board-dt.c to recognize TrimSlice board name
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/boot/dts/tegra-trimslice.dts | 38 +++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 3 ++
3 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-trimslice.dts
diff --git a/arch/arm/boot/dts/tegra-trimslice.dts b/arch/arm/boot/dts/tegra-trimslice.dts
new file mode 100644
index 0000000..d3d0d20
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-trimslice.dts
@@ -0,0 +1,38 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "Compulab TrimSlice board";
+ compatible = "compulab,trimslice", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk0p1 rw rootwait";
+ };
+
+ memory at 0 {
+ reg = < 0x00000000 0x40000000 >;
+ };
+
+ i2c at 7000c000 {
+ clock-frequency = <400000>;
+ };
+
+ i2c at 7000c400 {
+ clock-frequency = <400000>;
+ };
+
+ i2c at 7000c500 {
+ clock-frequency = <400000>;
+ };
+
+ serial at 70006000 {
+ clock-frequency = < 216000000 >;
+ };
+
+ sdhci at c8000600 {
+ cd-gpios = <&gpio 121 0>;
+ wp-gpios = <&gpio 122 0>;
+ };
+};
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index bd12c9f..9f177a4 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -4,4 +4,5 @@ initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
+dtb-$(CONFIG_MACH_TRIMSLICE) += tegra-trimslice.dtb
dtb-$(CONFIG_MACH_VENTANA) += tegra-ventana.dtb
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 0d22212..9ac4ed7 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -47,6 +47,7 @@
void harmony_pinmux_init(int is_dt);
void seaboard_pinmux_init(int is_dt);
+void trimslice_pinmux_init(int is_dt);
void ventana_pinmux_init(int is_dt);
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
@@ -84,6 +85,7 @@ static struct {
char *machine;
void (*init)(int is_dt);
} pinmux_configs[] = {
+ { "compulab,trimslice", trimslice_pinmux_init },
{ "nvidia,harmony", harmony_pinmux_init },
{ "nvidia,seaboard", seaboard_pinmux_init },
{ "nvidia,ventana", ventana_pinmux_init },
@@ -120,6 +122,7 @@ static void __init tegra_dt_init(void)
}
static const char * tegra_dt_board_compat[] = {
+ "compulab,trimslice",
"nvidia,harmony",
"nvidia,seaboard",
"nvidia,ventana",
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH V2 10/11] libxl_qmp, Introduce libxl__qmp_pci_add.
From: Ian Campbell @ 2011-10-24 10:01 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Xen Devel, Stefano Stabellini
In-Reply-To: <1319133573-25891-11-git-send-email-anthony.perard@citrix.com>
On Thu, 2011-10-20 at 18:59 +0100, Anthony PERARD wrote:
> This function insert a PCI passthrough device in qemu.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> tools/libxl/libxl_internal.h | 4 ++
> tools/libxl/libxl_qmp.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 105 insertions(+), 0 deletions(-)
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 849b251..09f618f 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -119,6 +119,9 @@ typedef struct {
> } libxl__device;
>
> #define XC_PCI_BDF "0x%x, 0x%x, 0x%x, 0x%x"
> +#define PCI_DEVFN(slot, func) ((((slot) & 0x1f) << 3) | ((func) & 0x07))
> +#define PCI_SLOT(devfn) (((devfn) >> 3) & 0x1f)
> +#define PCI_FUNC(devfn) ((devfn) & 0x07)
> #define AUTO_PHP_SLOT 0x100
> #define SYSFS_PCI_DEV "/sys/bus/pci/devices"
> #define SYSFS_PCIBACK_DRIVER "/sys/bus/pci/drivers/pciback"
> @@ -444,6 +447,7 @@ _hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx,
> uint32_t domid);
> /* ask to QEMU the serial port information and store it in xenstore. */
> _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
> +_hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
> /* close and free the QMP handler */
> _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
> /* remove the socket file, if the file has already been removed,
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 547cd53..bce7e16 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -41,6 +41,7 @@
> */
>
> #define QMP_RECEIVE_BUFFER_SIZE 4096
> +#define PCI_PT_QDEV_ID "pci-pt-%02x_%02x.%01x"
>
> typedef int (*qmp_callback_t)(libxl__qmp_handler *qmp,
> const libxl__json_object *tree,
> @@ -619,6 +620,112 @@ int libxl__qmp_query_serial(libxl__qmp_handler *qmp)
> return rc;
> }
>
> +static int pci_add_callback(libxl__qmp_handler *qmp,
> + const libxl__json_object *response, void *opaque)
> +{
> + libxl_device_pci *pcidev = opaque;
> + const libxl__json_object *bus = NULL;
> + libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> + int i, j, rc = -1;
> + char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
> + pcidev->bus, pcidev->dev, pcidev->func);
> +
> + for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
> + const libxl__json_object *devices = NULL;
> + const libxl__json_object *device = NULL;
> + const libxl__json_object *o = NULL;
> + const char *id = NULL;
> +
> + devices = libxl__json_map_get("devices", bus, JSON_ARRAY);
> +
> + for (j = 0; (device = libxl__json_array_get(devices, j)); j++) {
> + o = libxl__json_map_get("qdev_id", device, JSON_STRING);
> + id = libxl__json_object_get_string(o);
> +
> + if (id && strcmp(asked_id, id) == 0) {
> + int dev_slot, dev_func;
> +
> + o = libxl__json_map_get("slot", device, JSON_INTEGER);
> + if (!o)
> + goto out;
> + dev_slot = libxl__json_object_get_integer(o);
> + o = libxl__json_map_get("function", device, JSON_INTEGER);
> + if (!o)
> + goto out;
> + dev_func = libxl__json_object_get_integer(o);
> +
> + pcidev->vdevfn = PCI_DEVFN(dev_slot, dev_func);
> +
> + rc = 0;
> + goto out;
> + }
> + }
> + }
> +
> +
> +out:
> + libxl__free_all(&gc);
> + return rc;
> +}
> +
> +int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
> +{
> + libxl__qmp_handler *qmp = NULL;
> + flexarray_t *parameters = NULL;
> + libxl_key_value_list args = NULL;
> + char *hostaddr = NULL;
> + int rc = 0;
> + qmp_request_handle request = {
> + .callback = pci_add_callback,
> + .opaque = pcidev,
> + };
> +
> + qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> + if (!qmp)
> + return -1;
> +
> + hostaddr = libxl__sprintf(gc, "%04x:%02x:%02x.%01x", pcidev->domain,
> + pcidev->bus, pcidev->dev, pcidev->func);
> + if (!hostaddr)
> + return -1;
> +
> + parameters = flexarray_make(6, 1);
> + flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
> + flexarray_append_pair(parameters, "id",
> + libxl__sprintf(gc, PCI_PT_QDEV_ID,
> + pcidev->bus, pcidev->dev,
> + pcidev->func));
> + flexarray_append_pair(parameters, "hostaddr", hostaddr);
> + if (pcidev->vdevfn) {
> + flexarray_append_pair(parameters, "addr",
> + libxl__sprintf(gc, "%x.%x",
> + PCI_SLOT(pcidev->vdevfn),
> + PCI_FUNC(pcidev->vdevfn)));
> + }
> + args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
> + if (!args)
> + return -1;
> +
> + rc = qmp_synchronous_send(qmp, "device_add", &args, NULL, qmp->timeout);
> + if (rc == 0) {
> + rc = qmp_synchronous_send(qmp, "query-pci", NULL,
> + &request, qmp->timeout);
> + if (rc == 0) {
> + rc = request.rc;
> + }
Is every caller going to want this behaviour? Perhaps it belongs in
qmp_sync..._send?
> + }
> +
> + flexarray_free(parameters);
> + libxl__qmp_close(qmp);
> + return rc;
> +}
> +
> int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
> {
> libxl__qmp_handler *qmp = NULL;
^ permalink raw reply
* Re: getroot for ZFS without libzfs?
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-10-24 10:01 UTC (permalink / raw)
To: grub-devel
In-Reply-To: <CAOfDtXOFuXCsPQ3A4MrYz1+XjgQOECZqs009ackzi4V2r5=SYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 948 bytes --]
On 15.10.2011 18:59, Robert Millan wrote:
> Hi,
>
> Please test / comment on proof-of-concept attached patch, it gets rid
> of libzfs dependency in GRUB.
>
It looks like this patch would map all zpools with the same name to the
same device. That's a problem since system may have several
identically-named pools or misdetect a pool somewhere where there is none.
> The approach is to implement a disk abstraction, like LVM does, but in
> this case a very simple one (passthrough). Then grub-probe et al can
> obtain their information from this abstraction layer like they
> currently do with LVM or mdRAID, but they don't need the device node
> list anymore (since it's filled with a full scan, as with LVM).
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
^ permalink raw reply
* Re: [PATCH RFC V2 4/5] kvm guest : Added configuration support to enable debug information for KVM Guests
From: Sasha Levin @ 2011-10-24 10:01 UTC (permalink / raw)
To: Raghavendra K T
Cc: Peter Zijlstra, Virtualization, H. Peter Anvin,
Jeremy Fitzhardinge, Dave Jiang, KVM, x86, Ingo Molnar,
Avi Kivity, Rik van Riel, Stefano Stabellini, Srivatsa Vaddagiri,
Xen, Sedat Dilek, Thomas Gleixner, Yinghai Lu,
Konrad Rzeszutek Wilk, Greg Kroah-Hartman, LKML, Suzuki Poulose
In-Reply-To: <20111023190700.16364.7548.sendpatchset@oc5400248562.ibm.com>
On Mon, 2011-10-24 at 00:37 +0530, Raghavendra K T wrote:
> Added configuration support to enable debug information
> for KVM Guests in debugfs
>
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1f03f82..ed34269 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -562,6 +562,15 @@ config KVM_GUEST
> This option enables various optimizations for running under the KVM
> hypervisor.
>
> +config KVM_DEBUG_FS
> + bool "Enable debug information for KVM Guests in debugfs"
> + depends on KVM_GUEST
Shouldn't it depend on DEBUG_FS as well?
> + default n
> + ---help---
> + This option enables collection of various statistics for KVM guest.
> + Statistics are displayed in debugfs filesystem. Enabling this option
> + may incur significant overhead.
> +
> source "arch/x86/lguest/Kconfig"
>
> config PARAVIRT
--
Sasha.
^ permalink raw reply
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Sasha Levin @ 2011-10-24 10:01 UTC (permalink / raw)
To: Raghavendra K T
Cc: KVM, Peter Zijlstra, Virtualization, H. Peter Anvin,
Jeremy Fitzhardinge, Dave Jiang, x86, Ingo Molnar, Avi Kivity,
Rik van Riel, Stefano Stabellini, Srivatsa Vaddagiri, Xen,
Sedat Dilek, Thomas Gleixner, Yinghai Lu, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, LKML, Suzuki Poulose
In-Reply-To: <20111023190558.16364.2136.sendpatchset@oc5400248562.ibm.com>
On Mon, 2011-10-24 at 00:35 +0530, Raghavendra K T wrote:
> Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
>
> KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or it
> is woken up because of an event like interrupt.
>
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu.
>
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_WAIT_FOR_KICK/KVM_CAP_WAIT_FOR_KICK.
>
> Qemu needs a corresponding patch to pass up the presence of this feature to
> guest via cpuid. Patch to qemu will be sent separately.
>
> There is no Xen/KVM hypercall interface to await kick from.
>
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..2874c19 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
> #define KVM_FEATURE_CLOCKSOURCE 0
> #define KVM_FEATURE_NOP_IO_DELAY 1
> #define KVM_FEATURE_MMU_OP 2
> +
> /* This indicates that the new set of kvmclock msrs
> * are available. The use of 0x11 and 0x12 is deprecated
> */
> #define KVM_FEATURE_CLOCKSOURCE2 3
> #define KVM_FEATURE_ASYNC_PF 4
> #define KVM_FEATURE_STEAL_TIME 5
> +#define KVM_FEATURE_WAIT_FOR_KICK 6
>
> /* The last 8 bits are used to indicate how to interpret the flags field
> * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 84a28ea..b43fd18 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2077,6 +2077,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> case KVM_CAP_XSAVE:
> case KVM_CAP_ASYNC_PF:
> case KVM_CAP_GET_TSC_KHZ:
> + case KVM_CAP_WAIT_FOR_KICK:
> r = 1;
> break;
> case KVM_CAP_COALESCED_MMIO:
> @@ -2548,7 +2549,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
> (1 << KVM_FEATURE_NOP_IO_DELAY) |
> (1 << KVM_FEATURE_CLOCKSOURCE2) |
> (1 << KVM_FEATURE_ASYNC_PF) |
> - (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> + (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> + (1 << KVM_FEATURE_WAIT_FOR_KICK);
>
> if (sched_info_on())
> entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> @@ -5231,6 +5233,61 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> return 1;
> }
>
> +/*
> + * kvm_pv_wait_for_kick_op : Block until kicked by either a KVM_HC_KICK_CPU
> + * hypercall or a event like interrupt.
> + *
> + * @vcpu : vcpu which is blocking.
> + */
> +static void kvm_pv_wait_for_kick_op(struct kvm_vcpu *vcpu)
> +{
> + DEFINE_WAIT(wait);
> +
> + /*
> + * Blocking on vcpu->wq allows us to wake up sooner if required to
> + * service pending events (like interrupts).
> + *
> + * Also set state to TASK_INTERRUPTIBLE before checking vcpu->kicked to
> + * avoid racing with kvm_pv_kick_cpu_op().
> + */
> + prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
> +
> + /*
> + * Somebody has already tried kicking us. Acknowledge that
> + * and terminate the wait.
> + */
> + if (vcpu->kicked) {
> + vcpu->kicked = 0;
> + goto end_wait;
> + }
> +
> + /* Let's wait for either KVM_HC_KICK_CPU or someother event
> + * to wake us up.
> + */
> +
> + srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> + schedule();
> + vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
> +
> +end_wait:
> + finish_wait(&vcpu->wq, &wait);
> +}
> +
> +/*
> + * kvm_pv_kick_cpu_op: Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> +
> + if (vcpu) {
> + vcpu->kicked = 1;
I'm not sure about it, but maybe we want a memory barrier over here?
> + wake_up_interruptible(&vcpu->wq);
> + }
> +}
--
Sasha.
^ permalink raw reply
* Re: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
From: Michael S. Tsirkin @ 2011-10-24 10:02 UTC (permalink / raw)
To: Rusty Russell
Cc: Tejun Heo, virtualization, kvm, linux-kernel, Jens Axboe,
Greg Kroah-Hartman
In-Reply-To: <20111019101220.GE25794@redhat.com>
On Wed, Oct 19, 2011 at 12:12:20PM +0200, Michael S. Tsirkin wrote:
> On Thu, Jun 09, 2011 at 06:41:56AM -0400, Mark Wu wrote:
> > On 06/09/2011 05:14 AM, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Thu, Jun 09, 2011 at 08:51:05AM +0930, Rusty Russell wrote:
> > >> On Wed, 08 Jun 2011 09:08:29 -0400, Mark Wu <dwu@redhat.com> wrote:
> > >>> Hi Rusty,
> > >>> Yes, I can't figure out an instance of disk probing in parallel either, but as
> > >>> per the following commit, I think we still need use lock for safety. What's your opinion?
> > >>>
> > >>> commit 4034cc68157bfa0b6622efe368488d3d3e20f4e6
> > >>> Author: Tejun Heo <tj@kernel.org>
> > >>> Date: Sat Feb 21 11:04:45 2009 +0900
> > >>>
> > >>> [SCSI] sd: revive sd_index_lock
> > >>>
> > >>> Commit f27bac2761cab5a2e212dea602d22457a9aa6943 which converted sd to
> > >>> use ida instead of idr incorrectly removed sd_index_lock around id
> > >>> allocation and free. idr/ida do have internal locks but they protect
> > >>> their free object lists not the allocation itself. The caller is
> > >>> responsible for that. This missing synchronization led to the same id
> > >>> being assigned to multiple devices leading to oops.
> > >>
> > >> I'm confused. Tejun, Greg, anyone can probes happen in parallel?
> > >>
> > >> If so, I'll have to review all my drivers.
> > >
> > > Unless async is explicitly used, probe happens sequentially. IOW, if
> > > there's no async_schedule() call, things won't happen in parallel.
> > > That said, I think it wouldn't be such a bad idea to protect ida with
> > > spinlock regardless unless the probe code explicitly requires
> > > serialization.
> > >
> > > Thanks.
> > >
> > Since virtio blk driver doesn't use async probe, it needn't use spinlock to protect ida.
> > So remove the lock from patch.
> >
> > >From fbb396df9dbf8023f1b268be01b43529a3993d57 Mon Sep 17 00:00:00 2001
> > From: Mark Wu <dwu@redhat.com>
> > Date: Thu, 9 Jun 2011 06:34:07 -0400
> > Subject: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
> >
> > Current index allocation in virtio-blk is based on a monotonically
> > increasing variable "index". It could cause some confusion about disk
> > name in the case of hot-plugging disks. And it's impossible to find the
> > lowest available index by just maintaining a simple index. So it's
> > changed to use ida to allocate index via referring to the index
> > allocation in scsi disk.
> >
> > Signed-off-by: Mark Wu <dwu@redhat.com>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> This got lost in the noise and missed 3.1 which is unfortunate.
> How about we apply this as is and look at cleanups as a next step?
Rusty, any opinion on merging this for 3.2?
I expect merge window will open right after the summit,
so need to decide soon ...
> > ---
> > drivers/block/virtio_blk.c | 28 +++++++++++++++++++++++-----
> > 1 files changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > index 079c088..bf81ab6 100644
> > --- a/drivers/block/virtio_blk.c
> > +++ b/drivers/block/virtio_blk.c
> > @@ -8,10 +8,13 @@
> > #include <linux/scatterlist.h>
> > #include <linux/string_helpers.h>
> > #include <scsi/scsi_cmnd.h>
> > +#include <linux/idr.h>
> >
> > #define PART_BITS 4
> >
> > -static int major, index;
> > +static int major;
> > +static DEFINE_IDA(vd_index_ida);
> > +
> > struct workqueue_struct *virtblk_wq;
> >
> > struct virtio_blk
> > @@ -23,6 +26,7 @@ struct virtio_blk
> >
> > /* The disk structure for the kernel. */
> > struct gendisk *disk;
> > + u32 index;
> >
> > /* Request tracking. */
> > struct list_head reqs;
> > @@ -343,12 +347,23 @@ static int __devinit virtblk_probe(struct virtio_device *vdev)
> > struct request_queue *q;
> > int err;
> > u64 cap;
> > - u32 v, blk_size, sg_elems, opt_io_size;
> > + u32 v, blk_size, sg_elems, opt_io_size, index;
> > u16 min_io_size;
> > u8 physical_block_exp, alignment_offset;
> >
> > - if (index_to_minor(index) >= 1 << MINORBITS)
> > - return -ENOSPC;
> > + do {
> > + if (!ida_pre_get(&vd_index_ida, GFP_KERNEL))
> > + return -ENOMEM;
> > + err = ida_get_new(&vd_index_ida, &index);
> > + } while (err == -EAGAIN);
> > +
> > + if (err)
> > + return err;
> > +
> > + if (index_to_minor(index) >= 1 << MINORBITS) {
> > + err = -ENOSPC;
> > + goto out_free_index;
> > + }
> >
> > /* We need to know how many segments before we allocate. */
> > err = virtio_config_val(vdev, VIRTIO_BLK_F_SEG_MAX,
> > @@ -421,7 +436,7 @@ static int __devinit virtblk_probe(struct virtio_device *vdev)
> > vblk->disk->private_data = vblk;
> > vblk->disk->fops = &virtblk_fops;
> > vblk->disk->driverfs_dev = &vdev->dev;
> > - index++;
> > + vblk->index = index;
> >
> > /* configure queue flush support */
> > if (virtio_has_feature(vdev, VIRTIO_BLK_F_FLUSH))
> > @@ -516,6 +531,8 @@ out_free_vq:
> > vdev->config->del_vqs(vdev);
> > out_free_vblk:
> > kfree(vblk);
> > +out_free_index:
> > + ida_remove(&vd_index_ida, index);
> > out:
> > return err;
> > }
> > @@ -538,6 +555,7 @@ static void __devexit virtblk_remove(struct virtio_device *vdev)
> > mempool_destroy(vblk->pool);
> > vdev->config->del_vqs(vdev);
> > kfree(vblk);
> > + ida_remove(&vd_index_ida, vblk->index);
> > }
> >
> > static const struct virtio_device_id id_table[] = {
> > --
> > 1.7.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" 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
* Re: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
From: Jens Axboe @ 2011-10-24 10:02 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, Tejun Heo, virtualization, kvm, linux-kernel,
Greg Kroah-Hartman
In-Reply-To: <20111024100238.GA27444@redhat.com>
On 2011-10-24 12:02, Michael S. Tsirkin wrote:
> On Wed, Oct 19, 2011 at 12:12:20PM +0200, Michael S. Tsirkin wrote:
>> On Thu, Jun 09, 2011 at 06:41:56AM -0400, Mark Wu wrote:
>>> On 06/09/2011 05:14 AM, Tejun Heo wrote:
>>>> Hello,
>>>>
>>>> On Thu, Jun 09, 2011 at 08:51:05AM +0930, Rusty Russell wrote:
>>>>> On Wed, 08 Jun 2011 09:08:29 -0400, Mark Wu <dwu@redhat.com> wrote:
>>>>>> Hi Rusty,
>>>>>> Yes, I can't figure out an instance of disk probing in parallel either, but as
>>>>>> per the following commit, I think we still need use lock for safety. What's your opinion?
>>>>>>
>>>>>> commit 4034cc68157bfa0b6622efe368488d3d3e20f4e6
>>>>>> Author: Tejun Heo <tj@kernel.org>
>>>>>> Date: Sat Feb 21 11:04:45 2009 +0900
>>>>>>
>>>>>> [SCSI] sd: revive sd_index_lock
>>>>>>
>>>>>> Commit f27bac2761cab5a2e212dea602d22457a9aa6943 which converted sd to
>>>>>> use ida instead of idr incorrectly removed sd_index_lock around id
>>>>>> allocation and free. idr/ida do have internal locks but they protect
>>>>>> their free object lists not the allocation itself. The caller is
>>>>>> responsible for that. This missing synchronization led to the same id
>>>>>> being assigned to multiple devices leading to oops.
>>>>>
>>>>> I'm confused. Tejun, Greg, anyone can probes happen in parallel?
>>>>>
>>>>> If so, I'll have to review all my drivers.
>>>>
>>>> Unless async is explicitly used, probe happens sequentially. IOW, if
>>>> there's no async_schedule() call, things won't happen in parallel.
>>>> That said, I think it wouldn't be such a bad idea to protect ida with
>>>> spinlock regardless unless the probe code explicitly requires
>>>> serialization.
>>>>
>>>> Thanks.
>>>>
>>> Since virtio blk driver doesn't use async probe, it needn't use spinlock to protect ida.
>>> So remove the lock from patch.
>>>
>>> >From fbb396df9dbf8023f1b268be01b43529a3993d57 Mon Sep 17 00:00:00 2001
>>> From: Mark Wu <dwu@redhat.com>
>>> Date: Thu, 9 Jun 2011 06:34:07 -0400
>>> Subject: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
>>>
>>> Current index allocation in virtio-blk is based on a monotonically
>>> increasing variable "index". It could cause some confusion about disk
>>> name in the case of hot-plugging disks. And it's impossible to find the
>>> lowest available index by just maintaining a simple index. So it's
>>> changed to use ida to allocate index via referring to the index
>>> allocation in scsi disk.
>>>
>>> Signed-off-by: Mark Wu <dwu@redhat.com>
>>
>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> This got lost in the noise and missed 3.1 which is unfortunate.
>> How about we apply this as is and look at cleanups as a next step?
>
> Rusty, any opinion on merging this for 3.2?
> I expect merge window will open right after the summit,
I can toss it into for-3.2/drivers, if there's consensus to do that now.
--
Jens Axboe
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Robert @ 2011-10-24 10:04 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
In-Reply-To: <4EA53424.6050803@domain.hid>
Dnia 24 października 2011 11:47 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a):
> On 10/24/2011 11:16 AM, Robert wrote:
> >
> >
> > Dnia 24 października 2011 10:33 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a):
> >
> >> On 10/24/2011 09:53 AM, Robert wrote:
> >>>
> >>>
> >>>
> >>> Dnia 20 września 2011 20:13 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a):
> >>>
> >>>> On 09/20/2011 07:26 PM, Robert wrote:
> >>>>> Can someone help me installing xenomai on panda?
> >>>>>
> >>>>> What should I do, to install xenomai on ubuntu host?
> >>>>> Download kernel from kernel.org and patch it with xenomai and adeos-patch, or download kernel from git repository, or download ubuntu image-omap4 via apt-get source?
> >>>>>
> >>>>> The last one would download 2.6.38 kernel, but there is no adeos patch for this version yet.
> >>>>> It is also possible to download 2.6.37-9, but the same problem.
> >>>>
> >>>> The upcoming xenomai 2.6.0 supports panda. It should be released real
> >>>> soon now, in the mean-time, you can try xenomai 2.6.0-rc3.
> >>>>
> >>>>
> >>>
> >>> Hi again,
> >>> I have downloaded xenomai 2.6.0-rc5, and kernel 2.6.38.8 from kernel.org to ubuntu 11.04 on pandaboard.
> >>> Patched it with adeos included in xeno package.
> >>>
> >>> Compiled the kernel, modules and copied uImage to boot partition.
> >>> After reboot i got the following dmesg | grep -i xeno:
> >>> user@domain.hid
> >>> [ 1.195556] I-pipe: Domain Xenomai registered.
> >>> [ 1.195587] Xenomai: hal/arm started.
> >>> [ 1.195861] Xenomai: scheduling class idle registered.
> >>> [ 1.195861] Xenomai: scheduling class rt registered.
> >>> [ 1.199798] Xenomai: real-time nucleus v2.6.0-rc5 (head) loaded.
> >>> [ 1.199798] Xenomai: debug mode enabled.
> >>> [ 1.590240] Xenomai: native skin init failed, code -19.
> >>> [ 1.590270] Xenomai: starting POSIX services.
> >>> [ 1.980804] Xenomai: POSIX skin init failed, code -19.
> >>> [ 2.371429] Xenomai: RTDM skin init failed, code -19.
> >>>
> >>> user@domain.hid
> >>> user@domain.hid
> >>> user@domain.hid
> >>>
> >>> user@domain.hid
> >>> /usr/xenomai/bin/xeno-test-run-wrapper: 19: source: not found
> >>> ./xeno-test failed: dead child 1238 not found!
> >>
> >> That is surprising, what shell do you use? Have you copied all files
> >> installed by xenomai on the board root filesystem?
> >
> > I'm using bash.
> > What do you mean, by all files? I just ran make and make install.
>
> I take it you are not cross-compiling then? Anyway, to understand the
> bug in xeno-test, you should try adding "set -x" in
> xeno-test-run-wrapper, on the second line.
+ script=./xeno-test
+ shift
+ source ./xeno-test
/usr/xenomai/bin/xeno-test-run-wrapper: 1: source: not found
./xeno-test failed: dead child 10486 not found!
> >
> >
> >>>
> >>> user@domain.hid
> >>> Xenomai: incompatible feature set
> >>> (userland requires "kuser_tsc fastsynch nosmp", kernel provides "sa1100 v6 eabi
> >>> kuser_tsc fastsynch smp", missing="nosmp").
> >>>
> >>> Should I disable smp in kernel config?
> >>
> >> That, or more likely enable smp in user-space configuration.
> >>
> > Now I try to compile without smp.
>
> I would recommend not to do that. SMP is better tested than !SMP. And
> anyway, it is a bit stupid to only use one core on the dual-core OMAP4.
>
>
I thought it may cause a problems. So, what to do now?
config file looks good?
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 10:05 UTC (permalink / raw)
To: Mark Brown
Cc: Grant Likely, Shawn Guo, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024091924.GA6148@opensource.wolfsonmicro.com>
On Monday 24 October 2011 02:49 PM, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
>
>> How about the driver passing the of_node to be associated with the
>> regulator, as part of regulator_desc, to the regulator core,
>> instead of this complete DT search and the restriction of having
>> to match DT node names with names in regulator_desc.
>
> regulator_desc should be const so that we handle multiple instances of
> the same device nicely. We could pass the information in as an argument
> I guess.
Ok, will do. The only downside being that all existing users would
need to be changed.
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024091924.GA6148@opensource.wolfsonmicro.com>
On Monday 24 October 2011 02:49 PM, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
>
>> How about the driver passing the of_node to be associated with the
>> regulator, as part of regulator_desc, to the regulator core,
>> instead of this complete DT search and the restriction of having
>> to match DT node names with names in regulator_desc.
>
> regulator_desc should be const so that we handle multiple instances of
> the same device nicely. We could pass the information in as an argument
> I guess.
Ok, will do. The only downside being that all existing users would
need to be changed.
^ permalink raw reply
* [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> ?include/linux/of.h | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> ?}
>
> ?#define of_match_ptr(_ptr) ? ? NULL
> +#define of_match_node(_matches, _node) NULL
Where possible, I prefer to code to be written in C, not PP. :-)
static inline please.
g.
^ permalink raw reply
* Re: [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 10:06 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: devicetree-discuss, linux-kernel, linux-arm-kernel
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> include/linux/of.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> }
>
> #define of_match_ptr(_ptr) NULL
> +#define of_match_node(_matches, _node) NULL
Where possible, I prefer to code to be written in C, not PP. :-)
static inline please.
g.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024094203.GI9893@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2011 at 11:36:01AM +0200, Ulf Hansson wrote:
>> Russell King - ARM Linux wrote:
>>> I repeat: if you cut power to the card, you have to re-initialize it.
>>> Re-initialization takes quite a bit of time to re-detect and setup
>>> the card. You'd also need to re-configure things like the transfer
>>> mode and so forth.
>> Right now host->vcc (vmmc) regulator is controlling the power to card.
>> Not the MCIPWR register!
>
> Maybe for you, but that's not the case on all platforms.
>
> You *really* need to get out of the idea that just because your
> implementation works one way that everything works that way. You're
> working on a cross-SoC cross-platform driver, and you need to take
> account of how other platforms work.
Sorry for being a pain in the ass. :-) I am thinking of the above, even
if it not seems like that.
>
> In that case, there *are* platforms which the MCIPWR register does
> indeed control power to the card - and setting this to zero _will_
> power down the card.
>
>> I would be very surprised if any hardware has this kind of setup, that
>> the PL180 itself controls a regulator.
>
> ARM dev boards all use the MCIPWR bits to control an external power
> switch - there's no adjustment of the voltage except via soldered
> links on the board.
That explains it!
My believe was that since the bits for controlling the voltage levels
etc was not used (which is replaced with directions bits for
ST-version), this functionality was not used either.
Could you maybe elaborate a bit of how the power is controlled in the
ARM dev boards? Would it be possible to control such a switch in "GPIO"
manner instead? For example via the vdd_handler or similar?
I will also think if and see if is feasible to re-design and see if this
hole feature can be controlled by the variant struct instead. My feeling
is although it can be kind of messy. But let's see...
BR
Ulf Hansson
^ permalink raw reply
* Re: [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 10:06 UTC (permalink / raw)
To: Nicolas Ferre
Cc: robherring2, linux-kernel, linux-arm-kernel, devicetree-discuss
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> include/linux/of.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> }
>
> #define of_match_ptr(_ptr) NULL
> +#define of_match_node(_matches, _node) NULL
Where possible, I prefer to code to be written in C, not PP. :-)
static inline please.
g.
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 10:06 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lee Jones
In-Reply-To: <20111024094203.GI9893@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2011 at 11:36:01AM +0200, Ulf Hansson wrote:
>> Russell King - ARM Linux wrote:
>>> I repeat: if you cut power to the card, you have to re-initialize it.
>>> Re-initialization takes quite a bit of time to re-detect and setup
>>> the card. You'd also need to re-configure things like the transfer
>>> mode and so forth.
>> Right now host->vcc (vmmc) regulator is controlling the power to card.
>> Not the MCIPWR register!
>
> Maybe for you, but that's not the case on all platforms.
>
> You *really* need to get out of the idea that just because your
> implementation works one way that everything works that way. You're
> working on a cross-SoC cross-platform driver, and you need to take
> account of how other platforms work.
Sorry for being a pain in the ass. :-) I am thinking of the above, even
if it not seems like that.
>
> In that case, there *are* platforms which the MCIPWR register does
> indeed control power to the card - and setting this to zero _will_
> power down the card.
>
>> I would be very surprised if any hardware has this kind of setup, that
>> the PL180 itself controls a regulator.
>
> ARM dev boards all use the MCIPWR bits to control an external power
> switch - there's no adjustment of the voltage except via soldered
> links on the board.
That explains it!
My believe was that since the bits for controlling the voltage levels
etc was not used (which is replaced with directions bits for
ST-version), this functionality was not used either.
Could you maybe elaborate a bit of how the power is controlled in the
ARM dev boards? Would it be possible to control such a switch in "GPIO"
manner instead? For example via the vdd_handler or similar?
I will also think if and see if is feasible to re-design and see if this
hole feature can be controlled by the variant struct instead. My feeling
is although it can be kind of messy. But let's see...
BR
Ulf Hansson
^ permalink raw reply
* Re: cryptodev tree on github
From: Stephen Rothwell @ 2011-10-24 10:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, linux-crypto
In-Reply-To: <20111021082016.GA13483@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hi Herbert,
On Fri, 21 Oct 2011 10:20:16 +0200 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Sun, Sep 25, 2011 at 02:50:23PM +1000, Herbert Xu wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Are you also going to move crypto-curent?
> >
> > I'll create that soon. I'll let you know when it happens.
>
> The crypto-current tree is now up at
>
> git://github.com/herbertx/crypto.git
I have switched to that now. Please let me know if/when you switch back
to kernel.org.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] x86 amd_gart_64: Verify we can perform the remapping requested
From: Joerg Roedel @ 2011-10-24 10:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel
In-Reply-To: <m1fwir48og.fsf@fess.ebiederm.org>
On Mon, Oct 17, 2011 at 02:20:15PM -0700, Eric W. Biederman wrote:
>
> Recently I had a driver try with a peculiar 2G dma memory limit.
> The driver failed in weird and strange ways because the GART remapping
> apperture had been allocated above 2G where the driver cound not reach,
> and no error was reported when the mappings were setup.
>
> Implement gart_dma_supported to test for this problem case and to return
> and error if we can not support the remapping.
You do basically the same as for swiotlb, so it must be good :)
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
For both patches:
Acked-by: Joerg Roedel <joerg.roedel@amd.com>
> ---
> arch/x86/kernel/amd_gart_64.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
> index 8a439d3..66279cb 100644
> --- a/arch/x86/kernel/amd_gart_64.c
> +++ b/arch/x86/kernel/amd_gart_64.c
> @@ -519,6 +519,14 @@ static int gart_mapping_error(struct device *dev, dma_addr_t dma_addr)
> return (dma_addr == bad_dma_addr);
> }
>
> +static int gart_dma_supported(struct device *dev, u64 mask)
> +{
> + unsigned long iommu_max_addr = iommu_bus_base + iommu_size - 1;
> +
> + /* Fail if the gart window is too high to fit in the devices dma mask */
> + return iommu_max_addr <= mask;
> +}
> +
> static int no_agp;
>
> static __init unsigned long check_iommu_size(unsigned long aper, u64 aper_size)
> @@ -703,6 +711,7 @@ static struct dma_map_ops gart_dma_ops = {
> .alloc_coherent = gart_alloc_coherent,
> .free_coherent = gart_free_coherent,
> .mapping_error = gart_mapping_error,
> + .dma_supported = gart_dma_supported,
> };
>
> static void gart_iommu_shutdown(void)
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Nothing great was ever achieved without enthusiasm.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-24 10:08 UTC (permalink / raw)
To: Kevin Wolf; +Cc: avi, Alexander Graf, qemu-devel
In-Reply-To: <4EA535AB.3010805@redhat.com>
On 10/24/2011 11:53 AM, Kevin Wolf wrote:
>> >
>> > I'm talking about the internal driver API only. The external API is
>> > fine as is.
> Ok, so external callers don't force us to do it.
>
> Yes, we could split bdrv_flush internally into two functions for "flush
> one level to the OS" and "flush all the way down to the disk", but I'm
> not sure if this really buys us anything or just adds complexity.
I would say that:
1) the "safe" NBD and iSCSI drivers are not in-tree, but you would have to
convert those too. iSCSI uses aio, so it would be non-trivial.
2) long-term you wanted to convert raw-posix to coroutines, but in the
meanwhile your patch introduces yet another partial transition;
3) your two patches are more complex compared to something like this:
diff --git a/block.c b/block.c
index 11c7f91..1e06a8a 100644
--- a/block.c
+++ b/block.c
@@ -2908,9 +2908,19 @@ static void coroutine_fn bdrv_flush_co_entry(void *opaque)
int coroutine_fn bdrv_co_flush(BlockDriverState *bs)
{
- if (bs->open_flags & BDRV_O_NO_FLUSH) {
+ if (!bs->drv) {
return 0;
- } else if (!bs->drv) {
+ }
+
+ /* First send everything to the OS. */
+ if (bs->drv->bdrv_co_flush_metadata) {
+ int ret = bs->drv->bdrv_co_flush_metadata(bs);
+ if (ret < 0) {
+ return ret;
+ }
+ }
+
+ /* Now flush the host cache to disk if we need to. */
+ if (bs->open_flags & BDRV_O_NO_FLUSH) {
return 0;
} else if (bs->drv->bdrv_co_flush) {
return bs->drv->bdrv_co_flush(bs);
diff --git a/block/qcow2.c b/block/qcow2.c
index a181932..cd13452 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1105,7 +1105,7 @@ fail:
return ret;
}
-static int qcow2_co_flush(BlockDriverState *bs)
+static int qcow2_co_flush_metadata(BlockDriverState *bs)
{
BDRVQcowState *s = bs->opaque;
int ret;
@@ -1121,7 +1121,11 @@ static int qcow2_co_flush(BlockDriverState *bs)
return ret;
}
qemu_co_mutex_unlock(&s->lock);
+ return 0;
+}
+static int qcow2_co_flush(BlockDriverState *bs)
+{
return bdrv_co_flush(bs->file);
}
@@ -1244,6 +1248,7 @@ static BlockDriver bdrv_qcow2 = {
.bdrv_co_readv = qcow2_co_readv,
.bdrv_co_writev = qcow2_co_writev,
.bdrv_co_flush = qcow2_co_flush,
+ .bdrv_co_flush_metadata = qcow2_co_flush_metadata,
.bdrv_co_discard = qcow2_co_discard,
.bdrv_truncate = qcow2_truncate,
diff --git a/block_int.h b/block_int.h
index dac00f5..ab4ceea 100644
--- a/block_int.h
+++ b/block_int.h
@@ -84,6 +84,7 @@ struct BlockDriver {
int coroutine_fn (*bdrv_co_writev)(BlockDriverState *bs,
int64_t sector_num, int nb_sectors, QEMUIOVector *qiov);
int coroutine_fn (*bdrv_co_flush)(BlockDriverState *bs);
+ int coroutine_fn (*bdrv_co_flush_metadata)(BlockDriverState *bs);
int coroutine_fn (*bdrv_co_discard)(BlockDriverState *bs,
int64_t sector_num, int nb_sectors);
Paolo
^ permalink raw reply related
* Re: [PATCH] mmc: boot partition ro lock support
From: Chris Ball @ 2011-10-24 10:08 UTC (permalink / raw)
To: Ulf Hansson
Cc: Sebastian Rasmussen, Linus Walleij, Andrei Warkentin, Per FORLIN,
Lee Jones, Johan RUDHOLM, John BECKETT, linux-mmc@vger.kernel.org
In-Reply-To: <4EA52E92.1010406@stericsson.com>
Hi Ulf,
On Mon, Oct 24 2011, Ulf Hansson wrote:
> The kernel could very much be used in manufacturing environment as
> well. Don't know if and how we should consider this.
>
> Do you think a change to an ioctl is a better alternative than sysfs?
> Then let's change to that!
Ah, we're not proposing a new ioctl for this -- we're proposing that the
perm-r/o command could be sent from a userspace binary that *uses* the
arbitrary command ioctl that we already have.
The arbitrary command ioctl is drivers/mmc/card/block.c:mmc_blk_ioctl_cmd().
Please could you send a version of the patch that supports power-on r/o
but not perm r/o, and perhaps also post userspace code for submitting
the perm r/o command through the ioctl interface? (Perhaps this code
should eventually be submitted to a disk management tool..)
Also, it looks like it's possible to set read-only for the whole device,
as well as for boot partitions. Could you update the patch to allow
setting power-on r/o for the entire card, not just the boot partitions?
> Enable boot partitions to be power and permanently read-only locked via
> a sysfs entry. There will be one sysfs entry for the main mmc device:
>
> /sys/block/mmcblkX/boot_partition_ro_lock
I don't follow why this node is necessary, instead of just having the
nodes in the mmcblkXbootY/ directories. Could you explain?
> and one for each boot partition:
>
> /sys/block/mmcblkXbootY/ro_lock
>
> The boot partitions are power or permanently locked by writing "pwr_ro"
> or "perm_ro" to one of the files.
Now that we're only having one type of r/o lock, let's do:
echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
to lock just a boot partition, and:
echo 1 > /sys/block/mmcblkX/ro_lock_until_next_power_on
to lock the entire card (which will cover the boot partition too), with
echo 0 to unlock.
Other review comments: I noticed that your pr_*(); statements are
missing "\n"s on the end, and you should add documentation on the new
sysfs nodes to:
Documentation/mmc/mmc-dev-parts.txt
I think the overlap between your patch and Andrei's mmcblkXbootY/force_ro
node is going to be confusing -- one operates purely in the kernel and
the other is sent to the card. Do you have any proposal for making the
difference clearer?
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH 5/6] IIO:hwmon interface client driver.
From: Jonathan Cameron @ 2011-10-24 10:09 UTC (permalink / raw)
To: Jonathan Cameron
Cc: guenter.roeck, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linus.ml.walleij@gmail.com,
zdevai@gmail.com, linux@arm.linux.org.uk, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA03E8D.1010303@cam.ac.uk>
On 10/20/11 16:30, Jonathan Cameron wrote:
> On 10/20/11 16:12, Guenter Roeck wrote:
>> On Thu, 2011-10-20 at 05:33 -0400, Jonathan Cameron wrote:
>>> Should move to drivers/hwmon once people are happy with it.
>>>
>>> Minimal support of simple in, curr and temp attributes
>>> so far.
>>>
>>> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
>>> ---
>>> drivers/iio/Kconfig | 8 ++
>>> drivers/iio/Makefile | 1 +
>>> drivers/iio/iio_hwmon.c | 227 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 236 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>> index 308bc97..c2f0970 100644
>>> --- a/drivers/iio/Kconfig
>>> +++ b/drivers/iio/Kconfig
>>> @@ -11,6 +11,14 @@ menuconfig IIO
>>>
>>> if IIO
>>>
>>> +config IIO_HWMON
>>> + tristate "Hwmon driver that uses channels specified via iio maps"
>>> + depends on HWMON
>>> + help
>>> + This is a platform driver that in combination with a suitable
>>> + map allows IIO devices to provide basic hwmon functionality
>>> + for those channels specified in the map.
>>> +
>>> source "drivers/iio/adc/Kconfig"
>>> source "drivers/iio/imu/Kconfig"
>>> source "drivers/iio/light/Kconfig"
>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>> index cfb588a..5f9c01a 100644
>>> --- a/drivers/iio/Makefile
>>> +++ b/drivers/iio/Makefile
>>> @@ -6,6 +6,7 @@ obj-y = inkern.o
>>> obj-$(CONFIG_IIO) += iio.o
>>> industrialio-y := core.o
>>>
>>> +obj-$(CONFIG_IIO_HWMON) += iio_hwmon.o
>>> obj-y += adc/
>>> obj-y += imu/
>>> obj-y += light/
>>> diff --git a/drivers/iio/iio_hwmon.c b/drivers/iio/iio_hwmon.c
>>> new file mode 100644
>>> index 0000000..b3348ad
>>> --- /dev/null
>>> +++ b/drivers/iio/iio_hwmon.c
>>> @@ -0,0 +1,227 @@
>>> +/* Hwmon client for industrial I/O devices
>>> + *
>>> + * Copyright (c) 2011 Jonathan Cameron
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License version 2 as published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * Limited functionality currently supported.
>>
>> Just nitpicking ... this comment doesn't provide much value. It doesn't
>> explain the limits, nor what could be improved.
>>
>>> + */
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/module.h>
>>> +#include <linux/err.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/iio/inkern.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/hwmon-sysfs.h>
>>> +
>>> +/**
>>> + * struct iio_hwmon_state - device instance state
>>> + * @channels: filled with null terminated array of channels from iio
>>> + * @num_channels: number of channels in channels (saves counting twice)
>>> + * @hwmon_dev: associated hwmon device
>>> + * @attr_group: the group of attributes
>>> + * @attrs: null terminated array of attribute pointers.
>>> + */
>>> +struct iio_hwmon_state {
>>> + struct iio_channel **channels;
>>> + int num_channels;
>>> + struct device *hwmon_dev;
>>> + struct attribute_group attr_group;
>>> + struct attribute **attrs;
>>> +};
>>> +
>>> +/*
>>> + * Assumes that IIO and hwmon operate in the same base units.
>>> + * This is supposed to be true, but needs verification for
>>> + * new channel types.
>>> + */
>>> +static ssize_t iio_hwmon_read_val(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + long result;
>>> + int val, ret, scaleint, scalepart;
>>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
>>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
>>> +
>>> + /*
>>> + * No locking between this pair, so theoretically possible
>>> + * the scale has changed.
>>> + */
>>> + ret = iio_read_channel_raw(state->channels[sattr->index],
>>> + &val);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = iio_read_channel_scale(state->channels[sattr->index],
>>> + &scaleint, &scalepart);
>>> + if (ret < 0)
>>> + return ret;
>>> + switch (ret) {
>>> + case IIO_VAL_INT:
>>> + result = val * scaleint;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_MICRO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000L;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_NANO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000000L;
>>> + break;
>>
>> Still easy to imagine that val * scalepart gets larger than 2147483647L
>> (on machines where sizeof(long) = 4) ... it will already happen if the
>> result of (val * scalepart / 1000000000) is larger than 2.
> Good point. I really ought to have done the calcs.
> If we have maximum possible value in here things will be ugly.
>
> Worst case is scalepart is 9999999999. (could be done as 1 - 0.000000001
> which would be nicer, but we don't specify a preference - from this
> discussion I am suspecting we should!)
>
> Looks like 64 bits is going to be a requirement as you say.
>>
>> What value range do you expect to see here ?
>>
>> If (val * scaleint) is already the milli-unit, scalepart would possibly
>> only address fractions of milli-units. If so, the result of (val *
>> scalepart / 1000000000L) might always be smaller than 1, ie 0.
> It certainly should be.
>> If so, for the calculation to have any value, you might be better off using
>> DIV_ROUND_CLOSEST(val * scalepart, 1000000000L).
> Good idea.
>>
>> I am a bit confused by this anyway. Since hwmon in general reports
>> milli-units, VAL_INT appears to reflect milli-units, VAL_INT_PLUS_MICRO
>> really means nano-units, and IIO_VAL_INT_PLUS_NANO really means
>> pico-units. Is this correct ?
> Micro units of the scale factor.
>
> Take my test part a max1363...
> Scale is actually 0.5 so each adc count (e.g. raw value) is 0.5millivolts.
>
> scale int here is 0,
> scale part is 500,000 (so 0.5) and it returns IIO_VAL_INT_PLUS_MICRO.
How about the following? It'll be extremely costly, but this isn't exactly
a fast path!
case IIO_VAL_INT_PLUS_MICRO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000LL);
break;
case IIO_VAL_INT_PLUS_NANO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000000LL);
break;
Everything should fit in there and it should give us pretty good precision.
>
>
>>
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> + return sprintf(buf, "%ld\n", result);
>>> +}
>>> +
>>> +static void iio_hwmon_free_attrs(struct iio_hwmon_state *st)
>>> +{
>>> + int i;
>>> + struct sensor_device_attribute *a;
>>> + for (i = 0; i < st->num_channels; i++)
>>> + if (st->attrs[i]) {
>>> + a = to_sensor_dev_attr(
>>> + container_of(st->attrs[i],
>>> + struct device_attribute,
>>> + attr));
>>> + kfree(a);
>>> + }
>>> +}
>>> +
>>> +static int __devinit iio_hwmon_probe(struct platform_device *pdev)
>>> +{
>>> + struct iio_hwmon_state *st;
>>> + struct sensor_device_attribute *a;
>>> + int ret, i;
>>> + int in_i = 1, temp_i = 1, curr_i = 1;
>>> +
>>> + st = kzalloc(sizeof(*st), GFP_KERNEL);
>>> + if (st == NULL) {
>>> + ret = -ENOMEM;
>>> + goto error_ret;
>>> + }
>>> +
>>> + st->channels = iio_channel_get_all(&pdev->dev, NULL);
>>> + if (IS_ERR(st->channels)) {
>>> + ret = PTR_ERR(st->channels);
>>> + goto error_free_state;
>>> + }
>>> +
>>> + /* count how many attributes we have */
>>> + while (st->channels[st->num_channels])
>>> + st->num_channels++;
>>> +
>>> + st->attrs = kzalloc(sizeof(st->attrs) * (st->num_channels + 1),
>>> + GFP_KERNEL);
>>
>> Why "+ 1" ?
> Null terminated list for attribute groups. Hence the kzalloc.
>>
>> Unless I am missing something, you only use st->attrs[0] ..
>> st->attrs[st->num_channels-1].
>>
>> Thanks,
>> Guenter
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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
* Re: [lm-sensors] [PATCH 5/6] IIO:hwmon interface client driver.
From: Jonathan Cameron @ 2011-10-24 10:09 UTC (permalink / raw)
To: Jonathan Cameron
Cc: guenter.roeck, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linus.ml.walleij@gmail.com,
zdevai@gmail.com, linux@arm.linux.org.uk, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA03E8D.1010303@cam.ac.uk>
On 10/20/11 16:30, Jonathan Cameron wrote:
> On 10/20/11 16:12, Guenter Roeck wrote:
>> On Thu, 2011-10-20 at 05:33 -0400, Jonathan Cameron wrote:
>>> Should move to drivers/hwmon once people are happy with it.
>>>
>>> Minimal support of simple in, curr and temp attributes
>>> so far.
>>>
>>> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
>>> ---
>>> drivers/iio/Kconfig | 8 ++
>>> drivers/iio/Makefile | 1 +
>>> drivers/iio/iio_hwmon.c | 227 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 236 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>> index 308bc97..c2f0970 100644
>>> --- a/drivers/iio/Kconfig
>>> +++ b/drivers/iio/Kconfig
>>> @@ -11,6 +11,14 @@ menuconfig IIO
>>>
>>> if IIO
>>>
>>> +config IIO_HWMON
>>> + tristate "Hwmon driver that uses channels specified via iio maps"
>>> + depends on HWMON
>>> + help
>>> + This is a platform driver that in combination with a suitable
>>> + map allows IIO devices to provide basic hwmon functionality
>>> + for those channels specified in the map.
>>> +
>>> source "drivers/iio/adc/Kconfig"
>>> source "drivers/iio/imu/Kconfig"
>>> source "drivers/iio/light/Kconfig"
>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>> index cfb588a..5f9c01a 100644
>>> --- a/drivers/iio/Makefile
>>> +++ b/drivers/iio/Makefile
>>> @@ -6,6 +6,7 @@ obj-y = inkern.o
>>> obj-$(CONFIG_IIO) += iio.o
>>> industrialio-y := core.o
>>>
>>> +obj-$(CONFIG_IIO_HWMON) += iio_hwmon.o
>>> obj-y += adc/
>>> obj-y += imu/
>>> obj-y += light/
>>> diff --git a/drivers/iio/iio_hwmon.c b/drivers/iio/iio_hwmon.c
>>> new file mode 100644
>>> index 0000000..b3348ad
>>> --- /dev/null
>>> +++ b/drivers/iio/iio_hwmon.c
>>> @@ -0,0 +1,227 @@
>>> +/* Hwmon client for industrial I/O devices
>>> + *
>>> + * Copyright (c) 2011 Jonathan Cameron
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License version 2 as published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * Limited functionality currently supported.
>>
>> Just nitpicking ... this comment doesn't provide much value. It doesn't
>> explain the limits, nor what could be improved.
>>
>>> + */
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/module.h>
>>> +#include <linux/err.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/iio/inkern.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/hwmon-sysfs.h>
>>> +
>>> +/**
>>> + * struct iio_hwmon_state - device instance state
>>> + * @channels: filled with null terminated array of channels from iio
>>> + * @num_channels: number of channels in channels (saves counting twice)
>>> + * @hwmon_dev: associated hwmon device
>>> + * @attr_group: the group of attributes
>>> + * @attrs: null terminated array of attribute pointers.
>>> + */
>>> +struct iio_hwmon_state {
>>> + struct iio_channel **channels;
>>> + int num_channels;
>>> + struct device *hwmon_dev;
>>> + struct attribute_group attr_group;
>>> + struct attribute **attrs;
>>> +};
>>> +
>>> +/*
>>> + * Assumes that IIO and hwmon operate in the same base units.
>>> + * This is supposed to be true, but needs verification for
>>> + * new channel types.
>>> + */
>>> +static ssize_t iio_hwmon_read_val(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + long result;
>>> + int val, ret, scaleint, scalepart;
>>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
>>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
>>> +
>>> + /*
>>> + * No locking between this pair, so theoretically possible
>>> + * the scale has changed.
>>> + */
>>> + ret = iio_read_channel_raw(state->channels[sattr->index],
>>> + &val);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = iio_read_channel_scale(state->channels[sattr->index],
>>> + &scaleint, &scalepart);
>>> + if (ret < 0)
>>> + return ret;
>>> + switch (ret) {
>>> + case IIO_VAL_INT:
>>> + result = val * scaleint;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_MICRO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000L;
>>> + break;
>>> + case IIO_VAL_INT_PLUS_NANO:
>>> + result = (long)val * (long)scaleint +
>>> + (long)val * (long)scalepart / 1000000000L;
>>> + break;
>>
>> Still easy to imagine that val * scalepart gets larger than 2147483647L
>> (on machines where sizeof(long) = 4) ... it will already happen if the
>> result of (val * scalepart / 1000000000) is larger than 2.
> Good point. I really ought to have done the calcs.
> If we have maximum possible value in here things will be ugly.
>
> Worst case is scalepart is 9999999999. (could be done as 1 - 0.000000001
> which would be nicer, but we don't specify a preference - from this
> discussion I am suspecting we should!)
>
> Looks like 64 bits is going to be a requirement as you say.
>>
>> What value range do you expect to see here ?
>>
>> If (val * scaleint) is already the milli-unit, scalepart would possibly
>> only address fractions of milli-units. If so, the result of (val *
>> scalepart / 1000000000L) might always be smaller than 1, ie 0.
> It certainly should be.
>> If so, for the calculation to have any value, you might be better off using
>> DIV_ROUND_CLOSEST(val * scalepart, 1000000000L).
> Good idea.
>>
>> I am a bit confused by this anyway. Since hwmon in general reports
>> milli-units, VAL_INT appears to reflect milli-units, VAL_INT_PLUS_MICRO
>> really means nano-units, and IIO_VAL_INT_PLUS_NANO really means
>> pico-units. Is this correct ?
> Micro units of the scale factor.
>
> Take my test part a max1363...
> Scale is actually 0.5 so each adc count (e.g. raw value) is 0.5millivolts.
>
> scale int here is 0,
> scale part is 500,000 (so 0.5) and it returns IIO_VAL_INT_PLUS_MICRO.
How about the following? It'll be extremely costly, but this isn't exactly
a fast path!
case IIO_VAL_INT_PLUS_MICRO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000LL);
break;
case IIO_VAL_INT_PLUS_NANO:
result = (s64)val * (s64)scaleint +
div_s64((s64)val * (s64)scalepart, 1000000000LL);
break;
Everything should fit in there and it should give us pretty good precision.
>
>
>>
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> + return sprintf(buf, "%ld\n", result);
>>> +}
>>> +
>>> +static void iio_hwmon_free_attrs(struct iio_hwmon_state *st)
>>> +{
>>> + int i;
>>> + struct sensor_device_attribute *a;
>>> + for (i = 0; i < st->num_channels; i++)
>>> + if (st->attrs[i]) {
>>> + a = to_sensor_dev_attr(
>>> + container_of(st->attrs[i],
>>> + struct device_attribute,
>>> + attr));
>>> + kfree(a);
>>> + }
>>> +}
>>> +
>>> +static int __devinit iio_hwmon_probe(struct platform_device *pdev)
>>> +{
>>> + struct iio_hwmon_state *st;
>>> + struct sensor_device_attribute *a;
>>> + int ret, i;
>>> + int in_i = 1, temp_i = 1, curr_i = 1;
>>> +
>>> + st = kzalloc(sizeof(*st), GFP_KERNEL);
>>> + if (st = NULL) {
>>> + ret = -ENOMEM;
>>> + goto error_ret;
>>> + }
>>> +
>>> + st->channels = iio_channel_get_all(&pdev->dev, NULL);
>>> + if (IS_ERR(st->channels)) {
>>> + ret = PTR_ERR(st->channels);
>>> + goto error_free_state;
>>> + }
>>> +
>>> + /* count how many attributes we have */
>>> + while (st->channels[st->num_channels])
>>> + st->num_channels++;
>>> +
>>> + st->attrs = kzalloc(sizeof(st->attrs) * (st->num_channels + 1),
>>> + GFP_KERNEL);
>>
>> Why "+ 1" ?
> Null terminated list for attribute groups. Hence the kzalloc.
>>
>> Unless I am missing something, you only use st->attrs[0] ..
>> st->attrs[st->num_channels-1].
>>
>> Thanks,
>> Guenter
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ 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.