* [kvmarm] [PATCH v6 02/13] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl
From: Peter Maydell @ 2013-01-17 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116180028.29393.62418.stgit@ubuntu>
On 16 January 2013 18:00, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl
Patch subject needs updating with new name of this ioctl
(KVM_ARM_SET_DEVICE_ADDR)...
> On ARM (and possibly other architectures) some bits are specific to the
> model being emulated for the guest and user space needs a way to tell
> the kernel about those bits. An example is mmio device base addresses,
> where KVM must know the base address for a given device to properly
> emulate mmio accesses within a certain address range or directly map a
> device with virtualiation extensions into the guest address space.
"virtualization", while I'm here.
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -65,6 +65,19 @@ struct kvm_regs {
> #define KVM_ARM_TARGET_CORTEX_A15 0
> #define KVM_ARM_NUM_TARGETS 1
>
> +/* KVM_SET_DEVICE_ADDRESS ioctl id encoding */
> +#define KVM_DEVICE_TYPE_SHIFT 0
> +#define KVM_DEVICE_TYPE_MASK (0xffff << KVM_DEVICE_TYPE_SHIFT)
> +#define KVM_DEVICE_ID_SHIFT 16
> +#define KVM_DEVICE_ID_MASK (0xffff << KVM_DEVICE_ID_SHIFT)
...and this comment and I guess these constant names presumably
should have "ARM" in them?
> +/* Available with KVM_CAP_SET_DEVICE_ADDR */
KVM_CAP_ARM_SET_DEVICE_ADDR.
-- PMM
^ permalink raw reply
* [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
From: Tony Lindgren @ 2013-01-17 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7D535.6030205@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [130117 02:44]:
> On 01/17/2013 11:35 AM, Luciano Coelho wrote:
> > This out-of-tree code doesn't explain why we need to do the
> > enable/disable in the board file. We just need to do things a bit
> > differently in the driver. I'll start cleaning all this stuff up for
> > -next pretty soon.
> >
> > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so
> > that TI-ST at least works on Panda? Simply reverting the gpio removal
> > patch doesn't help, because we also need to handle the UART2 muxing
> > (which my patch does as well).
>
> I don't see better way to fix this either. In any case, I give you my:
>
> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
So what is actually broken? The horrible bluetooth muxing over serial
port? If so, let's rather fix it properly than even attempt to fix
it as it seems that it's been broken for two merge windows now.
Also, let's just do absolutely minimal board-*.c file fixes now.
This thing should be just moved to use DT so we can flip over omap4
to be DT only and drop estimated 5k LOC from mach-omap2.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] clockevents: decouple broadcast mechanism from drivers
From: Mark Rutland @ 2013-01-17 17:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
These are the generic timer patches I posted a few days ago [1], with
the fixes you requested previously.
Please could you pull these into your tree, and create a public branch
for me to base my other patches on?
Thanks,
Mark.
[1] https://lkml.org/lkml/2013/1/14/276
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://linux-arm.org/linux-mr.git for-tglx/timer-broadcast
for you to fetch changes up to a9a71292273e2a9ca694ca37aad4b61a3a1fcdee:
clockevents: Add generic timer broadcast function (2013-01-14 16:55:01 +0000)
----------------------------------------------------------------
Mark Rutland (2):
clockevents: Add generic timer broadcast receiver
clockevents: Add generic timer broadcast function
include/linux/clockchips.h | 9 +++++++++
kernel/time/Kconfig | 4 ++++
kernel/time/tick-broadcast.c | 28 ++++++++++++++++++++++++++++
3 files changed, 41 insertions(+)
^ permalink raw reply
* [PATCH v6 13/15] KVM: ARM: Handle I/O aborts
From: Christoffer Dall @ 2013-01-17 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F828AC.2050307@arm.com>
On Thu, Jan 17, 2013 at 11:37 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 16/01/13 17:59, 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. We don't support decoding these (patches
>> are available elsewhere), so we report an error to user space in this case.
>>
>> 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.
>>
>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>> Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
>> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>
> [...]
>
>> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
>> index 04a9705..702743e 100644
>> --- a/arch/arm/kvm/interrupts.S
>> +++ b/arch/arm/kvm/interrupts.S
>> @@ -192,6 +192,44 @@ after_vfp_restore:
>> mov r0, r1 @ Return the return code
>> bx lr @ return to IOCTL
>>
>> +
>> +/********************************************************************
>> + * Translate VA to PA
>> + *
>> + * u64 __kvm_va_to_pa(struct kvm_vcpu *vcpu, u32 va, bool priv)
>> + *
>> + * Arguments:
>> + * r0: pointer to vcpu struct
>> + * r1: virtual address to map (rounded to page)
>> + * r2: 1 = P1 (read) mapping, 0 = P0 (read) mapping.
>> + * Returns 64 bit PAR value.
>> + */
>> +ENTRY(__kvm_va_to_pa)
>> + push {r4-r12}
>> +
>> + @ Fold flag into r1, easier than using stack.
>> + cmp r2, #0
>> + movne r2, #1
>> + orr r1, r1, r2
>> +
>> + @ This swaps too many registers, but we're in the slow path anyway.
>> + read_cp15_state store_to_vcpu = 0
>> + write_cp15_state read_from_vcpu = 1
>> +
>> + ands r2, r1, #1
>> + bic r1, r1, r2
>> + mcrne p15, 0, r1, c7, c8, 0 @ VA to PA, ATS1CPR
>> + mcreq p15, 0, r1, c7, c8, 2 @ VA to PA, ATS1CUR
>> + isb
>> +
>> + @ Restore host state.
>> + read_cp15_state store_to_vcpu = 1
>> + write_cp15_state read_from_vcpu = 0
>> +
>> + mrrc p15, 0, r0, r1, c7 @ PAR
>> + pop {r4-r12}
>> + bx lr
>> +
>
> Do we still need this function? Now that the MMIO emulation is gone,
> there should be no need to perform a manual translation.
>
> I can't even find a caller for it either.
>
I'm trying to leave bits and pieces of the emulation code in here in
hope that it will spawn itself into a glorious unified solution that
decodes everything and that everybody will be happy with :)
I'll remove it. Thanks.
-Christoffer
^ permalink raw reply
* [PATCH 3/3] ARM: omap2: use get_auxcr for aux ctrl register read
From: Tony Lindgren @ 2013-01-17 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7B6C0.5090102@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130117 00:33]:
> On Thursday 17 January 2013 08:23 AM, Rob Herring wrote:
> >From: Rob Herring <rob.herring@calxeda.com>
> >
> >Use get_auxcr instead of inline assembly to read the CP15 aux ctrl
> >register.
> >
> >Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> >Cc: Kevin Hilman <khilman@ti.com>
> >Cc: Tony Lindgren <tony@atomide.com>
> >---
> This patch and the rest of the series looks fine to me.
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The series looks good to me too:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
From: Tony Lindgren @ 2013-01-17 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358422231-24736-20-git-send-email-rogerq@ti.com>
* Roger Quadros <rogerq@ti.com> [130117 03:34]:
> We don't need multiple aliases for the OMAP USB host clocks and neither
> the dummy clocks so remove them.
It's best that Paul queues this and the next patch as these clock alias
clean-up patches can be done separately. That way the dependency between
arch/arm/*omap* code is cut away as these files should be moved to live
under drivers/clk/omap.
Regards,
Tony
> CC: Paul Walmsley <paul@pwsan.com>
> CC: Rajendra Nayak <rnayak@ti.com>
> CC: Benoit Cousson <b-cousson@ti.com>
> CC: Mike Turquette <mturquette@linaro.com>
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Acked-by: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/cclock3xxx_data.c | 11 -----------
> 1 files changed, 0 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 6ef8758..b58ec96 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -3291,8 +3291,6 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "cpefuse_fck", &cpefuse_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "ts_fck", &ts_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> - CLK("usbhs_omap", "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> - CLK("usbhs_tll", "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "core_96m_fck", &core_96m_fck, CK_3XXX),
> CLK(NULL, "mmchs3_fck", &mmchs3_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "mmchs2_fck", &mmchs2_fck, CK_3XXX),
> @@ -3329,8 +3327,6 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "pka_ick", &pka_ick, CK_34XX | CK_36XX),
> CLK(NULL, "core_l4_ick", &core_l4_ick, CK_3XXX),
> CLK(NULL, "usbtll_ick", &usbtll_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> - CLK("usbhs_omap", "usbtll_ick", &usbtll_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> - CLK("usbhs_tll", "usbtll_ick", &usbtll_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK("omap_hsmmc.2", "ick", &mmchs3_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "mmchs3_ick", &mmchs3_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
> @@ -3393,17 +3389,10 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> - CLK("usbhs_omap", "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "utmi_p1_gfclk", &dummy_ck, CK_3XXX),
> CLK(NULL, "utmi_p2_gfclk", &dummy_ck, CK_3XXX),
> CLK(NULL, "xclk60mhsp1_ck", &dummy_ck, CK_3XXX),
> CLK(NULL, "xclk60mhsp2_ck", &dummy_ck, CK_3XXX),
> - CLK(NULL, "usb_host_hs_utmi_p1_clk", &dummy_ck, CK_3XXX),
> - CLK(NULL, "usb_host_hs_utmi_p2_clk", &dummy_ck, CK_3XXX),
> - CLK("usbhs_omap", "usb_tll_hs_usb_ch0_clk", &dummy_ck, CK_3XXX),
> - CLK("usbhs_omap", "usb_tll_hs_usb_ch1_clk", &dummy_ck, CK_3XXX),
> - CLK("usbhs_tll", "usb_tll_hs_usb_ch0_clk", &dummy_ck, CK_3XXX),
> - CLK("usbhs_tll", "usb_tll_hs_usb_ch1_clk", &dummy_ck, CK_3XXX),
> CLK(NULL, "init_60m_fclk", &dummy_ck, CK_3XXX),
> CLK(NULL, "usim_fck", &usim_fck, CK_3430ES2PLUS | CK_36XX),
> CLK(NULL, "gpt1_fck", &gpt1_fck, CK_3XXX),
> --
> 1.7.4.1
>
^ permalink raw reply
* [PATCH v7 01/22] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
From: Tony Lindgren @ 2013-01-17 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301171016090.1339-100000@iolanthe.rowland.org>
* Alan Stern <stern@rowland.harvard.edu> [130117 07:19]:
> On Thu, 17 Jan 2013, Roger Quadros wrote:
>
> > Let's have a single platform data structure for the OMAP's High-Speed
> > USB host subsystem instead of having 3 separate ones i.e. one for
> > board data, one for USB Host (UHH) module and one for USB-TLL module.
> >
> > This makes the code much simpler and avoids creating multiple copies of
> > platform data.
> >
> > CC: Alan Stern <stern@rowland.harvard.edu>
> >
> > Signed-off-by: Roger Quadros <rogerq@ti.com>
>
> For the ehci-omap.c part:
>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
If Samuel acks this patch, I can apply just this patch alone on v3.8-rc3
into an immutable branch omap-for-v3.9/board-usb so we all merge it in
as needed.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/7] reset: Add reset controller API
From: Stephen Warren @ 2013-01-17 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358419524.2411.126.camel@pizza.hi.pengutronix.de>
On 01/17/2013 03:45 AM, Philipp Zabel wrote:
> Hi Stephen,
>
> Am Mittwoch, den 16.01.2013, 15:15 -0700 schrieb Stephen Warren:
>> On 01/16/2013 09:13 AM, Philipp Zabel wrote:
>>> This adds a simple API for devices to request being reset
>>> by separate reset controller hardware and implements the
>>> reset signal device tree binding.
>>
>>
>>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>>
>>> +obj-$(CONFIG_RESET_CONTROLLER) += core.o
>>> +
>>
>> nit: blank line at EOF.
>
> Ok.
>
>>> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
>>
>>> +/**
>>> + * reset_control_reset - reset the controlled device
>>> + * @rstc: reset controller
>>> + */
>>> +int reset_control_reset(struct reset_control *rstc)
>>
>> What time period is the reset signal asserted for; should there be a
>> parameter to control this?
>
> "The reset controller knows".
>
> On i.MX, the SRC does all necessary things in hardware (and optionally
> causes an interrupt to signal when it's ready - right now the SRC driver
> just polls for the reset line to deassert).
OK, I guess that does make sense. As you say, for an on-SoC reset
controller that auto-clears the reset bit, it obviously has the timing
embedded in HW, and for any other kind of reset controller, we can just
provide configuration to the controller somehow.
> For reset controllers that need to be manually asserted/deasserted, and
> still want to provide the .reset callback, we should think about some
> timing configuration. But IMHO that should be separate from the API.
>
> I've thought about adding an example gpio-reset controller driver, which
> knows about the necessary delays and just toggles gpios. This could be
> represented in the device tree as follows:
>
> gpio_reset: gpio_reset {
> compatible = "gpio-reset"
> gpios = <&gpioa 0 0>, <&gpioc 5 0>, <&gpiod 3 1>;
> reset-delays = <10>, <100>, <50>;
> #reset-cells = <1>;
> };
>
> device-to-be-reset {
> resets = <&gpio_reset 2>; /* GPIOD3, active-low, 50ms */
> };
>
> Or one could add another reset-cell to configure the delay:
>
> gpio_reset: gpio_reset {
> compatible = "gpio-reset"
> gpios = <&gpioa 0 0>, <&gpioc 5 0>, <&gpiod 3 1>;
> #reset-cells = <2>;
> };
>
> device-to-be-reset {
> resets = <&gpio_reset 2 50>; /* GPIOD3, active-low, 50ms */
> };
>
> I'd prefer the former over the latter. In any case, I think the timing
> information should reside either in the reset controller or in the
> framework.
Sure. I think the choice of properties in the controller node vs. extra
#reset-cells is probably an individual design decision for the specific
controller driver and DT binding; it would even be possible to have one
driver support either based on its #reset-cells value, but probably
over-complex and not worth doing. Although actually, when you start
thinking about DT overlays and so on, extra #reset-cells begins to make
more sense, since the values are distributed, which makes it easier to
set them from the overlay DT file...
^ permalink raw reply
* [PATCH 0/4] gpio: introduce descriptor-based interface
From: Steven King @ 2013-01-17 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7E83E.8000105@uclinux.org>
On Thursday 17 January 2013 4:02:06 am Greg Ungerer wrote:
> Hi Linus,
>
> (My gerg at snapgear.com email no longer gets to me, gerg at uclinux.org is
> the best direct email for me now).
>
> On 01/17/2013 09:15 PM, Linus Walleij wrote:
> > On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> I've tried to find platforms that don't yet use GPIOLIB and fortunately
> >> there are very few left:
> >>
> >> I found two that provide the generic gpio interfaces when gpiolib
> >> is disabled, but use gpiolib otherwise for the same hardware,
> >> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h.
> >> I would assume that we can simply remove the non-gpiolib shortcut
> >> here at cost of a small overhead.
> >
> > Geert/Greg: interested in looking into this issue?
> >
> > The GPIO maintainers want to get rid of non-gpiolib platforms.
>
> Steven King did most of the ColdFire GPIO work (CC'ed on this).
> Steven: are you happy to drop the non-gpiolib support?
>
> Regards
> Greg
Well, my concern is the small, single chip platforms with limited ram and
speeds measured in MHz. My goal was that these platforms that had very basic
gpio needs, no offboard gpio, just toggling a few pins for spi or whatever,
could do that without pulling in a bunch of code they dont need. I realize
that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its
no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and
even more constraining, 2 megs of flash) need all the help they can get.
I haven't been keeping up with the kernel list of late, can someone point me
to what''s being discussed so I can see what were talking about here?
^ permalink raw reply
* [PATCH V4 5/5] ARM: tegra20: cpuidle: apply coupled cpuidle for powered-down mode
From: Stephen Warren @ 2013-01-17 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358389815.1667.32.camel@jlo-ubuntu-64.nvidia.com>
On 01/16/2013 07:30 PM, Joseph Lo wrote:
> On Thu, 2013-01-17 at 05:31 +0800, Stephen Warren wrote:
>> On 01/16/2013 11:55 AM, Colin Cross wrote:
>>> On Wed, Jan 16, 2013 at 12:11 AM, Joseph Lo <josephl@nvidia.com> wrote:
>>>> The "powered-down" cpuidle mode of Tegra20 needs the CPU0 be the last one
>>>> core to go into this mode before other core. The coupled cpuidle framework
>>>> can help to sync the MPCore to coupled state then go into "powered-down"
>>>> idle mode together. The driver can just assume the MPCore come into
>>>> "powered-down" mode at the same time. No need to take care if the CPU_0
>>>> goes into this mode along and only can put it into safe idle mode (WFI).
>>>>
>>>> The powered-down state of Tegra20 requires power gating both CPU cores.
>>>> When the secondary CPU requests to enter powered-down state, it saves
>>>> its own contexts and then enters WFI for waiting CPU0 in the same state.
>>>> When the CPU0 requests powered-down state, it attempts to put the secondary
>>>> CPU into reset to prevent it from waking up. Then power down both CPUs
>>>> together and power off the cpu rail.
>>>>
>>>> Be aware of that, you may see the legacy power state "LP2" in the code
>>
>> Colin, since you only raised a few small issues on this series, does
>> that mean you're OK with it once those issues are fixed?
>>
>> Joseph, we'll be merging Tegra114 in the near future. How will this
>> patch series affect Tegra114? Will the cpuidle driver simply fail to
>> register on Tegra114 (which would be fine until we explicitly add
>> support), or would we need to disable cpuidle in Kconfig to get a
>> working Tegra114 kernel. Does this patch series affect the answer to the
>> previous question? Thanks.
>>
> Stephen,
>
> This patch series won't affect Tegra114. I think I need to add a simple
> cpuidle driver for Tegra114 to support just WFI state first.
Ah right, I see that tegra_cpuidle_init() already switches on the SoC
version and doesn't do anything for unknown SoCs.
> And I am going do some re-works about CPUs and cluster power status sync
> functions that be introduced recently[1] for CPU hotplug, idle and
> secondary booting in Tegra tree. I hope I can hide all the power related
> function behind that and make the CPU idle driver be more generic for
> all Tegra series.
>
> Before that re-works, I will still keep upstream the platform suspend
> function for Tegra.
> (If I am not in the right direction, please pull me back.)
That's all fine; I just wanted to make sure that applying these patches
wouldn't break anything in the new Tegra114 support.
^ permalink raw reply
* [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module
From: Sergei Shtylyov @ 2013-01-17 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F56703.1060202@ti.com>
Hello.
On 01/15/2013 05:26 PM, kishon wrote:
>> On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
>>> A seperate driver has been added to handle the usb part of control
>>> module. A device for the above driver is created here, using the register
>>> address information to be used by the driver for powering on the PHY and
>>> for writing to the mailbox.
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> arch/arm/mach-omap2/devices.c | 50
>>> +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 50 insertions(+)
>>> diff --git a/arch/arm/mach-omap2/devices.c
>>> b/arch/arm/mach-omap2/devices.c
>>> index 5e304d0..a761faf4 100644
>>> --- a/arch/arm/mach-omap2/devices.c
>>> +++ b/arch/arm/mach-omap2/devices.c
>> [...]
>>> @@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
>>> #endif
>>> }
>>>
>>> +#if (defined(CONFIG_OMAP_CONTROL_USB) || \
>>> + defined(CONFIG_OMAP_CONTROL_USB_MODULE))
>> () around || not needed, and you're indenting the second line too much.
>>> +static inline void __init omap_init_control_usb(void)
>>> +{
>>> + int ret = 0;
>> Initializer not needed.
>>> +
>>> + if (cpu_is_omap44xx()) {
>>> + ret = platform_device_register(&omap4_control_usb);
>>> + if (ret)
>>> + pr_err("Error registering omap_control_usb device: %d\n"
>>> + , ret);
>> Please leave the comma on the previous line.
> Sure. I'll fix it.
Actually, you can use #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB) now instead of
your above constuct.
WBR, Sergei
^ permalink raw reply
* [PATCH] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
From: Peter Korsgaard @ 2013-01-17 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <loom.20130117T105358-639@post.gmane.org>
>>>>> "Michal" == Michal Bachraty <michal.bachraty@gmail.com> writes:
Hi Michael,
Michal> I made changes to cpsw driver two weeks ago, which add support
Michal> for reading MAC address from CPU and also I posted it to
Michal> review. You can find patch here :
Michal> https://patchwork.kernel.org/patch/1966481/ I will create
Michal> updated patch next week, depended on reactions. Can you try
Michal> that patch? I'll be glad to hear your opinion.
Thanks, I missed that patch. Functionality wise the patches do the same,
but I must say I find my patch cleaner, as it doesn't involve any new dt
bindings or access to the am33xx specific control module registers from
the cpsw driver.
The way I've handled it is similar to how it is done on atleast one
other arm subarchicture, see
arch/arm/mach-mxs/mach-mxs.c::update_fec_mac_prop()
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v5 06/14] ARM: EXYNOS: add System MMU definition to DT
From: Will Deacon @ 2013-01-17 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116.184321.179736289870581833.hdoyu@nvidia.com>
Hi Hiroshi,
On Wed, Jan 16, 2013 at 04:43:21PM +0000, Hiroshi Doyu wrote:
> Will Deacon <will.deacon@arm.com> wrote @ Wed, 16 Jan 2013 12:51:14 +0100:
> > Given that this information is not discoverable, it needs to be encoded
> > in the device tree, but where? I can see two approaches:
> >
> > 1. For each IOMMU node, list phandles to the devices connected to it
> > and have a corresponding list of StreamIDs.
> >
> > or
> >
> > 2. For each device wishing to use an IOMMU, have a phandle to the
> > IOMMU node and a separate StreamID property. The IOMMU would then
> > parse this information when the device is added to the bus.
> >
> > Although I prefer the second approach, it has the downside of affecting
> > all device bindings that wish to use an IOMMU, so I'm open to any other
> > ideas.
>
> Actually the above summarize tegra SMMU situation well too. For
> example, each IOMMU'able device has IOVA constraint that some of the
> address area isn't available because of its MMIO. This info needs to
> be described in DT. If <IOMMU phandle> + some parametes are embedded
> in a device node, that info could be dealt at a bus notifier(*1).
>
> *1: http://lists.linuxfoundation.org/pipermail/iommu/2012-November/004934.html
I've been thinking about this a bit more and, unfortunately, my conclusion
is that method (2) above is problematic, so we do need something similar to
(1).
The reason for this comes about when dealing with chained IOMMUs. In this
case, each IOMMU in the chain needs to know about all of the masters hanging
beneath it (potentially behind other IOMMUs) but may also need to supplement
each device with additional data relevant to that point in the IOMMU chain.
In the case of the ARM System MMU, this could be StreamID information (as
the StreamID for a device can change as the transaction stream passes
through an SMMU) and for your case it could be that the DMA window is
widened along the chain.
So, extending the mmu-master property described in this thread to be
"mmu-masters : a list of phandles to device nodes representing bus masters
for which the IOMMU can provide a translation" is probably a good start.
Will
^ permalink raw reply
* [PATCH v6 13/15] KVM: ARM: Handle I/O aborts
From: Marc Zyngier @ 2013-01-17 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116175911.29147.40578.stgit@ubuntu>
On 16/01/13 17:59, 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. We don't support decoding these (patches
> are available elsewhere), so we report an error to user space in this case.
>
> 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.
>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
[...]
> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
> index 04a9705..702743e 100644
> --- a/arch/arm/kvm/interrupts.S
> +++ b/arch/arm/kvm/interrupts.S
> @@ -192,6 +192,44 @@ after_vfp_restore:
> mov r0, r1 @ Return the return code
> bx lr @ return to IOCTL
>
> +
> +/********************************************************************
> + * Translate VA to PA
> + *
> + * u64 __kvm_va_to_pa(struct kvm_vcpu *vcpu, u32 va, bool priv)
> + *
> + * Arguments:
> + * r0: pointer to vcpu struct
> + * r1: virtual address to map (rounded to page)
> + * r2: 1 = P1 (read) mapping, 0 = P0 (read) mapping.
> + * Returns 64 bit PAR value.
> + */
> +ENTRY(__kvm_va_to_pa)
> + push {r4-r12}
> +
> + @ Fold flag into r1, easier than using stack.
> + cmp r2, #0
> + movne r2, #1
> + orr r1, r1, r2
> +
> + @ This swaps too many registers, but we're in the slow path anyway.
> + read_cp15_state store_to_vcpu = 0
> + write_cp15_state read_from_vcpu = 1
> +
> + ands r2, r1, #1
> + bic r1, r1, r2
> + mcrne p15, 0, r1, c7, c8, 0 @ VA to PA, ATS1CPR
> + mcreq p15, 0, r1, c7, c8, 2 @ VA to PA, ATS1CUR
> + isb
> +
> + @ Restore host state.
> + read_cp15_state store_to_vcpu = 1
> + write_cp15_state read_from_vcpu = 0
> +
> + mrrc p15, 0, r0, r1, c7 @ PAR
> + pop {r4-r12}
> + bx lr
> +
Do we still need this function? Now that the MMIO emulation is gone,
there should be no need to perform a manual translation.
I can't even find a caller for it either.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 2/9] clk: tegra: Add tegra specific clocks
From: Stephen Warren @ 2013-01-17 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117.070327.1625310713330263780.hdoyu@nvidia.com>
On 01/16/2013 10:03 PM, Hiroshi Doyu wrote:
> Stephen Warren <swarren@wwwdotorg.org> wrote @ Wed, 16 Jan 2013 21:11:24 +0100:
>
>>>> +static int clk_frac_div_set_rate(struct clk_hw *hw, unsigned long rate,
>>>> + unsigned long parent_rate)
>>>> +{
>>>> + struct tegra_clk_frac_div *divider = to_clk_frac_div(hw);
>>>> + int div;
>>>> + unsigned long flags = 0;
>>>
>>> nit, is "flags" not needed to initialize here?
>>
>> It avoids a compiler warning; the compiler doesn't that the if condition
>> that guards the path that uses flags is the same condition as the path
>> that initializes it. Or, it may be related to the fact that
>> spin_lock_irqsave() writes to the value through a pointer parameter, and
>> the compiler doesn't know it's an out-only parameter.
>
> It might be better to append the special comment /* GCC */[1] on that line.
>
> [1] https://lwn.net/Articles/529954/
I note that patch hasn't actually been merged though, so I think I'll
avoid doing that for now.
^ permalink raw reply
* [PATCH v2] drivers/pinctrl: grab default handles from device core
From: Stephen Warren @ 2013-01-17 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117060214.GC1197@verge.net.au>
On 01/16/2013 11:02 PM, Simon Horman wrote:
> On Wed, Jan 16, 2013 at 10:49:05AM -0700, Stephen Warren wrote:
>> On 01/11/2013 01:45 PM, Linus Walleij wrote:
>>> On Fri, Jan 11, 2013 at 9:36 PM, Laurent Pinchart
>>> <laurent.pinchart@ideasonboard.com> wrote:
>>>
>>>> I've sent several patch series for the SH PFC (Pin Function Controller) to the
>>>> linux-sh mailing list. One of the series included pinctrl core patches for
>>>> easier testing, but I made it clear that they should *not* be pushed to
>>>> mainline through the SH tree.
>>>
>>> No big deal, what fun is linux-next if we don't break it ;-)
>>
>> Hmm. It's causing a lot of engineers here a lot of trouble, since they
>> all see linux-next won't boot, and haven't been paying enough attention
>> to know which commit to revert:-(. Lots of lost productivity:-(
>>
>> Simon, the offending commit:
>>
>> 6d3ef6b drivers/pinctrl: grab default handles from device core
>>
>> is still in next-20130116. Can you please remove it?
>
> I removed the commit yesterday.
> Please let me know if it seems to be lingering.
Thanks. I believe it's gone from next-20130117, judging by a quick
search through "git log" at least.
^ permalink raw reply
* [PATCH v2] drivers/pinctrl: grab default handles from device core
From: Stephen Warren @ 2013-01-17 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbnyzppd-iom4PL3N3-YkuK+BRNzR577qVc6cPoTKxhTw@mail.gmail.com>
On 01/16/2013 05:59 PM, Linus Walleij wrote:
> On Wed, Jan 16, 2013 at 6:49 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
>> Hmm. It's causing a lot of engineers here a lot of trouble, since they
>> all see linux-next won't boot, and haven't been paying enough attention
>> to know which commit to revert:-(. Lots of lost productivity:-(
>>
>> Simon, the offending commit:
>>
>> 6d3ef6b drivers/pinctrl: grab default handles from device core
>>
>> is still in next-20130116. Can you please remove it?
>
> Not that this should be in the SH tree, but I have merged your fix
> to the pinctrl tree and it should be in -next, does it fix the problem?
There were two problems; one was the issues handling hogs during DT->map
conversion, for which you applied a patch. The other was the crashes due
to incorrect devm_* usage and interactions with -EPROBE_DEFER in the
patch which Simon applied, which requires that patch to be revised.
> Mainly asking because once Greg ACKs that patch I want to
> put it into the pinctrl tree...
^ permalink raw reply
* [PATCH 1/2] ARM: tegra: config: enable SERIAL_TEGRA
From: Stephen Warren @ 2013-01-17 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F78030.6080305@nvidia.com>
On 01/16/2013 09:38 PM, Laxman Dewangan wrote:
> On Wednesday 16 January 2013 11:27 PM, Stephen Warren wrote:
>> On 01/16/2013 06:06 AM, Laxman Dewangan wrote:
>>> Enable high speed serial driver for tegra platform.
>> Thanks, I've applied patch 1 to Tegra's for-3.9/defconfig branch and
>> patch 2 to Tegra's for-3.9/dt branch.
>>
>> Just as an FYI, the dt branch is merged into my for-next branch, and
>> sent upstream, before the defconfig branch, so your patch order was
>> reversed relative to that, but it's not an issue here.
>
> Thanks for applying it. There is no issue on the reversing the sequence.
>
>
>> Question: How do I test this; do I just fire up bluez(?) and point it at
>> the UARTC serial port, or is there more to it?
>
> I tested this in may pieces, not with the bluez.
> I tested this in downstream with linux-next dma, this new serial driver,
> some hacks in the board files with bluetooth.
>
> Then I tested this again on linux-next with some hacks in board-dt filew
> with invoking the driver from cardhu dts file. In this I tested driver
> registration, basic write is wokring or not with some register
> dump/interrupt, Not checked data integrity as not connected the serial
> sniffer. The idea is that nothing should be crash in linux-next. The
> basic driver code is already tested with bluetooth.
Well, my question was more about what user-space tools/configuration/...
do I need to bring up Bluetooth to test this? I assume that now both the
driver and DT patches are in linux-next, I shouldn't have to touch the
kernel at all to make this work?
^ permalink raw reply
* [PATCH v6 15/15] KVM: ARM: Add maintainer entry for KVM/ARM
From: Will Deacon @ 2013-01-17 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116175925.29147.40357.stgit@ubuntu>
On Wed, Jan 16, 2013 at 05:59:25PM +0000, Christoffer Dall wrote:
> Add an entry in the MAINTAINERS file for KVM/ARM.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 915564e..70e5a10 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4474,6 +4474,14 @@ F: arch/s390/include/asm/kvm*
> F: arch/s390/kvm/
> F: drivers/s390/kvm/
>
> +KERNEL VIRTUAL MACHINE (KVM) FOR ARM
> +M: Christoffer Dall <christofferdall@gmail.com>
> +L: kvmarm at lists.cs.columbia.edu
> +W: http://http://systems.cs.columbia.edu/projects/kvm-arm
Oops, I missed that this URL has two http:// prefixes.
> +S: Supported
This means that you're paid to look after KVM. If so, using a gmail address
seems a little odd...
> +F: arch/arm/include/asm/kvm*
uapi?
> +F: arch/arm/kvm/
Will
^ permalink raw reply
* [PATCH 2/2] ARM: use DEBUG_LL infrastructural for multiplatform uncompress debug
From: Arnd Bergmann @ 2013-01-17 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358436119-30808-3-git-send-email-shawn.guo@linaro.org>
On Thursday 17 January 2013, Shawn Guo wrote:
> However, there is a problem with above approach. DEBUG_LL routines
> will check MMU enable bit to decide whether physical or virtual address
> should be used to access debug port. In case virtual address needs
> to be used, the address returned by addruart will not work for
> decompressor who uses a different mapping from what kernel uses.
> Fortunately, decompressor uses a flat mapping (same physical and virtual
> addresses). So we can easily work it around by asking platform addruart
> return physical address as virtual address when it runs in decompressor.
> The macro UNCOMPRESS_DEBUG is defined for this use.
Can't you just create a new copy of kernel/debug.S in boot/compressed/
that provides only a putc() function and uses the physical address
unconditionally?
For all I can tell, that should be little more than just
#include CONFIG_DEBUG_LL_INCLUDE
ENTRY(putc)
addruart r1, r2, r3
waituart r3, r1
senduart r0, r1
busyuart r3, r1
mov pc,lr
ENDPROC(putc)
(I'm not sure about the actual semantics of the above, take that
as an approximation)
Arnd
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Andrew Murray @ 2013-01-17 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117160501.GC2186@avionic-0098.adnet.avionic-design.de>
On Thu, Jan 17, 2013 at 04:05:02PM +0000, Thierry Reding wrote:
> On Thu, Jan 17, 2013 at 03:42:36PM +0000, Andrew Murray wrote:
> > On Wed, Jan 16, 2013 at 06:31:01PM +0000, Thierry Reding wrote:
> > > Alright, putting the functions into pci_ops doesn't sound like a very
> > > good idea then. Or perhaps it would make sense for hardware where the
> > > root complex and the MSI controller are handled by the same driver.
> > > Basically it could be done as a shortcut and if those are not filled
> > > in, the drivers could still opt to look up an MSI controller from a
> > > phandle specified in DT.
> > >
> > > Even another alternative would be to keep the functions within the
> > > struct pci_ops and use generic ones if an external MSI controller is
> > > used. Just tossing around ideas.
> >
> > I think an ideal solution would be for additional logic in drivers/msi.c
> > (e.g. in functions like msi_capability_init) to determine (based on the
> > passed in pci_dev) which MSI controller ops to use. I'm not sure the best
> > way to implement an association between an MSI controller and PCI busses
> > (I believe arch/sparc does something like this - perhaps there will be
> > inspiration there).
> >
> > As you've pointed out, most RCs will have their own MSI controllers - so
> > it should be easy to register and associate both together.
> >
> > I've submitted my previous work on MSI controller registration, but it
> > doesn't quite solve this problem - perhaps it can be a starting point?
>
> We basically have two cases:
>
> - The PCI host bridge contains registers for MSI support. In that case
> it makes little sense to uncouple the MSI implementation from the
> host bridge driver.
>
> - An MSI controller exists outside of the PCI host bridge. The PCI
> host bridge would in that case have to lookup an MSI controller (via
> DT phandle or some other method).
>
> In either of those cases, does it make sense to use the MSI support
> outside the scope of the PCI infrastructure? That is, would devices
> other than PCI devices be able to generate an MSI?
I've come around to your way of thinking. Your approach sounds good for
registration of MSI ops - let the RC host driver do it (it probably has its
own), or use a helper for following a phandle to get ops that are not part
of the driver. MSIs won't be used outside of PCI devices.
Though existing drivers will use MSI framework functions to request MSIs, that
will result in callbacks to the arch_setup_msi_irqs type functions. These
functions would need to be updated to find these new ops if they exist, i.e. by
traversing the pci_dev structure up to the RC and finding a suitable structure.
Perhaps the msi ops could live alongside pci_ops in the pci_bus structure. This
way when traversing up the buses from the provided pci_dev - the first bus with
msi ops populated would be used?
If no ops are found, the standard arch callbacks can be called - thus preserving
exiting functionality.
Andrew Murray
^ permalink raw reply
* [PATCH] [RFC] ARM: compile fix for DEBUG_LL=y && MMU=n
From: Uwe Kleine-König @ 2013-01-17 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116223144.GA9071@quad.lixom.net>
On Wed, Jan 16, 2013 at 02:31:44PM -0800, Olof Johansson wrote:
> On Wed, Jan 16, 2013 at 03:32:06PM +0100, Uwe Kleine-K?nig wrote:
> > debug_ll_addr is only used on machines with an MMU so it can be #ifdef'ed
> > out safely. This fixes:
> >
> > arch/arm/kernel/debug.S: Assembler messages:
> > arch/arm/kernel/debug.S:104: Error: too many positional arguments
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: Stephen Warren <swarren@nvidia.com>
> > Cc: Olof Johansson <olof@lixom.net>
> > ---
> > The obvious alternative fix is to make addruart on !MMU take 3
> > arguments, too.
> >
> > The problem was introduced in
> >
> > e5c5f2a (ARM: implement debug_ll_io_init())
> >
> > which appeared in v3.8-rc1.
>
> Since we introduced the breakage in arm-soc, I've picked up the fix (I guess
> it could have gone through Russell's tree as well though).
>
> I've added the reference to the introducing commit, and the acks/review tags.
>
> Adding a defconfig for a !MMU platform seems like a good idea, since there's
> several of us who make sure that there is build coverage of the defconfigs and
> follow up on most of the breakage. Feel free to send one in for 3.9.
Jonny just pointed out in irc that there is at91x40_defconfig.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type
From: Roger Quadros @ 2013-01-17 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358348462-27693-4-git-send-email-kishon@ti.com>
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, the API's
> for adding PHY and getting PHY has been changed. Now the binding
> information of the PHY and controller should be done in platform file
> using usb_bind_phy API. And for getting a PHY, the device pointer of the
> USB controller and an index should be passed. Based on the binding
> information that is added in the platform file, get_phy will return the
> approappropriate PHY.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> arch/arm/mach-shmobile/board-marzen.c | 2 +-
> drivers/power/ab8500_charger.c | 2 +-
> drivers/power/isp1704_charger.c | 2 +-
> drivers/power/pda_power.c | 2 +-
> drivers/power/twl4030_charger.c | 2 +-
> drivers/usb/chipidea/udc.c | 2 +-
> drivers/usb/dwc3/core.c | 4 +-
> drivers/usb/gadget/fsl_udc_core.c | 2 +-
> drivers/usb/gadget/mv_udc_core.c | 2 +-
> drivers/usb/gadget/omap_udc.c | 2 +-
> drivers/usb/gadget/pxa25x_udc.c | 2 +-
> drivers/usb/gadget/pxa27x_udc.c | 2 +-
> drivers/usb/gadget/s3c-hsudc.c | 2 +-
> drivers/usb/host/ehci-fsl.c | 2 +-
> drivers/usb/host/ehci-msm.c | 2 +-
> drivers/usb/host/ehci-mv.c | 2 +-
> drivers/usb/host/ehci-tegra.c | 2 +-
> drivers/usb/host/ohci-omap.c | 2 +-
> drivers/usb/musb/am35x.c | 2 +-
> drivers/usb/musb/blackfin.c | 2 +-
> drivers/usb/musb/da8xx.c | 2 +-
> drivers/usb/musb/davinci.c | 2 +-
> drivers/usb/musb/musb_dsps.c | 2 +-
> drivers/usb/musb/omap2430.c | 2 +-
> drivers/usb/musb/tusb6010.c | 2 +-
> drivers/usb/musb/ux500.c | 2 +-
> drivers/usb/otg/ab8500-usb.c | 3 +-
> drivers/usb/otg/fsl_otg.c | 5 ++-
> drivers/usb/otg/gpio_vbus.c | 3 +-
> drivers/usb/otg/isp1301_omap.c | 3 +-
> drivers/usb/otg/msm_otg.c | 3 +-
> drivers/usb/otg/mv_otg.c | 3 +-
> drivers/usb/otg/nop-usb-xceiv.c | 3 +-
> drivers/usb/otg/otg.c | 67 +++++++++++++++------------------
> drivers/usb/otg/twl4030-usb.c | 3 +-
> drivers/usb/phy/mv_u3d_phy.c | 3 +-
> drivers/usb/phy/omap-usb2.c | 11 ++----
> drivers/usb/phy/rcar-phy.c | 3 +-
> include/linux/usb/phy.h | 12 +++---
> 39 files changed, 87 insertions(+), 89 deletions(-)
I think it better to leave the existing add/get APIs as they are add add
new APIs that support multiple PHYs. You could probably mark the old
ones as deprecated.
That way you don't need to wait till all users are converted and tested.
e.g. you could name the new APIs as
usb_add_phy_dev(struct usb_phy *phy);
usb_get_phy_dev(struct device *dev, int index);
--
cheers,
-roger
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Thierry Reding @ 2013-01-17 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117154236.GA25943@arm.com>
On Thu, Jan 17, 2013 at 03:42:36PM +0000, Andrew Murray wrote:
> On Wed, Jan 16, 2013 at 06:31:01PM +0000, Thierry Reding wrote:
> > Alright, putting the functions into pci_ops doesn't sound like a very
> > good idea then. Or perhaps it would make sense for hardware where the
> > root complex and the MSI controller are handled by the same driver.
> > Basically it could be done as a shortcut and if those are not filled
> > in, the drivers could still opt to look up an MSI controller from a
> > phandle specified in DT.
> >
> > Even another alternative would be to keep the functions within the
> > struct pci_ops and use generic ones if an external MSI controller is
> > used. Just tossing around ideas.
>
> I think an ideal solution would be for additional logic in drivers/msi.c
> (e.g. in functions like msi_capability_init) to determine (based on the
> passed in pci_dev) which MSI controller ops to use. I'm not sure the best
> way to implement an association between an MSI controller and PCI busses
> (I believe arch/sparc does something like this - perhaps there will be
> inspiration there).
>
> As you've pointed out, most RCs will have their own MSI controllers - so
> it should be easy to register and associate both together.
>
> I've submitted my previous work on MSI controller registration, but it
> doesn't quite solve this problem - perhaps it can be a starting point?
We basically have two cases:
- The PCI host bridge contains registers for MSI support. In that case
it makes little sense to uncouple the MSI implementation from the
host bridge driver.
- An MSI controller exists outside of the PCI host bridge. The PCI
host bridge would in that case have to lookup an MSI controller (via
DT phandle or some other method).
In either of those cases, does it make sense to use the MSI support
outside the scope of the PCI infrastructure? That is, would devices
other than PCI devices be able to generate an MSI?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/4b916113/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: use Kconfig to select uncompress.h
From: Arnd Bergmann @ 2013-01-17 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358436119-30808-2-git-send-email-shawn.guo@linaro.org>
On Thursday 17 January 2013, Shawn Guo wrote:
> Spam Status: Spamassassin 0% probability of being spam.
>
> Full report:
> No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1
> Following the approach handling DEBUG_LL inclusion, the patch creates
> a Kconfig symbol CONFIG_UNCOMPRESS_INCLUDE for choosing the correct
> uncompress header. For traditional build, mach/uncompress.h will be
> included in arch/arm/boot/compressed/misc.c. For multiplatform build,
> debug/uncompress.h which contains a suite of empty functions will be
> used. In this way, a platform with particular uncompress.h
> implementation could choose its own uncompress.h with this Kconfig
> option.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Nice trick!
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ 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