* [PATCH 4/6 V2] Add generic stubs for kvm stop check functions
From: Eric B Munson @ 2011-10-31 20:07 UTC (permalink / raw)
To: avi
Cc: mingo, x86, hpa, arnd, linux-kernel, kvm, linux-arch, ryanh,
aliguori, Eric B Munson
In-Reply-To: <1320091650-24682-1-git-send-email-emunson@mgebm.net>
Signed-off-by: Eric B Munson <emunson@mgebm.net>
---
include/asm-generic/pvclock.h | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 include/asm-generic/pvclock.h
diff --git a/include/asm-generic/pvclock.h b/include/asm-generic/pvclock.h
new file mode 100644
index 0000000..b42a8eb
--- /dev/null
+++ b/include/asm-generic/pvclock.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_GENERIC_PVCLOCK_H
+#define _ASM_GENERIC_PVCLOCK_H
+
+
+/*
+ * These functions are used by architectures that support kvm to avoid issuing
+ * false soft lockup messages.
+ */
+static inline bool kvm_check_and_clear_host_stopped(int cpu)
+{
+ return false;
+}
+
+static inline void kvm_clear_guest_paused(struct kvm_vcpu *vcpu)
+{
+ return;
+}
+
+#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/6 V2] Add ioctl for KVM_GUEST_STOPPED
From: Eric B Munson @ 2011-10-31 20:07 UTC (permalink / raw)
To: avi
Cc: mingo, x86, hpa, arnd, linux-kernel, kvm, linux-arch, ryanh,
aliguori, Eric B Munson
In-Reply-To: <1320091650-24682-1-git-send-email-emunson@mgebm.net>
Now that we have a flag that will tell the guest it was suspended, create an
interface for that communication using a KVM ioctl.
Signed-off-by: Eric B Munson <emunson@mgebm.net>
---
Changes from V1:
Add kvm_set_host_stopped to arch/x86/jvm/x86.c instead of kvmclock.c
Rename KVM_PAUSE_GUEST to KVM_GUEST_PAUSED
arch/x86/include/asm/pvclock.h | 3 +++
arch/x86/kvm/x86.c | 16 ++++++++++++++++
include/linux/kvm.h | 2 ++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 7d3ba41..9312814 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -3,6 +3,7 @@
#include <linux/clocksource.h>
#include <asm/pvclock-abi.h>
+#include <linux/kvm_host.h>
/* some helper functions for xen and kvm pv clock sources */
cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
@@ -13,6 +14,8 @@ void pvclock_read_wallclock(struct pvclock_wall_clock *wall,
struct timespec *ts);
void pvclock_resume(void);
+void kvm_set_host_stopped(struct kvm_vcpu *vcpu);
+
bool kvm_check_and_clear_host_stopped(int cpu);
/*
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..592ac3b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3295,6 +3295,11 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
goto out;
}
+ case KVM_GUEST_PAUSED: {
+ r = 0;
+ kvm_set_host_stopped(vcpu);
+ break;
+ }
default:
r = -EINVAL;
}
@@ -6117,6 +6122,17 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16 tss_selector, int reason,
}
EXPORT_SYMBOL_GPL(kvm_task_switch);
+/*
+ * kvm_set_host_stopped() indicates to the guest kernel that it has been
+ * stopped by the hypervisor. This function will be called from the host only.
+ */
+void kvm_set_host_stopped(struct kvm_vcpu *vcpu)
+{
+ struct pvclock_vcpu_time_info *src = &vcpu->arch.hv_clock;
+ src->flags |= PVCLOCK_GUEST_STOPPED;
+}
+EXPORT_SYMBOL_GPL(kvm_set_host_stopped);
+
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f47fcd3..87cab0d 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -763,6 +763,8 @@ struct kvm_clock_data {
#define KVM_CREATE_SPAPR_TCE _IOW(KVMIO, 0xa8, struct kvm_create_spapr_tce)
/* Available with KVM_CAP_RMA */
#define KVM_ALLOCATE_RMA _IOR(KVMIO, 0xa9, struct kvm_allocate_rma)
+/* VM is being stopped by host */
+#define KVM_GUEST_PAUSED _IO(KVMIO, 0xaa)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/6 V2] Add functions to check if the host has stopped the vm
From: Eric B Munson @ 2011-10-31 20:07 UTC (permalink / raw)
To: avi
Cc: mingo, x86, hpa, arnd, linux-kernel, kvm, linux-arch, ryanh,
aliguori, Eric B Munson
In-Reply-To: <1320091650-24682-1-git-send-email-emunson@mgebm.net>
When a host stops or suspends a VM it will set a flag to show this. The
watchdog will use these functions to determine if a softlockup is real, or the
result of a suspended VM.
Signed-off-by: Eric B Munson <emunson@mgebm.net>
---
arch/x86/include/asm/pvclock.h | 2 ++
arch/x86/kernel/kvmclock.c | 19 +++++++++++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index c59cc97..7d3ba41 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -13,6 +13,8 @@ void pvclock_read_wallclock(struct pvclock_wall_clock *wall,
struct timespec *ts);
void pvclock_resume(void);
+bool kvm_check_and_clear_host_stopped(int cpu);
+
/*
* Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction,
* yielding a 64-bit result.
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index c1a0188..8ddcfaf 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -113,6 +113,25 @@ static void kvm_get_preset_lpj(void)
preset_lpj = lpj;
}
+bool kvm_check_and_clear_host_stopped(int cpu)
+{
+ bool ret = false;
+ struct pvclock_vcpu_time_info *src;
+
+ /*
+ * per_cpu() is safe here because this function is only called from
+ * timer functions where preemption is already disabled.
+ */
+ WARN_ON(!in_atomic());
+ src = &per_cpu(hv_clock, cpu);
+ if ((src->flags & PVCLOCK_GUEST_STOPPED) != 0) {
+ src->flags = src->flags & (~PVCLOCK_GUEST_STOPPED);
+ ret = true;
+ }
+
+ return ret;
+}
+
static struct clocksource kvm_clock = {
.name = "kvm-clock",
.read = kvm_clock_get_cycles,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/6 V2] Add flag to indicate that a vm was stopped by the host
From: Eric B Munson @ 2011-10-31 20:07 UTC (permalink / raw)
To: avi
Cc: mingo, x86, hpa, arnd, linux-kernel, kvm, linux-arch, ryanh,
aliguori, Eric B Munson
In-Reply-To: <1320091650-24682-1-git-send-email-emunson@mgebm.net>
This flag will be used to check if the vm was stopped by the host when a soft
lockup was detected.
Signed-off-by: Eric B Munson <emunson@mgebm.net>
---
arch/x86/include/asm/pvclock-abi.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/pvclock-abi.h b/arch/x86/include/asm/pvclock-abi.h
index 35f2d19..6167fd7 100644
--- a/arch/x86/include/asm/pvclock-abi.h
+++ b/arch/x86/include/asm/pvclock-abi.h
@@ -40,5 +40,6 @@ struct pvclock_wall_clock {
} __attribute__((__packed__));
#define PVCLOCK_TSC_STABLE_BIT (1 << 0)
+#define PVCLOCK_GUEST_STOPPED (1 << 1)
#endif /* __ASSEMBLY__ */
#endif /* _ASM_X86_PVCLOCK_ABI_H */
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] drivers: i915: Default max backlight brightness value
From: Simon Que @ 2011-10-31 20:02 UTC (permalink / raw)
To: intel-gfx, chris, jbarnes, eric; +Cc: Simon Que, olofj, mjg
In-Reply-To: <1318636017-14568-1-git-send-email-sque@chromium.org>
On Fri, Oct 14, 2011 at 4:46 PM, Simon Que <sque@chromium.org> wrote:
> In the native backlight driver, use 4096 (0x1000) as the default backlight
> period, and use the period as the default max brightness.
>
> The default brightness is defined in a separate function that can be
> expanded to allow for different defaults on different systems in the
> future.
>
> Change-Id: Ie783b53dd034dcd7bf42e24ffc911cf2f10a5676
> Signed-off-by: Simon Que <sque@chromium.org>
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_panel.c | 22 ++++++++++++++++++----
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5d5def7..a832028 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3275,6 +3275,7 @@
> #define PWM_POLARITY_ACTIVE_HIGH2 (0 << 28)
>
> #define BLC_PWM_PCH_CTL2 0xc8254
> +#define BLC_PWM_PCH_FREQ_SHIFT 16
>
> #define PCH_PP_STATUS 0xc7200
> #define PCH_PP_CONTROL 0xc7204
> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> index 05f500c..8205945 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -161,6 +161,12 @@ static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
> return val;
> }
>
> +static u32 intel_panel_get_default_backlight_period(struct drm_device *dev)
> +{
> + /* The default number of clock cycles in one backlight PWM period. */
> + return 0x1000;
> +}
> +
> u32 intel_panel_get_max_backlight(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -168,11 +174,19 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
>
> max = i915_read_blc_pwm_ctl(dev_priv);
> if (max == 0) {
> - /* XXX add code here to query mode clock or hardware clock
> - * and program max PWM appropriately.
> + /* If no max backlight was found, use the default PWM period as
> + * the max backlight value.
> */
> - printk_once(KERN_WARNING "fixme: max PWM is zero.\n");
> - return 1;
> + max = intel_panel_get_default_backlight_period(dev);
> + if (HAS_PCH_SPLIT(dev_priv->dev)) {
> + u32 val = max << BLC_PWM_PCH_FREQ_SHIFT;
> + I915_WRITE(BLC_PWM_PCH_CTL2, val);
> + } else {
> + u32 val = max << BACKLIGHT_MODULATION_FREQ_SHIFT;
> + I915_WRITE(BLC_PWM_CTL, val);
> + }
> +
> + return max;
> }
>
> if (HAS_PCH_SPLIT(dev)) {
> --
> 1.7.2.3
>
>
Please provide feedback on this patch. I am hoping that more people
are available now that the Linux Conference is over. :)
^ permalink raw reply
* Re: [PATCH v4 4/4] qemu/rbd: improve rbd device specification
From: Eric Blake @ 2011-10-31 20:02 UTC (permalink / raw)
To: Josh Durgin; +Cc: libvir-list, ceph-devel, berrange
In-Reply-To: <fc9aba44da7d8be72fabeba1caf07901aaef202d.1319836201.git.josh.durgin@dreamhost.com>
On 10/28/2011 03:19 PM, Josh Durgin wrote:
> From: Sage Weil<sage@newdream.net>
>
> This improves the support for qemu rbd devices by adding support for a few
> key features (e.g., authentication) and cleaning up the way in which
> rbd configuration options are passed to qemu.
>
> And<auth> member of the disk source xml specifies how librbd should
s/And/An/
> authenticate. The username attribute is the Ceph/RBD user to authenticate as.
> The usage or uuid attributes specify which secret to use. Usage is an
> arbitrary identifier local to libvirt.
>
> The old RBD support relied on setting an environment variable to
> communicate information to qemu/librbd. Instead, pass those options
> explicitly to qemu. Update the qemu argument parsing and tests
> accordingly.
>
> Signed-off-by: Sage Weil<sage@newdream.net>
> Signed-off-by: Josh Durgin<josh.durgin@dreamhost.com>
> ---
>
> This fixes the things Daniel mentioned.
Needs a v5, to fix memory management issues.
> @@ -1495,6 +1496,159 @@ qemuSafeSerialParamValue(const char *value)
> return 0;
> }
>
> +static int qemuBuildRBDString(virConnectPtr conn,
> + virDomainDiskDefPtr disk,
> + virBufferPtr opt)
Nit: We've been using this style:
static int
qemuBuildRBDString(virConnectPtr conn,
virDomainDiskDefPtr disk,
virBufferPtr opt)
> + if (sec) {
> + char *base64;
> +
> + secret = (char *)conn->secretDriver->getValue(sec,&secret_size, 0,
> + VIR_SECRET_GET_VALUE_INTERNAL_CALL);
> + if (secret == NULL) {
> + qemuReportError(VIR_ERR_INTERNAL_ERROR,
> + _("could not get the value of the secret for username %s"),
> + disk->auth.username);
> + return -1;
Resource leak. You need to ensure virUnrefSecret(sec) gets called on
this path. I'd move that particular cleanup down into the cleanup:
label, and make this part goto cleanup instead of return -1.
> + }
> + /* qemu/librbd wants it base64 encoded */
> + base64_encode_alloc(secret, secret_size,&base64);
> + virBufferEscape(opt, ":", ":key=%s:auth_supported=cephx\\;none",
> + base64);
Need to check for allocation failure of base64_encode_alloc; otherwise,
you blindly passed NULL base64 to virBufferEscape, which is not portable.
> + VIR_FREE(base64);
> + VIR_FREE(secret);
> + virUnrefSecret(sec);
> + } else {
> + qemuReportError(VIR_ERR_INTERNAL_ERROR,
> + _("rbd username '%s' specified but secret not found"),
> + disk->auth.username);
> + return -1;
> + }
> + }
> +
> + if (disk->nhosts> 0) {
> + virBufferStrcat(opt, ":mon_host=", NULL);
> + for (i = 0; i< disk->nhosts; ++i) {
> + if (i) {
> + virBufferStrcat(opt, "\\;", NULL);
virBufferAddLit(opt, "\\;")
is more efficient than virBufferStrcat().
> + }
> + if (disk->hosts[i].port) {
> + virBufferAsprintf(opt, "%s\\:%s",
> + disk->hosts[i].name,
> + disk->hosts[i].port);
> + } else {
> + virBufferAsprintf(opt, "%s", disk->hosts[i].name);
> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int qemuAddRBDHost(virDomainDiskDefPtr disk, char *hostport)
> +{
> + char *port;
> + int ret;
> +
> + disk->nhosts++;
> + ret = VIR_REALLOC_N(disk->hosts, disk->nhosts);
> + if (ret< 0) {
> + virReportOOMError();
> + return -1;
> + }
> +
> + port = strstr(hostport, "\\:");
> + if (port) {
> + *port = '\0';
> + port += 2;
> + disk->hosts[disk->nhosts-1].port = strdup(port);
> + } else {
> + disk->hosts[disk->nhosts-1].port = strdup("6789");
> + }
> + disk->hosts[disk->nhosts-1].name = strdup(hostport);
These three strdup() need to check for allocation failure.
> + return 0;
> +}
> +
> +/* disk->src initially has everything after the rbd: prefix */
> +static int qemuParseRBDString(virDomainDiskDefPtr disk)
> +{
> + char *options = NULL;
> + char *p, *e, *next;
> +
> + p = strchr(disk->src, ':');
> + if (p) {
> + options = strdup(p + 1);
> + *p = '\0';
Need to check for strdup() failure.
> + }
> +
> + /* options */
> + if (!options)
> + return 0; /* all done */
> +
> + p = options;
> + while (*p) {
> + /* find : delimiter or end of string */
> + for (e = p; *e&& *e != ':'; ++e) {
> + if (*e == '\\') {
> + e++;
> + if (*e == '\0')
> + break;
> + }
> + }
> + if (*e == '\0') {
> + next = e; /* last kv pair */
> + } else {
> + next = e + 1;
> + *e = '\0';
> + }
> +
> + if (STRPREFIX(p, "id=")) {
> + disk->auth.username = strdup(p + strlen("id="));
Check for allocation failure. Also, you might want to see if using
strndup() on the original string is easier than copying the string, just
so you can do in-place modifications of injecting NUL bytes for strdup()
to work.
> + }
> + if (STRPREFIX(p, "mon_host=")) {
> + char *h, *sep;
> +
> + h = p + strlen("mon_host=");
> + while (h< e) {
> + for (sep = h; sep< e; ++sep) {
> + if (*sep == '\\'&& (sep[1] == ',' ||
> + sep[1] == ';' ||
> + sep[1] == ' ')) {
> + *sep = '\0';
> + sep += 2;
> + break;
> + }
> + }
> + qemuAddRBDHost(disk, h);
Don't ignore the return value here.
> + h = sep;
> + }
> + }
> +
> + p = next;
> + }
> + return 0;
> +}
>
> char *
> qemuBuildDriveStr(virConnectPtr conn,
> @@ -1614,8 +1768,10 @@ qemuBuildDriveStr(virConnectPtr conn,
> disk->hosts->name, disk->hosts->port);
> break;
> case VIR_DOMAIN_DISK_PROTOCOL_RBD:
> - /* TODO: set monitor hostnames */
> - virBufferAsprintf(&opt, "file=rbd:%s,", disk->src);
> + virBufferStrcat(&opt, "file=", NULL);
virBufferAddLit(&opt, "file=") is more efficient.
> + if (qemuBuildRBDString(conn, disk,&opt)< 0)
> + goto error;
> + virBufferStrcat(&opt, ",", NULL);
virBufferAddChar(&opt, ',') is more efficient.
> @@ -5299,10 +5418,6 @@ static int qemuStringToArgvEnv(const char *args,
> const char *next;
>
> start = curr;
> - /* accept a space in CEPH_ARGS */
> - if (STRPREFIX(curr, "CEPH_ARGS=-m ")) {
> - start += strlen("CEPH_ARGS=-m ");
> - }
While we aren't generating CEPH_ARGS in the environment any more, I
don't think we should rip out the parsing code. That is, parsing should
be able to handle our older output, in addition to our new output.
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth.args
> @@ -0,0 +1,6 @@
> +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \
> +/usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor \
> +unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -drive \
> +file=/dev/HostVG/QEMUGuest1,if=ide,bus=0,unit=0 -drive \
> +file=rbd:pool/image:id=myname:key=QVFDVm41aE82SHpGQWhBQXEwTkN2OGp0SmNJY0UrSE9CbE1RMUE=:auth_supported=cephx\;none:mon_host=mon1.example.org\:6321\;mon2.example.org\:6322\;mon3.example.org\:6322,\
That's a rather long line - I'd suggest using backslash-newline to break
it up, probably at each ':' (it's not the end of the world if you go
longer than 80 columns, if absolutely necessary, but life is easier when
everything just fits).
> +static virSecretPtr
> +fakeSecretLookupByUsage(virConnectPtr conn,
> + int usageType ATTRIBUTE_UNUSED,
> + const char *usageID)
> +{
> + virSecretPtr ret = NULL;
> + int err;
> + if (STRNEQ(usageID, "mycluster_myname"))
> + return NULL;
> + err = VIR_ALLOC(ret);
> + if (err< 0)
> + return NULL;
> + ret->magic = VIR_SECRET_MAGIC;
> + ret->conn = conn;
> + conn->refs++;
> + ret->refs = 1;
> + ret->usageID = strdup(usageID);
Check for strdup() failure.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
^ permalink raw reply
* Re: [RFC v2] tcp: Export TCP Delayed ACK parameters to user
From: Daniel Baluta @ 2011-10-31 20:02 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, eric.dumazet, kuznet, jmorris, yoshfuji, kaber,
netdev, luto
In-Reply-To: <4EAEE487.5080905@hp.com>
On Mon, Oct 31, 2011 at 8:10 PM, Rick Jones <rick.jones2@hp.com> wrote:
> Whether tracked as bytes or segments, my take is that to ask applications to
> have to think about another non-portable socket option is ungood. I would
> suggest taking the time to work-out the automagic heuristic to drop the
> deferred ACK count on connections where it being large is un-desirable and
> then not need to worry about the limits being global.
Your suggestion deserves further investigation, it looks tricky to
find a good heuristic for increasing/decreasing the ACK deferred count.
>
> Given the stack's existing propensity to try to decide when to increase the
> window I might even go so far as to suggest the sense of the heuristic be
> flipped and it seek to decide when it is ok to increase the number of
> segments/bytes per ACK. To what extent one needs to go beyond what happens
> already with the stretching of ACKs via GRO/LRO or if that mechanism can
> serve as part of the logic of the heuristic is probably a fertile area for
> discussion.
>
> If I recall correctly, in one of your earlier posts you mentioned something
> about a 20% performance boost. What were the specific conditions of that
> testing? Was it over a setup where the receiver already had LRO/GRO or was
> it over a more plain receiver NIC without that functionality?
If I remember correctly on the receiver side there was no LRO/GRO, but we
tweaked some of /proc/sys/net/ipv4 parameters (e.g tcp_rmem).
Also, the traffic was highly unidirectional with many clients feeding multimedia
content to a server.
Anyhow, we used our custom kernel which is an older kernel version.
Are there any recommended benchmarks/tools for testing this kind of parameters?
Daniel.
^ permalink raw reply
* Re: [PATCH] ath3k: output firmware filename when request_firmware failed
From: Gustavo Padovan @ 2011-10-31 20:02 UTC (permalink / raw)
To: Paul Fertser; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <1319910769-28518-1-git-send-email-fercerpav@gmail.com>
Hi Paul,
* Paul Fertser <fercerpav@gmail.com> [2011-10-29 21:52:49 +0400]:
> This makes it much easier for the users to understand why the driver
> refuses to load when the firmware is unavailable.
>
> Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> ---
> drivers/bluetooth/ath3k.c | 15 +++++++++++----
> 1 files changed, 11 insertions(+), 4 deletions(-)
Applied, thanks.
Gustavo
^ permalink raw reply
* Re: [MIPS]clocks_calc_mult_shift() may gen a too big mult value
From: John Stultz @ 2011-10-31 19:51 UTC (permalink / raw)
To: David Daney
Cc: tglx@linutronix.de, zhangfx, Chen Jie, Yong Zhang,
linux-mips@linux-mips.org, LKML, yanhua, 项宇,
孙海勇
In-Reply-To: <4EAEE92D.4080402@gmail.com>
On Mon, 2011-10-31 at 11:30 -0700, David Daney wrote:
> On 10/31/2011 11:12 AM, John Stultz wrote:
> > + /*
> > + * Since mult may be adjusted by ntp, add an extra saftey margin
> > + * for clocksources that have large mults, to avoid overflow.
> > + *
> > + * Assume we won't try to correct for more then 5% adjustments
>
> Can we do any better than making assumptions about this?
>
> The current assumption appears to be that only very small adjustments
> will be made, and that didn't workout so well.
s/only very small/no/
The calc_mult_shift function doesn't take any adjustments into account.
> Is it possible to put hard constraints on these things, so that it will
> always work?
Fair enough. The patch was a bit off the cuff, and you're right that the
assumption is broken: ntp limits the freq adjustment to 500ppm, but the
kernel limits tick adjustments to 10%. Thus 11% adjustments (easier to
remember then 10.05%) would be the hard limit of adjustments from
external interfaces. So I'll need to rework the patch to adapt for that.
The harder part, once we put a hard constraint on the adjustment, is to
enforce that the timekeeping_bigadjust() doesn't push it beyond that,
since its logic uses relative adjustments and doesn't consider the
original mult value. Further, since its fairly opaque code, proving the
constraint itself won't break in edge cases is also needed, and will
take some time.
So yea, you're point is fair. Its just going to take a bit of thoughtful
review before implementing such a hard constraint universally.
So making a good adversary constraint first (11%), and then iteratively
hardening the code it impacts might be a good approach to get there.
thanks
-john
^ permalink raw reply
* Re: [PATCH 4/7] Input: ALPS - Remove assumptions about packet size
From: Seth Forshee @ 2011-10-31 20:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chase Douglas, Alessandro Rubini, Henrik Rydberg, Andrew Skalski,
linux-input, linux-kernel
In-Reply-To: <20111031182437.GA10551@core.coreip.homeip.net>
On Mon, Oct 31, 2011 at 11:24:37AM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 31, 2011 at 02:17:02PM -0400, Seth Forshee wrote:
> > On Sun, Oct 30, 2011 at 11:36:19AM -0400, Chase Douglas wrote:
> > > On 10/26/2011 05:14 PM, Seth Forshee wrote:
> > > > In preparation for version 4 protocol support, which has 8-byte
> > > > data packets, remove all hard-coded assumptions about packet size
> > > > and use psmouse->pktsize instead.
> > > >
> > > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > > ---
> > > > drivers/input/mouse/alps.c | 27 ++++++++++++++++++---------
> > > > 1 files changed, 18 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> > > > index 572cb21..14d1f64 100644
> > > > --- a/drivers/input/mouse/alps.c
> > > > +++ b/drivers/input/mouse/alps.c
> > > > @@ -315,7 +315,7 @@ static void alps_flush_packet(unsigned long data)
> > > >
> > > > serio_pause_rx(psmouse->ps2dev.serio);
> > > >
> > > > - if (psmouse->pktcnt == 6) {
> > > > + if (psmouse->pktcnt == psmouse->pktsize) {
> > > >
> > > > /*
> > > > * We did not any more data in reasonable amount of time.
> > > > @@ -365,15 +365,15 @@ static psmouse_ret_t alps_process_byte(struct psmouse *psmouse)
> > > > return PSMOUSE_BAD_DATA;
> > > > }
> > > >
> > > > - /* Bytes 2 - 6 should have 0 in the highest bit */
> > > > - if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= 6 &&
> > > > + /* Bytes 2 - pktsize should have 0 in the highest bit */
> > > > + if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= psmouse->pktsize &&
> > > > (psmouse->packet[psmouse->pktcnt - 1] & 0x80)) {
> > > > dbg("refusing packet[%i] = %x\n",
> > > > psmouse->pktcnt - 1, psmouse->packet[psmouse->pktcnt - 1]);
> > > > return PSMOUSE_BAD_DATA;
> > > > }
> > > >
> > > > - if (psmouse->pktcnt == 6) {
> > > > + if (psmouse->pktcnt == psmouse->pktsize) {
> > > > alps_process_packet(psmouse);
> > > > return PSMOUSE_FULL_PACKET;
> > > > }
> > > > @@ -531,8 +531,13 @@ static int alps_tap_mode(struct psmouse *psmouse, int enable)
> > > > static int alps_poll(struct psmouse *psmouse)
> > > > {
> > > > struct alps_data *priv = psmouse->private;
> > > > - unsigned char buf[6];
> > > > + unsigned char *buf;
> > > > bool poll_failed;
> > > > + int ret = -1;
> > > > +
> > > > + buf = kmalloc(psmouse->pktsize, GFP_KERNEL);
> > > > + if (!buf)
> > > > + return -1;
> > >
> > > Can we preallocate a buffer somewhere instead of allocating every time
> > > we enter the function? If we know the maximum packet size we could
> > > allocate on the stack instead.
> >
> > Thanks for pointing that out; I had meant to come back and do something
> > about this but forgot. I was hoping to avoid having to hard-code an
> > assumed maximum packet size. I'll take a look at it.
>
> probably doing something like
>
> unsigned char buf[sizeof(psmouse->packet)];
>
> will cover it.
Yes, that will work great. I'll incorporate that into the next version
of the patches. Thanks.
^ permalink raw reply
* Re: bigalloc and max file size
From: Ted Ts'o @ 2011-10-31 20:00 UTC (permalink / raw)
To: Tao Ma
Cc: Andreas Dilger, linux-ext4 development, Alex Zhuravlev,
hao.bigrat@gmail.com
In-Reply-To: <4EAE780D.3090005@tao.ma>
On Mon, Oct 31, 2011 at 06:27:25PM +0800, Tao Ma wrote:
> In the new bigalloc case if chunk size=64k, and with the linux-3.0
> source, every file will be allocated a chunk, but they aren't contiguous
> if we only write the 1st 4k bytes. In this case, writeback and the block
> layer below can't merge all the requests sent by ext4. And in our test
> case, the total io will be around 20000. While with the cluster size, we
> have to zero the whole cluster. From the upper point of view. we have to
> write more bytes. But from the block layer, the write is contiguous and
> it can merge them to be a big one. In our test, it will only do around
> 2000 ios. So it helps the test case.
This is test case then where there are lot of sub-64k files, and so
the system administrator would be ill-advised to use a 64k bigalloc
cluster size in the first place. So don't really consider that a
strong argument; in fact, if the block device is a SSD or a
thin-provisioned device with an allocation size smaller than the
cluster size, the behaviour you describe would in fact be detrimental,
not a benefit.
In the case of a hard drive where seeks are expensive relative to
small writes, this is something which we could do (zero out the whole
cluster) with the current bigalloc file system format. I could
imagine trying to turn this on automatically with a hueristic, but
since we can't know the underlying allocation size of a
thin-provisioned block device, that would be tricky at best...
Regards,
- Ted
^ permalink raw reply
* [PATCH 3/3] arm/dt: tegra: add dts file for paz00
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1320088857.git.marvin24@gmx.de>
This adds a dts file for paz00. As a side effect, this also enables
the embedded controller which controls the keyboard, touchpad, power,
leds, and some other functions.
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
---
arch/arm/boot/dts/tegra-paz00.dts | 78 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 3 +
4 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-paz00.dts
diff --git a/arch/arm/boot/dts/tegra-paz00.dts b/arch/arm/boot/dts/tegra-paz00.dts
new file mode 100644
index 0000000..7eebd16
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-paz00.dts
@@ -0,0 +1,78 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "Toshiba AC100 / Dynabook AZ";
+ compatible = "compal,paz00", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 root=/dev/mmcblk0p1";
+ };
+
+ memory at 0 {
+ reg = <0x00000000 0x20000000>;
+ };
+
+ i2c at 7000c000 {
+ clock-frequency = <400000>;
+ };
+
+ i2c at 7000c400 {
+ clock-frequency = <400000>;
+ };
+
+ i2c at 7000c500 {
+ status = "disable";
+ };
+
+ nvec at 7000c500 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,nvec";
+ reg = <0x7000C500 0x100>;
+ interrupts = <124>;
+ clock-frequency = <80000>;
+ request-gpios = <&gpio 170 0>;
+ slave-addr = <138>;
+ };
+
+ i2c at 7000d000 {
+ clock-frequency = <400000>;
+ };
+
+ serial at 70006000 {
+ clock-frequency = <216000000>;
+ };
+
+ serial at 70006040 {
+ status = "disable";
+ };
+
+ serial at 70006200 {
+ status = "disable";
+ };
+
+ serial at 70006300 {
+ clock-frequency = <216000000>;
+ };
+
+ sdhci at c8000000 {
+ cd-gpios = <&gpio 173 0>; /* gpio PV5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ };
+
+ sdhci at c8000200 {
+ status = "disable";
+ };
+
+ sdhci at c8000400 {
+ status = "disable";
+ };
+
+ sdhci at c8000600 {
+ support-8bit;
+ };
+};
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 91a07e1..b04ebfe6 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -31,6 +31,7 @@ obj-${CONFIG_MACH_SEABOARD} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-dt.o
obj-${CONFIG_MACH_TEGRA_DT} += board-harmony-pinmux.o
+obj-${CONFIG_MACH_TEGRA_DT} += board-paz00-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice.o
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index bd12c9f..152f9fb 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -3,5 +3,6 @@ params_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00000100
initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
+dtb-$(CONFIG_MACH_PAZ00) += tegra-paz00.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.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 d368f8d..379660e 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -46,6 +46,7 @@
#include "devices.h"
void harmony_pinmux_init(void);
+void paz00_pinmux_init(void);
void seaboard_pinmux_init(void);
void ventana_pinmux_init(void);
@@ -85,6 +86,7 @@ static struct {
void (*init)(void);
} pinmux_configs[] = {
{ "nvidia,harmony", harmony_pinmux_init },
+ { "compal,paz00", paz00_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[] = {
"nvidia,harmony",
+ "compal,paz00",
"nvidia,seaboard",
"nvidia,ventana",
NULL
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/3] arm/dt: tegra: add dts file for paz00
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA
Cc: Olof Johansson, Colin Cross, Stephen Warren, linux-arm-kernel,
Marc Dietrich, Grant Likely
In-Reply-To: <cover.1320088857.git.marvin24-Mmb7MZpHnFY@public.gmane.org>
This adds a dts file for paz00. As a side effect, this also enables
the embedded controller which controls the keyboard, touchpad, power,
leds, and some other functions.
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Signed-off-by: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>
---
arch/arm/boot/dts/tegra-paz00.dts | 78 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 3 +
4 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-paz00.dts
diff --git a/arch/arm/boot/dts/tegra-paz00.dts b/arch/arm/boot/dts/tegra-paz00.dts
new file mode 100644
index 0000000..7eebd16
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-paz00.dts
@@ -0,0 +1,78 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "Toshiba AC100 / Dynabook AZ";
+ compatible = "compal,paz00", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 root=/dev/mmcblk0p1";
+ };
+
+ memory@0 {
+ reg = <0x00000000 0x20000000>;
+ };
+
+ i2c@7000c000 {
+ clock-frequency = <400000>;
+ };
+
+ i2c@7000c400 {
+ clock-frequency = <400000>;
+ };
+
+ i2c@7000c500 {
+ status = "disable";
+ };
+
+ nvec@7000c500 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nvidia,nvec";
+ reg = <0x7000C500 0x100>;
+ interrupts = <124>;
+ clock-frequency = <80000>;
+ request-gpios = <&gpio 170 0>;
+ slave-addr = <138>;
+ };
+
+ i2c@7000d000 {
+ clock-frequency = <400000>;
+ };
+
+ serial@70006000 {
+ clock-frequency = <216000000>;
+ };
+
+ serial@70006040 {
+ status = "disable";
+ };
+
+ serial@70006200 {
+ status = "disable";
+ };
+
+ serial@70006300 {
+ clock-frequency = <216000000>;
+ };
+
+ sdhci@c8000000 {
+ cd-gpios = <&gpio 173 0>; /* gpio PV5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ };
+
+ sdhci@c8000200 {
+ status = "disable";
+ };
+
+ sdhci@c8000400 {
+ status = "disable";
+ };
+
+ sdhci@c8000600 {
+ support-8bit;
+ };
+};
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 91a07e1..b04ebfe6 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -31,6 +31,7 @@ obj-${CONFIG_MACH_SEABOARD} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-dt.o
obj-${CONFIG_MACH_TEGRA_DT} += board-harmony-pinmux.o
+obj-${CONFIG_MACH_TEGRA_DT} += board-paz00-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice.o
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index bd12c9f..152f9fb 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -3,5 +3,6 @@ params_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00000100
initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
+dtb-$(CONFIG_MACH_PAZ00) += tegra-paz00.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.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 d368f8d..379660e 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -46,6 +46,7 @@
#include "devices.h"
void harmony_pinmux_init(void);
+void paz00_pinmux_init(void);
void seaboard_pinmux_init(void);
void ventana_pinmux_init(void);
@@ -85,6 +86,7 @@ static struct {
void (*init)(void);
} pinmux_configs[] = {
{ "nvidia,harmony", harmony_pinmux_init },
+ { "compal,paz00", paz00_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[] = {
"nvidia,harmony",
+ "compal,paz00",
"nvidia,seaboard",
"nvidia,ventana",
NULL
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] staging: nvec: add device tree support
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1320088857.git.marvin24@gmx.de>
This adds device tree support to the nvec driver. By using this method
it is no longer necessary to specify platform data through a board
file.
Cc: devel at driverdev.osuosl.org
Cc: Greg KH <gregkh@suse.de>
Cc: Julian Andres Klode <jak@jak-linux.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
---
.../devicetree/bindings/nvec/nvec_nvidia.txt | 9 +++++
drivers/staging/nvec/nvec.c | 35 ++++++++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
diff --git a/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt b/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
new file mode 100644
index 0000000..5aeee53
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
@@ -0,0 +1,9 @@
+NVIDIA compliant embedded controller
+
+Required properties:
+- compatible : should be "nvidia,nvec".
+- reg : the iomem of the i2c slave controller
+- interrupts : the interrupt line of the i2c slave controller
+- clock-frequency : the frequency of the i2c bus
+- gpios : the gpio used for ec request
+- slave-addr: the i2c address of the slave controller
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index e06b867..ffb73c0 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -27,6 +27,8 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/list.h>
#include <linux/mfd/core.h>
#include <linux/mutex.h>
@@ -36,6 +38,8 @@
#include <linux/spinlock.h>
#include <linux/workqueue.h>
+#include <asm/byteorder.h>
+
#include <mach/clk.h>
#include <mach/iomap.h>
@@ -719,6 +723,7 @@ static int __devinit tegra_nvec_probe(struct platform_device *pdev)
struct resource *res;
struct resource *iomem;
void __iomem *base;
+ const unsigned int *prop;
nvec = kzalloc(sizeof(struct nvec_chip), GFP_KERNEL);
if (nvec == NULL) {
@@ -727,8 +732,26 @@ static int __devinit tegra_nvec_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, nvec);
nvec->dev = &pdev->dev;
- nvec->gpio = pdata->gpio;
- nvec->i2c_addr = pdata->i2c_addr;
+
+ if (pdata) {
+ nvec->gpio = pdata->gpio;
+ nvec->i2c_addr = pdata->i2c_addr;
+ } else if (nvec->dev->of_node) {
+ nvec->gpio = of_get_named_gpio(nvec->dev->of_node, "request-gpios", 0);
+ if (nvec->gpio < 0) {
+ dev_err(&pdev->dev, "no gpio specified");
+ goto failed;
+ }
+ prop = of_get_property(nvec->dev->of_node, "slave-addr", NULL);
+ if (!prop) {
+ dev_err(&pdev->dev, "no i2c address specified");
+ goto failed;
+ }
+ nvec->i2c_addr = be32_to_cpup(prop);
+ } else {
+ dev_err(&pdev->dev, "no platform data\n");
+ goto failed;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -893,6 +916,13 @@ static int tegra_nvec_resume(struct platform_device *pdev)
#define tegra_nvec_resume NULL
#endif
+/* Match table for of_platform binding */
+static const struct of_device_id nvidia_nvec_of_match[] __devinitconst = {
+ { .compatible = "nvidia,nvec", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, nvidia_nvec_of_match);
+
static struct platform_driver nvec_device_driver = {
.probe = tegra_nvec_probe,
.remove = __devexit_p(tegra_nvec_remove),
@@ -901,6 +931,7 @@ static struct platform_driver nvec_device_driver = {
.driver = {
.name = "nvec",
.owner = THIS_MODULE,
+ .of_match_table = nvidia_nvec_of_match,
}
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] staging: nvec: add device tree support
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA
Cc: Olof Johansson, Colin Cross, Stephen Warren, linux-arm-kernel,
Marc Dietrich, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Greg KH,
Julian Andres Klode, Grant Likely
In-Reply-To: <cover.1320088857.git.marvin24-Mmb7MZpHnFY@public.gmane.org>
This adds device tree support to the nvec driver. By using this method
it is no longer necessary to specify platform data through a board
file.
Cc: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org
Cc: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>
Cc: Julian Andres Klode <jak-4HMq4SXA452hPH1hqNUYSQ@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Signed-off-by: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>
---
.../devicetree/bindings/nvec/nvec_nvidia.txt | 9 +++++
drivers/staging/nvec/nvec.c | 35 ++++++++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
diff --git a/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt b/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
new file mode 100644
index 0000000..5aeee53
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
@@ -0,0 +1,9 @@
+NVIDIA compliant embedded controller
+
+Required properties:
+- compatible : should be "nvidia,nvec".
+- reg : the iomem of the i2c slave controller
+- interrupts : the interrupt line of the i2c slave controller
+- clock-frequency : the frequency of the i2c bus
+- gpios : the gpio used for ec request
+- slave-addr: the i2c address of the slave controller
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index e06b867..ffb73c0 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -27,6 +27,8 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/list.h>
#include <linux/mfd/core.h>
#include <linux/mutex.h>
@@ -36,6 +38,8 @@
#include <linux/spinlock.h>
#include <linux/workqueue.h>
+#include <asm/byteorder.h>
+
#include <mach/clk.h>
#include <mach/iomap.h>
@@ -719,6 +723,7 @@ static int __devinit tegra_nvec_probe(struct platform_device *pdev)
struct resource *res;
struct resource *iomem;
void __iomem *base;
+ const unsigned int *prop;
nvec = kzalloc(sizeof(struct nvec_chip), GFP_KERNEL);
if (nvec == NULL) {
@@ -727,8 +732,26 @@ static int __devinit tegra_nvec_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, nvec);
nvec->dev = &pdev->dev;
- nvec->gpio = pdata->gpio;
- nvec->i2c_addr = pdata->i2c_addr;
+
+ if (pdata) {
+ nvec->gpio = pdata->gpio;
+ nvec->i2c_addr = pdata->i2c_addr;
+ } else if (nvec->dev->of_node) {
+ nvec->gpio = of_get_named_gpio(nvec->dev->of_node, "request-gpios", 0);
+ if (nvec->gpio < 0) {
+ dev_err(&pdev->dev, "no gpio specified");
+ goto failed;
+ }
+ prop = of_get_property(nvec->dev->of_node, "slave-addr", NULL);
+ if (!prop) {
+ dev_err(&pdev->dev, "no i2c address specified");
+ goto failed;
+ }
+ nvec->i2c_addr = be32_to_cpup(prop);
+ } else {
+ dev_err(&pdev->dev, "no platform data\n");
+ goto failed;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -893,6 +916,13 @@ static int tegra_nvec_resume(struct platform_device *pdev)
#define tegra_nvec_resume NULL
#endif
+/* Match table for of_platform binding */
+static const struct of_device_id nvidia_nvec_of_match[] __devinitconst = {
+ { .compatible = "nvidia,nvec", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, nvidia_nvec_of_match);
+
static struct platform_driver nvec_device_driver = {
.probe = tegra_nvec_probe,
.remove = __devexit_p(tegra_nvec_remove),
@@ -901,6 +931,7 @@ static struct platform_driver nvec_device_driver = {
.driver = {
.name = "nvec",
.owner = THIS_MODULE,
+ .of_match_table = nvidia_nvec_of_match,
}
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/3] ARM: tegra: paz00: add support for wakeup gpio key
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1320088857.git.marvin24@gmx.de>
This adds support for a wakeup gpio which is connected to the
embedded controller. This will be used later on for wakeup from suspend.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
---
arch/arm/mach-tegra/board-paz00.c | 27 +++++++++++++++++++++++++++
arch/arm/mach-tegra/board-paz00.h | 3 +++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c
index 55c55ba..799e420 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -23,8 +23,10 @@
#include <linux/serial_8250.h>
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio_keys.h>
#include <linux/pda_power.h>
#include <linux/io.h>
+#include <linux/input.h>
#include <linux/i2c.h>
#include <linux/gpio.h>
#include <linux/rfkill-gpio.h>
@@ -114,12 +116,37 @@ static struct platform_device leds_gpio = {
},
};
+static struct gpio_keys_button paz00_gpio_keys_buttons[] = {
+ {
+ .code = KEY_POWER,
+ .gpio = TEGRA_GPIO_POWERKEY,
+ .active_low = 1,
+ .desc = "Power",
+ .type = EV_KEY,
+ .wakeup = 1,
+ },
+};
+
+static struct gpio_keys_platform_data paz00_gpio_keys = {
+ .buttons = paz00_gpio_keys_buttons,
+ .nbuttons = ARRAY_SIZE(paz00_gpio_keys_buttons),
+};
+
+static struct platform_device gpio_keys_device = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev = {
+ .platform_data = &paz00_gpio_keys,
+ },
+};
+
static struct platform_device *paz00_devices[] __initdata = {
&debug_uart,
&tegra_sdhci_device4,
&tegra_sdhci_device1,
&wifi_rfkill_device,
&leds_gpio,
+ &gpio_keys_device,
};
static void paz00_i2c_init(void)
diff --git a/arch/arm/mach-tegra/board-paz00.h b/arch/arm/mach-tegra/board-paz00.h
index 8aff06e..ffa83f5 100644
--- a/arch/arm/mach-tegra/board-paz00.h
+++ b/arch/arm/mach-tegra/board-paz00.h
@@ -32,6 +32,9 @@
#define TEGRA_WIFI_RST TEGRA_GPIO_PD1
#define TEGRA_WIFI_LED TEGRA_GPIO_PD0
+/* WakeUp */
+#define TEGRA_GPIO_POWERKEY TEGRA_GPIO_PJ7
+
void paz00_pinmux_init(void);
#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/3] ARM: tegra: paz00: add support for wakeup gpio key
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA
Cc: Olof Johansson, Colin Cross, Stephen Warren, linux-arm-kernel,
Marc Dietrich
In-Reply-To: <cover.1320088857.git.marvin24-Mmb7MZpHnFY@public.gmane.org>
This adds support for a wakeup gpio which is connected to the
embedded controller. This will be used later on for wakeup from suspend.
Signed-off-by: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>
---
arch/arm/mach-tegra/board-paz00.c | 27 +++++++++++++++++++++++++++
arch/arm/mach-tegra/board-paz00.h | 3 +++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c
index 55c55ba..799e420 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -23,8 +23,10 @@
#include <linux/serial_8250.h>
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio_keys.h>
#include <linux/pda_power.h>
#include <linux/io.h>
+#include <linux/input.h>
#include <linux/i2c.h>
#include <linux/gpio.h>
#include <linux/rfkill-gpio.h>
@@ -114,12 +116,37 @@ static struct platform_device leds_gpio = {
},
};
+static struct gpio_keys_button paz00_gpio_keys_buttons[] = {
+ {
+ .code = KEY_POWER,
+ .gpio = TEGRA_GPIO_POWERKEY,
+ .active_low = 1,
+ .desc = "Power",
+ .type = EV_KEY,
+ .wakeup = 1,
+ },
+};
+
+static struct gpio_keys_platform_data paz00_gpio_keys = {
+ .buttons = paz00_gpio_keys_buttons,
+ .nbuttons = ARRAY_SIZE(paz00_gpio_keys_buttons),
+};
+
+static struct platform_device gpio_keys_device = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev = {
+ .platform_data = &paz00_gpio_keys,
+ },
+};
+
static struct platform_device *paz00_devices[] __initdata = {
&debug_uart,
&tegra_sdhci_device4,
&tegra_sdhci_device1,
&wifi_rfkill_device,
&leds_gpio,
+ &gpio_keys_device,
};
static void paz00_i2c_init(void)
diff --git a/arch/arm/mach-tegra/board-paz00.h b/arch/arm/mach-tegra/board-paz00.h
index 8aff06e..ffa83f5 100644
--- a/arch/arm/mach-tegra/board-paz00.h
+++ b/arch/arm/mach-tegra/board-paz00.h
@@ -32,6 +32,9 @@
#define TEGRA_WIFI_RST TEGRA_GPIO_PD1
#define TEGRA_WIFI_LED TEGRA_GPIO_PD0
+/* WakeUp */
+#define TEGRA_GPIO_POWERKEY TEGRA_GPIO_PJ7
+
void paz00_pinmux_init(void);
#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 0/3] paz00 updates for 3.3
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
the following three patches are intended for the 3.3 merge window and are based
on linux-next.
The first one adds wakeup support similar to seaboard, but with the difference
that the wakeup gpio is connected to the embedded controller instead of a real
gpio key.
The second patch adds device tree support for the nvec driver. This way we can
make use of it without adding more platform devices to the board files (and it
is also modern to do so).
The final one adds device tree support for paz00. The way the nvec it is
initialized will probably change in the future, but we like to include it for
now as it makes debugging easier.
The patches are against linux-next from Oct 25th.
Thanks
Marc
Changes since v2
- remove the mem= from the bootargs, this is handled by the memory property
already
- change the root device until the sdhci init order can be changed
- do not init unused serial ports
- add dt documentation for nvec
- remove CONFIG_OF #ifdefs from nvec.c
- exchange the order of patch 2 and 3
Changes since v1
- replace addition of the embedded controller to the board file by a device-tree
based implementation.
Marc Dietrich (3):
ARM: tegra: paz00: add support for wakeup gpio key
staging: nvec: add device tree support
arm/dt: tegra: add dts file for paz00
.../devicetree/bindings/nvec/nvec_nvidia.txt | 9 ++
arch/arm/boot/dts/tegra-paz00.dts | 78 ++++++++++++++++++++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 3 +
arch/arm/mach-tegra/board-paz00.c | 27 +++++++
arch/arm/mach-tegra/board-paz00.h | 3 +
drivers/staging/nvec/nvec.c | 35 ++++++++-
8 files changed, 155 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
create mode 100644 arch/arm/boot/dts/tegra-paz00.dts
--
1.7.5.4
^ permalink raw reply
* [PATCH v3 0/3] paz00 updates for 3.3
From: Marc Dietrich @ 2011-10-31 19:58 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA
Cc: Olof Johansson, Colin Cross, Stephen Warren, linux-arm-kernel,
Marc Dietrich
Hi,
the following three patches are intended for the 3.3 merge window and are based
on linux-next.
The first one adds wakeup support similar to seaboard, but with the difference
that the wakeup gpio is connected to the embedded controller instead of a real
gpio key.
The second patch adds device tree support for the nvec driver. This way we can
make use of it without adding more platform devices to the board files (and it
is also modern to do so).
The final one adds device tree support for paz00. The way the nvec it is
initialized will probably change in the future, but we like to include it for
now as it makes debugging easier.
The patches are against linux-next from Oct 25th.
Thanks
Marc
Changes since v2
- remove the mem= from the bootargs, this is handled by the memory property
already
- change the root device until the sdhci init order can be changed
- do not init unused serial ports
- add dt documentation for nvec
- remove CONFIG_OF #ifdefs from nvec.c
- exchange the order of patch 2 and 3
Changes since v1
- replace addition of the embedded controller to the board file by a device-tree
based implementation.
Marc Dietrich (3):
ARM: tegra: paz00: add support for wakeup gpio key
staging: nvec: add device tree support
arm/dt: tegra: add dts file for paz00
.../devicetree/bindings/nvec/nvec_nvidia.txt | 9 ++
arch/arm/boot/dts/tegra-paz00.dts | 78 ++++++++++++++++++++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 3 +
arch/arm/mach-tegra/board-paz00.c | 27 +++++++
arch/arm/mach-tegra/board-paz00.h | 3 +
drivers/staging/nvec/nvec.c | 35 ++++++++-
8 files changed, 155 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvec/nvec_nvidia.txt
create mode 100644 arch/arm/boot/dts/tegra-paz00.dts
--
1.7.5.4
^ permalink raw reply
* why does the kernel use mutex to protect the address_space structure
From: Zheng Da @ 2011-10-31 19:57 UTC (permalink / raw)
To: kernelnewbies
Hello,
I try to understand why the kernel uses mutex to protect the
address_space structure. I checked the critical areas protected by
i_mmap_mutex, and didn't see these areas use IO. I don't see why we
can't use spin locks. Do I miss something? It seems most of critical
areas provided by i_mmap_mutex aren't very large.
Thanks,
Da
^ permalink raw reply
* Re: [PATCH] Bluetooth: bfusb: Fix error path on firmware load
From: Gustavo Padovan @ 2011-10-31 19:55 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth, marcel
In-Reply-To: <1319620966-11193-1-git-send-email-dh.herrmann@googlemail.com>
Hi David,
* David Herrmann <dh.herrmann@googlemail.com> [2011-10-26 11:22:46 +0200]:
> When loading the usb-configuration we do not signal the end of configuration on
> memory allocation error. This patch moves the memory allocation to the top so
> every error path uses "goto error" now to correctly send the usb-ctrl message
> when detecting some error.
>
> This also replaces GFP_ATOMIC with GFP_KERNEL as we are allowed to sleep here.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> drivers/bluetooth/bfusb.c | 13 +++++++------
> 1 files changed, 7 insertions(+), 6 deletions(-)
Applied, thanks.
Gustavo
^ permalink raw reply
* Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
From: Ming Lei @ 2011-10-31 19:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM list, mark gross, LKML, John Stultz, Alan Stern,
NeilBrown
In-Reply-To: <201110132145.42270.rjw@sisk.pl>
Hi,
On Fri, Oct 14, 2011 at 3:45 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Second, to address the backup problem, we need to allow user space
> processes other than the suspend/hibernate process itself to prevent the
> system from being put into sleep states. A mechanism for that is introduced
> by the second patch in the form of the /dev/sleepctl special device working
> kind of like user space wakelocks on Android (although in a simplified
> fashion).
I also have another similar example: write(fd, buffer, 100*4096).
Suppose only 80*4096 are copied into pages of the file, then someone
run ' echo mem > /sys/power/state ' to trigger system sleep, so only
partial writing is completed before system sleep and data inconsistence
may be caused for the file on filesystem.
But I am not sure if it is possible to happen in reality.
thank,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: bcm203x: Use GFP_KERNEL in workqueue
From: Gustavo Padovan @ 2011-10-31 19:55 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth, marcel
In-Reply-To: <1319570016-7439-2-git-send-email-dh.herrmann@googlemail.com>
Hi David,
* David Herrmann <dh.herrmann@googlemail.com> [2011-10-25 21:13:36 +0200]:
> A workqueue is allowed to sleep so we can safely use GFP_KERNEL instead of
> GFP_ATOMIC. This is still legacy code when the driver used timer BHs and not a
> worqueue.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> drivers/bluetooth/bcm203x.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
Gustavo
^ permalink raw reply
* Re: Reference has invalid format: check maybe a bit to harsh?
From: Junio C Hamano @ 2011-10-31 19:54 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Michael Haggerty
In-Reply-To: <60007404.ge1WXNp2Qn@soybean>
Peter Oberndorfer <kumbayo84@arcor.de> writes:
> The invalid refs(about 30, loose and packed) containing a ':' were created by
> stgit a long time ago(Dec 2006)
I think even back then colon was one of the forbidden letters in a
refname. Of course, it is entirely possible that broken third-party tools
may have created such file that is not a ref in .git/refs hierarchy by
hand, and we may not be carefully rejecting such broken refs for a long
time.
... Goes and asks "git blame" ...
03feddd (git-check-ref-format: reject funny ref names., 2005-10-13)
started disallowing control characters and other characters that are used
for range operators and the separator between LHS and RHS of refspecs,
further tightened by 6828399 (Forbid pattern maching characters in
refnames., 2005-12-15).
> But i'm just wondering if dieing when seeing a single invalid ref might be a
> bit too harsh since no git tools can be used anymore on this repo at all.
I agree that we would want to give users an escape hatch. That is, if we
can make something like this to work:
c=$(git rev-parse --force refs/patches/obd_development/blah:_vari...)
git update-ref refs/patches/obd_development/blah--various-improvements $c
I think we would be in a good shape.
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: bcm203x: Fix race condition on disconnect
From: Gustavo Padovan @ 2011-10-31 19:54 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth, marcel
In-Reply-To: <1319620393-11127-1-git-send-email-dh.herrmann@googlemail.com>
Hi David,
* David Herrmann <dh.herrmann@googlemail.com> [2011-10-26 11:13:13 +0200]:
> When disconnecting a bcm203x device we kill and destroy the usb-urb, however,
> there might still be a pending work-structure which resubmits the now invalid
> urb. To avoid this race condition, we simply set a shutdown-flag and
> synchronously kill the worker first.
>
> This also adds a comment to all schedule_work()s, as it is really not clear
> that they are used as replacement for short timers (which can be seen in the git
> history).
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> V2: Remove memory barriers
>
> drivers/bluetooth/bcm203x.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
Applied, thanks.
Gustavo
^ 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.