Re: [PATCH] drm/doc: Fixing xml documentation warning
On Fri, Aug 21, 2015 at 04:46:14PM -0300, Danilo Cesar Lemes de Paula wrote:
> "/**" should be used for kernel-doc documentation only.
> It causes a warning with the new "in struct body" format.
>
> Signed-off-by: Danilo Cesar Lemes de Paula
> Cc: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Jonathan Corbet
> Cc: Herbert Xu
> Cc: Stephan Mueller
> Cc: Michal Marek
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx
> Cc: dri-devel
> Cc: Graham Whaley
Applied to drm-misc, thanks.
-Daniel
> ---
> include/drm/drm_modeset_lock.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
> index 70595ff..c16a3ec 100644
> --- a/include/drm/drm_modeset_lock.h
> +++ b/include/drm/drm_modeset_lock.h
> @@ -43,19 +43,19 @@ struct drm_modeset_acquire_ctx {
>
> struct ww_acquire_ctx ww_ctx;
>
> - /**
> + /*
>* Contended lock: if a lock is contended you should only call
>* drm_modeset_backoff() which drops locks and slow-locks the
>* contended lock.
>*/
> struct drm_modeset_lock *contended;
>
> - /**
> + /*
>* list of held locks (drm_modeset_lock)
>*/
> struct list_head locked;
>
> - /**
> + /*
>* Trylock mode, use only for panic handlers!
>*/
> bool trylock_only;
> @@ -70,12 +70,12 @@ struct drm_modeset_acquire_ctx {
> * Used for locking CRTCs and other modeset resources.
> */
> struct drm_modeset_lock {
> - /**
> + /*
>* modeset lock
>*/
> struct ww_mutex mutex;
>
> - /**
> + /*
>* Resources that are locked as part of an atomic update are added
>* to a list (so we know what to unlock at the end).
>*/
> --
> 2.4.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 09/17] vfio: Register/unregister irq_bypass_producer
This patch adds the registration/unregistration of an
irq_bypass_producer for MSI/MSIx on vfio pci devices.
v6:
- Make the add_consumer and del_consumer callbacks static
- Remove pointless INIT_LIST_HEAD to 'vdev->ctx[vector].producer.node)'
- Use dev_info instead of WARN_ON() when irq_bypass_register_producer fails
- Remove optional dummy callbacks for irq producer
Signed-off-by: Feng Wu
---
drivers/vfio/pci/vfio_pci_intrs.c | 9 +
drivers/vfio/pci/vfio_pci_private.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 1f577b4..c65299d 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -319,6 +319,7 @@ static int vfio_msi_set_vector_signal(struct
vfio_pci_device *vdev,
if (vdev->ctx[vector].trigger) {
free_irq(irq, vdev->ctx[vector].trigger);
+ irq_bypass_unregister_producer(>ctx[vector].producer);
kfree(vdev->ctx[vector].name);
eventfd_ctx_put(vdev->ctx[vector].trigger);
vdev->ctx[vector].trigger = NULL;
@@ -360,6 +361,14 @@ static int vfio_msi_set_vector_signal(struct
vfio_pci_device *vdev,
return ret;
}
+ vdev->ctx[vector].producer.token = trigger;
+ vdev->ctx[vector].producer.irq = irq;
+ ret = irq_bypass_register_producer(>ctx[vector].producer);
+ if (unlikely(ret))
+ dev_info(>dev,
+ "irq bypass producer (token %p) registeration fails: %d\n",
+ vdev->ctx[vector].producer.token, ret);
+
vdev->ctx[vector].trigger = trigger;
return 0;
diff --git a/drivers/vfio/pci/vfio_pci_private.h
b/drivers/vfio/pci/vfio_pci_private.h
index ae0e1b4..0e7394f 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -13,6 +13,7 @@
#include
#include
+#include
#ifndef VFIO_PCI_PRIVATE_H
#define VFIO_PCI_PRIVATE_H
@@ -29,6 +30,7 @@ struct vfio_pci_irq_ctx {
struct virqfd *mask;
char*name;
boolmasked;
+ struct irq_bypass_producer producer;
};
struct vfio_pci_device {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 07/17] KVM: make kvm_set_msi_irq() public
Make kvm_set_msi_irq() public, we can use this function outside.
Signed-off-by: Feng Wu
---
arch/x86/include/asm/kvm_host.h | 4
arch/x86/kvm/irq_comm.c | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c4f99f1..82d0709 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -175,6 +175,8 @@ enum {
*/
#define KVM_APIC_PV_EOI_PENDING1
+struct kvm_kernel_irq_routing_entry;
+
/*
* We don't want allocation failures within the mmu code, so we preallocate
* enough memory for a single page fault in a cache.
@@ -1212,4 +1214,6 @@ int x86_set_memory_region(struct kvm *kvm,
bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
struct kvm_vcpu **dest_vcpu);
+void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
+struct kvm_lapic_irq *irq);
#endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
index a9572a13..1319c60 100644
--- a/arch/x86/kvm/irq_comm.c
+++ b/arch/x86/kvm/irq_comm.c
@@ -91,8 +91,8 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
kvm_lapic *src,
return r;
}
-static inline void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
- struct kvm_lapic_irq *irq)
+void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
+struct kvm_lapic_irq *irq)
{
trace_kvm_msi_set_irq(e->msi.address_lo, e->msi.data);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 10/17] KVM: x86: Update IRTE for posted-interrupts
This patch adds the routine to update IRTE for posted-interrupts
when guest changes the interrupt configuration.
Signed-off-by: Feng Wu
---
arch/x86/kvm/x86.c | 73 ++
1 file changed, 73 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5ef2560..8f09a76 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -63,6 +63,7 @@
#include /* Ugh! */
#include
#include
+#include
#define MAX_IO_MSRS 256
#define KVM_MAX_MCE_BANKS 32
@@ -8248,6 +8249,78 @@ bool kvm_arch_has_noncoherent_dma(struct kvm *kvm)
}
EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
+/*
+ * kvm_arch_update_pi_irte - set IRTE for Posted-Interrupts
+ *
+ * @kvm: kvm
+ * @host_irq: host irq of the interrupt
+ * @guest_irq: gsi of the interrupt
+ * @set: set or unset PI
+ * returns 0 on success, < 0 on failure
+ */
+int kvm_arch_update_pi_irte(struct kvm *kvm, unsigned int host_irq,
+ uint32_t guest_irq, bool set)
+{
+ struct kvm_kernel_irq_routing_entry *e;
+ struct kvm_irq_routing_table *irq_rt;
+ struct kvm_lapic_irq irq;
+ struct kvm_vcpu *vcpu;
+ struct vcpu_data vcpu_info;
+ int idx, ret = -EINVAL;
+
+ if (!irq_remapping_cap(IRQ_POSTING_CAP))
+ return 0;
+
+ idx = srcu_read_lock(>irq_srcu);
+ irq_rt = srcu_dereference(kvm->irq_routing, >irq_srcu);
+ BUG_ON(guest_irq >= irq_rt->nr_rt_entries);
+
+ hlist_for_each_entry(e, _rt->map[guest_irq], link) {
+ if (e->type != KVM_IRQ_ROUTING_MSI)
+ continue;
+ /*
+* VT-d PI cannot support posting multicast/broadcast
+* interrupts to a VCPU, we still use interrupt remapping
+* for these kind of interrupts.
+*
+* For lowest-priority interrupts, we only support
+* those with single CPU as the destination, e.g. user
+* configures the interrupts via /proc/irq or uses
+* irqbalance to make the interrupts single-CPU.
+*
+* We will support full lowest-priority interrupt later.
+*
+*/
+
+ kvm_set_msi_irq(e, );
+ if (!kvm_intr_is_single_vcpu(kvm, , ))
+ continue;
+
+ vcpu_info.pi_desc_addr = kvm_x86_ops->get_pi_desc_addr(vcpu);
+ vcpu_info.vector = irq.vector;
+
+ if (set)
+ ret = irq_set_vcpu_affinity(host_irq, _info);
+ else {
+ /* suppress notification event before unposting */
+ kvm_x86_ops->pi_set_sn(vcpu);
+ ret = irq_set_vcpu_affinity(host_irq, NULL);
+ kvm_x86_ops->pi_clear_sn(vcpu);
+ }
+
+ if (ret < 0) {
+ printk(KERN_INFO "%s: failed to update PI IRTE\n",
+ __func__);
+ goto out;
+ }
+ }
+
+ ret = 0;
+out:
+ srcu_read_unlock(>irq_srcu, idx);
+ return ret;
+}
+
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 12/17] KVM: Implement IRQ bypass consumer callbacks for x86
Implement the following callbacks for x86:
- kvm_arch_irq_bypass_add_producer
- kvm_arch_irq_bypass_del_producer
- kvm_arch_irq_bypass_stop: dummy callback
- kvm_arch_irq_bypass_resume: dummy callback
and set CONFIG_HAVE_KVM_IRQ_BYPASS for x86.
Signed-off-by: Feng Wu
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/Kconfig| 1 +
arch/x86/kvm/x86.c | 34 ++
3 files changed, 36 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 82d0709..3038c1b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index c951d44..b90776f 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -30,6 +30,7 @@ config KVM
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQFD
select IRQ_BYPASS_MANAGER
+ select HAVE_KVM_IRQ_BYPASS
select HAVE_KVM_IRQ_ROUTING
select HAVE_KVM_EVENTFD
select KVM_APIC_ARCHITECTURE
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8f09a76..be4b561 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -50,6 +50,8 @@
#include
#include
#include
+#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -8321,6 +8323,38 @@ out:
return ret;
}
+int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
+ struct irq_bypass_producer *prod)
+{
+ struct kvm_kernel_irqfd *irqfd =
+ container_of(cons, struct kvm_kernel_irqfd, consumer);
+
+ irqfd->producer = prod;
+
+ return kvm_arch_update_pi_irte(irqfd->kvm, prod->irq, irqfd->gsi, 1);
+}
+
+void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
+ struct irq_bypass_producer *prod)
+{
+ int ret;
+ struct kvm_kernel_irqfd *irqfd =
+ container_of(cons, struct kvm_kernel_irqfd, consumer);
+
+ irqfd->producer = NULL;
+
+ /*
+* When producer of consumer is unregistered, we change back to
+* remapped mode, so we can re-use the current implementation
+* when the irq is masked/disabed or the consumer side (KVM
+* int this case doesn't want to receive the interrupts.
+ */
+ ret = kvm_arch_update_pi_irte(irqfd->kvm, prod->irq, irqfd->gsi, 0);
+ if (ret)
+ printk(KERN_INFO "irq bypass consumer (token %p) unregistration"
+ " fails: %d\n", irqfd->consumer.token, ret);
+}
+
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 14/17] KVM: Update Posted-Interrupts Descriptor when vCPU is preempted
This patch updates the Posted-Interrupts Descriptor when vCPU
is preempted.
sched out:
- Set 'SN' to suppress furture non-urgent interrupts posted for
the vCPU.
sched in:
- Clear 'SN'
- Change NDST if vCPU is scheduled to a different CPU
- Set 'NV' to POSTED_INTR_VECTOR
Signed-off-by: Feng Wu
---
arch/x86/kvm/vmx.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 234f720..9c87064 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include "trace.h"
#include "pmu.h"
@@ -2001,10 +2002,60 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int
cpu)
vmcs_writel(HOST_IA32_SYSENTER_ESP, sysenter_esp); /* 22.2.3 */
vmx->loaded_vmcs->cpu = cpu;
}
+
+ if (irq_remapping_cap(IRQ_POSTING_CAP)) {
+ struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+ struct pi_desc old, new;
+ unsigned int dest;
+
+ do {
+ old.control = new.control = pi_desc->control;
+
+ /*
+* If 'nv' field is POSTED_INTR_WAKEUP_VECTOR, there
+* are two possible cases:
+* 1. After running 'pi_pre_block', context switch
+*happened. For this case, 'sn' was set in
+*vmx_vcpu_put(), so we need to clear it here.
+* 2. After running 'pi_pre_block', we were blocked,
+*and woken up by some other guy. For this case,
+*we don't need to do anything, 'pi_post_block'
+*will do everything for us. However, we cannot
+*check whether it is case #1 or case #2 here
+*(maybe, not needed), so we also clear sn here,
+*I think it is not a big deal.
+*/
+ if (pi_desc->nv != POSTED_INTR_WAKEUP_VECTOR) {
+ if (vcpu->cpu != cpu) {
+ dest = cpu_physical_id(cpu);
+
+ if (x2apic_enabled())
+ new.ndst = dest;
+ else
+ new.ndst = (dest << 8) & 0xFF00;
+ }
+
+ /* set 'NV' to 'notification vector' */
+ new.nv = POSTED_INTR_VECTOR;
+ }
+
+ /* Allow posting non-urgent interrupts */
+ new.sn = 0;
+ } while (cmpxchg(_desc->control, old.control,
+ new.control) != old.control);
+ }
}
static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
{
+ if (irq_remapping_cap(IRQ_POSTING_CAP)) {
+ struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+
+ /* Set SN when the vCPU is preempted */
+ if (vcpu->preempted)
+ pi_set_sn(pi_desc);
+ }
+
__vmx_load_host_state(to_vmx(vcpu));
if (!vmm_exclusive) {
__loaded_vmcs_clear(to_vmx(vcpu)->loaded_vmcs);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
* Ingo Molnar wrote:
>
> * Johannes Berg wrote:
>
> > On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote:
> >
> > > This time around, I employed a linker trick to convert the structures
> > > containing extended error information into integers, which are then made
> > > to
> > > look just like normal error codes so that IS_ERR_VALUE() and friends
> > > would
> > > still work correctly on them. So no extra pointers in the struct
> > > perf_event
> > > or anywhere else; the extended error codes are passed around like normal
> > > error codes. They only need to be converted in syscalls' topmost return
> > > statements. This is done in 1/6.
> >
> > For the record, as we discussed separately, I'd love to see this move to
> > more
> > general infrastructure. In wireless (nl80211), for example, we have a few
> > hundred (!) callsites returning -EINVAL, mostly based on malformed netlink
> > attributes, and it can be very difficult to figure out what went wrong;
> > debugging mostly employs a variation of Hugh's trick.
>
> Absolutely, I suggested this as well earlier today, as the scheduler would
> like
> to make use of it in syscalls with extensible ABIs, such as sched_setattr().
>
> If people really like this then we could go farther as well and add a
> standalone
> 'extended errors system call' as well (SyS_errno_extended_get()), which would
> allow the recovery of error strings even for system calls that are not easily
> extensible. We could cache the last error description in the task struct.
If we do that then we don't even have to introduce per system call error code
conversion, but could unconditionally save the last extended error info in the
task struct and continue - this could be done very cheaply with the linker
trick
driven integer ID.
I.e. system calls could opt in to do:
return err_str(-EBUSY, "perf/x86: BTS conflicts with active events");
and the overhead of this would be minimal, we'd essentially do something like
this
to save the error:
current->err_code = code;
where 'code' is a build time constant in essence.
We could use this even in system calls where the error path is performance
critical, as all the string recovery and copying overhead would be triggered by
applications that opt in via the new system call:
struct err_desc {
const char *message;
const char *owner;
const int code;
};
SyS_err_get_desc(struct err_desc *err_desc __user);
[ Which could perhaps be a prctl() extension as well (PR_GET_ERR_DESC): finally
some truly matching functionality for prctl(). ]
Hm?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote: > On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: [...] > > + -analogix,link-rate: > > + max link rate supported by the eDP controller. > > + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A, > > + LINK_RATE_5_40GBPS = 0x14 > > Same here. I'd rather see something like "link-rate-mbps" and use the > actual rate. There is no need whatsoever to hard-code this in DT. (e)DP provides the means to detect what rate the link supports and the specification provides guidance on how to select an appropriate one. > > > + -analogix,lane-count: > > + max number of lanes supported by the eDP contoller. > > + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 > > And drop the vendor prefix here. Same as for the link rate. Thierry signature.asc Description: PGP signature
RE: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table
Hi Joerg,
In commit message:
> There is a bug in iommu_context_addr() which will always use the lower
> context table, event when the upper context table needs to be used. Fix this
> issue.
I think it should be " even when the upper context table ", not "event".
Thanks!
Best Regards
Nan Xiao
-Original Message-
From: j...@8bytes.org [mailto:j...@8bytes.org]
Sent: Tuesday, August 25, 2015 5:00 PM
To: Xiao, Nan (Nan@HPservers-Core-OE-PSC)
Cc: dw...@infradead.org; io...@lists.linux-foundation.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower
extended-context-table
On Tue, Aug 25, 2015 at 08:46:27AM +, Xiao, Nan (Nan@HPservers-Core-OE-PSC)
wrote:
> Yes, your patch is simple and better!
Okay, I queued this patch to my x86/vt-d branch:
>From 03932776424a799c3f065a69e98076a78530288b Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Tue, 25 Aug 2015 10:54:28 +0200
Subject: [PATCH] iommu/vt-d: Really use upper context table when necessary
There is a bug in iommu_context_addr() which will always use the lower context
table, event when the upper context table needs to be used. Fix this issue.
Fixes: 03ecc32c5274 ("iommu/vt-d: support extended root and context entries")
Reported-by: Xiao, Nan
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
a85077d..63daf1b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -803,6 +803,7 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
struct context_entry *context;
u64 *entry;
+ entry = >lo;
if (ecs_enabled(iommu)) {
if (devfn >= 0x80) {
devfn -= 0x80;
@@ -810,7 +811,6 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
}
devfn *= 2;
}
- entry = >lo;
if (*entry & 1)
context = phys_to_virt(*entry & VTD_PAGE_MASK);
else {
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: rcar: GPIO_RCAR doesn't relate to ARM
On Tue, Aug 25, 2015 at 11:12 AM, Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> 8cd1470("gpio: rcar: Add r8a7795 (R-Car H3) support") added
> GPIO support for r8a7795. r8a7795 based on CONFIG_ARM64.
> OTOH, GPIO_RCAR driver can be compiled fine on non-ARM.
> This patch removed ARM dependency for it.
>
> Signed-off-by: Kuninori Morimoto
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote: > On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux > wrote: > > On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote: > >> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: > >> > + -analogix,color-depth: > >> > + number of bits per colour component. > >> > + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 > >> > = 3 > >> > >> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And > >> drop the vendor prefix. > > > > Please think about this some more. What does "color-depth" mean? Does it > > mean the number of bits per colour _component_, or does it mean the total > > number of bits to represent a particular colour. It's confusing as it > > stands. > > Then "component-color-bpp" perhaps? There should be no need to have this in DT at all. The BPC is a property of the attached panel and it should come from the panel (either the panel driver or parsed from EDID if available). > > When we adopted the graph bindings for iMX DRM, I thought exactly at that > > time "it would be nice if this could become the standard for binding DRM > > components together" but I don't have the authority from either the DT > > perspective or the DRM perspective to mandate that. Neither does anyone > > else. That's the _real_ problem here. > > > > I've seen several DRM bindings go by which don't use the of-graph stuff, > > which means that they'll never be compatible with generic components > > which do use the of-graph stuff. > > It goes beyond bindings IMO. The use of the component framework or not > has been at the whim of driver writers as well. It is either used or > private APIs are created. I'm using components and my need for it > boils down to passing the struct drm_device pointer to the encoder. > Other components like panels and bridges have different ways to attach > to the DRM driver. I certainly support unification, but it needs to be reasonable. There are cases where a different structure for the binding work better than another and I think this always needs to be evaluated on a case by case basis. Because of that I think it makes sense to make all these framework bits opt-in, otherwise we could easily end up in a situation where drivers have to be rearchitected (or even DT bindings altered!) in order to be able to reuse code. Thierry signature.asc Description: PGP signature
[PATCH v2 01/11] mmc: host: omap_hsmmc: Support vmmc_aux to switch to 1.8v
Add support for vmmc_aux to switch to 1.8v. Also use "iov" instead of
"vdd" to indicate io voltage. This is in preparation for adding support
for io signal voltage switch.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 48 +++--
1 file changed, 32 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d884d8f..9c13157 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -244,11 +244,12 @@ static int omap_hsmmc_get_cover_state(struct device *dev)
return mmc_gpio_get_cd(host->mmc);
}
-static int omap_hsmmc_enable_supply(struct mmc_host *mmc)
+static int omap_hsmmc_enable_supply(struct mmc_host *mmc, int iov)
{
int ret;
struct omap_hsmmc_host *host = mmc_priv(mmc);
struct mmc_ios *ios = >ios;
+ int uvoltage;
if (mmc->supply.vmmc) {
ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
@@ -257,7 +258,25 @@ static int omap_hsmmc_enable_supply(struct mmc_host *mmc)
}
/* Enable interface voltage rail, if needed */
- if (mmc->supply.vqmmc && !host->vqmmc_enabled) {
+ if (mmc->supply.vqmmc) {
+ if (host->vqmmc_enabled) {
+ ret = regulator_disable(mmc->supply.vqmmc);
+ if (ret) {
+ dev_err(mmc_dev(mmc),
+ "vmmc_aux reg disable failed\n");
+ goto err_vqmmc;
+ }
+ host->vqmmc_enabled = 0;
+ }
+
+ uvoltage = (iov == VDD_165_195) ? VDD_1V8 : VDD_3V0;
+ ret = regulator_set_voltage(mmc->supply.vqmmc, uvoltage,
+ uvoltage);
+ if (ret) {
+ dev_err(mmc_dev(mmc), "vmmc_aux set voltage failed\n");
+ goto err_vqmmc;
+ }
+
ret = regulator_enable(mmc->supply.vqmmc);
if (ret) {
dev_err(mmc_dev(mmc), "vmmc_aux reg enable failed\n");
@@ -309,22 +328,19 @@ err_set_ocr:
}
static int omap_hsmmc_set_pbias(struct omap_hsmmc_host *host, bool power_on,
- int vdd)
+ int iov)
{
int ret;
+ int uvoltage;
if (!host->pbias)
return 0;
if (power_on) {
- if (vdd <= VDD_165_195)
- ret = regulator_set_voltage(host->pbias, VDD_1V8,
- VDD_1V8);
- else
- ret = regulator_set_voltage(host->pbias, VDD_3V0,
- VDD_3V0);
- if (ret < 0) {
- dev_err(host->dev, "pbias set voltage fail\n");
+ uvoltage = (iov <= VDD_165_195) ? VDD_1V8 : VDD_3V0;
+ ret = regulator_set_voltage(host->pbias, uvoltage, uvoltage);
+ if (ret) {
+ dev_err(host->dev, "pbias set voltage failed\n");
return ret;
}
@@ -348,7 +364,7 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host
*host, bool power_on,
return 0;
}
-static int omap_hsmmc_set_power(struct device *dev, int power_on, int vdd)
+static int omap_hsmmc_set_power(struct device *dev, int power_on, int iov)
{
struct omap_hsmmc_host *host =
platform_get_drvdata(to_platform_device(dev));
@@ -363,7 +379,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
return 0;
if (mmc_pdata(host)->before_set_reg)
- mmc_pdata(host)->before_set_reg(dev, power_on, vdd);
+ mmc_pdata(host)->before_set_reg(dev, power_on, iov);
ret = omap_hsmmc_set_pbias(host, false, 0);
if (ret)
@@ -383,11 +399,11 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- ret = omap_hsmmc_enable_supply(mmc);
+ ret = omap_hsmmc_enable_supply(mmc, iov);
if (ret)
return ret;
- ret = omap_hsmmc_set_pbias(host, true, vdd);
+ ret = omap_hsmmc_set_pbias(host, true, iov);
if (ret)
goto err_set_voltage;
} else {
@@ -397,7 +413,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
}
if (mmc_pdata(host)->after_set_reg)
- mmc_pdata(host)->after_set_reg(dev, power_on, vdd);
+ mmc_pdata(host)->after_set_reg(dev, power_on, iov);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: [PATCH] gpio: rcar: Enable r8a7795 for ARM64
Hi Geert > > config GPIO_RCAR > > tristate "Renesas R-Car GPIO" > > - depends on ARM && (ARCH_SHMOBILE || COMPILE_TEST) > > + depends on (ARM || ARM64) && (ARCH_SHMOBILE || COMPILE_TEST) > > As this driver seems to compile fine on non-ARM, what about relaxing the > dependency to > > depends on ARCH_SHMOBILE || COMPILE_TEST I posted updated one, thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/11] omap_hsmmc: voltage switching and tuning
Patch series implements voltage switching and tuning for omap_hsmmc driver. Changes from v1: *) rebased on top of [1] *) Patch breaking omap3 beagle xm is fixed. (set clk rate patch was breaking beagle xm) [1] -> https://lkml.org/lkml/2015/8/21/125 Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, Beaglebone black, OMAP5 uEVM and OMAP4 PANDA, OMAP3 beagle xm. Also performed PM suspend/resume test with OMAP3 beagle xm. Balaji T K (2): mmc: host: omap_hsmmc: add voltage switch support for UHS SD card mmc: host: omap_hsmmc: add tuning support Kishon Vijay Abraham I (8): mmc: host: omap_hsmmc: Support vmmc_aux to switch to 1.8v mmc: host: omap_hsmmc: separate setting voltage capabilities from bus power mmc: host: omap_hsmmc: program HCTL based on signal_voltage set by mmc core mmc: host: omap_hsmmc: set clk rate to the max frequency mmc: host: omap_hsmmc: set timing in the UHSMS field mmc: host: omap_hsmmc: Workaround for errata id i802 mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd mmc: host: omap_hsmmc: remove incorrect voltage switch sequence Mugunthan V N (1): mmc: host: omap_hsmmc: add software timer when timeout greater than hardware capablility drivers/mmc/host/omap_hsmmc.c | 677 + 1 file changed, 554 insertions(+), 123 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/5] arm64: add KASan support
On Mon, Aug 24, 2015 at 06:47:36PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 24, 2015 at 05:15:22PM +0300, Andrey Ryabinin wrote: > > Yes, ~130Mb (3G/1G split) should work. 512Mb shadow is optional. > > The only advantage of 512Mb shadow is better handling of user memory > > accesses bugs > > (access to user memory without copy_from_user/copy_to_user/strlen_user etc > > API). > > No need for that to be handed by KASan. I have patches in linux-next, > now acked by Will, which prevent the kernel accessing userspace with > zero memory footprint. No need for remapping, we have a way to quickly > turn off access to userspace mapped pages on non-LPAE 32-bit CPUs. > (LPAE is not supported yet - Catalin will be working on that using the > hooks I'm providing once he returns.) Hey, I only acked the "Efficiency cleanups" series so far! The PAN emulation is still on my list. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
and another is KVM_FAST_MMIO_BUS. This leads to issue:
- kvm_io_bus_destroy() knows nothing about the devices on two buses
points to a single dev. Which will lead double free [1] during exit.
- wildcard eventfd ignores data len, so it was registered as a
kvm_io_range with zero length. This will fail the binary search in
kvm_io_bus_get_first_dev() when we try to emulate through
KVM_MMIO_BUS. This will cause userspace io emulation request instead
of a eventfd notification (virtqueue kick will be trapped by qemu
instead of vhost in this case).
Fixing this by don't register wildcard mmio eventfd on two
buses. Instead, only register it in KVM_FAST_MMIO_BUS. This fixes the
double free issue of kvm_io_bus_destroy(). For the arch/setups that
does not utilize KVM_FAST_MMIO_BUS, before searching KVM_MMIO_BUS, try
KVM_FAST_MMIO_BUS first to see it it has a match.
[1] Panic caused by double free:
CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f
RIP: 0010:[] []
ioeventfd_release+0x28/0x60 [kvm]
RSP: 0018:88020e7f3bc8 EFLAGS: 00010292
RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d
RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900
RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d
R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000
R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880
FS: 7fc1ee3e6700() GS:88023e24() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0
Stack:
88021e7cc000 88020e7f3be8 c07e2622
88020e7f3c38 c07df69a 880232524160 88020e792d80
880219b78c00 0008 8802321686a8
Call Trace:
[] ioeventfd_destructor+0x12/0x20 [kvm]
[] kvm_put_kvm+0xca/0x210 [kvm]
[] kvm_vcpu_release+0x18/0x20 [kvm]
[] __fput+0xe7/0x250
[] fput+0xe/0x10
[] task_work_run+0xd4/0xf0
[] do_exit+0x368/0xa50
[] ? recalc_sigpending+0x1f/0x60
[] do_group_exit+0x45/0xb0
[] get_signal+0x291/0x750
[] do_signal+0x28/0xab0
[] ? do_futex+0xdb/0x5d0
[] ? __wake_up_locked_key+0x18/0x20
[] ? SyS_futex+0x76/0x170
[] do_notify_resume+0x69/0xb0
[] int_signal+0x12/0x17
Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20
e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01
10 00 00
RIP [] ioeventfd_release+0x28/0x60 [kvm]
RSP
Cc: Gleb Natapov
Cc: Paolo Bonzini
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
Changes from V2:
- Tweak styles and comment suggested by Cornelia.
Changes from v1:
- change ioeventfd_bus_from_flags() to return KVM_FAST_MMIO_BUS when
needed to save lots of unnecessary changes.
---
virt/kvm/eventfd.c | 31 +--
virt/kvm/kvm_main.c | 16 ++--
2 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 9ff4193..c3ffdc3 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -762,13 +762,16 @@ ioeventfd_check_collision(struct kvm *kvm, struct
_ioeventfd *p)
return false;
}
-static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
+static enum kvm_bus ioeventfd_bus_from_args(struct kvm_ioeventfd *args)
{
- if (flags & KVM_IOEVENTFD_FLAG_PIO)
+ if (args->flags & KVM_IOEVENTFD_FLAG_PIO)
return KVM_PIO_BUS;
- if (flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
+ if (args->flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
return KVM_VIRTIO_CCW_NOTIFY_BUS;
- return KVM_MMIO_BUS;
+ /* When length is ignored, MMIO is put on a separate bus, for
+* faster lookups.
+*/
+ return args->len ? KVM_MMIO_BUS : KVM_FAST_MMIO_BUS;
}
static int
@@ -779,7 +782,7 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
*args)
struct eventfd_ctx *eventfd;
int ret;
- bus_idx = ioeventfd_bus_from_flags(args->flags);
+ bus_idx = ioeventfd_bus_from_args(args);
/* must be natural-word sized, or 0 to ignore length */
switch (args->len) {
case 0:
@@ -843,16 +846,6 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd
*args)
if (ret < 0)
goto unlock_fail;
- /* When length is ignored, MMIO is also put on a separate bus, for
-* faster lookups.
-*/
- if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
- ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
- p->addr, 0, >dev);
- if (ret < 0)
- goto register_fail;
- }
Re: [RESEND PATCH 6/7] leds: Export OF module alias information in missing drivers
On 08/25/2015 08:31 AM, Javier Martinez Canillas wrote: The I2C core always reports the MODALIAS uevent as "i2c:" regardless of the mechanism that was used to register the device (i.e: OF or board code) and the table that is used later to match the driver with the device (i.e: I2C id table or OF match table). So drivers needs to export the I2C id table and this be built into the module or udev won't have the necessary information to autoload the needed driver module when the device is added. But this means that OF-only drivers needs to have both OF and I2C id tables that have to be kept in sync and also the dev node compatible manufacturer prefix is stripped when reporting the MODALIAS. Which can lead to issues if two vendors use the same I2C device name for example. To avoid the above, the I2C core behavior may be changed in the future to not require an SPI device table for OF-only drivers and report the OF module alias. So, it's better to also export the OF table even when is unused now to prevent breaking module loading when the core changes. Signed-off-by: Javier Martinez Canillas Acked-by: Jacek Anaszewski --- drivers/leds/leds-pca963x.c | 1 + drivers/leds/leds-tca6507.c | 1 + 2 files changed, 2 insertions(+) Merged, thanks. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: rcar: GPIO_RCAR doesn't relate to ARM
From: Kuninori Morimoto
8cd1470("gpio: rcar: Add r8a7795 (R-Car H3) support") added
GPIO support for r8a7795. r8a7795 based on CONFIG_ARM64.
OTOH, GPIO_RCAR driver can be compiled fine on non-ARM.
This patch removed ARM dependency for it.
Signed-off-by: Kuninori Morimoto
---
This was "gpio: rcar: Enable r8a7795 for ARM64"
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..8949b3f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -356,7 +356,7 @@ config GPIO_PXA
config GPIO_RCAR
tristate "Renesas R-Car GPIO"
- depends on ARM && (ARCH_SHMOBILE || COMPILE_TEST)
+ depends on ARCH_SHMOBILE || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
Say yes here to support GPIO on Renesas R-Car SoCs.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
平时最多也就联系了三千家，全球还有十几万客户在哪里？
您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ2821117472给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/3] kvm: use kmalloc() instead of kzalloc() during iodev register/unregister
All fields of kvm_io_range were initialized or copied explicitly afterwards. So switch to use kmalloc(). Cc: Gleb Natapov Cc: Paolo Bonzini Cc: Michael S. Tsirkin Signed-off-by: Jason Wang --- virt/kvm/kvm_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8b8a444..0d79fe8 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3248,7 +3248,7 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus bus_idx, gpa_t addr, if (bus->dev_count - bus->ioeventfd_count > NR_IOBUS_DEVS - 1) return -ENOSPC; - new_bus = kzalloc(sizeof(*bus) + ((bus->dev_count + 1) * + new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count + 1) * sizeof(struct kvm_io_range)), GFP_KERNEL); if (!new_bus) return -ENOMEM; @@ -3280,7 +3280,7 @@ int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx, if (r) return r; - new_bus = kzalloc(sizeof(*bus) + ((bus->dev_count - 1) * + new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) * sizeof(struct kvm_io_range)), GFP_KERNEL); if (!new_bus) return -ENOMEM; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 3/3] kvm: add tracepoint for fast mmio
Cc: Gleb Natapov
Cc: Paolo Bonzini
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
arch/x86/kvm/trace.h | 17 +
arch/x86/kvm/vmx.c | 1 +
arch/x86/kvm/x86.c | 1 +
3 files changed, 19 insertions(+)
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 4eae7c3..2d4e81a 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -128,6 +128,23 @@ TRACE_EVENT(kvm_pio,
__entry->count > 1 ? "(...)" : "")
);
+TRACE_EVENT(kvm_fast_mmio,
+ TP_PROTO(u64 gpa),
+ TP_ARGS(gpa),
+
+ TP_STRUCT__entry(
+ __field(u64,gpa)
+ ),
+
+ TP_fast_assign(
+ __entry->gpa= gpa;
+ ),
+
+ TP_printk("fast mmio at gpa 0x%llx", __entry->gpa)
+);
+
+
+
/*
* Tracepoint for cpuid.
*/
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 83b7b5c..a55d279 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5831,6 +5831,7 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu)
gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) {
skip_emulated_instruction(vcpu);
+ trace_kvm_fast_mmio(gpa);
return 1;
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8f0f6ec..36cf78e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8254,6 +8254,7 @@ bool kvm_arch_has_noncoherent_dma(struct kvm *kvm)
EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_fast_mmio);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_msr);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/11] mmc: host: omap_hsmmc: separate setting voltage capabilities from bus power
Added a separate function to set the voltage capabilities of the host
controller. Voltage capabilities should be set only once during
controller initialization but bus power can be changed every time there
is a voltage switch and whenever a different card is inserted.
This allows omap_hsmmc_conf_bus_power to be invoked every time there
is a voltage switch.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9c13157..fd8cc81 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1821,25 +1821,34 @@ err:
return ret;
}
+static void omap_hsmmc_set_capabilities(struct omap_hsmmc_host *host)
+{
+ u32 val;
+
+ val = OMAP_HSMMC_READ(host->base, CAPA);
+
+ /* Only MMC1 supports 3.0V */
+ if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
+ val |= (VS30 | VS18);
+ else
+ val |= VS18;
+
+ OMAP_HSMMC_WRITE(host->base, CAPA, val);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
- u32 hctl, capa, value;
+ u32 hctl, value;
/* Only MMC1 supports 3.0V */
- if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
+ if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
hctl = SDVS30;
- capa = VS30 | VS18;
- } else {
+ else
hctl = SDVS18;
- capa = VS18;
- }
value = OMAP_HSMMC_READ(host->base, HCTL) & ~SDVS_MASK;
OMAP_HSMMC_WRITE(host->base, HCTL, value | hctl);
- value = OMAP_HSMMC_READ(host->base, CAPA);
- OMAP_HSMMC_WRITE(host->base, CAPA, value | capa);
-
/* Set SD bus power bit */
set_sd_bus_power(host);
}
@@ -2143,6 +2152,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc->pm_caps |= mmc_pdata(host)->pm_caps;
+ omap_hsmmc_set_capabilities(host);
omap_hsmmc_conf_bus_power(host);
if (!pdev->dev.of_node) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 15/17] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
This patch updates the Posted-Interrupts Descriptor when vCPU
is blocked.
pre-block:
- Add the vCPU to the blocked per-CPU list
- Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
post-block:
- Remove the vCPU from the per-CPU list
Signed-off-by: Feng Wu
---
arch/x86/include/asm/kvm_host.h | 5 ++
arch/x86/kvm/vmx.c | 151
arch/x86/kvm/x86.c | 55 ---
include/linux/kvm_host.h| 3 +
virt/kvm/kvm_main.c | 3 +
5 files changed, 207 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 22269b4..32af275 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -554,6 +554,8 @@ struct kvm_vcpu_arch {
*/
bool write_fault_to_shadow_pgtable;
+ bool halted;
+
/* set at EPT violation at this point */
unsigned long exit_qualification;
@@ -868,6 +870,9 @@ struct kvm_x86_ops {
void (*pi_clear_sn)(struct kvm_vcpu *vcpu);
void (*pi_set_sn)(struct kvm_vcpu *vcpu);
+
+ int (*pi_pre_block)(struct kvm_vcpu *vcpu);
+ void (*pi_post_block)(struct kvm_vcpu *vcpu);
/* pmu operations of sub-arch */
const struct kvm_pmu_ops *pmu_ops;
};
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9c87064..64e35ea 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -888,6 +888,13 @@ static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
+/*
+ * We maintian a per-CPU linked-list of vCPU, so in wakeup_handler() we
+ * can find which vCPU should be waken up.
+ */
+static DEFINE_PER_CPU(struct list_head, blocked_vcpu_on_cpu);
+static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
+
static unsigned long *vmx_io_bitmap_a;
static unsigned long *vmx_io_bitmap_b;
static unsigned long *vmx_msr_bitmap_legacy;
@@ -2981,6 +2988,8 @@ static int hardware_enable(void)
return -EBUSY;
INIT_LIST_HEAD(_cpu(loaded_vmcss_on_cpu, cpu));
+ INIT_LIST_HEAD(_cpu(blocked_vcpu_on_cpu, cpu));
+ spin_lock_init(_cpu(blocked_vcpu_on_cpu_lock, cpu));
/*
* Now we can enable the vmclear operation in kdump
@@ -6106,6 +6115,25 @@ static void update_ple_window_actual_max(void)
ple_window_grow, INT_MIN);
}
+/*
+ * Handler for POSTED_INTERRUPT_WAKEUP_VECTOR.
+ */
+static void wakeup_handler(void)
+{
+ struct kvm_vcpu *vcpu;
+ int cpu = smp_processor_id();
+
+ spin_lock(_cpu(blocked_vcpu_on_cpu_lock, cpu));
+ list_for_each_entry(vcpu, _cpu(blocked_vcpu_on_cpu, cpu),
+ blocked_vcpu_list) {
+ struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+
+ if (pi_test_on(pi_desc) == 1)
+ kvm_vcpu_kick(vcpu);
+ }
+ spin_unlock(_cpu(blocked_vcpu_on_cpu_lock, cpu));
+}
+
static __init int hardware_setup(void)
{
int r = -ENOMEM, i, msr;
@@ -6290,6 +6318,8 @@ static __init int hardware_setup(void)
kvm_x86_ops->enable_log_dirty_pt_masked = NULL;
}
+ kvm_set_posted_intr_wakeup_handler(wakeup_handler);
+
return alloc_kvm_area();
out8:
@@ -10414,6 +10444,124 @@ static void vmx_enable_log_dirty_pt_masked(struct kvm
*kvm,
kvm_mmu_clear_dirty_pt_masked(kvm, memslot, offset, mask);
}
+/*
+ * This routine does the following things for vCPU which is going
+ * to be blocked if VT-d PI is enabled.
+ * - Store the vCPU to the wakeup list, so when interrupts happen
+ * we can find the right vCPU to wake up.
+ * - Change the Posted-interrupt descriptor as below:
+ * 'NDST' <-- vcpu->pre_pcpu
+ * 'NV' <-- POSTED_INTR_WAKEUP_VECTOR
+ * - If 'ON' is set during this process, which means at least one
+ * interrupt is posted for this vCPU, we cannot block it, in
+ * this case, return 1, otherwise, return 0.
+ *
+ */
+static int vmx_pi_pre_block(struct kvm_vcpu *vcpu)
+{
+ unsigned long flags;
+ unsigned int dest;
+ struct pi_desc old, new;
+ struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+
+ if (!irq_remapping_cap(IRQ_POSTING_CAP))
+ return 0;
+
+ vcpu->pre_pcpu = vcpu->cpu;
+ spin_lock_irqsave(_cpu(blocked_vcpu_on_cpu_lock,
+ vcpu->pre_pcpu), flags);
+ list_add_tail(>blocked_vcpu_list,
+ _cpu(blocked_vcpu_on_cpu,
+ vcpu->pre_pcpu));
+ spin_unlock_irqrestore(_cpu(blocked_vcpu_on_cpu_lock,
+ vcpu->pre_pcpu), flags);
+
+ do {
+ old.control = new.control = pi_desc->control;
+
+ /*
+* We should not block the vCPU if
+* an interrupt is posted for it.
+*/
+ if
[PATCH v2 04/11] mmc: host: omap_hsmmc: add voltage switch support for UHS SD card
From: Balaji T K
UHS sd card i/o data line can operate at 3V and 1.8V on UHS speed
modes. Add support for signal voltage switch and check for card_busy.
Signed-off-by: Balaji T K
Signed-off-by: Sourav Poddar
[kis...@ti.com : cleanup the voltage switch sequence]
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 129 +
1 file changed, 129 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d3fe0f8..7dac486 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -112,6 +112,9 @@
/* PSTATE */
#define DLEV_DAT(x)(1 << (20 + (x)))
+/* AC12 */
+#define AC12_V1V8_SIGEN(1 << 19)
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
#define TC_EN (1 << 1)
@@ -151,6 +154,12 @@
#define VDD_1V8180 /* 18 uV */
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+#define VDD_30_31 (ffs(MMC_VDD_30_31) - 1)
+
+#define CON_CLKEXTFREE (1 << 16)
+#define CON_PADEN (1 << 15)
+#define PSTATE_CLEV(1 << 24)
+#define PSTATE_DLEV(0xF << 20)
/*
* One controller can have multiple slots, like on some omap boards using
@@ -1860,6 +1869,124 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card
*card,
return blk_size;
}
+static int omap_hsmmc_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ struct omap_hsmmc_host *host;
+ u32 val = 0;
+ int ret = 0;
+
+ host = mmc_priv(mmc);
+
+ if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
+ val = OMAP_HSMMC_READ(host->base, CAPA);
+ if (!(val & VS30))
+ return -EOPNOTSUPP;
+
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
+
+ val = OMAP_HSMMC_READ(host->base, AC12);
+ val &= ~AC12_V1V8_SIGEN;
+ OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+ ret = mmc_pdata(host)->set_power(host->dev, 1, VDD_30_31);
+ if (ret) {
+ dev_dbg(mmc_dev(host->mmc), "failed to switch to 3v\n");
+ return ret;
+ }
+
+ dev_dbg(mmc_dev(host->mmc), " i/o voltage switch to 3V\n");
+ } else if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+ val = OMAP_HSMMC_READ(host->base, CAPA);
+ if (!(val & VS18))
+ return -EOPNOTSUPP;
+
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
+
+ val = OMAP_HSMMC_READ(host->base, AC12);
+ val |= AC12_V1V8_SIGEN;
+ OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+ ret = mmc_pdata(host)->set_power(host->dev, 1, VDD_165_195);
+ if (ret < 0) {
+ dev_dbg(mmc_dev(host->mmc), "failed to switch 1.8v\n");
+ return ret;
+ }
+ } else {
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static int omap_hsmmc_card_busy_low(struct omap_hsmmc_host *host)
+{
+ u32 val;
+ unsigned long timeout;
+
+ val = OMAP_HSMMC_READ(host->base, CON);
+ val &= ~CON_CLKEXTFREE;
+ val |= CON_PADEN;
+ OMAP_HSMMC_WRITE(host->base, CON, val);
+
+ timeout = jiffies + msecs_to_jiffies(1);
+ do {
+ val = OMAP_HSMMC_READ(host->base, PSTATE);
+ if (!(val & (PSTATE_CLEV | PSTATE_DLEV)))
+ return true;
+
+ usleep_range(100, 200);
+ } while (!time_after(jiffies, timeout));
+
+ dev_err(mmc_dev(host->mmc), "timeout : i/o low 0x%x\n", val);
+
+ return false;
+}
+
+static int omap_hsmmc_card_busy_high(struct omap_hsmmc_host *host)
+{
+ u32 val;
+ unsigned long timeout;
+
+ val = OMAP_HSMMC_READ(host->base, CON);
+ val |= CLKEXTFREE;
+ OMAP_HSMMC_WRITE(host->base, CON, val);
+
+ timeout = jiffies + msecs_to_jiffies(1);
+ do {
+ val = OMAP_HSMMC_READ(host->base, PSTATE);
+ if ((val & PSTATE_CLEV) && (val & PSTATE_DLEV)) {
+ val = OMAP_HSMMC_READ(host->base, CON);
+ val &= ~(CON_CLKEXTFREE | CON_PADEN);
+ OMAP_HSMMC_WRITE(host->base, CON, val);
+ return false;
+ }
+
+ usleep_range(100, 200);
+ } while (!time_after(jiffies, timeout));
+
+ dev_err(mmc_dev(host->mmc), "timeout : i/o high 0x%x\n", val);
+
+ return true;
+}
+
+static int omap_hsmmc_card_busy(struct mmc_host *mmc)
+{
+ struct omap_hsmmc_host *host;
+ u32 val;
+ int ret;
+
+
[PATCH v2 06/11] mmc: host: omap_hsmmc: set timing in the UHSMS field
Add a separate function to set the UHSMS field to one
of SDR104, SDR50, DDR50, SDR25 or SDR12 depending on the
inserted SD card. This is required for
tuning to succeed in the case of SDR104/HS200 or SDR50.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 60c1ac2..c042b91 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,13 @@
/* AC12 */
#define AC12_V1V8_SIGEN(1 << 19)
+#define AC12_UHSMC_MASK(7 << 16)
+#define AC12_UHSMC_SDR12 (0 << 16)
+#define AC12_UHSMC_SDR25 (1 << 16)
+#define AC12_UHSMC_SDR50 (2 << 16)
+#define AC12_UHSMC_SDR104 (3 << 16)
+#define AC12_UHSMC_DDR50 (4 << 16)
+#define AC12_UHSMC_RES (0x7 << 16)
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
@@ -199,6 +206,7 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
+ unsigned char timing;
int suspended;
u32 con;
u32 hctl;
@@ -1667,6 +1675,41 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
omap_hsmmc_start_command(host, req->cmd, req->data);
}
+static void omap_hsmmc_set_timing(struct omap_hsmmc_host *host)
+{
+ u32 val;
+ struct mmc_ios *ios = >mmc->ios;
+
+ omap_hsmmc_stop_clock(host);
+
+ val = OMAP_HSMMC_READ(host->base, AC12);
+ val &= ~AC12_UHSMC_MASK;
+ switch (ios->timing) {
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ val |= AC12_UHSMC_SDR104;
+ break;
+ case MMC_TIMING_UHS_DDR50:
+ val |= AC12_UHSMC_DDR50;
+ break;
+ case MMC_TIMING_UHS_SDR50:
+ val |= AC12_UHSMC_SDR50;
+ break;
+ case MMC_TIMING_UHS_SDR25:
+ val |= AC12_UHSMC_SDR25;
+ break;
+ case MMC_TIMING_UHS_SDR12:
+ val |= AC12_UHSMC_SDR12;
+ break;
+ default:
+ val |= AC12_UHSMC_RES;
+ break;
+ }
+ OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+ omap_hsmmc_start_clock(host);
+}
+
/* Routine to configure clock values. Exposed API to core */
static void omap_hsmmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
@@ -1715,6 +1758,11 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
omap_hsmmc_set_clock(host);
+ if (ios->timing != host->timing) {
+ omap_hsmmc_set_timing(host);
+ host->timing = ios->timing;
+ }
+
if (do_send_init_stream)
send_init_stream(host);
@@ -2204,6 +2252,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->mapbase = res->start + pdata->reg_offset;
host->base = base + pdata->reg_offset;
host->power_mode = MMC_POWER_OFF;
+ host->timing= 0;
host->next_data.cookie = 1;
host->vqmmc_enabled = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
This patch adds support for R-Car generation 3 USB2 PHY driver.
This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
with the HSUSB (USB2.0 peripheral) device.
So, the purpose of this driver is:
1) initializes some registers of SoC specific to use the
{ehci,ohci}-platform driver.
2) detects id pin to select host or peripheral on the channel 0.
For now, this driver only supports 1) above.
Signed-off-by: Yoshihiro Shimoda
---
This patch is based on the latest linux-phy / next branch.
(commit id = cfd093bbb5fe84ec8c7bb069fe618159a8b601f5)
Changes from v1:
- Revise some typos.
- Remove using clk API to enable/disable the clocks.
(In other words, this driver expects to enable/disable the clocks by
Runtime PM API by the phy-core driver.)
- Remove an unnecessary header file (asm/cmpxchg.h).
.../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 35 +++
drivers/phy/Kconfig| 6 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rcar-gen3-usb2.c | 240 +
4 files changed, 282 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
new file mode 100644
index 000..1d57766
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -0,0 +1,35 @@
+* Renesas R-Car generation 3 USB 2.0 PHY
+
+This file provides information on what the device node for the R-Car generation
+3 USB 2.0 PHY contains.
+
+Required properties:
+- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795
+ SoC.
+- reg: offset and length of the USB2.0 host register block.
+- reg-names: must be "usb2".
+- clocks: clock phandle and specifier pair(s).
+- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
+
+Optional properties:
+To use a USB channel where EHCI/OHCI and HSUSB are combined, the device tree
+node should set HSUSB properties to reg and reg-names properties:
+- reg: offset and length of the HSUSB register block.
+- reg-names: must be "hsusb".
+
+Example (R-Car H3):
+
+ usb-phy@ee080200 {
+ compatible = "renesas,usb2-phy-r8a7795";
+ reg = <0 0xee080200 0 0x6ff>, <0 0xe6590100 0 0x100>;
+ reg-names = "usb2", "hsusb";
+ clocks = <_clks R8A7795_CLK_EHCI0>,
+<_clks R8A7795_CLK_HSUSB>;
+ };
+
+ usb-phy@ee0a0200 {
+ compatible = "renesas,usb2-phy-r8a7795";
+ reg = <0 0xee0a0200 0 0x6ff>;
+ reg-names = "usb2";
+ clocks = <_clks R8A7795_CLK_EHCI0>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0fe9bff..406dc43 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -116,6 +116,12 @@ config PHY_RCAR_GEN2
help
Support for USB PHY found on Renesas R-Car generation 2 SoCs.
+config PHY_RCAR_GEN3_USB2
+ tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
+ depends on GENERIC_PHY
+ help
+ Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
+
config OMAP_CONTROL_PHY
tristate "OMAP CONTROL PHY Driver"
depends on ARCH_OMAP2PLUS || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..97e83bc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_MIPHY28LP)+= phy-miphy28lp.o
obj-$(CONFIG_PHY_MIPHY365X)+= phy-miphy365x.o
obj-$(CONFIG_PHY_RCAR_GEN2)+= phy-rcar-gen2.o
+obj-$(CONFIG_PHY_RCAR_GEN3_USB2) += phy-rcar-gen3-usb2.o
obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
new file mode 100644
index 000..2c2fcf9
--- /dev/null
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -0,0 +1,240 @@
+/*
+ * Renesas R-Car Gen3 for USB2.0 PHY driver
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * This is based on the phy-rcar-gen2 driver:
+ * Copyright (C) 2014 Renesas Solutions Corp.
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*** USB2.0 Host registers (original offset is +0x200) ***/
+#define USB2_INT_ENABLE0x000
+#define USB2_USBCTR0x00c
+#define
[PATCH v2 09/11] mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd
Now that vmmc regulator is made optional, do not bail out if vmmc regulator is not found. Signed-off-by: Kishon Vijay Abraham I --- drivers/mmc/host/omap_hsmmc.c |7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 9ab0f6e..f553b5f 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -440,13 +440,6 @@ static int omap_hsmmc_set_power(struct device *dev, int power_on, int iov) struct mmc_host *mmc = host->mmc; int ret = 0; - /* -* If we don't see a Vcc regulator, assume it's a fixed -* voltage always-on regulator. -*/ - if (!mmc->supply.vmmc) - return 0; - if (mmc_pdata(host)->before_set_reg) mmc_pdata(host)->before_set_reg(dev, power_on, iov); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/11] mmc: host: omap_hsmmc: add tuning support
From: Balaji T K
MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.
The tuning function omap_execute_tuning() will only
be called by the MMC/SD core if the corresponding
speed modes are supported by the OMAP silicon which
is set in the mmc host "caps" field.
Signed-off-by: Balaji T K
Signed-off-by: Viswanath Puttagunta
Signed-off-by: Sourav Poddar
[kis...@ti.com : cleanup the tuning sequence]
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 234 -
1 file changed, 232 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c042b91..43485c3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -49,6 +50,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
+#define OMAP_HSMMC_DLL 0x0034
#define OMAP_HSMMC_SDMASA 0x0100
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -66,6 +68,7 @@
#define OMAP_HSMMC_ISE 0x0138
#define OMAP_HSMMC_AC120x013C
#define OMAP_HSMMC_CAPA0x0140
+#define OMAP_HSMMC_CAPA2 0x0144
#define VS18 (1 << 26)
#define VS30 (1 << 25)
@@ -114,6 +117,7 @@
/* AC12 */
#define AC12_V1V8_SIGEN(1 << 19)
+#define AC12_SCLK_SEL (1 << 23)
#define AC12_UHSMC_MASK(7 << 16)
#define AC12_UHSMC_SDR12 (0 << 16)
#define AC12_UHSMC_SDR25 (1 << 16)
@@ -122,6 +126,18 @@
#define AC12_UHSMC_DDR50 (4 << 16)
#define AC12_UHSMC_RES (0x7 << 16)
+/* DLL */
+#define DLL_SWT(1 << 20)
+#define DLL_FORCE_SR_C_SHIFT 13
+#define DLL_FORCE_SR_C_MASK0x7f
+#define DLL_FORCE_VALUE(1 << 12)
+#define DLL_CALIB (1 << 1)
+
+#define MAX_PHASE_DELAY0x7c
+
+/* CAPA2 */
+#define CAPA2_TSDR50 (1 << 13)
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
#define TC_EN (1 << 1)
@@ -202,6 +218,7 @@ struct omap_hsmmc_host {
int vqmmc_enabled;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
+ struct completion buf_ready;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -229,6 +246,9 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
+ u32 *tuning_data;
+ int tuning_size;
+
/* return MMC cover switch state, can be NULL if not supported.
*
* possible return values:
@@ -245,8 +265,39 @@ struct omap_mmc_of_data {
u8 controller_flags;
};
+static const u8 ref_tuning_4bits[] = {
+ 0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
+ 0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
+ 0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
+ 0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
+ 0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
+ 0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
+ 0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
+ 0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
+};
+
+static const u8 ref_tuning_8bits[] = {
+ 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
+ 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
+ 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
+ 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
+ 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
+ 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
+ 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
+ 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
+ 0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
+ 0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
+ 0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
+ 0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
+ 0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
+ 0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
+ 0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
+ 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
+};
+
static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov);
+static void omap_hsmmc_disable_tuning(struct omap_hsmmc_host *host);
static int omap_hsmmc_card_detect(struct device *dev)
{
@@ -609,8 +660,12 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
{
u32 irq_mask = INT_EN_MASK;
unsigned long flags;
+ bool
[PATCH v2 08/11] mmc: host: omap_hsmmc: Workaround for errata id i802
According to errata i802, DCRC error interrupts
(MMCHS_STAT[21] DCRC=0x1) can occur during the tuning procedure.
The DCRC interrupt, occurs when the last tuning block fails
(the last ratio tested). The delay from CRC check until the
interrupt is asserted is bigger than the delay until assertion
of the tuning end flag. Assertion of tuning end flag is what
masks the interrupts. Because of this race, an erroneous DCRC
interrupt occurs.
The suggested workaround is to disable DCRC interrupts during
the tuning procedure which is implemented here.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Sekhar Nori
---
drivers/mmc/host/omap_hsmmc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 43485c3..9ab0f6e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -665,8 +665,17 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
is_tuning = (cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
(cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200);
- if (!is_tuning && host->use_dma)
+ if (is_tuning) {
+ /*
+* OMAP5/DRA74X/DRA72x Errata i802:
+* DCRC error interrupts (MMCHS_STAT[21] DCRC=0x1) can occur
+* during the tuning procedure. So disable it during the
+* tuning procedure.
+*/
+ irq_mask &= ~DCRC_EN;
+ } else if (host->use_dma) {
irq_mask &= ~(BRR_EN | BWR_EN);
+ }
/* Disable timeout for erases */
if (cmd->opcode == MMC_ERASE)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v3 RESEND] mfd: 88pm80x: Add 88pm860 chip type support
Add chip identification support for 88PM860 device
to the pm80x_chip_mapping table.
Signed-off-by: Vaibhav Hiremath
Reviewed-by: Krzysztof Kozlowski
Acked-by: Lee Jones
---
drivers/mfd/88pm80x.c | 2 ++
include/linux/mfd/88pm80x.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 5e72f65..63445ea 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -33,6 +33,8 @@ static struct pm80x_chip_mapping chip_mapping[] = {
{0x3, CHIP_PM800},
/* 88PM805 chip id number */
{0x0, CHIP_PM805},
+ /* 88PM860 chip id number */
+ {0x4, CHIP_PM860},
};
/*
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 8fcad63..d409ceb 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -21,6 +21,7 @@ enum {
CHIP_INVALID = 0,
CHIP_PM800,
CHIP_PM805,
+ CHIP_PM860,
CHIP_MAX,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/11] mmc: host: omap_hsmmc: remove incorrect voltage switch sequence
ios->vdd is set only in mmc_power_up and mmc_power_off and not in
mmc_select_voltage as mentioned in the code comment. This seems to be
legacy code that has been carried for a long time without being
tested.
This will be replaced with a proper voltage switch sequence and
populated in start_signal_voltage_switch ops to be used by
mmc core for switching voltages.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 81 -
1 file changed, 81 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f553b5f..bc59822 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1334,69 +1334,6 @@ static void set_sd_bus_power(struct omap_hsmmc_host
*host)
}
}
-/*
- * Switch MMC interface voltage ... only relevant for MMC1.
- *
- * MMC2 and MMC3 use fixed 1.8V levels, and maybe a transceiver.
- * The MMC2 transceiver controls are used instead of DAT4..DAT7.
- * Some chips, like eMMC ones, use internal transceivers.
- */
-static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
-{
- u32 reg_val = 0;
- int ret;
-
- /* Disable the clocks */
- pm_runtime_put_sync(host->dev);
- if (host->dbclk)
- clk_disable_unprepare(host->dbclk);
-
- /* Turn the power off */
- ret = mmc_pdata(host)->set_power(host->dev, 0, 0);
-
- /* Turn the power ON with given VDD 1.8 or 3.0v */
- if (!ret)
- ret = mmc_pdata(host)->set_power(host->dev, 1, vdd);
- pm_runtime_get_sync(host->dev);
- if (host->dbclk)
- clk_prepare_enable(host->dbclk);
-
- if (ret != 0)
- goto err;
-
- OMAP_HSMMC_WRITE(host->base, HCTL,
- OMAP_HSMMC_READ(host->base, HCTL) & SDVSCLR);
- reg_val = OMAP_HSMMC_READ(host->base, HCTL);
-
- /*
-* If a MMC dual voltage card is detected, the set_ios fn calls
-* this fn with VDD bit set for 1.8V. Upon card removal from the
-* slot, omap_hsmmc_set_ios sets the VDD back to 3V on MMC_POWER_OFF.
-*
-* Cope with a bit of slop in the range ... per data sheets:
-* - "1.8V" for vdds_mmc1/vdds_mmc1a can be up to 2.45V max,
-*but recommended values are 1.71V to 1.89V
-* - "3.0V" for vdds_mmc1/vdds_mmc1a can be up to 3.5V max,
-*but recommended values are 2.7V to 3.3V
-*
-* Board setup code shouldn't permit anything very out-of-range.
-* TWL4030-family VMMC1 and VSIM regulators are fine (avoiding the
-* middle range) but VSIM can't power DAT4..DAT7 at more than 3V.
-*/
- if ((1 << vdd) <= MMC_VDD_23_24)
- reg_val |= SDVS18;
- else
- reg_val |= SDVS30;
-
- OMAP_HSMMC_WRITE(host->base, HCTL, reg_val);
- set_sd_bus_power(host);
-
- return 0;
-err:
- dev_err(mmc_dev(host->mmc), "Unable to switch operating voltage\n");
- return ret;
-}
-
/* Protect the card while the cover is open */
static void omap_hsmmc_protect_card(struct omap_hsmmc_host *host)
{
@@ -1808,24 +1745,6 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
omap_hsmmc_set_bus_width(host);
- if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
- /* Only MMC1 can interface at 3V without some flavor
-* of external transceiver; but they all handle 1.8V.
-*/
- if ((OMAP_HSMMC_READ(host->base, HCTL) & SDVSDET) &&
- (ios->vdd == DUAL_VOLT_OCR_BIT)) {
- /*
-* The mmc_select_voltage fn of the core does
-* not seem to set the power_mode to
-* MMC_POWER_UP upon recalculating the voltage.
-* vdd 1.8v.
-*/
- if (omap_hsmmc_switch_opcond(host, ios->vdd) != 0)
- dev_dbg(mmc_dev(host->mmc),
- "Switch operation failed\n");
- }
- }
-
omap_hsmmc_set_clock(host);
if (ios->timing != host->timing) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/11] mmc: host: omap_hsmmc: set clk rate to the max frequency
Set the clock rate of the functional clock to the max frequency
that is passed to the driver either using pdata or dt.
Also remove unnecessary setting of host->fclk to NULL.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7dac486..60c1ac2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2149,6 +2149,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ unsigned int freq;
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
@@ -2229,10 +2230,20 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
host->fclk = devm_clk_get(>dev, "fck");
if (IS_ERR(host->fclk)) {
ret = PTR_ERR(host->fclk);
- host->fclk = NULL;
goto err1;
}
+ freq = clk_get_rate(host->fclk);
+ if (freq > mmc->f_max) {
+ mmc->f_max = freq;
+ } else {
+ ret = clk_set_rate(host->fclk, mmc->f_max);
+ if (ret) {
+ dev_err(>dev, "failed to set clock to %d\n",
mmc->f_max);
+ goto err1;
+ }
+ }
+
if (host->pdata->controller_flags & OMAP_HSMMC_BROKEN_MULTIBLOCK_READ) {
dev_info(>dev, "multiblock reads disabled due to 35xx
erratum 2.1.1.128; MMC read performance may suffer\n");
omap_hsmmc_ops.multi_io_quirk = omap_hsmmc_multi_io_quirk;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
On 08/25/2015 04:20 PM, Cornelia Huck wrote:
> On Tue, 25 Aug 2015 15:47:14 +0800
> Jason Wang wrote:
>
>> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
>> index 9ff4193..95f2901 100644
>> --- a/virt/kvm/eventfd.c
>> +++ b/virt/kvm/eventfd.c
>> @@ -762,13 +762,15 @@ ioeventfd_check_collision(struct kvm *kvm, struct
>> _ioeventfd *p)
>> return false;
>> }
>>
>> -static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
>> +static enum kvm_bus ioeventfd_bus_from_flags(struct kvm_ioeventfd *args)
> ioeventfd_bus_from_args()? But _from_flags() is not wrong either :)
>
>> {
>> -if (flags & KVM_IOEVENTFD_FLAG_PIO)
>> +if (args->flags & KVM_IOEVENTFD_FLAG_PIO)
>> return KVM_PIO_BUS;
>> -if (flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
>> +if (args->flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
>> return KVM_VIRTIO_CCW_NOTIFY_BUS;
>> -return KVM_MMIO_BUS;
>> +if (args->len)
>> +return KVM_MMIO_BUS;
>> +return KVM_FAST_MMIO_BUS;
> Hm...
>
> /* When length is ignored, MMIO is put on a separate bus, for
> * faster lookups.
> */
> return args->len ? KVM_MMIO_BUS : KVM_FAST_MMIO_BUS;
>
>> }
>>
>> static int
> This version of the patch looks nice and compact. Regardless whether
> you want to follow my (minor) style suggestions, consider this patch
>
> Acked-by: Cornelia Huck
>
Thanks for the review. V3 posted :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/11] mmc: host: omap_hsmmc: program HCTL based on signal_voltage set by mmc core
HCTL is now set based on ios.signal_voltage set by mmc core and not
hardcoded to 3V0 if OMAP_HSMMC_SUPPORTS_DUAL_VOLT is set. If
OMAP_HSMMC_SUPPORTS_DUAL_VOLT is set, it means HCTL can be set to either
3V0 or 1V8. And it should be set to 3V0 or 1V8 depending on
ios.signal_voltage.
Also it is now set on power mode status being changed to MMC_POWER_ON.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd8cc81..d3fe0f8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -229,6 +229,7 @@ struct omap_mmc_of_data {
};
static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
+static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov);
static int omap_hsmmc_card_detect(struct device *dev)
{
@@ -1674,6 +1675,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
mmc_pdata(host)->set_power(host->dev, 1, ios->vdd);
break;
case MMC_POWER_ON:
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
do_send_init_stream = 1;
break;
}
@@ -1836,17 +1838,12 @@ static void omap_hsmmc_set_capabilities(struct
omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host->base, CAPA, val);
}
-static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
+static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov)
{
u32 hctl, value;
- /* Only MMC1 supports 3.0V */
- if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
- hctl = SDVS30;
- else
- hctl = SDVS18;
-
value = OMAP_HSMMC_READ(host->base, HCTL) & ~SDVS_MASK;
+ hctl = (iov == MMC_SIGNAL_VOLTAGE_180) ? SDVS18 : SDVS30;
OMAP_HSMMC_WRITE(host->base, HCTL, value | hctl);
/* Set SD bus power bit */
@@ -2153,7 +2150,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc->pm_caps |= mmc_pdata(host)->pm_caps;
omap_hsmmc_set_capabilities(host);
- omap_hsmmc_conf_bus_power(host);
if (!pdev->dev.of_node) {
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
@@ -2328,6 +2324,7 @@ static int omap_hsmmc_suspend(struct device *dev)
static int omap_hsmmc_resume(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+ struct mmc_ios *ios;
if (!host)
return 0;
@@ -2337,8 +2334,9 @@ static int omap_hsmmc_resume(struct device *dev)
if (host->dbclk)
clk_prepare_enable(host->dbclk);
+ ios = >mmc->ios;
if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER))
- omap_hsmmc_conf_bus_power(host);
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
omap_hsmmc_protect_card(host);
pm_runtime_mark_last_busy(host->dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/11] mmc: host: omap_hsmmc: add software timer when timeout greater than hardware capablility
From: Mugunthan V N
DRA7 Errata No i834: When using high speed HS200 and SDR104
cards, the functional clock for MMC module will be 192MHz.
At this frequency, the maximum obtainable timeout (DTO =0xE)
in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
than 700ms will be affected by this small window frame and
will be timing out frequently even without a genune timeout
from the card. Workarround for this errata is use a software
timer instead of hardware timer to provide the delay requested
by the upper layer
So adding a software timer as a work around for the errata.
Instead of using software timeout only for larger delays requested
when using HS200/SDR104 cards which results in hardware and
software timer race conditions, so move all the timeout request
to use software timer when HS200/SDR104 card is connected and
use hardware timer when other type cards are connected.
Also start the software timer after queueing to DMA to ensure
we are more likely to expire within correct limits. To be ever
more sure that we won't expire this soft timer too early, we're
adding a 100ns slack to the data timeout requested by the
upper layer.
Signed-off-by: Mugunthan V N
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 71 +++--
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc59822..ec80de9 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -168,6 +168,7 @@
#define ACNE (1 << 0)
#define MMC_AUTOSUSPEND_DELAY 100
+#define MMC_SOFT_TIMER_SLACK 100 /* ns */
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
#define OMAP_MMC_MIN_CLOCK 40
@@ -246,6 +247,10 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
+ struct timer_list timer;
+ unsigned long data_timeout;
+ unsigned intneed_i834_errata:1;
+
u32 *tuning_data;
int tuning_size;
@@ -670,8 +675,8 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
irq_mask &= ~(BRR_EN | BWR_EN);
}
- /* Disable timeout for erases */
- if (cmd->opcode == MMC_ERASE)
+ /* Disable timeout for erases or when using software timeout */
+ if (cmd->opcode == MMC_ERASE || host->need_i834_errata)
irq_mask &= ~DTO_EN;
spin_lock_irqsave(>irq_lock, flags);
@@ -761,6 +766,22 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
OMAP_HSMMC_WRITE(host->base, HCTL, regval);
}
+ /*
+* DRA7 Errata No i834: When using high speed HS200 and SDR104
+* cards, the functional clock for MMC module will be 192MHz.
+* At this frequency, the maximum obtainable timeout (DTO =0xE)
+* in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
+* than 700ms will be affected by this small window frame and
+* will be timing out frequently even without a genune timeout
+* from the card. Workarround for this errata is use a software
+* timer instead of hardware timer to provide the delay requested
+* by the upper layer
+*/
+ if (ios->clock == 19200)
+ host->need_i834_errata = true;
+ else
+ host->need_i834_errata = false;
+
omap_hsmmc_start_clock(host);
}
@@ -1307,6 +1328,16 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host->base, STAT);
+
+ /*
+* During a successful bulk data transfer command-completion
+* interrupt and transfer-completion interrupt will be generated,
+* but software-timeout timer should be deleted only on non-CC
+* interrupts (transfer complete or error)
+*/
+ if (host->need_i834_errata && (status & (~CC_EN)))
+ del_timer(>timer);
+
while (status & (INT_EN_MASK | CIRQ_EN)) {
if (host->req_in_progress)
omap_hsmmc_do_irq(host, status);
@@ -1321,6 +1352,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static void omap_hsmmc_soft_timeout(unsigned long data)
+{
+ struct omap_hsmmc_host *host = (struct omap_hsmmc_host *)data;
+
+ hsmmc_command_incomplete(host, -ETIMEDOUT, 0);
+}
+
static void set_sd_bus_power(struct omap_hsmmc_host *host)
{
unsigned long i;
@@ -1522,6 +1560,22 @@ static void set_data_timeout(struct omap_hsmmc_host
*host,
if (clkd == 0)
clkd = 1;
+ if (host->need_i834_errata) {
+ unsigned long delta;
+
+ delta = (timeout_clks /
[PATCH v7 16/17] KVM: Warn if 'SN' is set during posting interrupts by software
Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot post
interrupts when 'SN' is set.
If the vcpu is in guest mode, it cannot have been scheduled out,
and that's the only case when SN is set currently, warning if
SN is set.
Signed-off-by: Feng Wu
---
arch/x86/kvm/vmx.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 64e35ea..eb640a1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4494,6 +4494,22 @@ static inline bool
kvm_vcpu_trigger_posted_interrupt(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_SMP
if (vcpu->mode == IN_GUEST_MODE) {
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+ /*
+* Currently, we don't support urgent interrupt,
+* all interrupts are recognized as non-urgent
+* interrupt, so we cannot post interrupts when
+* 'SN' is set.
+*
+* If the vcpu is in guest mode, it means it is
+* running instead of being scheduled out and
+* waiting in the run queue, and that's the only
+* case when 'SN' is set currently, warning if
+* 'SN' is set.
+*/
+ WARN_ON_ONCE(pi_test_sn(>pi_desc));
+
apic->send_IPI_mask(get_cpu_mask(vcpu->cpu),
POSTED_INTR_VECTOR);
return true;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 17/17] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts
Enable VT-d Posted-Interrtups and add a command line
parameter for it.
Signed-off-by: Feng Wu
---
Documentation/kernel-parameters.txt | 1 +
drivers/iommu/irq_remapping.c | 12
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 1d6f045..52aca36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1547,6 +1547,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
nosid disable Source ID checking
no_x2apic_optout
BIOS x2APIC opt-out request will be ignored
+ nopost disable Interrupt Posting
iomem= Disable strict checking of access to MMIO memory
strict regions from userspace.
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 2d99930..d8c3997 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -22,7 +22,7 @@ int irq_remap_broken;
int disable_sourceid_checking;
int no_x2apic_optout;
-int disable_irq_post = 1;
+int disable_irq_post = 0;
static int disable_irq_remap;
static struct irq_remap_ops *remap_ops;
@@ -58,14 +58,18 @@ static __init int setup_irqremap(char *str)
return -EINVAL;
while (*str) {
- if (!strncmp(str, "on", 2))
+ if (!strncmp(str, "on", 2)) {
disable_irq_remap = 0;
- else if (!strncmp(str, "off", 3))
+ disable_irq_post = 0;
+ } else if (!strncmp(str, "off", 3)) {
disable_irq_remap = 1;
- else if (!strncmp(str, "nosid", 5))
+ disable_irq_post = 1;
+ } else if (!strncmp(str, "nosid", 5))
disable_sourceid_checking = 1;
else if (!strncmp(str, "no_x2apic_optout", 16))
no_x2apic_optout = 1;
+ else if (!strncmp(str, "nopost", 6))
+ disable_irq_post = 1;
str += strcspn(str, ",");
while (*str == ',')
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 11/17] KVM: Define two weak arch callbacks for irq bypass manager
Define two weak arch callbacks so that archs that don't need
them don't need define them.
Signed-off-by: Feng Wu
---
virt/kvm/eventfd.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index d7a230f..f3050b9 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -256,6 +256,16 @@ static void irqfd_update(struct kvm *kvm, struct
kvm_kernel_irqfd *irqfd)
write_seqcount_end(>irq_entry_sc);
}
+void __attribute__((weak)) kvm_arch_irq_bypass_stop(
+ struct irq_bypass_consumer *cons)
+{
+}
+
+void __attribute__((weak)) kvm_arch_irq_bypass_start(
+ struct irq_bypass_consumer *cons)
+{
+}
+
static int
kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
{
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 13/17] KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd'
This patch adds an arch specific hooks 'arch_update' in
'struct kvm_kernel_irqfd'. On Intel side, it is used to
update the IRTE when VT-d posted-interrupts is used.
Signed-off-by: Feng Wu
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 5 +
include/linux/kvm_host.h| 11 +++
include/linux/kvm_irqfd.h | 2 ++
virt/kvm/eventfd.c | 12 +++-
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3038c1b..22269b4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -176,6 +176,8 @@ enum {
*/
#define KVM_APIC_PV_EOI_PENDING1
+#define __KVM_HAVE_ARCH_IRQFD_INIT 1
+
struct kvm_kernel_irq_routing_entry;
/*
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index be4b561..ef93fdc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8355,6 +8355,11 @@ void kvm_arch_irq_bypass_del_producer(struct
irq_bypass_consumer *cons,
" fails: %d\n", irqfd->consumer.token, ret);
}
+void kvm_arch_irqfd_init(struct kvm_kernel_irqfd *irqfd)
+{
+ irqfd->arch_update = kvm_arch_update_pi_irte;
+}
+
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 5f183fb..f4005dc 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -34,6 +34,8 @@
#include
+struct kvm_kernel_irqfd;
+
/*
* The bit 16 ~ bit 31 of kvm_memory_region::flags are internally used
* in kvm, other bits are visible for userspace which are defined in
@@ -1145,6 +1147,15 @@ extern struct kvm_device_ops kvm_xics_ops;
extern struct kvm_device_ops kvm_arm_vgic_v2_ops;
extern struct kvm_device_ops kvm_arm_vgic_v3_ops;
+#ifdef __KVM_HAVE_ARCH_IRQFD_INIT
+void kvm_arch_irqfd_init(struct kvm_kernel_irqfd *irqfd);
+#else
+static inline void kvm_arch_irqfd_init(struct kvm_kernel_irqfd *irqfd)
+{
+ irqfd->arch_update = NULL;
+}
+#endif
+
#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool val)
diff --git a/include/linux/kvm_irqfd.h b/include/linux/kvm_irqfd.h
index 0c1de05..b7aab52 100644
--- a/include/linux/kvm_irqfd.h
+++ b/include/linux/kvm_irqfd.h
@@ -66,6 +66,8 @@ struct kvm_kernel_irqfd {
struct work_struct shutdown;
struct irq_bypass_consumer consumer;
struct irq_bypass_producer *producer;
+ int (*arch_update)(struct kvm *kvm, unsigned int host_irq,
+ uint32_t guest_irq, bool set);
};
#endif /* __LINUX_KVM_IRQFD_H */
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index f3050b9..b2d9066 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -288,6 +288,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
INIT_LIST_HEAD(>list);
INIT_WORK(>inject, irqfd_inject);
INIT_WORK(>shutdown, irqfd_shutdown);
+ kvm_arch_irqfd_init(irqfd);
seqcount_init(>irq_entry_sc);
f = fdget(args->fd);
@@ -580,13 +581,22 @@ kvm_irqfd_release(struct kvm *kvm)
*/
void kvm_irq_routing_update(struct kvm *kvm)
{
+ int ret;
struct kvm_kernel_irqfd *irqfd;
spin_lock_irq(>irqfds.lock);
- list_for_each_entry(irqfd, >irqfds.items, list)
+ list_for_each_entry(irqfd, >irqfds.items, list) {
irqfd_update(kvm, irqfd);
+ if (irqfd->arch_update && irqfd->producer) {
+ ret = irqfd->arch_update(
+ irqfd->kvm, irqfd->producer->irq,
+ irqfd->gsi, 1);
+ WARN_ON(ret);
+ }
+ }
+
spin_unlock_irq(>irqfds.lock);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 08/17] vfio: Select IRQ_BYPASS_MANAGER for vfio PCI devices
Enable irq bypass manager for vfio PCI devices. Signed-off-by: Feng Wu --- drivers/vfio/pci/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig index 579d83b..02912f1 100644 --- a/drivers/vfio/pci/Kconfig +++ b/drivers/vfio/pci/Kconfig @@ -2,6 +2,7 @@ config VFIO_PCI tristate "VFIO support for PCI devices" depends on VFIO && PCI && EVENTFD select VFIO_VIRQFD + select IRQ_BYPASS_MANAGER help Support for the PCI VFIO bus driver. This is required to make use of PCI drivers using the VFIO framework. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 00/17] Add VT-d Posted-Interrupts support
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. With VT-d Posted-Interrupts enabled, external interrupts from direct-assigned devices can be delivered to guests without VMM intervention when guest is running in non-root mode. You can find the VT-d Posted-Interrtups Spec. in the following URL: http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html v7: * Define two weak irq bypass callbacks: - kvm_arch_irq_bypass_start() - kvm_arch_irq_bypass_stop() * Remove the x86 dummy implementation of the above two functions. * Print some useful information instead of WARN_ON() when the irq bypass consumer unregistration fails. * Fix an issue when calling pi_pre_block and pi_post_block. v6: * Rebase on 4.2.0-rc6 * Rebase on https://lkml.org/lkml/2015/8/6/526 and http://www.gossamer-threads.com/lists/linux/kernel/2235623 * Make the add_consumer and del_consumer callbacks static * Remove pointless INIT_LIST_HEAD to 'vdev->ctx[vector].producer.node)' * Use dev_info instead of WARN_ON() when irq_bypass_register_producer fails * Remove optional dummy callbacks for irq producer v4: * For lowest-priority interrupt, only support single-CPU destination interrupts at the current stage, more common lowest priority support will be added later. * Accoring to Marcelo's suggestion, when vCPU is blocked, we handle the posted-interrupts in the HLT emulation path. * Some small changes (coding style, typo, add some code comments) v3: * Adjust the Posted-interrupts Descriptor updating logic when vCPU is preempted or blocked. * KVM_DEV_VFIO_DEVICE_POSTING_IRQ --> KVM_DEV_VFIO_DEVICE_POST_IRQ * __KVM_HAVE_ARCH_KVM_VFIO_POSTING --> __KVM_HAVE_ARCH_KVM_VFIO_POST * Add KVM_DEV_VFIO_DEVICE_UNPOST_IRQ attribute for VFIO irq, which can be used to change back to remapping mode. * Fix typo v2: * Use VFIO framework to enable this feature, the VFIO part of this series is base on Eric's patch "[PATCH v3 0/8] KVM-VFIO IRQ forward control" * Rebase this patchset on git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git, then revise some irq logic based on the new hierarchy irqdomain patches provided by Jiang Liu Feng Wu (17): KVM: Extend struct pi_desc for VT-d Posted-Interrupts KVM: Add some helper functions for Posted-Interrupts KVM: Define a new interface kvm_intr_is_single_vcpu() KVM: Get Posted-Interrupts descriptor address from 'struct kvm_vcpu' KVM: Add interfaces to control PI outside vmx KVM: Make struct kvm_irq_routing_table accessible KVM: make kvm_set_msi_irq() public vfio: Select IRQ_BYPASS_MANAGER for vfio PCI devices vfio: Register/unregister irq_bypass_producer KVM: x86: Update IRTE for posted-interrupts KVM: Define two weak arch callbacks for irq bypass manager KVM: Implement IRQ bypass consumer callbacks for x86 KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd' KVM: Update Posted-Interrupts Descriptor when vCPU is preempted KVM: Update Posted-Interrupts Descriptor when vCPU is blocked KVM: Warn if 'SN' is set during posting interrupts by software iommu/vt-d: Add a command line parameter for VT-d posted-interrupts Documentation/kernel-parameters.txt | 1 + arch/x86/include/asm/kvm_host.h | 20 +++ arch/x86/kvm/Kconfig| 1 + arch/x86/kvm/irq_comm.c | 28 +++- arch/x86/kvm/vmx.c | 288 +++- arch/x86/kvm/x86.c | 167 +++-- drivers/iommu/irq_remapping.c | 12 +- drivers/vfio/pci/Kconfig| 1 + drivers/vfio/pci/vfio_pci_intrs.c | 9 ++ drivers/vfio/pci/vfio_pci_private.h | 2 + include/linux/kvm_host.h| 28 include/linux/kvm_irqfd.h | 2 + virt/kvm/eventfd.c | 22 ++- virt/kvm/irqchip.c | 10 -- virt/kvm/kvm_main.c | 3 + 15 files changed, 565 insertions(+), 29 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 02/17] KVM: Add some helper functions for Posted-Interrupts
This patch adds some helper functions to manipulate the
Posted-Interrupts Descriptor.
Signed-off-by: Feng Wu
---
arch/x86/kvm/vmx.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 271dd70..316f9bf 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -443,6 +443,8 @@ struct nested_vmx {
};
#define POSTED_INTR_ON 0
+#define POSTED_INTR_SN 1
+
/* Posted-Interrupt Descriptor */
struct pi_desc {
u32 pir[8]; /* Posted interrupt requested */
@@ -483,6 +485,30 @@ static int pi_test_and_set_pir(int vector, struct pi_desc
*pi_desc)
return test_and_set_bit(vector, (unsigned long *)pi_desc->pir);
}
+static void pi_clear_sn(struct pi_desc *pi_desc)
+{
+ return clear_bit(POSTED_INTR_SN,
+ (unsigned long *)_desc->control);
+}
+
+static void pi_set_sn(struct pi_desc *pi_desc)
+{
+ return set_bit(POSTED_INTR_SN,
+ (unsigned long *)_desc->control);
+}
+
+static int pi_test_on(struct pi_desc *pi_desc)
+{
+ return test_bit(POSTED_INTR_ON,
+ (unsigned long *)_desc->control);
+}
+
+static int pi_test_sn(struct pi_desc *pi_desc)
+{
+ return test_bit(POSTED_INTR_SN,
+ (unsigned long *)_desc->control);
+}
+
struct vcpu_vmx {
struct kvm_vcpu vcpu;
unsigned long host_rsp;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 04/17] KVM: Get Posted-Interrupts descriptor address from 'struct kvm_vcpu'
Define an interface to get PI descriptor address from the vCPU structure.
Signed-off-by: Feng Wu
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/vmx.c | 11 +++
2 files changed, 13 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index af11bca..d50c1d3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -858,6 +858,8 @@ struct kvm_x86_ops {
void (*enable_log_dirty_pt_masked)(struct kvm *kvm,
struct kvm_memory_slot *slot,
gfn_t offset, unsigned long mask);
+
+ u64 (*get_pi_desc_addr)(struct kvm_vcpu *vcpu);
/* pmu operations of sub-arch */
const struct kvm_pmu_ops *pmu_ops;
};
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 316f9bf..81a995c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -610,6 +610,10 @@ static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu
*vcpu)
#define FIELD64(number, name) [number] = VMCS12_OFFSET(name), \
[number##_HIGH] = VMCS12_OFFSET(name)+4
+struct pi_desc *vcpu_to_pi_desc(struct kvm_vcpu *vcpu)
+{
+ return &(to_vmx(vcpu)->pi_desc);
+}
static unsigned long shadow_read_only_fields[] = {
/*
@@ -4487,6 +4491,11 @@ static void vmx_sync_pir_to_irr_dummy(struct kvm_vcpu
*vcpu)
return;
}
+static u64 vmx_get_pi_desc_addr(struct kvm_vcpu *vcpu)
+{
+ return __pa((u64)vcpu_to_pi_desc(vcpu));
+}
+
/*
* Set up the vmcs's constant host-state fields, i.e., host-state fields that
* will not change in the lifetime of the guest.
@@ -10460,6 +10469,8 @@ static struct kvm_x86_ops vmx_x86_ops = {
.flush_log_dirty = vmx_flush_log_dirty,
.enable_log_dirty_pt_masked = vmx_enable_log_dirty_pt_masked,
+ .get_pi_desc_addr = vmx_get_pi_desc_addr,
+
.pmu_ops = _pmu_ops,
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v6 5/6] mfd: 88pm800: Set default interrupt clear method
On Tuesday 25 August 2015 02:00 PM, Lee Jones wrote:
On Mon, 24 Aug 2015, Vaibhav Hiremath wrote:
On Monday 24 August 2015 09:21 PM, Lee Jones wrote:
On Mon, 24 Aug 2015, Vaibhav Hiremath wrote:
On Monday 24 August 2015 07:24 PM, Lee Jones wrote:
On Wed, 08 Jul 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name and removed unnecessary field
pm80x_chip.irq_mode, using platform_data.irq_clr_method.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 9 +++--
2 files changed, 17 insertions(+), 7 deletions(-)
[...]
+#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
+#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
Use BIT().
+/* Used by irq_clr_method */
+#define PM800_IRQ_CLR_ON_READ 0
+#define PM800_IRQ_CLR_ON_WRITE 1
- int irq_mode; /* Clear interrupt by read/write(0/1) */
+ bool irq_clr_method;/* Clear interrupt by read/write(0/1) */
+ irq_clr_mode = pdata->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
This is pretty convoluted.
For starters you're abusing the 'bool' type here. Bool is either
'true' or 'false', so at the very least you should rename
'irq_clr_method' to 'irq_clr_on_write'.
Then you can do:
irq_clr_mode = pdata->irq_clr_on_write ?
PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
We have discussed on this, and went back-n-forth.
I think if I remember correctly, one of the version was using
true/false then we decided to rename it to relevant macro.
If I am not wrong V4 version of this series is exactly same as what you
are referring to.
Right. I made a few suggestions which vary in usefulness depending on
how you plan to implement all of this. Unfortunately this is a bit of
a bastardised version where some of it make sense and other parts
could do with some improvement.
This so called "basterdised version could have been avoided :)
V2 version itself was clean and ready. It just got dragged into
multiple iterations.
Don't kid yourself. There were still improvements to be made.
Yes indeed,
Moving to pdata was required. I was referring to logic part of it.
However, what I suggest you really do is share
PM800_WAKEUP2_INT_{READ,WRITE}_CLEAR with platform data and just pass
the value through directly.
I think we discussed about this also, and the reason I recall here is,
we may need to control this from DT in the future so we decided to keep
it boolean in platform_data and have simple check before writing to
register.
And I think that was also another reason we introduced
/* Used by irq_clr_method */
#define PM800_IRQ_CLR_ON_READ 0
#define PM800_IRQ_CLR_ON_WRITE 1
I think these are still required. So it would look like this:
NO. I think you are confused here,
We have two different macros playing around here,
+/* Used by irq_clr_method */
+#define PM800_IRQ_CLR_ON_READ 0
+#define PM800_IRQ_CLR_ON_WRITE 1
/* Used to write to register */
+#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
+#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
I know. I used both of them *correctly* in my example below. No
confusion here.
== Platform data ==
struct pdata {
bool clear_irq_on_write;
};
pdata->clear_irq_on_write = PM800_IRQ_CLR_ON_{READ,WRITE};
== Driver ==
irq_clr_mode = pdata->clear_irq_on_write ?
PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
The V2 version had
irq_clr_mode = (chip->irq_clr_on_wr) ?
PM800_WAKEUP2_INT_WRITE_CLEAR :
PM800_WAKEUP2_INT_READ_CLEAR;
ret = regmap_update_bits(map, PM800_WAKEUP2, mask,
irq_clr_mode);
Which is exactly same as your example above, except pdata moment.
Lets not discuss too much on this, I think its time for conclusion :)
Your below example looks even better to me. So I will adopt below
example and resubmit the series.
Please check V2, which is exactly same as above.
https://patchwork.kernel.org/patch/6627781/
If you are OK with it, I will spin another version and submit it.
If you can't use the value directly, which if you want to pull the
value from DT you can't, then either use the method above, or
something like this might be better:
int clear_on_write = 0;
if
Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
* Johannes Berg wrote: > On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: > > > This time around, I employed a linker trick to convert the structures > > containing extended error information into integers, which are then > > made to look just like normal error codes so that IS_ERR_VALUE() and > > friends would still work correctly on them. So no extra pointers in > > the struct perf_event or anywhere else; the extended error codes are > > passed around like normal error codes. They only need to be converted > > in syscalls' topmost return statements. This is done in 1/6. > > For the record, as we discussed separately, I'd love to see this move to more > general infrastructure. In wireless (nl80211), for example, we have a few > hundred (!) callsites returning -EINVAL, mostly based on malformed netlink > attributes, and it can be very difficult to figure out what went wrong; > debugging mostly employs a variation of Hugh's trick. Absolutely, I suggested this as well earlier today, as the scheduler would like to make use of it in syscalls with extensible ABIs, such as sched_setattr(). If people really like this then we could go farther as well and add a standalone 'extended errors system call' as well (SyS_errno_extended_get()), which would allow the recovery of error strings even for system calls that are not easily extensible. We could cache the last error description in the task struct. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v5] serial: 8250_dw: Add support for big-endian MMIO accesses
From: Noam Camus
Add support for UPIO_MEM32BE in addition to UPIO_MEM32.
dw8250_serial_out32() extra functionality that is not part of
the 8250 core driver was moved to new function called
dw8250_check_LCR().
For big endian we use 2 new accessors similar to little endian,
called dw8250_serial_out32be() and dw8250_serial_in32be().
Both little and big endian accessors use dw8250_check_LCR()
for their dw8250_serial_out32{,be}().
In addition I added another 2 accessors inside private_data field of
uart_port. This second level accessors are set during probe in
private_data field of uart_port. Now any direct call to readl/writel
is replaced with those accessors which are endianness aware.
Last issue:
readl() for UCV and CPR will not work for port type UPIO_MEM32BE.
Instead we use the serial_in32() accessor which is initialized
properly according to endianness.
Signed-off-by: Noam Camus
---
drivers/tty/serial/8250/8250_dw.c | 72 -
1 files changed, 63 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index d48b506..62f766a 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -64,6 +64,9 @@ struct dw8250_data {
struct clk *pclk;
struct reset_control*rst;
struct uart_8250_dmadma;
+ unsigned int(*serial_in)(const void __iomem *addr);
+ void(*serial_out)(unsigned int value,
+ void __iomem *addr);
};
#define BYT_PRV_CLK0x800
@@ -173,15 +176,13 @@ static void dw8250_serial_outq(struct uart_port *p, int
offset, int value)
}
#endif /* CONFIG_64BIT */
-static void dw8250_serial_out32(struct uart_port *p, int offset, int value)
+static void dw8250_check_LCR(struct uart_port *p, int offset, int value)
{
struct dw8250_data *d = p->private_data;
if (offset == UART_MCR)
d->last_mcr = value;
- writel(value, p->membase + (offset << p->regshift));
-
/* Make sure LCR write wasn't ignored */
if (offset == UART_LCR) {
int tries = 1000;
@@ -190,7 +191,8 @@ static void dw8250_serial_out32(struct uart_port *p, int
offset, int value)
if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
return;
dw8250_force_idle(p);
- writel(value, p->membase + (UART_LCR << p->regshift));
+ d->serial_out(value,
+ p->membase + (UART_LCR << p->regshift));
}
/*
* FIXME: this deadlocks if port->lock is already held
@@ -199,6 +201,22 @@ static void dw8250_serial_out32(struct uart_port *p, int
offset, int value)
}
}
+static void _dw8250_serial_out32(unsigned int value, void __iomem *addr)
+{
+ writel(value, addr);
+}
+
+static unsigned int _dw8250_serial_in32(const void __iomem *addr)
+{
+ return readl(addr);
+}
+
+static void dw8250_serial_out32(struct uart_port *p, int offset, int value)
+{
+ writel(value, p->membase + (offset << p->regshift));
+ dw8250_check_LCR(p, offset, value);
+}
+
static unsigned int dw8250_serial_in32(struct uart_port *p, int offset)
{
unsigned int value = readl(p->membase + (offset << p->regshift));
@@ -206,6 +224,29 @@ static unsigned int dw8250_serial_in32(struct uart_port
*p, int offset)
return dw8250_modify_msr(p, offset, value);
}
+static void _dw8250_serial_out32be(unsigned int value, void __iomem *addr)
+{
+ iowrite32be(value, addr);
+}
+
+static unsigned int _dw8250_serial_in32be(const void __iomem *addr)
+{
+ return ioread32be(addr);
+}
+
+static void dw8250_serial_out32be(struct uart_port *p, int offset, int value)
+{
+ iowrite32be(value, p->membase + (offset << p->regshift));
+ dw8250_check_LCR(p, offset, value);
+}
+
+static unsigned int dw8250_serial_in32be(struct uart_port *p, int offset)
+{
+ unsigned int value = ioread32be(p->membase + (offset << p->regshift));
+
+ return dw8250_modify_msr(p, offset, value);
+}
+
static int dw8250_handle_irq(struct uart_port *p)
{
struct dw8250_data *d = p->private_data;
@@ -269,7 +310,8 @@ static bool dw8250_dma_filter(struct dma_chan *chan, void
*param)
static void dw8250_setup_port(struct uart_8250_port *up)
{
struct uart_port*p = >port;
- u32 reg = readl(p->membase + DW_UART_UCV);
+ struct dw8250_data *d = p->private_data;
+ u32 reg = d->serial_in(p->membase + DW_UART_UCV);
/*
* If the Component Version Register returns zero, we know that
@@ -281,7 +323,7 @@ static void dw8250_setup_port(struct uart_8250_port *up)
dev_dbg_ratelimited(p->dev, "Designware UART version %c.%c%c\n",
Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
* Zhang, Jonathan Zhixiong wrote: > > > On 8/22/2015 2:24 AM, Ingo Molnar wrote: > > > >* Jonathan (Zhixiong) Zhang wrote: > > > >>From: "Jonathan (Zhixiong) Zhang" > >> > >>With ACPI APEI firmware first handling, generic hardware error > >>record is updated by firmware in GHES memory region. On an arm64 > >>platform, firmware updates GHES memory region with uncached > >>access attribute, and then Linux reads stale data from cache. > > > >This paragraph *still* doesn't parse for me. It's not any English > >I can recognize: what is a 'With ACPI APEI firmware first handling'? > APEI is ACPI Platform Error Interface; it is part of ACPI spec, > defining the aspect of hardware error handling. "firmware first > handling" is a terminology used in APEI. It describes such mechanism > that when hardware error happens, firmware intersects/handles such > hardware error, formulates hardware error record and writes the record > to GHES memory region, notifies the kernel through NMI/interrupt, then > the kernel GHES driver grabs the error record from the GHES memory > region. Argh. So how about translating that to English and putting that misnomer into scare quotes, and saying something like: If the ACPI APEI firmware handles the error first (called "firmware first handling"), the generic hardware error record is updated by the firmware in the GHES memory region. ( Also note all the missing articles I added for readability. The rest of the changelog is missing articles as well. ) > > ... plus what this changelog still doesn't mention is the most important > > part > > of any bug fix description: how does the user notice this in practice and > > why > > does he care? > > The changelog mentioned that Linux would read stale data from cache. When > stale > data is read, kernel reports there is no new hardware error when there > actually > is. Note that this is the most valuable sentence so far, in this whole changelog and discussion. And we needed how many emails to get to this point? obviously saying 'stale data' in itself does not mean much - it could mean a harmless inconsistency nobody really cares about, or in fact it could mean something more serious: > [...] This may lead to further damage in various scenarios, such as error > propagation caused data corruption. Please outline this better. How users are affected in practice is far more important than any other detail. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table
On Tue, Aug 25, 2015 at 08:46:27AM +, Xiao, Nan (Nan@HPservers-Core-OE-PSC)
wrote:
> Yes, your patch is simple and better!
Okay, I queued this patch to my x86/vt-d branch:
>From 03932776424a799c3f065a69e98076a78530288b Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Tue, 25 Aug 2015 10:54:28 +0200
Subject: [PATCH] iommu/vt-d: Really use upper context table when necessary
There is a bug in iommu_context_addr() which will always use
the lower context table, event when the upper context table
needs to be used. Fix this issue.
Fixes: 03ecc32c5274 ("iommu/vt-d: support extended root and context entries")
Reported-by: Xiao, Nan
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a85077d..63daf1b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -803,6 +803,7 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
struct context_entry *context;
u64 *entry;
+ entry = >lo;
if (ecs_enabled(iommu)) {
if (devfn >= 0x80) {
devfn -= 0x80;
@@ -810,7 +811,6 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
}
devfn *= 2;
}
- entry = >lo;
if (*entry & 1)
context = phys_to_virt(*entry & VTD_PAGE_MASK);
else {
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: rcar: Enable r8a7795 for ARM64
Hi Morimoto-san,
On Tue, Aug 25, 2015 at 10:39 AM, Kuninori Morimoto
wrote:
> 8cd1470("gpio: rcar: Add r8a7795 (R-Car H3) support") adds
> GPIO support for r8a7795. r8a7795 based on CONFIG_ARM64.
> This patch enables r8a7795 on ARM64.
>
> Signed-off-by: Kuninori Morimoto
> ---
> drivers/gpio/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index b4fc9e4..5d083f7 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -356,7 +356,7 @@ config GPIO_PXA
>
> config GPIO_RCAR
> tristate "Renesas R-Car GPIO"
> - depends on ARM && (ARCH_SHMOBILE || COMPILE_TEST)
> + depends on (ARM || ARM64) && (ARCH_SHMOBILE || COMPILE_TEST)
As this driver seems to compile fine on non-ARM, what about relaxing the
dependency to
depends on ARCH_SHMOBILE || COMPILE_TEST
instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v5] *** 8250_dw ***
From: Noam Camus v5 change: Two patches is now squashed into single one v4 change Remove patch for skipping looptest through DT option. This is now handled in our simulator model. Thanks to Vineet Gupta from Synopsys for his help. We are left with 2 patches which adds BIG endian support. V3 change: Use second level accessors for big/little endian port. The new accessors are now pointed from uart_port->private_data These accessors are initialized during driver probe(). Driver shouldn't access directly to readl/writel but to these new second level accessors (first level is at uart_port). e.g. at dw8250_check_LCR() and dw8250_setup_port() I replaced such direct calls. V2 changes: 1) better description for each commit. 2) adding to CC list the device tree maintainer. 3) rename dw8250_check_control() --> dw8250_check_LCR(). 4) remove bad patch of "add UPF_FIXED_TYPE to flags". Noam Camus (1): serial: 8250_dw: Add support for big-endian MMIO accesses drivers/tty/serial/8250/8250_dw.c | 72 - 1 files changed, 63 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: > This time around, I employed a linker trick to convert the structures > containing extended error information into integers, which are then > made to look just like normal error codes so that IS_ERR_VALUE() and > friends would still work correctly on them. So no extra pointers in > the struct perf_event or anywhere else; the extended error codes are > passed around like normal error codes. They only need to be converted > in syscalls' topmost return statements. This is done in 1/6. > For the record, as we discussed separately, I'd love to see this move to more general infrastructure. In wireless (nl80211), for example, we have a few hundred (!) callsites returning -EINVAL, mostly based on malformed netlink attributes, and it can be very difficult to figure out what went wrong; debugging mostly employs a variation of Hugh's trick. It would be absolutely necessary to support modules, however that could get tricky: unless we pass a THIS_MODULE through in some way to netlink_ack() (in the nl80211 case) we'd have to store the actual index inside the err_site and assign it on module load somehow. Passing the module pointer seems better, but has even more wrinkles like what to do when the error came from a nested call (e.g. nla_parse()) that's in a different modules ... Unrelated to all that - maybe perf_errno_to_site() should have some range checking? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v2 3/5] mfd: devicetree: bindings: Add clock subdevice node information
On Tuesday 25 August 2015 01:28 PM, Lee Jones wrote: On Tue, 25 Aug 2015, Vaibhav Hiremath wrote: This patch updates the binding documentation for optional clocks node and related information for buffered 32KHz clock. Signed-off-by: Vaibhav Hiremath Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring --- Documentation/devicetree/bindings/mfd/88pm800.txt | 27 +++ 1 file changed, 27 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt b/Documentation/devicetree/bindings/mfd/88pm800.txt index 2c82fcb..bc6cb02 100644 --- a/Documentation/devicetree/bindings/mfd/88pm800.txt +++ b/Documentation/devicetree/bindings/mfd/88pm800.txt @@ -15,6 +15,26 @@ Optional properties : Without this both BUCK1A and BUCK1B operates independently with 3A capacity. (This property is only applicable to 88PM860) +Optional nodes: +- clocks: 88pm800 family of devices provide multiple buffered 32.768 + KHz outputs, so to register these as clocks with common clock framework + instantiate a sub-node named "clocks". It uses the common clock binding + documented in : + [Documentation/devicetree/bindings/clock/clock-bindings.txt] I tend to prefer relative paths. Firstly because they're shorter and more succinct and secondly because if we do eventually move DT out of the kernel, it will be less hassle to rename each of them. + - #clock-cells: should be 1. + + - The following is the list of clocks generated by the controller. Each clock +is assigned an identifier and client nodes use this identifier to specify +the clock which they consume. +Clock ID Devices +-- +pm800_clk32k_1 0 88PM800 and 88PM860 +pm800_clk32k_2 1 88PM800 and 88PM860 +pm800_clk32k_3 2 88PM800 + + - compatible: Should be : "marvell,88pm800-clk" + 88pm80x family of devices consists of varied group of sub-devices: DeviceSupply Names Description @@ -22,6 +42,7 @@ DeviceSupply Names Description 88pm80x-onkey : : On key 88pm80x-rtc : : RTC 88pm80x-regulator : : Regulators +88pm80x-clk: : 32KHz Clk provider Nit: Alphabetical? Will correct both comments. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/nfc/s3fwrn5/Makefile: remove superfluous cflags
NFC_DEBUG is not defined in Kconfig and since DEBUG is not used anywhere in this directory, we can safely remove this line. Signed-off-by: Valentin Rothberg --- I detected the issue with scripts/checkkconfigsymbols.py drivers/nfc/s3fwrn5/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/nfc/s3fwrn5/Makefile b/drivers/nfc/s3fwrn5/Makefile index 3381c34faf62..ddfa7be7dd05 100644 --- a/drivers/nfc/s3fwrn5/Makefile +++ b/drivers/nfc/s3fwrn5/Makefile @@ -7,5 +7,3 @@ s3fwrn5_i2c-objs = i2c.o obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5.o obj-$(CONFIG_NFC_S3FWRN5_I2C) += s3fwrn5_i2c.o - -ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v2 1/5] mfd: 88pm800: Fix tabbing issue
On Tuesday 25 August 2015 01:22 PM, Lee Jones wrote: On Tue, 25 Aug 2015, Vaibhav Hiremath wrote: Driver had coding style issues where spaces were used instead of tabs. This patch fixes them all. Signed-off-by: Vaibhav Hiremath --- drivers/mfd/88pm800.c | 125 -- 1 file changed, 61 insertions(+), 64 deletions(-) Same comment as before. How similar is this file to the other one? I believe you are referring to include/linux/mfd/88pm80x.h Can you reduce the size by having shared register defines? Not sure whether I understand your comment here, They are common defines. PM860 only defines are named as PM860_ Similarly, PM805 only defines are named as PM805_ and PM800_xxx should be common. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v1 0/4] perf: Introduce extended syscall error reporting
* Alexander Shishkin wrote: > Ingo Molnar writes: > > > * Peter Zijlstra wrote: > > > >> On Fri, Jul 24, 2015 at 02:45:55PM +0300, Alexander Shishkin wrote: > >> > Hi Peter and Ingo and everybody, > >> > > >> > Here's my second stab at improving perf's error reporting by attaching > >> > arbitrary strings to the integer error codes. This is largely based > >> > off of the previous email thread [1]. > >> > > >> > This time around, I employed a linker trick to convert the structures > >> > containing extended error information into integers, which are then > >> > made to look just like normal error codes so that IS_ERR_VALUE() and > >> > friends would still work correctly on them. So no extra pointers in > >> > the struct perf_event or anywhere else; the extended error codes are > >> > passed around like normal error codes. They only need to be converted > >> > in syscalls' topmost return statements. This is done in 1/4. > >> > > >> > Then, 2/4 illustrates how error sites can be extended to include more > >> > information such as file names and line numbers [1]. > >> > > >> > The other two patches add perf_err() annotation to a few semi-randomly > >> > picked places in perf core (3/4) and x86 bits (4/4). > >> > >> Looks generally ok to me. Thanks for doing this. > > > > I like this too. > > > > Alexander, mind sending a finalized, signed off version? > > Sure, I have everything ready, except for what about 2/4 (using > CONFIG_DEBUG_KERNEL to extend output with file name and line number)? Should > I > leave it out or can we pick a more specific kconfig option or add a new one? I'd make it unconditional. We'll see whether we compress the debug info some more if the number of callsites increases dramatically. Tooling can decide whether it wants to display it by default, or print it only if some verbosity option is activated. Also, mind structuring it in a bit more generic way that makes it possible for other kernel subsystems to use this facility too? I.e. add a new header for it instead of embedding it in perf, etc. Nothing complex, just some common-sense generalization for a useful looking facility. For example the scheduler could start using it in struct sched_attr and feed back the 15+ of failure causes in sys_sched_setattr() / __sched_setscheduler() in a bit more usable fashion. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table
Hi Joerg,
Yes, your patch is simple and better!
Best Regards
Nan Xiao
-Original Message-
From: j...@8bytes.org [mailto:j...@8bytes.org]
Sent: Tuesday, August 25, 2015 4:42 PM
To: Xiao, Nan (Nan@HPservers-Core-OE-PSC)
Cc: dw...@infradead.org; io...@lists.linux-foundation.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower
extended-context-table
Hi Nan,
On Mon, Aug 24, 2015 at 06:26:33AM +, Xiao, Nan (Nan@HPS Performance,
Beijing) wrote:
> drivers/iommu/intel-iommu.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0649b94..4213598 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -759,10 +759,11 @@ static inline struct context_entry
> *iommu_context_addr(struct intel_iommu *iommu
> if (devfn >= 0x80) {
> devfn -= 0x80;
> entry = >hi;
> - }
> + } else
> + entry = >lo;
> devfn *= 2;
> - }
> - entry = >lo;
> + } else
> + entry = >lo;
> if (*entry & 1)
> context = phys_to_virt(*entry & VTD_PAGE_MASK);
> else {
Shouldn't this diff have the same effect?
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
0649b94..7553cb9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -755,6 +755,7 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
struct context_entry *context;
u64 *entry;
+ entry = >lo;
if (ecs_enabled(iommu)) {
if (devfn >= 0x80) {
devfn -= 0x80;
@@ -762,7 +763,6 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
}
devfn *= 2;
}
- entry = >lo;
if (*entry & 1)
context = phys_to_virt(*entry & VTD_PAGE_MASK);
else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] mfd: update Intel soc PMIC header file to support Broxton WC PMIC
On Wed, 26 Aug 2015, Qipeng Zha wrote:
> IRQ control registers of Intel Broxton Whisky Cove PMIC are
> separated in two parts, so add secondary IRQ chip.
> And the new member of device will be used in PMC IPC regmap APIs.
>
> Signed-off-by: Qipeng Zha
> ---
> include/linux/mfd/intel_soc_pmic.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/mfd/intel_soc_pmic.h
> b/include/linux/mfd/intel_soc_pmic.h
> index abcbfcf..a730f14 100644
> --- a/include/linux/mfd/intel_soc_pmic.h
> +++ b/include/linux/mfd/intel_soc_pmic.h
> @@ -21,10 +21,15 @@
>
> #include
>
> +#define INIT_REGMAP_IRQ(_irq, _off, _mask) \
> + [_irq] = { .reg_offset = (_off), .mask = (_mask) }
> +
No, that's not what I asked.
Either this macro is going to be useful to *everyone*, or it's
probably not useful to *anyone*. If it's going to exist, it should
exist in the core header file, not Intel's own.
> struct intel_soc_pmic {
> int irq;
> struct regmap *regmap;
> struct regmap_irq_chip_data *irq_chip_data;
> + struct regmap_irq_chip_data *irq_chip_data_level2;
> + struct device *dev;
> };
>
> #endif /* __INTEL_SOC_PMIC_H__ */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v2 2/5] mfd: 88pm800: Update the header file with 32K clk related macros
On Tuesday 25 August 2015 01:25 PM, Lee Jones wrote:
On Tue, 25 Aug 2015, Vaibhav Hiremath wrote:
Update header file with required macros for 32KHz buffered clock
output of 88PM800 family of device.
These macros will be used in clk provider driver.
Signed-off-by: Vaibhav Hiremath
---
include/linux/mfd/88pm80x.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 122cfd2..0215d5f 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -91,6 +91,7 @@ enum {
/* Referance and low power registers */
#define PM800_LOW_POWER1 (0x20)
#define PM800_LOW_POWER2 (0x21)
+#define PM800_LOW_POWER2_XO_LJ_EN BIT(5)
Some people add an extra space for register bits, which I quite like.
So:
#define SOME_REGISTER_ADDRESS 0x123
#define SOME_BIT_VALUE BIT(4)
Feel free to use it, or not.
#define PM800_LOW_POWER_CONFIG3 (0x22)
#define PM800_LDOBK_FREEZEBIT(7)
@@ -138,6 +139,13 @@ enum {
#define PM800_ALARM BIT(5)
#define PM800_RTC1_USE_XO BIT(7)
+#define PM800_32K_OUTX_SEL_MASK0x3
+/* 32KHz clk output sel mode */
+#define PM800_32K_OUTX_SEL_ZERO0x0
+#define PM800_32K_OUTX_SEL_INT_32KHZ 0x1
+#define PM800_32K_OUTX_SEL_XO_32KHZ0x2
+#define PM800_32K_OUTX_SEL_HIZ 0x3
+
/* Regulator Control Registers: BUCK1,BUCK5,LDO1 have DVC */
/* buck registers */
@@ -208,6 +216,10 @@ enum {
#define PM800_PMOD_MEAS1 0x52
#define PM800_PMOD_MEAS2 0x53
+/* Oscillator control */
+#define PM800_OSC_CNTRL1 0x50
+#define PM800_OSC_CNTRL1_OSC_FREERUN_ENBIT(1)
0x50 goes before 0x52 (and 0x51 if it's there).
Will reorder in next version.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/7] drm/vc4: Add KMS support for Raspberry Pi.
On Tue, Aug 18, 2015 at 02:54:04PM -0700, Eric Anholt wrote: > This is the start of a full VC4 driver. Right now this just supports > configuring the display using a pre-existing video mode (because > changing the pixel clock isn't available yet, and doesn't work when it > is). However, this is enough for fbcon and bringing up X using > xf86-video-modesetting. > > Signed-off-by: Eric Anholt > --- > > v2: Drop FB_HELPER select thanks to Archit's patches. Do manual init > ordering instead of using the .load hook. Structure registration > more like tegra's, but still using the typical "component" code. > Drop no-op hooks for atomic_begin and mode_fixup() now that > they're optional. Drop sentinel in Makefile. Fix minor style > nits I noticed on another reread. fwiw Acked-by: Daniel Vetter since Eric has done all the changes I requested - simply forgot to add that in my earlier review. No full r-b since I don't have a clue about the hw (and didn't take a close look at the hw touching code hence). Cheers, Daniel > > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/vc4/Kconfig | 13 + > drivers/gpu/drm/vc4/Makefile | 17 + > drivers/gpu/drm/vc4/vc4_bo.c | 52 > drivers/gpu/drm/vc4/vc4_crtc.c| 565 ++ > drivers/gpu/drm/vc4/vc4_debugfs.c | 38 +++ > drivers/gpu/drm/vc4/vc4_drv.c | 271 > drivers/gpu/drm/vc4/vc4_drv.h | 120 > drivers/gpu/drm/vc4/vc4_hdmi.c| 633 > ++ > drivers/gpu/drm/vc4/vc4_hvs.c | 161 ++ > drivers/gpu/drm/vc4/vc4_kms.c | 84 + > drivers/gpu/drm/vc4/vc4_plane.c | 320 +++ > drivers/gpu/drm/vc4/vc4_regs.h| 562 + > 14 files changed, 2839 insertions(+) > create mode 100644 drivers/gpu/drm/vc4/Kconfig > create mode 100644 drivers/gpu/drm/vc4/Makefile > create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c > create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c > create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c > create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c > create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c > create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c > create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 06ae500..19bb0db 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -260,3 +260,5 @@ source "drivers/gpu/drm/sti/Kconfig" > source "drivers/gpu/drm/amd/amdkfd/Kconfig" > > source "drivers/gpu/drm/imx/Kconfig" > + > +source "drivers/gpu/drm/vc4/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 8858510..283ed8e 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/ > obj-$(CONFIG_DRM_I810) += i810/ > obj-$(CONFIG_DRM_I915) += i915/ > obj-$(CONFIG_DRM_MGAG200) += mgag200/ > +obj-$(CONFIG_DRM_VC4) += vc4/ > obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ > obj-$(CONFIG_DRM_SIS) += sis/ > obj-$(CONFIG_DRM_SAVAGE)+= savage/ > diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig > new file mode 100644 > index 000..e810ef7 > --- /dev/null > +++ b/drivers/gpu/drm/vc4/Kconfig > @@ -0,0 +1,13 @@ > +config DRM_VC4 > + tristate "Broadcom VC4 Graphics" > + depends on ARCH_BCM2835 > + depends on DRM > + select DRM_KMS_HELPER > + select DRM_KMS_CMA_HELPER > + help > + Choose this option if you have a system that has a Broadcom > + VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835. > + > + This driver requires that "avoid_warnings=2" be present in > + the config.txt for the firmware, to keep it from smashing > + our display setup. > diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile > new file mode 100644 > index 000..32b4f9c > --- /dev/null > +++ b/drivers/gpu/drm/vc4/Makefile > @@ -0,0 +1,17 @@ > +ccflags-y := -Iinclude/drm > + > +# Please keep these build lists sorted! > + > +# core driver code > +vc4-y := \ > + vc4_bo.o \ > + vc4_crtc.o \ > + vc4_drv.o \ > + vc4_kms.o \ > + vc4_hdmi.o \ > + vc4_hvs.o \ > + vc4_plane.o > + > +vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o > + > +obj-$(CONFIG_DRM_VC4) += vc4.o > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c > new file mode 100644 > index 000..ab9f510 > --- /dev/null > +++ b/drivers/gpu/drm/vc4/vc4_bo.c > @@ -0,0 +1,52 @@ > +/* > + * Copyright © 2015 Broadcom > + * > + * 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 > + *
Re: Proposal for finishing the 64-bit x86 syscall cleanup
* Ingo Molnar wrote: > > * Andy Lutomirski wrote: > > > Hi all- > > > > I want to (try to) mostly or fully get rid of the messy bits (as > > opposed to the hardware-bs-forced bits) of the 64-bit syscall asm. > > There are two major conceptual things that are in the way. > > > > Thing 1: partial pt_regs > > > > 64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and > > r12-r15 are uninitialized. Some syscalls require them to be > > initialized, and they have special awful stubs to do it. The entry > > and exit tracing code (except for phase1 tracing) also need them > > initialized, and they have their own messy initialization. Compat > > syscalls are their own private little mess here. > > > > This gets in the way of all kinds of cleanups, because C code can't > > switch between the full and partial pt_regs states. > > > > I can see two ways out. We could remove the optimization entirely, > > which consists of pushing and popping six more registers and adds > > about ten cycles to fast path syscalls on Sandy Bridge. It also > > simplifies and presumably speeds up the slow paths. > > So out of hundreds of regular system calls there's only a handful of such > system > calls: > > triton:~/tip> git grep stub arch/x86/entry/syscalls/ > arch/x86/entry/syscalls/syscall_32.tbl:2i386fork > sys_forkstub32_fork > arch/x86/entry/syscalls/syscall_32.tbl:11 i386execve > sys_execve stub32_execve > arch/x86/entry/syscalls/syscall_32.tbl:119 i386sigreturn > sys_sigreturn stub32_sigreturn > arch/x86/entry/syscalls/syscall_32.tbl:120 i386clone > sys_clone stub32_clone > arch/x86/entry/syscalls/syscall_32.tbl:173 i386rt_sigreturn > sys_rt_sigreturnstub32_rt_sigreturn > arch/x86/entry/syscalls/syscall_32.tbl:190 i386vfork > sys_vfork stub32_vfork > arch/x86/entry/syscalls/syscall_32.tbl:358 i386execveat > sys_execveatstub32_execveat > arch/x86/entry/syscalls/syscall_64.tbl:15 64 rt_sigreturn > stub_rt_sigreturn > arch/x86/entry/syscalls/syscall_64.tbl:56 common clone > stub_clone > arch/x86/entry/syscalls/syscall_64.tbl:57 common fork > stub_fork > arch/x86/entry/syscalls/syscall_64.tbl:58 common vfork > stub_vfork > arch/x86/entry/syscalls/syscall_64.tbl:59 64 execve > stub_execve > arch/x86/entry/syscalls/syscall_64.tbl:322 64 execveat > stub_execveat > arch/x86/entry/syscalls/syscall_64.tbl:513 x32 rt_sigreturn > stub_x32_rt_sigreturn > arch/x86/entry/syscalls/syscall_64.tbl:520 x32 execve > stub_x32_execve > arch/x86/entry/syscalls/syscall_64.tbl:545 x32 execveat > stub_x32_execveat > > and none of them are super performance critical system calls, so no way would > I > go for unconditionally saving/restoring all of ptregs, just to make it a bit > simpler for these syscalls. Let me qualify that: no way in the long run. In the short run we can drop the optimization and reintroduce it later, to lower all the risks that the C conversion brings with itself. ( That would also make it easier to re-analyze the cost/benefit ratio of the optimization. ) So feel free to introduce a simple ptregs save/restore pattern for now. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table
Hi Nan,
On Mon, Aug 24, 2015 at 06:26:33AM +, Xiao, Nan (Nan@HPS Performance,
Beijing) wrote:
> drivers/iommu/intel-iommu.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0649b94..4213598 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -759,10 +759,11 @@ static inline struct context_entry
> *iommu_context_addr(struct intel_iommu *iommu
> if (devfn >= 0x80) {
> devfn -= 0x80;
> entry = >hi;
> - }
> + } else
> + entry = >lo;
> devfn *= 2;
> - }
> - entry = >lo;
> + } else
> + entry = >lo;
> if (*entry & 1)
> context = phys_to_virt(*entry & VTD_PAGE_MASK);
> else {
Shouldn't this diff have the same effect?
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0649b94..7553cb9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -755,6 +755,7 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
struct context_entry *context;
u64 *entry;
+ entry = >lo;
if (ecs_enabled(iommu)) {
if (devfn >= 0x80) {
devfn -= 0x80;
@@ -762,7 +763,6 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
}
devfn *= 2;
}
- entry = >lo;
if (*entry & 1)
context = phys_to_virt(*entry & VTD_PAGE_MASK);
else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v2 1/5] mfd: 88pm800: Fix tabbing issue
On Tuesday 25 August 2015 01:21 PM, Lee Jones wrote: On Tue, 25 Aug 2015, Vaibhav Hiremath wrote: Driver had coding style issues where spaces were used instead of tabs. This patch fixes them all. That's not all it's doing though is it? Yes, its just tabbing related fixes. Please describe all of your changes. Signed-off-by: Vaibhav Hiremath --- drivers/mfd/88pm800.c | 125 -- 1 file changed, 61 insertions(+), 64 deletions(-) diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c index f104a32..c4e097d 100644 --- a/drivers/mfd/88pm800.c +++ b/drivers/mfd/88pm800.c @@ -30,55 +30,55 @@ #include /* Interrupt Registers */ -#define PM800_INT_STATUS1 (0x05) +#define PM800_INT_STATUS1 0x05 #define PM800_ONKEY_INT_STS1 (1 << 0) #define PM800_EXTON_INT_STS1 (1 << 1) -#define PM800_CHG_INT_STS1 (1 << 2) -#define PM800_BAT_INT_STS1 (1 << 3) -#define PM800_RTC_INT_STS1 (1 << 4) +#define PM800_CHG_INT_STS1 (1 << 2) +#define PM800_BAT_INT_STS1 (1 << 3) +#define PM800_RTC_INT_STS1 (1 << 4) #define PM800_CLASSD_OC_INT_STS1 (1 << 5) These should all be replaced by BIT(). Please fix the whole file. Will do. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: rcar: Enable r8a7795 for ARM64
From: Kuninori Morimoto
8cd1470("gpio: rcar: Add r8a7795 (R-Car H3) support") adds
GPIO support for r8a7795. r8a7795 based on CONFIG_ARM64.
This patch enables r8a7795 on ARM64.
Signed-off-by: Kuninori Morimoto
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..5d083f7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -356,7 +356,7 @@ config GPIO_PXA
config GPIO_RCAR
tristate "Renesas R-Car GPIO"
- depends on ARM && (ARCH_SHMOBILE || COMPILE_TEST)
+ depends on (ARM || ARM64) && (ARCH_SHMOBILE || COMPILE_TEST)
select GPIOLIB_IRQCHIP
help
Say yes here to support GPIO on Renesas R-Car SoCs.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: gpiolib: use devm_* API to simplify driver code
On 08/24/2015 03:05 PM, Peng Fan wrote: Use devm_* API to simplify driver code. Signed-off-by: Peng Fan Cc: Linus Walleij Cc: Alexandre Courbot --- drivers/gpio/gpiolib.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 6bc612b..f9470b0 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -243,7 +243,8 @@ int gpiochip_add(struct gpio_chip *chip) int base = chip->base; struct gpio_desc *descs; - descs = kcalloc(chip->ngpio, sizeof(descs[0]), GFP_KERNEL); + descs = devm_kcalloc(chip->dev, chip->ngpio, sizeof(descs[0]), +GFP_KERNEL); ^ above will not work for every one as NOT all GPIO drivers implemented using dev/drv model, so chip->dev could be not set (at least it was true when I've checked it last time). -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed()
On 8/25/15 4:30 PM, Ingo Molnar wrote:
* Wanpeng Li wrote:
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2376,8 +2376,12 @@ void cpuset_cpus_allowed(struct task_struct *tsk, struct
cpumask *pmask)
void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
{
+ unsigned long flags;
+
rcu_read_lock();
+ raw_spin_lock_irqsave(>pi_lock, flags);
do_set_cpus_allowed(tsk, task_cs(tsk)->effective_cpus);
+ raw_spin_lock_irqsave(>pi_lock, flags);
Just curious, Will introduce deadlock after acquire lock twice? ;)
Could you point out where acquires lock twice?
In the code you quote?
Shame me, sorry for sending out the wrong version. I fix in it soon in v2.
Regards,
Wanpeng Li
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v2 5/5] mfd: 88pm800: Add support for clk subdevice
On Tuesday 25 August 2015 01:19 PM, Lee Jones wrote:
On Tue, 25 Aug 2015, Krzysztof Kozlowski wrote:
On 25.08.2015 03:56, Vaibhav Hiremath wrote:
This patch adds mfd_cell/clk-subdevice for 88PM800 MFD
(and family of devices).
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index c4e097d..a928eed 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -173,6 +173,14 @@ static const struct mfd_cell regulator_devs[] = {
},
};
+static struct mfd_cell clk_devs[] = {
+ {
+ .name = "88pm80x-clk",
+ .of_compatible = "marvell,88pm800-clk",
+ .id = -1,
The "-1" here stands for PLATFORM_DEVID_NONE?
Right. Please use the define, but use it in the mfd_add_devices()
call, rather than individual cells.
Ok,
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns
* Denys Vlasenko wrote: > On 08/24/2015 08:50 AM, Ingo Molnar wrote: > > > > * Ingo Molnar wrote: > > > >> > >> * Denys Vlasenko wrote: > >> > >>> I propose the table to be commented like shown below: > >>> > >>> /*Opcode: d8 d9da db dc dd de df */ > >>> /*c0..f*/ fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_, > >>> _df_c0_, > >>> /*c8..f*/ fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, > >>> _df_c8_, > >>> /*d0..7*/ fcom_st,fp_nop, fcmovbe,fcmovnbe,_dc_d0_,fst_i_, > >>> _de_d0_,_df_d0_, > >>> /*d8..f*/ fcompst,_d9_d8_, fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, > >>> _df_d8_, > >>> /*e0..7*/ fsub__, FPU_etc, __BAD__,finit_, fsubri, fucom_, fsubrp, > >>> fstsw_, > >>> /*e8..f*/ fsubr_, fconst, fucompp,fucomi_, fsub_i, fucomp, fsubp_, > >>> fucomip, > >>> /*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_, fdivri, __BAD__,fdivrp, > >>> fcomip, > >>> /*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, > >>> __BAD__, > >> > >> I agree with that, but please fix the vertical alignment (like my patch > >> did), as > >> the table is pretty hard to navigate in this form. > > > > and by that I mean to split each line into two, to have groups of 4 > > instructions > > and enough tabs between them. > > How would you want it? Like this? > > /*Opcode: d8 d9 da db */ > /*dc dd de df */ > /*c0..f*/ fadd__, fld_i_,fcmovb, fcmovnb, > /*c0..f*/ fadd_i, ffree_,faddp_, _df_c0_, > /*c8..f*/ fmul__, fxch_i,fcmove, fcmovne, > /*c8..f*/ fmul_i, _dd_c8_, fmulp_, _df_c8_, > /*d0..7*/ fcom_st, fp_nop,fcmovbe, fcmovnbe, > /*d0..7*/ _dc_d0_, fst_i_,_de_d0_, _df_d0_, > /*d8..f*/ fcompst, _d9_d8_, fcmovu, fcmovnu, > /*d8..f*/ _dc_d8_, fstp_i,fcompp, _df_d8_, > /*e0..7*/ fsub__, FPU_etc, __BAD__, finit_, > /*e0..7*/ fsubri, fucom_,fsubrp, fstsw_, > /*e8..f*/ fsubr_, fconst,fucompp, fucomi_, > /*e8..f*/ fsub_i, fucomp,fsubp_, fucomip, > /*f0..7*/ fdiv__, FPU_triga, __BAD__, fcomi_, > /*f0..7*/ fdivri, __BAD__, fdivrp, fcomip, > /*f8..f*/ fdivr_, FPU_trigb, __BAD__, __BAD__, > /*f8..f*/ fdiv_i, __BAD__, fdivp_, __BAD__, Yeah, although we could afford a few more tabs and spaces to make it less claustrophobic, right? Something like this: /* c0..f */fadd__, fld_i_, fcmovb, fcmovnb, /* c0..f */fadd_i, ffree_, faddp_, _df_c0_, /* c8..f */fmul__, fxch_i, fcmove, fcmovne, /* c8..f */fmul_i, _dd_c8_,fmulp_, _df_c8_, /* d0..7 */fcom_st,fp_nop, fcmovbe, fcmovnbe, /* d0..7 */_dc_d0_,fst_i_, _de_d0_,_df_d0_, /* d8..f */fcompst,_d9_d8_ fcmovu, fcmovnu, /* d8..f */_dc_d8_,fstp_i, fcompp, _df_d8_, /* e0..7 */fsub__, FPU_etc,__BAD__,finit_, /* e0..7 */fsubri, fucom_, fsubrp, fstsw_, /* e8..f */fsubr_, fconst, fucompp,fucomi_, /* e8..f */fsub_i, fucomp, fsubp_, fucomip, /* f0..7 */fdiv__, FPU_triga, __BAD__,fcomi_, /* f0..7 */fdivri, __BAD__,fdivrp, fcomip, /* f8..f */fdivr_, FPU_trigb, __BAD__,__BAD__, /* f8..f */fdiv_i, __BAD__,fdivp_, __BAD__, looks pretty good to me. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Aug 25
Hi all, Changes since 20150824: The nfs tree still had its build failure for which I disabled a staging driver. The i2c tree gained a build failure so I used the version from next-20150824. The net-next tree lost its build failure. The tty tree still had its build failure for which I reverted part of a commit. Non-merge commits (relative to Linus' tree): 9579 8393 files changed, 511821 insertions(+), 200348 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (c13dcf9f2d6f Linux 4.2-rc8) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (3939f3345050 ARM: 8418/1: add boot image dependencies to not generate invalid images) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (f7644cbfcdf0 Linux 4.2-rc6) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (b6df7d61c877 net: bcmgenet: fix uncleaned dma flags) Merging ipsec/master (158cd4af8ded packet: missing dev_put() in packet_do_bind()) Merging sound-current/for-linus (c7e69ae6b4ff ALSA: hda: fix possible NULL dereference) Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses on PA-RISC) Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() call to error pathway) Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module) Merging staging.current/staging-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging input-current/for-linus (1ae5ddb6f883 Input: gpio_keys_polled - request GPIO pin as input.) Merging crypto-current/master (b310c178e6d8 crypto: caam - fix memory corruption in ahash_final_ctx) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct) Merging mfd-fixes/for-mfd-fixes (fb9caeedafe6 mfd: Remove MFD_CROS_EC_SPI depends on OF) Merging drm-intel-fixes/for-linux-next-fixes
Re: [PATCH] mm/backing-dev: Check return value of the debugfs_create_dir()
On Tue 25-08-15 13:54:23, Alexander Kuleshov wrote:
> The debugfs_create_dir() function may fail and return error. If the
> root directory not created, we can't create anything inside it. This
> patch adds check for this case.
>
> Signed-off-by: Alexander Kuleshov
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/backing-dev.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/mm/backing-dev.c b/mm/backing-dev.c
> index dac5bf5..518d26a 100644
> --- a/mm/backing-dev.c
> +++ b/mm/backing-dev.c
> @@ -117,15 +117,21 @@ static const struct file_operations
> bdi_debug_stats_fops = {
>
> static void bdi_debug_register(struct backing_dev_info *bdi, const char
> *name)
> {
> - bdi->debug_dir = debugfs_create_dir(name, bdi_debug_root);
> - bdi->debug_stats = debugfs_create_file("stats", 0444, bdi->debug_dir,
> -bdi, _debug_stats_fops);
> + if (bdi_debug_root) {
> + bdi->debug_dir = debugfs_create_dir(name, bdi_debug_root);
> + if (bdi->debug_dir)
> + bdi->debug_stats = debugfs_create_file("stats", 0444,
> + bdi->debug_dir, bdi,
> + _debug_stats_fops);
> + }
> }
>
> static void bdi_debug_unregister(struct backing_dev_info *bdi)
> {
> - debugfs_remove(bdi->debug_stats);
> - debugfs_remove(bdi->debug_dir);
> + if (bdi_debug_root) {
> + debugfs_remove(bdi->debug_stats);
> + debugfs_remove(bdi->debug_dir);
> + }
> }
> #else
> static inline void bdi_debug_init(void)
> --
> 2.5.0
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v3] mfd: 88pm80x: Add 88pm860 chip type support
On Tuesday 25 August 2015 12:08 PM, Mark Brown wrote: On Mon, Aug 24, 2015 at 12:32:17PM +0530, Vaibhav Hiremath wrote: On Monday 20 July 2015 05:22 PM, Vaibhav Hiremath wrote: Add chip identification support for 88PM860 device to the pm80x_chip_mapping table. Last update/understanding which I have on this patch is, Lee is OK with taking this patch from regulator tree. Lee please let me know if you think otherwise. With this patch in, the build dependency will go away. Request to pick this patch into your topic/88pm800 branch and run build test. Please don't send content free pings, they just waste time. I can't review or apply content free pings. Please submit patches following the process in SubmittingPatches. The chances are I deleted this mail unread since it is a MFD patch... Hmmm Ok, Resending now... Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed()
* Wanpeng Li wrote:
> >>--- a/kernel/cpuset.c
> >>+++ b/kernel/cpuset.c
> >>@@ -2376,8 +2376,12 @@ void cpuset_cpus_allowed(struct task_struct *tsk,
> >>struct cpumask *pmask)
> >> void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
> >> {
> >>+ unsigned long flags;
> >>+
> >>rcu_read_lock();
> >>+ raw_spin_lock_irqsave(>pi_lock, flags);
> >>do_set_cpus_allowed(tsk, task_cs(tsk)->effective_cpus);
> >>+ raw_spin_lock_irqsave(>pi_lock, flags);
> >Just curious, Will introduce deadlock after acquire lock twice? ;)
>
> Could you point out where acquires lock twice?
In the code you quote?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v2 5/5] mfd: 88pm800: Add support for clk subdevice
On Tuesday 25 August 2015 10:55 AM, Krzysztof Kozlowski wrote:
On 25.08.2015 03:56, Vaibhav Hiremath wrote:
This patch adds mfd_cell/clk-subdevice for 88PM800 MFD
(and family of devices).
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index c4e097d..a928eed 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -173,6 +173,14 @@ static const struct mfd_cell regulator_devs[] = {
},
};
+static struct mfd_cell clk_devs[] = {
+ {
+ .name = "88pm80x-clk",
+ .of_compatible = "marvell,88pm800-clk",
+ .id = -1,
The "-1" here stands for PLATFORM_DEVID_NONE?
Yes,
But it is rarely used in the kernel. so was reluctant to use and
decided to follow existing implementation.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v6 5/6] mfd: 88pm800: Set default interrupt clear method
On Mon, 24 Aug 2015, Vaibhav Hiremath wrote:
>
>
> On Monday 24 August 2015 09:21 PM, Lee Jones wrote:
> >On Mon, 24 Aug 2015, Vaibhav Hiremath wrote:
> >
> >>
> >>
> >>On Monday 24 August 2015 07:24 PM, Lee Jones wrote:
> >>>On Wed, 08 Jul 2015, Vaibhav Hiremath wrote:
> >>>
> As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
> (page 0) controls the method of clearing interrupt
> status of 88pm800 family of devices;
>
> 0: clear on read
> 1: clear on write
>
> If pdata is not coming from board file, then set the
> default irq clear method to "irq clear on write"
>
> Also, as suggested by "Lee Jones" renaming variable field
> to appropriate name and removed unnecessary field
> pm80x_chip.irq_mode, using platform_data.irq_clr_method.
>
> Signed-off-by: Zhao Ye
> Signed-off-by: Vaibhav Hiremath
> Reviewed-by: Krzysztof Kozlowski
> ---
> drivers/mfd/88pm800.c | 15 ++-
> include/linux/mfd/88pm80x.h | 9 +++--
> 2 files changed, 17 insertions(+), 7 deletions(-)
> >>>
> >>>[...]
> >>>
> +#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
> +#define PM800_WAKEUP2_INT_WRITE_CLEAR(1 << 1)
> >>>
> >>>Use BIT().
> >>>
> +/* Used by irq_clr_method */
> +#define PM800_IRQ_CLR_ON_READ0
> +#define PM800_IRQ_CLR_ON_WRITE 1
> >>>
> - int irq_mode; /* Clear interrupt by read/write(0/1) */
> + bool irq_clr_method;/* Clear interrupt by read/write(0/1) */
> >>>
> + irq_clr_mode = pdata->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
> + PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
> + ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
> >>>
> >>>This is pretty convoluted.
> >>>
> >>>For starters you're abusing the 'bool' type here. Bool is either
> >>>'true' or 'false', so at the very least you should rename
> >>>'irq_clr_method' to 'irq_clr_on_write'.
> >>>
> >>>Then you can do:
> >>>
> >>> irq_clr_mode = pdata->irq_clr_on_write ?
> >>> PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
> >>>
> >>
> >>We have discussed on this, and went back-n-forth.
> >>I think if I remember correctly, one of the version was using
> >>true/false then we decided to rename it to relevant macro.
> >>
> >>If I am not wrong V4 version of this series is exactly same as what you
> >>are referring to.
> >
> >Right. I made a few suggestions which vary in usefulness depending on
> >how you plan to implement all of this. Unfortunately this is a bit of
> >a bastardised version where some of it make sense and other parts
> >could do with some improvement.
> >
>
> This so called "basterdised version could have been avoided :)
>
> V2 version itself was clean and ready. It just got dragged into
> multiple iterations.
Don't kid yourself. There were still improvements to be made.
> >>>However, what I suggest you really do is share
> >>>PM800_WAKEUP2_INT_{READ,WRITE}_CLEAR with platform data and just pass
> >>>the value through directly.
> >>>
> >>
> >>I think we discussed about this also, and the reason I recall here is,
> >>
> >>we may need to control this from DT in the future so we decided to keep
> >>it boolean in platform_data and have simple check before writing to
> >>register.
> >>
> >>And I think that was also another reason we introduced
> >>
> >>/* Used by irq_clr_method */
> >>#define PM800_IRQ_CLR_ON_READ 0
> >>#define PM800_IRQ_CLR_ON_WRITE 1
> >
> >I think these are still required. So it would look like this:
> >
>
> NO. I think you are confused here,
> We have two different macros playing around here,
>
>
> +/* Used by irq_clr_method */
> +#define PM800_IRQ_CLR_ON_READ0
> +#define PM800_IRQ_CLR_ON_WRITE 1
>
> /* Used to write to register */
> +#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
> +#define PM800_WAKEUP2_INT_WRITE_CLEAR(1 << 1)
I know. I used both of them *correctly* in my example below. No
confusion here.
> >== Platform data ==
> >
> >struct pdata {
> > bool clear_irq_on_write;
> >};
> >
> >pdata->clear_irq_on_write = PM800_IRQ_CLR_ON_{READ,WRITE};
> >
> >== Driver ==
> >
> >irq_clr_mode = pdata->clear_irq_on_write ?
> > PM800_WAKEUP2_INT_WRITE_CLEAR :
> > PM800_WAKEUP2_INT_READ_CLEAR;
> >regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
> >
>
> Please check V2, which is exactly same as above.
>
> https://patchwork.kernel.org/patch/6627781/
>
>
> If you are OK with it, I will spin another version and submit it.
If you can't use the value directly, which if you want to pull the
value from DT you can't, then either use the method above, or
something like this might be better:
int clear_on_write = 0;
if (pdata->clear_irq_on_write)
clear_on_write = PM800_WAKEUP2_INT_WRITE_CLEAR;
.. this way you only need to add one new define and you can drop
PM800_WAKEUP2_INT_READ_CLEAR
Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
* Frederic Weisbecker wrote: > On Mon, Aug 24, 2015 at 08:44:12AM +0200, Ingo Molnar wrote: > > 2) > > > > What happens if the boot CPU is offlined? (under > > CONFIG_BOOTPARAM_HOTPLUG_CPU0=y) > > > > I don't see CPU hotplug callbacks fixing up the housekeeping_mask if the > > boot CPU > > is offlined. > > We have tick_nohz_cpu_down_callback() which makes sure that the timekeeper, > which > is the boot CPU in nohz full, never gets offlined. That solution really sucks - it essentially regresses a feature the user explicitly asked for! I also see no way for the user to migrate the timekeeping functionality over to another CPU without rebooting. If this is the last timekeeping CPU then it should migrate the timekeeping functionality to another CPU, and perhaps printk a warning if all other CPUs are nohz-full and we have to mark one of them as the timekeeper. Also, the nohz-full and timekeeper functionality should not be a boot parameter only thing, but should be runtime configurable. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
Commit-ID: 9e517ac88b2443bebc0499c0b477b155d63648a7
Gitweb: http://git.kernel.org/tip/9e517ac88b2443bebc0499c0b477b155d63648a7
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:25 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:44 +0200
drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get an
MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: Laurent Pinchart
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: toshi.k...@hp.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-4-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/video/fbdev/kyro/fbdev.c | 33 +++--
include/video/kyro.h | 4 +---
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 65041e1..5bb0153 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -22,9 +22,6 @@
#include
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
#include
@@ -84,9 +81,7 @@ static device_info_t deviceInfo;
static char *mode_option = NULL;
static int nopan = 0;
static int nowrap = 1;
-#ifdef CONFIG_MTRR
static int nomtrr = 0;
-#endif
/* PCI driver prototypes */
static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -570,10 +565,8 @@ static int __init kyrofb_setup(char *options)
nopan = 1;
} else if (strcmp(this_opt, "nowrap") == 0) {
nowrap = 1;
-#ifdef CONFIG_MTRR
} else if (strcmp(this_opt, "nomtrr") == 0) {
nomtrr = 1;
-#endif
} else {
mode_option = this_opt;
}
@@ -691,17 +684,16 @@ static int kyrofb_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
currentpar->regbase = deviceInfo.pSTGReg =
ioremap_nocache(kyro_fix.mmio_start, kyro_fix.mmio_len);
+ if (!currentpar->regbase)
+ goto out_free_fb;
- info->screen_base = ioremap_nocache(kyro_fix.smem_start,
- kyro_fix.smem_len);
+ info->screen_base = pci_ioremap_wc_bar(pdev, 0);
+ if (!info->screen_base)
+ goto out_unmap_regs;
-#ifdef CONFIG_MTRR
if (!nomtrr)
-
[tip:x86/mm] drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style
Commit-ID: 39c33704420b147fb7e193a9f406cc8420a1d610
Gitweb: http://git.kernel.org/tip/39c33704420b147fb7e193a9f406cc8420a1d610
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:31 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:46 +0200
drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style
dma_alloc_writecombine()'s call and return value check is
tangled in all in one call. Untangle both calls according to
kernel coding style.
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Vinod Koul
Cc: Dan Williams
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: daniel.vet...@ffwll.ch
Cc: dmaeng...@vger.kernel.org
Cc: konrad.w...@oracle.com
Cc: l...@amacapital.net
Cc: m...@redhat.com
Cc: tomi.valkei...@ti.com
Cc: toshi.k...@hp.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-10-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/dma/iop-adma.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 9988268..e4f4312 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -1300,10 +1300,11 @@ static int iop_adma_probe(struct platform_device *pdev)
* note: writecombine gives slightly better performance, but
* requires that we explicitly flush the writes
*/
- if ((adev->dma_desc_pool_virt = dma_alloc_writecombine(>dev,
- plat_data->pool_size,
- >dma_desc_pool,
- GFP_KERNEL)) == NULL) {
+ adev->dma_desc_pool_virt = dma_alloc_writecombine(>dev,
+ plat_data->pool_size,
+ >dma_desc_pool,
+ GFP_KERNEL);
+ if (!adev->dma_desc_pool_virt) {
ret = -ENOMEM;
goto err_free_adev;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc()
Commit-ID: 4edcd2ab125506516c7de038f6e0a6d19dcc411d
Gitweb: http://git.kernel.org/tip/4edcd2ab125506516c7de038f6e0a6d19dcc411d
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:29 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:45 +0200
drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc()
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get an
MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: Lad, Prabhakar
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rickard Strandqvist
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: toshi.k...@hp.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-8-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/video/fbdev/s3fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a..13b1090 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
struct s3fb_info {
int chip, rev, mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
-
static int fasttext = 1;
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc)
(deprecated)");
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable,
default=1)");
-#endif
module_param(fasttext, int, 0644);
MODULE_PARM_DESC(fasttext, "Enable S3 fast text mode (1=enable, 0=disable,
default=1)");
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
[tip:x86/mm] drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc()
Commit-ID: 81bdef04d3bc76fc516ca613fa96061ff27bced9
Gitweb: http://git.kernel.org/tip/81bdef04d3bc76fc516ca613fa96061ff27bced9
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:30 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:45 +0200
drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc()
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get an
MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: Lad, Prabhakar
Cc: Laurent Pinchart
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: toshi.k...@hp.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-9-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/video/fbdev/vt8623fb.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index 8bac309..dd0f18e 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
#include /* Why should fb driver call console functions?
because console_lock() */
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
struct vt8623fb_info {
char __iomem *mmio_base;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
/* Module parameters */
static char *mode_option = "640x480-8@60";
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
MODULE_AUTHOR("(c) 2006 Ondrej Zajicek ");
MODULE_LICENSE("GPL");
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0);
MODULE_PARM_DESC(mode, "Default video mode e.g. '648x480-8@60' (deprecated)");
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable,
default=1)");
-#endif
/* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
info->fix.mmio_len = pci_resource_len(dev, 1);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+
[tip:x86/mm] drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc()
Commit-ID: c823a48ac47f8e0274fa7c8a3befae4bfa8412e3
Gitweb: http://git.kernel.org/tip/c823a48ac47f8e0274fa7c8a3befae4bfa8412e3
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:28 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:45 +0200
drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc()
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and
onx86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get an
MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Lad, Prabhakar
Cc: Laurent Pinchart
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: toshi.k...@hp.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-7-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/video/fbdev/arkfb.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e..6a317de 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
#include /* Why should fb driver call console functions?
because console_lock() */
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
struct arkfb_info {
int mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
static char *mode_option = "640x480-8@60";
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
MODULE_AUTHOR("(c) 2007 Ondrej Zajicek ");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("fbdev driver for ARK 2000PV");
@@ -115,11 +107,6 @@ MODULE_PARM_DESC(mode_option, "Default video mode
('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc)
(deprecated)");
-#ifdef CONFIG_MTRR
-module_param(mtrr, int, 0444);
-MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable,
default=1)");
-#endif
-
static int threshold = 4;
module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
[tip:x86/mm] PCI: Add pci_iomap_wc() variants
Commit-ID: 1b3d4200c1e00a3fb5e0aea428de5b07079a37e3
Gitweb: http://git.kernel.org/tip/1b3d4200c1e00a3fb5e0aea428de5b07079a37e3
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:27 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:45 +0200
PCI: Add pci_iomap_wc() variants
PCI BARs tell us whether prefetching is safe, but they don't say
anything about write combining (WC). WC changes ordering rules
and allows writes to be collapsed, so it's not safe in general
to use it on a prefetchable region.
Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take
advantage of write combining when they know it's safe.
On architectures that don't fully support WC, e.g., x86 without
PAT, drivers for legacy framebuffers may get some of the benefit
by using arch_phys_wc_add() in addition to pci_iomap_wc(). But
arch_phys_wc_add() is unreliable and should be avoided in
general. On x86, it uses MTRRs, which are limited in number and
size, so the results will vary based on driver loading order.
The goals of adding pci_iomap_wc() are to:
- Give drivers an architecture-independent way to use WC so they can stop
using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
PAT when available).
- Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
and pci_mmap_page_range()").
Signed-off-by: Luis R. Rodriguez
[ Move IORESOURCE_IO check up, space out statements for better readability. ]
Signed-off-by: Borislav Petkov
Acked-by: Arnd Bergmann
Cc:
Cc:
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Dave Hansen
Cc: Davidlohr Bueso
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Mel Gorman
Cc: Michael S. Tsirkin
Cc: Peter Zijlstra
Cc: Roger Pau Monné
Cc: Rusty Russell
Cc: Stefan Bader
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: dan.j.willi...@intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: konrad.w...@oracle.com
Cc: linux-a...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: venkatesh.pallip...@intel.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-6-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
include/asm-generic/pci_iomap.h | 14 +
lib/pci_iomap.c | 66 +
2 files changed, 80 insertions(+)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87..b1e17fc 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long
max);
extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
int bar, unsigned lon
return NULL;
}
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar,
unsigned long max)
+{
+ return NULL;
+}
static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
{
return NULL;
}
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f1..5f5d24d 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,51 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
EXPORT_SYMBOL(pci_iomap_range);
/**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen:
Re: [PATCH V2 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
On Tue, 25 Aug 2015 15:47:14 +0800
Jason Wang wrote:
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index 9ff4193..95f2901 100644
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
> @@ -762,13 +762,15 @@ ioeventfd_check_collision(struct kvm *kvm, struct
> _ioeventfd *p)
> return false;
> }
>
> -static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
> +static enum kvm_bus ioeventfd_bus_from_flags(struct kvm_ioeventfd *args)
ioeventfd_bus_from_args()? But _from_flags() is not wrong either :)
> {
> - if (flags & KVM_IOEVENTFD_FLAG_PIO)
> + if (args->flags & KVM_IOEVENTFD_FLAG_PIO)
> return KVM_PIO_BUS;
> - if (flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
> + if (args->flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
> return KVM_VIRTIO_CCW_NOTIFY_BUS;
> - return KVM_MMIO_BUS;
> + if (args->len)
> + return KVM_MMIO_BUS;
> + return KVM_FAST_MMIO_BUS;
Hm...
/* When length is ignored, MMIO is put on a separate bus, for
* faster lookups.
*/
return args->len ? KVM_MMIO_BUS : KVM_FAST_MMIO_BUS;
> }
>
> static int
This version of the patch looks nice and compact. Regardless whether
you want to follow my (minor) style suggestions, consider this patch
Acked-by: Cornelia Huck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
Commit-ID: c112709809b2ca1e8ff2841a1958503e548b81e4
Gitweb: http://git.kernel.org/tip/c112709809b2ca1e8ff2841a1958503e548b81e4
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:24 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:44 +0200
drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture-specific and
onx86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get an
MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: Benoit Taine
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: toshi.k...@hp.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-3-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/video/fbdev/i740fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c
index a2b4204..452e116 100644
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -27,24 +27,15 @@
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
#include "i740_reg.h"
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
struct i740fb_par {
unsigned char __iomem *regs;
bool has_sgram;
-#ifdef CONFIG_MTRR
- int mtrr_reg;
-#endif
+ int wc_cookie;
bool ddc_registered;
struct i2c_adapter ddc_adapter;
struct i2c_algo_bit_data ddc_algo;
@@ -1040,7 +1031,7 @@ static int i740fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
goto err_request_regions;
}
- info->screen_base = pci_ioremap_bar(dev, 0);
+ info->screen_base = pci_ioremap_wc_bar(dev, 0);
if (!info->screen_base) {
dev_err(info->device, "error remapping base\n");
ret = -ENOMEM;
@@ -1144,13 +1135,9 @@ static int i740fb_probe(struct pci_dev *dev, const
struct pci_device_id *ent)
fb_info(info, "%s frame buffer device\n", info->fix.id);
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start,
- info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
Re: [PATCH] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed()
On 8/25/15 4:13 PM, Leo Yan wrote:
Hi Wanpeng,
On Tue, Aug 25, 2015 at 03:59:54PM +0800, Wanpeng Li wrote:
[ 15.273708] [ cut here ]
[ 15.274097] WARNING: CPU: 0 PID: 13 at kernel/sched/core.c:1156
do_set_cpus_allowed+0x7e/0x80()
[ 15.274857] Modules linked in:
[ 15.275101] CPU: 0 PID: 13 Comm: migration/0 Not tainted
4.2.0-rc1-00049-g25834c7 #2
[ 15.275674] d21f1d24 c19228b2 d21f1d58 c1056a3b
c1ba00e4
[ 15.276084] 000d c1ba17d8 0484 c10838be 0484 c10838be
d21e5000
[ 15.276084] d2121900 d21e5158 d21f1d68 c1056b12 0009 d21f1d7c
c10838be
[ 15.276084] Call Trace:
[ 15.276084] [] dump_stack+0x4b/0x75
[ 15.276084] [] warn_slowpath_common+0x8b/0xc0
[ 15.276084] [] ? do_set_cpus_allowed+0x7e/0x80
[ 15.276084] [] ? do_set_cpus_allowed+0x7e/0x80
[ 15.276084] [] warn_slowpath_null+0x22/0x30
[ 15.276084] [] do_set_cpus_allowed+0x7e/0x80
[ 15.276084] [] cpuset_cpus_allowed_fallback+0x7c/0x170
[ 15.276084] [] ? cpuset_cpus_allowed+0x180/0x180
[ 15.276084] [] select_fallback_rq+0x221/0x280
[ 15.276084] [] migration_call+0xe3/0x250
[ 15.276084] [] notifier_call_chain+0x53/0x70
[ 15.276084] [] __raw_notifier_call_chain+0x1e/0x30
[ 15.276084] [] cpu_notify+0x28/0x50
[ 15.276084] [] take_cpu_down+0x22/0x40
[ 15.276084] [] multi_cpu_stop+0xd5/0x140
[ 15.276084] [] ? __stop_cpus+0x80/0x80
[ 15.276084] [] cpu_stopper_thread+0xbc/0x170
[ 15.276084] [] ? preempt_count_sub+0x9/0x50
[ 15.276084] [] ? _raw_spin_unlock_irq+0x37/0x50
[ 15.276084] [] ? _raw_spin_unlock_irqrestore+0x55/0x70
[ 15.276084] [] ? trace_hardirqs_on_caller+0x144/0x1e0
[ 15.276084] [] ? cpu_stop_should_run+0x35/0x40
[ 15.276084] [] ? preempt_count_sub+0x9/0x50
[ 15.276084] [] ? _raw_spin_unlock_irqrestore+0x41/0x70
[ 15.276084] [] smpboot_thread_fn+0x174/0x2f0
[ 15.276084] [] ? sort_range+0x30/0x30
[ 15.276084] [] kthread+0xc4/0xe0
[ 15.276084] [] ret_from_kernel_thread+0x21/0x30
[ 15.276084] [] ? kthread_create_on_node+0x180/0x180
[ 15.276084] ---[ end trace 15f4c86d404693b0 ]---
After commit (25834c73f93: sched: Fix a race between __kthread_bind()
and sched_setaffinity()) do_set_cpus_allowed() should be called w/
p->pi_lock held, however, it is not true in cpuset path currently.
This patch fix it by holding p->pi_lock in cpuset path.
Signed-off-by: Wanpeng Li
---
kernel/cpuset.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index e414ae9..605ed66 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2376,8 +2376,12 @@ void cpuset_cpus_allowed(struct task_struct *tsk, struct
cpumask *pmask)
void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
{
+ unsigned long flags;
+
rcu_read_lock();
+ raw_spin_lock_irqsave(>pi_lock, flags);
do_set_cpus_allowed(tsk, task_cs(tsk)->effective_cpus);
+ raw_spin_lock_irqsave(>pi_lock, flags);
Just curious, Will introduce deadlock after acquire lock twice? ;)
Could you point out where acquires lock twice?
Regards,
Wanpeng Li
Thanks,
Leo Yan
rcu_read_unlock();
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar( ) to map framebuffer
Commit-ID: f3adccbd75831f3651ca6e2cbb83f27cd68a27c9
Gitweb: http://git.kernel.org/tip/f3adccbd75831f3651ca6e2cbb83f27cd68a27c9
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:26 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:44 +0200
drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available.
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Laurent Pinchart
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: toshi.k...@hp.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-5-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..f19133a 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
info->fix.smem_start = fb_phys;
info->fix.smem_len = pci_resource_len(pdev, 1);
- info->screen_base = pci_ioremap_bar(pdev, 1);
+ info->screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info->screen_base) {
dev_err(>dev, "gxt4500: cannot map framebuffer\n");
goto err_unmap_regs;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] powerpc: use jump label for {cpu,mmu}_has_feature()
* Kevin Hao wrote:
> Hi,
>
> v2:
> Drop the following two patches as suggested by Ingo and Peter:
> jump_label: no need to acquire the jump_label_mutex in jump_lable_init()
> jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros
>
> v1:
> I have tried to change the {cpu,mmu}_has_feature() to use jump label two yeas
> ago [1]. But that codes seem a bit ugly. This is a reimplementation by moving
> the
> jump_label_init() much earlier so the jump label can be used in a very earlier
> stage. Boot test on p4080ds, t2080rdb and powermac (qemu). This patch series
> is against linux-next.
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111026.html
>
> Kevin Hao (6):
> jump_label: make it possible for the archs to invoke jump_label_init()
> much earlier
> powerpc: invoke jump_label_init() in a much earlier stage
> powerpc: kill mfvtb()
> powerpc: move the cpu_has_feature to a separate file
> powerpc: use the jump label for cpu_has_feature
> powerpc: use jump label for mmu_has_feature
>
> arch/powerpc/include/asm/cacheflush.h | 1 +
> arch/powerpc/include/asm/cpufeatures.h | 34 ++
> arch/powerpc/include/asm/cputable.h | 16 +++---
> arch/powerpc/include/asm/cputime.h | 1 +
> arch/powerpc/include/asm/dbell.h| 1 +
> arch/powerpc/include/asm/dcr-native.h | 1 +
> arch/powerpc/include/asm/mman.h | 1 +
> arch/powerpc/include/asm/mmu.h | 29 ++
> arch/powerpc/include/asm/reg.h | 9
> arch/powerpc/include/asm/time.h | 3 ++-
> arch/powerpc/include/asm/xor.h | 1 +
> arch/powerpc/kernel/align.c | 1 +
> arch/powerpc/kernel/cputable.c | 37
> +
> arch/powerpc/kernel/irq.c | 1 +
> arch/powerpc/kernel/process.c | 1 +
> arch/powerpc/kernel/setup-common.c | 1 +
> arch/powerpc/kernel/setup_32.c | 5 +
> arch/powerpc/kernel/setup_64.c | 4
> arch/powerpc/kernel/smp.c | 1 +
> arch/powerpc/platforms/cell/pervasive.c | 1 +
> arch/powerpc/xmon/ppc-dis.c | 1 +
> kernel/jump_label.c | 3 +++
> 22 files changed, 135 insertions(+), 18 deletions(-)
> create mode 100644 arch/powerpc/include/asm/cpufeatures.h
Looks good to me!
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] PCI: Add pci_ioremap_wc_bar()
Commit-ID: c43996f4001de629af4a4d6713782e883677e5b9
Gitweb: http://git.kernel.org/tip/c43996f4001de629af4a4d6713782e883677e5b9
Author: Luis R. Rodriguez
AuthorDate: Mon, 24 Aug 2015 12:13:23 -0700
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:59:43 +0200
PCI: Add pci_ioremap_wc_bar()
This lets drivers take advantage of PAT when available. It
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache(), see:
de33c442ed2a ("x86 PAT: fix performance drop for glx, use UC minus for
ioremap(), ioremap_nocache() and pci_mmap_page_range()")
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Borislav Petkov
Acked-by: Arnd Bergmann
Cc:
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Davidlohr Bueso
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Mel Gorman
Cc: Peter Zijlstra
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Cc: airl...@linux.ie
Cc: b...@kernel.crashing.org
Cc: dan.j.willi...@intel.com
Cc: konrad.w...@oracle.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: vinod.k...@intel.com
Cc: xen-de...@lists.xensource.com
Link:
http://lkml.kernel.org/r/1440443613-13696-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0008c95..fdae37b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -138,6 +138,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
bar)
return ioremap_nocache(res->start, resource_size(res));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
+ return ioremap_wc(pci_resource_start(pdev, bar),
+ pci_resource_len(pdev, bar));
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
#define PCI_FIND_CAP_TTL 48
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8a0321a..985dd39 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1661,6 +1661,7 @@ static inline void pci_mmcfg_late_init(void) { }
int pci_ext_cfg_avail(void);
void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
#ifdef CONFIG_PCI_IOV
int pci_iov_virtfn_bus(struct pci_dev *dev, int id);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm: Make kernel/check.c explicitly non-modular
Commit-ID: 13fe86f465b72fc9328d4f5ebc33223c011852ae Gitweb: http://git.kernel.org/tip/13fe86f465b72fc9328d4f5ebc33223c011852ae Author: Paul Gortmaker AuthorDate: Mon, 24 Aug 2015 19:34:55 -0400 Committer: Ingo Molnar CommitDate: Tue, 25 Aug 2015 09:48:38 +0200 x86/mm: Make kernel/check.c explicitly non-modular The Kconfig currently controlling compilation of this code is: arch/x86/Kconfig:config X86_CHECK_BIOS_CORRUPTION arch/x86/Kconfig: bool "Check for low memory corruption" ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Signed-off-by: Paul Gortmaker Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1440459295-21814-4-git-send-email-paul.gortma...@windriver.com Signed-off-by: Ingo Molnar --- arch/x86/kernel/check.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/check.c b/arch/x86/kernel/check.c index 83a7995..f40cfd1 100644 --- a/arch/x86/kernel/check.c +++ b/arch/x86/kernel/check.c @@ -1,4 +1,4 @@ -#include +#include #include #include #include @@ -162,6 +162,5 @@ static int start_periodic_check_for_corruption(void) schedule_delayed_work(_check_work, 0); return 0; } - -module_init(start_periodic_check_for_corruption); +device_initcall(start_periodic_check_for_corruption); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm/pat: Make mm/pageattr[-test] .c explicitly non-modular
Commit-ID: 8f45fe441a9836011672436ef007654969b28ccc Gitweb: http://git.kernel.org/tip/8f45fe441a9836011672436ef007654969b28ccc Author: Paul Gortmaker AuthorDate: Mon, 24 Aug 2015 19:34:54 -0400 Committer: Ingo Molnar CommitDate: Tue, 25 Aug 2015 09:48:38 +0200 x86/mm/pat: Make mm/pageattr[-test].c explicitly non-modular The file pageattr.c is obj-y and it includes pageattr-test.c based on CPA_DEBUG (a bool), meaning that no code here is currently being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Signed-off-by: Paul Gortmaker Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1440459295-21814-3-git-send-email-paul.gortma...@windriver.com Signed-off-by: Ingo Molnar --- arch/x86/mm/pageattr-test.c | 4 ++-- arch/x86/mm/pageattr.c | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/pageattr-test.c b/arch/x86/mm/pageattr-test.c index 8ff686a..5f169d5 100644 --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include @@ -256,5 +257,4 @@ static int start_pageattr_test(void) return 0; } - -module_init(start_pageattr_test); +device_initcall(start_pageattr_test); diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 727158c..2c44c07 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -4,7 +4,6 @@ */ #include #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
* Alexander Shishkin wrote: > Hi Peter and Ingo and everybody, > > Here's an update of my extended error reporting patchset, addressing > review comments and adding a few more error messages to PT and BTS > drivers. > > Changes since v1: > * addressed Peter's comments, > * added perf_err() annotation to intel_pt and intel_bts drivers; > especially the former is rich in EINVALs in event validation path, > so it should be immediately useful; > * changed the error code to EINVAL for the case when perf_err() is > supplied a non-constart error code; > * dropped RFC, added sign-offs. > > This time around, I employed a linker trick to convert the structures > containing extended error information into integers, which are then > made to look just like normal error codes so that IS_ERR_VALUE() and > friends would still work correctly on them. So no extra pointers in > the struct perf_event or anywhere else; the extended error codes are > passed around like normal error codes. They only need to be converted > in syscalls' topmost return statements. This is done in 1/6. Nice trick! > Then, 2/6 illustrates how error sites can be extended to include more > information such as file names and line numbers [1]. Side note, it can > be dropped without impact on other patches. > > The other patches add perf_err() annotation to a few semi-randomly > picked places in perf core (3/6), x86 bits (4/6), intel_pt (5/6) and > intel_bts (6/6). > > [1] http://marc.info/?l=linux-kernel=141471816115946 > > Alexander Shishkin (6): > perf: Introduce extended syscall error reporting > perf: Add file name and line number to perf extended error reports > perf: Annotate some of the error codes with perf_err() > perf/x86: Annotate some of the error codes with perf_err() > perf/x86/intel/pt: Use extended error reporting in event > initialization > perf/x86/intel/bts: Use extended error reporting in event > initialization > > arch/x86/kernel/cpu/perf_event.c | 8 +- > arch/x86/kernel/cpu/perf_event_intel_bts.c | 4 +- > arch/x86/kernel/cpu/perf_event_intel_lbr.c | 2 +- > arch/x86/kernel/cpu/perf_event_intel_pt.c | 29 +--- > include/linux/perf_event.h | 82 + > include/uapi/linux/perf_event.h| 8 +- > kernel/events/core.c | 113 > + > 7 files changed, 215 insertions(+), 31 deletions(-) Ok, this looks pretty good to me. Mind adding support on the perf tooling side as well, so that it can be tested and applied in a single set of patches? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/platform] x86/platform: Make atom/ pmc_atom.c explicitly non-modular
Commit-ID: e971aa2cbac02363a29e9358de3b688001191ffd
Gitweb: http://git.kernel.org/tip/e971aa2cbac02363a29e9358de3b688001191ffd
Author: Paul Gortmaker
AuthorDate: Mon, 24 Aug 2015 19:34:53 -0400
Committer: Ingo Molnar
CommitDate: Tue, 25 Aug 2015 09:47:50 +0200
x86/platform: Make atom/pmc_atom.c explicitly non-modular
The Kconfig currently controlling compilation of this code is:
config PMC_ATOM
def_bool y
...meaning that it currently is not being built as a module by
anyone.
Lets remove the couple traces of modularity so that when reading
the driver there is no doubt it is builtin-only.
Since module_init() translates to device_initcall() in the
non-modular case, the init ordering remains unchanged with this
commit.
We leave some tags like MODULE_AUTHOR() for documentation
purposes.
Also note that MODULE_DEVICE_TABLE() is a no-op for non-modular
code. We correct a comment that indicates the data was only used
by that macro, as it actually is used by the code directly.
Signed-off-by: Paul Gortmaker
Cc: Andy Shevchenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1440459295-21814-2-git-send-email-paul.gortma...@windriver.com
Signed-off-by: Ingo Molnar
---
arch/x86/platform/atom/pmc_atom.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/platform/atom/pmc_atom.c
b/arch/x86/platform/atom/pmc_atom.c
index e814d34..964ff4f 100644
--- a/arch/x86/platform/atom/pmc_atom.c
+++ b/arch/x86/platform/atom/pmc_atom.c
@@ -15,7 +15,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
#include
#include
#include
@@ -422,10 +421,7 @@ static int pmc_setup_dev(struct pci_dev *pdev, const
struct pci_device_id *ent)
/*
* Data for PCI driver interface
*
- * This data only exists for exporting the supported
- * PCI ids via MODULE_DEVICE_TABLE. We do not actually
- * register a pci_driver, because lpc_ich will register
- * a driver on the same PCI id.
+ * used by pci_match_id() call below.
*/
static const struct pci_device_id pmc_pci_ids[] = {
{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_VLV_PMC),
(kernel_ulong_t)_reg_map },
@@ -433,8 +429,6 @@ static const struct pci_device_id pmc_pci_ids[] = {
{ 0, },
};
-MODULE_DEVICE_TABLE(pci, pmc_pci_ids);
-
static int __init pmc_atom_init(void)
{
struct pci_dev *pdev = NULL;
@@ -457,9 +451,10 @@ static int __init pmc_atom_init(void)
return -ENODEV;
}
-module_init(pmc_atom_init);
-/* no module_exit, this driver shouldn't be unloaded */
+device_initcall(pmc_atom_init);
+/*
MODULE_AUTHOR("Aubrey Li ");
MODULE_DESCRIPTION("Intel Atom SOC Power Management Controller Interface");
MODULE_LICENSE("GPL v2");
+*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [sched] 25834c73f9: WARNING: CPU: 0 PID: 13 at kernel/sched/core.c:1156 do_set_cpus_allowed+0x7e/0x80()
On 8/22/15 7:00 AM, kernel test robot wrote:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 25834c73f93af7f0712c98ca4593691592e6b360 ("sched: Fix a race between
__kthread_bind() and sched_setaffinity()")
https://lkml.org/lkml/2015/8/25/117
Hopes this patch can fix it.
Regards,
Wanpeng Li
+--+++
| | 7855a35ac0
| 25834c73f9 |
+--+++
| boot_successes | 10
| 0 |
| boot_failures| 1
| 11 |
| Out_of_memory:Kill_process | 1
| 11 |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 1
| 10 |
| backtrace:vfs_fstatat| 1
| 2 |
| backtrace:SyS_fstatat64 | 1
| 2 |
| WARNING:at_kernel/sched/core.c:#do_set_cpus_allowed()| 0
| 6 |
| backtrace:smpboot_thread_fn | 0
| 6 |
| backtrace:SYSC_socketcall| 0
| 4 |
| backtrace:SyS_socketcall | 0
| 4 |
| backtrace:tty_ldisc_setup| 0
| 1 |
| backtrace:tty_init_dev | 0
| 1 |
| backtrace:do_sys_open| 0
| 1 |
| backtrace:SyS_open | 0
| 1 |
+--+++
[ 15.273708] [ cut here ]
[ 15.274097] WARNING: CPU: 0 PID: 13 at kernel/sched/core.c:1156
do_set_cpus_allowed+0x7e/0x80()
[ 15.274857] Modules linked in:
[ 15.275101] CPU: 0 PID: 13 Comm: migration/0 Not tainted
4.2.0-rc1-00049-g25834c7 #2
[ 15.275674] d21f1d24 c19228b2 d21f1d58 c1056a3b
c1ba00e4
[ 15.276084] 000d c1ba17d8 0484 c10838be 0484 c10838be
d21e5000
[ 15.276084] d2121900 d21e5158 d21f1d68 c1056b12 0009 d21f1d7c
c10838be
[ 15.276084] Call Trace:
[ 15.276084] [] dump_stack+0x4b/0x75
[ 15.276084] [] warn_slowpath_common+0x8b/0xc0
[ 15.276084] [] ? do_set_cpus_allowed+0x7e/0x80
[ 15.276084] [] ? do_set_cpus_allowed+0x7e/0x80
[ 15.276084] [] warn_slowpath_null+0x22/0x30
[ 15.276084] [] do_set_cpus_allowed+0x7e/0x80
[ 15.276084] [] cpuset_cpus_allowed_fallback+0x7c/0x170
[ 15.276084] [] ? cpuset_cpus_allowed+0x180/0x180
[ 15.276084] [] select_fallback_rq+0x221/0x280
[ 15.276084] [] migration_call+0xe3/0x250
[ 15.276084] [] notifier_call_chain+0x53/0x70
[ 15.276084] [] __raw_notifier_call_chain+0x1e/0x30
[ 15.276084] [] cpu_notify+0x28/0x50
[ 15.276084] [] take_cpu_down+0x22/0x40
[ 15.276084] [] multi_cpu_stop+0xd5/0x140
[ 15.276084] [] ? __stop_cpus+0x80/0x80
[ 15.276084] [] cpu_stopper_thread+0xbc/0x170
[ 15.276084] [] ? preempt_count_sub+0x9/0x50
[ 15.276084] [] ? _raw_spin_unlock_irq+0x37/0x50
[ 15.276084] [] ? _raw_spin_unlock_irqrestore+0x55/0x70
[ 15.276084] [] ? trace_hardirqs_on_caller+0x144/0x1e0
[ 15.276084] [] ? cpu_stop_should_run+0x35/0x40
[ 15.276084] [] ? preempt_count_sub+0x9/0x50
[ 15.276084] [] ? _raw_spin_unlock_irqrestore+0x41/0x70
[ 15.276084] [] smpboot_thread_fn+0x174/0x2f0
[ 15.276084] [] ? sort_range+0x30/0x30
[ 15.276084] [] kthread+0xc4/0xe0
[ 15.276084] [] ret_from_kernel_thread+0x21/0x30
[ 15.276084] [] ? kthread_create_on_node+0x180/0x180
[ 15.276084] ---[ end trace 15f4c86d404693b0 ]---
Thanks,
Ying Huang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal for finishing the 64-bit x86 syscall cleanup
* Andy Lutomirski wrote: > Hi all- > > I want to (try to) mostly or fully get rid of the messy bits (as > opposed to the hardware-bs-forced bits) of the 64-bit syscall asm. > There are two major conceptual things that are in the way. > > Thing 1: partial pt_regs > > 64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and > r12-r15 are uninitialized. Some syscalls require them to be > initialized, and they have special awful stubs to do it. The entry > and exit tracing code (except for phase1 tracing) also need them > initialized, and they have their own messy initialization. Compat > syscalls are their own private little mess here. > > This gets in the way of all kinds of cleanups, because C code can't > switch between the full and partial pt_regs states. > > I can see two ways out. We could remove the optimization entirely, > which consists of pushing and popping six more registers and adds > about ten cycles to fast path syscalls on Sandy Bridge. It also > simplifies and presumably speeds up the slow paths. So out of hundreds of regular system calls there's only a handful of such system calls: triton:~/tip> git grep stub arch/x86/entry/syscalls/ arch/x86/entry/syscalls/syscall_32.tbl:2i386fork sys_forkstub32_fork arch/x86/entry/syscalls/syscall_32.tbl:11 i386execve sys_execve stub32_execve arch/x86/entry/syscalls/syscall_32.tbl:119 i386sigreturn sys_sigreturn stub32_sigreturn arch/x86/entry/syscalls/syscall_32.tbl:120 i386clone sys_clone stub32_clone arch/x86/entry/syscalls/syscall_32.tbl:173 i386rt_sigreturn sys_rt_sigreturnstub32_rt_sigreturn arch/x86/entry/syscalls/syscall_32.tbl:190 i386vfork sys_vfork stub32_vfork arch/x86/entry/syscalls/syscall_32.tbl:358 i386execveat sys_execveatstub32_execveat arch/x86/entry/syscalls/syscall_64.tbl:15 64 rt_sigreturn stub_rt_sigreturn arch/x86/entry/syscalls/syscall_64.tbl:56 common clone stub_clone arch/x86/entry/syscalls/syscall_64.tbl:57 common fork stub_fork arch/x86/entry/syscalls/syscall_64.tbl:58 common vfork stub_vfork arch/x86/entry/syscalls/syscall_64.tbl:59 64 execve stub_execve arch/x86/entry/syscalls/syscall_64.tbl:322 64 execveat stub_execveat arch/x86/entry/syscalls/syscall_64.tbl:513 x32 rt_sigreturn stub_x32_rt_sigreturn arch/x86/entry/syscalls/syscall_64.tbl:520 x32 execve stub_x32_execve arch/x86/entry/syscalls/syscall_64.tbl:545 x32 execveat stub_x32_execveat and none of them are super performance critical system calls, so no way would I go for unconditionally saving/restoring all of ptregs, just to make it a bit simpler for these syscalls. > We could also annotate with syscalls need full regs and jump to the > slow path for them. This would leave the fast path unchanged (we > could duplicate the sys call table so that regs-requiring syscalls > would turn into some asm that switches to the slow path). We'd make > the syscall table say something like: > > 59 64 execve sys_execve:regs > > The fast path would have exactly identical performance and the slow > path would presumably speed up. The down side would be additional > complexity. The 'fast path performance unchanged' aspect definitely gives me warm fuzzy feelings. Your suggested annotation would essentially be a syntactical cleanup, in that we'd auto-generate the stubs during build, instead of the current ugly open coded stubs? Or did you have something else in mind? > Thing 2: vdso compilation with binutils that doesn't support .cfi directives > > Userspace debuggers really like having the vdso properly > CFI-annotated, and the 32-bit fast syscall entries are annotatied > manually in hexidecimal. AFAIK Jan Beulich is the only person who > understands it. > > I want to be able to change the entries a little bit to clean them up > (and possibly rework the SYSCALL32 and SYSENTER register tricks, which > currently suck), but it's really, really messy right now because of > the hex CFI stuff. Could we just drop the CFI annotations if the > binutils version is too old or even just require new enough binutils > to build 32-bit and compat kernels? We could also test for those directives and not generate debuginfo on such tooling. Not generating debuginfo is still much better than failing the build. I'm all for removing the hexa encoded debuginfo. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a
Re: [PATCH v3 3/10] x86/asm: Fix pud/pmd interfaces to handle large PAT bit
On Wed, 5 Aug 2015, Toshi Kani wrote: > The PAT bit gets relocated to bit 12 when PUD and PMD mappings are > used. This bit 12, however, is not covered by PTE_FLAGS_MASK, which > is corrently used for masking pfn and flags for all cases. > > Fix pud/pmd interfaces to handle pfn and flags properly by using > P?D_PAGE_MASK when PUD/PMD mappings are used, i.e. PSE bit is set. Can you please split that into a patch introducing and describing the new mask helper functions and a second one making use of it? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma/ipu: change ipu_irq_handler() to remove compile warning
> On Aug 25, 2015, at 16:07, Thomas Gleixner wrote:
>
> On Tue, 25 Aug 2015, yalin wang wrote:
>> Change ipu_irq_handler() to avoid gcc warning:
>>
>> drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>generic_handle_irq(irq);
>
> That's a false positive from GCC. irq is always initialized when
> generic_handle_irq() is called.
>
>> Signed-off-by: yalin wang
>> ---
>> drivers/dma/ipu/ipu_irq.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
>> index 7489d2a..1a74eee 100644
>> --- a/drivers/dma/ipu/ipu_irq.c
>> +++ b/drivers/dma/ipu/ipu_irq.c
>> @@ -286,23 +286,21 @@ static void ipu_irq_handler(unsigned int __irq, struct
>> irq_desc *desc)
>> raw_spin_unlock(_lock);
>> while ((line = ffs(status))) {
>> struct ipu_irq_map *map;
>> -unsigned int irq;
>>
>> line--;
>> status &= ~(1UL << line);
>>
>> raw_spin_lock(_lock);
>> map = src2map(32 * i + line);
>> -if (map)
>> -irq = map->irq;
>> raw_spin_unlock(_lock);
>>
>> if (!map) {
>> pr_err("IPU: Interrupt on unmapped source %u
>> bank %d\n",
>> line, i);
>> continue;
>> +} else {
>> +generic_handle_irq(map->irq);
>
> So you change that from retrieving the irq number with bank lock held
> to an unprotected access.
i see,
i will send a V2 patch .
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] dma/ipu: change ipu_irq_handler() to remove compile warning
Change ipu_irq_handler() to avoid gcc warning:
drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used
uninitialized in this function [-Wmaybe-uninitialized]
generic_handle_irq(irq);
Signed-off-by: yalin wang
---
drivers/dma/ipu/ipu_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index 7489d2a..4768a82 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -286,7 +286,7 @@ static void ipu_irq_handler(unsigned int __irq, struct
irq_desc *desc)
raw_spin_unlock(_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
- unsigned int irq;
+ unsigned int irq = NO_IRQ;
line--;
status &= ~(1UL << line);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed()
Hi Wanpeng,
On Tue, Aug 25, 2015 at 03:59:54PM +0800, Wanpeng Li wrote:
> [ 15.273708] [ cut here ]
> [ 15.274097] WARNING: CPU: 0 PID: 13 at kernel/sched/core.c:1156
> do_set_cpus_allowed+0x7e/0x80()
> [ 15.274857] Modules linked in:
> [ 15.275101] CPU: 0 PID: 13 Comm: migration/0 Not tainted
> 4.2.0-rc1-00049-g25834c7 #2
> [ 15.275674] d21f1d24 c19228b2 d21f1d58
> c1056a3b c1ba00e4
> [ 15.276084] 000d c1ba17d8 0484 c10838be 0484
> c10838be d21e5000
> [ 15.276084] d2121900 d21e5158 d21f1d68 c1056b12 0009
> d21f1d7c c10838be
> [ 15.276084] Call Trace:
> [ 15.276084] [] dump_stack+0x4b/0x75
> [ 15.276084] [] warn_slowpath_common+0x8b/0xc0
> [ 15.276084] [] ? do_set_cpus_allowed+0x7e/0x80
> [ 15.276084] [] ? do_set_cpus_allowed+0x7e/0x80
> [ 15.276084] [] warn_slowpath_null+0x22/0x30
> [ 15.276084] [] do_set_cpus_allowed+0x7e/0x80
> [ 15.276084] [] cpuset_cpus_allowed_fallback+0x7c/0x170
> [ 15.276084] [] ? cpuset_cpus_allowed+0x180/0x180
> [ 15.276084] [] select_fallback_rq+0x221/0x280
> [ 15.276084] [] migration_call+0xe3/0x250
> [ 15.276084] [] notifier_call_chain+0x53/0x70
> [ 15.276084] [] __raw_notifier_call_chain+0x1e/0x30
> [ 15.276084] [] cpu_notify+0x28/0x50
> [ 15.276084] [] take_cpu_down+0x22/0x40
> [ 15.276084] [] multi_cpu_stop+0xd5/0x140
> [ 15.276084] [] ? __stop_cpus+0x80/0x80
> [ 15.276084] [] cpu_stopper_thread+0xbc/0x170
> [ 15.276084] [] ? preempt_count_sub+0x9/0x50
> [ 15.276084] [] ? _raw_spin_unlock_irq+0x37/0x50
> [ 15.276084] [] ? _raw_spin_unlock_irqrestore+0x55/0x70
> [ 15.276084] [] ? trace_hardirqs_on_caller+0x144/0x1e0
> [ 15.276084] [] ? cpu_stop_should_run+0x35/0x40
> [ 15.276084] [] ? preempt_count_sub+0x9/0x50
> [ 15.276084] [] ? _raw_spin_unlock_irqrestore+0x41/0x70
> [ 15.276084] [] smpboot_thread_fn+0x174/0x2f0
> [ 15.276084] [] ? sort_range+0x30/0x30
> [ 15.276084] [] kthread+0xc4/0xe0
> [ 15.276084] [] ret_from_kernel_thread+0x21/0x30
> [ 15.276084] [] ? kthread_create_on_node+0x180/0x180
> [ 15.276084] ---[ end trace 15f4c86d404693b0 ]---
>
> After commit (25834c73f93: sched: Fix a race between __kthread_bind()
> and sched_setaffinity()) do_set_cpus_allowed() should be called w/
> p->pi_lock held, however, it is not true in cpuset path currently.
>
> This patch fix it by holding p->pi_lock in cpuset path.
>
> Signed-off-by: Wanpeng Li
> ---
> kernel/cpuset.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index e414ae9..605ed66 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -2376,8 +2376,12 @@ void cpuset_cpus_allowed(struct task_struct *tsk,
> struct cpumask *pmask)
>
> void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
> {
> + unsigned long flags;
> +
> rcu_read_lock();
> + raw_spin_lock_irqsave(>pi_lock, flags);
> do_set_cpus_allowed(tsk, task_cs(tsk)->effective_cpus);
> + raw_spin_lock_irqsave(>pi_lock, flags);
Just curious, Will introduce deadlock after acquire lock twice? ;)
Thanks,
Leo Yan
> rcu_read_unlock();
>
> /*
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 12:49 +0100, Leif Lindholm wrote: > On Mon, Aug 24, 2015 at 06:19:56PM +0800, Haojian Zhuang wrote: > > > If your EFI memory map describes the memory as mappable, it is wrong. > > > > When kernel is working, kernel will create its own page table based on > > UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll > > be moved to reserved memblock. Why is it wrong? > > > > In the second, UEFI is firmware. When it's stable, nobody should change > > it without any reason. > > Much like the memory map. > > > These reserved memory are used in mailbox driver. > > Look. It's driver, so it could be changed at any time. > > No, it is a set of regions of memory set aside for use by a different > master in the system as well as communications with that master. > > The fact that there is a driver somewhere that is aware of this is > entirely beside the point. All agents in the system must adher to this > protocol. > > > Why do you want > > to UEFI knowing this memory range? Do you hope UEFI to change when > > mailbox driver is changed? > > Yes. > > UEFI is a runtime environment. Having random magic areas not to be > touched will cause random pieces of software running under it to break > horribly or break other things horribly. > Unless you mark them as reserved in the UEFI memory map. > At which point the Linux kernel will automatically ignore them, and > the proposed patch is redundant. > > So, yes, if you want a system that can boot reliably, run testsuites > (like SCT or FWTS), run applications (like fastboot ... or the EFI > stub kernel itself), then any memory regions that is reserved for > mailbox communication (or other masters in the system) _must_ be > marked in the EFI memory map. 1. We need support both UEFI and uboot. So the reserved buffer have to be declared in DTB since they are used by kernel driver, not UEFI. 2. UEFI just loads grub. It's no time to run any other custom EFI application. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT pull] x86 fix for 4.2
Linus,
please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
A single fix for a APIC regression introduced in 4.0 which went
undetected until now. I screwed up the x2apic cleanup in a subtle
way. The screwup is only visible on systems which have x2apic
preenabled in the BIOS and need to disable it during boot.
Thanks,
tglx
-->
Thomas Gleixner (1):
x86/apic: Fix fallout from x2apic cleanup
arch/x86/kernel/apic/apic.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index dcb52850a28f..cde732c1b495 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1424,7 +1424,7 @@ static inline void __x2apic_disable(void)
{
u64 msr;
- if (cpu_has_apic)
+ if (!cpu_has_apic)
return;
rdmsrl(MSR_IA32_APICBASE, msr);
@@ -1483,10 +1483,13 @@ void x2apic_setup(void)
static __init void x2apic_disable(void)
{
- u32 x2apic_id;
+ u32 x2apic_id, state = x2apic_state;
- if (x2apic_state != X2APIC_ON)
- goto out;
+ x2apic_mode = 0;
+ x2apic_state = X2APIC_DISABLED;
+
+ if (state != X2APIC_ON)
+ return;
x2apic_id = read_apic_id();
if (x2apic_id >= 255)
@@ -1494,9 +1497,6 @@ static __init void x2apic_disable(void)
__x2apic_disable();
register_lapic_address(mp_lapic_addr);
-out:
- x2apic_state = X2APIC_DISABLED;
- x2apic_mode = 0;
}
static __init void x2apic_enable(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/2] mfd: update Intel soc PMIC header file to support Broxton WC PMIC
IRQ control registers of Intel Broxton Whisky Cove PMIC are
separated in two parts, so add secondary IRQ chip.
And the new member of device will be used in PMC IPC regmap APIs.
Signed-off-by: Qipeng Zha
---
include/linux/mfd/intel_soc_pmic.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/mfd/intel_soc_pmic.h
b/include/linux/mfd/intel_soc_pmic.h
index abcbfcf..a730f14 100644
--- a/include/linux/mfd/intel_soc_pmic.h
+++ b/include/linux/mfd/intel_soc_pmic.h
@@ -21,10 +21,15 @@
#include
+#define INIT_REGMAP_IRQ(_irq, _off, _mask) \
+ [_irq] = { .reg_offset = (_off), .mask = (_mask) }
+
struct intel_soc_pmic {
int irq;
struct regmap *regmap;
struct regmap_irq_chip_data *irq_chip_data;
+ struct regmap_irq_chip_data *irq_chip_data_level2;
+ struct device *dev;
};
#endif /* __INTEL_SOC_PMIC_H__ */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC
On Mon, Aug 24, 2015 at 03:49:28PM -0700, Stephen Boyd wrote:
> On 08/24, Varadarajan Narayanan wrote:
> > Add initial dts files and SoC support for IPQ40XX
> >
>
> So far we haven't added any Xs in the model names for our SoC
> support. Even for IPQ806X, we have it as IPQ8064 as the config
> name with IPQ806x in the help text because there's IPQ8062 out
> there. So I guess it should be IPQ4019 or something?
Will rename it as IPQ4019
> > Signed-off-by: Varadarajan Narayanan
> > ---
> > diff --git a/Documentation/devicetree/bindings/qcom.txt
> > b/Documentation/devicetree/bindings/qcom.txt
> > new file mode 100644
> > index 000..7d56bd0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/qcom.txt
> > @@ -0,0 +1,16 @@
> > +Qualcomm IPQ device tree bindings
> > +-
> > +
> > +System on Chip
> > +
> > +Device tree must specify which SoC it uses, with one of the
> > +following compatible strings
> > +
> > + "qcom,ipq40xx"
> > +
> > +Platform
> > +
> > +Device tree must specify which Platform it uses, with one of the
> > +following compatible strings
> > +
> > + "qcom,ipq40xx-r3pc"
>
> This file is not complete and I don't see any other silicon
> vendors doing this, so please drop the entire file.
Ok.
> > diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> > b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> > new file mode 100644
> > index 000..7e4e629
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> > @@ -0,0 +1,33 @@
> > +/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include "qcom-ipq40xx.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. IPQ40XX R3PC";
>
> Same here, we should know what model number is on the board.
Ok.
> > + compatible = "qcom,ipq40xx-r3pc", "qcom,ipq40xx";
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <0x8000 0x2000>; /* 512MB */
> > + };
>
> Doesn't the bootloader fill the memory node for us? Why do we
> need this?
>
> > +
> > + chosen {
> > + bootargs = "root=/dev/ram rw init=/init
> > console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246";
> > + };
>
> Please don't add bootargs. Use stdout-path for the console part
> and everything else should be done by the bootloader or is the
> defaults.
Since this is for the emulation platform, we don't have the bootloader.
> > +
> > + soc {
> > + serial@78b {
> > + status = "ok";
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/qcom-ipq40xx.dtsi
> > b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
> > new file mode 100644
> > index 000..f572f38
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
> > @@ -0,0 +1,81 @@
> > +/*
> > + * Copyright (c) 2014, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "skeleton.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. IPQ40XX";
> > + compatible = "qcom,ipq40xx";
>
> These two should also be specific and drop the Xs. Same goes for
> the file name.
Ok.
> > + interrupt-parent = <>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a7";
> > + reg = <0x0>;
> > + };
> > +
> > + cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a7";
> > + reg = <0x1>;
> > + };
> > +
> > + cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a7";
> > + reg = <0x2>;
> > + };
> > +
> > + cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a7";
> > + reg = <0x3>;
> > +
