* [PATCH 03/16] ARM: b.L: introduce helpers for platform coherency exit/setup
From: Catalin Marinas @ 2013-01-14 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114181006.GB1967@linaro.org>
On Mon, Jan 14, 2013 at 06:10:06PM +0000, Dave Martin wrote:
> On Mon, Jan 14, 2013 at 05:15:28PM +0000, Catalin Marinas wrote:
> > On Mon, Jan 14, 2013 at 05:08:51PM +0000, Dave Martin wrote:
> > > From b64f305c90e7ea585992df2d710f62ec6a7b5395 Mon Sep 17 00:00:00 2001
> > > From: Dave Martin <dave.martin@linaro.org>
> > > Date: Mon, 14 Jan 2013 16:25:47 +0000
> > > Subject: [PATCH] ARM: b.L: Fix outer cache handling for coherency setup/exit helpers
> > >
> > > This patch addresses the following issues:
> > >
> > > * When invalidating stale data from the cache before a read,
> > > outer caches must be invalidated _before_ inner caches, not
> > > after, otherwise stale data may be re-filled from outer to
> > > inner after the inner cache is flushed.
> > >
> > > We still retain an inner clean before touching the outer cache,
> > > to avoid stale data being rewritten from there into the outer
> > > cache after the outer cache is flushed.
> > >
> > > * All the sync_mem() calls synchronise either reads or writes,
> > > but not both. This patch splits sync_mem() into separate
> > > functions for reads and writes, to avoid excessive inner
> > > flushes in the write case.
> > >
> > > The two functions are different from the original sync_mem(),
> > > to fix the above issues.
> > >
> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > ---
> > > NOTE: This patch is build-tested only.
> > >
> > > arch/arm/common/bL_entry.c | 57 ++++++++++++++++++++++++++++++++++----------
> > > 1 files changed, 44 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/arch/arm/common/bL_entry.c b/arch/arm/common/bL_entry.c
> > > index 1ea4ec9..3e1a404 100644
> > > --- a/arch/arm/common/bL_entry.c
> > > +++ b/arch/arm/common/bL_entry.c
> > > @@ -119,16 +119,47 @@ int bL_cpu_powered_up(void)
> > >
> > > struct bL_sync_struct bL_sync;
> > >
> > > -static void __sync_range(volatile void *p, size_t size)
> > > +/*
> > > + * Ensure preceding writes to *p by this CPU are visible to
> > > + * subsequent reads by other CPUs:
> > > + */
> > > +static void __sync_range_w(volatile void *p, size_t size)
> > > {
> > > char *_p = (char *)p;
> > >
> > > __cpuc_flush_dcache_area(_p, size);
> > > - outer_flush_range(__pa(_p), __pa(_p + size));
> > > + outer_clean_range(__pa(_p), __pa(_p + size));
> > > outer_sync();
> >
> > It's not part of your patch but I thought about commenting here. The
> > outer_clean_range() already has a cache_sync() operation, so no need for
> > the additional outer_sync().
> >
> > > }
> > >
> > > -#define sync_mem(ptr) __sync_range(ptr, sizeof *(ptr))
> > > +/*
> > > + * Ensure preceding writes to *p by other CPUs are visible to
> > > + * subsequent reads by this CPU:
> > > + */
> > > +static void __sync_range_r(volatile void *p, size_t size)
> > > +{
> > > + char *_p = (char *)p;
> > > +
> > > +#ifdef CONFIG_OUTER_CACHE
> > > + if (outer_cache.flush_range) {
> > > + /*
> > > + * Ensure ditry data migrated from other CPUs into our cache
> > > + * are cleaned out safely before the outer cache is cleaned:
> > > + */
> > > + __cpuc_flush_dcache_area(_p, size);
> > > +
> > > + /* Clean and invalidate stale data for *p from outer ... */
> > > + outer_flush_range(__pa(_p), __pa(_p + size));
> > > + outer_sync();
> >
> > Same here.
>
> Ah, right. I've seen code do this in various places, and just copy-
> pasted it under the assumption that it is needed. Our discussion abouto
> ensuring that outer_sync() really does guarantee completion of its
> effects on return still applies.
>
> Are there any situations when outer_sync() should be called explicitly?
outer_sync() on its own ensures the draining of the PL310 write buffer.
DSB drains the CPU write buffers but PL310 doesn't detect it, so a
separate outer_sync() is needed. In general this is required when you
write a Normal Non-cacheable buffer (but bufferable, e.g. DMA coherent)
and you want to ensure data visibility (DSB+outer_sync(), that's what
the mb() macro does).
--
Catalin
^ permalink raw reply
* [kvmarm] [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code
From: Alexander Graf @ 2013-01-14 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98q+y4GoHmqh-CS+fDnfbDbBQHQOY05urer5DMgy9b1X5ng@mail.gmail.com>
Am 14.01.2013 um 22:08 schrieb Christoffer Dall <c.dall@virtualopensystems.com>:
> On Mon, Jan 14, 2013 at 10:31 AM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, Jan 08, 2013 at 06:41:51PM +0000, Christoffer Dall wrote:
>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> Wire the basic framework code for VGIC support and the initial in-kernel
>>> MMIO support code for the VGIC, used for the distributor emulation.
>>
>> [...]
>>
>>> +/**
>>> + * vgic_reg_access - access vgic register
>>> + * @mmio: pointer to the data describing the mmio access
>>> + * @reg: pointer to the virtual backing of vgic distributor data
>>> + * @offset: least significant 2 bits used for word offset
>>> + * @mode: ACCESS_ mode (see defines above)
>>> + *
>>> + * Helper to make vgic register access easier using one of the access
>>> + * modes defined for vgic register access
>>> + * (read,raz,write-ignored,setbit,clearbit,write)
>>> + */
>>> +static void vgic_reg_access(struct kvm_exit_mmio *mmio, u32 *reg,
>>> + phys_addr_t offset, int mode)
>>> +{
>>> + int shift = (offset & 3) * 8;
>>> + u32 mask;
>>> + u32 regval;
>>> +
>>> + /*
>>> + * Any alignment fault should have been delivered to the guest
>>> + * directly (ARM ARM B3.12.7 "Prioritization of aborts").
>>> + */
>>> +
>>> + mask = (~0U) >> shift;
>>> + if (reg) {
>>> + regval = *reg;
>>> + } else {
>>> + BUG_ON(mode != (ACCESS_READ_RAZ | ACCESS_WRITE_IGNORED));
>>> + regval = 0;
>>> + }
>>> +
>>> + if (mmio->is_write) {
>>> + u32 data = (*((u32 *)mmio->data) & mask) << shift;
>>> + switch (ACCESS_WRITE_MASK(mode)) {
>>> + case ACCESS_WRITE_IGNORED:
>>> + return;
>>> +
>>> + case ACCESS_WRITE_SETBIT:
>>> + regval |= data;
>>> + break;
>>> +
>>> + case ACCESS_WRITE_CLEARBIT:
>>> + regval &= ~data;
>>> + break;
>>> +
>>> + case ACCESS_WRITE_VALUE:
>>> + regval = (regval & ~(mask << shift)) | data;
>>> + break;
>>> + }
>>> + *reg = regval;
>>> + } else {
>>> + switch (ACCESS_READ_MASK(mode)) {
>>> + case ACCESS_READ_RAZ:
>>> + regval = 0;
>>> + /* fall through */
>>> +
>>> + case ACCESS_READ_VALUE:
>>> + *((u32 *)mmio->data) = (regval >> shift) & mask;
>>> + }
>>> + }
>>> +}
>>
>> As I mentioned previously, I suspect that this doesn't work with big-endian
>> systems. Whilst that's reasonable for the moment, a comment would be useful
>> for the unlucky soul that decides to do that work in future (or add
>> accessors for mmio->data as I suggested before).
>>
> admittedly this really hurts my brain, but I think there's actually no
> problem with endianness: whatever comes in mmio->data will have native
> endianness
IIRC we have a local endianness flag on ppc. Once you introduce big endian guests, you can just add one too and add a CAP for it. I wouldn't worry about it now though.
Alex
> and the vgic is always little-endian, so a guest would have
> to make sure to do its own endianness conversion before writing data,
> or did I get this backwards? (some nasty feeling about if the OS is
> compiled in another endianness than the hardware everything may
> break).
>
> Anyhow, I think there's another bug in this code though. Please take a
> look and see if you agree:
>
> commit 3cab2b93a6f6acd3c043e584f23b94ab8f1bbd66
> Author: Christoffer Dall <c.dall@virtualopensystems.com>
> Date: Mon Jan 14 15:55:18 2013 -0500
>
> KVM: ARM: Limit vgic read/writes to load/store length
>
> The vgic read/write operations did not consider ldrb/strb masks, and
> would therefore unintentionally overwrite parts of a register.
>
> Consider for example a store of a single byte to a word-aligned address
> of one of the priority registers, that would cause the 3 most
> significant bytes to be overwritten with zeros.
>
> Cc: Marc Zyniger <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>
> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
> index 25daa07..5c1bcf5 100644
> --- a/arch/arm/kvm/vgic.c
> +++ b/arch/arm/kvm/vgic.c
> @@ -233,6 +233,16 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
> *vcpu, int irq)
> vcpu->arch.vgic_cpu.pending_shared);
> }
>
> +static u32 mmio_data_read(struct kvm_exit_mmio *mmio, u32 mask)
> +{
> + return *((u32 *)mmio->data) & mask;
> +}
> +
> +static void mmio_data_write(struct kvm_exit_mmio *mmio, u32 mask, u32 value)
> +{
> + *((u32 *)mmio->data) = value & mask;
> +}
> +
> /**
> * vgic_reg_access - access vgic register
> * @mmio: pointer to the data describing the mmio access
> @@ -247,8 +257,8 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
> *vcpu, int irq)
> static void vgic_reg_access(struct kvm_exit_mmio *mmio, u32 *reg,
> phys_addr_t offset, int mode)
> {
> - int shift = (offset & 3) * 8;
> - u32 mask;
> + int word_offset = (offset & 3) * 8;
> + u32 mask = (1UL << (mmio->len * 8)) - 1;
> u32 regval;
>
> /*
> @@ -256,7 +266,6 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> * directly (ARM ARM B3.12.7 "Prioritization of aborts").
> */
>
> - mask = (~0U) >> shift;
> if (reg) {
> regval = *reg;
> } else {
> @@ -265,7 +274,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> }
>
> if (mmio->is_write) {
> - u32 data = (*((u32 *)mmio->data) & mask) << shift;
> + u32 data = mmio_data_read(mmio, mask) << word_offset;
> switch (ACCESS_WRITE_MASK(mode)) {
> case ACCESS_WRITE_IGNORED:
> return;
> @@ -279,7 +288,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> break;
>
> case ACCESS_WRITE_VALUE:
> - regval = (regval & ~(mask << shift)) | data;
> + regval = (regval & ~(mask << word_offset)) | data;
> break;
> }
> *reg = regval;
> @@ -290,7 +299,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> /* fall through */
>
> case ACCESS_READ_VALUE:
> - *((u32 *)mmio->data) = (regval >> shift) & mask;
> + mmio_data_write(mmio, mask, regval >> word_offset);
> }
> }
> }
> @@ -702,6 +711,12 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> (mmio->phys_addr + mmio->len) > (base + KVM_VGIC_V2_DIST_SIZE))
> return false;
>
> + /* We don't support ldrd / strd or ldm / stm to the emulated vgic */
> + if (mmio->len > 4) {
> + kvm_inject_dabt(vcpu, mmio->phys_addr);
> + return true;
> + }
> +
> range = find_matching_range(vgic_ranges, mmio, base);
> if (unlikely(!range || !range->handle_mmio)) {
> pr_warn("Unhandled access %d %08llx %d\n",
> --
>
> Thanks,
> -Christoffer
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
^ permalink raw reply
* [PATCH] arm: mach-zynq/timer.c: fix memory leakage
From: Cong Ding @ 2013-01-14 21:18 UTC (permalink / raw)
To: linux-arm-kernel
the variable ttccs allocated isn't freed when error occurs, so we call kfree
before return.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
---
arch/arm/mach-zynq/timer.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-zynq/timer.c b/arch/arm/mach-zynq/timer.c
index f9fbc9c..df04761 100644
--- a/arch/arm/mach-zynq/timer.c
+++ b/arch/arm/mach-zynq/timer.c
@@ -203,15 +203,15 @@ static void __init zynq_ttc_setup_clocksource(struct device_node *np,
err = of_property_read_u32(np, "reg", ®);
if (WARN_ON(err))
- return;
+ goto out;
clk = of_clk_get_by_name(np, "cpu_1x");
if (WARN_ON(IS_ERR(clk)))
- return;
+ goto out;
err = clk_prepare_enable(clk);
if (WARN_ON(err))
- return;
+ goto out;
ttccs->xttc.base_addr = base + reg * 4;
@@ -229,7 +229,10 @@ static void __init zynq_ttc_setup_clocksource(struct device_node *np,
err = clocksource_register_hz(&ttccs->cs, clk_get_rate(clk) / PRESCALE);
if (WARN_ON(err))
- return;
+ goto out;
+ return;
+out:
+ kfree(ttccs);
}
static void __init zynq_ttc_setup_clockevent(struct device_node *np,
@@ -245,21 +248,21 @@ static void __init zynq_ttc_setup_clockevent(struct device_node *np,
err = of_property_read_u32(np, "reg", ®);
if (WARN_ON(err))
- return;
+ goto out;
ttcce->xttc.base_addr = base + reg * 4;
ttcce->clk = of_clk_get_by_name(np, "cpu_1x");
if (WARN_ON(IS_ERR(ttcce->clk)))
- return;
+ goto out;
err = clk_prepare_enable(ttcce->clk);
if (WARN_ON(err))
- return;
+ goto out;
irq = irq_of_parse_and_map(np, 0);
if (WARN_ON(!irq))
- return;
+ goto out;
ttcce->ce.name = np->name;
ttcce->ce.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
@@ -277,11 +280,15 @@ static void __init zynq_ttc_setup_clockevent(struct device_node *np,
err = request_irq(irq, xttcps_clock_event_interrupt, IRQF_TIMER,
np->name, ttcce);
if (WARN_ON(err))
- return;
+ goto out;
clockevents_config_and_register(&ttcce->ce,
clk_get_rate(ttcce->clk) / PRESCALE,
1, 0xfffe);
+ return;
+
+out:
+ kfree(ttcce);
}
static const __initconst struct of_device_id zynq_ttc_match[] = {
--
1.7.9.5
^ permalink raw reply related
* OMAP baseline test results for v3.8-rc3
From: Felipe Balbi @ 2013-01-14 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114204654.GB18224@blackmetal.musicnaut.iki.fi>
Hi,
On Mon, Jan 14, 2013 at 10:46:54PM +0200, Aaro Koskinen wrote:
> On Mon, Jan 14, 2013 at 09:14:59PM +0200, Felipe Balbi wrote:
> > On Mon, Jan 14, 2013 at 08:40:18PM +0200, Aaro Koskinen wrote:
> > > On Mon, Jan 14, 2013 at 05:59:12PM +0000, Paul Walmsley wrote:
> > > > Here are some basic OMAP test results for Linux v3.8-rc3.
> > > > Logs and other details at:
> > > >
> > > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc3/20130109222058/
> > > >
> > > >
> > > > Test summary
> > > > ------------
> > > >
> > > > Boot to userspace:
> > > > Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
> > > > 3730beaglexm, 37xxevm, 4430es2panda, 5912osk,
> > > > 4460pandaes
> > > > FAIL ( 2/11): am335xbone, cmt3517
> > >
> > > N900 boot is unstable again, I2C issues are back.
> >
> > damn!
> >
> > > Boot succeeds and fails randomly. Let's see if this can be bisected.
> > > The same kernel works on N950.
> >
> > fair enough, it might be something related to some errata fix which
> > might have been missed. Can you apply this small patch just so I know if
> > there is something pending in CNT reg ?
>
> [ 0.207946] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
> [ 0.208129] twl 1-0048: power (irq 343) chaining IRQs 346..353
> [ 0.209350] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
> [ 1.218749] omap_i2c omap_i2c.1: timeout waiting for bus ready
> [ 1.218811] omap_i2c omap_i2c.1: SA 0049 CON 9602 CNT 0004
here's the issue, there is unloaded data in the FIFO. Can you enable
full I2C debugging logs ?
> > you might also want to try merging my latest i2c patches, which missed
> > the merge window, as they might help with this issue too.
> >
> > The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
> >
> > Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c-deferred-STP
>
> I could not reproduce the issue with these. Tested around 20 boots.
> There's a noticeable delay (over 4 secs!) around where I2C is initialized
> and used for the first time, but no errors and the boot completes:
>
> [ 0.187530] SCSI subsystem initialized
> [ 0.188110] usbcore: registered new interface driver usbfs
> [ 0.188415] usbcore: registered new interface driver hub
> [ 0.188781] usbcore: registered new device driver usb
> [ 0.189453] musb-omap2430 musb-omap2430: invalid resource
> [ 4.296905] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
> [ 4.297088] twl 1-0048: power (irq 343) chaining IRQs 346..353
> [ 4.329010] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
> [ 4.470123] VUSB1V5: 1500 mV normal standby
> [ 4.470916] VUSB1V8: 1800 mV normal standby
cool, at least it works, but looks like there is something still weird
going on. Can you enable full logs so I see what's happening ?
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/3adc8864/attachment.sig>
^ permalink raw reply
* [GIT PULL] DeviceTree fixes for 3.8
From: Rob Herring @ 2013-01-14 21:17 UTC (permalink / raw)
To: linux-arm-kernel
Linus,
Please pull these 2 small fixes for DT. The move to common dtb build rules
went in through the DT tree, so I'm taking the fixes too.
Rob
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git tags/dt-fixes-for-3.8
for you to fetch changes up to 1ab3681271c84b7f926be9ae3be1d769b7e933e9:
ARM: dts: prevent *.dtb from always being rebuilt (2013-01-14 08:08:31 -0600)
----------------------------------------------------------------
DeviceTree fixes for 3.8
2 fixes to prevent unconditional re-compile of dts files on arm and arm64.
----------------------------------------------------------------
Stephen Warren (2):
arm64: dts: prevent *.dtb from always being rebuilt
ARM: dts: prevent *.dtb from always being rebuilt
arch/arm/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/Makefile | 1 +
2 files changed, 2 insertions(+)
^ permalink raw reply
* [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code
From: Christoffer Dall @ 2013-01-14 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114153107.GE18935@mudshark.cambridge.arm.com>
On Mon, Jan 14, 2013 at 10:31 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jan 08, 2013 at 06:41:51PM +0000, Christoffer Dall wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> Wire the basic framework code for VGIC support and the initial in-kernel
>> MMIO support code for the VGIC, used for the distributor emulation.
>
> [...]
>
>> +/**
>> + * vgic_reg_access - access vgic register
>> + * @mmio: pointer to the data describing the mmio access
>> + * @reg: pointer to the virtual backing of vgic distributor data
>> + * @offset: least significant 2 bits used for word offset
>> + * @mode: ACCESS_ mode (see defines above)
>> + *
>> + * Helper to make vgic register access easier using one of the access
>> + * modes defined for vgic register access
>> + * (read,raz,write-ignored,setbit,clearbit,write)
>> + */
>> +static void vgic_reg_access(struct kvm_exit_mmio *mmio, u32 *reg,
>> + phys_addr_t offset, int mode)
>> +{
>> + int shift = (offset & 3) * 8;
>> + u32 mask;
>> + u32 regval;
>> +
>> + /*
>> + * Any alignment fault should have been delivered to the guest
>> + * directly (ARM ARM B3.12.7 "Prioritization of aborts").
>> + */
>> +
>> + mask = (~0U) >> shift;
>> + if (reg) {
>> + regval = *reg;
>> + } else {
>> + BUG_ON(mode != (ACCESS_READ_RAZ | ACCESS_WRITE_IGNORED));
>> + regval = 0;
>> + }
>> +
>> + if (mmio->is_write) {
>> + u32 data = (*((u32 *)mmio->data) & mask) << shift;
>> + switch (ACCESS_WRITE_MASK(mode)) {
>> + case ACCESS_WRITE_IGNORED:
>> + return;
>> +
>> + case ACCESS_WRITE_SETBIT:
>> + regval |= data;
>> + break;
>> +
>> + case ACCESS_WRITE_CLEARBIT:
>> + regval &= ~data;
>> + break;
>> +
>> + case ACCESS_WRITE_VALUE:
>> + regval = (regval & ~(mask << shift)) | data;
>> + break;
>> + }
>> + *reg = regval;
>> + } else {
>> + switch (ACCESS_READ_MASK(mode)) {
>> + case ACCESS_READ_RAZ:
>> + regval = 0;
>> + /* fall through */
>> +
>> + case ACCESS_READ_VALUE:
>> + *((u32 *)mmio->data) = (regval >> shift) & mask;
>> + }
>> + }
>> +}
>
> As I mentioned previously, I suspect that this doesn't work with big-endian
> systems. Whilst that's reasonable for the moment, a comment would be useful
> for the unlucky soul that decides to do that work in future (or add
> accessors for mmio->data as I suggested before).
>
admittedly this really hurts my brain, but I think there's actually no
problem with endianness: whatever comes in mmio->data will have native
endianness and the vgic is always little-endian, so a guest would have
to make sure to do its own endianness conversion before writing data,
or did I get this backwards? (some nasty feeling about if the OS is
compiled in another endianness than the hardware everything may
break).
Anyhow, I think there's another bug in this code though. Please take a
look and see if you agree:
commit 3cab2b93a6f6acd3c043e584f23b94ab8f1bbd66
Author: Christoffer Dall <c.dall@virtualopensystems.com>
Date: Mon Jan 14 15:55:18 2013 -0500
KVM: ARM: Limit vgic read/writes to load/store length
The vgic read/write operations did not consider ldrb/strb masks, and
would therefore unintentionally overwrite parts of a register.
Consider for example a store of a single byte to a word-aligned address
of one of the priority registers, that would cause the 3 most
significant bytes to be overwritten with zeros.
Cc: Marc Zyniger <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
index 25daa07..5c1bcf5 100644
--- a/arch/arm/kvm/vgic.c
+++ b/arch/arm/kvm/vgic.c
@@ -233,6 +233,16 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
*vcpu, int irq)
vcpu->arch.vgic_cpu.pending_shared);
}
+static u32 mmio_data_read(struct kvm_exit_mmio *mmio, u32 mask)
+{
+ return *((u32 *)mmio->data) & mask;
+}
+
+static void mmio_data_write(struct kvm_exit_mmio *mmio, u32 mask, u32 value)
+{
+ *((u32 *)mmio->data) = value & mask;
+}
+
/**
* vgic_reg_access - access vgic register
* @mmio: pointer to the data describing the mmio access
@@ -247,8 +257,8 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
*vcpu, int irq)
static void vgic_reg_access(struct kvm_exit_mmio *mmio, u32 *reg,
phys_addr_t offset, int mode)
{
- int shift = (offset & 3) * 8;
- u32 mask;
+ int word_offset = (offset & 3) * 8;
+ u32 mask = (1UL << (mmio->len * 8)) - 1;
u32 regval;
/*
@@ -256,7 +266,6 @@ static void vgic_reg_access(struct kvm_exit_mmio
*mmio, u32 *reg,
* directly (ARM ARM B3.12.7 "Prioritization of aborts").
*/
- mask = (~0U) >> shift;
if (reg) {
regval = *reg;
} else {
@@ -265,7 +274,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
*mmio, u32 *reg,
}
if (mmio->is_write) {
- u32 data = (*((u32 *)mmio->data) & mask) << shift;
+ u32 data = mmio_data_read(mmio, mask) << word_offset;
switch (ACCESS_WRITE_MASK(mode)) {
case ACCESS_WRITE_IGNORED:
return;
@@ -279,7 +288,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
*mmio, u32 *reg,
break;
case ACCESS_WRITE_VALUE:
- regval = (regval & ~(mask << shift)) | data;
+ regval = (regval & ~(mask << word_offset)) | data;
break;
}
*reg = regval;
@@ -290,7 +299,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
*mmio, u32 *reg,
/* fall through */
case ACCESS_READ_VALUE:
- *((u32 *)mmio->data) = (regval >> shift) & mask;
+ mmio_data_write(mmio, mask, regval >> word_offset);
}
}
}
@@ -702,6 +711,12 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu,
struct kvm_run *run,
(mmio->phys_addr + mmio->len) > (base + KVM_VGIC_V2_DIST_SIZE))
return false;
+ /* We don't support ldrd / strd or ldm / stm to the emulated vgic */
+ if (mmio->len > 4) {
+ kvm_inject_dabt(vcpu, mmio->phys_addr);
+ return true;
+ }
+
range = find_matching_range(vgic_ranges, mmio, base);
if (unlikely(!range || !range->handle_mmio)) {
pr_warn("Unhandled access %d %08llx %d\n",
--
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH v2 10/10] clk: tegra30: remove unused TEGRA_CLK_DUPLICATE()s
From: Mike Turquette @ 2013-01-14 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F07DA0.6000806@wwwdotorg.org>
Quoting Stephen Warren (2013-01-11 13:01:20)
> On 01/11/2013 01:01 AM, Prashant Gaikwad wrote:
> > With device tree support added for Tegra clocks look up is done from
> > device tree, remove unused TEGRA_CLK_DUPLICATE()s.
>
> Cc'ing in the drivers/clk maintainer as an FYI and for Acks; this patch
> needs to go through the Tegra tree due to dependencies.
>
Acked-by: Mike Turquette <mturquette@linaro.org>
> > Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
> > ---
> > drivers/clk/tegra/clk-tegra30.c | 70 ---------------------------------------
> > 1 files changed, 0 insertions(+), 70 deletions(-)
> >
> > diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
> > index 987312c..6d1ff86 100644
> > --- a/drivers/clk/tegra/clk-tegra30.c
> > +++ b/drivers/clk/tegra/clk-tegra30.c
> > @@ -1642,41 +1642,6 @@ static void __init tegra30_periph_clk_init(void)
> > clk_register_clkdev(clk, "emc", NULL);
> > clks[emc] = clk;
> >
> > - /* i2c1-fast */
> > - clk = clk_register_fixed_factor(NULL, "i2c1-fast", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "fast-clk", "tegra-i2c.0");
> > -
> > - /* i2c2-fast */
> > - clk = clk_register_fixed_factor(NULL, "i2c2-fast", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "fast-clk", "tegra-i2c.1");
> > -
> > - /* i2c3-fast */
> > - clk = clk_register_fixed_factor(NULL, "i2c3-fast", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "fast-clk", "tegra-i2c.2");
> > -
> > - /* i2c4-fast */
> > - clk = clk_register_fixed_factor(NULL, "i2c4-fast", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "fast-clk", "tegra-i2c.3");
> > -
> > - /* i2c5-fast */
> > - clk = clk_register_fixed_factor(NULL, "i2c5-fast", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "fast-clk", "tegra-i2c.5");
> > -
> > - /* dsi1-fixed */
> > - clk = clk_register_fixed_factor(NULL, "dsi1-fixed", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "dsi-fixed", "tegradc.0");
> > -
> > - /* dsi2-fixed */
> > - clk = clk_register_fixed_factor(NULL, "dsi2-fixed", "pll_p_out3",
> > - CLK_SET_RATE_PARENT, 1, 1);
> > - clk_register_clkdev(clk, "dsi-fixed", "tegradc.1");
> > -
> > for (i = 0; i < ARRAY_SIZE(tegra_periph_clk_list); i++) {
> > data = &tegra_periph_clk_list[i];
> > clk = tegra_clk_periph(data->name, data->parent_names,
> > @@ -1935,19 +1900,9 @@ static __initdata struct tegra_clk_init_table init_table[] = {
> > * table under two names.
> > */
> > static struct tegra_clk_duplicate tegra_clk_duplicates[] = {
> > - TEGRA_CLK_DUPLICATE(uarta, "serial8250.0", NULL),
> > - TEGRA_CLK_DUPLICATE(uartb, "serial8250.1", NULL),
> > - TEGRA_CLK_DUPLICATE(uartc, "serial8250.2", NULL),
> > - TEGRA_CLK_DUPLICATE(uartd, "serial8250.3", NULL),
> > - TEGRA_CLK_DUPLICATE(uarte, "serial8250.4", NULL),
> > TEGRA_CLK_DUPLICATE(usbd, "utmip-pad", NULL),
> > TEGRA_CLK_DUPLICATE(usbd, "tegra-ehci.0", NULL),
> > TEGRA_CLK_DUPLICATE(usbd, "tegra-otg", NULL),
> > - TEGRA_CLK_DUPLICATE(pll_p, "tegradc.0", "parent"),
> > - TEGRA_CLK_DUPLICATE(pll_p, "tegradc.1", "parent"),
> > - TEGRA_CLK_DUPLICATE(pll_d2_out0, "hdmi", "parent"),
> > - TEGRA_CLK_DUPLICATE(dsib, "tegradc.0", "dsib"),
> > - TEGRA_CLK_DUPLICATE(dsia, "tegradc.1", "dsia"),
> > TEGRA_CLK_DUPLICATE(bsev, "tegra-avp", "bsev"),
> > TEGRA_CLK_DUPLICATE(bsev, "nvavp", "bsev"),
> > TEGRA_CLK_DUPLICATE(vde, "tegra-aes", "vde"),
> > @@ -1956,33 +1911,8 @@ static struct tegra_clk_duplicate tegra_clk_duplicates[] = {
> > TEGRA_CLK_DUPLICATE(cml1, "tegra_sata_cml", NULL),
> > TEGRA_CLK_DUPLICATE(cml0, "tegra_pcie", "cml"),
> > TEGRA_CLK_DUPLICATE(pciex, "tegra_pcie", "pciex"),
> > - TEGRA_CLK_DUPLICATE(i2c1, "tegra-i2c-slave.0", NULL),
> > - TEGRA_CLK_DUPLICATE(i2c2, "tegra-i2c-slave.1", NULL),
> > - TEGRA_CLK_DUPLICATE(i2c3, "tegra-i2c-slave.2", NULL),
> > - TEGRA_CLK_DUPLICATE(i2c4, "tegra-i2c-slave.3", NULL),
> > - TEGRA_CLK_DUPLICATE(i2c5, "tegra-i2c-slave.4", NULL),
> > - TEGRA_CLK_DUPLICATE(sbc1, "spi_slave_tegra.0", NULL),
> > - TEGRA_CLK_DUPLICATE(sbc2, "spi_slave_tegra.1", NULL),
> > - TEGRA_CLK_DUPLICATE(sbc3, "spi_slave_tegra.2", NULL),
> > - TEGRA_CLK_DUPLICATE(sbc4, "spi_slave_tegra.3", NULL),
> > - TEGRA_CLK_DUPLICATE(sbc5, "spi_slave_tegra.4", NULL),
> > - TEGRA_CLK_DUPLICATE(sbc6, "spi_slave_tegra.5", NULL),
> > TEGRA_CLK_DUPLICATE(twd, "smp_twd", NULL),
> > TEGRA_CLK_DUPLICATE(vcp, "nvavp", "vcp"),
> > - TEGRA_CLK_DUPLICATE(i2s0, NULL, "i2s0"),
> > - TEGRA_CLK_DUPLICATE(i2s1, NULL, "i2s1"),
> > - TEGRA_CLK_DUPLICATE(i2s2, NULL, "i2s2"),
> > - TEGRA_CLK_DUPLICATE(i2s3, NULL, "i2s3"),
> > - TEGRA_CLK_DUPLICATE(i2s4, NULL, "i2s4"),
> > - TEGRA_CLK_DUPLICATE(dam0, NULL, "dam0"),
> > - TEGRA_CLK_DUPLICATE(dam1, NULL, "dam1"),
> > - TEGRA_CLK_DUPLICATE(dam2, NULL, "dam2"),
> > - TEGRA_CLK_DUPLICATE(spdif_in, NULL, "spdif_in"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.0", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.1", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.2", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.3", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.4", "fast-clk"),
> > TEGRA_CLK_DUPLICATE(clk_max, NULL, NULL), /* MUST be the last entry */
> > };
> >
> >
^ permalink raw reply
* [PATCH v2 09/10] clk: tegra20: remove unused TEGRA_CLK_DUPLICATE()s
From: Mike Turquette @ 2013-01-14 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F07D87.4000405@wwwdotorg.org>
Quoting Stephen Warren (2013-01-11 13:00:55)
> On 01/11/2013 01:01 AM, Prashant Gaikwad wrote:
> > With device tree support added for Tegra clocks look up is done from
> > device tree, remove unused TEGRA_CLK_DUPLICATE()s.
>
> Cc'ing in the drivers/clk maintainer as an FYI and for Acks; this patch
> needs to go through the Tegra tree due to dependencies.
>
Acked-by: Mike Turquette <mturquette@linaro.org>
> > Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
> > ---
> > drivers/clk/tegra/clk-tegra20.c | 17 -----------------
> > 1 files changed, 0 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> > index 4875261..9383b85 100644
> > --- a/drivers/clk/tegra/clk-tegra20.c
> > +++ b/drivers/clk/tegra/clk-tegra20.c
> > @@ -1174,28 +1174,11 @@ static __initdata struct tegra_clk_init_table init_table[] = {
> > * table under two names.
> > */
> > static struct tegra_clk_duplicate tegra_clk_duplicates[] = {
> > - TEGRA_CLK_DUPLICATE(uarta, "serial8250.0", NULL),
> > - TEGRA_CLK_DUPLICATE(uartb, "serial8250.1", NULL),
> > - TEGRA_CLK_DUPLICATE(uartc, "serial8250.2", NULL),
> > - TEGRA_CLK_DUPLICATE(uartd, "serial8250.3", NULL),
> > - TEGRA_CLK_DUPLICATE(uarte, "serial8250.4", NULL),
> > TEGRA_CLK_DUPLICATE(usbd, "utmip-pad", NULL),
> > TEGRA_CLK_DUPLICATE(usbd, "tegra-ehci.0", NULL),
> > TEGRA_CLK_DUPLICATE(usbd, "tegra-otg", NULL),
> > - TEGRA_CLK_DUPLICATE(pll_p, "tegradc.0", "parent"),
> > - TEGRA_CLK_DUPLICATE(pll_p, "tegradc.1", "parent"),
> > - TEGRA_CLK_DUPLICATE(pll_d_out0, "hdmi", "parent"),
> > - TEGRA_CLK_DUPLICATE(gr2d, "tegra_grhost", "gr2d"),
> > - TEGRA_CLK_DUPLICATE(gr3d, "tegra_grhost", "gr3d"),
> > - TEGRA_CLK_DUPLICATE(epp, "tegra_grhost", "epp"),
> > - TEGRA_CLK_DUPLICATE(mpe, "tegra_grhost", "mpe"),
> > - TEGRA_CLK_DUPLICATE(vde, "tegra-aes", "vde"),
> > TEGRA_CLK_DUPLICATE(cclk, NULL, "cpu"),
> > TEGRA_CLK_DUPLICATE(twd, "smp_twd", NULL),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.0", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.1", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.2", "fast-clk"),
> > - TEGRA_CLK_DUPLICATE(pll_p_out3, "tegra-i2c.3", "fast-clk"),
> > TEGRA_CLK_DUPLICATE(clk_max, NULL, NULL), /* Must be the last entry */
> > };
> >
> >
^ permalink raw reply
* OMAP baseline test results for v3.8-rc3
From: Aaro Koskinen @ 2013-01-14 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114191459.GA9402@arwen.pp.htv.fi>
On Mon, Jan 14, 2013 at 09:14:59PM +0200, Felipe Balbi wrote:
> On Mon, Jan 14, 2013 at 08:40:18PM +0200, Aaro Koskinen wrote:
> > On Mon, Jan 14, 2013 at 05:59:12PM +0000, Paul Walmsley wrote:
> > > Here are some basic OMAP test results for Linux v3.8-rc3.
> > > Logs and other details at:
> > >
> > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc3/20130109222058/
> > >
> > >
> > > Test summary
> > > ------------
> > >
> > > Boot to userspace:
> > > Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
> > > 3730beaglexm, 37xxevm, 4430es2panda, 5912osk,
> > > 4460pandaes
> > > FAIL ( 2/11): am335xbone, cmt3517
> >
> > N900 boot is unstable again, I2C issues are back.
>
> damn!
>
> > Boot succeeds and fails randomly. Let's see if this can be bisected.
> > The same kernel works on N950.
>
> fair enough, it might be something related to some errata fix which
> might have been missed. Can you apply this small patch just so I know if
> there is something pending in CNT reg ?
[ 0.207946] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
[ 0.208129] twl 1-0048: power (irq 343) chaining IRQs 346..353
[ 0.209350] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
[ 1.218749] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 1.218811] omap_i2c omap_i2c.1: SA 0049 CON 9602 CNT 0004
[ 2.234374] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 2.234436] omap_i2c omap_i2c.1: SA 0049 CON 9602 CNT 0004
[ 2.234466] twl: Write failed (mod 2, reg 0x12 count 1)
[ 3.249999] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 3.250030] omap_i2c omap_i2c.1: SA 0049 CON 9602 CNT 0004
[ 3.250061] twl: Write failed (mod 2, reg 0x12 count 1)
> you might also want to try merging my latest i2c patches, which missed
> the merge window, as they might help with this issue too.
>
> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
>
> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c-deferred-STP
I could not reproduce the issue with these. Tested around 20 boots.
There's a noticeable delay (over 4 secs!) around where I2C is initialized
and used for the first time, but no errors and the boot completes:
[ 0.187530] SCSI subsystem initialized
[ 0.188110] usbcore: registered new interface driver usbfs
[ 0.188415] usbcore: registered new interface driver hub
[ 0.188781] usbcore: registered new device driver usb
[ 0.189453] musb-omap2430 musb-omap2430: invalid resource
[ 4.296905] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
[ 4.297088] twl 1-0048: power (irq 343) chaining IRQs 346..353
[ 4.329010] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
[ 4.470123] VUSB1V5: 1500 mV normal standby
[ 4.470916] VUSB1V8: 1800 mV normal standby
A.
^ permalink raw reply
* [PATCH] cpsw: Add support to read cpu MAC address
From: Grant Likely @ 2013-01-14 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357917302-32550-1-git-send-email-michal.bachraty@streamunlimited.com>
On Fri, 11 Jan 2013 16:15:02 +0100, Michal Bachraty <michal.bachraty@streamunlimited.com> wrote:
> Signed-off-by: Michal Bachraty <michal.bachraty@streamunlimited.com>
> ---
> Documentation/devicetree/bindings/net/cpsw.txt | 10 +-
> arch/arm/boot/dts/am33xx.dtsi | 5 +-
> drivers/net/ethernet/ti/cpsw.c | 121 +++++++++++++++++++++---
> include/linux/platform_data/cpsw.h | 8 ++
> 4 files changed, 128 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
> index dcaabe9..432122c 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -4,7 +4,7 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
> Required properties:
> - compatible : Should be "ti,cpsw"
> - reg : physical base address and size of the cpsw
> - registers map
> + registers map and mac-address cpu config registers
> - interrupts : property with a value describing the interrupt
> number
> - interrupt-parent : The parent interrupt controller
> @@ -25,17 +25,23 @@ Required properties:
> - slave_reg_ofs : Specifies slave register offset
> - sliver_reg_ofs : Specifies slave sliver register offset
> - phy_id : Specifies slave phy id
> -- mac-address : Specifies slave MAC address
>
> Optional properties:
> - ti,hwmods : Must be "cpgmac0"
> - no_bd_ram : Must be 0 or 1
> +- mac-address-source : Specifies source of MAC address ("user-defined-mac",
> + "cpu-id0-mac", "cpu-id01-mac", "random-mac"). If not
> + specified, "cpu-id0-mac" is selected
Drop the '-mac' suffix on the values. The property is already named
"mac-address-source", so I think it is already unambiguious from the
context. :-)
Otherwise the patch looks good to me, but I haven't gone over the code
in fine detail.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
^ permalink raw reply
* [PATCH v2 01/10] spi: tegra: Do not use clock name to get clock
From: Grant Likely @ 2013-01-14 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F07CF4.2090502@wwwdotorg.org>
On Fri, 11 Jan 2013 13:58:28 -0700, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/11/2013 01:01 AM, Prashant Gaikwad wrote:
> > Since Tegra spi devices do not have multiple clocks, no need to use
> > clock name to get the clock.
>
> Cc'ing in the SPI maintainers as an FYI and for Acks; this patch needs
> to go through the Tegra tree due to dependencies.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
No problem merging it via the Tegra tree.
g.
^ permalink raw reply
* [Bulk] [PATCH] timer: vt8500: Move timer code to drivers/clocksource
From: Olof Johansson @ 2013-01-14 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358142455.25591.1.camel@gitbox>
On Mon, Jan 14, 2013 at 06:47:35PM +1300, Tony Prisk wrote:
> On Mon, 2013-01-14 at 18:13 +1300, Tony Prisk wrote:
> > On Mon, 2013-01-14 at 18:09 +1300, Tony Prisk wrote:
> > > This patch moves arch-vt8500/timer.c into drivers/clocksource and
> > > updates the necessary Kconfig/Makefile options.
> > >
> > > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> > > ---
> > > arch/arm/mach-vt8500/Kconfig | 1 +
> > > arch/arm/mach-vt8500/Makefile | 2 +-
> > > arch/arm/mach-vt8500/common.h | 1 -
> > > arch/arm/mach-vt8500/timer.c | 184 ------------------------------------
> > > arch/arm/mach-vt8500/vt8500.c | 1 +
> > > drivers/clocksource/Kconfig | 3 +
> > > drivers/clocksource/Makefile | 1 +
> > > drivers/clocksource/vt8500_timer.c | 184 ++++++++++++++++++++++++++++++++++++
> > > include/linux/vt8500_timer.h | 22 +++++
> > > 9 files changed, 213 insertions(+), 186 deletions(-)
> > > delete mode 100644 arch/arm/mach-vt8500/timer.c
> > > create mode 100644 drivers/clocksource/vt8500_timer.c
> > > create mode 100644 include/linux/vt8500_timer.h
> >
> > Darn.. forgot the -m again. I'll await your feedback regarding the
> > basing of the patch first (and any other feedback), then I'll redo it
> > with the correct stats.
> >
> > Regards
> > Tony P
>
> Oh grr.. forget this completely. It doesn't take into account the
> patches I already sent for WM8850.
>
> I guess it needs to be based on timer/cleanup + vt8500/wm8x50.
>
> Need a little advise on how to handle this one please :)
The normal way to handle these kind of dependencies is to base them on merges
of the needed branches. Based on the later email, you only seem to need
timer/cleanup, but if you would have needed the other one, then you'd merge
that on top of timer/cleanup, and then add your patches.
Of course, ideally you would do the cleanup, then add the wm8x50 features,
but in reality work doesn't always pan out that way, so you end up with
cleanups that depend on including new features in the same (sweeping)
cleanup since they have already been merged. That's when things sometimes
get hairy, and we need to start a second cleanup branch that's "after"
the feature branch in the sequence of topics. But it should be rare,
and in your case it seems like it wasn't needed.
-Olof
^ permalink raw reply
* [PATCH] mmc: add BCM2835 driver
From: Chris Ball @ 2013-01-14 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357191289-10455-1-git-send-email-swarren@wwwdotorg.org>
Hi Stephen,
On Thu, Jan 03 2013, Stephen Warren wrote:
> Add a very simple driver for the BCM2835 SoC, which is used in the
> Raspberry Pi board.
>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Looks good, thanks -- pushed to mmc-next for 3.9.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH v5 2/4] ARM: KVM: arch_timers: Add guest timer core support
From: Christoffer Dall @ 2013-01-14 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114151837.GC18935@mudshark.cambridge.arm.com>
On Mon, Jan 14, 2013 at 10:18 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jan 08, 2013 at 06:43:20PM +0000, Christoffer Dall wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> Add some the architected timer related infrastructure, and support timer
>> interrupt injection, which can happen as a resultof three possible
>> events:
>>
>> - The virtual timer interrupt has fired while we were still
>> executing the guest
>> - The timer interrupt hasn't fired, but it expired while we
>> were doing the world switch
>> - A hrtimer we programmed earlier has fired
>
> [...]
>
>> +void kvm_timer_sync_to_cpu(struct kvm_vcpu *vcpu)
>> +{
>> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +
>> + /*
>> + * We're about to run this vcpu again, so there is no need to
>> + * keep the background timer running, as we're about to
>> + * populate the CPU timer again.
>> + */
>> + timer_disarm(timer);
>> +}
>> +
>> +void kvm_timer_sync_from_cpu(struct kvm_vcpu *vcpu)
>> +{
>> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> + cycle_t cval, now;
>> + u64 ns;
>> +
>> + /* Check if the timer is enabled and unmasked first */
>> + if ((timer->cntv_ctl & 3) != 1)
>> + return;
>> +
>> + cval = timer->cntv_cval;
>> + now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>> +
>> + BUG_ON(timer_is_armed(timer));
>> +
>> + if (cval <= now) {
>> + /*
>> + * Timer has already expired while we were not
>> + * looking. Inject the interrupt and carry on.
>> + */
>> + kvm_timer_inject_irq(vcpu);
>> + return;
>> + }
>> +
>> + ns = cyclecounter_cyc2ns(timecounter->cc, cval - now);
>> + timer_arm(timer, ns);
>> +}
>
> Please use flush/sync terminology to match the rest of arch/arm/.
>
ok, the following fixes this for both timers and the vgic:
commit 1b68f39459dbc797f6766c103edf2c1053984161
Author: Christoffer Dall <c.dall@virtualopensystems.com>
Date: Mon Jan 14 14:16:31 2013 -0500
KVM: ARM: vgic: use sync/flush terminology
Use sync/flush for saving state to/from CPUs to be consistent with
other uses in arch/arm.
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
diff --git a/arch/arm/include/asm/kvm_vgic.h b/arch/arm/include/asm/kvm_vgic.h
index 5e81e28..f5f270b 100644
--- a/arch/arm/include/asm/kvm_vgic.h
+++ b/arch/arm/include/asm/kvm_vgic.h
@@ -149,8 +149,8 @@ int kvm_vgic_hyp_init(void);
int kvm_vgic_init(struct kvm *kvm);
int kvm_vgic_create(struct kvm *kvm);
int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
-void kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu);
-void kvm_vgic_sync_from_cpu(struct kvm_vcpu *vcpu);
+void kvm_vgic_flush(struct kvm_vcpu *vcpu);
+void kvm_vgic_sync(struct kvm_vcpu *vcpu);
int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
bool level);
int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f986718..7921bc4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -714,7 +714,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *run)
update_vttbr(vcpu->kvm);
- kvm_vgic_sync_to_cpu(vcpu);
+ kvm_vgic_flush(vcpu);
kvm_timer_flush(vcpu);
local_irq_disable();
@@ -730,7 +730,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *run)
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm)) {
local_irq_enable();
kvm_timer_sync(vcpu);
- kvm_vgic_sync_from_cpu(vcpu);
+ kvm_vgic_sync(vcpu);
continue;
}
@@ -770,7 +770,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *run)
*************************************************************/
kvm_timer_sync(vcpu);
- kvm_vgic_sync_from_cpu(vcpu);
+ kvm_vgic_sync(vcpu);
ret = handle_exit(vcpu, run, ret);
}
diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
index 7eb94fa..25daa07 100644
--- a/arch/arm/kvm/vgic.c
+++ b/arch/arm/kvm/vgic.c
@@ -946,7 +946,7 @@ static bool vgic_queue_hwirq(struct kvm_vcpu *vcpu, int irq)
* Fill the list registers with pending interrupts before running the
* guest.
*/
-static void __kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu)
+static void __kvm_vgic_flush(struct kvm_vcpu *vcpu)
{
struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
@@ -1009,7 +1009,7 @@ static bool vgic_process_maintenance(struct
kvm_vcpu *vcpu)
* We do not need to take the distributor lock here, since the only
* action we perform is clearing the irq_active_bit for an EOIed
* level interrupt. There is a potential race with
- * the queuing of an interrupt in __kvm_sync_to_cpu(), where we check
+ * the queuing of an interrupt in __kvm_vgic_flush(), where we check
* if the interrupt is already active. Two possibilities:
*
* - The queuing is occurring on the same vcpu: cannot happen,
@@ -1055,7 +1055,7 @@ static bool vgic_process_maintenance(struct
kvm_vcpu *vcpu)
* the distributor here (the irq_pending_on_cpu bit is safe to set),
* so there is no need for taking its lock.
*/
-static void __kvm_vgic_sync_from_cpu(struct kvm_vcpu *vcpu)
+static void __kvm_vgic_sync(struct kvm_vcpu *vcpu)
{
struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
@@ -1085,7 +1085,7 @@ static void __kvm_vgic_sync_from_cpu(struct
kvm_vcpu *vcpu)
set_bit(vcpu->vcpu_id, &dist->irq_pending_on_cpu);
}
-void kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu)
+void kvm_vgic_flush(struct kvm_vcpu *vcpu)
{
struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
@@ -1093,16 +1093,16 @@ void kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu)
return;
spin_lock(&dist->lock);
- __kvm_vgic_sync_to_cpu(vcpu);
+ __kvm_vgic_flush(vcpu);
spin_unlock(&dist->lock);
}
-void kvm_vgic_sync_from_cpu(struct kvm_vcpu *vcpu)
+void kvm_vgic_sync(struct kvm_vcpu *vcpu)
{
if (!irqchip_in_kernel(vcpu->kvm))
return;
- __kvm_vgic_sync_from_cpu(vcpu);
+ __kvm_vgic_sync(vcpu);
}
int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
--
commit b9e08fdd32b7f3da3ad0b287c4da575b3b6c23d7
Author: Christoffer Dall <c.dall@virtualopensystems.com>
Date: Mon Jan 14 14:15:31 2013 -0500
KVM: ARM: timers: use sync/flush terminology
Use sync/flush for saving state to/from CPUs to be consistent with other
uses in arch/arm.
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
diff --git a/arch/arm/include/asm/kvm_arch_timer.h
b/arch/arm/include/asm/kvm_arch_timer.h
index aed1c42..2af5096 100644
--- a/arch/arm/include/asm/kvm_arch_timer.h
+++ b/arch/arm/include/asm/kvm_arch_timer.h
@@ -62,8 +62,8 @@ struct arch_timer_cpu {
int kvm_timer_hyp_init(void);
int kvm_timer_init(struct kvm *kvm);
void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
-void kvm_timer_sync_to_cpu(struct kvm_vcpu *vcpu);
-void kvm_timer_sync_from_cpu(struct kvm_vcpu *vcpu);
+void kvm_timer_flush(struct kvm_vcpu *vcpu);
+void kvm_timer_sync(struct kvm_vcpu *vcpu);
void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
#else
static inline int kvm_timer_hyp_init(void)
diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 6cb9aa3..3f2580f 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -101,7 +101,14 @@ static enum hrtimer_restart
kvm_timer_expire(struct hrtimer *hrt)
return HRTIMER_NORESTART;
}
-void kvm_timer_sync_to_cpu(struct kvm_vcpu *vcpu)
+/**
+ * kvm_timer_flush - prepare to move the virt timer to the cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Disarm any pending soft timers, since the world-switch code will write the
+ * virtual timer state back to the physical CPU.
+ */
+void kvm_timer_flush(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -113,7 +120,14 @@ void kvm_timer_sync_to_cpu(struct kvm_vcpu *vcpu)
timer_disarm(timer);
}
-void kvm_timer_sync_from_cpu(struct kvm_vcpu *vcpu)
+/**
+ * kvm_timer_sync - sync timer state from cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Check if the virtual timer was armed and either schedule a corresponding
+ * soft timer or inject directly if already expired.
+ */
+void kvm_timer_sync(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
cycle_t cval, now;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index fdd4a7c..f986718 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -715,7 +715,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *run)
update_vttbr(vcpu->kvm);
kvm_vgic_sync_to_cpu(vcpu);
- kvm_timer_sync_to_cpu(vcpu);
+ kvm_timer_flush(vcpu);
local_irq_disable();
@@ -729,7 +729,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *run)
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm)) {
local_irq_enable();
- kvm_timer_sync_from_cpu(vcpu);
+ kvm_timer_sync(vcpu);
kvm_vgic_sync_from_cpu(vcpu);
continue;
}
@@ -769,7 +769,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *run)
* Back from guest
*************************************************************/
- kvm_timer_sync_from_cpu(vcpu);
+ kvm_timer_sync(vcpu);
kvm_vgic_sync_from_cpu(vcpu);
ret = handle_exit(vcpu, run, ret);
--
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH REBASE 0/6] i2c: omap: misc changes
From: Felipe Balbi @ 2013-01-14 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355502849-9289-1-git-send-email-balbi@ti.com>
Hi,
On Fri, Dec 14, 2012 at 06:34:03PM +0200, Felipe Balbi wrote:
> this is just a rebase of the previous series adding support
> for amount of bytes transferred upon NACK.
>
> Well, actually the patches implementing transferred bytes
> reporting aren't here because we need to discuss how to move
> forward.
>
> This series is just a preparation for that, but it also
> contains a at least one bugfix.
>
> Each and every patch has been tested with pandaboard, it
> would be nice to get Tested-bys from other folks on other
> platforms before pushing this for v3.9 (there's more than
> enough time for that).
>
> Note that we're also dropping b_hw flag since that becomes
> useless since we'll never set STT and STP together anymore.
>
> Give it a good round of test, please.
Wolfram, I have these patches rebased on top of v3.8-rc3 if you wish.
Let me know if I should resend them (again).
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/ab751ed8/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.8-rc3
From: Felipe Balbi @ 2013-01-14 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114184018.GA18224@blackmetal.musicnaut.iki.fi>
Hi,
On Mon, Jan 14, 2013 at 08:40:18PM +0200, Aaro Koskinen wrote:
> On Mon, Jan 14, 2013 at 05:59:12PM +0000, Paul Walmsley wrote:
> > Here are some basic OMAP test results for Linux v3.8-rc3.
> > Logs and other details at:
> >
> > http://www.pwsan.com/omap/testlogs/test_v3.8-rc3/20130109222058/
> >
> >
> > Test summary
> > ------------
> >
> > Boot to userspace:
> > Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
> > 3730beaglexm, 37xxevm, 4430es2panda, 5912osk,
> > 4460pandaes
> > FAIL ( 2/11): am335xbone, cmt3517
>
> N900 boot is unstable again, I2C issues are back.
damn!
> Boot succeeds and fails randomly. Let's see if this can be bisected.
> The same kernel works on N950.
fair enough, it might be something related to some errata fix which
might have been missed. Can you apply this small patch just so I know if
there is something pending in CNT reg ?
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 20d41bf..173e883 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -462,6 +462,10 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) & OMAP_I2C_STAT_BB) {
if (time_after(jiffies, timeout)) {
dev_warn(dev->dev, "timeout waiting for bus ready\n");
+ dev_warn(dev->dev, "SA %04x CON %04x CNT %04x\n",
+ omap_i2c_read_reg(dev, OMAP_I2C_SA_REG),
+ omap_i2c_read_reg(dev, OMAP_I2C_CON_REG),
+ omap_i2c_read_reg(dev, OMAP_I2C_CNT_REG));
return -ETIMEDOUT;
}
msleep(1);
you might also want to try merging my latest i2c patches, which missed
the merge window, as they might help with this issue too.
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c-deferred-STP
for you to fetch changes up to a7b1b41b270be84f6bf6e7d3654d74c873b3daf8:
i2c: omap: get rid of b_hw flag (2013-01-14 21:04:16 +0200)
----------------------------------------------------------------
Felipe Balbi (6):
i2c: omap: no need to access platform_device
i2c: omap: also complete() when stat becomes zero
i2c: omap: improve 'rev' a little bit
i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS
i2c: omap: wait for transfer completion before sending STP bit
i2c: omap: get rid of b_hw flag
drivers/i2c/busses/i2c-omap.c | 184 +++++++++++++++++++++---------------------
1 file changed, 93 insertions(+), 91 deletions(-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/0686f1db/attachment.sig>
^ permalink raw reply related
* [kvmarm] [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Christoffer Dall @ 2013-01-14 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114190018.GL31341@mudshark.cambridge.arm.com>
On Mon, Jan 14, 2013 at 2:00 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 14, 2013 at 06:53:14PM +0000, Alexander Graf wrote:
>> On 01/14/2013 07:50 PM, Will Deacon wrote:
>> > FWIW, KVM only needs this code for handling complex MMIO instructions, which
>> > aren't even generated by recent guest kernels. I'm inclined to suggest removing
>> > this emulation code from KVM entirely given that it's likely to bitrot as
>> > it is executed less and less often.
>>
>> That'd mean that you heavily limit what type of guests you're executing,
>> which I don't think is a good idea.
>
> To be honest, I don't think we know whether that's true or not. How many
> guests out there do writeback accesses to MMIO devices? Even on older
> Linux guests, it was dependent on how GCC felt.
I don't think bitrot'ing is a valid argument: the code doesn't depend
on any other implementation state that's likely to change and break
this code (the instruction encoding is not exactly going to change).
And we should simply finish the selftest code to test this stuff
(which should be finished if the code is unified or not, and is on my
todo list).
>
> I see where you're coming from, I just don't think we can quantify it either
> way outside of Linux.
>
FWIW, I know of at least a couple of companies wanting to use KVM for
running non-Linux guests as well.
But, however a shame, I can more easily maintain this single patch
out-of-tree, so I'm willing to drop this logic for now if it gets
things moving.
-Christoffer
^ permalink raw reply
* [PATCH v2 0/3] Use devm_* managed functions to ease slot-gpio users
From: Chris Ball @ 2013-01-14 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355236340-21304-1-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On Tue, Dec 11 2012, Shawn Guo wrote:
> Changes since v1:
> * Add kernel doc for mmc_gpio_request/free_ro/cd() to document the
> use cases.
> * Add a patch to remove unncessary mmc_gpio_free_cd() call from
> existing slot-gpio users.
>
> Shawn Guo (3):
> mmc: slot-gpio: use devm_* managed functions to ease users
> mmc: remove unncessary mmc_gpio_free_cd() call from slot-gpio users
> mmc: sdhci-esdhc-imx: use slot-gpio helpers for CD and WP
>
> drivers/mmc/core/slot-gpio.c | 57 ++++++++++++++++++++++++++++++++----
> drivers/mmc/host/sdhci-esdhc-imx.c | 56 ++++++++++-------------------------
> drivers/mmc/host/sdhci-pxav3.c | 5 ----
> drivers/mmc/host/sh_mmcif.c | 6 ----
> drivers/mmc/host/tmio_mmc_pio.c | 8 -----
> 5 files changed, 67 insertions(+), 65 deletions(-)
Thanks for doing this, all merged to mmc-next for 3.9.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] ARM: sunxi: Use the Synosys APB UART instead of ns8250
From: Maxime Ripard @ 2013-01-14 19:09 UTC (permalink / raw)
To: linux-arm-kernel
The UART controller used in the A10/A13 is the Synopsys DesignWare 8250.
The wrong use of a regular 8250 driver may lead to a oops during kernel
boot with "irq 17: nobody cared", because the apb UART as an extra
interrupt that gets raised when writing to the LCR when busy.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sunxi.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index 8bbc2bf..8b36abe 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -60,19 +60,21 @@
};
uart0: uart at 01c28000 {
- compatible = "ns8250";
+ compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
interrupts = <1>;
reg-shift = <2>;
+ reg-io-width = <4>;
clock-frequency = <24000000>;
status = "disabled";
};
uart1: uart at 01c28400 {
- compatible = "ns8250";
+ compatible = "snps,dw-apb-uart";
reg = <0x01c28400 0x400>;
interrupts = <2>;
reg-shift = <2>;
+ reg-io-width = <4>;
clock-frequency = <24000000>;
status = "disabled";
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH] mmc: sdhci: query card presence from cd-gpio before asking SDHCI
From: Chris Ball @ 2013-01-14 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355210622-9753-1-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On Tue, Dec 11 2012, Shawn Guo wrote:
> Call mmc_gpio_get_cd() to query card presence from cd-gpio before
> asking SDHCI. The rationale behind this change is that flag
> SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to
> tell that SDHCI_PRESENT_STATE is broken, and it should be used for this
> case only. So when cd-gpio is being used, the controller should set
> the flag to tell that SDHCI_PRESENT_STATE is not available.
>
> However, the existing code will skip checking cd-gpio as long as flag
> SDHCI_QUIRK_BROKEN_CARD_DETECTION is set. Change the querying order
> between cd-gpio and SDHCI to support the rationale above.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Thanks, pushed to mmc-next for 3.9.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [kvmarm] [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Will Deacon @ 2013-01-14 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F4541A.9030702@suse.de>
On Mon, Jan 14, 2013 at 06:53:14PM +0000, Alexander Graf wrote:
> On 01/14/2013 07:50 PM, Will Deacon wrote:
> > FWIW, KVM only needs this code for handling complex MMIO instructions, which
> > aren't even generated by recent guest kernels. I'm inclined to suggest removing
> > this emulation code from KVM entirely given that it's likely to bitrot as
> > it is executed less and less often.
>
> That'd mean that you heavily limit what type of guests you're executing,
> which I don't think is a good idea.
To be honest, I don't think we know whether that's true or not. How many
guests out there do writeback accesses to MMIO devices? Even on older
Linux guests, it was dependent on how GCC felt.
I see where you're coming from, I just don't think we can quantify it either
way outside of Linux.
Will
^ permalink raw reply
* [kvmarm] [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Christoffer Dall @ 2013-01-14 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F4541A.9030702@suse.de>
On Mon, Jan 14, 2013 at 1:53 PM, Alexander Graf <agraf@suse.de> wrote:
> On 01/14/2013 07:50 PM, Will Deacon wrote:
>>
>> On Mon, Jan 14, 2013 at 06:43:19PM +0000, Russell King - ARM Linux wrote:
>>>
>>> On Mon, Jan 14, 2013 at 01:25:39PM -0500, Christoffer Dall wrote:
>>>>
>>>> However, unifying all instruction decoding within arch/arm is quite
>>>> the heavy task, and requires agreeing on some canonical API that
>>>> people can live with and it will likely take a long time. I seem to
>>>> recall there were also arguments against unifying kprobe code with
>>>> other instruction decoding, as the kprobe code was also written to
>>>> work highly optimized under certain assumptions, if I understood
>>>> previous comments correctly.
>>>
>>> Yes, I know Rusty had a go.
>>>
>>> What I think may make sense is to unify this and the alignment code.
>>> They're really after the same things, which are:
>>>
>>> - Given an instruction, and register set, calculate the address of the
>>> access, size, number of accesses, and the source/destination
>>> registers.
>>> - Update the register set as though the instruction had been executed
>>> by the CPU.
>>>
>>> However, I've changed tack slightly from the above in the last 10 minutes
>>> or so. I'm thinking a little more that we might be able to take what we
>>> already have in alignment.c and provide it with a set of accessors
>>> according to size etc.
>>
>> FWIW, KVM only needs this code for handling complex MMIO instructions,
>> which
>> aren't even generated by recent guest kernels. I'm inclined to suggest
>> removing
>> this emulation code from KVM entirely given that it's likely to bitrot as
>> it is executed less and less often.
>
>
> That'd mean that you heavily limit what type of guests you're executing,
> which I don't think is a good idea.
>
It would limit legacy Linux kernels at least, but I think getting
KVM/ARM code in mainline is the highest priority, so if merging the
current code is unacceptable, I'm willing to drop the mmio emulation
for now and queue the task of unifying the code for later.
A bit of a shame (think about someone wanting to run some proprietary
custom OS in a VM), but this code has been out-of-tree for too long
already, and I'm afraid unifying the decoding pre-merge is going to
hold things up.
-Christoffer
^ permalink raw reply
* [PATCH v2 2/2] i2c: pxa: Use i2c-core to get bus number now
From: Doug Anderson @ 2013-01-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358189602-24180-1-git-send-email-dianders@chromium.org>
The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
present" adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v2:
- No longer tweak pdev->id as per Sylwester Nawrocki.
- No longer add the dev ID to the adap.name. Other drivers don't
include the device ID here and it doesn't make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(&dev->dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a board that uses this driver.
drivers/i2c/busses/i2c-pxa.c | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..705cc9f 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, &pdev->dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, "i2c");
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
- return ret;
- }
- pdev->id = ret;
+
+ /* For device tree we always use the dynamic or alias-assigned ID */
+ i2c->adap.nr = -1;
+
if (of_get_property(np, "mrvl,i2c-polling", NULL))
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
@@ -1100,6 +1097,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
goto emalloc;
}
+ /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
+ i2c->adap.nr = dev->id;
+
ret = i2c_pxa_probe_dt(dev, i2c, &i2c_type);
if (ret > 0)
ret = i2c_pxa_probe_pdata(dev, i2c, &i2c_type);
@@ -1124,9 +1124,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
spin_lock_init(&i2c->lock);
init_waitqueue_head(&i2c->wait);
- i2c->adap.nr = dev->id;
- snprintf(i2c->adap.name, sizeof(i2c->adap.name), "pxa_i2c-i2c.%u",
- i2c->adap.nr);
+ strlcpy(i2c->adap.name, "pxa_i2c-i2c", sizeof(i2c->adap.name));
i2c->clk = clk_get(&dev->dev, NULL);
if (IS_ERR(i2c->clk)) {
@@ -1169,7 +1167,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
} else {
i2c->adap.algo = &i2c_pxa_algorithm;
ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
- i2c->adap.name, i2c);
+ dev_name(&dev->dev), i2c);
if (ret)
goto ereqirq;
}
--
1.7.7.3
^ permalink raw reply related
* [PATCH v2 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
From: Doug Anderson @ 2013-01-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358189602-24180-1-git-send-email-dianders@chromium.org>
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = &i2c_0;
i2c1 = &i2c_1;
};
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
---
Changes in v2: None
drivers/i2c/i2c-core.c | 105 +++++++++++++++++++++++++++++++++++-------------
1 files changed, 77 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index e388590..a60ed6d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -921,13 +921,81 @@ out_list:
}
/**
+ * i2c_get_number_from_dt - get the adapter number based on dt alias
+ * @adap: the adapter to look at
+ *
+ * Check whether there's an alias in the FDT that gives an ID for this i2c
+ * device. Use an alias like "i2c<nr>", like:
+ * aliases {
+ * i2c0 = &i2c_0;
+ * i2c1 = &i2c_1;
+ * };
+ *
+ * Returns the ID if found. If no alias is found returns -1.
+ */
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
+{
+ struct device *dev = &adap->dev;
+ int id;
+
+ if (!dev->of_node)
+ return -1;
+
+ id = of_alias_get_id(dev->of_node, "i2c");
+ if (id < 0)
+ return -1;
+ return id;
+}
+
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap->nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap->nr == -1);
+
+ if (adap->nr & ~MAX_IDR_MASK)
+ return -EINVAL;
+
+retry:
+ if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ mutex_lock(&core_lock);
+ /* "above" here means "above or equal to", sigh;
+ * we need the "equal to" result to force the result
+ */
+ status = idr_get_new_above(&i2c_adapter_idr, adap, adap->nr, &id);
+ if (status == 0 && id != adap->nr) {
+ status = -EBUSY;
+ idr_remove(&i2c_adapter_idr, id);
+ }
+ mutex_unlock(&core_lock);
+ if (status == -EAGAIN)
+ goto retry;
+
+ if (status == 0)
+ status = i2c_register_adapter(adap);
+ return status;
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap->nr, and the specified adapter became available for clients.
@@ -937,6 +1005,12 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
{
int id, res = 0;
+ id = i2c_get_number_from_dt(adapter);
+ if (id >= 0) {
+ adapter->nr = id;
+ return _i2c_add_numbered_adapter(adapter);
+ }
+
retry:
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
return -ENOMEM;
@@ -983,34 +1057,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
- int status;
-
if (adap->nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap->nr & ~MAX_IDR_MASK)
- return -EINVAL;
-
-retry:
- if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
- return -ENOMEM;
-
- mutex_lock(&core_lock);
- /* "above" here means "above or equal to", sigh;
- * we need the "equal to" result to force the result
- */
- status = idr_get_new_above(&i2c_adapter_idr, adap, adap->nr, &id);
- if (status == 0 && id != adap->nr) {
- status = -EBUSY;
- idr_remove(&i2c_adapter_idr, id);
- }
- mutex_unlock(&core_lock);
- if (status == -EAGAIN)
- goto retry;
-
- if (status == 0)
- status = i2c_register_adapter(adap);
- return status;
+ return _i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.7.7.3
^ permalink raw reply related
* [PATCH v2 0/2] Add automatic bus number support for i2c busses with device tree
From: Doug Anderson @ 2013-01-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357927027-4857-2-git-send-email-dianders@chromium.org>
This was suggested by Mark Brown in response to a patch for adding
this functionality only for the s3c2410 bus:
https://lkml.org/lkml/2012/11/20/681
I have also modified the i2c-pxa driver to use this new functionality.
Changes in v2:
- No longer tweak pdev->id as per Sylwester Nawrocki.
- No longer add the dev ID to the adap.name. Other drivers don't
include the device ID here and it doesn't make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(&dev->dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a board that uses this driver.
Doug Anderson (2):
i2c-core: dt: Pick i2c bus number from i2c alias if present
i2c: pxa: Use i2c-core to get bus number now
drivers/i2c/busses/i2c-pxa.c | 20 ++++----
drivers/i2c/i2c-core.c | 105 ++++++++++++++++++++++++++++++-----------
2 files changed, 86 insertions(+), 39 deletions(-)
--
1.7.7.3
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox