* [PATCH] ARM: mxs_defconfig: Select CONFIG_DEVTMPFS_MOUNT
From: Shawn Guo @ 2013-01-17 2:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358386324-23995-1-git-send-email-festevam@gmail.com>
On Wed, Jan 16, 2013 at 11:32:04PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Newer versions of udev (such as 182) requires CONFIG_DEVTMPFS_MOUNT to be
> selected, otherwise we get a stuck console:
>
> Starting udev
> Starting Bootlog daemon: bootlogd: cannot deduce real console device
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v4] video: imxfb: Do not crash on reboot
From: Shawn Guo @ 2013-01-17 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358341121-19480-1-git-send-email-fabio.estevam@freescale.com>
On Wed, Jan 16, 2013 at 10:58:41AM -0200, Fabio Estevam wrote:
> Shawn,
>
> Since you have taken a patch recently that touches this file and given the fact
> that we have zero response from the fb maintainer, can you please apply it via
> imx tree?
Ok, I will queue it as the 3rd batch of fixes to be sent next week.
Is it a material for stable tree?
Shawn
^ permalink raw reply
* [PATCH] arm: mxs: Update mxs_defconfig
From: Shawn Guo @ 2013-01-17 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301170222.51048.marex@denx.de>
On Thu, Jan 17, 2013 at 02:22:50AM +0100, Marek Vasut wrote:
> Do you think this can be made a stable matter for 3.7 ? It's a defconfig update
> afterall and it help a great deal.
>
No, I don't think so. Sorry.
Shawn
^ permalink raw reply
* [PATCH v5 03/14] KVM: ARM: Initial skeleton to compile KVM support
From: Rusty Russell @ 2013-01-17 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116094444.GP23505@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Wed, Jan 16, 2013 at 01:26:01PM +1030, Rusty Russell wrote:
>> Christoffer Dall <c.dall@virtualopensystems.com> writes:
>>
>> > On Mon, Jan 14, 2013 at 11:24 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Tue, Jan 08, 2013 at 01:38:55PM -0500, Christoffer Dall wrote:
>> >>> + /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
>> >>> + for (i = 0; i < sizeof(init->features)*8; i++) {
>> >>> + if (init->features[i / 32] & (1 << (i % 32))) {
>> >>
>> >> Isn't this an open-coded version of test_bit() ?
>> >
>> > indeed, nicely spotted:
>>
>> BTW, I wrote it that was out of excessive paranoia: it's a userspace
>> API, and test_bit() won't be right on 64 bit BE systems.
>
> So why is this a concern for 32-bit systems (which are, by definition,
> only in arch/arm) ?
Because this feature bitmap system is the same code which other archs
*should* be using for specifying kvm cpus :)
Cheers,
Rusty.
^ permalink raw reply
* [PATCH v3 1/3] ARM i.MX6: change mxs usbphy clock usage
From: Shawn Guo @ 2013-01-17 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358326745-25018-1-git-send-email-peter.chen@freescale.com>
On Wed, Jan 16, 2013 at 04:59:03PM +0800, Peter Chen wrote:
> This mxs usbphy is only needs to be on after system boots
> up, and software never needs to control it anymore.
> Meanwhile, usbphy's parent needs to be notified if usb
> is suspend or not. So we design below mxs usbphy usage:
>
> - usbphy1_gate and usbphy2_gate:
> Their parents are dummy clock, we only needs to enable
> it after system boots up.
> - usbphy1 and usbphy2
> Usage reserved bit for this clock, in that case, the refcount
> will be updated, but without hardware changing.
>
Ok, so we change the clocks usbphy1 and ushphy2 to access a reserved bit
for gating. Then usbphy driver can play the clocks to maintain the use
count for parent PLL, which may have other child clocks, while leaving
the actual gating control to hardware.
Meanwhile, we add new clocks usbphy1_gate and ushphy2_gate being the
children of dummy clock to accessing the real gate bit. Then clock
initialization can call clk_prepare_enable to enable for only once.
Though I feel this is a total hack, I do not see any other better option
to fulfill the hardware requirement with the least churn to software.
So I'm fine with it.
See one minor comment below.
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> Changes for v3:
> - Add new clk for usbphy clk gate which is only used
> at system boots up process.
>
> Changes for v2:
> - Use reserved bit for usb phy clk control
>
> arch/arm/mach-imx/clk-imx6q.c | 26 ++++++++++++++++++++++----
> 1 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index 7f2c10c..ccb24cf 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -154,8 +154,8 @@ enum mx6q_clks {
> usdhc4, vdo_axi, vpu_axi, cko1, pll1_sys, pll2_bus, pll3_usb_otg,
> pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
> ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
> - sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
> - clk_max
> + sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
> + usbphy2_gate, clk_max
usbphy1_gate and usbphy2_gate need to be numbered in binding doc.
Shawn
> };
>
> static struct clk *clk[clk_max];
> @@ -208,8 +208,21 @@ int __init mx6q_clocks_init(void)
> clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_usb_host","osc", base + 0x20, 0x3);
> clk[pll8_mlb] = imx_clk_pllv3(IMX_PLLV3_MLB, "pll8_mlb", "osc", base + 0xd0, 0x0);
>
> - clk[usbphy1] = imx_clk_gate("usbphy1", "pll3_usb_otg", base + 0x10, 6);
> - clk[usbphy2] = imx_clk_gate("usbphy2", "pll7_usb_host", base + 0x20, 6);
> + /*
> + * Bit 20 is the reserved and read-only bit, we do this only for:
> + * - Do nothing for usbphy clk_enable/disable
> + * - Keep refcount when do usbphy clk_enable/disable, in that case,
> + * the clk framework may need to enable/disable usbphy's parent
> + */
> + clk[usbphy1] = imx_clk_gate("usbphy1", "pll3_usb_otg", base + 0x10, 20);
> + clk[usbphy2] = imx_clk_gate("usbphy2", "pll7_usb_host", base + 0x20, 20);
> +
> + /*
> + * usbphy*_gate needs to be on after system boots up, and software
> + * never needs to control it anymore.
> + */
> + clk[usbphy1_gate] = imx_clk_gate("usbphy1_gate", "dummy", base + 0x10, 6);
> + clk[usbphy2_gate] = imx_clk_gate("usbphy2_gate", "dummy", base + 0x20, 6);
>
> clk[sata_ref] = imx_clk_fixed_factor("sata_ref", "pll6_enet", 1, 5);
> clk[pcie_ref] = imx_clk_fixed_factor("pcie_ref", "pll6_enet", 1, 4);
> @@ -436,6 +449,11 @@ int __init mx6q_clocks_init(void)
> for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> clk_prepare_enable(clk[clks_init_on[i]]);
>
> + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> + clk_prepare_enable(clk[usbphy1_gate]);
> + clk_prepare_enable(clk[usbphy2_gate]);
> + }
> +
> np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
> base = of_iomap(np, 0);
> WARN_ON(!base);
> --
> 1.7.0.4
>
>
^ permalink raw reply
* [PATCH V4 5/5] ARM: tegra20: cpuidle: apply coupled cpuidle for powered-down mode
From: Joseph Lo @ 2013-01-17 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRTmGVrjnKa_z+zonGypU+U4r2iE=D-Zfvyoq8chY68QKQ@mail.gmail.com>
On Thu, 2013-01-17 at 02:55 +0800, 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
> > which is exactly the same meaning of "CPU power down".
> >
> > Based on the work by:
> > Colin Cross <ccross@android.com>
> > Gary King <gking@nvidia.com>
> >
> > Signed-off-by: Joseph Lo <josephl@nvidia.com>
> > ---
> > V4:
> > * rename the function to "tegra20_wake_cpu1_from_reset"
> > * make the coupled cpuidle can be disabled if SMP is disabled
> > V3:
> > * sqash last two patch in previous version to support coupled cpuidle
> > directly
> > V2:
> > * refine the cpu control function that dedicate for CPU_1
> > * rename "tegra_cpu_pllp" to "tegra_switch_cpu_to_pllp"
> > ---
>
> <snip>
>
> > diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
> > index 50f984d..63ab9c2 100644
> > --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
> > +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
>
> <snip>
>
> > @@ -87,20 +176,31 @@ static inline bool tegra20_idle_enter_lp2_cpu_1(struct cpuidle_device *dev,
> > }
> > #endif
> >
> > -static int tegra20_idle_lp2(struct cpuidle_device *dev,
> > - struct cpuidle_driver *drv,
> > - int index)
> > +static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
> > + struct cpuidle_driver *drv,
> > + int index)
> > {
> > u32 cpu = is_smp() ? cpu_logical_map(dev->cpu) : dev->cpu;
> > bool entered_lp2 = false;
> >
> > + if (tegra_pending_sgi())
> > + atomic_inc(&abort_flag);
> Minor nit, this doesn't need to be atomic. You could just use
> abort_flag = true, or ACCESS_ONCE(abort_flag) = true. Each cpu will
> either not touch this variable or write 1 to it, so there is no
> read/modify/write race.
>
Thanks for your remind. There is a reason I don't use a boolean flag
here. The SGI register was per CPU register. Different CPU may get
different content of the register depend on there is a SGI pending or
not. That's why I don't use a boolean flag that may be overwritten by
the other CPU here.
So I think I can just modify as follows and remove atomic operation.
if (tegra_pending_sgi())
abort_flag++;
if (abort_flag > 0)
abort coupled cpuidle;
> > +
> > + cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
> > +
> > + if (atomic_read(&abort_flag) > 0) {
> > + cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
> > + atomic_set(&abort_flag, 0); /* clean flag for next coming */
> > + return -EINTR;
> > + }
> > +
> > local_fiq_disable();
> >
> > tegra_set_cpu_in_lp2(cpu);
> > cpu_pm_enter();
> >
> > if (cpu == 0)
> > - cpu_do_idle();
> > + entered_lp2 = tegra20_cpu_cluster_power_down(dev, drv, index);
> > else
> > entered_lp2 = tegra20_idle_enter_lp2_cpu_1(dev, drv, index);
> >
> > @@ -122,6 +222,10 @@ int __init tegra20_cpuidle_init(void)
> > struct cpuidle_device *dev;
> > struct cpuidle_driver *drv = &tegra_idle_driver;
> >
> > +#ifdef CONFIG_PM_SLEEP
> > + tegra_tear_down_cpu = tegra20_tear_down_cpu;
> > +#endif
> > +
> > drv->state_count = ARRAY_SIZE(tegra_idle_states);
> > memcpy(drv->states, tegra_idle_states,
> > drv->state_count * sizeof(drv->states[0]));
> > @@ -135,6 +239,9 @@ int __init tegra20_cpuidle_init(void)
> > for_each_possible_cpu(cpu) {
> > dev = &per_cpu(tegra_idle_device, cpu);
> > dev->cpu = cpu;
> > +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> > + dev->coupled_cpus = *cpu_online_mask;
> I think this should be cpu_possible_mask instead of cpu_online_mask.
> coupled.c already makes sure that only online cpus are considered by
> the synchronization code. If cpuidle were compiled as a module and
> loaded after offlining a cpu, you would hit the WARN_ON in
> cpuidle_coupled_register_device when onlining a cpu.
>
Fair enough to me.
Thanks,
Joseph
> > +#endif
> >
> > dev->state_count = drv->state_count;
> > ret = cpuidle_register_device(dev);
^ permalink raw reply
* [PATCH] ARM: mxs_defconfig: Select CONFIG_DEVTMPFS_MOUNT
From: Fabio Estevam @ 2013-01-17 1:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Newer versions of udev (such as 182) requires CONFIG_DEVTMPFS_MOUNT to be
selected, otherwise we get a stuck console:
Starting udev
Starting Bootlog daemon: bootlogd: cannot deduce real console device
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/configs/mxs_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index dfd5c82..fbbc5bb 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -48,6 +48,7 @@ CONFIG_CAN_BCM=m
CONFIG_CAN_FLEXCAN=m
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: imx23-olinuxino: Add i2c support
From: Shawn Guo @ 2013-01-17 1:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358273796-421-1-git-send-email-f.koliqi@gmail.com>
On Tue, Jan 15, 2013 at 01:16:36PM -0500, Fadil Berisha wrote:
> From: Fadil Berisha <f.koliqi@gmail.com>
>
> mx23-olinuxino board has i2c interface exposed on UEXT connector. This patch
> add i2c support. Test is done with module MOD-IO2 attached on UEXT connector.
>
> Signed-off-by: Fadil Berisha <f.koliqi@gmail.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> V2:
> Reworked as per Shawn's request. I2C instance has 3 pinmux settings
>
> arch/arm/boot/dts/imx23-olinuxino.dts | 6 +++++
> arch/arm/boot/dts/imx23.dtsi | 41 ++++++++++++++++++++++++++++++++-
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
> index e7484e4..a43141a 100644
> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
> @@ -68,6 +68,12 @@
> };
>
> apbx at 80040000 {
> + i2c0: i2c at 80058000 {
I guess the label "i2c0:" is being copied from imx28 dts, which is
unnecessary for imx23, since we only have one i2c in total here. Or
at least to have the label be "i2c" to align with pinctrl label below.
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_b>;
> + status = "okay";
> + };
Bad indent?
> +
> duart: serial at 80070000 {
> pinctrl-names = "default";
> pinctrl-0 = <&duart_pins_a>;
> diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> index 65415c5..6954b69 100644
> --- a/arch/arm/boot/dts/imx23.dtsi
> +++ b/arch/arm/boot/dts/imx23.dtsi
> @@ -292,6 +292,39 @@
> fsl,voltage = <1>;
> fsl,pull-up = <1>;
> };
> +
> + i2c_pins_a: i2c at 0 {
> + reg = <0>;
> + fsl,pinmux-ids = <
> + 0x01e0 /* MX23_PAD_I2C_SCL__I2C_SCL */
> + 0x01f0 /* MX23_PAD_I2C_SDA__I2C_SDA */
> + >;
> + fsl,drive-strength = <1>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <1>;
> + };
> +
> + i2c_pins_b: i2c at 1 {
> + reg = <1>;
> + fsl,pinmux-ids = <
> + 0x1171 /* MX23_PAD_LCD_ENABLE__I2C_SCL */
> + 0x1181 /* MX23_PAD_LCD_HSYNC__I2C_SDA */
> + >;
> + fsl,drive-strength = <1>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <1>;
> + };
> +
> + i2c_pins_c: i2c at 2 {
> + reg = <2>;
> + fsl,pinmux-ids = <
> + 0x2031 /* MX23_PAD_SSP1_DATA1__I2C_SCL */
> + 0x2041 /* MX23_PAD_SSP1_DATA2__I2C_SDA */
> + >;
> + fsl,drive-strength = <1>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <1>;
> + };
> };
>
> digctl at 8001c000 {
> @@ -400,8 +433,14 @@
> status = "disabled";
> };
>
> - i2c at 80058000 {
> + i2c0: i2c at 80058000 {
Ditto on the label.
Shawn
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx28-i2c";
> reg = <0x80058000 0x2000>;
> + interrupts = <27 26>;
> + clock-frequency = <100000>;
> + fsl,i2c-dma-channel = <3>;
> status = "disabled";
> };
>
> --
> 1.7.10
>
^ permalink raw reply
* [PATCH] arm: mxs: Update mxs_defconfig
From: Marek Vasut @ 2013-01-17 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117012010.GA26179@S2101-09.ap.freescale.net>
Dear Shawn Guo,
> On Tue, Jan 15, 2013 at 05:31:05PM -0200, Fabio Estevam wrote:
> > Shawn,
> >
> > On Tue, Dec 25, 2012 at 11:23 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > > Applied with one comment below to Fabio.
> >
> > Which tree this was applied?
>
> Just pushed out branch mxs/soc.
Do you think this can be made a stable matter for 3.7 ? It's a defconfig update
afterall and it help a great deal.
> Shawn
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] arm: mxs: Update mxs_defconfig
From: Shawn Guo @ 2013-01-17 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Bxk44dug4XajZLHS2e==cBcLuUcSaGCrOrjPMpkDZ1VA@mail.gmail.com>
On Tue, Jan 15, 2013 at 05:31:05PM -0200, Fabio Estevam wrote:
> Shawn,
>
> On Tue, Dec 25, 2012 at 11:23 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
>
> > Applied with one comment below to Fabio.
>
> Which tree this was applied?
>
Just pushed out branch mxs/soc.
Shawn
^ permalink raw reply
* [PATCH v2] drivers/pinctrl: grab default handles from device core
From: Linus Walleij @ 2013-01-17 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6E811.2040606@wwwdotorg.org>
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?
Mainly asking because once Greg ACKs that patch I want to
put it into the pinctrl tree...
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Samsung fixes-3 for v3.8
From: Olof Johansson @ 2013-01-17 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c1201cdf44a$8e44c040$aace40c0$@samsung.com>
On Wed, Jan 16, 2013 at 4:35 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> > Sachin Kamat (2):
>> > ARM: S3C24XX: Fix warnings in irq-s3c2416.c
>> > ARM: S3C24XX: Make 'clk_msysclk' static
>>
>> Those two are sparse fixes, please queue for 3.9 instead.
>>
> Agreed, it's not critical. I did. Can you pull same branch?
>
> If you want new branch for this, let me know.
Same branch is fine, will pull tonight.
-Olof
^ permalink raw reply
* [GIT PULL] Samsung fixes-3 for v3.8
From: Kukjin Kim @ 2013-01-17 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiRSUbsnP2cCC=Ur9zL1CG9HGT0AQZ_fMktL+QAUmiDzA@mail.gmail.com>
Olof Johansson wrote:
>
> Hi,
>
> On Wed, Jan 16, 2013 at 4:10 PM, Kukjin Kim <kgene.kim@samsung.com>
> wrote:
> > Hi Arnd, Olof
> >
> > Here is Samsung fixes for v3.8, please pull from:
> > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > v3.8-samsung-fixes-3
> >
> > That branch fixes build warnings and error for S3C24XX/S3C64xx. And
> corrects
> > dw-mshc properties on EXYNOS5 DT and fixes IRQ mapping on
> Cragganmore board.
> >
> > If any problems, please kindly let me know.
> >
> > Thanks.
> >
> > - Kukjin
> >
> > The following changes since commit
> 9931faca02c604c22335f5a935a501bb2ace6e20:
> >
> > Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > v3.8-samsung-fixes-3
> >
> > for you to fetch changes up to
> cd9a8934a28d604ffb62e80ab08ba12fab128a1e:
> >
> > ARM: S3C24XX: Make 'clk_msysclk' static (2013-01-16 15:53:48 -0800)
> >
> > ----------------------------------------------------------------
> > Alim Akhtar (1):
> > ARM: dts: correct the dw-mshc timing properties as per binding
> >
> > Dimitris Papastamos (1):
> > ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
> >
> > Sachin Kamat (2):
> > ARM: S3C24XX: Fix warnings in irq-s3c2416.c
> > ARM: S3C24XX: Make 'clk_msysclk' static
>
> Those two are sparse fixes, please queue for 3.9 instead.
>
Agreed, it's not critical. I did. Can you pull same branch?
If you want new branch for this, let me know.
Thanks.
- Kukjin
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.8-samsung-fixes-3
for you to fetch changes up to b86dc0d8c12bbb9fed3f392c284bdc7114ce00c1:
ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore (2013-01-16
15:49:53 -0800)
----------------------------------------------------------------
Alim Akhtar (1):
ARM: dts: correct the dw-mshc timing properties as per binding
Dimitris Papastamos (1):
ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
Tomasz Figa (1):
ARM: S3C64XX: Fix build error with CONFIG_S3C_DEV_FB disabled
arch/arm/boot/dts/cros5250-common.dtsi | 12 ++++++------
arch/arm/boot/dts/exynos5250-smdk5250.dts | 8 ++++----
arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +-
arch/arm/mach-s3c64xx/pm.c | 2 ++
4 files changed, 13 insertions(+), 11 deletions(-)
^ permalink raw reply
* [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type
From: Simon Horman @ 2013-01-17 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358348462-27693-4-git-send-email-kishon@ti.com>
On Wed, Jan 16, 2013 at 08:30:59PM +0530, 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 +-
Modification to the above file:
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [GIT PULL] Samsung fixes-3 for v3.8
From: Olof Johansson @ 2013-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c0301cdf447$109e7d50$31db77f0$@samsung.com>
Hi,
On Wed, Jan 16, 2013 at 4:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Hi Arnd, Olof
>
> Here is Samsung fixes for v3.8, please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v3.8-samsung-fixes-3
>
> That branch fixes build warnings and error for S3C24XX/S3C64xx. And corrects
> dw-mshc properties on EXYNOS5 DT and fixes IRQ mapping on Cragganmore board.
>
> If any problems, please kindly let me know.
>
> Thanks.
>
> - Kukjin
>
> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
>
> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v3.8-samsung-fixes-3
>
> for you to fetch changes up to cd9a8934a28d604ffb62e80ab08ba12fab128a1e:
>
> ARM: S3C24XX: Make 'clk_msysclk' static (2013-01-16 15:53:48 -0800)
>
> ----------------------------------------------------------------
> Alim Akhtar (1):
> ARM: dts: correct the dw-mshc timing properties as per binding
>
> Dimitris Papastamos (1):
> ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
>
> Sachin Kamat (2):
> ARM: S3C24XX: Fix warnings in irq-s3c2416.c
> ARM: S3C24XX: Make 'clk_msysclk' static
Those two are sparse fixes, please queue for 3.9 instead.
-Olof
^ permalink raw reply
* [GIT PULL] Samsung fixes-3 for v3.8
From: Kukjin Kim @ 2013-01-17 0:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
Here is Samsung fixes for v3.8, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.8-samsung-fixes-3
That branch fixes build warnings and error for S3C24XX/S3C64xx. And corrects
dw-mshc properties on EXYNOS5 DT and fixes IRQ mapping on Cragganmore board.
If any problems, please kindly let me know.
Thanks.
- Kukjin
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.8-samsung-fixes-3
for you to fetch changes up to cd9a8934a28d604ffb62e80ab08ba12fab128a1e:
ARM: S3C24XX: Make 'clk_msysclk' static (2013-01-16 15:53:48 -0800)
----------------------------------------------------------------
Alim Akhtar (1):
ARM: dts: correct the dw-mshc timing properties as per binding
Dimitris Papastamos (1):
ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
Sachin Kamat (2):
ARM: S3C24XX: Fix warnings in irq-s3c2416.c
ARM: S3C24XX: Make 'clk_msysclk' static
Tomasz Figa (1):
ARM: S3C64XX: Fix build error with CONFIG_S3C_DEV_FB disabled
arch/arm/boot/dts/cros5250-common.dtsi | 12 ++++++------
arch/arm/boot/dts/exynos5250-smdk5250.dts | 8 ++++----
arch/arm/mach-s3c24xx/common-s3c2443.c | 2 +-
arch/arm/mach-s3c24xx/irq-s3c2416.c | 6 +++---
arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +-
arch/arm/mach-s3c64xx/pm.c | 2 ++
6 files changed, 17 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH] ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
From: Kukjin Kim @ 2013-01-17 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358016152-5056-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> From: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
>
> We are using S3C_EINT(4) instead of S3C_EINT(5).
>
> Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: stable at vger.kernel.org
> ---
> arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> index 553059f..755c0bb 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> @@ -47,7 +47,7 @@ static struct spi_board_info wm1253_devs[] = {
> .bus_num = 0,
> .chip_select = 0,
> .mode = SPI_MODE_0,
> - .irq = S3C_EINT(5),
> + .irq = S3C_EINT(4),
> .controller_data = &wm0010_spi_csinfo,
> .platform_data = &wm0010_pdata,
> },
> --
> 1.7.10.4
Applied, thanks.
- Kukjin
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC v3.9
From: Olof Johansson @ 2013-01-16 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116063750.GA11765@verge.net.au>
On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> I have some complex dependencies for mach-shmobile for v3.9
> and as such I am sending this email outline the dependencies
> of branches on each other. I have also included the multiple
> pull requests below though I am happy to post them
> individually including the patches they comprise if you
> have no objections to the way the branch dependencies are arranged.
>
> I would also be happy to supply a single branch with all changes
> with or without merge commits.
Hmm, complex indeed.
Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
sh/pinctrl dependencies? That's what really makes things look complicated
here. If you could move the final cleanup/code removal pieces out of
the sh/pinctrl branches such that you have a less iterative chain of:
sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members, etc)
... but I haven't looked in detail at the per-patch dependencies to see how
tough that would be to arrange.
> All branches are present in the renesas tree
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
>
> 1. Branch: sh-soc
> Description: Pre-requisites for pfc changes for SH SoCs
> Based on: v3.8-rc1
>
> 2. Branch: clocksource
> Description: Pre-requisite clocksource change for soc branch
> Based on: v3.8-rc1
>
> 3. Branch: pfc
> Description: PFC Updates
> Based on: sh-soc
>
> 4. Branch: sh-soc2
> Description: Further PFC changes for SH SoCs
> Based on: pfc
>
> 5. Branch: soc
> Description: shmobile (ARM) SoCs updates, including PFC changes.
> Based on: a merge of clocksource and pfc
>
> 6. Branch: boards
> Description: Board changes, including PFC changes.
> Based on: A merge of timer/cleanup (present in the arm-soc tree) and soc
>
> 7. Branch: pfc2
> Description: Further PFC changes which depend on SoC changes
> Based on: A merge of sh-soc2 and soc
>
> 8. Branch: sh-soc3
> Description: Further PFC changes for SH SoCs
> Based on: pfc2
>
> 9. Branch: soc2
> Description: Further PFC changes for shmobile (ARM) SoCs
> Based on: A merge of timer/cleanup (present in the arm-soc tree) and pfc2
>
> 10. Branch: pfc3
> Description: Description: Further PFC changes which depend on SoC changes
> Based on: A merge of sh-soc3 and soc2
Looking at it from the end here, 10 contains only arch/sh and global
changes, and depends on 8 and 9. 8 also contains only sh changes. So it
looks like 8 and 10 could be pruned from this pull request and go through
either SH or pinctrl.
What pieces from branch 7 are stronly needed? A couple of the added pinctrl
modules are used by mach-shmobile boards, it seems. And the structure rename
might also be needed.
Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
difference.
For branch 2 (clocksource include order), I'd like to see an ack from John or
Thomas. Does it really make sense to base that on an ifdef instead of always
initialize early?
Branch 4 seems to be mostly sh-specific updates. With some of the later
dependencies avoided, maybe this branch can be dropped too, not sure?
About half of branch 5 looks like it's generic SoC-updates unrelated
to the pinctrl rework, and branch 6 looks like mostly regular
patches/updates, is that stronly dependent on all the pinctrl
rework? Doesn't look like it should be?
-Olof
^ permalink raw reply
* [PATCH] tty: serial/vt8500_serial.c: fix bug caused by missing "{}"
From: Tony Prisk @ 2013-01-16 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358375103-11703-1-git-send-email-dinggnu@gmail.com>
On Wed, 2013-01-16 at 23:25 +0100, Cong Ding wrote:
> It is obviously here should be braced by "{}" in the "if" branch (more than 1
> line in the "if" branch), and by the
> coding style document of the kernel I also add "{}" to the else branch.
>
> Signed-off-by: Cong Ding <dinggnu@gmail.com>
> ---
> drivers/tty/serial/vt8500_serial.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/vt8500_serial.c b/drivers/tty/serial/vt8500_serial.c
> index 8fd1814..ac46a6e 100644
> --- a/drivers/tty/serial/vt8500_serial.c
> +++ b/drivers/tty/serial/vt8500_serial.c
> @@ -567,12 +567,13 @@ static int vt8500_serial_probe(struct platform_device *pdev)
> if (!mmres || !irqres)
> return -ENODEV;
>
> - if (np)
> + if (np) {
> port = of_alias_get_id(np, "serial");
> if (port > VT8500_MAX_PORTS)
> port = -1;
> - else
> + } else {
> port = -1;
> + }
>
> if (port < 0) {
> /* calculate the port id */
Correct. This patch is good but unnecessary now as the patch series I
pushed out removes this code anyway.
It should be applied if the series I sent out is not accepted in this
merge windows.
Regards
Tony P
^ permalink raw reply
* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: Tejun Heo @ 2013-01-16 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358332355.2384.11.camel@dabdike.int.hansenpartnership.com>
On Wed, Jan 16, 2013 at 10:32:35AM +0000, James Bottomley wrote:
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 6b2fb87..ab88c5b 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -809,7 +809,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
> op(vaddr, len, dir);
> }
> offset = 0;
> - page++;
> + page = pfn_to_page(page_to_pfn(page) + 1);
Probably page = nth_page(page, 1) is the better form.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] ARM: mm: Fix missing XN flag for for MT_MEMORY_SO
From: Russell King - ARM Linux @ 2013-01-16 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358347762-14682-1-git-send-email-santosh.shilimkar@ti.com>
On Wed, Jan 16, 2013 at 08:19:22PM +0530, Santosh Shilimkar wrote:
> Commit 8fb54284ba6a {ARM: mm: Add strongly ordered descriptor support}
> added XN flag at section level but missed it at PTE level.
>
> Fix it by adding the L_PTE_XN to MT_MEMORY_SO PET descriptor.
>
> Cc: Russell King <linux@arm.linux.org.uk>
>
> Reported-by: Richard Woodruff <r-woodruff2@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
Hmm, yes. => patch system please.
> arch/arm/mm/mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 9f06102..ce328c7 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -283,7 +283,7 @@ static struct mem_type mem_types[] = {
> },
> [MT_MEMORY_SO] = {
> .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> - L_PTE_MT_UNCACHED,
> + L_PTE_MT_UNCACHED | L_PTE_XN,
> .prot_l1 = PMD_TYPE_TABLE,
> .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_S |
> PMD_SECT_UNCACHED | PMD_SECT_XN,
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: Russell King - ARM Linux @ 2013-01-16 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358332355.2384.11.camel@dabdike.int.hansenpartnership.com>
On Wed, Jan 16, 2013 at 10:32:35AM +0000, James Bottomley wrote:
> On Wed, 2013-01-16 at 12:07 +0530, Subhash Jadavani wrote:
>
> > Now consider this call stack from MMC block driver (this is on the ARmv7
> > based board):
> > [ 98.918174] [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from
> > [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
> > [ 98.927819] [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from
> > [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
> > [ 98.937982] [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from
> > [<c0017ff8>] (dma_map_sg+0x3c/0x114)
>
> OK, so this is showing that ARM itself is making the assumption that the
> pages are contiguous in the page offset map.
>
> Fix this by doing the increment via the pfn, which will do the right
> thing whatever the memory model.
>
> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Ok. What would you like the patch summary line for this to be -
the existing one seems to be a little wrong given the content of
this patch...
>
> ---
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 6b2fb87..ab88c5b 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -809,7 +809,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
> op(vaddr, len, dir);
> }
> offset = 0;
> - page++;
> + page = pfn_to_page(page_to_pfn(page) + 1);
> left -= len;
> } while (left);
> }
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
From: Soeren Moch @ 2013-01-16 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116175203.GK25500@titan.lakedaemon.net>
On 16.01.2013 18:52, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 06:05:59PM +0100, Soeren Moch wrote:
>> On 16.01.2013 16:50, Jason Cooper wrote:
>>> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>>>> On 16.01.2013 04:24, Soeren Moch wrote:
>>>>> On 16.01.2013 03:40, Jason Cooper wrote:
>>>>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>
>>>> OK, I could trigger the error
>>>> ERROR: 1024 KiB atomic DMA coherent pool is too small!
>>>> Please increase it with coherent_pool= kernel parameter!
>>>> only with em28xx sticks and sata, dib0700 sticks removed.
>>>
>>> Did you test the reverse scenario? ie dib0700 with sata_mv and no
>>> em28xx.
>>
>> Maybe I can test this next night.
>
> Please do, this will tell us if it is in the USB drivers or lower
> (something in common).
>
>>>>>> What would be most helpful is if you could do a git bisect between
>>>>>> v3.5.x (working) and the oldest version where you know it started
>>>>>> failing (v3.7.1 or earlier if you know it).
>>>>>>
>>>>> I did not bisect it, but Marek mentioned earlier that commit
>>>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>>>> new code for dma allocations. This is probably the root cause for the
>>>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>>>
>>>> I don't want to say that Mareks patch is wrong, probably it triggers a
>>>> bug somewhere else! (in em28xx?)
>>>
>>> Of the four drivers you listed, none are using dma. sata_mv is the only
>>> one.
>>
>> usb_core is doing the actual DMA for the usb bridge drivers, I think.
>
> Yes, my mistake. I'd like to attribute that statement to pre-coffee
> rambling. :-)
>
>>> If one is to believe the comments in sata_mv.c:~151, then the alignment
>>> is wrong for the sg_tbl_pool.
>>>
>>> Could you please try the following patch?
>>
>> OK, what should I test first, the setup from last night (em28xx, no
>> dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
>> without your patch, or my normal setting (all dvb sticks) plus your
>> patch?
>
> if testing time is limited, please do the test I outlined at the top of
> this email. I've been digging more into the dma code and while I think
> the patch is correct, I don't see where it would fix your problem (yet).
Unfortunately test time is limited, and the test has to run about
10 hours to trigger the error.
I also think that sata is not causing the problem.
Maybe your patch even goes in the wrong direction. Perhaps the dma
memory pool is not too small, there might be enough memory available,
but it is too much fragmented to satisfy larger block allocations. With
different drivers allocating totally different block sizes aligned to
bytes or words, perhaps we end up with lots of very small free blocks
in the dma pool after several hours of runtime?
So maybe it would help to align all allocations in the dma pool to 256B?
Regards,
Soeren
^ permalink raw reply
* [PATCH V4 5/5] ARM: tegra20: cpuidle: apply coupled cpuidle for powered-down mode
From: Colin Cross @ 2013-01-16 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F71C21.20904@wwwdotorg.org>
On Wed, Jan 16, 2013 at 1:31 PM, Stephen Warren <swarren@wwwdotorg.org> 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?
I didn't review the Tegra-specific parts careful, but from the coupled
cpuidle perspective, with the comments I pointed out,
Acked-by: Colin Cross <ccross@android.com>
> 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.
>
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-16 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116174736.GJ25500@titan.lakedaemon.net>
On 16.01.2013 18:47, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
>> On 16.01.2013 09:55, Soeren Moch wrote:
>>> On 16.01.2013 04:24, Soeren Moch wrote:
>>>> I did not bisect it, but Marek mentioned earlier that commit
>>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>>> new code for dma allocations. This is probably the root cause for the
>>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>>
>>> I don't want to say that Mareks patch is wrong, probably it triggers a
>>> bug somewhere else! (in em28xx?)
>>
>> The em28xx sticks are using isochronous usb transfers. Is there a
>> special handling for that?
>
> I'm looking at that now. It looks like the em28xx wants (as a maximum)
> 655040 bytes (em28xx-core.c:1088). There are 5 transfer buffers, with
> 64 max packets and 2047 max packet size (runtime reported max & 0x7ff).
>
> If it actually needs all of that, then the answer may be to just
> increase coherent_pool= when using that driver. I'll keep digging.
I already tested with 4M coherent pool size and could not see
significant improvement. Would it make sense to further increase the
buffer size?
Regards,
Soeren
^ 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