* [PATCH 1/4] arch: arm: gpmc: gpmc migration support
From: Tony Lindgren @ 2013-02-01 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358933176-12409-2-git-send-email-avinashphilip@ti.com>
* Philip Avinash <avinashphilip@ti.com> [130123 01:28]:
> With recent GPMC driver conversion, usage of gpmc_save/restore_context
> can done from gpmc driver itself. Hence removes the usage from pm34xx.c.
> Also removes the conditional compilation primitives ARCH_OMAP3 for
> gpmc_save/restore_context.
Hmm I think this will break GPMC for deeper idle modes. Note that we
need to save and restore the context every time hitting off-idle, not
just for suspend and resume. Or am I missing something here?
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
From: Tony Lindgren @ 2013-02-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359736726-10193-2-git-send-email-jon-hunter@ti.com>
* Jon Hunter <jon-hunter@ti.com> [130201 08:42]:
> If the GPMC probe fails, devices that use the GPMC (such as ethernet
> chips, flash memories, etc) can still allocate a GPMC chip-select and
> register the device. On the OMAP2420 H4 board, this was causing the
> kernel to crash after the gpmc probe failed and the board attempted
> to start networking. Prevent this by marking all the chip-selects as
> reserved by default and only make them available for devices to request
> if the GPMC probe succeeds.
Thanks applying into omap-for-v3.9/gpmc.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Tony Lindgren @ 2013-02-01 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128115339.GD7754@e106331-lin.cambridge.arm.com>
* Mark Rutland <mark.rutland@arm.com> [130128 03:57]:
>
> So if I've understood correctly, the first address cell is the CS, and the
> second the offset within this (as the comment in the onenand at 0 node hints)?
>
> If so, the code now makes sense to me :)
Sounds like further checking can be added as needed, so applying this
series into omap-for-v3.9/gpmc.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2] ARM: dts: OMAP3: Add GPMC controller and NAND memory to Overo
From: Tony Lindgren @ 2013-02-01 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359395648-2137-1-git-send-email-florian.vaussard@epfl.ch>
* Florian Vaussard <florian.vaussard@epfl.ch> [130128 09:57]:
> Hello,
>
> This is more an RFC serie, as an issue is still unclear to me.
> Building on the work of Daniel Mack for the GPMC controller (staged
> in Tony's tree [1]), it was easy to add the GPMC controller to OMAP3.
>
> The issue comes from the Overo on-board NAND, as the amount of flash
> depends on the revision. Currently, partitions are handled in the board
> file using MTDPART_SIZ_FULL, but looking at the ofpart parser, the size
> given to the parser must be fixed.
>
> So how should we handle such case? Having several dtsi depending
> on the Overo's revision would be a mess to my sense, considering
> the non-conditional include inside the expansion boards' dts.
> Or would it make sense to extend the DT binding for partitions?
Yes makes sense to extend the binding to use the full flash memory
if the size can be probed.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm: omap: make wakeupgen_lock raw
From: Tony Lindgren @ 2013-02-01 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51023995.1050703@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130124 23:54]:
> On Thursday 24 January 2013 11:52 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Dec 07, 2012 at 04:49:47PM +0200, Felipe Balbi wrote:
> >>From: Thomas Gleixner <tglx@linutronix.de>
> >>
> >>When applying RT patch on top of Linux, spinlocks are
> >>implemented as RT-mutexes, which means they are preemptable.
> >>
> >>Current GIC implementation on OMAP is using a spinlock
> >>to protect against preemption. As it turns out, we need
> >>to convert that lock into a raw_spinlock so that OMAP's
> >>interrupt controller works as expected after RT-patch
> >>is applied.
> >>
> >>This patch is simply to decrease the amount of changes
> >>RT-team needs to carry out of tree. It doesn't cause any
> >>changes in behavior.
> >>
> >>Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> >>Signed-off-by: Felipe Balbi <balbi@ti.com>
> >
> Sorry i missed this patch. Tony can you please
> pick it up?
>
> For the patch,
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
Looks like no comments, so applying this into
omap-for-v3.9/fixes-non-critical.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP: Fix the use of uninitialized dma_lch_count
From: Tony Lindgren @ 2013-02-01 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50EFF99B.7040602@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130111 03:40]:
> On Friday 11 January 2013 11:09 AM, Chen Gang wrote:
> >
> > 'omap_dma_reserve_channels' when used is suppose to be from command.
> > so, it alreay has value before 1st call of omap_system_dma_probe.
> > and it will never be changed again during running (not from ioctl).
> >
> > but 'dma_lch_count' is zero before 1st call of omap_system_dma_probe.
> > so it will be failed for omap_dma_reserve_channels, when 1st call.
> >
> > so, need use 'd->lch_count' instead of 'dma_lch_count' for judging.
> >
> >Signed-off-by: Chen Gang <gang.chen@asianux.com>
> >Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >---
> Looks fine to me.
>
> Tony,
> If you are ok with the patch, can you pick this fix in your
> non-critical fixes branch ?
Yes applying thanks.
Tony
^ permalink raw reply
* [PATCH] omap2: twl-common: Add default power configuration
From: Tony Lindgren @ 2013-02-01 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOCHtYjufr+MS1=6Cnsn-EgvkPs+Y5oWejAG98aLkVjdQbu1ZA@mail.gmail.com>
Hi,
* Robert Nelson <robertcnelson@gmail.com> [130124 07:58]:
> On Wed, Jan 23, 2013 at 12:50 PM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
> > This patch adds a generic power script configuration.
> > When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
> > With the generic power script, TWL4030 will be reset
> > when a warm reset occures. This way the OMAP3530 does not
> > hang on reboot.
Both look OK to me. I've added Peter to cc, it's best that he queues
all the twl changes.
Regards,
Tony
> > Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> > ---
> > arch/arm/mach-omap2/twl-common.c | 38 ++++++++++++++++++++++++++++++++++++++
> > arch/arm/mach-omap2/twl-common.h | 1 +
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> > index e49b40b..f096beb 100644
> > --- a/arch/arm/mach-omap2/twl-common.c
> > +++ b/arch/arm/mach-omap2/twl-common.c
> > @@ -120,6 +120,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
> > .codec = &omap3_codec,
> > };
> >
> > +static struct twl4030_ins wrst_seq[] __initdata = {
> > + {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
> > + {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
> > + {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
> > + {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
> > + {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
> > + {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
> > +};
> > +
> > +static struct twl4030_script wrst_script __initdata = {
> > + .script = wrst_seq,
> > + .size = ARRAY_SIZE(wrst_seq),
> > + .flags = TWL4030_WRST_SCRIPT,
> > +};
> > +
> > +static struct twl4030_script *omap3_power_scripts[] __initdata = {
> > + &wrst_script,
> > +};
> > +
> > +static struct twl4030_resconfig omap3_rconfig[] = {
> > + { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
> > + .type2 = -1 },
> > + { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
> > + .type2 = -1 },
> > + { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
> > + .type2 = -1 },
> > + { 0, 0},
> > +};
> > +
> > +static struct twl4030_power_data omap3_power_pdata = {
> > + .scripts = omap3_power_scripts,
> > + .num = ARRAY_SIZE(omap3_power_scripts),
> > + .resource_config = omap3_rconfig,
> > +};
> > +
> > static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
> > REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
> > };
> > @@ -224,6 +259,9 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
> > if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
> > pmic_data->audio = &omap3_audio_pdata;
> >
> > + if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
> > + pmic_data->power = &omap3_power_pdata;
> > +
> > /* Common regulator configurations */
> > if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
> > pmic_data->vdac = &omap3_vdac_idata;
> > diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
> > index dcfbad5..dbeb905 100644
> > --- a/arch/arm/mach-omap2/twl-common.h
> > +++ b/arch/arm/mach-omap2/twl-common.h
> > @@ -7,6 +7,7 @@
> > #define TWL_COMMON_PDATA_BCI (1 << 1)
> > #define TWL_COMMON_PDATA_MADC (1 << 2)
> > #define TWL_COMMON_PDATA_AUDIO (1 << 3)
> > +#define TWL_COMMON_PDATA_POWER (1 << 4)
> >
> > /* Common LDO regulators for TWL4030/TWL6030 */
> > #define TWL_COMMON_REGULATOR_VDAC (1 << 0)
> > --
> > 1.7.11.7
>
> Thanks for making this generic Matthias..
>
> Tested-by: Robert Nelson <robertcnelson@gmail.com>
>
> Tested on Beagle C4 (omap3530) and Beagle xM (DM3730, no regressions)
> with this patch to enable it on the Beagle..
>
> From 65004dafc8d37c69dd839803dc8ea5dcefd993df Mon Sep 17 00:00:00 2001
> From: Robert Nelson <robertcnelson@gmail.com>
> Date: Thu, 24 Jan 2013 09:43:51 -0600
> Subject: [PATCH] ARM: OMAP: Beagle: use TWL4030 generic reset script
>
> Enable TWL_COMMON_PDATA_POWER such that OMAP3530 revisions of the
> Beagle (Bx/Cx) will not hang on reboot when running at 125 Mhz.
>
> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index 22c483d..0974e08 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -353,7 +353,7 @@ static int __init omap3_beagle_i2c_init(void)
> {
> omap3_pmic_get_config(&beagle_twldata,
> TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_MADC |
> - TWL_COMMON_PDATA_AUDIO,
> + TWL_COMMON_PDATA_AUDIO | TWL_COMMON_PDATA_POWER,
> TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
>
> beagle_twldata.vpll2->constraints.name = "VDVI";
> --
> 1.7.10.4
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
From: Tony Lindgren @ 2013-02-01 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51095D85.6080204@ti.com>
* Jon Hunter <jon-hunter@ti.com> [130130 09:54]:
>
> On 01/30/2013 01:18 AM, Bedia, Vaibhav wrote:
> > On Wed, Jan 30, 2013 at 01:53:11, Hunter, Jon wrote:
> >> Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
> >> device-tree support for selecting a clockevent timer by property.
> >> However, the code is currently ignoring the property passed and
> >> selecting the first available timer found. Hence, for the OMAP3 beagle
> >> board timer-12 is not being selected as expected. Fix this problem
> >> by ensuring the timer property is passed to omap_get_timer_dt().
> >
> > I thought that was intentional ;) and had this change in the clkevt-clksrc
> > interchange patch for AM33xx.
>
> No definitely was not. Thanks, I had missed that detail in the patch you
> sent!
>
> > Anyways, this change works for me so...
> >
> > Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>
> Thanks!
Thanks applying into omap-for-v3.9/fixes-non-critical.
Tony
^ permalink raw reply
* [PATCH] ARM:omap2: using strlcpy instead of strncpy
From: Tony Lindgren @ 2013-02-01 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51090829.1010109@asianux.com>
* Chen Gang <gang.chen@asianux.com> [130130 03:50]:
>
> the fields must be null-terminated:
> the caller may use it as null-terminted string, next.
Added Peter to cc on this one too, it's best that he queues
all the twl changes.
Tony
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> arch/arm/mach-omap2/twl-common.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index e49b40b..6a7aec6 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -23,6 +23,7 @@
> #include <linux/i2c.h>
> #include <linux/i2c/twl.h>
> #include <linux/gpio.h>
> +#include <linux/string.h>
> #include <linux/regulator/machine.h>
> #include <linux/regulator/fixed.h>
>
> @@ -56,7 +57,7 @@ void __init omap_pmic_init(int bus, u32 clkrate,
> struct twl4030_platform_data *pmic_data)
> {
> omap_mux_init_signal("sys_nirq", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
> - strncpy(pmic_i2c_board_info.type, pmic_type,
> + strlcpy(pmic_i2c_board_info.type, pmic_type,
> sizeof(pmic_i2c_board_info.type));
> pmic_i2c_board_info.irq = pmic_irq;
> pmic_i2c_board_info.platform_data = pmic_data;
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH] ARM: AM33xx: Add SoC specific restart hook
From: Tony Lindgren @ 2013-02-01 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358974960-20106-1-git-send-email-jsabeaudry@handyem.com>
* Jean-Sebastien A. Beaudry <jsabeaudry@handyem.com> [130123 13:06]:
> From: "Jean-Sebastien A. Beaudry" <jsabeaudry@handyem.com>
>
> Add restart hook so that DTS based AM33xx builds can restart
> the platform.
Thanks applying into omap-for-v3.9/soc.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ
From: Tony Lindgren @ 2013-02-01 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524396.4DaQLsSWOZ@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [130131 07:41]:
> On Thursday 31 January 2013 21:02:00 Santosh Shilimkar wrote:
> > The timekeeping doesn't depend on HZ value in presence of fine grained
> > clocksource and hence there should not be any time drift because of HZ
> > value which was chosen to be divisor of 32768.
> >
> > OMAP has been using HZ = 128 value to avoid any time drift issues
> > because of 32768 HZ clock. But with various measurements performed
> > with HZ = 100, no time drift is observed and it also proves the
> > point about HZ not having impact on time keeping on OMAP.
> >
> > Very informative thread on this topic is here:
> > https://lkml.org/lkml/2013/1/29/435
> >
> > Special thanks to John Stulz, Arnd Bergmann and Russell King for their
> > valuable suggestions.
> >
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: John Stultz <john.stultz@linaro.org>
> > Cc: Tony Lindgren <tony@atomide.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks so much for looking into this!
Great thanks for checking it Santosh! Applying into
omap-for-v3.9/soc.
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2: AM33XX: id: Add support for AM335x PG2.0
From: Tony Lindgren @ 2013-02-01 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359714502-21528-1-git-send-email-anilkumar@ti.com>
* AnilKumar Ch <anilkumar@ti.com> [130201 02:31]:
> Add support for chip id recognition of AM335x PG2.0 silicon. By default
> omap3xxx_check_revision() recognizes PG1.0, which is extended by adding
> PG2.0 support
Thanks applying into omap-for-v3.9/soc.
Tony
^ permalink raw reply
* [PATCH 2/7] clk: tegra: Use common of_clk_init() function
From: Mike Turquette @ 2013-02-01 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510B496B.2030303@nvidia.com>
Quoting Prashant Gaikwad (2013-01-31 20:49:47)
> On Friday 25 January 2013 10:14 AM, Stephen Warren wrote:
> > On 01/24/2013 04:57 PM, Mike Turquette wrote:
> >> Quoting Stephen Warren (2013-01-24 11:32:37)
> >>> On 01/24/2013 11:20 AM, Mike Turquette wrote:
> >>>> Quoting Prashant Gaikwad (2013-01-04 18:44:48)
> >>>>> On Friday 04 January 2013 10:00 PM, Stephen Warren wrote:
> >>>>>> On 01/04/2013 12:00 AM, Prashant Gaikwad wrote:
> >>>>>>> Use common of_clk_init() function for clocks initialization.
> >>>>>>> drivers/clk/tegra/clk-tegra20.c | 3 ++-
> >>>>>>> drivers/clk/tegra/clk-tegra30.c | 3 ++-
> >>>>>> Oh, so this series is written assuming that the Tegra CCF rework is
> >>>>>> already applied then? That makes the dependencies quite painful, since I
> >>>>>> think we'll end up with the following order being needed:
> >>>>>>
> >>>>>> 1) clk: Add composite clock type
> >>>>>> -> This would usually go through the clk tree.
> >>>>>> 2) The Tegra CCF rework series
> >>>>>> -> This must go through the Tegra tree due to lots of dependencies
> >>>>>> and merge conflicts with other Tegra patches.
> >>>>>> 3) This series
> >>>>>> -> This would usually go through the clk tree.
> >>>>>>
> >>>>>> Is it possible to re-order the dependencies as (1) (3) (2), so that Mike
> >>>>>> can apply (1) and (3) to the clock tree, then I can use the clk tree as
> >>>>>> the basis for a branch in the Tegra tree to apply (2) and all the other
> >>>>>> Tegra patches that will conflict with (2)?
> >>>>> If Mike approves the concept and implementation in (1) and (3) then I
> >>>>> will repost (2) and (3) with dependencies re-ordered.
> >>>> Patch (1) still has some unaddressed comments, and is not a real
> >>>> dependency for this series.
> >>> I assume "Patch (1)" refers to the list of series a couple emails above,
> >>> not the first patch in the series you're replying to; that threw me for
> >>> a moment.
> >>>
> >>>> Since all of the patches have received their
> >>>> Tested-by's then I propose to merge all patches from this series into
> >>>> clk-next, which exception of patch 2/7 (the Tegra patch).
> >>>>
> >>>> This reduces your Tegra CCF conversion dependencies and you can role the
> >>>> necessary of_clk_init change into your Tegra CCF conversion branch (it
> >>>> has my implicit Ack and can be taken through your tree).
> >>>>
> >>>> Let me know if this is OK for you.
> >>> OK, I'm happy to merge your clock tree into the Tegra tree and then
> >>> apply 2/7 on top of the Tegra CCF work.
> >> Hmm, maybe the clk tree needs to be a dependency branch of arm-soc
> >> again, as it has in the past. Would that help with any Tegra merge
> >> pain?
> > Yes, I think that's what would end up happening if I merge the clk tree
> > into the Tegra tree anyway.
>
> Hi Mike,
>
> Have you merged these patches for 3.9?
Yes, these have been sitting in clk-next for a few days now.
Regards,
Mike
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-01 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201205600.GA31762@arwen.pp.htv.fi>
Hello.
On 02-02-2013 0:56, Felipe Balbi wrote:
>>> good point, do you wanna send some patches ?
>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>> patch. :-(
> sticking into arch/arm/common/ wasn't a nice move.
Like with EDMA we have nothing else to do with CPPI 4.1 being shared by
DaVinci-like and OMAP-like SOCs. Thank TI for creatring this mess. And
actually even that is not a good place since I think I know of a MIPS SoC
having CPPI 4.1 as well, just out of tree.
> But then again, so
> wasn't asking for the patch to be removed :-s
Unfortunately, Russell has done it -- all that was discuseed without me in
the loop even. :-/
>>> I guess to make the MUSB side simpler we would need musb-dma-engine glue
>>> to map dmaengine to the private MUSB API. Then we would have some
>>> starting point to also move inventra (and anybody else) to dmaengine
>>> API.
>> Why? Inventra is a dedicated device's private DMA controller, why make
>> universal DMA driver for it?
> because it doesn't make sense to support multiple DMA APIs. We can check
> from MUSB's registers if it was configured with Inventra DMA support and
> based on that we can register MUSB's own DMA Engine to dmaengine API.
I still disagree. IMO drivers/dma/ is for standalone DMA engines. Else we
could stick every bus mastering device's DMA engines there. CPPI 4.1 is in
design standlone DMA engine, despite all in-tree implementations having it as
subblock of MUSB and serving only MUSB.
WBR, Sergei
^ permalink raw reply
* [rtc-linux] [PATCH] rtc: pl031: fix the missing operation on enable
From: Andrew Morton @ 2013-02-01 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6h2NS6dGYBvbwQ2u4FvQZ_uW8wUcT+cSA14xRzUyDfLwyQCg@mail.gmail.com>
On Fri, 1 Feb 2013 09:32:59 +0800
Haojian Zhuang <haojian.zhuang@linaro.org> wrote:
> Without this
> patch, I really
> failed to enable RTC in Hisilicon Hi3620 SoC. It results that the
> register mapping section
> in RTC is always read as zero. So I doubt that ST guys may already
> enable this register
> in bootloader. So they won't meet this issue.
OK, thanks, that sounds pretty serious so I tagged the patch for
backporting into -stable kernels as well.
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-02 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201185959.GQ2244@beef>
Hello.
On 01-02-2013 22:59, Matt Porter wrote:
>>>>> Move mach-davinci/dma.c to common/edma.c so it can be used
>>>>> by OMAP (specifically AM33xx) as well.
>>>> I think this should rather go to drivers/dma/?
>>> No, this is the private EDMA API. It's the analogous thing to
>>> the private OMAP dma API that is in plat-omap/dma.c. The actual
>>> dmaengine driver is in drivers/dma/edma.c as a wrapper around
>>> this...same way OMAP DMA engine conversion is being done.
>> Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
>> that, instead of waiting indefinitely for TI to convert it to drivers/dma/
>> directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh.
> That is a shame. Yeah, I've pointed out that I was doing this exactly
> the same way as was acceptable for the OMAP DMA conversion since it was
> in RFC. The reasons are sound since in both cases, we have many drivers
> to convert that need to continue using the private DMA APIs.
In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other
in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is
sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't
know them well).
> -Matt
WBR, Sergei
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-02 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201213003.GW2637@n2100.arm.linux.org.uk>
Hello.
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>> good point, do you wanna send some patches ?
>>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>>> patch. :-(
>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
>> wasn't asking for the patch to be removed :-s
> Err, patches don't get removed, they get moved to 'discarded'.
Any chance to bring it back to life? :-)
Although... drivers/usb/musb/cppi41.c would need to be somewhat reworked
for at least AM35x and I don't have time. But that may change, of course.
>>>> I guess to make the MUSB side simpler we would need musb-dma-engine glue
>>>> to map dmaengine to the private MUSB API. Then we would have some
>>>> starting point to also move inventra (and anybody else) to dmaengine
>>>> API.
>>> Why? Inventra is a dedicated device's private DMA controller, why make
>>> universal DMA driver for it?
>> because it doesn't make sense to support multiple DMA APIs. We can check
>> from MUSB's registers if it was configured with Inventra DMA support and
>> based on that we can register MUSB's own DMA Engine to dmaengine API.
> Hang on. This is one of the DMA implementations which is closely
> coupled with the USB and only the USB? If it is...
> I thought this had been discussed _extensively_ before. I thought the
> resolution on it was:
> 1. It would not use the DMA engine API.
> 2. It would not live in arch/arm.
> 3. It would be placed nearby the USB driver it's associated with.
> (1) because we don't use APIs just for the hell of it - think. Do we
> use the DMA engine API for PCI bus mastering ethernet controllers? No.
> Do we use it for PCI bus mastering SCSI controllers? No. Because the
> DMA is integral to the rest of the device.
> The DMA engine API only makes sense if the DMA engine is a shared
> system resource.
Thanks for such extensive wording in the support of my point. :-)
WBR, Sergei
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-02 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201213003.GW2637@n2100.arm.linux.org.uk>
Hello.
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>> good point, do you wanna send some patches ?
>>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>>> patch. :-(
>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
>> wasn't asking for the patch to be removed :-s
> Err, patches don't get removed, they get moved to 'discarded'.
>>>> I guess to make the MUSB side simpler we would need musb-dma-engine glue
>>>> to map dmaengine to the private MUSB API. Then we would have some
>>>> starting point to also move inventra (and anybody else) to dmaengine
>>>> API.
>>> Why? Inventra is a dedicated device's private DMA controller, why make
>>> universal DMA driver for it?
>> because it doesn't make sense to support multiple DMA APIs. We can check
>> from MUSB's registers if it was configured with Inventra DMA support and
>> based on that we can register MUSB's own DMA Engine to dmaengine API.
> Hang on. This is one of the DMA implementations which is closely
> coupled with the USB and only the USB? If it is...
> I thought this had been discussed _extensively_ before. I thought the
> resolution on it was:
> 1. It would not use the DMA engine API.
> 2. It would not live in arch/arm.
> 3. It would be placed nearby the USB driver it's associated with.
Note that all this doesn't apply to CPPI 4.1 controller (as contrasted to
CPPI 3.0 support in MUSB aand EMAC drivers) -- it's shared by design. Just the
implementations that are in tree have it as MUSB's sub-block, serving only MUSB.
WBR, Sergei
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Russell King - ARM Linux @ 2013-02-02 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510C58DF.3010103@mvista.com>
On Sat, Feb 02, 2013 at 04:07:59AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 1:30, Russell King - ARM Linux wrote:
>
>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>> good point, do you wanna send some patches ?
>
>>>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>>>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>>>> patch. :-(
>
>>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
>>> wasn't asking for the patch to be removed :-s
>
>> Err, patches don't get removed, they get moved to 'discarded'.
>
> Any chance to bring it back to life? :-)
> Although... drivers/usb/musb/cppi41.c would need to be somewhat
> reworked for at least AM35x and I don't have time. But that may change,
> of course.
Right, I've just looked back at the various meeting minutes from December
2010 when the CPPI stuff was discussed. Yes, I archive these things and
all email discussions for referencing in cases like this.
Unfortunately, they do not contain any useful information other than the
topic having been brought up. At that point, the CPPI stuff was in
mach-davinci, and I had suggested moving it into drivers/dma.
The result of that was to say that it doesn't fit the DMA engine APIs.
So someone came up with the idea of putting it in arch/arm/common - which
I frankly ignored by email (how long have we been saying "no drivers in
arch/arm" ?)
Now, it would've been discussed in that meeting, but unfortunately no
record exists of that. What does follow that meeting is a discussion
trail. From what I can see there, but it looks to me like the decision
was taken to move it to the DMA engine API, and work on sorting out MUSB
was going to commence.
The last email in that says "I'll get to that soon"... and that is also
the final email I have on this topic. I guess if nothing has happened...
Shrug, that's someone elses problem.
Anyway, the answer for putting it in arch/arm/common hasn't changed,
and really, where we are now, post Linus having a moan about the size
of arch/arm, that answer is even more concrete in the negative. It's
54K of code which should not be under arch/arm at all.
Anyway, if you need to look at the patch, it's 6305/1. Typing into the
summary search box 'cppi' found it in one go.
^ permalink raw reply
* [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
From: Jon Hunter @ 2013-02-02 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201215154.GV22517@atomide.com>
On 02/01/2013 03:51 PM, Tony Lindgren wrote:
> Hi Jon,
>
> * Jon Hunter <jon-hunter@ti.com> [130201 08:42]:
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -32,6 +32,7 @@
>>
>> #include "soc.h"
>> #include "common.h"
>> +#include "control.h"
>> #include "omap_device.h"
>> #include "gpmc.h"
>>
>> @@ -778,18 +779,26 @@ static void gpmc_mem_exit(void)
>> static int gpmc_mem_init(void)
>> {
>> int cs, rc;
>> - unsigned long boot_rom_space = 0;
>>
>> - /* never allocate the first page, to facilitate bug detection;
>> - * even if we didn't boot from ROM.
>> + /*
>> + * The first 1MB of GPMC address space is mapped to the
>> + * internal ROM. OMAP2 devices are an exception to this
>> + * where the first 1MB may be mapped to the GPMC.
>> */
>> - boot_rom_space = BOOT_ROM_SPACE;
>> - /* In apollon the CS0 is mapped as 0x0000 0000 */
>> - if (machine_is_omap_apollon())
>> - boot_rom_space = 0;
>
> This part is going away anyways with the patch dropping apollon
> board support from Kyungin.
Yes just saw that today.
>> - gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
>> + gpmc_mem_root.start = GPMC_MEM_START + BOOT_ROM_SPACE;
>> gpmc_mem_root.end = GPMC_MEM_END;
>>
>> + /*
>> + * OMAP2 devices that boot from external memory devices, will
>> + * map CS0 to the start of the GPMC address space (0x0). We can
>> + * test this by checking if SYS_BOOT3 pin is set. If not set
>> + * then CS0 is mapped to 0x0.
>> + */
>> + if (cpu_is_omap24xx())
>> + if (!(omap_ctrl_readl(OMAP24XX_CONTROL_STATUS) &
>> + OMAP2_SYSBOOT_3_MASK))
>> + gpmc_mem_root.start = GPMC_MEM_START;
>> +
>> /* Reserve all regions that has been set up by bootloader */
>> for (cs = 0; cs < GPMC_CS_NUM; cs++) {
>> u32 base, size;
>
> How about let's fix this properly to start with so we don't add
> more blockers moving this code to drivers/bus?
>
> Looks like gpmc_mem_init() gets called from gpmc_probe() so
> we can pass that information in pdev.
I wondered if you would suggest that ;-)
I definitely can and it is probably best. Things like this become
painful when we move to device-tree. We really need a generic way for
passing stuff like this to drivers for omap. Our options are auxdata or
bus notifiers. I am wondering whether we can plug pdata in the
omap_device bus notifier for device-tree. Let me know if you have any
thoughts.
Cheers
Jon
^ permalink raw reply
* [PATCH 1/2] ahci: sata: add support for exynos5440 sata
From: girishks2000 at gmail.com @ 2013-02-02 1:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Girish K S <ks.giri@samsung.com>
This patch adds the compatible string of the exynos5440 sata controller
compliant with the ahci 1.3 and sata 3.0 specification.
Signed-off-by: Girish K S <ks.giri@samsung.com>
---
drivers/ata/ahci_platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 7a8a284..c06f021 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend, ahci_resume);
static const struct of_device_id ahci_of_match[] = {
{ .compatible = "snps,spear-ahci", },
+ { .compatible = "samsung,exynos5440-ahci", },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] arm: exynos5440: add dts node for the ahci sata
From: girishks2000 at gmail.com @ 2013-02-02 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359770185-31867-1-git-send-email-yes>
From: Girish K S <ks.giri@samsung.com>
This patch adds dts support for the sata controller
Signed-off-by: Girish K S <ks.giri@samsung.com>
---
arch/arm/boot/dts/exynos5440.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index a00ed6a..8d6a784 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -193,4 +193,13 @@
clocks = <&clock 8>;
clock-names = "rtc";
};
+
+ sata at 210000 {
+ compatible = "samsung,exynos5440-ahci";
+ reg = <0x210000 0x10000>;
+ interrupts = <0 30 0>;
+ clocks = <&clock 10>;
+ clock-names = "sata";
+ };
+
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-02 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130202004455.GX2637@n2100.arm.linux.org.uk>
Hello.
On 02-02-2013 4:44, Russell King - ARM Linux wrote:
>>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>>> good point, do you wanna send some patches ?
>>>>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>>>>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>>>>> patch. :-(
>>>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
>>>> wasn't asking for the patch to be removed :-s
>>> Err, patches don't get removed, they get moved to 'discarded'.
>> Any chance to bring it back to life? :-)
>> Although... drivers/usb/musb/cppi41.c would need to be somewhat
>> reworked for at least AM35x and I don't have time. But that may change,
>> of course.
> Right, I've just looked back at the various meeting minutes from December
> 2010 when the CPPI stuff was discussed. Yes, I archive these things and
> all email discussions for referencing in cases like this.
Thanks.
> Unfortunately, they do not contain any useful information other than the
> topic having been brought up. At that point, the CPPI stuff was in
> mach-davinci, and I had suggested moving it into drivers/dma.
I don't remember that, probably was out of the loop again.
> The result of that was to say that it doesn't fit the DMA engine APIs.
I remember this as a discussion happening post me sending the patch to the
patch system and it being discarded...
> So someone came up with the idea of putting it in arch/arm/common - which
Probably was me. There was also idea of putting it into drivers/usb/musb/
-- which TI indeed followed in its Arago prject. I firmly denied that suggestion.
> I frankly ignored by email (how long have we been saying "no drivers in
> arch/arm" ?)
But there *are* drivers there! And look at edma.c which is about to be
moved there... Anyway, I haven't seen such warnings, probably was too late in
the game.
> Now, it would've been discussed in that meeting, but unfortunately no
> record exists of that. What does follow that meeting is a discussion
> trail. From what I can see there, but it looks to me like the decision
> was taken to move it to the DMA engine API, and work on sorting out MUSB
> was going to commence.
> The last email in that says "I'll get to that soon"... and that is also
> the final email I have on this topic. I guess if nothing has happened...
> Shrug, that's someone elses problem.
Well, as usual... :-(
> Anyway, the answer for putting it in arch/arm/common hasn't changed,
> and really, where we are now, post Linus having a moan about the size
> of arch/arm, that answer is even more concrete in the negative. It's
> 54K of code which should not be under arch/arm at all.
> Anyway, if you need to look at the patch, it's 6305/1. Typing into the
> summary search box 'cppi' found it in one go.
Thanks, I remember this variant was under arch/arm/common/.
Now however, I see what happened to that variant in somewhat different
light. Looks like it was entirely your decision to discard the patch, without
TI's request...
WBR, Sergei
^ permalink raw reply
* [PATCH] ARM:omap2: using strlcpy instead of strncpy
From: Chen Gang @ 2013-02-02 2:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201224546.GG22517@atomide.com>
? 2013?02?02? 06:45, Tony Lindgren ??:
> Added Peter to cc on this one too, it's best that he queues
> all the twl changes.
is it suitable to sync the MAINTAINER file for it ?
if suitable, can you help to change it ?
thanks.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.
From: Padma Venkat @ 2013-02-02 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201302011523.25771.arnd@arndb.de>
Hi Arnd,
On Fri, Feb 1, 2013 at 8:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 01 February 2013, Padmavathi Venna wrote:
>> This patch modify the filter function to filter the required channel
>> based on new filter params.
>>
>> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
>
> The result of this looks good, but I fear that changing the filter function
> like this wil break all drivers that currently use the plat-samsung/dma-ops.c
> code. For migration purposes, I think the best way is to change
> samsung_dmadev_request() to match the new filter_param format.
>
> After that is done, you can migrate all the drivers using samsung_dma_get_ops
> over to the new dma_request_slave_channel interface without breaking
> anything when only part of the series is applied.
>
> Arnd
Please check the below link where I made the dma request compatible to
both DT and non-DT
http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065
http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=b5be04d35dbb2e00ab27a97bfd26e17019e857ef
Please let me know if any changes required.
Thanks for the suggestions.
Padma
^ 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