* [RFC PATCH 0/4] b.L: Memory barriers and miscellaneous tidyups
From: Dave Martin @ 2013-01-15 16:48 UTC (permalink / raw)
To: linux-arm-kernel
After much head-scratching and discussion, I have concluded that we
need comprehensive memory barriers in order to ensure that the
low-level synchronisation code executes robustly on all platforms.
DSBs are excessive on most situations though, so many DSBs can be
replces with DMBs.
As was observed in review, providing a C interface to the vlocks
makes little sense, so this series gets rid of it.
Dave Martin (4):
ARM: b.L: Remove C declarations for vlocks
ARM: b.L: vlocks: Add architecturally required memory barriers
ARM: bL_entry: Match memory barriers to architectural requirements
ARM: vexpress/dcscb: power_up_setup memory barrier cleanup
arch/arm/common/bL_head.S | 40 ++++++++-----------------------
arch/arm/common/vlock.S | 7 ++++-
arch/arm/common/vlock.h | 43 ----------------------------------
arch/arm/mach-vexpress/dcscb_setup.S | 5 +--
4 files changed, 18 insertions(+), 77 deletions(-)
delete mode 100644 arch/arm/common/vlock.h
--
1.7.4.1
^ permalink raw reply
* [PATCH 00/16] big.LITTLE low-level CPU and cluster power management
From: Nicolas Pitre @ 2013-01-15 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358217848.8513.14.camel@jlo-ubuntu-64.nvidia.com>
On Tue, 15 Jan 2013, Joseph Lo wrote:
> On Mon, 2013-01-14 at 22:05 +0800, Nicolas Pitre wrote:
> > On Mon, 14 Jan 2013, Joseph Lo wrote:
> >
> > > Hi Nicolas,
> > >
> > > On Thu, 2013-01-10 at 08:20 +0800, Nicolas Pitre wrote:
> > > > This is the initial public posting of the initial support for big.LITTLE.
> > > > Included here is the code required to safely power up and down CPUs in a
> > > > b.L system, whether this is via CPU hotplug, a cpuidle driver or the
> > > > Linaro b.L in-kernel switcher[*] on top of this. Only SMP secondary
> > > > boot and CPU hotplug support is included at this time. Getting to this
> > > > point already represents a significcant chunk of code as illustrated by
> > > > the diffstat below.
> > > >
> > > >
> > >
> > > Thanks for introducing this series.
> > > I am taking a look at this series. It introduced an algorithm for
> > > syncing and avoid racing when syncing the power status of clusters and
> > > CPUs. Do you think these codes could have a chance to become a generic
> > > framework?
> >
> > Yes. As I mentioned before, the bL_ prefix is implied only by the fact
> > that big.LITTLE was the motivation for creating this code.
> >
> > > The Tegra chip series had a similar design for CPU clusters and it
> > had
> > > limitation that the CPU0 always needs to be the last CPU to be shut down
> > > before cluster power down as well. I believe it can also get benefits of
> > > this works. We indeed need a similar algorithm to sync CPUs power status
> > > before cluster power down and switching.
> > >
> > > The "bL_entry.c", "bL_entry.S", "bL_entry.h", "vlock.h" and "vlock.S"
> > > looks have a chance to be a common framework for ARM platform even if it
> > > just support one cluster. Because some systems had the limitations for
> > > cluster power down. That's why the coupled cpuidle been introduced. And
> > > this framework could be enabled automatically if platform dependent or
> > > by menuconfig.
> >
> > Absolutely.
> >
> So do you have a plan to make it become a generic framework in this
> series or later work?
It is already generic, except for the name. In other words, you could
start using this code already.
I'm still debating a good substitute for the bL_ prefix in this series
to give it the appearance of generic code.
> (And I will add some common power sync wrapper functions that based on
> this framework for all Tegra series.)
Great!
Nicolas
^ permalink raw reply
* [PATCH] timer: vt8500: Convert vt8500 to use CLKSRC_OF
From: Stephen Warren @ 2013-01-15 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358232649-19964-1-git-send-email-linux@prisktech.co.nz>
On 01/14/2013 11:50 PM, Tony Prisk wrote:
> This patch converts arch-vt8500 to make use of CLKSRC_OF. Doing so
> removes the need for include/linux/vt8500_timer.h as vt8500_timer_init
> no longer needs to be visible outside vt8500_timer.c
Reviewed-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
From: Gregory CLEMENT @ 2013-01-15 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115153716.GF13433@titan.lakedaemon.net>
On 01/15/2013 04:37 PM, Jason Cooper wrote:
> Mike,
>
> On Tue, Jan 15, 2013 at 03:23:08PM +0000, Cong Ding wrote:
>> From 75c73077905b822be6e8a32a09d6b0cdb5e61763 Mon Sep 17 00:00:00 2001
>> From: Cong Ding <dinggnu@gmail.com>
>> Date: Mon, 14 Jan 2013 18:06:26 +0100
>> Subject: [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
>>
>> the variable cpuclk and clk_name should be properly freed when error happens.
>>
>> Signed-off-by: Cong Ding <dinggnu@gmail.com>
>> ---
>> drivers/clk/mvebu/clk-cpu.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>
>
> Do you want to take this fix through the clock tree? If so,
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
>
I also think it should go through the clock tree but before this
I'd like we fix the last issue.
Cong Ding,
you didn't take in account the case when the allocation of the 1st clocks
when the 2nd cpu clock failed. In this case there is still a memory leak with
the clock_name of the first cpu clock. See below for my proposal:
> Otherwise, just let me know.
>
> thx,
>
> Jason.
>
>> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
>> index ff004578..1066a43 100644
>> --- a/drivers/clk/mvebu/clk-cpu.c
>> +++ b/drivers/clk/mvebu/clk-cpu.c
>> @@ -124,7 +124,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
>>
>> clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
>> if (WARN_ON(!clks))
>> - return;
>> + goto clks_out;
>>
>> for_each_node_by_type(dn, "cpu") {
>> struct clk_init_data init;
>> @@ -134,11 +134,13 @@ void __init of_cpu_clk_setup(struct device_node *node)
>> int cpu, err;
>>
>> if (WARN_ON(!clk_name))
>> - return;
>> + goto bail_out;
>>
>> err = of_property_read_u32(dn, "reg", &cpu);
>> - if (WARN_ON(err))
>> - return;
>> + if (WARN_ON(err)) {
>> + kfree(clk_name);
we can free it later
>> + goto bail_out;
>> + }
>>
>> sprintf(clk_name, "cpu%d", cpu);
>> parent_clk = of_clk_get(node, 0);
>> @@ -156,8 +158,10 @@ void __init of_cpu_clk_setup(struct device_node *node)
>> init.num_parents = 1;
>>
>> clk = clk_register(NULL, &cpuclk[cpu].hw);
>> - if (WARN_ON(IS_ERR(clk)))
>> + if (WARN_ON(IS_ERR(clk))) {
>> + kfree(clk_name);
we can free it later
>> goto bail_out;
>> + }
>> clks[cpu] = clk;
>> }
>> clk_data.clk_num = MAX_CPU;
>> @@ -167,6 +171,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
>> return;
>> bail_out:
>> kfree(clks);
>> +clks_out:
as cpuclk is allocated with all its member set to 0, and kfree(0) is a valid call.
We can add the following lines:
while(ncpus--)
kfree(cpuclk[ncpus].clk_name);
>> kfree(cpuclk);
>> }
>>
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Paul E. McKenney @ 2013-01-15 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFTL4hzYkPCmkfqBafkTA5E_snkLoC_y3p9xwumj=L1xWAWK0g@mail.gmail.com>
On Tue, Jan 15, 2013 at 01:13:10AM +0100, Frederic Weisbecker wrote:
> 2013/1/11 Colin Cross <ccross@android.com>:
> > Emulate NMIs on systems where they are not available by using timer
> > interrupts on other cpus. Each cpu will use its softlockup hrtimer
> > to check that the next cpu is processing hrtimer interrupts by
> > verifying that a counter is increasing.
> >
> > This patch is useful on systems where the hardlockup detector is not
> > available due to a lack of NMIs, for example most ARM SoCs.
> > Without this patch any cpu stuck with interrupts disabled can
> > cause a hardware watchdog reset with no debugging information,
> > but with this patch the kernel can detect the lockup and panic,
> > which can result in useful debugging info.
> >
> > Signed-off-by: Colin Cross <ccross@android.com>
>
> I believe this is pretty much what the RCU stall detector does
> already: checks for other CPUs being responsive. The only difference
> is on how it checks that. For RCU it's about checking for CPUs
> reporting quiescent states when requested to do so. In your case it's
> about ensuring the hrtimer interrupt is well handled.
>
> One thing you can do is to enqueue an RCU callback (cal_rcu()) every
> minute so you can force other CPUs to report quiescent states
> periodically and thus check for lockups.
This would work in all but one case, and that is where RCU believes
that the non-responsive CPU is in dyntick-idle mode. In that case,
RCU would not be expecting it to respond and would therefore ignore
any non-responsiveness.
> Now you'll face the same problem in the end: if you don't have NMIs,
> you won't have a very useful report.
Indeed, I must confess that I have thus far chickened out on solving
the general NMI problem. The RCU stall detector does try to look at
stacks remotely in some cases, but this is often unreliable, and some
architectures seem to refuse to produce a remote stack trace.
Thanx, Paul
^ permalink raw reply
* [kvmarm] [PATCH v5 06/14] KVM: ARM: Inject IRQs and FIQs from userspace
From: Alexander Graf @ 2013-01-15 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115151757.GD12489@redhat.com>
On 01/15/2013 04:17 PM, Gleb Natapov wrote:
> On Tue, Jan 15, 2013 at 02:04:47PM +0000, Peter Maydell wrote:
>> On 15 January 2013 12:52, Gleb Natapov<gleb@redhat.com> wrote:
>>> On Tue, Jan 15, 2013 at 12:15:01PM +0000, Peter Maydell wrote:
>>>> On 15 January 2013 09:56, Gleb Natapov<gleb@redhat.com> wrote:
>>>>>> ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
>>>>> CPU level interrupt should use KVM_INTERRUPT instead.
>>>> No, that would be wrong. KVM_INTERRUPT is for interrupts which must be
>>>> delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which
>>>> can be fed to the kernel asynchronously. It happens that on x86 "must be
>>>> delivered synchronously" and "not going to in kernel irqchip" are the same, but
>>>> this isn't true for other archs. For ARM all our interrupts can be fed
>>>> to the kernel asynchronously, and so we use KVM_IRQ_LINE in all
>>>> cases.
>>> I do no quite understand what you mean by synchronously and
>>> asynchronously.
>> Synchronously: the vcpu has to be stopped and userspace then
>> feeds in the interrupt to be taken when the guest is resumed.
>> Asynchronously: any old thread can tell the kernel there's an
>> interrupt, and the guest vcpu then deals with it when needed
>> (the vcpu thread may leave the guest but doesn't come out of
>> the host kernel to qemu).
>>
>>> The difference between KVM_INTERRUPT and KVM_IRQ_LINE line
>>> is that former is used when destination cpu is known to userspace later
>>> is used when kernel code is involved in figuring out the destination.
>> This doesn't match up with Avi's explanation at all.
>>
>>> The
>>> injections themselves are currently synchronous for both of them on x86
>>> and ARM. i.e vcpu is kicked out from guest mode when interrupt need to
>>> be injected into a guest and vcpu state is changed to inject interrupt
>>> during next guest entry. In the near feature x86 will be able to inject
>>> interrupt without kicking vcpu out from the guest mode does ARM plan to
>>> do the same? For GIC interrupts or for IRQ/FIQ or for both?
>>>
>>>> There was a big discussion thread about this on kvm and qemu-devel last
>>>> July (and we cleaned up some of the QEMU code to not smoosh together
>>>> all these different concepts under "do I have an irqchip or not?").
>>> Do you have a pointer?
>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
>> and there was a later longer (but less clear) thread which included
>> this mail from Avi:
>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
>> basically explaining that the reason for the weird synchronous
>> KVM_INTERRUPT API is that it's emulating a weird synchronous
>> hardware interface which is specific to x86. ARM doesn't have
>> a synchronous interface in the same way, so it's much more
>> straightforward to use KVM_IRQ_LINE.
>>
> OK. I see. So basically Avi saw KVM_INTERRUPT as an oddball interface
> required only for APIC emulation in userspace. It is used for PIC also,
> where this is not strictly needed, but this is for historical reasons
> (KVM_IRQ_LINE was introduces late and it is GSI centric on x86).
>
> Thank you for the pointer.
Yeah, please keep in mind that KVM_INTERRUPT is not a unified interface
either. In fact, it is asynchronous on PPC :). And it's called
KVM_S390_INTERRUPT on s390 and also asynchronous. X86 is the oddball here.
But I don't care whether we call the ioctl to steer CPU interrupt pins
KVM_INTERRUPT, KVM_S390_INTERRUPT or KVM_IRQ_LINE, as long as the code
makes it obvious what is happening.
Alex
^ permalink raw reply
* [kvmarm] [PATCH v5 03/14] KVM: ARM: Initial skeleton to compile KVM support
From: Alexander Graf @ 2013-01-15 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115153555.GF12489@redhat.com>
On 01/15/2013 04:35 PM, Gleb Natapov wrote:
> On Tue, Jan 15, 2013 at 02:43:26PM +0100, Alexander Graf wrote:
>> On 15.01.2013, at 14:32, Gleb Natapov wrote:
>>
>>> On Mon, Jan 14, 2013 at 05:17:31PM -0500, Christoffer Dall wrote:
>>>> On Mon, Jan 14, 2013 at 1:49 PM, Gleb Natapov<gleb@redhat.com> wrote:
>>>>> 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?
>>>>>
>>>> We use the ONE_REG API instead and we don't want to support two
>>>> separate APIs to user space.
>>>>
>>> I suppose fetching all registers is not anywhere on a fast path in
>>> userspace :)
>> If it's ever going to be in a fast path, we will add MULTI_REG which will feature an array of ONE_REG structs to fetch multiple registers at once.
>>
> And I hope it will not be. On x86 only the broken vmware PV
> interface requires reading registers for emulation.
>
> This reminds me the question I wanted to ask you about ONE_REG
> interface. Why architecture is encoded in register name? Is architecture
> implied by HW the code is running on anyway?
It provides for nice sanity checks. Also, 64 bits are quite a lot, so we
can easily waste a few bits for redundancy.
Alex
^ permalink raw reply
* [PATCH] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
From: Mike Turquette @ 2013-01-15 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358256897-26275-1-git-send-email-afzal@ti.com>
Quoting Afzal Mohammed (2013-01-15 05:34:57)
> LCDC clock node is a one that does not have set rate capability. It
> just passes on the rate that is sent downstream by it's parent. While
> lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
> dpll_disp_ck has the capability to configure rate.
>
> And the default rates provided by LCDC clock's ancestors are not
> sufficient to obtain pixel clock for current LCDC use cases, hence
> currently display would not work on AM335x SoC's (with driver
> modifications in platfrom independent way).
>
> Hence inform clock framework to propogate set rate for LCDC clock as
> well as it's parent - dpll_disp_m2_ck. With this change, set rate on
> LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
> hence allowing the driver (same driver is used in DaVinci too) to set
> rates using LCDC clock without worrying about platform dependent clock
> details.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>
> Based on v3.8-rc3
>
> arch/arm/mach-omap2/cclock33xx_data.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
> index ea64ad6..b731216 100644
> --- a/arch/arm/mach-omap2/cclock33xx_data.c
> +++ b/arch/arm/mach-omap2/cclock33xx_data.c
> @@ -284,9 +284,10 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
> * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
> * and ALT_CLK1/2)
> */
> -DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck, 0x0,
> - AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
> - AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
> +DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck,
> + CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
> + AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
> + CLK_DIVIDER_ONE_BASED, NULL);
>
> /* DPLL_PER */
> static struct dpll_data dpll_per_dd = {
> @@ -932,6 +933,8 @@ int __init am33xx_clk_init(void)
> cpu_clkflg = CK_AM33XX;
> }
>
> + lcd_gclk.flags |= CLK_SET_RATE_PARENT;
> +
Afzal,
This is a bit hacky. Someone looking at the definition of struct
lcd_gclk above cannot easily tell that CLK_SET_RATE_PARENT is set below.
Also if other clocks need flags set at a later date then this will
become a big ugly block of flag setting.
I hope to move away from these macros some day, but in the mean time it
might be good to have a DEFINE_STRUCT_CLK_FLAGS macro which adds in an
argument struct clk->flags.
Paul, any thoughts on yet another macro?
Thanks,
Mike
> for (c = am33xx_clks; c < am33xx_clks + ARRAY_SIZE(am33xx_clks); c++) {
> if (c->cpu & cpu_clkflg) {
> clkdev_add(&c->lk);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 0/7] usb: musb: add driver for control module
From: B, Ravi @ 2013-01-15 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115150432.GB26272@arwen.pp.htv.fi>
> Hi,
>
> On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
> > Hi Arnd,
> >
> > On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> > >On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> > >>Added a new driver for the usb part of control module.
> This has an
> > >>API to power on the USB2 phy and an API to write to the mailbox
> > >>depending on whether MUSB has to act in host mode or in
> device mode.
> > >>
> > >>Writing to control module registers for doing the above
> task which
> > >>was previously done in omap glue and in omap-usb2 phy is removed.
> > >>
> > >>Also added the dt data to get MUSB working in OMAP platforms.
> > >>This series has patches for both drivers and ARCH
> folders, so If it
> > >>has to be split I'll do it.
> > >>
> > >
> > >The series looks good to me, I just had a minor comment on
> one patch.
> > >
> > >One a somewhat related topic, I wonder whether there are
> any plans on
> > >your side to change this driver to support multiple bus
> glues to be
> > >built for one kernel image. With a multiplatform kernel,
> we may need
> > >all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
> >
> > We don't have plans as of now. I actually don't expect any
> changes in
> > the driver other than the Kconfig changes. Anyways the
> probe of glue's
> > other than the platform it's running won't get called. right Felipe?
If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs. What if, if control module interface (register defintions) varies b/w different revision or spin of same type of SoCs, if usbphy type is changed. In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ?
Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver?
>
> AFAICT there's nothing preventing those from being built
> together as long as you don't use DMA (yeah, that's a touchy
> subject still with MUSB).
>
> If there are any build breaks, please report them so bus glue
> owners can fix. I see that at least the davinci folks need to
> work a bit
>
> $ git grep -e "mach\/" drivers/usb/musb/
> drivers/usb/musb/da8xx.c:#include <mach/da8xx.h>
> drivers/usb/musb/davinci.c:#include <mach/cputype.h>
> drivers/usb/musb/davinci.c:#include <mach/hardware.h>
>
> I'm adding Ravi B to the loop here for those.
>
> --
> balbi
>
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Andrew Murray @ 2013-01-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301151244.12767.arnd@arndb.de>
On Tue, Jan 15, 2013 at 12:44:12PM +0000, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Thierry Reding wrote:
> > I'm not sure I follow you're reasoning here. Is it possible to use MSIs
> > without PCI? If not then I think there's little sense in keeping the
> > implementations separate.
>
> Conceptually, you can use MSI for any device, but the Linux interfaces
> for MSI are tied to PCI. If you use an MSI controller for a non-PCI
> device, it would probably just appear as a regular interrupt controller.
>
> > Furthermore, if MSI controller and PCI host bridge are separate entities
> > how do you look up the MSI controller given a PCI device?
>
> The host bridge can contain a pointer ot the MSI controller. You can
> have multiple host bridges sharing a single MSI controller or you
> can have separate ones for each host.
Yes and I hoped this relationship would be described by a device tree phandle
as is done for relating devices to their interrupt-parent (where device trees
are used). This would provide (arguably unnecessarily) greater flexibility,
e.g. if you have two PCI/MSI controller pairs, the MSIs only offer limited MSIs
and you only use one PCI fabric - you could service different parts of the
fabric by different MSI controllers (assuming you relate MSI controllers to
part of the fabric and that you'd want to). Perhaps there would be benefits for
virtualisation as well?
Andrew Murray
^ permalink raw reply
* [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
From: Jason Cooper @ 2013-01-15 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115152307.GA25615@gmail.com>
Mike,
On Tue, Jan 15, 2013 at 03:23:08PM +0000, Cong Ding wrote:
> From 75c73077905b822be6e8a32a09d6b0cdb5e61763 Mon Sep 17 00:00:00 2001
> From: Cong Ding <dinggnu@gmail.com>
> Date: Mon, 14 Jan 2013 18:06:26 +0100
> Subject: [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
>
> the variable cpuclk and clk_name should be properly freed when error happens.
>
> Signed-off-by: Cong Ding <dinggnu@gmail.com>
> ---
> drivers/clk/mvebu/clk-cpu.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
Do you want to take this fix through the clock tree? If so,
Acked-by: Jason Cooper <jason@lakedaemon.net>
Otherwise, just let me know.
thx,
Jason.
> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> index ff004578..1066a43 100644
> --- a/drivers/clk/mvebu/clk-cpu.c
> +++ b/drivers/clk/mvebu/clk-cpu.c
> @@ -124,7 +124,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
>
> clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
> if (WARN_ON(!clks))
> - return;
> + goto clks_out;
>
> for_each_node_by_type(dn, "cpu") {
> struct clk_init_data init;
> @@ -134,11 +134,13 @@ void __init of_cpu_clk_setup(struct device_node *node)
> int cpu, err;
>
> if (WARN_ON(!clk_name))
> - return;
> + goto bail_out;
>
> err = of_property_read_u32(dn, "reg", &cpu);
> - if (WARN_ON(err))
> - return;
> + if (WARN_ON(err)) {
> + kfree(clk_name);
> + goto bail_out;
> + }
>
> sprintf(clk_name, "cpu%d", cpu);
> parent_clk = of_clk_get(node, 0);
> @@ -156,8 +158,10 @@ void __init of_cpu_clk_setup(struct device_node *node)
> init.num_parents = 1;
>
> clk = clk_register(NULL, &cpuclk[cpu].hw);
> - if (WARN_ON(IS_ERR(clk)))
> + if (WARN_ON(IS_ERR(clk))) {
> + kfree(clk_name);
> goto bail_out;
> + }
> clks[cpu] = clk;
> }
> clk_data.clk_num = MAX_CPU;
> @@ -167,6 +171,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
> return;
> bail_out:
> kfree(clks);
> +clks_out:
> kfree(cpuclk);
> }
>
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [kvmarm] [PATCH v5 03/14] KVM: ARM: Initial skeleton to compile KVM support
From: Gleb Natapov @ 2013-01-15 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <FE4B72B9-F302-49BA-98D7-E674247BD093@suse.de>
On Tue, Jan 15, 2013 at 02:43:26PM +0100, Alexander Graf wrote:
>
> On 15.01.2013, at 14:32, Gleb Natapov wrote:
>
> > On Mon, Jan 14, 2013 at 05:17:31PM -0500, Christoffer Dall wrote:
> >> On Mon, Jan 14, 2013 at 1:49 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >>> 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?
> >>>
> >>
> >> We use the ONE_REG API instead and we don't want to support two
> >> separate APIs to user space.
> >>
> > I suppose fetching all registers is not anywhere on a fast path in
> > userspace :)
>
> If it's ever going to be in a fast path, we will add MULTI_REG which will feature an array of ONE_REG structs to fetch multiple registers at once.
>
And I hope it will not be. On x86 only the broken vmware PV
interface requires reading registers for emulation.
This reminds me the question I wanted to ask you about ONE_REG
interface. Why architecture is encoded in register name? Is architecture
implied by HW the code is running on anyway?
--
Gleb.
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Gleb Natapov @ 2013-01-15 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F56C3B.6040308@arm.com>
On Tue, Jan 15, 2013 at 02:48:27PM +0000, Marc Zyngier wrote:
> On 15/01/13 14:27, Gleb Natapov wrote:
> > On Tue, Jan 15, 2013 at 01:46:04PM +0000, Marc Zyngier wrote:
> >> On 15/01/13 13:34, Gleb Natapov wrote:
> >>> On Tue, Jan 15, 2013 at 01:29:40PM +0000, Marc Zyngier wrote:
> >>>> On 15/01/13 13:18, Gleb Natapov wrote:
> >>>>> On Tue, Jan 08, 2013 at 01:40:05PM -0500, Christoffer Dall wrote:
> >>>>>> When the guest accesses I/O memory this will create data abort
> >>>>>> exceptions and they are handled by decoding the HSR information
> >>>>>> (physical address, read/write, length, register) and forwarding reads
> >>>>>> and writes to QEMU which performs the device emulation.
> >>>>>>
> >>>>>> Certain classes of load/store operations do not support the syndrome
> >>>>>> information provided in the HSR and we therefore must be able to fetch
> >>>>>> the offending instruction from guest memory and decode it manually.
> >>>>>>
> >>>>>> We only support instruction decoding for valid reasonable MMIO operations
> >>>>>> where trapping them do not provide sufficient information in the HSR (no
> >>>>>> 16-bit Thumb instructions provide register writeback that we care about).
> >>>>>>
> >>>>>> The following instruction types are NOT supported for MMIO operations
> >>>>>> despite the HSR not containing decode info:
> >>>>>> - any Load/Store multiple
> >>>>>> - any load/store exclusive
> >>>>>> - any load/store dual
> >>>>>> - anything with the PC as the dest register
> >>>>>>
> >>>>>> This requires changing the general flow somewhat since new calls to run
> >>>>>> the VCPU must check if there's a pending MMIO load and perform the write
> >>>>>> after userspace has made the data available.
> >>>>>>
> >>>>>> Rusty Russell fixed a horrible race pointed out by Ben Herrenschmidt:
> >>>>>> (1) Guest complicated mmio instruction traps.
> >>>>>> (2) The hardware doesn't tell us enough, so we need to read the actual
> >>>>>> instruction which was being exectuted.
> >>>>>> (3) KVM maps the instruction virtual address to a physical address.
> >>>>>> (4) The guest (SMP) swaps out that page, and fills it with something else.
> >>>>>> (5) We read the physical address, but now that's the wrong thing.
> >>>>> How can this happen?! The guest cannot reuse physical page before it
> >>>>> flushes it from all vcpus tlb cache. For that it needs to send
> >>>>> synchronous IPI to all vcpus and IPI will not be processed by a vcpu
> >>>>> while it does emulation.
> >>>>
> >>>> I don't know how this works on x86, but a KVM/ARM guest can definitely
> >>>> handle an IPI.
> >>>>
> >>> How can a vcpu handle an IPI while it is not in a guest mode?
> >>
> >> I think there is some misunderstanding. A guest IPI is of course handled
> >> while running the guest. You completely lost me here.
> > You need IPI from one guest vcpu to another to invalidate its TLB on
> > x86. That prevents the race from happening there.
>
> We don't need this on ARM (starting with v7, v6 is an entirely different
> story, and we do not support KVM on v6).
>
> The TLB is propagated by the HW using the following (pseudocode) sequence:
> tlb_invalidate VA
> barrier
>
> Leaving the barrier guaranties that all TLB invalidations have been
> propagated.
>
That explains why __get_user_pages_fast() is missing on ARM :)
> >>
> >>>> Furthermore, TLB invalidation doesn't require an IPI on ARMv7 (unless
> >>>> we're doing some set/way operation which is handled separately).
> >>>>
> >>> What prevents a page to be swapped out while code is fetched from it?
> >>
> >> Why would you prevent it? TLB invalidation is broadcast by the HW. If
> >> you swap a page out, you flag the entry as invalid and invalidate the
> >> corresponding TLB. If you hit it, you swap the page back in.
> >>
> > There is no IPI (or anything that requires response from cpu whose TLB
> > is invalidated) involved in invalidating remote TLB?
>
> No. The above sequence is all you have to do.
>
> This is why the above race is a bit hairy. A vcpu will happily
> invalidate TLBs, but as the faulting vcpu already performed the
> translation, we're screwed.
>
> Thankfully, this is a case that only matters when we have to emulate an
> MMIO operation that is not automatically decoded by the HW. They are
> rare (the Linux kernel doesn't use them). In this case, we stop the
> world (IPI).
>
Got it. Thanks.
--
Gleb.
^ permalink raw reply
* [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
From: Cong Ding @ 2013-01-15 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F563EC.3030804@free-electrons.com>
>From 75c73077905b822be6e8a32a09d6b0cdb5e61763 Mon Sep 17 00:00:00 2001
From: Cong Ding <dinggnu@gmail.com>
Date: Mon, 14 Jan 2013 18:06:26 +0100
Subject: [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
the variable cpuclk and clk_name should be properly freed when error happens.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
---
drivers/clk/mvebu/clk-cpu.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index ff004578..1066a43 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -124,7 +124,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
if (WARN_ON(!clks))
- return;
+ goto clks_out;
for_each_node_by_type(dn, "cpu") {
struct clk_init_data init;
@@ -134,11 +134,13 @@ void __init of_cpu_clk_setup(struct device_node *node)
int cpu, err;
if (WARN_ON(!clk_name))
- return;
+ goto bail_out;
err = of_property_read_u32(dn, "reg", &cpu);
- if (WARN_ON(err))
- return;
+ if (WARN_ON(err)) {
+ kfree(clk_name);
+ goto bail_out;
+ }
sprintf(clk_name, "cpu%d", cpu);
parent_clk = of_clk_get(node, 0);
@@ -156,8 +158,10 @@ void __init of_cpu_clk_setup(struct device_node *node)
init.num_parents = 1;
clk = clk_register(NULL, &cpuclk[cpu].hw);
- if (WARN_ON(IS_ERR(clk)))
+ if (WARN_ON(IS_ERR(clk))) {
+ kfree(clk_name);
goto bail_out;
+ }
clks[cpu] = clk;
}
clk_data.clk_num = MAX_CPU;
@@ -167,6 +171,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
return;
bail_out:
kfree(clks);
+clks_out:
kfree(cpuclk);
}
--
1.7.9.5
^ permalink raw reply related
* [kvmarm] [PATCH v5 06/14] KVM: ARM: Inject IRQs and FIQs from userspace
From: Gleb Natapov @ 2013-01-15 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA8gzD4F4BPKR_dSDDD-iyv0ONt6H+yrj_nHifeCFBfpPA@mail.gmail.com>
On Tue, Jan 15, 2013 at 02:04:47PM +0000, Peter Maydell wrote:
> On 15 January 2013 12:52, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Jan 15, 2013 at 12:15:01PM +0000, Peter Maydell wrote:
> >> On 15 January 2013 09:56, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
> >> > CPU level interrupt should use KVM_INTERRUPT instead.
> >>
> >> No, that would be wrong. KVM_INTERRUPT is for interrupts which must be
> >> delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which
> >> can be fed to the kernel asynchronously. It happens that on x86 "must be
> >> delivered synchronously" and "not going to in kernel irqchip" are the same, but
> >> this isn't true for other archs. For ARM all our interrupts can be fed
> >> to the kernel asynchronously, and so we use KVM_IRQ_LINE in all
> >> cases.
>
> > I do no quite understand what you mean by synchronously and
> > asynchronously.
>
> Synchronously: the vcpu has to be stopped and userspace then
> feeds in the interrupt to be taken when the guest is resumed.
> Asynchronously: any old thread can tell the kernel there's an
> interrupt, and the guest vcpu then deals with it when needed
> (the vcpu thread may leave the guest but doesn't come out of
> the host kernel to qemu).
>
> > The difference between KVM_INTERRUPT and KVM_IRQ_LINE line
> > is that former is used when destination cpu is known to userspace later
> > is used when kernel code is involved in figuring out the destination.
>
> This doesn't match up with Avi's explanation at all.
>
> > The
> > injections themselves are currently synchronous for both of them on x86
> > and ARM. i.e vcpu is kicked out from guest mode when interrupt need to
> > be injected into a guest and vcpu state is changed to inject interrupt
> > during next guest entry. In the near feature x86 will be able to inject
> > interrupt without kicking vcpu out from the guest mode does ARM plan to
> > do the same? For GIC interrupts or for IRQ/FIQ or for both?
> >
> >> There was a big discussion thread about this on kvm and qemu-devel last
> >> July (and we cleaned up some of the QEMU code to not smoosh together
> >> all these different concepts under "do I have an irqchip or not?").
> > Do you have a pointer?
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
> and there was a later longer (but less clear) thread which included
> this mail from Avi:
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
> basically explaining that the reason for the weird synchronous
> KVM_INTERRUPT API is that it's emulating a weird synchronous
> hardware interface which is specific to x86. ARM doesn't have
> a synchronous interface in the same way, so it's much more
> straightforward to use KVM_IRQ_LINE.
>
OK. I see. So basically Avi saw KVM_INTERRUPT as an oddball interface
required only for APIC emulation in userspace. It is used for PIC also,
where this is not strictly needed, but this is for historical reasons
(KVM_IRQ_LINE was introduces late and it is GSI centric on x86).
Thank you for the pointer.
--
Gleb.
^ permalink raw reply
* [Linaro-mm-sig][RFC] ARM: dma-mapping: Add DMA attribute to skip iommu mapping
From: Marek Szyprowski @ 2013-01-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357639944-12050-1-git-send-email-abhinav.k@samsung.com>
Hello,
On 1/8/2013 11:12 AM, Abhinav Kochhar wrote:
> Adding a new dma attribute which can be used by the
> platform drivers to avoid creating iommu mappings.
> In some cases the buffers are allocated by display
> controller driver using dma alloc apis but are not
> used for scanout. Though the buffers are allocated
> by display controller but are only used for sharing
> among different devices.
> With this attribute the platform drivers can choose
> not to create iommu mapping at the time of buffer
> allocation and only create the mapping when they
> access this buffer.
>
> Change-Id: I2178b3756170982d814e085ca62474d07b616a21
> Signed-off-by: Abhinav Kochhar <abhinav.k@samsung.com>
> ---
> arch/arm/mm/dma-mapping.c | 8 +++++---
> include/linux/dma-attrs.h | 1 +
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index c0f0f43..e73003c 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1279,9 +1279,11 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
> if (!pages)
> return NULL;
>
> - *handle = __iommu_create_mapping(dev, pages, size);
> - if (*handle == DMA_ERROR_CODE)
> - goto err_buffer;
> + if (!dma_get_attr(DMA_ATTR_NO_IOMMU_MAPPING, attrs)) {
> + *handle = __iommu_create_mapping(dev, pages, size);
> + if (*handle == DMA_ERROR_CODE)
> + goto err_buffer;
> + }
>
> if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs))
> return pages;
> diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
> index c8e1831..1f04419 100644
> --- a/include/linux/dma-attrs.h
> +++ b/include/linux/dma-attrs.h
> @@ -15,6 +15,7 @@ enum dma_attr {
> DMA_ATTR_WEAK_ORDERING,
> DMA_ATTR_WRITE_COMBINE,
> DMA_ATTR_NON_CONSISTENT,
> + DMA_ATTR_NO_IOMMU_MAPPING,
> DMA_ATTR_NO_KERNEL_MAPPING,
> DMA_ATTR_SKIP_CPU_SYNC,
> DMA_ATTR_FORCE_CONTIGUOUS,
I'm sorry, but from my perspective this patch and the yet another dma
attribute shows that there is something fishy happening in the exynos-drm
driver. Creating a mapping in DMA address space is the MAIN purpose of
the DMA mapping subsystem, so adding an attribute which skips this
operation already should give you a sign of warning that something is
not used right.
It looks that dma-mapping in the current state is simply not adequate
for this driver. I noticed that DRM drivers are already known for
implementing a lots of common code for their own with slightly changed
behavior, like custom page manager/allocator. It looks that exynos-drm
driver grew to the point where it also needs such features. It already
contains custom code for CPU cache handling, IOMMU and contiguous
memory special cases management. I would advise to drop DMA-mapping
API completely, avoid adding yet another dozen of DMA attributes useful
only for one driver and implement your own memory manager with direct
usage of IOMMU API, alloc_pages() and dma_alloc_pages_from_contiguous().
This way DMA mapping subsystem can be kept simple, robust and easy to
understand without confusing or conflicting parts.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [RFC PATCH 0/7] usb: musb: add driver for control module
From: Felipe Balbi @ 2013-01-15 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F56A1A.3040504@ti.com>
Hi,
On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
> Hi Arnd,
>
> On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> >On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> >>Added a new driver for the usb part of control module. This has an API
> >>to power on the USB2 phy and an API to write to the mailbox depending on
> >>whether MUSB has to act in host mode or in device mode.
> >>
> >>Writing to control module registers for doing the above task which was
> >>previously done in omap glue and in omap-usb2 phy is removed.
> >>
> >>Also added the dt data to get MUSB working in OMAP platforms.
> >>This series has patches for both drivers and ARCH folders, so If it has to
> >>be split I'll do it.
> >>
> >
> >The series looks good to me, I just had a minor comment on one patch.
> >
> >One a somewhat related topic, I wonder whether there are any plans
> >on your side to change this driver to support multiple bus glues
> >to be built for one kernel image. With a multiplatform kernel, we
> >may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
>
> We don't have plans as of now. I actually don't expect any changes in
> the driver other than the Kconfig changes. Anyways the probe of
> glue's other than the platform it's running won't get called. right
> Felipe?
AFAICT there's nothing preventing those from being built together as
long as you don't use DMA (yeah, that's a touchy subject still with
MUSB).
If there are any build breaks, please report them so bus glue owners can
fix. I see that at least the davinci folks need to work a bit
$ git grep -e "mach\/" drivers/usb/musb/
drivers/usb/musb/da8xx.c:#include <mach/da8xx.h>
drivers/usb/musb/davinci.c:#include <mach/cputype.h>
drivers/usb/musb/davinci.c:#include <mach/hardware.h>
I'm adding Ravi B to the loop here for those.
--
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/20130115/b9e42659/attachment.sig>
^ permalink raw reply
* [PATCH v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller
From: Artem Bityutskiy @ 2013-01-15 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356901207-13536-1-git-send-email-linux@prisktech.co.nz>
On Mon, 2012-12-31 at 10:00 +1300, Tony Prisk wrote:
> This patch adds support for the Wondermedia serial flash controller
> found on WM8505, WM8650 and WM8850 SoCs.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> v2: Whitespace tidyup
Hi, would you please take a look at these warings, identified by aiaiai:
Successfully built configuration "x86_64_defconfig,x86_64,", results:
--- before_patching.log
+++ after_patching.log
@@ @@
+drivers/mtd/devices/wmt_sflash.c: In function ?sf_read?:
+drivers/mtd/devices/wmt_sflash.c:425:9: warning: format ?%d? expects argument of type ?int?, but argument 4 has type ?size_t? [-Wformat]
+drivers/mtd/devices/wmt_sflash.c: In function ?sf_sector_write?:
+drivers/mtd/devices/wmt_sflash.c:442:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
+drivers/mtd/devices/wmt_sflash.c:442:24: warning: cast removes address space of expression [sparse]
+drivers/mtd/devices/wmt_sflash.c:458:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
+drivers/mtd/devices/wmt_sflash.c:458:31: warning: incorrect type in argument 1 (different address spaces) [sparse]
+drivers/mtd/devices/wmt_sflash.c:458:31: expected void volatile [noderef] <asn:2>*dst [sparse]
+drivers/mtd/devices/wmt_sflash.c:458:31: got unsigned char [usertype] *<noident> [sparse]
+drivers/mtd/devices/wmt_sflash.c:465:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
+drivers/mtd/devices/wmt_sflash.c:465:39: warning: incorrect type in argument 1 (different address spaces) [sparse]
+drivers/mtd/devices/wmt_sflash.c:465:39: expected void volatile [noderef] <asn:2>*dst [sparse]
+drivers/mtd/devices/wmt_sflash.c:465:39: got unsigned char [usertype] *<noident> [sparse]
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/b6b91162/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/2] cpufreq: add imx6q-cpufreq driver
From: Shawn Guo @ 2013-01-15 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F427A7.7000203@boundarydevices.com>
Hi Eric,
On Mon, Jan 14, 2013 at 08:43:35AM -0700, Eric Nelson wrote:
> >+ /* scaling up? scale voltage before frequency */
> >+ if (freqs.new > freqs.old) {
> >+ ret = regulator_set_voltage_tol(arm_reg, volt, 0);
> >+ if (ret) {
> >+ dev_err(cpu_dev, "failed to scale voltage up: %d\n", ret);
> >+ return ret;
> >+ }
> >+
> >+ /*
> >+ * Need to increase vddpu and vddsoc for safety
> >+ * if we are about to run at 1.2 GHz.
> >+ */
> >+ if (freqs.new == FREQ_1P2_GHZ / 1000) {
> >+ regulator_set_voltage_tol(pu_reg,
> >+ PU_SOC_VOLTAGE_HIGH, 0);
> >+ regulator_set_voltage_tol(soc_reg,
> >+ PU_SOC_VOLTAGE_HIGH, 0);
> >+ }
>
> I believe you need a delay here to let the LDOs ramp before changing
> the CPU frequency.
>
> According to the i.MX6Q reference manual, with the factory default
> step times in PMU_MISC2 and the maximum voltage swing is
> 1.25V (1.2GHz) - 0.95V (400MHz) == 0.325V
>
> or 13 steps at 25mV.
>
> The default step time is 0.000021333s (512 clocks at 24MHz), so
> the worst case delay needed is ~280uS.
>
> This could also be done in the regulator driver, but that may
> require multiple delays if multiple rails are changed.
>
I initially thought that regulator driver should take care of it. But
now I agree with you that we can do it here for the least latency.
Will roll it into v4. Thanks.
Shawn
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Marc Zyngier @ 2013-01-15 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115142747.GP11529@redhat.com>
On 15/01/13 14:27, Gleb Natapov wrote:
> On Tue, Jan 15, 2013 at 01:46:04PM +0000, Marc Zyngier wrote:
>> On 15/01/13 13:34, Gleb Natapov wrote:
>>> On Tue, Jan 15, 2013 at 01:29:40PM +0000, Marc Zyngier wrote:
>>>> On 15/01/13 13:18, Gleb Natapov wrote:
>>>>> On Tue, Jan 08, 2013 at 01:40:05PM -0500, Christoffer Dall wrote:
>>>>>> When the guest accesses I/O memory this will create data abort
>>>>>> exceptions and they are handled by decoding the HSR information
>>>>>> (physical address, read/write, length, register) and forwarding reads
>>>>>> and writes to QEMU which performs the device emulation.
>>>>>>
>>>>>> Certain classes of load/store operations do not support the syndrome
>>>>>> information provided in the HSR and we therefore must be able to fetch
>>>>>> the offending instruction from guest memory and decode it manually.
>>>>>>
>>>>>> We only support instruction decoding for valid reasonable MMIO operations
>>>>>> where trapping them do not provide sufficient information in the HSR (no
>>>>>> 16-bit Thumb instructions provide register writeback that we care about).
>>>>>>
>>>>>> The following instruction types are NOT supported for MMIO operations
>>>>>> despite the HSR not containing decode info:
>>>>>> - any Load/Store multiple
>>>>>> - any load/store exclusive
>>>>>> - any load/store dual
>>>>>> - anything with the PC as the dest register
>>>>>>
>>>>>> This requires changing the general flow somewhat since new calls to run
>>>>>> the VCPU must check if there's a pending MMIO load and perform the write
>>>>>> after userspace has made the data available.
>>>>>>
>>>>>> Rusty Russell fixed a horrible race pointed out by Ben Herrenschmidt:
>>>>>> (1) Guest complicated mmio instruction traps.
>>>>>> (2) The hardware doesn't tell us enough, so we need to read the actual
>>>>>> instruction which was being exectuted.
>>>>>> (3) KVM maps the instruction virtual address to a physical address.
>>>>>> (4) The guest (SMP) swaps out that page, and fills it with something else.
>>>>>> (5) We read the physical address, but now that's the wrong thing.
>>>>> How can this happen?! The guest cannot reuse physical page before it
>>>>> flushes it from all vcpus tlb cache. For that it needs to send
>>>>> synchronous IPI to all vcpus and IPI will not be processed by a vcpu
>>>>> while it does emulation.
>>>>
>>>> I don't know how this works on x86, but a KVM/ARM guest can definitely
>>>> handle an IPI.
>>>>
>>> How can a vcpu handle an IPI while it is not in a guest mode?
>>
>> I think there is some misunderstanding. A guest IPI is of course handled
>> while running the guest. You completely lost me here.
> You need IPI from one guest vcpu to another to invalidate its TLB on
> x86. That prevents the race from happening there.
We don't need this on ARM (starting with v7, v6 is an entirely different
story, and we do not support KVM on v6).
The TLB is propagated by the HW using the following (pseudocode) sequence:
tlb_invalidate VA
barrier
Leaving the barrier guaranties that all TLB invalidations have been
propagated.
>>
>>>> Furthermore, TLB invalidation doesn't require an IPI on ARMv7 (unless
>>>> we're doing some set/way operation which is handled separately).
>>>>
>>> What prevents a page to be swapped out while code is fetched from it?
>>
>> Why would you prevent it? TLB invalidation is broadcast by the HW. If
>> you swap a page out, you flag the entry as invalid and invalidate the
>> corresponding TLB. If you hit it, you swap the page back in.
>>
> There is no IPI (or anything that requires response from cpu whose TLB
> is invalidated) involved in invalidating remote TLB?
No. The above sequence is all you have to do.
This is why the above race is a bit hairy. A vcpu will happily
invalidate TLBs, but as the faulting vcpu already performed the
translation, we're screwed.
Thankfully, this is a case that only matters when we have to emulate an
MMIO operation that is not automatically decoded by the HW. They are
rare (the Linux kernel doesn't use them). In this case, we stop the
world (IPI).
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
From: Arnd Bergmann @ 2013-01-15 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F56697.9060803@ti.com>
On Tuesday 15 January 2013, kishon wrote:
> Good point :-). Currently, none of the OMAP platforms have multiple
> control modules and it doesn't seem to be in the future (AFAIK). While
> it might be simpler to support multiple control devices with phandle, it
> might face the same complications as faced by the USB PHY framework for
> non-dt boot.
>
Maybe you can put the phandle into the binding then but don't use it
until hardware actually requires it. If anything needs it, then we
can always change the code later, but it's harder to change the
binding.
Arnd
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Christoffer Dall @ 2013-01-15 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115142747.GP11529@redhat.com>
On Tue, Jan 15, 2013 at 9:27 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Jan 15, 2013 at 01:46:04PM +0000, Marc Zyngier wrote:
>> On 15/01/13 13:34, Gleb Natapov wrote:
>> > On Tue, Jan 15, 2013 at 01:29:40PM +0000, Marc Zyngier wrote:
>> >> On 15/01/13 13:18, Gleb Natapov wrote:
>> >>> On Tue, Jan 08, 2013 at 01:40:05PM -0500, Christoffer Dall wrote:
>> >>>> When the guest accesses I/O memory this will create data abort
>> >>>> exceptions and they are handled by decoding the HSR information
>> >>>> (physical address, read/write, length, register) and forwarding reads
>> >>>> and writes to QEMU which performs the device emulation.
>> >>>>
>> >>>> Certain classes of load/store operations do not support the syndrome
>> >>>> information provided in the HSR and we therefore must be able to fetch
>> >>>> the offending instruction from guest memory and decode it manually.
>> >>>>
>> >>>> We only support instruction decoding for valid reasonable MMIO operations
>> >>>> where trapping them do not provide sufficient information in the HSR (no
>> >>>> 16-bit Thumb instructions provide register writeback that we care about).
>> >>>>
>> >>>> The following instruction types are NOT supported for MMIO operations
>> >>>> despite the HSR not containing decode info:
>> >>>> - any Load/Store multiple
>> >>>> - any load/store exclusive
>> >>>> - any load/store dual
>> >>>> - anything with the PC as the dest register
>> >>>>
>> >>>> This requires changing the general flow somewhat since new calls to run
>> >>>> the VCPU must check if there's a pending MMIO load and perform the write
>> >>>> after userspace has made the data available.
>> >>>>
>> >>>> Rusty Russell fixed a horrible race pointed out by Ben Herrenschmidt:
>> >>>> (1) Guest complicated mmio instruction traps.
>> >>>> (2) The hardware doesn't tell us enough, so we need to read the actual
>> >>>> instruction which was being exectuted.
>> >>>> (3) KVM maps the instruction virtual address to a physical address.
>> >>>> (4) The guest (SMP) swaps out that page, and fills it with something else.
>> >>>> (5) We read the physical address, but now that's the wrong thing.
>> >>> How can this happen?! The guest cannot reuse physical page before it
>> >>> flushes it from all vcpus tlb cache. For that it needs to send
>> >>> synchronous IPI to all vcpus and IPI will not be processed by a vcpu
>> >>> while it does emulation.
>> >>
>> >> I don't know how this works on x86, but a KVM/ARM guest can definitely
>> >> handle an IPI.
>> >>
>> > How can a vcpu handle an IPI while it is not in a guest mode?
>>
>> I think there is some misunderstanding. A guest IPI is of course handled
>> while running the guest. You completely lost me here.
> You need IPI from one guest vcpu to another to invalidate its TLB on
> x86. That prevents the race from happening there.
>
>>
>> >> Furthermore, TLB invalidation doesn't require an IPI on ARMv7 (unless
>> >> we're doing some set/way operation which is handled separately).
>> >>
>> > What prevents a page to be swapped out while code is fetched from it?
>>
>> Why would you prevent it? TLB invalidation is broadcast by the HW. If
>> you swap a page out, you flag the entry as invalid and invalidate the
>> corresponding TLB. If you hit it, you swap the page back in.
>>
> There is no IPI (or anything that requires response from cpu whose TLB
> is invalidated) involved in invalidating remote TLB?
>
>
no there's not, the hardware broadcasts the TLB invalidate operation.
-Christoffer
^ permalink raw reply
* [PATCH] clk: mvebu/clk-cpu.c: fix memory leakage
From: Cong Ding @ 2013-01-15 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F563EC.3030804@free-electrons.com>
On Tue, Jan 15, 2013 at 03:13:00PM +0100, Gregory CLEMENT wrote:
> Dear Cong Ding,
>
> On 01/14/2013 06:18 PM, Cong Ding wrote:
> > the variable cpuclk and clk_name should be properly freed.
> >
>
> Thanks for reporting this memory leak and for your patch but I think
> we could do even better, see below:
>
> > Signed-off-by: Cong Ding <dinggnu@gmail.com>
> > ---
> > drivers/clk/mvebu/clk-cpu.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> > index ff004578..1a0d84f 100644
> > --- a/drivers/clk/mvebu/clk-cpu.c
> > +++ b/drivers/clk/mvebu/clk-cpu.c
> > @@ -124,7 +124,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
> >
> > clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
> > if (WARN_ON(!clks))
> > - return;
> > + goto clks_out;
> >
> > for_each_node_by_type(dn, "cpu") {
> > struct clk_init_data init;
> > @@ -134,11 +134,11 @@ void __init of_cpu_clk_setup(struct device_node *node)
> > int cpu, err;
> >
> > if (WARN_ON(!clk_name))
> > - return;
> > + goto clk_name_out;
>
> I agree
>
> >
> > err = of_property_read_u32(dn, "reg", &cpu);
> > if (WARN_ON(err))
> > - return;
> > + goto bail_out;
>
> I agree
>
> >
> > sprintf(clk_name, "cpu%d", cpu);
> > parent_clk = of_clk_get(node, 0);
> > @@ -166,7 +166,10 @@ void __init of_cpu_clk_setup(struct device_node *node)
> >
> > return;
> > bail_out:
> > + kfree(clk_name);
>
> Here you free only one clk_name whereas we could have previous clk_name which have
> been already allocated during the for_each_node_by_type loop.
>
> A more annoying thing is that you use clk_name whereas it is only valid in the
> for_each_node_by_type statement and then this patch breaks the compilation:
>
> drivers/clk/mvebu/clk-cpu.c: In function ?of_cpu_clk_setup?:
> drivers/clk/mvebu/clk-cpu.c:169:8: error: ?clk_name? undeclared (first use in this function)
> drivers/clk/mvebu/clk-cpu.c:169:8: note: each undeclared identifier is reported only once for each function it appears in
sorry for the mistake, I am sending version 2.
thanks,
- cong
^ permalink raw reply
* [kvmarm] [PATCH v5 06/14] KVM: ARM: Inject IRQs and FIQs from userspace
From: Christoffer Dall @ 2013-01-15 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA8gzD4F4BPKR_dSDDD-iyv0ONt6H+yrj_nHifeCFBfpPA@mail.gmail.com>
On Tue, Jan 15, 2013 at 9:04 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 15 January 2013 12:52, Gleb Natapov <gleb@redhat.com> wrote:
>> On Tue, Jan 15, 2013 at 12:15:01PM +0000, Peter Maydell wrote:
>>> On 15 January 2013 09:56, Gleb Natapov <gleb@redhat.com> wrote:
>>> >> ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
>>> > CPU level interrupt should use KVM_INTERRUPT instead.
>>>
>>> No, that would be wrong. KVM_INTERRUPT is for interrupts which must be
>>> delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which
>>> can be fed to the kernel asynchronously. It happens that on x86 "must be
>>> delivered synchronously" and "not going to in kernel irqchip" are the same, but
>>> this isn't true for other archs. For ARM all our interrupts can be fed
>>> to the kernel asynchronously, and so we use KVM_IRQ_LINE in all
>>> cases.
>
>> I do no quite understand what you mean by synchronously and
>> asynchronously.
>
> Synchronously: the vcpu has to be stopped and userspace then
> feeds in the interrupt to be taken when the guest is resumed.
> Asynchronously: any old thread can tell the kernel there's an
> interrupt, and the guest vcpu then deals with it when needed
> (the vcpu thread may leave the guest but doesn't come out of
> the host kernel to qemu).
>
>> The difference between KVM_INTERRUPT and KVM_IRQ_LINE line
>> is that former is used when destination cpu is known to userspace later
>> is used when kernel code is involved in figuring out the destination.
>
> This doesn't match up with Avi's explanation at all.
>
>> The
>> injections themselves are currently synchronous for both of them on x86
>> and ARM. i.e vcpu is kicked out from guest mode when interrupt need to
>> be injected into a guest and vcpu state is changed to inject interrupt
>> during next guest entry. In the near feature x86 will be able to inject
>> interrupt without kicking vcpu out from the guest mode does ARM plan to
>> do the same? For GIC interrupts or for IRQ/FIQ or for both?
>>
>>> There was a big discussion thread about this on kvm and qemu-devel last
>>> July (and we cleaned up some of the QEMU code to not smoosh together
>>> all these different concepts under "do I have an irqchip or not?").
>> Do you have a pointer?
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
> and there was a later longer (but less clear) thread which included
> this mail from Avi:
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
> basically explaining that the reason for the weird synchronous
> KVM_INTERRUPT API is that it's emulating a weird synchronous
> hardware interface which is specific to x86. ARM doesn't have
> a synchronous interface in the same way, so it's much more
> straightforward to use KVM_IRQ_LINE.
>
Also, this code has been reviewed numerous times by the KVM community
and as Peter points out has also been discussed in detail.
Could we please not change this API in the last second?
-Christoffer
^ permalink raw reply
* [RFC PATCH 0/7] usb: musb: add driver for control module
From: kishon @ 2013-01-15 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301151341.08297.arnd@arndb.de>
Hi Arnd,
On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
>> Added a new driver for the usb part of control module. This has an API
>> to power on the USB2 phy and an API to write to the mailbox depending on
>> whether MUSB has to act in host mode or in device mode.
>>
>> Writing to control module registers for doing the above task which was
>> previously done in omap glue and in omap-usb2 phy is removed.
>>
>> Also added the dt data to get MUSB working in OMAP platforms.
>> This series has patches for both drivers and ARCH folders, so If it has to
>> be split I'll do it.
>>
>
> The series looks good to me, I just had a minor comment on one patch.
>
> One a somewhat related topic, I wonder whether there are any plans
> on your side to change this driver to support multiple bus glues
> to be built for one kernel image. With a multiplatform kernel, we
> may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
We don't have plans as of now. I actually don't expect any changes in
the driver other than the Kconfig changes. Anyways the probe of glue's
other than the platform it's running won't get called. right Felipe?
Thanks
Kishon
^ 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