* [RFC PATCH 0/7] usb: musb: add driver for control module
From: Arnd Bergmann @ 2013-01-15 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358239378-10030-1-git-send-email-kishon@ti.com>
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.
Arnd
^ permalink raw reply
* [kvmarm] [PATCH v5 03/14] KVM: ARM: Initial skeleton to compile KVM support
From: Alexander Graf @ 2013-01-15 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115133207.GM11529@redhat.com>
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.
Alex
^ permalink raw reply
* [GIT PULL] imx fixes for 3.8, take 2
From: Shawn Guo @ 2013-01-15 13:43 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit e37f0d5b32c2a66677d0f2a21431a87e7e9ce22d:
ARM: mx5: Fix MX53 flexcan2 clock (2013-01-08 08:53:07 +0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.8-2
for you to fetch changes up to 83ae20981ae924c37d02a42c829155fc3851260c:
ARM: imx: correct low-power mode setting (2013-01-14 22:19:48 +0800)
----------------------------------------------------------------
It's the second batch of fixes for 3.8, which includes one fixing for
!CONFIG_SMP build, two patches fixing broken imxfb driver caused by
multiplatform conversion, and a couple of pm/hotplug fixes.
----------------------------------------------------------------
Gwenhael Goavec-Merou (2):
ARM: imx: platform-imx-fb: modifies platform device name
video: imxfb: fix imxfb_info configuration order
Shawn Guo (3):
ARM: imx: fix build error with !CONFIG_SMP
ARM: imx: disable cpu in .cpu_kill hook
ARM: imx: correct low-power mode setting
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/clk-imx6q.c | 3 +++
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/devices/platform-imx-fb.c | 2 +-
arch/arm/mach-imx/hotplug.c | 10 ++++++----
arch/arm/mach-imx/platsmp.c | 1 +
arch/arm/mach-imx/pm-imx6q.c | 1 +
drivers/video/imxfb.c | 3 ++-
8 files changed, 16 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Marc Zyngier @ 2013-01-15 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115133455.GN11529@redhat.com>
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.
>> 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.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 12/26] mfd: ab8500-debugfs: Use NULL to initialise remaining NULL pointer
From: Lee Jones @ 2013-01-15 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115130635.GH5701@opensource.wolfsonmicro.com>
On Tue, 15 Jan 2013, Mark Brown wrote:
> On Tue, Jan 15, 2013 at 12:55:52PM +0000, Lee Jones wrote:
> > Partly for coding style reasons, but mostly because sparse warns on it.
> >
> > This patch is a completion of a previous patch my Mark Brown.
>
> Typo there :)
Yes, it should say "patch by my Mark Brown". ;)
> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks. I'll fixup with the typo.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 0/5] ARM: dts: AM33XX: lcdc support
From: Afzal Mohammed @ 2013-01-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series add DT sources for AM335x SoC as well as AM335x based
boards.
As compared to previous version, in this version, comment has been
added in dt source file about pinmux details so that user can easily
correlate to that mentioned in TRM. Also author of one of the patch
was actually "Manjunathappa, Prakash", here in this series, authorship
has been made proper.
As pinmux is an SoC specific detail rather than IP specific one,
addition of pin control has been done in a separate patch from
the one in which display timings are added. Also it may aid in
debugging in case of any issues.
This has been tested on AM335x based boards like AM335x EVM and
AM335x EVM-SK.
This series is based on v3.8-rc3.
This series has a dependency on,
1. Series v16 "of: add display helper" by,
Steffen Trumtrar <s.trumtrar@pengutronix.de>
2. Series v3 "video: da8xx-fb: runtime timing configuration" by,
me (Afzal Mohammed <afzal@ti.com>)
3. Series v2 "video: da8xx-fb: DT support" by,
me (Afzal Mohammed <afzal@ti.com>)
To test on AM335x, in addition to the above, following changes,
1. Patch "ARM: AM33XX: clock: SET_RATE_PARENT in lcd path" by,
me (Afzal Mohammed <afzal@ti.com>)
2. Patch "da8xx: Allow use by am33xx based devices" by,
Pantelis Antoniou <panto@antoniou-consulting.com>
3. Series "HWMOD fixes for AM33xx PWM submodules and device tree nodes" by,
Philip, Avinash <avinashphilip@ti.com>
would be required
All above dependencies along with those required for testing is available
@git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3.8-rc3
Regards
Afzal
v2: add pinmux comment in dtsi files, correct authorship of one of the
patch.
Afzal Mohammed (4):
ARM: dts: AM33XX: Add lcdc node
ARM: dts: AM33XX: Add am335x-evm lcdc panel timings
ARM: dts: AM33XX: Add am335x-evmsk lcdc panel timings
ARM: dts: AM33XX: Add am335x-evmsk lcdc pincontrol info
Manjunathappa, Prakash (1):
ARM: dts: AM33XX: Add am335x-evm lcdc pincontrol info
arch/arm/boot/dts/am335x-evm.dts | 55 +++++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/am335x-evmsk.dts | 55 +++++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/am33xx.dtsi | 8 ++++++
3 files changed, 116 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/5] ARM: dts: AM33XX: Add lcdc node
From: Afzal Mohammed @ 2013-01-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358252955.git.afzal@ti.com>
Add lcdc node.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..432d4bb8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,13 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ lcdc: lcdc at 4830e000 {
+ compatible = "ti,am3352-lcdc", "ti,da830-lcdc";
+ reg = <0x4830e000 0x1000>;
+ interrupts = <36>;
+ status = "disabled";
+ ti,hwmods = "lcdc";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/5] ARM: dts: AM33XX: Add am335x-evm lcdc panel timings
From: Afzal Mohammed @ 2013-01-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358252955.git.afzal@ti.com>
Update lcdc node with panel timings (typical) for AM335X-EVM.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..a4229aa 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -244,3 +244,23 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&lcdc {
+ status = "okay";
+
+ display-timings {
+ 800x480p62 {
+ clock-frequency = <30000000>;
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <39>;
+ hback-porch = <39>;
+ hsync-len = <47>;
+ vback-porch = <29>;
+ vfront-porch = <13>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: AM33XX: Add am335x-evm lcdc pincontrol info
From: Afzal Mohammed @ 2013-01-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358252955.git.afzal@ti.com>
From: "Manjunathappa, Prakash" <prakash.pm@ti.com>
Update pin mux information for lcd panel on AM335X-EVM
[afzal at ti.com: comment specifying user understandable pinmux details]
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
v2: correct authorship, add comment on pinmux
arch/arm/boot/dts/am335x-evm.dts | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index a4229aa..0527885 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux at 44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
+ pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0 &lcd_pins_s0>;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins = <
@@ -44,6 +44,39 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT | MODE7 */
>;
};
+
+ lcd_pins_s0: lcd_pins_s0 {
+ pinctrl-single,pins = <
+ 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT | MODE1 */
+ 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT | MODE1 */
+ 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT | MODE1 */
+ 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT | MODE1 */
+ 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT | MODE1 */
+ 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT | MODE1 */
+ 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT | MODE1 */
+ 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT | MODE1 */
+ 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT | MODE0 */
+ 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT | MODE0 */
+ 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT | MODE0 */
+ 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT | MODE0 */
+ 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT | MODE0 */
+ 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT | MODE0 */
+ 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT | MODE0 */
+ 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT | MODE0 */
+ 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT | MODE0 */
+ 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT | MODE0 */
+ 0xc8 0x00 /* lcd_data10.lcd_data10, OUTPUT | MODE0 */
+ 0xcc 0x00 /* lcd_data11.lcd_data11, OUTPUT | MODE0 */
+ 0xd0 0x00 /* lcd_data12.lcd_data12, OUTPUT | MODE0 */
+ 0xd4 0x00 /* lcd_data13.lcd_data13, OUTPUT | MODE0 */
+ 0xd8 0x00 /* lcd_data14.lcd_data14, OUTPUT | MODE0 */
+ 0xdc 0x00 /* lcd_data15.lcd_data15, OUTPUT | MODE0 */
+ 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT | MODE0 */
+ 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT | MODE0 */
+ 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT | MODE0 */
+ 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+ >;
+ };
};
ocp {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: AM33XX: Add am335x-evmsk lcdc panel timings
From: Afzal Mohammed @ 2013-01-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358252955.git.afzal@ti.com>
Update lcdc node with panel timings (typical) for AM335X-EVMSK.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
arch/arm/boot/dts/am335x-evmsk.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..a7e017b 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -248,3 +248,23 @@
};
};
};
+
+&lcdc {
+ status = "okay";
+
+ display-timings {
+ 480x272p57 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <8>;
+ hback-porch = <43>;
+ hsync-len = <4>;
+ vback-porch = <12>;
+ vfront-porch = <4>;
+ vsync-len = <10>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: AM33XX: Add am335x-evmsk lcdc pincontrol info
From: Afzal Mohammed @ 2013-01-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358252955.git.afzal@ti.com>
Update pin mux information for lcd panel on AM335X-EVMSK.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
v2: add comment on pinmux entries
arch/arm/boot/dts/am335x-evmsk.dts | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index a7e017b..24dde1d 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux at 44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0 &gpio_keys_s0>;
+ pinctrl-0 = <&user_leds_s0 &gpio_keys_s0 &lcd_pins_s0>;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
@@ -51,6 +51,39 @@
0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT | MODE7 */
>;
};
+
+ lcd_pins_s0: lcd_pins_s0 {
+ pinctrl-single,pins = <
+ 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT | MODE1 */
+ 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT | MODE1 */
+ 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT | MODE1 */
+ 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT | MODE1 */
+ 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT | MODE1 */
+ 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT | MODE1 */
+ 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT | MODE1 */
+ 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT | MODE1 */
+ 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT | MODE0 */
+ 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT | MODE0 */
+ 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT | MODE0 */
+ 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT | MODE0 */
+ 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT | MODE0 */
+ 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT | MODE0 */
+ 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT | MODE0 */
+ 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT | MODE0 */
+ 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT | MODE0 */
+ 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT | MODE0 */
+ 0xc8 0x00 /* lcd_data10.lcd_data10, OUTPUT | MODE0 */
+ 0xcc 0x00 /* lcd_data11.lcd_data11, OUTPUT | MODE0 */
+ 0xd0 0x00 /* lcd_data12.lcd_data12, OUTPUT | MODE0 */
+ 0xd4 0x00 /* lcd_data13.lcd_data13, OUTPUT | MODE0 */
+ 0xd8 0x00 /* lcd_data14.lcd_data14, OUTPUT | MODE0 */
+ 0xdc 0x00 /* lcd_data15.lcd_data15, OUTPUT | MODE0 */
+ 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT | MODE0 */
+ 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT | MODE0 */
+ 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT | MODE0 */
+ 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+ >;
+ };
};
ocp {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 04/18] power: ab8500_fg: Replace msleep() with usleep_range() for greater accuracy
From: Lee Jones @ 2013-01-15 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301151323.28879.arnd@arndb.de>
> > > > @@ -956,7 +956,7 @@ static int ab8500_fg_load_comp_volt_to_capacity(struct ab8500_fg *di)
> > > > do {
> > > > vbat += ab8500_fg_bat_voltage(di);
> > > > i++;
> > > > - msleep(5);
> > > > + usleep_range(5000, 5001);
> > >
> > > If you're going to give a range that small
> > > you might as well use usleep instead.
> > >
> > > Otherwise, add some tolerance to allow any
> > > other coalesced wakeup to occur.
> >
> > I can't increase the tolerance, as I don't know how that would
> > effect the running of the system, and the person who would know
> > is off on parental leave.
>
> The function only averages the voltage between a couple of readings.
> It won't change much if those register reads are slightly more
> uniformly timed. Note that the thread can still be preempted for
> a much longer time if anything else is running, and
Okay, I'll fixup to have a more sensible range.
> the entire
> interrupt handling in this driver looks so fragile that I would
> not rely on the interrupt actually happening at the right time
> anyway. I think it should first be debugged properly to remove
> the need for the enable_irq/disable_irq calls.
Yes, I remember discussing this with you before and I've since
placed it on my TODO list. However, I'm really shying away from
it for the moment, as this patch-set only applies <20 out of the
70+ outstanding patches left in the internal kernel's delta. To
avoid any unnecessary fixups, I'll apply those kinds of fixes at
the end of the set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/6] arm: mvebu: Enable USB controllers on Armada 370 evaluation board
From: Ezequiel Garcia @ 2013-01-15 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301151307.26665.arnd@arndb.de>
Hi Arnd,
On 01/15/2013 10:07 AM, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Ezequiel Garcia wrote:
>> Cc: Lior Amsalem <alior@marvell.com>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>
> The patches look good, but when you have four trivial patches
> doing the same thing in different files, and you decide that it's
> not worth writing a changelog for them, they should probably
> go into a single patch.
>
Mmm... maybe you're right and such splitting is excessive.
It seemed tidier this way, enabling each board on a different patch.
I can squash them on a v2, if you want me to.
Thanks for reviewing!
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Shawn Guo @ 2013-01-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358216975-1404-2-git-send-email-peter.chen@freescale.com>
On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> As mach/hardware.h is deleted, we need to use platform_device_id to
> differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> already used pdata to differentiate runtime
>
> Meanwhile we update the platform code accordingly.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> arch/arm/mach-imx/devices/devices-common.h | 1 +
> arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 ++++---
> drivers/usb/gadget/fsl_mxc_udc.c | 24 +++++-------
> drivers/usb/gadget/fsl_udc_core.c | 42 +++++++++++++--------
> 4 files changed, 45 insertions(+), 37 deletions(-)
Since we are splitting the original patch anyway, it's a bit strange
to me that you are mixing arch/arm/mach-imx and drivers/usb/gadget
in this patch. I'm fine with it, since I assume all the patches to
go via USB tree anyway.
>
> diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
> index 6277baf..9bd5777 100644
> --- a/arch/arm/mach-imx/devices/devices-common.h
> +++ b/arch/arm/mach-imx/devices/devices-common.h
> @@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
>
> #include <linux/fsl_devices.h>
> struct imx_fsl_usb2_udc_data {
> + const char *devid;
> resource_size_t iobase;
> resource_size_t irq;
> };
> diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> index 37e4439..fb527c7 100644
> --- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> +++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
> @@ -11,35 +11,36 @@
> #include "../hardware.h"
> #include "devices-common.h"
>
> -#define imx_fsl_usb2_udc_data_entry_single(soc) \
> +#define imx_fsl_usb2_udc_data_entry_single(soc, _devid) \
> { \
> + .devid = _devid, \
> .iobase = soc ## _USB_OTG_BASE_ADDR, \
> .irq = soc ## _INT_USB_OTG, \
> }
>
> #ifdef CONFIG_SOC_IMX25
> const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX25);
> + imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
> #endif /* ifdef CONFIG_SOC_IMX25 */
>
> #ifdef CONFIG_SOC_IMX27
> const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX27);
> + imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
> #endif /* ifdef CONFIG_SOC_IMX27 */
>
> #ifdef CONFIG_SOC_IMX31
> const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX31);
> + imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
> #endif /* ifdef CONFIG_SOC_IMX31 */
>
> #ifdef CONFIG_SOC_IMX35
> const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX35);
> + imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
> #endif /* ifdef CONFIG_SOC_IMX35 */
>
> #ifdef CONFIG_SOC_IMX51
> const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
> - imx_fsl_usb2_udc_data_entry_single(MX51);
> + imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
> #endif
>
> struct platform_device *__init imx_add_fsl_usb2_udc(
> @@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
> .flags = IORESOURCE_IRQ,
> },
> };
> - return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
> + return imx_add_platform_device_dmamask(data->devid, -1,
> res, ARRAY_SIZE(res),
> pdata, sizeof(*pdata), DMA_BIT_MASK(32));
> }
<snip>
> +static const struct platform_device_id fsl_udc_devtype[] = {
> + {
> + .name = "imx-udc-mx25",
> + }, {
> + .name = "imx-udc-mx27",
> + }, {
> + .name = "imx-udc-mx31",
> + }, {
> + .name = "imx-udc-mx35",
> + }, {
> + .name = "imx-udc-mx51",
> + }
> +};
>From what I understand balbi's comment, he dislikes this full list of
device id. Instead, he prefers to something like below.
static const struct platform_device_id fsl_udc_devtype[] = {
{
.name = "imx-udc-mx27",
}, {
.name = "imx-udc-mx51",
}
};
It basically tells that we are handling two type of devices here, one
is imx-udc-mx27 type and the other is imx-udc-mx51 type, with mx25/31/35
completely compatible with mx27 type. We choose mx27 instead of mx25
to define the type because mx27 Si came out earlier than mx25. That
said, we generally choose the earlies SoC name to define a particular
version of IP block, since hardware version is mostly unavailable or
unreliable.
But that also means in platform code which create the platform_device,
you will need to use name "imx-udc-mx27" for even mx25/31/35.
imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx27");
imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx27");
imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx27");
Considering this is a piece of code we will not use for any new
hardware, I'm fine with either way.
So, balbi, it's all your call to accept the series as it is or ask for
another iteration.
Shawn
^ permalink raw reply
* [kvmarm] [PATCH v5 06/14] KVM: ARM: Inject IRQs and FIQs from userspace
From: Peter Maydell @ 2013-01-15 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115125241.GK11529@redhat.com>
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.
-- PMM
^ permalink raw reply
* [PATCH 04/18] power: ab8500_fg: Replace msleep() with usleep_range() for greater accuracy
From: Lee Jones @ 2013-01-15 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357909986-9262-5-git-send-email-lee.jones@linaro.org>
From: Jonas Aaberg <jonas.aberg@stericsson.com>
Doing so provides a greater degree of accuracy when dealing with
time-frames between 1us and 20ms. msleep() is only accurate for
wake-ups greater than 20ms.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonas ABERG <jonas.aberg@stericsson.com>
Reviewed-by: Johan BJORNSTEDT <johan.bjornstedt@stericsson.com>
---
drivers/power/ab8500_fg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index 828529e..78124587 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -956,7 +956,7 @@ static int ab8500_fg_load_comp_volt_to_capacity(struct ab8500_fg *di)
do {
vbat += ab8500_fg_bat_voltage(di);
i++;
- msleep(5);
+ usleep_range(5000, 6000);
} while (!ab8500_fg_inst_curr_done(di));
ab8500_fg_inst_curr_finalize(di, &di->inst_curr);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] clk: mvebu/clk-cpu.c: fix memory leakage
From: Gregory CLEMENT @ 2013-01-15 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358183892-28928-1-git-send-email-dinggnu@gmail.com>
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
Thanks,
Gregory
^ permalink raw reply
* [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
From: kishon @ 2013-01-15 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301151336.47546.arnd@arndb.de>
Hi Arnd,
On Tuesday 15 January 2013 07:06 PM, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
>> +OMAP CONTROL USB
>> +
>> +Required properties:
>> + - compatible: Should be "ti,omap-control-usb"
>> + - reg : Address and length of the register set for the device. It contains
>> + the address of "control_dev_conf" and "otghs_control".
>> + - reg-names: The names of the register addresses corresponding to the registers
>> + filled in "reg".
>> + - ti,has_mailbox: This is used to specify if the platform uses mailbox in
>> + control module.
>
> I wonder whether we need to have a phandle here to connect the control device
> to the actual usb device. What happens if you have multiple instances of
> each?
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.
Thanks
Kishon
^ permalink raw reply
* [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module
From: kishon @ 2013-01-15 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F5514A.2040207@mvista.com>
On Tuesday 15 January 2013 06:23 PM, Sergei Shtylyov wrote:
> Hello.
>
> 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.
Thanks
Kishon
^ permalink raw reply
* [PATCH v5 13/14] KVM: ARM: Handle I/O aborts
From: Gleb Natapov @ 2013-01-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F55D9C.8070007@arm.com>
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?
--
Gleb.
^ permalink raw reply
* [PATCH v5 07/12] ARM: KVM: VGIC virtual CPU interface management
From: Christoffer Dall @ 2013-01-15 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F536DC.2060702@arm.com>
On Tue, Jan 15, 2013 at 6:00 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 14/01/13 22:02, Christoffer Dall wrote:
>> On Mon, Jan 14, 2013 at 10:42 AM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, Jan 08, 2013 at 06:42:11PM +0000, Christoffer Dall wrote:
>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> Add VGIC virtual CPU interface code, picking pending interrupts
>>>> from the distributor and stashing them in the VGIC control interface
>>>> list registers.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>>> ---
>>>> arch/arm/include/asm/kvm_vgic.h | 30 ++++
>>>> arch/arm/kvm/vgic.c | 327 +++++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 356 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/include/asm/kvm_vgic.h b/arch/arm/include/asm/kvm_vgic.h
>>>> index 9ff0d9c..b3133c4 100644
>>>> --- a/arch/arm/include/asm/kvm_vgic.h
>>>> +++ b/arch/arm/include/asm/kvm_vgic.h
>>>> @@ -110,8 +110,33 @@ struct vgic_dist {
>>>> };
>>>>
>>>> struct vgic_cpu {
>>>> +#ifdef CONFIG_KVM_ARM_VGIC
>>>> + /* per IRQ to LR mapping */
>>>> + u8 vgic_irq_lr_map[VGIC_NR_IRQS];
>>>> +
>>>> + /* Pending interrupts on this VCPU */
>>>> + DECLARE_BITMAP( pending_percpu, VGIC_NR_PRIVATE_IRQS);
>>>> + DECLARE_BITMAP( pending_shared, VGIC_NR_SHARED_IRQS);
>>>> +
>>>> + /* Bitmap of used/free list registers */
>>>> + DECLARE_BITMAP( lr_used, 64);
>>>> +
>>>> + /* Number of list registers on this CPU */
>>>> + int nr_lr;
>>>> +
>>>> + /* CPU vif control registers for world switch */
>>>> + u32 vgic_hcr;
>>>> + u32 vgic_vmcr;
>>>> + u32 vgic_misr; /* Saved only */
>>>> + u32 vgic_eisr[2]; /* Saved only */
>>>> + u32 vgic_elrsr[2]; /* Saved only */
>>>> + u32 vgic_apr;
>>>> + u32 vgic_lr[64]; /* A15 has only 4... */
>>>
>>> Have a #define for the maximum number of list registers.
>>>
>>>> +#endif
>>>> };
>>>>
>>>> +#define LR_EMPTY 0xff
>>>> +
>>>> struct kvm;
>>>> struct kvm_vcpu;
>>>> struct kvm_run;
>>>> @@ -119,9 +144,14 @@ struct kvm_exit_mmio;
>>>>
>>>> #ifdef CONFIG_KVM_ARM_VGIC
>>>> int kvm_vgic_set_addr(struct kvm *kvm, unsigned long type, u64 addr);
>>>> +void kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu);
>>>> +void kvm_vgic_sync_from_cpu(struct kvm_vcpu *vcpu);
>>>
>>> Same comment as for the arch timer (flush/sync).
>>>
>>>> +int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
>>>> bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
>>>> struct kvm_exit_mmio *mmio);
>>>>
>>>> +#define irqchip_in_kernel(k) (!!((k)->arch.vgic.vctrl_base))
>>>> +
>>>> #else
>>>> static inline int kvm_vgic_hyp_init(void)
>>>> {
>>>> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
>>>> index bd2bd7f..58237d5 100644
>>>> --- a/arch/arm/kvm/vgic.c
>>>> +++ b/arch/arm/kvm/vgic.c
>>>> @@ -152,6 +152,34 @@ static int vgic_irq_is_enabled(struct kvm_vcpu *vcpu, int irq)
>>>> return vgic_bitmap_get_irq_val(&dist->irq_enabled, vcpu->vcpu_id, irq);
>>>> }
>>>>
>>>> +static int vgic_irq_is_active(struct kvm_vcpu *vcpu, int irq)
>>>> +{
>>>> + struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
>>>> +
>>>> + return vgic_bitmap_get_irq_val(&dist->irq_active, vcpu->vcpu_id, irq);
>>>> +}
>>>> +
>>>> +static void vgic_irq_set_active(struct kvm_vcpu *vcpu, int irq)
>>>> +{
>>>> + struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
>>>> +
>>>> + vgic_bitmap_set_irq_val(&dist->irq_active, vcpu->vcpu_id, irq, 1);
>>>> +}
>>>> +
>>>> +static void vgic_irq_clear_active(struct kvm_vcpu *vcpu, int irq)
>>>> +{
>>>> + struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
>>>> +
>>>> + vgic_bitmap_set_irq_val(&dist->irq_active, vcpu->vcpu_id, irq, 0);
>>>> +}
>>>> +
>>>> +static int vgic_dist_irq_is_pending(struct kvm_vcpu *vcpu, int irq)
>>>> +{
>>>> + struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
>>>> +
>>>> + return vgic_bitmap_get_irq_val(&dist->irq_state, vcpu->vcpu_id, irq);
>>>> +}
>>>> +
>>>> static void vgic_dist_irq_set(struct kvm_vcpu *vcpu, int irq)
>>>> {
>>>> struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
>>>> @@ -711,7 +739,30 @@ static void vgic_dispatch_sgi(struct kvm_vcpu *vcpu, u32 reg)
>>>>
>>>> static int compute_pending_for_cpu(struct kvm_vcpu *vcpu)
>>>> {
>>>> - return 0;
>>>> + struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
>>>> + unsigned long *pending, *enabled, *pend_percpu, *pend_shared;
>>>> + unsigned long pending_private, pending_shared;
>>>> + int vcpu_id;
>>>> +
>>>> + vcpu_id = vcpu->vcpu_id;
>>>> + pend_percpu = vcpu->arch.vgic_cpu.pending_percpu;
>>>> + pend_shared = vcpu->arch.vgic_cpu.pending_shared;
>>>> +
>>>> + pending = vgic_bitmap_get_cpu_map(&dist->irq_state, vcpu_id);
>>>> + enabled = vgic_bitmap_get_cpu_map(&dist->irq_enabled, vcpu_id);
>>>> + bitmap_and(pend_percpu, pending, enabled, VGIC_NR_PRIVATE_IRQS);
>>>> +
>>>> + pending = vgic_bitmap_get_shared_map(&dist->irq_state);
>>>> + enabled = vgic_bitmap_get_shared_map(&dist->irq_enabled);
>>>> + bitmap_and(pend_shared, pending, enabled, VGIC_NR_SHARED_IRQS);
>>>> + bitmap_and(pend_shared, pend_shared,
>>>> + vgic_bitmap_get_shared_map(&dist->irq_spi_target[vcpu_id]),
>>>> + VGIC_NR_SHARED_IRQS);
>>>> +
>>>> + pending_private = find_first_bit(pend_percpu, VGIC_NR_PRIVATE_IRQS);
>>>> + pending_shared = find_first_bit(pend_shared, VGIC_NR_SHARED_IRQS);
>>>> + return (pending_private < VGIC_NR_PRIVATE_IRQS ||
>>>> + pending_shared < VGIC_NR_SHARED_IRQS);
>>>> }
>>>>
>>>> /*
>>>> @@ -737,6 +788,280 @@ static void vgic_update_state(struct kvm *kvm)
>>>> }
>>>> }
>>>>
>>>> +#define LR_CPUID(lr) \
>>>> + (((lr) & GICH_LR_PHYSID_CPUID) >> GICH_LR_PHYSID_CPUID_SHIFT)
>>>> +#define MK_LR_PEND(src, irq) \
>>>> + (GICH_LR_PENDING_BIT | ((src) << GICH_LR_PHYSID_CPUID_SHIFT) | (irq))
>>>> +/*
>>>> + * Queue an interrupt to a CPU virtual interface. Return true on success,
>>>> + * or false if it wasn't possible to queue it.
>>>> + */
>>>> +static bool vgic_queue_irq(struct kvm_vcpu *vcpu, u8 sgi_source_id, int irq)
>>>> +{
>>>> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
>>>> + int lr;
>>>> +
>>>> + /* Sanitize the input... */
>>>> + BUG_ON(sgi_source_id & ~7);
>>>> + BUG_ON(sgi_source_id && irq > 15);
>>>
>>> You can use your new NR_SGIS definition here.
>>>
>>
>> This should address the remaining comments:
>>
>> commit 43957095ec5476beb198f4c4630dfc3e2f3951db
>> Author: Christoffer Dall <c.dall@virtualopensystems.com>
>> Date: Mon Jan 14 16:59:38 2013 -0500
>>
>> KVM: ARM: vgic: Define VGIC_MAX_LRS
>>
>> Define maximum number of link registers we can handle instead of using
>> literals in the code. If an architecture reports more link registers
>> than we support, only use the number we can support.
>>
>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>
>> diff --git a/arch/arm/include/asm/kvm_vgic.h b/arch/arm/include/asm/kvm_vgic.h
>> index 1ace491..f9d1977 100644
>> --- a/arch/arm/include/asm/kvm_vgic.h
>> +++ b/arch/arm/include/asm/kvm_vgic.h
>> @@ -33,6 +33,7 @@
>> #define VGIC_NR_PRIVATE_IRQS (VGIC_NR_SGIS + VGIC_NR_PPIS)
>> #define VGIC_NR_SHARED_IRQS (VGIC_NR_IRQS - VGIC_NR_PRIVATE_IRQS)
>> #define VGIC_MAX_CPUS KVM_MAX_VCPUS
>> +#define VGIC_MAX_LRS 64
>
> Consider this instead (for the reason below)
> #define VGIC_MAX_LRS (1 << 7)
>
>> /* Sanity checks... */
>> #if (VGIC_MAX_CPUS > 8)
>> @@ -120,7 +121,7 @@ struct vgic_cpu {
>> DECLARE_BITMAP( pending_shared, VGIC_NR_SHARED_IRQS);
>>
>> /* Bitmap of used/free list registers */
>> - DECLARE_BITMAP( lr_used, 64);
>> + DECLARE_BITMAP( lr_used, VGIC_MAX_LRS);
>>
>> /* Number of list registers on this CPU */
>> int nr_lr;
>> @@ -132,7 +133,7 @@ struct vgic_cpu {
>> u32 vgic_eisr[2]; /* Saved only */
>> u32 vgic_elrsr[2]; /* Saved only */
>> u32 vgic_apr;
>> - u32 vgic_lr[64]; /* A15 has only 4... */
>> + u32 vgic_lr[VGIC_MAX_LRS];
>> #endif
>> };
>>
>> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
>> index a0d283c..90a99fd 100644
>> --- a/arch/arm/kvm/vgic.c
>> +++ b/arch/arm/kvm/vgic.c
>> @@ -1345,6 +1345,8 @@ int kvm_vgic_hyp_init(void)
>>
>> vgic_nr_lr = readl_relaxed(vgic_vctrl_base + GICH_VTR);
>> vgic_nr_lr = (vgic_nr_lr & 0x1f) + 1;
>
> There is a bug here. It should be:
> vgic_nr_lr = (vgic_nr_lr & 0x2f) + 1;
>
>> + if (vgic_nr_lr > VGIC_MAX_LRS)
>> + vgic_nr_lr = VGIC_MAX_LRS; /* TODO: Clear remaining LRs */
>
> Why? VGIC_MAX_LRS isn't a configurable value, but a maximum value
> defined by the specification. This is the maximum you can fit in a 6 bit
> field, plus one (1 << 7, exactly).
>
I figures this was something that could potentially change with a
newer gic architecture etc., and then it was good to have the check,
but you're right, then everything would break.
-Christoffer
^ permalink raw reply
* [GIT PULL] arch_decomp_wdog() cleanup for 3.9
From: Shawn Guo @ 2013-01-15 14:32 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/cleanup-decompwdog-3.9
for you to fetch changes up to 1ff5f55a8c7b011f818434923a93afc48de0b2ee:
ARM: samsung: remove unused arch_decomp_wdog() code (2013-01-11 13:55:35 +0800)
----------------------------------------------------------------
The series cleans up ARCH_HAS_DECOMP_WDOG and arch_decomp_wdog which
are unused on ARM architecure. Samsung has some code setting up wdog
in arch_decomp_wdog(). But since CONFIG_S3C_BOOT_WATCHDOG is defined
nowhere, it will not run. Otherwise, system can not boot at all when
wdog is set up but no one pats it.
----------------------------------------------------------------
Shawn Guo (3):
ARM: decompress: remove unused ARCH_HAS_DECOMP_WDOG
ARM: remove unused arch_decomp_wdog()
ARM: samsung: remove unused arch_decomp_wdog() code
arch/arm/boot/compressed/decompress.c | 2 --
arch/arm/mach-at91/include/mach/uncompress.h | 2 --
arch/arm/mach-bcm2835/include/mach/uncompress.h | 1 -
arch/arm/mach-clps711x/include/mach/uncompress.h | 2 --
arch/arm/mach-cns3xxx/include/mach/uncompress.h | 1 -
arch/arm/mach-davinci/include/mach/uncompress.h | 1 -
arch/arm/mach-dove/include/mach/uncompress.h | 1 -
arch/arm/mach-ebsa110/include/mach/uncompress.h | 1 -
arch/arm/mach-ep93xx/include/mach/uncompress.h | 2 --
arch/arm/mach-footbridge/include/mach/uncompress.h | 1 -
arch/arm/mach-gemini/include/mach/uncompress.h | 2 --
arch/arm/mach-h720x/include/mach/uncompress.h | 1 -
arch/arm/mach-integrator/include/mach/uncompress.h | 2 --
arch/arm/mach-iop13xx/include/mach/uncompress.h | 1 -
arch/arm/mach-iop32x/include/mach/uncompress.h | 1 -
arch/arm/mach-iop33x/include/mach/uncompress.h | 1 -
arch/arm/mach-ixp4xx/include/mach/uncompress.h | 2 --
arch/arm/mach-kirkwood/include/mach/uncompress.h | 1 -
arch/arm/mach-ks8695/include/mach/uncompress.h | 1 -
arch/arm/mach-lpc32xx/include/mach/uncompress.h | 1 -
arch/arm/mach-mmp/include/mach/uncompress.h | 6 -----
arch/arm/mach-msm/include/mach/uncompress.h | 4 ---
arch/arm/mach-mv78xx0/include/mach/uncompress.h | 1 -
arch/arm/mach-mxs/include/mach/uncompress.h | 1 -
arch/arm/mach-netx/include/mach/uncompress.h | 1 -
arch/arm/mach-nomadik/include/mach/uncompress.h | 2 --
arch/arm/mach-omap1/include/mach/uncompress.h | 5 ----
arch/arm/mach-omap2/include/mach/uncompress.h | 5 ----
arch/arm/mach-orion5x/include/mach/uncompress.h | 1 -
arch/arm/mach-prima2/include/mach/uncompress.h | 2 --
arch/arm/mach-pxa/include/mach/uncompress.h | 5 ----
arch/arm/mach-realview/include/mach/uncompress.h | 1 -
arch/arm/mach-rpc/include/mach/uncompress.h | 5 ----
arch/arm/mach-s5p64x0/include/mach/uncompress.h | 28 --------------------
arch/arm/mach-sa1100/include/mach/uncompress.h | 1 -
arch/arm/mach-shark/include/mach/uncompress.h | 1 -
arch/arm/mach-shmobile/include/mach/uncompress.h | 2 --
arch/arm/mach-tegra/include/mach/uncompress.h | 4 ---
arch/arm/mach-u300/include/mach/uncompress.h | 1 -
arch/arm/mach-ux500/include/mach/uncompress.h | 2 --
arch/arm/mach-versatile/include/mach/uncompress.h | 1 -
arch/arm/mach-vt8500/include/mach/uncompress.h | 1 -
arch/arm/mach-w90x900/include/mach/uncompress.h | 2 --
arch/arm/plat-samsung/include/plat/uncompress.h | 28 --------------------
arch/arm/plat-spear/include/plat/uncompress.h | 1 -
45 files changed, 138 deletions(-)
^ permalink raw reply
* [PATCH v5 2/4] ARM: KVM: arch_timers: Add guest timer core support
From: Christoffer Dall @ 2013-01-15 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F53868.4060208@arm.com>
On Tue, Jan 15, 2013 at 6:07 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 14/01/13 19:19, Christoffer Dall wrote:
>> On Mon, Jan 14, 2013 at 10:18 AM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, Jan 08, 2013 at 06:43:20PM +0000, Christoffer Dall wrote:
>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> Add some the architected timer related infrastructure, and support timer
>>>> interrupt injection, which can happen as a resultof three possible
>>>> events:
>>>>
>>>> - The virtual timer interrupt has fired while we were still
>>>> executing the guest
>>>> - The timer interrupt hasn't fired, but it expired while we
>>>> were doing the world switch
>>>> - A hrtimer we programmed earlier has fired
>>>
>>> [...]
>>>
>>>> +void kvm_timer_sync_to_cpu(struct kvm_vcpu *vcpu)
>>>> +{
>>>> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>>> +
>>>> + /*
>>>> + * We're about to run this vcpu again, so there is no need to
>>>> + * keep the background timer running, as we're about to
>>>> + * populate the CPU timer again.
>>>> + */
>>>> + timer_disarm(timer);
>>>> +}
>>>> +
>>>> +void kvm_timer_sync_from_cpu(struct kvm_vcpu *vcpu)
>>>> +{
>>>> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>>> + cycle_t cval, now;
>>>> + u64 ns;
>>>> +
>>>> + /* Check if the timer is enabled and unmasked first */
>>>> + if ((timer->cntv_ctl & 3) != 1)
>>>> + return;
>>>> +
>>>> + cval = timer->cntv_cval;
>>>> + now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>>>> +
>>>> + BUG_ON(timer_is_armed(timer));
>>>> +
>>>> + if (cval <= now) {
>>>> + /*
>>>> + * Timer has already expired while we were not
>>>> + * looking. Inject the interrupt and carry on.
>>>> + */
>>>> + kvm_timer_inject_irq(vcpu);
>>>> + return;
>>>> + }
>>>> +
>>>> + ns = cyclecounter_cyc2ns(timecounter->cc, cval - now);
>>>> + timer_arm(timer, ns);
>>>> +}
>>>
>>> Please use flush/sync terminology to match the rest of arch/arm/.
>>>
>> ok, the following fixes this for both timers and the vgic:
>>
>> commit 1b68f39459dbc797f6766c103edf2c1053984161
>> Author: Christoffer Dall <c.dall@virtualopensystems.com>
>> Date: Mon Jan 14 14:16:31 2013 -0500
>>
>> KVM: ARM: vgic: use sync/flush terminology
>>
>> Use sync/flush for saving state to/from CPUs to be consistent with
>> other uses in arch/arm.
>
> Sync and flush on their own are pretty inexpressive. Consider changing
> it to {flush,sync}_hwstate, so we're consistent with what VFP does.
>
sure
^ permalink raw reply
* [PATCH] ARM: KVM: avoid add/sub on vcpu pointer
From: Christoffer Dall @ 2013-01-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358248829-13764-1-git-send-email-marc.zyngier@arm.com>
On Tue, Jan 15, 2013 at 6:20 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Doing arithmetic on the vcpu pointer can be avoided by using
> another register as a base. Saves a few instructions on the
> switch path.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/kvm/interrupts_head.S | 32 ++++++++++++++------------------
> 1 file changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
> index 0e423be..d2442f9 100644
> --- a/arch/arm/kvm/interrupts_head.S
> +++ b/arch/arm/kvm/interrupts_head.S
> @@ -264,11 +264,10 @@ vcpu .req r0 @ vcpu pointer always in r0
> str r3, [vcpu, #CP15_OFFSET(c1_CPACR)]
> str r4, [vcpu, #CP15_OFFSET(c2_TTBCR)]
> str r5, [vcpu, #CP15_OFFSET(c3_DACR)]
> - add vcpu, vcpu, #CP15_OFFSET(c2_TTBR0)
> - strd r6, r7, [vcpu]
> - add vcpu, vcpu, #CP15_OFFSET(c2_TTBR1) - CP15_OFFSET(c2_TTBR0)
> - strd r8, r9, [vcpu]
> - sub vcpu, vcpu, #CP15_OFFSET(c2_TTBR1)
> + add r2, vcpu, #CP15_OFFSET(c2_TTBR0)
> + strd r6, r7, [r2]
> + add r2, vcpu, #CP15_OFFSET(c2_TTBR1)
> + strd r8, r9, [r2]
> str r10, [vcpu, #CP15_OFFSET(c10_PRRR)]
> str r11, [vcpu, #CP15_OFFSET(c10_NMRR)]
> str r12, [vcpu, #CP15_OFFSET(c0_CSSELR)]
> @@ -362,11 +361,10 @@ vcpu .req r0 @ vcpu pointer always in r0
> ldr r3, [vcpu, #CP15_OFFSET(c1_CPACR)]
> ldr r4, [vcpu, #CP15_OFFSET(c2_TTBCR)]
> ldr r5, [vcpu, #CP15_OFFSET(c3_DACR)]
> - add vcpu, vcpu, #CP15_OFFSET(c2_TTBR0)
> - ldrd r6, r7, [vcpu]
> - add vcpu, vcpu, #CP15_OFFSET(c2_TTBR1) - CP15_OFFSET(c2_TTBR0)
> - ldrd r8, r9, [vcpu]
> - sub vcpu, vcpu, #CP15_OFFSET(c2_TTBR1)
> + add r12, vcpu, #CP15_OFFSET(c2_TTBR0)
> + ldrd r6, r7, [r12]
> + add r12, vcpu, #CP15_OFFSET(c2_TTBR1)
> + ldrd r8, r9, [r12]
> ldr r10, [vcpu, #CP15_OFFSET(c10_PRRR)]
> ldr r11, [vcpu, #CP15_OFFSET(c10_NMRR)]
> ldr r12, [vcpu, #CP15_OFFSET(c0_CSSELR)]
> @@ -479,7 +477,7 @@ vcpu .req r0 @ vcpu pointer always in r0
> * for the host.
> *
> * Assumes vcpu pointer in vcpu reg
> - * Clobbers r2-r4
> + * Clobbers r2-r5
> */
> .macro save_timer_state
> #ifdef CONFIG_KVM_ARM_TIMER
> @@ -496,9 +494,8 @@ vcpu .req r0 @ vcpu pointer always in r0
>
> mrrc p15, 3, r2, r3, c14 @ CNTV_CVAL
> ldr r4, =VCPU_TIMER_CNTV_CVAL
> - add vcpu, vcpu, r4
> - strd r2, r3, [vcpu]
> - sub vcpu, vcpu, r4
> + add r5, vcpu, r4
> + strd r2, r3, [r5]
>
> 1:
> #endif
> @@ -513,7 +510,7 @@ vcpu .req r0 @ vcpu pointer always in r0
> * for the host.
> *
> * Assumes vcpu pointer in vcpu reg
> - * Clobbers r2-r4
> + * Clobbers r2-r5
> */
> .macro restore_timer_state
> @ Disallow physical timer access for the guest
> @@ -534,9 +531,8 @@ vcpu .req r0 @ vcpu pointer always in r0
> mcrr p15, 4, r2, r3, c14 @ CNTVOFF
>
> ldr r4, =VCPU_TIMER_CNTV_CVAL
> - add vcpu, vcpu, r4
> - ldrd r2, r3, [vcpu]
> - sub vcpu, vcpu, r4
> + add r5, vcpu, r4
> + ldrd r2, r3, [r5]
> mcrr p15, 3, r2, r3, c14 @ CNTV_CVAL
> isb
>
> --
> 1.8.1
>
much nicer, thanks.
-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