* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
From: Arnd Bergmann @ 2013-01-21 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121185716.GA26754@kroah.com>
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
>
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
>
Ok, great! Thanks a lot, both of you,
Arnd
^ permalink raw reply
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
From: Arnd Bergmann @ 2013-01-21 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121190302.GN22517@atomide.com>
On Monday 21 January 2013, Tony Lindgren wrote:
> >
> > arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
> > arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'
>
> This should be already fixed by 72533b (arm: mvebu: Fix compile for
> multiplatform when ARMv6 is selected) in arm-soc fixes branch.
>
Ok, silly me, I forgot to check my own tree :)
Thanks for looking into it!
Arnd
^ permalink raw reply
* [PATCH v7 09/15] gpio: pl061: set initcall level to module init
From: Dinh Nguyen @ 2013-01-21 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358785488.6590.33.camel@hornet>
Hi Linus,
On Mon, 2013-01-21 at 16:24 +0000, Pawel Moll wrote:
> On Mon, 2013-01-21 at 14:41 +0000, Linus Walleij wrote:
> > On Fri, Jan 18, 2013 at 8:31 AM, Haojian Zhuang
> > <haojian.zhuang@linaro.org> wrote:
> >
> > > Replace subsys initcall by module initcall level. Since pinctrl
> > > driver is already launched before gpio driver. It's unnecessary
> > > to set gpio driver in subsys init call level.
> > >
> > > Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> >
> > On you platform maybe it works, but have you made sure that nobody
> > else will be affected?
> >
> > SPEAr of course, then these:
> >
> > arch/arm/mach-realview/core.c: * GPIO on PL061 is active,
> > which is the proper
> > arch/arm/mach-socfpga/Kconfig: select GPIO_PL061 if GPIOLIB
> >
> > Pawel, Dinh: are you OK with this change?
Still works ok on mach-socfpga.
Dinh
>
> Hm. Doesn't this make the MMCI probing depending on the module_init
> order? As in: wouldn't it make the mmci probe completely fail (not even
> defer it) if it was called before the pl061? In that case even your,
> Linus, hack with inverting the CD status wouldn't work...
>
> Pawel
>
>
>
>
^ permalink raw reply
* [PATCH 1/8] mmc: mmci: Move ios_handler functionality into the driver
From: Ulf Hansson @ 2013-01-21 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121140626.GB6857@gmail.com>
On 21 January 2013 15:06, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 13 Dec 2012, Lee Jones wrote:
>
>> There are currently two instances of the ios_handler being used.
>> Both of which mearly toy with some regulator settings. Now there
>> is a GPIO regulator API, we can use that instead, and lessen the
>> per platform burden. By doing this, we also become more Device
>> Tree compatible.
>>
>> Cc: Chris Ball <cjb@laptop.org>
>> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
>> Acked-by: Ulf Hansson <ulf.hansson@stericsson.com>
>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Any more news on this one?
Not exactly this version of the patch, but another one has has been
merged through Russell's patch tracker. Available for 3.9.
>
>> drivers/mmc/host/mmci.c | 22 ++++++++++++++++++++++
>> drivers/mmc/host/mmci.h | 1 +
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index edc3e9b..d45c931 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -1091,6 +1091,16 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>> case MMC_POWER_OFF:
>> if (host->vcc)
>> ret = mmc_regulator_set_ocr(mmc, host->vcc, 0);
>> +
>> + if (host->vqmmc) {
>> + if (regulator_is_enabled(host->vqmmc)) {
>> + ret = regulator_disable(host->vqmmc);
>> + if (ret < 0)
>> + dev_warn(mmc_dev(mmc),
>> + "unable to disable vmmc-ios\n");
>> + }
>> + }
>> +
>> break;
>> case MMC_POWER_UP:
>> if (host->vcc) {
>> @@ -1115,6 +1125,14 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>
>> break;
>> case MMC_POWER_ON:
>> + if (host->vqmmc)
>> + if (!regulator_is_enabled(host->vqmmc)) {
>> + ret = regulator_enable(host->vqmmc);
>> + if (ret < 0)
>> + dev_warn(mmc_dev(mmc),
>> + "unable to enable vmmc-ios\n");
>> + }
>> +
>> pwr |= MCI_PWR_ON;
>> break;
>> }
>> @@ -1379,6 +1397,10 @@ static int __devinit mmci_probe(struct amba_device *dev,
>> "(using regulator instead)\n");
>> }
>> }
>> +
>> + host->vqmmc = regulator_get(&dev->dev, "vqmmc");
>> + if (IS_ERR(host->vqmmc))
>> + host->vqmmc = NULL;
>> #endif
>> /* Fall back to platform data if no regulator is found */
>> if (host->vcc == NULL)
>> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
>> index d437ccf..b87d9e2 100644
>> --- a/drivers/mmc/host/mmci.h
>> +++ b/drivers/mmc/host/mmci.h
>> @@ -194,6 +194,7 @@ struct mmci_host {
>> struct sg_mapping_iter sg_miter;
>> unsigned int size;
>> struct regulator *vcc;
>> + struct regulator *vqmmc;
>>
>> #ifdef CONFIG_DMA_ENGINE
>> /* DMA stuff */
>
> --
> 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 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Alan Stern @ 2013-01-21 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301212014.20678.arnd@arndb.de>
On Mon, 21 Jan 2013, Arnd Bergmann wrote:
> On Monday 21 January 2013, Felipe Balbi wrote:
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > Manjunath Goudar is already working on a patch to convert
> > > both the imx and the mvebu glue drivers (along with all
> > > the other ARM specific ones) to the new probing method,
> > > but that will be too late to fix v3.8. This patch instead
> > > adds yet another hack like the existing ones to allow
> > > the ehci driver to load both back-ends.
> >
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
>
> As I explained above, Manjunath already has a patch [1] for that, but I
> think it's too late to include that in v3.8 given the regression
> potential and size of the patch. Once he submits that patch for 3.9,
> my change would get taken out anyway, but it lets us build important
> configurations (including allyesconfig build tests) on 3.8.
>
> Arnd
>
> [1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae
Is Manjunath aware of the first patch attached to this email message?
http://marc.info/?l=linux-usb&m=135843902916416&w=2
Alan Stern
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Peter Korsgaard @ 2013-01-21 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121171022.GC10020@beef>
>>>>> "Matt" == Matt Porter <mporter@ti.com> writes:
Matt> On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote:
>> Does anyone know when the BeagleBone support is going to be fixed in
>> mainline ?
Matt> Hi Mark,
Matt> I'm not sure what needs to be fixed. The only thing my edma dmaengine
Matt> series adds is new features (specifically, mmc and spi dma support).
Matt> I would suspect some boot problem specific to Paul's configuration
Matt> if it's hanging. I just booted current mainline with an
Matt> omap2plus_defconfig build on my bone a5 and it came up fine.
It also works here. I have noticed issues with nfs boot and recent
mainline when powered from the USB cable though. I suspect we're getting
close to the power limit.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
From: Michał Mirosław @ 2013-01-21 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358798722-25102-1-git-send-email-marex@denx.de>
2013/1/21 Marek Vasut <marex@denx.de>:
> This patch adds support for i.MX23 into the LRADC driver. The LRADC
> block on MX23 is not much different from the one on MX28, thus this
> is only a few changes fixing the parts that are specific to MX23.
[...]
> +struct mxs_lradc_of_config {
> + const int irq_count;
> + const char * const *irq_name;
> +};
> +
> +static const struct mxs_lradc_of_config const mxs_lradc_of_config[] = {
> + [IMX23_LRADC] = {
> + .irq_count = ARRAY_SIZE(mx23_lradc_irq_names),
> + .irq_name = mx23_lradc_irq_names,
> + },
> + [IMX28_LRADC] = {
> + .irq_count = ARRAY_SIZE(mx28_lradc_irq_names),
> + .irq_name = mx28_lradc_irq_names,
> + },
> +};
> +
> enum mxs_lradc_ts {
> MXS_LRADC_TOUCHSCREEN_NONE = 0,
> MXS_LRADC_TOUCHSCREEN_4WIRE,
> @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc *lradc)
> writel(0, lradc->base + LRADC_DELAY(i));
> }
>
> +static const struct of_device_id mxs_lradc_dt_ids[] = {
> + { .compatible = "fsl,imx23-lradc", .data = (void *)IMX23_LRADC, },
> + { .compatible = "fsl,imx28-lradc", .data = (void *)IMX28_LRADC, },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
> +
Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
Best Regards,
Micha? Miros?aw
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Peter Korsgaard @ 2013-01-21 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121182419.GE10020@beef>
>>>>> "Matt" == Matt Porter <mporter@ti.com> writes:
Matt> On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote:
>> On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote:
>> > for MMC filesystem - we need the edma series. for a ramdisk, I am able
>> > to boot up to shell with 3.8-rc4 tag
>>
>> Yep, I also could boot 3.8-rc3 using ramfs, no problem.
Matt> Do you use appended dtb? The only different that jumped out at me first
Matt> Paul's reported hang is he uses appended dtb and I boot my boards with a
Matt> single uImage and multiple dtbs the traditional DT way.
It works for me with appended dtb as well.
--
Bye, Peter Korsgaard
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Arnd Bergmann @ 2013-01-21 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1bkiowcO7OPSfPmaB6eRj_3FNr+4ONnaQHEZkpxB2XfduQ@mail.gmail.com>
On Monday 21 January 2013, Matt Sealey wrote:
>
> ARM seems to be the only "major" platform not using the
> kernel/Kconfig.hz definitions, instead rolling it's own and setting
> what could be described as both reasonable and unreasonable defaults
> for platforms. If we're going wholesale for multiplatform on ARM then
> having CONFIG_HZ be selected dependent on platform options seems
> rather curious since building a kernel for Exynos, OMAP or so will
> force the default to a value which is not truly desired by the
> maintainers.
Agreed 100%.
(adding John Stultz to Cc, he's the local time expert)
> config HZ
> int
> default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
> ARCH_S5PV210 || ARCH_EXYNOS4
> default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
> default AT91_TIMER_HZ if ARCH_AT91
> default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
> default 100
>
> There is a patch floating around ("ARM: OMAP2+: timer: remove
> CONFIG_OMAP_32K_TIMER")
> which modifies the OMAP line, so I'll ignore that for my below
> example, and I saw a patch for adding Exynos5 processors to the top
> default somewhere around here.
>
> So, based on those getting in, in my case here, I can see a situation where;
>
> * I build multiplatform for i.MX6 and Exynos4/5 ARCH_MULTIPLATFORM, I
> will get CONFIG_HZ=200.
>
> * If I built for just i.MX6, I will get CONFIG_HZ=100.
>
> Either way, if I boot a kernel on i.MX6, CONFIG_HZ depends on the
> other ARM platforms I also want to boot on it.. this is not exactly
> multiplatform compliant, right?
Right. It's pretty clear that the above logic does not work
with multiplatform. Maybe we should just make ARCH_MULTIPLATFORM
select NO_HZ to make the question much less interesting.
Regarding the defaults, I would suggest putting them into all the
defaults into the defconfig files and removing the other hardcoding
otherwise. Ben Dooks and Russell are probably the best to know
what triggered the 200 HZ for s3c24xx and for ebsa110. My guess
is that the other samsung ones are the result of cargo cult
programming.
at91 and omap set the HZ value to something that is derived
from their hardware timer, but we have also forever had logic
to calculate the exact time when that does not match. This code
has very recently been moved into the new register_refined_jiffies()
function. John can probably tell is if this solves all the problems
for these platforms.
> Additionally, using kernel/Kconfig.hz is a predicate for enabling
> (forced enabling, even) CONFIG_SCHED_HRTICK which is defined nowhere
> else. I don't know how many ARM systems here benefit from this, if
> there is a benefit, or what this really means.. if you really have a
> high resolution timer (and hrtimers enabled) that would assist the
> scheduler this way, is it supposed to make a big difference to the way
> the scheduler works for the better or worse? Is this actually
> overridden by ARM sched_clock handling or so? Shouldn't there be a
> help entry or some documentation for what this option does? I have
> CC'd the scheduler maintainers because I'd really like to know what I
> am doing here before I venture into putting patches out which could
> potentially rip open spacetime and have us all sucked in..
Yes, that sounds like yet another bug.
Arnd
^ permalink raw reply
* [PATCH 3/6] arm: kconfig: don't select TWD with local timer for Armada 370/XP
From: Arnd Bergmann @ 2013-01-21 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1b=9WQNwHOz=k13XVc=MyZT1UrcaYj8muF2A5B4eJA5+MA@mail.gmail.com>
On Monday 21 January 2013, Matt Sealey wrote:
> On Mon, Jan 21, 2013 at 12:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 21 January 2013, Gregory CLEMENT wrote:
> >> @@ -1624,7 +1624,7 @@ config LOCAL_TIMERS
> >> bool "Use local timer interrupts"
> >> depends on SMP
> >> default y
> >> - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> >> + select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT && !ARMADA_370_XP_TIMER)
> >>
> >
> > Maybe it can be written as
> >
> > config LOCAL_TIMERS
> > bool "Use local timer interrupts"
> > depends on SMP
> > default y
> >
> > config HAVE_ARM_TWD
> > depends on LOCAL_TIMERS
> > default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> > default y
> >
> > This will still be slightly wrong (generating extra code) on a multiplatform
> > kernel that has no platform other than MSM or EXYNOS, but the other alternative
> > would be that each platform with TWD support has to select HAVE_ARM_TWD itself.
>
> Why would having each platform with TWD support select HAVE_ARM_TWD be
> a problem?
Not a big one, it's just one more Kconfig line for each of a large number
of platforms in the long run.
> On multiplatform kernels where at least one arch has TWD support, it
> will be included, and where not, it will not.
>
> It doesn't seem logical for a feature descriptor (HAVE_ARM_TWD) to
> rely on greater knowledge of what platforms may or may not support it.
> If we had to include every platform in that list it would be unwieldy.
I would expect that all future platforms have ARM_TWD, so the list
of the platforms that don't is not going to grow much, but the list
of platforms that do will keep growing.
> Which leads me to this; I wonder if there should be a policy document
> that basically describes what HAVE_* really is meant for, and how
> dependencies on ARCH_* (or MACH_* in the world of multiplatform)
> should be handled for architectural features? That way there's a
> little more fixed definition of how Kconfigs should be written to
> effectively support multiplatform kernels and allow people to identify
> misuses and get rid of them for multiplatform, if only just to get the
> information out of the heads of maintainers and into a file somewhere
> that we can reference... maybe it exists already but I am missing it?
Documentation is generally considered a good thing, but few people
can be bothered to write it, and few of the other people that should
read it actually do.
To some extent this problem will improve over time for the ARM
multiplatform support as we find all the bugs like this one
and fix them.
Arnd
^ permalink raw reply
* [PATCH 1/3] ARM: dts: AM33XX: Add ELM node
From: Peter Korsgaard @ 2013-01-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358491295-4022-2-git-send-email-avinashphilip@ti.com>
>>>>> "Philip" == Philip Avinash <avinashphilip@ti.com> writes:
Philip> From: "Philip, Avinash" <avinashphilip@ti.com>
Philip> Add ELM data node to AM33XX device tree file.
Philip> Signed-off-by: Philip Avinash <avinashphilip@ti.com>
Philip> ---
Philip> arch/arm/boot/dts/am33xx.dtsi | 8 ++++++++
Philip> 1 file changed, 8 insertions(+)
Philip> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
Philip> index c2f14e8..eaef5e7 100644
Philip> --- a/arch/arm/boot/dts/am33xx.dtsi
Philip> +++ b/arch/arm/boot/dts/am33xx.dtsi
Philip> @@ -385,5 +385,13 @@
Philip> mac-address = [ 00 00 00 00 00 00 ];
Philip> };
Philip> };
Philip> +
Philip> + elm: elm at 48080000 {
Philip> + compatible = "ti,am33xx-elm";
Please drop the <tab> after compatible.
Other than that it looks goood.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 06/15] clk: export __clk_get_name
From: Ulf Hansson @ 2013-01-21 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-7-git-send-email-arnd@arndb.de>
On 21 January 2013 18:15, Arnd Bergmann <arnd@arndb.de> wrote:
> The __clk_get_name is used by drivers that provide their
> own clocks, which have traditionally all been built-in.
> The new imx drm driver however provides clocks but can
> be built as a module, so we need to export __clk_get_name.
>
> While this is only a staging driver, it's likely that
> there will be others like it in the future.
>
> Without this patch, building ARM allmodconfig results in:
>
> ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
> drivers/clk/clk.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 251e45d..13b793e 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -263,6 +263,7 @@ inline const char *__clk_get_name(struct clk *clk)
> {
> return !clk ? NULL : clk->name;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_name);
>
> inline struct clk_hw *__clk_get_hw(struct clk *clk)
> {
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: John Stultz @ 2013-01-21 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301212041.17951.arnd@arndb.de>
On 01/21/2013 12:41 PM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Matt Sealey wrote:
>> config HZ
>> int
>> default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
>> ARCH_S5PV210 || ARCH_EXYNOS4
>> default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
>> default AT91_TIMER_HZ if ARCH_AT91
>> default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
>> default 100
>>
>> There is a patch floating around ("ARM: OMAP2+: timer: remove
>> CONFIG_OMAP_32K_TIMER")
>> which modifies the OMAP line, so I'll ignore that for my below
>> example, and I saw a patch for adding Exynos5 processors to the top
>> default somewhere around here.
>>
>> So, based on those getting in, in my case here, I can see a situation where;
>>
>> * I build multiplatform for i.MX6 and Exynos4/5 ARCH_MULTIPLATFORM, I
>> will get CONFIG_HZ=200.
>>
>> * If I built for just i.MX6, I will get CONFIG_HZ=100.
>>
>> Either way, if I boot a kernel on i.MX6, CONFIG_HZ depends on the
>> other ARM platforms I also want to boot on it.. this is not exactly
>> multiplatform compliant, right?
> Right. It's pretty clear that the above logic does not work
> with multiplatform. Maybe we should just make ARCH_MULTIPLATFORM
> select NO_HZ to make the question much less interesting.
Although, even with NO_HZ, we still have some sense of HZ.
> Regarding the defaults, I would suggest putting them into all the
> defaults into the defconfig files and removing the other hardcoding
> otherwise. Ben Dooks and Russell are probably the best to know
> what triggered the 200 HZ for s3c24xx and for ebsa110. My guess
> is that the other samsung ones are the result of cargo cult
> programming.
>
> at91 and omap set the HZ value to something that is derived
> from their hardware timer, but we have also forever had logic
> to calculate the exact time when that does not match. This code
> has very recently been moved into the new register_refined_jiffies()
> function. John can probably tell is if this solves all the problems
> for these platforms.
Yea, as far as timekeeping is concerned, we shouldn't be HZ dependent
(and the register_refined_jiffies is really only necessary if you're not
expecting a proper clocksource to eventually be registered), assuming
the hardware can do something close to the HZ value requested.
So I'd probably want to hear about what history caused the specific 200
HZ selections, as I suspect there's actual hardware limitations there.
So if you can not get actual timer ticks any faster then 200 HZ on that
hardware, setting HZ higher could cause some jiffies related timer
trouble (ie: if the kernel thinks HZ is 1000 but the hardware can only
do 200, that's a different problem then if the hardware actually can
only do 999.8 HZ). So things like timer-wheel timeouts may not happen
when they should.
I suspect the best approach for multi-arch in those cases may be to
select HZ=100 and use HRT to allow more modern systems to have
finer-grained timers.
thanks
-john
^ permalink raw reply
* [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
From: Marek Vasut @ 2013-01-21 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHXqBFLQUY6g6p988MVkk=sRu44B5tEzDMH2UbU2n2UDda0Q-A@mail.gmail.com>
Dear Micha? Miros?aw,
> 2013/1/21 Marek Vasut <marex@denx.de>:
> > This patch adds support for i.MX23 into the LRADC driver. The LRADC
> > block on MX23 is not much different from the one on MX28, thus this
> > is only a few changes fixing the parts that are specific to MX23.
>
> [...]
>
> > +struct mxs_lradc_of_config {
> > + const int irq_count;
> > + const char * const *irq_name;
> > +};
> > +
> > +static const struct mxs_lradc_of_config const mxs_lradc_of_config[] = {
> > + [IMX23_LRADC] = {
> > + .irq_count = ARRAY_SIZE(mx23_lradc_irq_names),
> > + .irq_name = mx23_lradc_irq_names,
> > + },
> > + [IMX28_LRADC] = {
> > + .irq_count = ARRAY_SIZE(mx28_lradc_irq_names),
> > + .irq_name = mx28_lradc_irq_names,
> > + },
> > +};
> > +
> >
> > enum mxs_lradc_ts {
> >
> > MXS_LRADC_TOUCHSCREEN_NONE = 0,
> > MXS_LRADC_TOUCHSCREEN_4WIRE,
> >
> > @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc
> > *lradc)
> >
> > writel(0, lradc->base + LRADC_DELAY(i));
> >
> > }
> >
> > +static const struct of_device_id mxs_lradc_dt_ids[] = {
> > + { .compatible = "fsl,imx23-lradc", .data = (void *)IMX23_LRADC,
> > }, + { .compatible = "fsl,imx28-lradc", .data = (void
> > *)IMX28_LRADC, }, + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
> > +
>
> Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
Check the register layout, it differs between MX23 and MX28, that's one reason,
since were we to access differently placed registers, we can do it easily as in
the SSP/I2C drivers.
Moreover, there are some features on the MX28 that are not on the MX23 (like
voltage treshold triggers and touchbuttons), with this setup, we can easily
check what we're running at at runtime and determine to disallow these.
>From my point of view, using the number (IMX23_LRADC / IMX28_LRADC) is much more
convenient in the long run.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Greg KH @ 2013-01-21 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301211855.25455.arnd@arndb.de>
On Mon, Jan 21, 2013 at 06:55:25PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Soeren Moch wrote:
> > On 01/19/13 21:05, Arnd Bergmann wrote:
> > > from the distribution of the numbers, it seems that there is exactly 1 MB
> > > of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
> > > in individual pages. This matches the size of your pool, so it's definitely
> > > something coming from USB, and no single other allocation, but it does not
> > > directly point to a specific line of code.
> > Very interesting, so this is no fragmentation problem nor something
> > caused by sata or ethernet.
>
> Right.
>
> > > One thing I found was that the ARM dma-mapping code seems buggy in the way
> > > that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
> > > not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.
> > >
> > > I believe we need the patch below, but it is not clear to me if that issue
> > > is related to your problem or now.
> > Out of curiosity I checked include/linux/gfp.h. GFP_ATOMIC is defined as
> > __GFP_HIGH (which means 'use emergency pool', and no wait), so this
> > patch should not make any difference for "normal" (GPF_ATOMIC /
> > GFP_KERNEL) allocations, only for gfp_flags accidentally set to zero.
>
> Yes, or one of the rare cases where someone intentionally does something like
> (GFP_ATOMIC & !__GFP_HIGH) or (GFP_KERNEL || __GFP_HIGH), which are both
> wrong.
>
> > So, can a new test with this patch help to debug the pool exhaustion?
>
> Yes, but I would not expect this to change much. It's a bug, but not likely
> the one you are hitting.
>
> > > So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
> > > causes the low-level allocation to be GFP_ATOMIC, because
> > > qh_append_tds() is called under a spinlock. If we have hundreds
> > > of URBs in flight, that will exhaust the pool rather quickly.
> > >
> > Maybe there are hundreds of URBs in flight in my application, I have no
> > idea how to check this.
>
> I don't know a lot about USB, but I always assumed that this was not
> a normal condition and that there are only a couple of URBs per endpoint
> used at a time. Maybe Greg or someone else with a USB background can
> shed some light on this.
There's no restriction on how many URBs a driver can have outstanding at
once, and if you have a system with a lot of USB devices running at the
same time, there could be lots of URBs in flight depending on the number
of host controllers and devices and drivers being used.
Sorry,
greg k-h
^ permalink raw reply
* [PATCH 2/3] ARM: dts: AM33XX: Add GPMC node
From: Peter Korsgaard @ 2013-01-21 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358491295-4022-3-git-send-email-avinashphilip@ti.com>
>>>>> "Philip" == Philip Avinash <avinashphilip@ti.com> writes:
Philip> From: "Philip, Avinash" <avinashphilip@ti.com>
Philip> Add GPMC data node to AM33XX device tree file.
Philip> Signed-off-by: Philip Avinash <avinashphilip@ti.com>
Philip> ---
Philip> arch/arm/boot/dts/am33xx.dtsi | 12 ++++++++++++
Philip> 1 file changed, 12 insertions(+)
Philip> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
Philip> index eaef5e7..f4209d8 100644
Philip> --- a/arch/arm/boot/dts/am33xx.dtsi
Philip> +++ b/arch/arm/boot/dts/am33xx.dtsi
Philip> @@ -393,5 +393,17 @@
Philip> ti,hwmods = "elm";
Philip> status = "disabled";
Philip> };
Philip> +
Philip> + gpmc: gpmc at 50000000 {
Philip> + compatible = "ti,am3352-gpmc";
Philip> + ti,hwmods = "gpmc";
Philip> + reg = <0x50000000 0x2000>;
Philip> + interrupts = <100>;
Philip> + num-cs = <8>;
Next to Jan's comment about am335x having 7 cs signals, I just realized
the difference in compatible string between the gpmc and elm. The gpmc
refers to a real device (which is afaik how it should be done), but the
elm compatible is simply ti,am33xx-elm.
Presumably it should have been ti,am3352-elm in the binding instead?
Other than that it looks fine.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Matt Sealey @ 2013-01-21 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301212041.17951.arnd@arndb.de>
On Mon, Jan 21, 2013 at 2:41 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 21 January 2013, Matt Sealey wrote:
>>
>> ARM seems to be the only "major" platform not using the
>> kernel/Kconfig.hz definitions, instead rolling it's own and setting
>> what could be described as both reasonable and unreasonable defaults
>> for platforms. If we're going wholesale for multiplatform on ARM then
>> having CONFIG_HZ be selected dependent on platform options seems
>> rather curious since building a kernel for Exynos, OMAP or so will
>> force the default to a value which is not truly desired by the
>> maintainers.
>
> Agreed 100%.
>
> (adding John Stultz to Cc, he's the local time expert)
Hi, John! Welcome to the fray :)
>> config HZ
>> int
>> default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
>> ARCH_S5PV210 || ARCH_EXYNOS4
>> default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
>> default AT91_TIMER_HZ if ARCH_AT91
>> default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
>> default 100
>>
[snip]
>> Either way, if I boot a kernel on i.MX6, CONFIG_HZ depends on the
>> other ARM platforms I also want to boot on it.. this is not exactly
>> multiplatform compliant, right?
>
> Right. It's pretty clear that the above logic does not work
> with multiplatform. Maybe we should just make ARCH_MULTIPLATFORM
> select NO_HZ to make the question much less interesting.
>
> Regarding the defaults, I would suggest putting them into all the
> defaults into the defconfig files and removing the other hardcoding
> otherwise. Ben Dooks and Russell are probably the best to know
> what triggered the 200 HZ for s3c24xx and for ebsa110. My guess
> is that the other samsung ones are the result of cargo cult
> programming.
>
> at91 and omap set the HZ value to something that is derived
> from their hardware timer, but we have also forever had logic
> to calculate the exact time when that does not match. This code
> has very recently been moved into the new register_refined_jiffies()
> function. John can probably tell is if this solves all the problems
> for these platforms.
I would be very interested. My plan would be then (providing John
responds in the affirmative) to basically submit a patch to remove the
8 lines pasted above and source kernel/Kconfig.hz instead. I'm doing
this now on a local kernel tree and I can't see any real problem with
it.
It would then be up to the above-mentioned maintainers to decide if
they are part of the cargo cult and don't need it or refine their
board files to match the New World Order of using Kconfig.hz. The
unconfigured kernel default is 100 anyway which is lower than all the
above default setting, so I would technically be causing a regression
on those platforms... do I want to be responsible for that? Probably
not, but as I said, it's not affecting (in fact, it may be
*improving*) the platforms I care about.
>> Additionally, using kernel/Kconfig.hz is a predicate for enabling
>> (forced enabling, even) CONFIG_SCHED_HRTICK which is defined nowhere
>> else. I don't know how many ARM systems here benefit from this, if
>> there is a benefit, or what this really means.. if you really have a
>> high resolution timer (and hrtimers enabled) that would assist the
>> scheduler this way, is it supposed to make a big difference to the way
>> the scheduler works for the better or worse? Is this actually
>> overridden by ARM sched_clock handling or so? Shouldn't there be a
>> help entry or some documentation for what this option does? I have
>> CC'd the scheduler maintainers because I'd really like to know what I
>> am doing here before I venture into putting patches out which could
>> potentially rip open spacetime and have us all sucked in..
>
> Yes, that sounds like yet another bug.
So is that a bug in that it is not available to ARM right now, a bug
in that it would be impossible for anyone on ARM to have ever tested
this code, or a bug in that it should NEVER be enabled for ARM for
some reason? John? Ingo? :)
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Russell King - ARM Linux @ 2013-01-21 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301212041.17951.arnd@arndb.de>
On Mon, Jan 21, 2013 at 08:41:17PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Matt Sealey wrote:
> >
> > ARM seems to be the only "major" platform not using the
> > kernel/Kconfig.hz definitions, instead rolling it's own and setting
> > what could be described as both reasonable and unreasonable defaults
> > for platforms.
No, you've got this totally wrong.
They're not defaults. And I object to your use of "unreasonable" too.
I've no idea where you get that from.
There's a reason why we have different HZ rates - some platforms just
can't do the standard 100Hz tick rate. No way - their timers can't
divide down to that interrupt rate. Sorry to spoil your ivory tower
with a few facts, but your statement is just rediculous.
The reason we don't use kernel/Kconfig.hz is precisely because of that;
we _HAVE_ to have different HZ definitions on different platforms, and
you'll notice that kernel/Kconfig.hz makes _no_ prevision for this.
Now, while things have moved forwards and we have clocksource/clockevent
support, not every platform can support this timekeeping structure;
ebsa110 certainly can't. There's one timer and one timer only which
is usable, which even needs to be manually reloaded by the CPU. No
other independent counter to act as a clock source.
As for Samsung and the rest I can't comment. The original reason OMAP
used this though was because the 32768Hz counter can't produce 100Hz
without a .1% error - too much error under pre-clocksource
implementations for timekeeping. Whether that's changed with the
clocksource/clockevent support needs to be checked.
It's entirely possible with the modern clocksource/clockevent support
that many of these platforms can have their alternative HZ tick rates
removed - but there will continue to be a subset which can't, and all
the time that we have such a subset, kernel/Kconfig.hz can't be used
without modification.
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Russell King - ARM Linux @ 2013-01-21 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FDAC5F.4040605@linaro.org>
On Mon, Jan 21, 2013 at 01:00:15PM -0800, John Stultz wrote:
> So if you can not get actual timer ticks any faster then 200 HZ on that
> hardware, setting HZ higher could cause some jiffies related timer
> trouble
Err, no John. It's the other way around - especially on some platforms
which are incapable of being converted to the clock source support.
EBSA110 has _one_ counter. It counts down at a certain rate, and when
it rolls over from 0 to FFFF, it produces an interrupt and continues
counting down from FFFF.
To produce anything close to a reasonable regular tick rate from that,
the only way to do it is - with interrupts disabled - read the current
value to find out how far the timer has rolled over, and set it so that
the next event will expire as close as possible to the desired HZ rate.
So, none of the clcokevent stuff can be used; and we rely _purely_ on
counting interrupts in jiffy based increments to provide any reference
of time.
Moreover, because the counter is only 16-bit, and it's clocked from
something around 7MHz, well, maths will tell you why 200Hz had to be
chosen rather than 100Hz.
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Matt Sealey @ 2013-01-21 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FDAC5F.4040605@linaro.org>
On Mon, Jan 21, 2013 at 3:00 PM, John Stultz <john.stultz@linaro.org> wrote:
> On 01/21/2013 12:41 PM, Arnd Bergmann wrote:
>>
>> Right. It's pretty clear that the above logic does not work
>> with multiplatform. Maybe we should just make ARCH_MULTIPLATFORM
>> select NO_HZ to make the question much less interesting.
>
> Although, even with NO_HZ, we still have some sense of HZ.
I wonder if you can confirm my understanding of this by the way? The
way I think this works is;
CONFIG_HZ on it's own defines the rate at which the kernel wakes up
from sleeping on the job, and checks for current or expired timer
events such that it can do things like schedule_work (as in
workqueues) or perform scheduler (as in processes/tasks) operations.
CONFIG_NO_HZ turns on logic which effectively only wakes up at a
*maximum* of CONFIG_HZ times per second, but otherwise will go to
sleep and stay that way if no events actually happened (so, we rely on
a timer interrupt popping up).
In this case, no matter whether CONFIG_HZ=1000 or CONFIG_HZ=250 (for
example) combined with CONFIG_NO_HZ and less than e.g. 250 things
happening per second will wake up "exactly" the same number of times?
CONFIG_HZ=1000 with CONFIG_NO_HZ would be an effective, all-round
solution here, then, and CONFIG_HZ=100 should be a reasonable default
(as it is anyway with an otherwise-unconfigured kernel on any other
platform) for !CONFIG_NO_HZ.
I have to admit, the only reason I noticed the above is because I was
reading one of CK's BFS logs and reading it makes it seem like the
above is the case, but I have no idea if he thinks BFS makes that the
case or if the current CFQ scheduler makes that the case, or if this
is simply.. the case.. (can you see this is kind of confusing to me as
this is basically not written anywhere except maybe an LWN article
from 2008 I read up on? :)
>> Regarding the defaults, I would suggest putting them into all the
>> defaults into the defconfig files and removing the other hardcoding
>> otherwise. Ben Dooks and Russell are probably the best to know
>> what triggered the 200 HZ for s3c24xx and for ebsa110. My guess
>> is that the other samsung ones are the result of cargo cult
>> programming.
>>
>> at91 and omap set the HZ value to something that is derived
>> from their hardware timer, but we have also forever had logic
>> to calculate the exact time when that does not match. This code
>> has very recently been moved into the new register_refined_jiffies()
>> function. John can probably tell is if this solves all the problems
>> for these platforms.
>
>
> Yea, as far as timekeeping is concerned, we shouldn't be HZ dependent (and
> the register_refined_jiffies is really only necessary if you're not
> expecting a proper clocksource to eventually be registered), assuming the
> hardware can do something close to the HZ value requested.
>
> So I'd probably want to hear about what history caused the specific 200 HZ
> selections, as I suspect there's actual hardware limitations there. So if
> you can not get actual timer ticks any faster then 200 HZ on that hardware,
> setting HZ higher could cause some jiffies related timer trouble (ie: if the
> kernel thinks HZ is 1000 but the hardware can only do 200, that's a
> different problem then if the hardware actually can only do 999.8 HZ). So
> things like timer-wheel timeouts may not happen when they should.
>
> I suspect the best approach for multi-arch in those cases may be to select
> HZ=100
As above, or "not select anything at all" since HZ=100 if you don't
touch anything, right?
If someone picks HZ=1000 and their platform can't support it, then
that's their own damn problem (don't touch things you don't
understand, right? ;)
> and use HRT to allow more modern systems to have finer-grained
> timers.
My question really has to be is CONFIG_SCHED_HRTICK useful, what
exactly is it going to do on ARM here since nobody can ever have
enabled it? Is it going to keel over and explode if nobody registers a
non-jiffies sched_clock (since the jiffies clock is technically
reporting itself as a ridiculously high resolution clocksource..)?
Or is this one of those things that if your platform doesn't have a
real high resolution timer, you shouldn't enable HRTIMERS and
therefore not enable SCHED_HRTICK as a result? That affects
ARCH_MULTIPLATFORM here. Is the solution as simple as
ARCH_MULTIPLATFORM compliant platforms kind of have to have a high
resolution timer? Documentation to that effect?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
From: Michał Mirosław @ 2013-01-21 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301212200.36917.marex@denx.de>
2013/1/21 Marek Vasut <marex@denx.de>:
> Dear Micha? Miros?aw,
>
>> 2013/1/21 Marek Vasut <marex@denx.de>:
>> > This patch adds support for i.MX23 into the LRADC driver. The LRADC
>> > block on MX23 is not much different from the one on MX28, thus this
>> > is only a few changes fixing the parts that are specific to MX23.
>>
>> [...]
>>
>> > +struct mxs_lradc_of_config {
>> > + const int irq_count;
>> > + const char * const *irq_name;
>> > +};
>> > +
>> > +static const struct mxs_lradc_of_config const mxs_lradc_of_config[] = {
>> > + [IMX23_LRADC] = {
>> > + .irq_count = ARRAY_SIZE(mx23_lradc_irq_names),
>> > + .irq_name = mx23_lradc_irq_names,
>> > + },
>> > + [IMX28_LRADC] = {
>> > + .irq_count = ARRAY_SIZE(mx28_lradc_irq_names),
>> > + .irq_name = mx28_lradc_irq_names,
>> > + },
>> > +};
>> > +
>> >
>> > enum mxs_lradc_ts {
>> >
>> > MXS_LRADC_TOUCHSCREEN_NONE = 0,
>> > MXS_LRADC_TOUCHSCREEN_4WIRE,
>> >
>> > @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc
>> > *lradc)
>> >
>> > writel(0, lradc->base + LRADC_DELAY(i));
>> >
>> > }
>> >
>> > +static const struct of_device_id mxs_lradc_dt_ids[] = {
>> > + { .compatible = "fsl,imx23-lradc", .data = (void *)IMX23_LRADC,
>> > }, + { .compatible = "fsl,imx28-lradc", .data = (void
>> > *)IMX28_LRADC, }, + { /* sentinel */ }
>> > +};
>> > +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
>> > +
>>
>> Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
>
> Check the register layout, it differs between MX23 and MX28, that's one reason,
> since were we to access differently placed registers, we can do it easily as in
> the SSP/I2C drivers.
>
> Moreover, there are some features on the MX28 that are not on the MX23 (like
> voltage treshold triggers and touchbuttons), with this setup, we can easily
> check what we're running at at runtime and determine to disallow these.
>
> From my point of view, using the number (IMX23_LRADC / IMX28_LRADC) is much more
> convenient in the long run.
I'm asking, because you don't use this number anywhere other than in
mxs_lradc_probe()
and there only to dereference the irq-names table. After that the
structure and number
are forgotten.
Sure, it's just an insn or two, so no strong opinion here --- just curious.
Best Regards,
Micha? Miros?aw
^ permalink raw reply
* [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
From: Marek Vasut @ 2013-01-21 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHXqBFKzMgX48EJL_f6RF1tZYkdPLCZhip7M9jNuFkY+wjeQqA@mail.gmail.com>
Dear Micha? Miros?aw,
> 2013/1/21 Marek Vasut <marex@denx.de>:
> > Dear Micha? Miros?aw,
> >
> >> 2013/1/21 Marek Vasut <marex@denx.de>:
> >> > This patch adds support for i.MX23 into the LRADC driver. The LRADC
> >> > block on MX23 is not much different from the one on MX28, thus this
> >> > is only a few changes fixing the parts that are specific to MX23.
> >>
> >> [...]
> >>
> >> > +struct mxs_lradc_of_config {
> >> > + const int irq_count;
> >> > + const char * const *irq_name;
> >> > +};
> >> > +
> >> > +static const struct mxs_lradc_of_config const mxs_lradc_of_config[] =
> >> > { + [IMX23_LRADC] = {
> >> > + .irq_count = ARRAY_SIZE(mx23_lradc_irq_names),
> >> > + .irq_name = mx23_lradc_irq_names,
> >> > + },
> >> > + [IMX28_LRADC] = {
> >> > + .irq_count = ARRAY_SIZE(mx28_lradc_irq_names),
> >> > + .irq_name = mx28_lradc_irq_names,
> >> > + },
> >> > +};
> >> > +
> >> >
> >> > enum mxs_lradc_ts {
> >> >
> >> > MXS_LRADC_TOUCHSCREEN_NONE = 0,
> >> > MXS_LRADC_TOUCHSCREEN_4WIRE,
> >> >
> >> > @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc
> >> > *lradc)
> >> >
> >> > writel(0, lradc->base + LRADC_DELAY(i));
> >> >
> >> > }
> >> >
> >> > +static const struct of_device_id mxs_lradc_dt_ids[] = {
> >> > + { .compatible = "fsl,imx23-lradc", .data = (void
> >> > *)IMX23_LRADC, }, + { .compatible = "fsl,imx28-lradc", .data =
> >> > (void
> >> > *)IMX28_LRADC, }, + { /* sentinel */ }
> >> > +};
> >> > +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
> >> > +
> >>
> >> Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
> >
> > Check the register layout, it differs between MX23 and MX28, that's one
> > reason, since were we to access differently placed registers, we can do
> > it easily as in the SSP/I2C drivers.
> >
> > Moreover, there are some features on the MX28 that are not on the MX23
> > (like voltage treshold triggers and touchbuttons), with this setup, we
> > can easily check what we're running at at runtime and determine to
> > disallow these.
> >
> > From my point of view, using the number (IMX23_LRADC / IMX28_LRADC) is
> > much more convenient in the long run.
>
> I'm asking, because you don't use this number anywhere other than in
> mxs_lradc_probe()
> and there only to dereference the irq-names table. After that the
> structure and number
> are forgotten.
Certainly, so far it's used only this way. But please see my argument about
register layout, that's why I went down this road of abstraction.
> Sure, it's just an insn or two, so no strong opinion here --- just curious.
I tried to put it down above ;-)
> Best Regards,
> Micha? Miros?aw
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
From: Sebastien Guiriec @ 2013-01-21 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD512B.4020003@ti.com>
Hi Santosh,
I have push under the omap-audio gitorious two patches on top of your
series. One for adding the ABE DPLL and a second for the remove of Audio
DMA addresses.
https://gitorious.org/omap-audio/linux-audio/commits/base/omap5_es2_data
I will try to check Display tomorrow.
Sebastien
On 01/21/2013 03:31 PM, Santosh Shilimkar wrote:
> On Monday 21 January 2013 07:57 PM, Sebastien Guiriec wrote:
>> Hi Santosh,
>>
>> I check the tree with Audio and it is working. Just a comment for the
>> addition of ABE DPLL locking like for OMAP4.
>>
> Excellent. Can you send the update please?
> I will fold that in.
>
> Regards
> santosh
>
^ permalink raw reply
* [PATCH 11/15] mtd: davinci_nand: fix OF support
From: Heiko Schocher @ 2013-01-21 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-12-git-send-email-arnd@arndb.de>
Hello Arnd,
On 21.01.2013 18:16, Arnd Bergmann wrote:
> The patch cdeadd "mtd: nand: davinci: add OF support for
> davinci nand controller" ironically causes a build error
> when CONFIG_OF is enabled because of a missing ';'
> character:
>
> drivers/mtd/nand/davinci_nand.c:527:1: error: expected ',' or ';' before 'extern'
>
> This is the obvious fix.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Cc: David Woodhouse <David.Woodhouse@intel.com>
> ---
> drivers/mtd/nand/davinci_nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Already fixed here:
http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
From: Lars-Peter Clausen @ 2013-01-21 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301212232.52161.marex@denx.de>
On 01/21/2013 10:32 PM, Marek Vasut wrote:
> Dear Micha? Miros?aw,
>
>> 2013/1/21 Marek Vasut <marex@denx.de>:
>>> Dear Micha? Miros?aw,
>>>
>>>> 2013/1/21 Marek Vasut <marex@denx.de>:
>>>>> This patch adds support for i.MX23 into the LRADC driver. The LRADC
>>>>> block on MX23 is not much different from the one on MX28, thus this
>>>>> is only a few changes fixing the parts that are specific to MX23.
>>>>
>>>> [...]
>>>>
>>>>> +struct mxs_lradc_of_config {
>>>>> + const int irq_count;
>>>>> + const char * const *irq_name;
>>>>> +};
>>>>> +
>>>>> +static const struct mxs_lradc_of_config const mxs_lradc_of_config[] =
>>>>> { + [IMX23_LRADC] = {
>>>>> + .irq_count = ARRAY_SIZE(mx23_lradc_irq_names),
>>>>> + .irq_name = mx23_lradc_irq_names,
>>>>> + },
>>>>> + [IMX28_LRADC] = {
>>>>> + .irq_count = ARRAY_SIZE(mx28_lradc_irq_names),
>>>>> + .irq_name = mx28_lradc_irq_names,
>>>>> + },
>>>>> +};
>>>>> +
>>>>>
>>>>> enum mxs_lradc_ts {
>>>>>
>>>>> MXS_LRADC_TOUCHSCREEN_NONE = 0,
>>>>> MXS_LRADC_TOUCHSCREEN_4WIRE,
>>>>>
>>>>> @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc
>>>>> *lradc)
>>>>>
>>>>> writel(0, lradc->base + LRADC_DELAY(i));
>>>>>
>>>>> }
>>>>>
>>>>> +static const struct of_device_id mxs_lradc_dt_ids[] = {
>>>>> + { .compatible = "fsl,imx23-lradc", .data = (void
>>>>> *)IMX23_LRADC, }, + { .compatible = "fsl,imx28-lradc", .data =
>>>>> (void
>>>>> *)IMX28_LRADC, }, + { /* sentinel */ }
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
>>>>> +
>>>>
>>>> Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
>>>
>>> Check the register layout, it differs between MX23 and MX28, that's one
>>> reason, since were we to access differently placed registers, we can do
>>> it easily as in the SSP/I2C drivers.
>>>
>>> Moreover, there are some features on the MX28 that are not on the MX23
>>> (like voltage treshold triggers and touchbuttons), with this setup, we
>>> can easily check what we're running at at runtime and determine to
>>> disallow these.
>>>
>>> From my point of view, using the number (IMX23_LRADC / IMX28_LRADC) is
>>> much more convenient in the long run.
>>
>> I'm asking, because you don't use this number anywhere other than in
>> mxs_lradc_probe()
>> and there only to dereference the irq-names table. After that the
>> structure and number
>> are forgotten.
>
> Certainly, so far it's used only this way. But please see my argument about
> register layout, that's why I went down this road of abstraction.
You'll probably be better of by putting these differences into the
mxs_lradc_of_config struct as well, instead of adding switch statements here
and there throughout the code.
- Lars
^ 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