* [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
* [kvmarm] [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Alexander Graf @ 2013-01-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114185038.GJ31341@mudshark.cambridge.arm.com>
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.
Alex
^ permalink raw reply
* [REPOST PATCH 2/2] i2c: pxa: Use i2c-core to get bus number now
From: Doug Anderson @ 2013-01-14 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F08E44.3050500@gmail.com>
Sylwester,
Thanks for the review...
On Fri, Jan 11, 2013 at 2:12 PM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
>> - 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;
>> + pdev->id = -1;
>
>
> I think assignments like this are illegal. At this point the device is
> already registered and modifying pdev->id can cause issues at the core
> code.
Good catch. I think the old code is just as illegal since it was also
assigning to pdev->id, but I'm happy to spin the patch.
> It might be better to have the bus number stored in struct pxa_i2c,
> initialized with pdev->id value for non-dt and now with -1 for dt case.
I'll just init i2c->adap.nr before calling i2c_pxa_probe_dt(). Then
i2c_pxa_probe_dt() can adjust the number. Hopefully this is OK.
> I realize it is not something your patch is intended to deal with,
> but since you're touching this code maybe it's worth to fix that issue
> as well ?
Sure, I've spun it. While doing this I realized a few other issues
relating to the ID number. Specifically:
* We were using the id (as %u) when creating 'i2c->adap.name'. This
probably gave a very nonsensical ID. I'm just going to remove the
device number from the adap.name. That matches what i2c-s3c2410.c
does. As far as I can tell the adap.name isn't actually used for
much.
* The name was being used in request_irq(). I've changed this to be
like i2c-s3c2410 and use dev_name(). On my current board that means
that the name comes from the table in of_platform_populate(). ...but
that table is supposed to be going away. If I remove that i2c parts
of that table I get names like '12c60000.i2c', which should be fine
for passing to request_irq().
-Doug
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Will Deacon @ 2013-01-14 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114184319.GN23505@n2100.arm.linux.org.uk>
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.
This doesn't solve the problem of having multiple people doing the same
thing, but at least we don't have one extra set of decoding logic for
arch/arm/ (even though the code itself is pretty clean).
Will
^ permalink raw reply
* [PATCH 07/16] ARM: bL_platsmp.c: close the kernel entry gate before hot-unplugging a CPU
From: Nicolas Pitre @ 2013-01-14 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114182604.GL23505@n2100.arm.linux.org.uk>
On Mon, 14 Jan 2013, Russell King - ARM Linux wrote:
> On Mon, Jan 14, 2013 at 12:15:07PM -0500, Nicolas Pitre wrote:
> > The same could be said about the outer cache ops. If a DSB is needed
> > for their intent to be valid, then why isn't this DSB always implied by
> > the corresponding cache op calls?
>
> Hmm, just been thinking about this.
>
> The L2x0 calls do contain a DSB but it's not obvious. They hold a
> raw spinlock, and when that spinlock is dropped, we issue a dsb and
> sev instruction.
>
> Whether the other L2 implementations do this or not I'm not sure -
> but the above is a requirement of the spinlock implementation, and
> it just happens to provide the right behaviour for L2x0.
>
> But... we _probably_ don't want to impose that down at the L2 cache
> level of things - at least not for DMA ops, particular for the sanity
> of the scatter-list operating operations. We really want to avoid
> doing one DSB per scatterlist entry, doing one DSB per scatterlist
> operation instead.
>
> That does affect how the L2 cache API gets used - maybe we want to
> separate out the DMA stuff from the other users so that we can have
> dsbs in that path for non-DMA users.
>
> Thoughts?
The dsb or its intended effect could be confined to outer_sync() and
then cache_sync() removed from l2x0_flush_range(). That would allow the
sync to be applied when appropriate. However that suffers the same API
intent mismatch I was talking about.
Maybe adding some asynchronous methods to outer_cache (that could
default to the synchronous calls) where the name of the function clearly
implies a posted operation would be a better solution. In that case the
effect of the operation would be assumed complete only after a
terminating outer_sync().
Nicolas
^ permalink raw reply
* [PATCH v5 03/14] KVM: ARM: Initial skeleton to compile KVM support
From: Gleb Natapov @ 2013-01-14 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130108183855.46302.40539.stgit@ubuntu>
A couple of general question about ABI. If they were already answered
just refer me to the previous discussion.
On Tue, Jan 08, 2013 at 01:38:55PM -0500, Christoffer Dall wrote:
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index a4df553..4237c27 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -293,7 +293,7 @@ kvm_run' (see below).
> 4.11 KVM_GET_REGS
>
> Capability: basic
> -Architectures: all
> +Architectures: all except ARM
> Type: vcpu ioctl
> Parameters: struct kvm_regs (out)
> Returns: 0 on success, -1 on error
> @@ -314,7 +314,7 @@ struct kvm_regs {
> 4.12 KVM_SET_REGS
>
> Capability: basic
> -Architectures: all
> +Architectures: all except ARM
> Type: vcpu ioctl
> Parameters: struct kvm_regs (in)
> Returns: 0 on success, -1 on error
> @@ -600,7 +600,7 @@ struct kvm_fpu {
> 4.24 KVM_CREATE_IRQCHIP
Why KVM_GET_REGS/KVM_SET_REGS are not usable for arm?
>
> Capability: KVM_CAP_IRQCHIP
> -Architectures: x86, ia64
> +Architectures: x86, ia64, ARM
> Type: vm ioctl
> Parameters: none
> Returns: 0 on success, -1 on error
> @@ -608,7 +608,8 @@ Returns: 0 on success, -1 on error
> Creates an interrupt controller model in the kernel. On x86, creates a virtual
> ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
> local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
> -only go to the IOAPIC. On ia64, a IOSAPIC is created.
> +only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM, a GIC is
> +created.
>
>
> 4.25 KVM_IRQ_LINE
> @@ -1775,6 +1776,14 @@ registers, find a list below:
> PPC | KVM_REG_PPC_VPA_DTL | 128
> PPC | KVM_REG_PPC_EPCR | 32
>
> +ARM registers are mapped using the lower 32 bits. The upper 16 of that
> +is the register group type, or coprocessor number:
> +
> +ARM core registers have the following id bit patterns:
> + 0x4002 0000 0010 <index into the kvm_regs struct:16>
> +
> +
> +
> 4.69 KVM_GET_ONE_REG
>
> Capability: KVM_CAP_ONE_REG
> @@ -2127,6 +2136,46 @@ written, then `n_invalid' invalid entries, invalidating any previously
> valid entries found.
>
>
> +4.77 KVM_ARM_VCPU_INIT
> +
> +Capability: basic
> +Architectures: arm
> +Type: vcpu ioctl
> +Parameters: struct struct kvm_vcpu_init (in)
> +Returns: 0 on success; -1 on error
> +Errors:
> + ?EINVAL: ???the target is unknown, or the combination of features is invalid.
> + ?ENOENT: ???a features bit specified is unknown.
> +
> +This tells KVM what type of CPU to present to the guest, and what
> +optional features it should have. ?This will cause a reset of the cpu
> +registers to their initial values. ?If this is not called, KVM_RUN will
> +return ENOEXEC for that vcpu.
> +
Can different vcpus of the same VM be of different type?
> +Note that because some registers reflect machine topology, all vcpus
> +should be created before this ioctl is invoked.
How cpu hot plug suppose to work?
> +
> +
> +4.78 KVM_GET_REG_LIST
> +
> +Capability: basic
> +Architectures: arm
> +Type: vcpu ioctl
> +Parameters: struct kvm_reg_list (in/out)
> +Returns: 0 on success; -1 on error
> +Errors:
> + ?E2BIG: ????the reg index list is too big to fit in the array specified by
> + ????????????the user (the number required will be written into n).
> +
> +struct kvm_reg_list {
> + __u64 n; /* number of registers in reg[] */
> + __u64 reg[0];
> +};
> +
> +This ioctl returns the guest registers that are supported for the
> +KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
> +
> +
Doesn't userspace know what registers are supported by each CPU type?
--
Gleb.
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Russell King - ARM Linux @ 2013-01-14 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qKASA_YML6L0KDHNsPShA+rfE2E=XXznqG4+dNn+939kg@mail.gmail.com>
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.
^ permalink raw reply
* OMAP baseline test results for v3.8-rc3
From: Aaro Koskinen @ 2013-01-14 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301141756460.20390@utopia.booyaka.com>
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.
Boot succeeds and fails randomly. Let's see if this can be bisected.
The same kernel works on N950.
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc3-n9xx (aaro at blackmetal) (gcc version 4.7.2 (GCC) ) #1 Sun Jan 13 16:01:49 EET 2013
[ 0.000000] Ignoring unrecognised tag 0x414f4d50
[ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[ 0.000000] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz
[ 0.000000] Kernel command line: console=tty console=ttyO2,115200
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Memory: 255MB = 255MB total
[ 0.000000] Memory: 246248k/246248k available, 15896k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc03d4fcc (3892 kB)
[ 0.000000] .init : 0xc03d5000 - 0xc0af9fc8 (7316 kB)
[ 0.000000] .data : 0xc0afa000 - 0xc0b31d20 ( 224 kB)
[ 0.000000] .bss : 0xc0b31d20 - 0xc0c4765c (1111 kB)
[ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[ 0.000000] Total of 96 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] console [tty0] enabled
[ 0.000885] Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384)
[ 0.054687] pid_max: default: 32768 minimum: 301
[ 0.054901] Mount-cache hash table entries: 512
[ 0.055633] CPU: Testing write buffer coherency: ok
[ 0.056091] Setting up static identity map for 0x802de0a8 - 0x802de100
[ 0.057189] devtmpfs: initialized
[ 0.064453] omap_hwmod: mcbsp2: cannot be enabled for reset (3)
[ 0.088714] pinctrl core: initialized pinctrl subsystem
[ 0.090179] regulator-dummy: no parameters
[ 0.090637] NET: Registered protocol family 16
[ 0.092132] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.092987] omap-gpmc omap-gpmc: GPMC revision 5.0
[ 0.097656] OMAP GPIO hardware version 2.5
[ 0.104827] omap_mux_init: Add partition: #1: core, flags: 4
[ 0.108581] Reprogramming SDRC clock to 332000000 Hz
[ 0.114715] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.121215] Reserving DMA channels 0 and 1 for HS ROM code
[ 0.121276] OMAP DMA hardware revision 4.0
[ 0.123168] arm-pmu: alias fck already exists
[ 0.142547] bio: create slab <bio-0> at 0
[ 0.181976] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[ 0.184570] SCSI subsystem initialized
[ 0.185150] usbcore: registered new interface driver usbfs
[ 0.185455] usbcore: registered new interface driver hub
[ 0.185821] usbcore: registered new device driver usb
[ 0.186492] musb-omap2430 musb-omap2430: invalid resource
[ 0.212890] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
[ 0.213073] twl 1-0048: power (irq 343) chaining IRQs 346..353
[ 0.214294] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
[ 1.226562] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 2.242187] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 2.242248] twl: Write failed (mod 2, reg 0x12 count 1)
[ 3.257812] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 3.257843] twl: Write failed (mod 2, reg 0x12 count 1)
[ 3.259277] VUSB1V5: 1500 mV normal standby
[ 4.273437] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 4.273498] twl: Write failed (mod 21, reg 0x73 count 1)
[ 4.274139] VUSB1V8: 1800 mV normal standby
[ 5.289062] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 5.289093] twl: Write failed (mod 21, reg 0x76 count 1)
[ 5.289764] VUSB3V1: 3100 mV normal standby
[ 6.304687] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 6.304718] twl: Write failed (mod 21, reg 0x79 count 1)
[ 7.320312] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 7.320373] twl: Write failed (mod 20, reg 0x0e count 1)
[ 8.335937] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 8.335968] twl: Write failed (mod 20, reg 0x0e count 1)
[ 9.351562] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 9.351593] twl: Write failed (mod 21, reg 0x7d count 1)
[ 10.367187] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 10.367218] twl: Write failed (mod 21, reg 0x77 count 1)
[ 11.382812] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 11.382843] twl: Write failed (mod 21, reg 0x78 count 1)
[ 12.398437] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 12.398468] twl: Write failed (mod 21, reg 0x71 count 1)
[ 13.414062] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 13.414093] twl: Write failed (mod 21, reg 0x72 count 1)
[ 14.429687] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 14.429718] twl: Write failed (mod 21, reg 0x74 count 1)
[ 15.445312] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 15.445343] twl: Write failed (mod 21, reg 0x75 count 1)
[ 16.460937] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 16.460968] twl: Write failed (mod 20, reg 0x0e count 1)
[ 17.476562] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 17.476593] twl: Write failed (mod 19, reg 0x01 count 1)
[ 17.476623] twl4030: twl4030_sih_bus_sync_unlock, write --> -110
[ 18.492187] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 18.492218] twl: Read failed (mod 19, reg 0x05 count 2)
[ 18.492248] twl4030: twl4030_sih_bus_sync_unlock, read --> -110
[ 19.507812] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 19.507843] twl: Read failed (mod 20, reg 0x0f count 1)
[ 19.507904] twl4030_usb twl4030_usb: USB link status err -110
[ 19.507965] twl4030_usb twl4030_usb: Initialized TWL4030 USB module
[ 20.523437] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 20.523498] twl: Read failed (mod 21, reg 0x2f count 1)
[ 21.539062] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 21.539093] twl: Write failed (mod 21, reg 0x32 count 1)
[ 21.539123] VPLL: failed to apply 1800000uV constraint
[ 21.539459] twl_reg twl_reg.4: can't register VPLL1, -110
[ 21.539520] twl_reg: probe of twl_reg.4 failed with error -110
[ 22.554687] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 22.554748] twl: Read failed (mod 21, reg 0x4b count 1)
[ 22.554779] VIO: failed to enable
[ 22.555053] twl_reg twl_reg.2: can't register VIO, -110
[ 22.555114] twl_reg: probe of twl_reg.2 failed with error -110
[ 22.555755] vdd_mpu_iva: 600 <--> 1450 mV normal
[ 23.570312] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 23.570343] twl: Write failed (mod 21, reg 0x57 count 1)
[ 23.571014] vdd_core: 600 <--> 1450 mV normal
[ 24.585937] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 24.585968] twl: Write failed (mod 21, reg 0x65 count 1)
[ 25.601562] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 25.601623] twl: Read failed (mod 21, reg 0x2a count 1)
[ 25.601654] VMMC1: 1850 <--> 3150 mV normal standby
[ 26.617187] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 26.617218] twl: Read failed (mod 21, reg 0x2a count 1)
[ 27.632812] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 27.632843] twl: Write failed (mod 21, reg 0x29 count 1)
[ 28.648437] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 28.648468] twl: Read failed (mod 21, reg 0x3b count 1)
[ 29.664062] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 29.664093] twl: Write failed (mod 21, reg 0x3e count 1)
[ 29.664123] VDAC: failed to apply 1800000uV constraint
[ 29.664428] twl_reg twl_reg.3: can't register VDAC, -110
[ 29.664489] twl_reg: probe of twl_reg.3 failed with error -110
[ 29.665130] VCSI: 1800 mV normal standby
[ 30.679687] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 30.679718] twl: Read failed (mod 21, reg 0x1e count 1)
[ 31.695312] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 31.695343] twl: Write failed (mod 21, reg 0x1d count 1)
[ 32.710937] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 32.710998] twl: Read failed (mod 21, reg 0x3f count 1)
[ 32.711029] VINTANA1: failed to enable
[ 32.711303] twl_reg twl_reg.14: can't register VINTANA1, -110
[ 32.711364] twl_reg: probe of twl_reg.14 failed with error -110
[ 33.726562] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 33.726623] twl: Read failed (mod 21, reg 0x43 count 1)
[ 34.742187] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 34.742218] twl: Write failed (mod 21, reg 0x46 count 1)
[ 34.742248] VINTANA2: failed to apply 2750000uV constraint
[ 34.742553] twl_reg twl_reg.15: can't register VINTANA2, -110
[ 34.742614] twl_reg: probe of twl_reg.15 failed with error -110
[ 35.757812] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 35.757843] twl: Read failed (mod 21, reg 0x47 count 1)
[ 35.757873] VINTDIG: failed to enable
[ 35.758178] twl_reg twl_reg.16: can't register VINTDIG, -110
[ 35.758209] twl_reg: probe of twl_reg.16 failed with error -110
[ 36.773437] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 36.773468] twl: Read failed (mod 21, reg 0x33 count 1)
[ 37.789062] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 37.789093] twl: Write failed (mod 21, reg 0x36 count 1)
[ 37.789123] VSDI_CSI: failed to apply 1800000uV constraint
[ 37.789428] twl_reg twl_reg.5: can't register VPLL2, -110
[ 37.789459] twl_reg: probe of twl_reg.5 failed with error -110
[ 38.804687] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 38.804718] twl: Read failed (mod 21, reg 0x2b count 1)
[ 38.804748] V28_A: failed to enable
[ 38.805053] twl_reg twl_reg.7: can't register VMMC2, -110
[ 38.805084] twl_reg: probe of twl_reg.7 failed with error -110
[ 39.820312] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 39.820343] twl: Read failed (mod 21, reg 0x37 count 1)
[ 40.835937] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 40.835968] twl: Write failed (mod 21, reg 0x3a count 1)
[ 40.835998] VMMC2_IO_18: failed to apply 1800000uV constraint
[ 40.836303] twl_reg twl_reg.8: can't register VSIM, -110
[ 40.836364] twl_reg: probe of twl_reg.8 failed with error -110
[ 41.851562] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 41.851623] twl: Read failed (mod 21, reg 0x17 count 1)
[ 41.851623] V28: failed to enable
[ 41.851928] twl_reg twl_reg.9: can't register VAUX1, -110
[ 41.851959] twl_reg: probe of twl_reg.9 failed with error -110
[ 42.867187] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 42.867218] twl: Read failed (mod 21, reg 0x22 count 1)
[ 42.867279] VMMC2_30: 2800 <--> 3000 mV normal standby
[ 43.882812] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 43.882843] twl: Read failed (mod 21, reg 0x22 count 1)
[ 44.898437] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 44.898468] twl: Write failed (mod 21, reg 0x21 count 1)
[ 45.914062] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 45.914123] twl: Read failed (mod 21, reg 0x23 count 1)
[ 46.929687] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 46.929718] twl: Write failed (mod 21, reg 0x26 count 1)
[ 46.929748] VCAM_ANA_28: failed to apply 2800000uV constraint
[ 46.930053] twl_reg twl_reg.13: can't register VAUX4, -110
[ 46.930114] twl_reg: probe of twl_reg.13 failed with error -110
[ 46.930175] omap_i2c omap_i2c.1: bus 1 rev3.3 at 2200 kHz
[ 46.932159] omap_i2c omap_i2c.2: bus 2 rev3.3 at 100 kHz
[ 46.932830] omap_i2c omap_i2c.3: bus 3 rev3.3 at 400 kHz
[ 46.935821] Switching to clocksource 32k_counter
[ 46.962829] NET: Registered protocol family 2
[ 46.963562] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[ 46.963684] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 46.963745] TCP: Hash tables configured (established 2048 bind 2048)
[ 46.963897] TCP: reno registered
[ 46.963958] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 46.963989] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 47.036743] CPU PMU: probing PMU on CPU 0
[ 47.036804] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 47.399627] msgmni has been set to 480
[ 47.408660] io scheduler noop registered
[ 47.409759] io scheduler cfq registered (default)
[ 47.435668] OMAP DSS rev 2.0
[ 47.446533] omapdss SDI error: can't get VDDS_SDI regulator
[ 47.446624] omapdss SDI error: device lcd init failed: -517
[ 47.457244] omapdss VENC error: can't get VDDA_DAC regulator
[ 47.457305] omapdss VENC error: device tv init failed: -517
[ 47.477661] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 47.513946] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0
[ 47.519775] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1
[ 47.525665] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2
[ 48.804534] console [ttyO2] enabled
[ 48.844818] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 48.861083] OneNAND driver initializing
[ 48.865600] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0880000, freq 66 MHz
[ 48.876953] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 48.882049] OneNAND version = 0x0121
[ 48.887603] Scanning device for bad blocks
[ 48.970550] OneNAND eraseblock 1229 is an initial bad block
[ 49.033142] Creating 6 MTD partitions on "omap2-onenand":
[ 49.039001] 0x000000000000-0x000000020000 : "bootloader"
[ 49.061614] 0x000000020000-0x000000080000 : "config"
[ 49.087982] 0x000000080000-0x0000000c0000 : "log"
[ 49.114257] 0x0000000c0000-0x0000002c0000 : "kernel"
[ 49.140106] 0x0000002c0000-0x0000004c0000 : "initfs"
[ 49.167175] 0x0000004c0000-0x000010000000 : "rootfs"
[ 49.209228] omap-dma-engine omap-dma-engine: allocating channel for 40
[ 49.216247] omap-dma-engine omap-dma-engine: allocating channel for 39
[ 49.228393] omap-dma-engine omap-dma-engine: allocating channel for 36
[ 49.235382] omap-dma-engine omap-dma-engine: allocating channel for 35
[ 49.263488] omap-dma-engine omap-dma-engine: allocating channel for 71
[ 49.270507] omap-dma-engine omap-dma-engine: allocating channel for 70
[ 49.283508] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[ 49.315521] mousedev: PS/2 mouse device common for all mice
[ 49.332122] input: TWL4030 Keypad as /devices/platform/omap_i2c.1/i2c-1/1-004a/twl4030_keypad/input/input0
[ 49.369415] input: TSC2005 touchscreen as /devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/input/input1
My test defconfig (cp to .config && make oldnoconfig):
CONFIG_EXPERIMENTAL=y
CONFIG_LOCALVERSION="-n9xx"
CONFIG_KERNEL_LZMA=y
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
CONFIG_EXPERT=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_ARCH_OMAP=y
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX_DEBUG=y
# CONFIG_MACH_OMAP_GENERIC is not set
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_TI81XX is not set
# CONFIG_SOC_AM33XX is not set
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OMAP3530_LV_SOM is not set
# CONFIG_MACH_OMAP3_TORPEDO is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
# CONFIG_MACH_OMAP_ZOOM3 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_CM_T3517 is not set
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_IGEP0030 is not set
# CONFIG_MACH_SBC3530 is not set
# CONFIG_MACH_OMAP_3630SDP is not set
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=tty console=ttyO2,115200"
CONFIG_CMDLINE_FORCE=y
CONFIG_KEXEC=y
CONFIG_BINFMT_MISC=y
CONFIG_PM_DEBUG=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_INET=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_IPV6 is not set
# CONFIG_WIRELESS is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_OF_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_OOPS=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_OMAP2=y
CONFIG_MTD_UBI=y
# CONFIG_BLK_DEV is not set
CONFIG_EEPROM_93CX6=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_TWL4030=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
CONFIG_TOUCHSCREEN_TSC2005=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_TWL4030_PWRBUTTON=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_HW_RANDOM=y
CONFIG_I2C_CHARDEV=y
CONFIG_SPI=y
CONFIG_SPI_OMAP24XX=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_TWL4030=y
CONFIG_W1=y
CONFIG_POWER_SUPPLY=y
CONFIG_WATCHDOG=y
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_OMAP2_DSS=y
# CONFIG_OMAP2_DSS_DPI is not set
CONFIG_OMAP2_DSS_SDI=y
CONFIG_FB_OMAP2=m
# CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
CONFIG_PANEL_ACX565AKM=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
# CONFIG_LOGO_LINUX_CLUT224 is not set
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_OTG=y
# CONFIG_USB_OTG_WHITELIST is not set
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MUSB_PIO_ONLY=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
CONFIG_TWL4030_USB=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_MMC=y
CONFIG_MMC_UNSAFE_RESUME=y
CONFIG_SDIO_UART=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_TWL4030=y
CONFIG_DMADEVICES=y
CONFIG_DMA_OMAP=y
# CONFIG_FILE_LOCKING is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
CONFIG_TMPFS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
CONFIG_CRC16=y
A.
^ permalink raw reply
* [PATCH v2] gpio: vt8500: memory cleanup missing
From: Tony Prisk @ 2013-01-14 18:37 UTC (permalink / raw)
To: linux-arm-kernel
This driver is missing a .remove callback, and the fail path on
probe is incomplete.
If an error occurs in vt8500_add_chips, gpio_base is not unmapped.
The driver is also ignoring the return value from this function so
if a chip fails to register it completes as successful.
Replaced pr_err with dev_err in vt8500_add_chips since the device is
available.
There is also no .remove callback defined. To allow removing the
registered chips, I have moved *vtchip to be a static global.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
Hi Grant,
Let me know what you think of these changes.
v2:
Removed unnecessary whitespace change.
Removed test against pdev->dev.of_node (np). Replaced code with a
devm_request_and_ioremap so np is now unneccessary. This also removes the need
for cleanup in the fail path.
Move struct vt8500_gpio_chip within vt8500_data and store the iobase and
num_banks in vt8500_data.
drivers/gpio/gpio-vt8500.c | 61 +++++++++++++++++++++++++++++++++++---------
1 file changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
index b53320a..5c8cd7c 100644
--- a/drivers/gpio/gpio-vt8500.c
+++ b/drivers/gpio/gpio-vt8500.c
@@ -127,6 +127,12 @@ struct vt8500_gpio_chip {
void __iomem *base;
};
+struct vt8500_data {
+ struct vt8500_gpio_chip *chip;
+ void __iomem *iobase;
+ int num_banks;
+};
+
#define to_vt8500(__chip) container_of(__chip, struct vt8500_gpio_chip, chip)
@@ -224,19 +230,32 @@ static int vt8500_of_xlate(struct gpio_chip *gc,
static int vt8500_add_chips(struct platform_device *pdev, void __iomem *base,
const struct vt8500_gpio_data *data)
{
+ struct vt8500_data *priv;
struct vt8500_gpio_chip *vtchip;
struct gpio_chip *chip;
int i;
int pin_cnt = 0;
- vtchip = devm_kzalloc(&pdev->dev,
+ priv = devm_kzalloc(&pdev->dev, sizeof(struct vt8500_data), GFP_KERNEL);
+ if (!priv) {
+ dev_err(&pdev->dev, "failed to allocate memory\n");
+ return -ENOMEM;
+ }
+
+ priv->chip = devm_kzalloc(&pdev->dev,
sizeof(struct vt8500_gpio_chip) * data->num_banks,
GFP_KERNEL);
- if (!vtchip) {
- pr_err("%s: failed to allocate chip memory\n", __func__);
+ if (!priv->chip) {
+ dev_err(&pdev->dev, "failed to allocate chip memory\n");
return -ENOMEM;
}
+ priv->iobase = base;
+ priv->num_banks = data->num_banks;
+ platform_set_drvdata(pdev, priv);
+
+ vtchip = priv->chip;
+
for (i = 0; i < data->num_banks; i++) {
vtchip[i].base = base;
vtchip[i].regs = &data->banks[i];
@@ -273,36 +292,54 @@ static struct of_device_id vt8500_gpio_dt_ids[] = {
static int vt8500_gpio_probe(struct platform_device *pdev)
{
+ int ret;
void __iomem *gpio_base;
- struct device_node *np;
+ struct resource *res;
const struct of_device_id *of_id =
of_match_device(vt8500_gpio_dt_ids, &pdev->dev);
if (!of_id) {
- dev_err(&pdev->dev, "Failed to find gpio controller\n");
+ dev_err(&pdev->dev, "No matching driver data\n");
return -ENODEV;
}
- np = pdev->dev.of_node;
- if (!np) {
- dev_err(&pdev->dev, "Missing GPIO description in devicetree\n");
- return -EFAULT;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Unable to get IO resource\n");
+ return -ENODEV;
}
- gpio_base = of_iomap(np, 0);
+ gpio_base = devm_request_and_ioremap(&pdev->dev, res);
if (!gpio_base) {
dev_err(&pdev->dev, "Unable to map GPIO registers\n");
- of_node_put(np);
return -ENOMEM;
}
- vt8500_add_chips(pdev, gpio_base, of_id->data);
+ ret = vt8500_add_chips(pdev, gpio_base, of_id->data);
+
+ return ret;
+}
+
+static int vt8500_gpio_remove(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct vt8500_data *priv = platform_get_drvdata(pdev);
+ struct vt8500_gpio_chip *vtchip = priv->chip;
+
+ for (i = 0; i < priv->num_banks; i++) {
+ ret = gpiochip_remove(&vtchip[i].chip);
+ if (ret)
+ dev_warn(&pdev->dev, "gpiochip_remove returned %d\n",
+ ret);
+ }
return 0;
}
static struct platform_driver vt8500_gpio_driver = {
.probe = vt8500_gpio_probe,
+ .remove = vt8500_gpio_remove,
.driver = {
.name = "vt8500-gpio",
.owner = THIS_MODULE,
--
1.7.9.5
^ permalink raw reply related
* [PATCH] clk: tegra: use _clk_pll_disable from _program_pll
From: Stephen Warren @ 2013-01-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
_program_pll() was dropping the PLL's lock and calling clk_pll_disable().
clk_pll_disable() does nothing but acquire the same lock and call
_clk_pll_disable(). So, remove the lock manipulation code, and just call
_clk_pll_disable() directly instead.
Reported-by: Sivaram Nair <sivaramn@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Mike, this also will need to go through the Tegra tree; just looking for
any review/ack from you. Thanks.
drivers/clk/tegra/clk-pll.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 474ce1f..9f9bb73 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -339,14 +339,8 @@ static int _program_pll(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
state = clk_pll_is_enabled(hw);
if (state) {
- if (pll->lock)
- spin_unlock_irqrestore(pll->lock, flags);
-
- clk_pll_disable(hw);
+ _clk_pll_disable(hw);
val &= ~(PLL_BASE_BYPASS | PLL_BASE_ENABLE);
-
- if (pll->lock)
- spin_lock_irqsave(pll->lock, flags);
}
pll_writel_base(val, pll);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v5 08/14] KVM: ARM: Emulation framework and CP15 emulation
From: Russell King - ARM Linux @ 2013-01-14 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qJpbrOsDcDmcGJp6fogLZHCFxghDg6zMXyt8jaXzm1QsA@mail.gmail.com>
On Mon, Jan 14, 2013 at 12:38:17PM -0500, Christoffer Dall wrote:
> On Mon, Jan 14, 2013 at 11:36 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 08, 2013 at 01:39:31PM -0500, Christoffer Dall wrote:
> >> + /*
> >> + * Check whether this vcpu requires the cache to be flushed on
> >> + * this physical CPU. This is a consequence of doing dcache
> >> + * operations by set/way on this vcpu. We do it here to be in
> >> + * a non-preemptible section.
> >> + */
> >> + if (cpumask_test_cpu(cpu, &vcpu->arch.require_dcache_flush)) {
> >> + cpumask_clear_cpu(cpu, &vcpu->arch.require_dcache_flush);
> >
> > There is cpumask_test_and_clear_cpu() which may be better for this.
>
> nice:
>
> commit d31686fadb74ad564f6a5acabdebe411de86d77d
> Author: Christoffer Dall <c.dall@virtualopensystems.com>
> Date: Mon Jan 14 12:36:53 2013 -0500
>
> KVM: ARM: Use cpumask_test_and_clear_cpu
>
> Nicer shorter cleaner code. Ahhhh.
>
> Cc: Russell King <linux@arm.linux.org.uk>
Great, thanks.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index b5c6ab1..fdd4a7c 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -352,10 +352,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> * operations by set/way on this vcpu. We do it here to be in
> * a non-preemptible section.
> */
> - if (cpumask_test_cpu(cpu, &vcpu->arch.require_dcache_flush)) {
> - cpumask_clear_cpu(cpu, &vcpu->arch.require_dcache_flush);
> + if (cpumask_test_and_clear_cpu(cpu, &vcpu->arch.require_dcache_flush))
> flush_cache_all(); /* We'd really want v7_flush_dcache_all() */
> - }
>
> kvm_arm_set_running_vcpu(vcpu);
> }
>
> --
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH 07/16] ARM: bL_platsmp.c: close the kernel entry gate before hot-unplugging a CPU
From: Russell King - ARM Linux @ 2013-01-14 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301141207360.6300@xanadu.home>
On Mon, Jan 14, 2013 at 12:15:07PM -0500, Nicolas Pitre wrote:
> The same could be said about the outer cache ops. If a DSB is needed
> for their intent to be valid, then why isn't this DSB always implied by
> the corresponding cache op calls?
Hmm, just been thinking about this.
The L2x0 calls do contain a DSB but it's not obvious. They hold a
raw spinlock, and when that spinlock is dropped, we issue a dsb and
sev instruction.
Whether the other L2 implementations do this or not I'm not sure -
but the above is a requirement of the spinlock implementation, and
it just happens to provide the right behaviour for L2x0.
But... we _probably_ don't want to impose that down at the L2 cache
level of things - at least not for DMA ops, particular for the sanity
of the scatter-list operating operations. We really want to avoid
doing one DSB per scatterlist entry, doing one DSB per scatterlist
operation instead.
That does affect how the L2 cache API gets used - maybe we want to
separate out the DMA stuff from the other users so that we can have
dsbs in that path for non-DMA users.
Thoughts?
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Christoffer Dall @ 2013-01-14 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114164326.GH23505@n2100.arm.linux.org.uk>
On Mon, Jan 14, 2013 at 11:43 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 08, 2013 at 01:40:05PM -0500, Christoffer Dall wrote:
>> diff --git a/arch/arm/kvm/decode.c b/arch/arm/kvm/decode.c
>> new file mode 100644
>> index 0000000..469cf14
>> --- /dev/null
>> +++ b/arch/arm/kvm/decode.c
>> @@ -0,0 +1,462 @@
>> +/*
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall@virtualopensystems.com>
>> + *
>> + * 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.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
>> + */
>> +#include <linux/kvm_host.h>
>> +#include <asm/kvm_mmio.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_decode.h>
>> +#include <trace/events/kvm.h>
>> +
>> +#include "trace.h"
>> +
>> +struct arm_instr {
>> + /* Instruction decoding */
>> + u32 opc;
>> + u32 opc_mask;
>> +
>> + /* Decoding for the register write back */
>> + bool register_form;
>> + u32 imm;
>> + u8 Rm;
>> + u8 type;
>> + u8 shift_n;
>> +
>> + /* Common decoding */
>> + u8 len;
>> + bool sign_extend;
>> + bool w;
>> +
>> + bool (*decode)(struct kvm_decode *decode, struct kvm_exit_mmio *mmio,
>> + unsigned long instr, struct arm_instr *ai);
>> +};
>> +
>> +enum SRType {
>> + SRType_LSL,
>> + SRType_LSR,
>> + SRType_ASR,
>> + SRType_ROR,
>> + SRType_RRX
>> +};
>> +
>> +/* Modelled after DecodeImmShift() in the ARM ARM */
>> +static enum SRType decode_imm_shift(u8 type, u8 imm5, u8 *amount)
>> +{
>> + switch (type) {
>> + case 0x0:
>> + *amount = imm5;
>> + return SRType_LSL;
>> + case 0x1:
>> + *amount = (imm5 == 0) ? 32 : imm5;
>> + return SRType_LSR;
>> + case 0x2:
>> + *amount = (imm5 == 0) ? 32 : imm5;
>> + return SRType_ASR;
>> + case 0x3:
>> + if (imm5 == 0) {
>> + *amount = 1;
>> + return SRType_RRX;
>> + } else {
>> + *amount = imm5;
>> + return SRType_ROR;
>> + }
>> + }
>> +
>> + return SRType_LSL;
>> +}
>> +
>> +/* Modelled after Shift() in the ARM ARM */
>> +static u32 shift(u32 value, u8 N, enum SRType type, u8 amount, bool carry_in)
>> +{
>> + u32 mask = (1 << N) - 1;
>> + s32 svalue = (s32)value;
>> +
>> + BUG_ON(N > 32);
>> + BUG_ON(type == SRType_RRX && amount != 1);
>> + BUG_ON(amount > N);
>> +
>> + if (amount == 0)
>> + return value;
>> +
>> + switch (type) {
>> + case SRType_LSL:
>> + value <<= amount;
>> + break;
>> + case SRType_LSR:
>> + value >>= amount;
>> + break;
>> + case SRType_ASR:
>> + if (value & (1 << (N - 1)))
>> + svalue |= ((-1UL) << N);
>> + value = svalue >> amount;
>> + break;
>> + case SRType_ROR:
>> + value = (value >> amount) | (value << (N - amount));
>> + break;
>> + case SRType_RRX: {
>> + u32 C = (carry_in) ? 1 : 0;
>> + value = (value >> 1) | (C << (N - 1));
>> + break;
>> + }
>> + }
>> +
>> + return value & mask;
>> +}
>> +
>> +static bool decode_arm_wb(struct kvm_decode *decode, struct kvm_exit_mmio *mmio,
>> + unsigned long instr, const struct arm_instr *ai)
>> +{
>> + u8 Rt = (instr >> 12) & 0xf;
>> + u8 Rn = (instr >> 16) & 0xf;
>> + u8 W = (instr >> 21) & 1;
>> + u8 U = (instr >> 23) & 1;
>> + u8 P = (instr >> 24) & 1;
>> + u32 base_addr = *kvm_decode_reg(decode, Rn);
>> + u32 offset_addr, offset;
>> +
>> + /*
>> + * Technically this is allowed in certain circumstances,
>> + * but we don't support it.
>> + */
>> + if (Rt == 15 || Rn == 15)
>> + return false;
>> +
>> + if (P && !W) {
>> + kvm_err("Decoding operation with valid ISV?\n");
>> + return false;
>> + }
>> +
>> + decode->rt = Rt;
>> +
>> + if (ai->register_form) {
>> + /* Register operation */
>> + enum SRType s_type;
>> + u8 shift_n = 0;
>> + bool c_bit = *kvm_decode_cpsr(decode) & PSR_C_BIT;
>> + u32 s_reg = *kvm_decode_reg(decode, ai->Rm);
>> +
>> + s_type = decode_imm_shift(ai->type, ai->shift_n, &shift_n);
>> + offset = shift(s_reg, 5, s_type, shift_n, c_bit);
>> + } else {
>> + /* Immediate operation */
>> + offset = ai->imm;
>> + }
>> +
>> + /* Handle Writeback */
>> + if (U)
>> + offset_addr = base_addr + offset;
>> + else
>> + offset_addr = base_addr - offset;
>> + *kvm_decode_reg(decode, Rn) = offset_addr;
>> + return true;
>> +}
>> +
>> +static bool decode_arm_ls(struct kvm_decode *decode, struct kvm_exit_mmio *mmio,
>> + unsigned long instr, struct arm_instr *ai)
>> +{
>> + u8 A = (instr >> 25) & 1;
>> +
>> + mmio->is_write = ai->w;
>> + mmio->len = ai->len;
>> + decode->sign_extend = false;
>> +
>> + ai->register_form = A;
>> + ai->imm = instr & 0xfff;
>> + ai->Rm = instr & 0xf;
>> + ai->type = (instr >> 5) & 0x3;
>> + ai->shift_n = (instr >> 7) & 0x1f;
>> +
>> + return decode_arm_wb(decode, mmio, instr, ai);
>> +}
>> +
>> +static bool decode_arm_extra(struct kvm_decode *decode,
>> + struct kvm_exit_mmio *mmio,
>> + unsigned long instr, struct arm_instr *ai)
>> +{
>> + mmio->is_write = ai->w;
>> + mmio->len = ai->len;
>> + decode->sign_extend = ai->sign_extend;
>> +
>> + ai->register_form = !((instr >> 22) & 1);
>> + ai->imm = ((instr >> 4) & 0xf0) | (instr & 0xf);
>> + ai->Rm = instr & 0xf;
>> + ai->type = 0; /* SRType_LSL */
>> + ai->shift_n = 0;
>> +
>> + return decode_arm_wb(decode, mmio, instr, ai);
>> +}
>> +
>> +/*
>> + * The encodings in this table assumes that a fault was generated where the
>> + * ISV field in the HSR was clear, and the decoding information was invalid,
>> + * which means that a register write-back occurred, the PC was used as the
>> + * destination or a load/store multiple operation was used. Since the latter
>> + * two cases are crazy for MMIO on the guest side, we simply inject a fault
>> + * when this happens and support the common case.
>> + *
>> + * We treat unpriviledged loads and stores of words and bytes like all other
>> + * loads and stores as their encodings mandate the W bit set and the P bit
>> + * clear.
>> + */
>> +static const struct arm_instr arm_instr[] = {
>> + /**************** Load/Store Word and Byte **********************/
>> + /* Store word with writeback */
>> + { .opc = 0x04000000, .opc_mask = 0x0c500000, .len = 4, .w = true,
>> + .sign_extend = false, .decode = decode_arm_ls },
>> + /* Store byte with writeback */
>> + { .opc = 0x04400000, .opc_mask = 0x0c500000, .len = 1, .w = true,
>> + .sign_extend = false, .decode = decode_arm_ls },
>> + /* Load word with writeback */
>> + { .opc = 0x04100000, .opc_mask = 0x0c500000, .len = 4, .w = false,
>> + .sign_extend = false, .decode = decode_arm_ls },
>> + /* Load byte with writeback */
>> + { .opc = 0x04500000, .opc_mask = 0x0c500000, .len = 1, .w = false,
>> + .sign_extend = false, .decode = decode_arm_ls },
>> +
>> + /*************** Extra load/store instructions ******************/
>> +
>> + /* Store halfword with writeback */
>> + { .opc = 0x000000b0, .opc_mask = 0x0c1000f0, .len = 2, .w = true,
>> + .sign_extend = false, .decode = decode_arm_extra },
>> + /* Load halfword with writeback */
>> + { .opc = 0x001000b0, .opc_mask = 0x0c1000f0, .len = 2, .w = false,
>> + .sign_extend = false, .decode = decode_arm_extra },
>> +
>> + /* Load dual with writeback */
>> + { .opc = 0x000000d0, .opc_mask = 0x0c1000f0, .len = 8, .w = false,
>> + .sign_extend = false, .decode = decode_arm_extra },
>> + /* Load signed byte with writeback */
>> + { .opc = 0x001000d0, .opc_mask = 0x0c1000f0, .len = 1, .w = false,
>> + .sign_extend = true, .decode = decode_arm_extra },
>> +
>> + /* Store dual with writeback */
>> + { .opc = 0x000000f0, .opc_mask = 0x0c1000f0, .len = 8, .w = true,
>> + .sign_extend = false, .decode = decode_arm_extra },
>> + /* Load signed halfword with writeback */
>> + { .opc = 0x001000f0, .opc_mask = 0x0c1000f0, .len = 2, .w = false,
>> + .sign_extend = true, .decode = decode_arm_extra },
>> +
>> + /* Store halfword unprivileged */
>> + { .opc = 0x002000b0, .opc_mask = 0x0f3000f0, .len = 2, .w = true,
>> + .sign_extend = false, .decode = decode_arm_extra },
>> + /* Load halfword unprivileged */
>> + { .opc = 0x003000b0, .opc_mask = 0x0f3000f0, .len = 2, .w = false,
>> + .sign_extend = false, .decode = decode_arm_extra },
>> + /* Load signed byte unprivileged */
>> + { .opc = 0x003000d0, .opc_mask = 0x0f3000f0, .len = 1, .w = false,
>> + .sign_extend = true , .decode = decode_arm_extra },
>> + /* Load signed halfword unprivileged */
>> + { .opc = 0x003000d0, .opc_mask = 0x0f3000f0, .len = 2, .w = false,
>> + .sign_extend = true , .decode = decode_arm_extra },
>
> So here, yet again, we end up with more code decoding the ARM load/store
> instructions so that we can do something with them. How many places do
> we now have in the ARM kernel doing this exact same thing? Do we really
> need to keep rewriting this functionality each time a feature that needs
> it gets implemented, or is _someone_ going to sort this out once and for
> all?
Hi Russell,
This was indeed discussed a couple of time already, and I hear your concern.
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.
Therefore I tried writing the decoding up in a way, which was not too
KVM specific, but without adding a lot of code paths to decode
instructions that were never going to be decoded by KVM and thus
trying to avoid having untested code in the kernel.
I really hope that this will not hold up the KVM patches right now, as
unifying the decoding would not break any external APIs when doing it
later. Maintaining these patches out-of-tree is placing an
increasingly large burden on both me and Marc Zyngier especially, and
more and more people are requesting the KVM functionality.
That being said, I do like the though of having a complete solution
for instruction decoding in the kernel, and if I in any way can find
time down the road, I'd be happy taking part in writing this code,
especially if I receive help from people knowing the other potential
subsystems benefiting from such code.
So, I would go as far as to beg you to accept this code as part of the
KVM/ARM implementation with the promise that I *will* help out or take
charge later on in a unifying effort if in any way possible for me?
Best,
-Christoffer
^ permalink raw reply
* [PATCH] clk: tegra: ensure all provided clock values are valid cookies
From: Stephen Warren @ 2013-01-14 18:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Tegra's clock implementation uses pointers as the clock cookies, and
hence chooses to make NULL an invalid clock cookie. However, there are
gaps in the assigned device tree clock IDs, and hence the array mapping
DT clock ID contains entries with NULL values (uninitialized BSS) unless
explicit action is taken. This patch enhances the Tegra clock code to
detect this case and explicitly initialize those lookup table entries to
an error value. This prevents clk_get() from ever returning NULL. Hence,
Tegra's clock APIs don't have to check the clock cookie they're passed
for NULL.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Mike, this also will need to go through the Tegra tree; just looking for
any review/ack from you. Thanks.
drivers/clk/tegra/clk-tegra20.c | 5 ++++-
drivers/clk/tegra/clk-tegra30.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 5847b5e..e59ac14 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1243,12 +1243,15 @@ void __init tegra20_clock_init(struct device_node *np)
tegra20_audio_clk_init();
- for (i = 0; i < ARRAY_SIZE(clks); i++)
+ for (i = 0; i < ARRAY_SIZE(clks); i++) {
if (IS_ERR(clks[i])) {
pr_err("Tegra20 clk %d: register failed with %ld\n",
i, PTR_ERR(clks[i]));
BUG();
}
+ if (!clks[i])
+ clks[i] = ERR_PTR(-EINVAL);
+ }
tegra_init_dup_clks(tegra_clk_duplicates, clks, clk_max);
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 987312c..9c0b2ee 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -2022,12 +2022,15 @@ void __init tegra30_clock_init(struct device_node *np)
tegra30_audio_clk_init();
tegra30_pmc_clk_init();
- for (i = 0; i < ARRAY_SIZE(clks); i++)
+ for (i = 0; i < ARRAY_SIZE(clks); i++) {
if (IS_ERR(clks[i])) {
pr_err("Tegra30 clk %d: register failed with %ld\n",
i, PTR_ERR(clks[i]));
BUG();
}
+ if (!clks[i])
+ clks[i] = ERR_PTR(-EINVAL);
+ }
tegra_init_dup_clks(tegra_clk_duplicates, clks, clk_max);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 0/3] Use helper clockevents_config_and_register()
From: Olof Johansson @ 2013-01-14 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301141222130.7475@ionos>
On Mon, Jan 14, 2013 at 12:23:16PM +0100, Thomas Gleixner wrote:
> On Sat, 12 Jan 2013, Arnd Bergmann wrote:
> > On Saturday 12 January 2013, Shawn Guo wrote:
> > > The clockevent core is able to figure out the best mult and shift,
> > > calculate min_delta_ns and max_delta_ns, with the necessary info passed
> > > into clockevents_config_and_register(). Use this handy helper to make
> > > the drivers less error prone and save some LOC.
> > >
> > > Changes since v1:
> > > - Add one patch to export clockevents_config_and_register for fixing
> > > the error [1] reported by Fengguang.
> > > - Add Acked-by and Tested-by tags given by people (Thanks!)
> > >
> > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/209152
> >
> > Very nice series!
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>
> Arnd, can you take the whole lot via the ARM tree? The export should
> not cause any conflicts, and if it does Linus should be able to solve
> it :)
(with the presumed s/Arnd/Arnd or Olof/)
Great! I've applied these to a clockevent/cleanup topic branch in arm-soc,
together with the added acks, etc.
-Olof
^ permalink raw reply
* [PATCH] ARM: at91: fix board-rm9200-dt after sys_timer conversion
From: Olof Johansson @ 2013-01-14 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358185342-7518-1-git-send-email-swarren@wwwdotorg.org>
On Mon, Jan 14, 2013 at 10:42:22AM -0700, Stephen Warren wrote:
> From: Joachim Eastwood <manabian@gmail.com>
>
> After "ARM: delete struct sys_timer" board-rm9200-dt
> fails compilation with the following error:
>
> CC arch/arm/mach-at91/board-rm9200-dt.o
> arch/arm/mach-at91/board-rm9200-dt.c:50:2: error: unknown field 'timer' specified in initializer
> arch/arm/mach-at91/board-rm9200-dt.c:50:13: error: 'at91rm9200_timer' undeclared here (not in a function)
> make[1]: *** [arch/arm/mach-at91/board-rm9200-dt.o] Error 1
> make: *** [arch/arm/mach-at91] Error 2
>
> This is a fall out from the timer conversion. Fix it by
> converting board-rm9200-dt to use new timer init
> function as well.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Olof, Arnd, another fix for the timer-cleanup branch in arm-soc.
Applied to timer/cleanup. Thanks!
-Olof
^ permalink raw reply
* [PATCH 03/16] ARM: b.L: introduce helpers for platform coherency exit/setup
From: Dave Martin @ 2013-01-14 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114171528.GF23616@arm.com>
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?
Cheers
---Dave
^ permalink raw reply
* [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Tony Lindgren @ 2013-01-14 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALF0-+UbqFF17X1Ok1s1AGKg6SBmvMc1mvjVuZb=Ej7xo+qcmA@mail.gmail.com>
* Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
> On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
> > +
> > +Example for an AM33xx board:
> > +
> > + gpmc: gpmc at 50000000 {
> > + compatible = "ti,am3352-gpmc";
> > + ti,hwmods = "gpmc";
> > + reg = <0x50000000 0x1000000>;
> > + interrupts = <100>;
> > + gpmc,num-cs = <8>;
> > + gpmc,num-waitpins = <2>;
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND */
> > +
> > + nand at 0,0 {
> > + reg = <0 0 0>; /* CS0, offset 0 */
>
> I'm a bit confused by this: what are the other two values in "reg"?
> I see you've only added a binding for CS.
>
> I've extended a bit on your work and added a binding to enable OneNAND
> device on my IGEP board.
>
> I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
Regards,
Tony
^ permalink raw reply
* [PATCH 06/16] ARM: b.L: generic SMP secondary bringup and hotplug support
From: Achin Gupta @ 2013-01-14 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F053BF.8090302@ti.com>
Hi Santosh,
On Fri, Jan 11, 2013 at 6:02 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
>>
>> Now that the b.L power API is in place, we can use it for SMP secondary
>> bringup and CPU hotplug in a generic fashion.
>>
>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>> ---
>> arch/arm/common/Makefile | 2 +-
>> arch/arm/common/bL_platsmp.c | 79
>> ++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 80 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/common/bL_platsmp.c
>>
>> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
>> index 894c2ddf9b..59b36db7cc 100644
>> --- a/arch/arm/common/Makefile
>> +++ b/arch/arm/common/Makefile
>> @@ -15,4 +15,4 @@ obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
>> obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
>> obj-$(CONFIG_FIQ_GLUE) += fiq_glue.o fiq_glue_setup.o
>> obj-$(CONFIG_FIQ_DEBUGGER) += fiq_debugger.o
>> -obj-$(CONFIG_BIG_LITTLE) += bL_head.o bL_entry.o vlock.o
>> +obj-$(CONFIG_BIG_LITTLE) += bL_head.o bL_entry.o bL_platsmp.o
>> vlock.o
>> diff --git a/arch/arm/common/bL_platsmp.c b/arch/arm/common/bL_platsmp.c
>> new file mode 100644
>> index 0000000000..0acb9f4685
>> --- /dev/null
>> +++ b/arch/arm/common/bL_platsmp.c
>> @@ -0,0 +1,79 @@
>> +/*
>> + * linux/arch/arm/mach-vexpress/bL_platsmp.c
>> + *
>> + * Created by: Nicolas Pitre, November 2012
>> + * Copyright: (C) 2012 Linaro Limited
>> + *
>> + * 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.
>> + *
>> + * Code to handle secondary CPU bringup and hotplug for the bL power API.
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/smp.h>
>> +
>> +#include <asm/bL_entry.h>
>> +#include <asm/smp_plat.h>
>> +#include <asm/hardware/gic.h>
>> +
>> +static void __init simple_smp_init_cpus(void)
>> +{
>> + set_smp_cross_call(gic_raise_softirq);
>> +}
>> +
>> +static int __cpuinit bL_boot_secondary(unsigned int cpu, struct
>> task_struct *idle)
>> +{
>> + unsigned int pcpu, pcluster, ret;
>> + extern void secondary_startup(void);
>> +
>> + pcpu = cpu_logical_map(cpu) & 0xff;
>> + pcluster = (cpu_logical_map(cpu) >> 8) & 0xff;
>> + pr_debug("%s: logical CPU %d is physical CPU %d cluster %d\n",
>> + __func__, cpu, pcpu, pcluster);
>> +
>> + bL_set_entry_vector(pcpu, pcluster, NULL);
>> + ret = bL_cpu_power_up(pcpu, pcluster);
>> + if (ret)
>> + return ret;
>> + bL_set_entry_vector(pcpu, pcluster, secondary_startup);
>> + gic_raise_softirq(cpumask_of(cpu), 0);
>> + sev();
>
> softirq() should be enough to break a CPU if it is in standby with
> wfe state. Is that additional sev() needed here ?
Not if the target cpu has its I & F bits disabled and that would be the
case with a secondary waiting to be woken up
thanks,
Achin
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* OMAP baseline test results for v3.8-rc3
From: Paul Walmsley @ 2013-01-14 17:59 UTC (permalink / raw)
To: linux-arm-kernel
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
PM ret/off, suspend + dynamic idle:
Pass (3/3): 3530es3beagle, 3730beaglexm, 37xxevm
PM ret, suspend + dynamic idle:
Pass (1/2): 4460pandaes
FAIL (1/2): 4430es2panda
PM ret, dynamic idle:
FAIL (1/1): 2430sdp
Failing tests: fixed by posted patches
--------------------------------------
Other:
* 2420N800: powers down 30 seconds after boot
- Presumably due to missing CBUS patches for watchdog control
- http://lkml.org/lkml/2012/9/3/265
- http://marc.info/?l=linux-omap&m=135274739624125&w=2
- http://marc.info/?l=linux-omap&m=135664195831104&w=2
Failing tests: needing investigation
------------------------------------
Build tests:
* rmk_3430_ldp_allnoconfig, rmk_4430_sdp_allnoconfig: twl4030 build failures
- in drivers/mfd/twl-core.c
Boot tests:
* am335xbone: hangs after "Starting kernel"
- Cause unknown
- http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
* CM-T3517: boot hangs with MMC root
- Due to missing MMC setup in board file
- http://www.spinics.net/lists/arm-kernel/msg211471.html
Boot warnings:
* 3530es3beagle, 3730beaglexm, 37xxevm: nand_scan_ident() warning
- "at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()"
- http://marc.info/?l=linux-omap&m=135630897110185&w=2
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
* 2430sdp: power domains not entering retention
- Cause unknown
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock gate ("debug ignore_loglevel")
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent
Failing tests: needing local investigation (may be due to testbed issues)
-------------------------------------------------------------------------
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omap&m=135082257727502&w=2
- Not yet part of the automated test suite
- Nishanth Menon & Vaibhav Hiremath report that it works for them
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
vmlinux object size
(delta in bytes from test_v3.8-rc2 (d1c3ed669a2d452cacfb48c2d171a1f364dae2ed)):
text data bss total kernel
+216 +8 0 +224 am33xx_only
+256 0 0 +256 n800_multi_omap2xxx
+256 0 0 +256 n800_only_a
+24 +8 0 +32 omap1_defconfig
+28 0 0 +28 omap1_defconfig_1510innovator_only
+16 -8 0 +8 omap1_defconfig_5912osk_only
+328 +80 0 +408 omap2plus_defconfig
+268 +8 0 +276 omap2plus_defconfig_2430sdp_only
+316 -8 0 +308 omap2plus_defconfig_cpupm
+256 +80 0 +336 omap2plus_defconfig_no_pm
+136 +8 0 +144 omap2plus_defconfig_omap2_4_only
+16 -16 0 0 omap2plus_defconfig_omap3_4_only
+48 -16 0 +32 rmk_omap3430_ldp_oldconfig
-88 +8 0 -80 rmk_omap4430_sdp_oldconfig
- Paul
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Felipe Balbi @ 2013-01-14 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F4464E.7000605@pengutronix.de>
On Mon, Jan 14, 2013 at 06:54:22PM +0100, Marc Kleine-Budde wrote:
> On 01/14/2013 06:40 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:
> >
> > <snip>
> >
> >>>> Usually there isn't any Changelog between IP cores used in the different
> >>>> fsl processors (at least available outside of fsl), that makes it quite
> >>>> difficult to say if something found on one imx is really the same as on
> >>>> the other one. And they (usually) don't provide any versioning
> >>>> information in a register or the documentation.
> >>>>
> >>>> just my 2?
> >>>
> >>> $SUBJECT is trying to differentiate a single feature (or maybe two) to
> >>> replace cpu_is_xxx(), then expose that on driver_data without creating
> >>> one enum value for each release from fsl.
> >>
> >> Felipe, every one or two SoCs may have their special operations for
> >> integrate PHY interface, clk operation, or workaround for IC
> >> limitation.
> >
> > the particular PHY and clk used should be hidden by phy layer and clk
> > API respectively. Workarounds, fair enough, we need to handle them; but
> > ideally those should be based on runtime revision detection, not some
> > hackery using driver_data.
>
> If this is actually possible, I'd love to do this. But IP vendor don't
> include a version register in their cores. :(
then fair enough, driver_data or platform_data is the way to go, still
my point (a) below is valid.
--
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/747025be/attachment.sig>
^ permalink raw reply
* [PATCH 08/16] ARM: bL_platsmp.c: make sure the GIC interface of a dying CPU is disabled
From: Lorenzo Pieralisi @ 2013-01-14 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114172401.GG31341@mudshark.cambridge.arm.com>
On Mon, Jan 14, 2013 at 05:24:01PM +0000, Will Deacon wrote:
> On Mon, Jan 14, 2013 at 05:18:24PM +0000, Nicolas Pitre wrote:
> > On Mon, 14 Jan 2013, Will Deacon wrote:
> > > Sorry! This case is more interesting though, because you also want to order
> > > the cpu_if_down GIC write so that it completes before we do the power_off.
> >
> > In this case I'm leaning toward removing that gic_cpu_if_down()
> > entirely. I'm not convinced it is necessary, and if it is then we
> > probably have a bug somewhere else.
>
> Or that :)
In the CPU idle code path (cpu_suspend) we do need to turn off the GIC CPU IF,
hence we will have to cross that bridge when we come to it. Very soon.
Lorenzo
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Marc Kleine-Budde @ 2013-01-14 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114174054.GB12611@arwen.pp.htv.fi>
On 01/14/2013 06:40 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:
>
> <snip>
>
>>>> Usually there isn't any Changelog between IP cores used in the different
>>>> fsl processors (at least available outside of fsl), that makes it quite
>>>> difficult to say if something found on one imx is really the same as on
>>>> the other one. And they (usually) don't provide any versioning
>>>> information in a register or the documentation.
>>>>
>>>> just my 2?
>>>
>>> $SUBJECT is trying to differentiate a single feature (or maybe two) to
>>> replace cpu_is_xxx(), then expose that on driver_data without creating
>>> one enum value for each release from fsl.
>>
>> Felipe, every one or two SoCs may have their special operations for
>> integrate PHY interface, clk operation, or workaround for IC
>> limitation.
>
> the particular PHY and clk used should be hidden by phy layer and clk
> API respectively. Workarounds, fair enough, we need to handle them; but
> ideally those should be based on runtime revision detection, not some
> hackery using driver_data.
If this is actually possible, I'd love to do this. But IP vendor don't
include a version register in their cores. :(
>> Maybe, it will add more future or SoCs (maybe not for this driver) in
>> the future, using enum is easier than string comparison for expanding
>> something.
>
> a) I never told you to *not* use enum. I said that creating DEVICE_A,
> DEVICE_B, DEVICE_C, DEVICE_D and DEVICE_E values when DEVICE_B,
> DEVICE_C and DEVICE_E behave exactly the same is unnecessary.
>
> b) you can't be expecting to add future SoCs support to fsl udc, I have
> already said and will repeat for the last time: move to chipidea ASAP.
>
> New SoCs cannot be added to fsl udc, you *must* use chipidea for
> anything new and move the legacy to chipidea eventually. I will wait for
> a full year for you to do that, but after that I will have to start
> deleting drivers for the sake of avoid duplication of effort.
+1
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/d69ca078/attachment-0001.sig>
^ permalink raw reply
* [PATCH 08/16] ARM: bL_platsmp.c: make sure the GIC interface of a dying CPU is disabled
From: Lorenzo Pieralisi @ 2013-01-14 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301121134390.6300@xanadu.home>
On Sat, Jan 12, 2013 at 04:47:19PM +0000, Nicolas Pitre wrote:
> On Sat, 12 Jan 2013, Santosh Shilimkar wrote:
>
> > On Saturday 12 January 2013 12:37 AM, Nicolas Pitre wrote:
> > > On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
> > >
> > > > On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
> > > > > Otherwise there might be some interrupts or IPIs becoming pending and
> > > > > the
> > > > > CPU will not enter low power mode when doing a WFI. The effect of this
> > > > > is a CPU that loops back into the kernel, go through the first man
> > > > > election, signals itself as alive, and prevent the cluster from being
> > > > > shut down.
> > > > >
> > > > > This could benefit from a better solution.
> > > > >
> > > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > > > ---
> > > > > arch/arm/common/bL_platsmp.c | 1 +
> > > > > arch/arm/common/gic.c | 6 ++++++
> > > > > arch/arm/include/asm/hardware/gic.h | 2 ++
> > > > > 3 files changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/common/bL_platsmp.c b/arch/arm/common/bL_platsmp.c
> > > > > index 0ae44123bf..6a3b251b97 100644
> > > > > --- a/arch/arm/common/bL_platsmp.c
> > > > > +++ b/arch/arm/common/bL_platsmp.c
> > > > > @@ -68,6 +68,7 @@ static void __ref bL_cpu_die(unsigned int cpu)
> > > > > pcpu = mpidr & 0xff;
> > > > > pcluster = (mpidr >> 8) & 0xff;
> > > > > bL_set_entry_vector(pcpu, pcluster, NULL);
> > > > > + gic_cpu_if_down();
> > > >
> > > > So for a case where CPU still don't power down for some reason even
> > > > after CPU interface is disabled, can not listen to and SGI or PPI.
> > > > Not sure if this happens on big.LITTLE but i have seen one such issue
> > > > on Cortex-A9 based SOC.
> > >
> > > Here the problem was the reverse i.e. a CPU wouldn't go down because
> > > some pending SGIs prevented that.
> > >
> > I understood that part. What I was saying is, with CPU IF disabled and
> > if CPU doesn't enter into the intended low power state and if the wakeup
> > mechanism on that CPU is SGI/SPI, CPU may never wakeup and can lead to
> > dead lock. I have seen this scenario on OMAP especially in CPUidle path.
>
> Obviously, on the CPU idle path, you should not turn off the GIC
> interface as this might lose the ability to wake the CPU up with a
> pending interrupt, if your system is so configured.
That's platform specific. On TC2 turning GIC CPU IF off is pivotal otherwise
the CPU receiving an IRQ can complete wfi and be reset by firmware when
executing in the middle of nowhere, leading to a system lock-up.
Disabling the GIC CPU IF must not be added to the gic_cpu_save() code,
but we do need a helper function to disable the CPU IF for platforms
that need this to happen to function properly (eg TC2).
Lorenzo
^ permalink raw reply
* shmobile and struct sys_timer removal conflicts
From: Stephen Warren @ 2013-01-14 17:52 UTC (permalink / raw)
To: linux-arm-kernel
Simon,
I notice that the following shmobile-related commits in next-20130114
add new ARM machine descriptors, but set the .timer field rather than
the new .init_time field. I believe the code in these commits won't
build in linux-next or Linux 3.9 once it's released:
a625586 ARM: mach-shmobile: kzm9g: Reference DT implementation
ac0876f ARM: shmobile: armadillo800eva: Reference DT implementation
be1fc65 ARM: shmobile: add a reference DT implementation for mackerel
66f1162 ARM: mach-shmobile: sh73a0: Minimal setup using DT
In order to solve this problem, you'll need to adjust those changes
according to:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git timer/cleanup
(where "adjust" is probably "rebase on top of")
^ 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