* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Joe Perches @ 2014-02-05 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205124127.GP26684@n2100.arm.linux.org.uk>
On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
> > Apparently, people just convert stupidly large udelay()s
> > to mdelay and not be bothered.
>
> And that's the correct answer. Having udelay(10000) rather than mdelay(10)
> is a sign that they weren't paying that much attention when writing the
> code.
Not really.
Look at the code that brought this up in the first place.
On Tue, 2014-02-04 at 08:37 +0530, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> Use mdelay instead of udelay to fix this error:
>
> ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
[]
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
[]
> @@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type)
> if (AR_SREV_9300_20_OR_LATER(ah))
> udelay(50);
> else if (AR_SREV_9100(ah))
> - udelay(10000);
> + mdelay(10);
> else
> udelay(100);
>
>
> > if (AR_SREV_9300_20_OR_LATER(ah))
> > udelay(50);
> > else if (AR_SREV_9100(ah))
> > - udelay(10000);
> > + mdelay(10);
> > else
> > udelay(100);
One chip needs a larger delay than the others.
It's not so much not paying attention as not
knowing ARM is broken for large udelay().
^ permalink raw reply
* [PATCH v2 0/6] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: David Lanzendörfer @ 2014-02-05 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205103949.GC3192@lukather>
Hi Maxime
> I have four comments here:
> - Read Documentation/SubmittingPatches, especially Section 5 and 12
> (hints, you forgot the clock maintainers for your clock patches
> and you didn't put any signed-off-by tags)
Oops. I added signed-offs now
> - You ignored pretty much all the comments that were made during the
> review of the first version. Go through
Uh? I just fixed the commits and squashed them together for easier handling.
I'm even using mmc_of_parse now...
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219339.
> html and address the comments that were made.
> - Each of your patches should compile. Fix the order of your
> patches.
Done.
> - Submit a v3, with the changes you made. Otherwise we have no way
> of knowing what have been fixed and what didn't
Too many patches would be bloaty.
That's why I've squashed them into small and corrected patches.
> Looking forward for the next iteration!
Good :-)
You can have a look at the recent status here:
http://git.o2s.ch/?p=linux-next.git;a=shortlog;h=refs/heads/20140205
cheers
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/d03c7f13/attachment.sig>
^ permalink raw reply
* [PATCH 10/17] spi: pl022: Remove redundant pinctrl to default state in probe
From: Linus Walleij @ 2014-02-05 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-11-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> The driver core is now taking care of putting our pins into default
> state at probe. Thus we can remove the redundant call for it in probe.
>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 05/17] mmc: mmci: Put the device into low power state at system suspend
From: Linus Walleij @ 2014-02-05 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8738jyu1h9.fsf@paris.lan>
On Tue, Feb 4, 2014 at 8:22 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
>> Due to the available runtime PM callbacks, we are now able to put our
>> device into low power state at system suspend.
(...)
> I'm trying to thing of a good reason to not make PM_SLEEP depend on
> PM_RUNTIME for platforms like this.
Isn't the typical Android platform using PM_SLEEP without using
PM_RUNTIME?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 16/18] charger: max14577: Add support for MAX77836 charger
From: Krzysztof Kozlowski @ 2014-02-05 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203113031.GA8848@jenny-desktop>
Hi,
On Mon, 2014-02-03 at 17:00 +0530, Jenny Tc wrote:
> On Tue, Jan 28, 2014 at 01:18:40PM +0100, Krzysztof Kozlowski wrote:
> > - /* Battery-Charger Constant Voltage (CV) Mode, from SM-V700: 4.35V */
> > + /* Battery-Charger Constant Voltage (CV) Mode, set to: 4.35V */
>
> Does this charger chip support only 4.35V batteries? If the CV is hard coded
> to 4.35V, it's not safe for 4.2V batteries.
>
> > + /* End-of-Charge Current, set to 50mA (max14577) / 7.5mA (max77836) */
> The End of charge current basically depend on battery and not on charger chip.
>
> > - /* Overvoltage-Protection Threshold, from SM-V700: 6.5V */
> > + /* Overvoltage-Protection Threshold, set to 6.5V */
> 6.5V as over voltage for battery? A 4.35V battery would have exploded by
> that time!
Currently the max14577 driver has all these values hard-coded. This
patch doesn't change this, it only adds support for max77836. I agree
with you that hard-coding these values is not a proper way of doing
this.
I'll add another patch for parsing these values from DTS.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4] of: add functions to count number of elements in a property
From: Heiko Stübner @ 2014-02-05 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205120652.9B1A7C40A89@trevor.secretlab.ca>
Am Mittwoch, 5. Februar 2014, 12:06:52 schrieb Grant Likely:
> On Tue, 04 Feb 2014 19:48:17 +0100, Heiko St??bner <heiko@sntech.de> wrote:
> > Hi Grant,
> >
> > On Tuesday, 4. February 2014 17:30:34 Grant Likely wrote:
> > > On Sat, 18 Jan 2014 09:07:30 -0600, Rob Herring <robherring2@gmail.com>
> >
> > wrote:
> > > > On Sat, Jan 18, 2014 at 6:02 AM, Heiko St????bner <heiko@sntech.de>
wrote:
> > > > > The need to know the number of array elements in a property is
> > > > > a common pattern. To prevent duplication of open-coded
> > > > > implementations
> > > > > add a helper static function that also centralises strict sanity
> > > > > checking and DTB format details, as well as a set of wrapper
> > > > > functions
> > > > > for u8, u16, u32 and u64.
> > > > >
> > > > > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > > > ---
> > > >
> > > > Looks good. Do you plan to convert some users to use this?
> > >
> > > I'll take that as an acked-by. Merged, thanks.
> >
> > before you taking this patch, I was planning on simply sending this as
> > part of my rockchip-smp series - as I'm currently the only user of it :-)
> > .
> >
> > This going through your tree is most likely the better way, but now I need
> > it to somehow make its way into arm-soc too ... I guess some sort of
> > stable branch arm-soc could pull?
>
> Nah, I'll drop it from my tree. Add my acked-by and merge it via
> arm-soc.
As I said on IRC, now it seems like you can keep this patch in your tree :-)
If we're really going with reserved-memory like you suggested in the rockchip-
smp series it removes the need to count u32-elements in a property for me, as
the reserved blocks move into individual subnodes.
Heiko
^ permalink raw reply
* [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham @ 2014-02-05 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205124459.61c7da0e@amdc2363>
Hi Lukasz,
On Wed, Feb 5, 2014 at 5:14 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Thomas,
>
> Fist of all, thanks for your patches.
>
>> Hi Lukasz,
>>
>> On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski
>> <l.majewski@samsung.com> wrote:
>> > Hi Thomas,
>> >
>> >> From: Thomas Abraham <thomas.ab@samsung.com>
>> >>
>> >> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched
>> >> over to use cpufreq-cpu0 driver for cpufreq functionality. So the
>> >> Exynos specific cpufreq drivers for these platforms can be removed.
>> >>
>>
>> <snip>
>>
>> >> -static unsigned int exynos4x12_volt_table[] = {
>> >> - 1350000, 1287500, 1250000, 1187500, 1137500, 1087500,
>> >> 1037500,
>> >> - 1000000, 987500, 975000, 950000, 925000, 900000, 900000
>> >> -};
>> >> -
>> >> -static struct cpufreq_frequency_table exynos4x12_freq_table[] = {
>> >> - {CPUFREQ_BOOST_FREQ, 1500 * 1000},
>> >
>> > Here, you are removing BOOST support for Exynos4412, without any
>> > code, which brings back this functionality in the new code.
>> >
>> > I'd propose adding new property to cpus node and during
>> > operating-points parsing mark the entry at the
>> > cpufreq_frequency_table accordingly.
>>
>> I tried doing this as you suggested with [1] but looks like that will
>> not go through at this point.
>
> I've read your patches regarding OPP. In my opinion, despite the problem
> with further OPP format discussion (which is ongoing and probably will
> take some time), there is a palatable solution (presented below).
>
>> The other alternative would be to use
>> exynos specific cpufreq drivers only if multiplatform config is not
>> selected or use cpufreq-cpu0 if multiplatform config is selected (but
>> this is not something I would want to do). With this, there are issues
>> like clock blocks encapsulated within the opaque clock type cannot be
>> removed since exynos specific cpufreq drivers need it and hence it is
>> not really a clean solution.
>
> It would be a maintenance nightmare. We cannot afford to do such huge
> cleanup only partially. The rationale for the whole clean up is to
> remove exynosXXXX-cpufreq.c files.
>
> I also share your doubts here. We shall NOT do it this way.
>
>>The other option is to drop the support
>> for boost on exynos4x12 for now and reintroduce that when the OPP
>> bindings have been finalized.
>
> So you want to drop the BOOST kernel functionality just because you are
> doing clean up and this feature is problematic to provide at new
> approach?
>
>> Would that be okay?
>
> It is NOT acceptable. Sorry, but NAK.
>
>> Any other
>> suggestions will also be helpful.
>
> For me it would be perfectly fine to see at device tree CPU0 node code
> proposed by Nishanth:
>
> operating-points = < Fa Va
> Fb Vb
> Fc Vc
> Fd Vd
> >;
> boost-frequencies = <Fc Fd>;
>
> And then the cpufreq table could be properly modified by marking
> relevant frequencies as CPUFREQ_BOOST_FREQ.
Okay, thanks. Initially it looked like adding boost frequencies into
operating-modes would convolute it but I guess I was wrong. So I will
add support for looking up "boost-frequencies" property in
dev_pm_opp_init_cpufreq_table function and mark the frequencies listed
in this binding as CPUFREQ_BOOST_FREQ.
Thanks,
Thomas.
>
>>
>> Thanks,
>> Thomas.
>>
>> >
>> >> - {L1, 1400 * 1000},
>> >> - {L2, 1300 * 1000},
>> >> - {L3, 1200 * 1000},
>> >> - {L4, 1100 * 1000},
>> >> - {L5, 1000 * 1000},
>> >> - {L6, 900 * 1000},
>> >> - {L7, 800 * 1000},
>> >> - {L8, 700 * 1000},
>> >> - {L9, 600 * 1000},
>> >> - {L10, 500 * 1000},
>> >> - {L11, 400 * 1000},
>> >> - {L12, 300 * 1000},
>> >> - {L13, 200 * 1000},
>> >> - {0, CPUFREQ_TABLE_END},
>> >> -};
>> >> -
>> >> -static struct apll_freq *apll_freq_4x12;
>> >> -
>> >> -static struct apll_freq apll_freq_4212[] = {
>> >> - /*
>> >> - * values:
>> >> - * freq
>> >> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> >> PCLK_DBG, APLL, CORE2
>> >> - * clock divider for COPY, HPM, RESERVED
>> >> - * PLL M, P, S
>> >> - */
>> >> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 250, 4, 0),
>> >> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 175, 3, 0),
>> >> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 325, 6, 0),
>> >> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 200, 4, 0),
>> >> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 2, 0, 275, 6, 0),
>> >> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 2, 0, 125, 3, 0),
>> >> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 150, 4, 0),
>> >> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 0),
>> >> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 175, 3, 1),
>> >> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 200, 4, 1),
>> >> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 125, 3, 1),
>> >> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 1),
>> >> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 2, 0, 200, 4, 2),
>> >> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 2, 0, 100, 3, 2),
>> >> -};
>> >> -
>> >> -static struct apll_freq apll_freq_4412[] = {
>> >> - /*
>> >> - * values:
>> >> - * freq
>> >> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> >> PCLK_DBG, APLL, CORE2
>> >> - * clock divider for COPY, HPM, CORES
>> >> - * PLL M, P, S
>> >> - */
>> >> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 7, 250, 4, 0),
>> >> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 6, 175, 3, 0),
>> >> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 6, 325, 6, 0),
>> >> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 5, 200, 4, 0),
>> >> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 0, 5, 275, 6, 0),
>> >> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 0, 4, 125, 3, 0),
>> >> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 4, 150, 4, 0),
>> >> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 3, 100, 3, 0),
>> >> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 3, 175, 3, 1),
>> >> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 200, 4, 1),
>> >> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 125, 3, 1),
>> >> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 1, 100, 3, 1),
>> >> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 0, 1, 200, 4, 2),
>> >> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 0, 0, 100, 3, 2),
>> >> -};
>> >> -
>> >> -static void exynos4x12_set_clkdiv(unsigned int div_index)
>> >> -{
>> >> - unsigned int tmp;
>> >> - unsigned int stat_cpu1;
>> >> -
>> >> - /* Change Divider - CPU0 */
>> >> -
>> >> - tmp = apll_freq_4x12[div_index].clk_div_cpu0;
>> >> -
>> >> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU);
>> >> -
>> >> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU) & 0x11111111)
>> >> - cpu_relax();
>> >> -
>> >> - /* Change Divider - CPU1 */
>> >> - tmp = apll_freq_4x12[div_index].clk_div_cpu1;
>> >> -
>> >> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU1);
>> >> - if (soc_is_exynos4212())
>> >> - stat_cpu1 = 0x11;
>> >> - else
>> >> - stat_cpu1 = 0x111;
>> >> -
>> >> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU1) & stat_cpu1)
>> >> - cpu_relax();
>> >> -}
>> >> -
>> >> -static void exynos4x12_set_apll(unsigned int index)
>> >> -{
>> >> - unsigned int tmp, freq = apll_freq_4x12[index].freq;
>> >> -
>> >> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
>> >> - clk_set_parent(moutcore, mout_mpll);
>> >> -
>> >> - do {
>> >> - cpu_relax();
>> >> - tmp = (__raw_readl(EXYNOS4_CLKMUX_STATCPU)
>> >> - >> EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT);
>> >> - tmp &= 0x7;
>> >> - } while (tmp != 0x2);
>> >> -
>> >> - clk_set_rate(mout_apll, freq * 1000);
>> >> -
>> >> - /* MUX_CORE_SEL = APLL */
>> >> - clk_set_parent(moutcore, mout_apll);
>> >> -
>> >> - do {
>> >> - cpu_relax();
>> >> - tmp = __raw_readl(EXYNOS4_CLKMUX_STATCPU);
>> >> - tmp &= EXYNOS4_CLKMUX_STATCPU_MUXCORE_MASK;
>> >> - } while (tmp != (0x1 << EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
>> >> -}
>> >> -
>> >> -static void exynos4x12_set_frequency(unsigned int old_index,
>> >> - unsigned int new_index)
>> >> -{
>> >> - if (old_index > new_index) {
>> >> - exynos4x12_set_clkdiv(new_index);
>> >> - exynos4x12_set_apll(new_index);
>> >> - } else if (old_index < new_index) {
>> >> - exynos4x12_set_apll(new_index);
>> >> - exynos4x12_set_clkdiv(new_index);
>> >> - }
>> >> -}
>> >> -
>> >> -int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
>> >> -{
>> >> - unsigned long rate;
>> >> -
>> >> - cpu_clk = clk_get(NULL, "armclk");
>> >> - if (IS_ERR(cpu_clk))
>> >> - return PTR_ERR(cpu_clk);
>> >> -
>> >> - moutcore = clk_get(NULL, "moutcore");
>> >> - if (IS_ERR(moutcore))
>> >> - goto err_moutcore;
>> >> -
>> >> - mout_mpll = clk_get(NULL, "mout_mpll");
>> >> - if (IS_ERR(mout_mpll))
>> >> - goto err_mout_mpll;
>> >> -
>> >> - rate = clk_get_rate(mout_mpll) / 1000;
>> >> -
>> >> - mout_apll = clk_get(NULL, "mout_apll");
>> >> - if (IS_ERR(mout_apll))
>> >> - goto err_mout_apll;
>> >> -
>> >> - if (soc_is_exynos4212())
>> >> - apll_freq_4x12 = apll_freq_4212;
>> >> - else
>> >> - apll_freq_4x12 = apll_freq_4412;
>> >> -
>> >> - info->mpll_freq_khz = rate;
>> >> - /* 800Mhz */
>> >> - info->pll_safe_idx = L7;
>> >> - info->cpu_clk = cpu_clk;
>> >> - info->volt_table = exynos4x12_volt_table;
>> >> - info->freq_table = exynos4x12_freq_table;
>> >> - info->set_freq = exynos4x12_set_frequency;
>> >> -
>> >> - return 0;
>> >> -
>> >> -err_mout_apll:
>> >> - clk_put(mout_mpll);
>> >> -err_mout_mpll:
>> >> - clk_put(moutcore);
>> >> -err_moutcore:
>> >> - clk_put(cpu_clk);
>> >> -
>> >> - pr_debug("%s: failed initialization\n", __func__);
>> >> - return -EINVAL;
>> >> -}
>> >> diff --git a/drivers/cpufreq/exynos5250-cpufreq.c
>> >> b/drivers/cpufreq/exynos5250-cpufreq.c deleted file mode 100644
>> >> index 5f90b82..0000000
>> >> --- a/drivers/cpufreq/exynos5250-cpufreq.c
>> >> +++ /dev/null
>> >> @@ -1,183 +0,0 @@
>> >> -/*
>> >> - * Copyright (c) 2010-20122Samsung Electronics Co., Ltd.
>> >> - * http://www.samsung.com
>> >> - *
>> >> - * EXYNOS5250 - CPU frequency scaling support
>> >> - *
>> >> - * This program is free software; you can redistribute it and/or
>> >> modify
>> >> - * it under the terms of the GNU General Public License version 2
>> >> as
>> >> - * published by the Free Software Foundation.
>> >> -*/
>> >> -
>> >> -#include <linux/module.h>
>> >> -#include <linux/kernel.h>
>> >> -#include <linux/err.h>
>> >> -#include <linux/clk.h>
>> >> -#include <linux/io.h>
>> >> -#include <linux/slab.h>
>> >> -#include <linux/cpufreq.h>
>> >> -
>> >> -#include <mach/map.h>
>> >> -
>> >> -#include "exynos-cpufreq.h"
>> >> -
>> >> -static struct clk *cpu_clk;
>> >> -static struct clk *moutcore;
>> >> -static struct clk *mout_mpll;
>> >> -static struct clk *mout_apll;
>> >> -
>> >> -static unsigned int exynos5250_volt_table[] = {
>> >> - 1300000, 1250000, 1225000, 1200000, 1150000,
>> >> - 1125000, 1100000, 1075000, 1050000, 1025000,
>> >> - 1012500, 1000000, 975000, 950000, 937500,
>> >> - 925000
>> >> -};
>> >> -
>> >> -static struct cpufreq_frequency_table exynos5250_freq_table[] = {
>> >> - {L0, 1700 * 1000},
>> >> - {L1, 1600 * 1000},
>> >> - {L2, 1500 * 1000},
>> >> - {L3, 1400 * 1000},
>> >> - {L4, 1300 * 1000},
>> >> - {L5, 1200 * 1000},
>> >> - {L6, 1100 * 1000},
>> >> - {L7, 1000 * 1000},
>> >> - {L8, 900 * 1000},
>> >> - {L9, 800 * 1000},
>> >> - {L10, 700 * 1000},
>> >> - {L11, 600 * 1000},
>> >> - {L12, 500 * 1000},
>> >> - {L13, 400 * 1000},
>> >> - {L14, 300 * 1000},
>> >> - {L15, 200 * 1000},
>> >> - {0, CPUFREQ_TABLE_END},
>> >> -};
>> >> -
>> >> -static struct apll_freq apll_freq_5250[] = {
>> >> - /*
>> >> - * values:
>> >> - * freq
>> >> - * clock divider for ARM, CPUD, ACP, PERIPH, ATB, PCLK_DBG,
>> >> APLL, ARM2
>> >> - * clock divider for COPY, HPM, RESERVED
>> >> - * PLL M, P, S
>> >> - */
>> >> - APLL_FREQ(1700, 0, 3, 7, 7, 7, 3, 5, 0, 0, 2, 0, 425, 6, 0),
>> >> - APLL_FREQ(1600, 0, 3, 7, 7, 7, 1, 4, 0, 0, 2, 0, 200, 3, 0),
>> >> - APLL_FREQ(1500, 0, 2, 7, 7, 7, 1, 4, 0, 0, 2, 0, 250, 4, 0),
>> >> - APLL_FREQ(1400, 0, 2, 7, 7, 6, 1, 4, 0, 0, 2, 0, 175, 3, 0),
>> >> - APLL_FREQ(1300, 0, 2, 7, 7, 6, 1, 3, 0, 0, 2, 0, 325, 6, 0),
>> >> - APLL_FREQ(1200, 0, 2, 7, 7, 5, 1, 3, 0, 0, 2, 0, 200, 4, 0),
>> >> - APLL_FREQ(1100, 0, 3, 7, 7, 5, 1, 3, 0, 0, 2, 0, 275, 6, 0),
>> >> - APLL_FREQ(1000, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 125, 3, 0),
>> >> - APLL_FREQ(900, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 150, 4, 0),
>> >> - APLL_FREQ(800, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 100, 3, 0),
>> >> - APLL_FREQ(700, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 175, 3, 1),
>> >> - APLL_FREQ(600, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 200, 4, 1),
>> >> - APLL_FREQ(500, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 125, 3, 1),
>> >> - APLL_FREQ(400, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 100, 3, 1),
>> >> - APLL_FREQ(300, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 200, 4, 2),
>> >> - APLL_FREQ(200, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 100, 3, 2),
>> >> -};
>> >> -
>> >> -static void set_clkdiv(unsigned int div_index)
>> >> -{
>> >> - unsigned int tmp;
>> >> -
>> >> - /* Change Divider - CPU0 */
>> >> -
>> >> - tmp = apll_freq_5250[div_index].clk_div_cpu0;
>> >> -
>> >> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU0);
>> >> -
>> >> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU0) & 0x11111111)
>> >> - cpu_relax();
>> >> -
>> >> - /* Change Divider - CPU1 */
>> >> - tmp = apll_freq_5250[div_index].clk_div_cpu1;
>> >> -
>> >> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU1);
>> >> -
>> >> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU1) & 0x11)
>> >> - cpu_relax();
>> >> -}
>> >> -
>> >> -static void set_apll(unsigned int index)
>> >> -{
>> >> - unsigned int tmp;
>> >> - unsigned int freq = apll_freq_5250[index].freq;
>> >> -
>> >> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
>> >> - clk_set_parent(moutcore, mout_mpll);
>> >> -
>> >> - do {
>> >> - cpu_relax();
>> >> - tmp = (__raw_readl(EXYNOS5_CLKMUX_STATCPU) >> 16);
>> >> - tmp &= 0x7;
>> >> - } while (tmp != 0x2);
>> >> -
>> >> - clk_set_rate(mout_apll, freq * 1000);
>> >> -
>> >> - /* MUX_CORE_SEL = APLL */
>> >> - clk_set_parent(moutcore, mout_apll);
>> >> -
>> >> - do {
>> >> - cpu_relax();
>> >> - tmp = __raw_readl(EXYNOS5_CLKMUX_STATCPU);
>> >> - tmp &= (0x7 << 16);
>> >> - } while (tmp != (0x1 << 16));
>> >> -}
>> >> -
>> >> -static void exynos5250_set_frequency(unsigned int old_index,
>> >> - unsigned int new_index)
>> >> -{
>> >> - if (old_index > new_index) {
>> >> - set_clkdiv(new_index);
>> >> - set_apll(new_index);
>> >> - } else if (old_index < new_index) {
>> >> - set_apll(new_index);
>> >> - set_clkdiv(new_index);
>> >> - }
>> >> -}
>> >> -
>> >> -int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
>> >> -{
>> >> - unsigned long rate;
>> >> -
>> >> - cpu_clk = clk_get(NULL, "armclk");
>> >> - if (IS_ERR(cpu_clk))
>> >> - return PTR_ERR(cpu_clk);
>> >> -
>> >> - moutcore = clk_get(NULL, "mout_cpu");
>> >> - if (IS_ERR(moutcore))
>> >> - goto err_moutcore;
>> >> -
>> >> - mout_mpll = clk_get(NULL, "mout_mpll");
>> >> - if (IS_ERR(mout_mpll))
>> >> - goto err_mout_mpll;
>> >> -
>> >> - rate = clk_get_rate(mout_mpll) / 1000;
>> >> -
>> >> - mout_apll = clk_get(NULL, "mout_apll");
>> >> - if (IS_ERR(mout_apll))
>> >> - goto err_mout_apll;
>> >> -
>> >> - info->mpll_freq_khz = rate;
>> >> - /* 800Mhz */
>> >> - info->pll_safe_idx = L9;
>> >> - info->cpu_clk = cpu_clk;
>> >> - info->volt_table = exynos5250_volt_table;
>> >> - info->freq_table = exynos5250_freq_table;
>> >> - info->set_freq = exynos5250_set_frequency;
>> >> -
>> >> - return 0;
>> >> -
>> >> -err_mout_apll:
>> >> - clk_put(mout_mpll);
>> >> -err_mout_mpll:
>> >> - clk_put(moutcore);
>> >> -err_moutcore:
>> >> - clk_put(cpu_clk);
>> >> -
>> >> - pr_err("%s: failed initialization\n", __func__);
>> >> - return -EINVAL;
>> >> -}
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > Lukasz Majewski
>> >
>> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>> --
>> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Russell King - ARM Linux @ 2014-02-05 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391603566.2538.63.camel@joe-AO722>
On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
> On Wed, 2014-02-05 at 11:50 +0000, Russell King - ARM Linux wrote:
> > On Tue, Feb 04, 2014 at 08:36:36AM -0800, Joe Perches wrote:
> > > On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:
> > > > Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
> > > > cannot handle large values because of lost-of-precision.
> > > >
> > > > IMHO udelay on ARM is broken, because it also cannot work with fast
> > > > ARM processors (where bogomips >= 3355, which is in sight now). It's
> > > > just not broken enought that someone did something against it ... so
> > > > the current kludge is good enought.
> > >
> > > Maybe something like this would be better?
> >
> > No, the point of __bad_udelay() is that people doing stupidly large
> > udelay()s result in build errors,
>
> Apparently, people just convert stupidly large udelay()s
> to mdelay and not be bothered.
And that's the correct answer. Having udelay(10000) rather than mdelay(10)
is a sign that they weren't paying that much attention when writing the
code.
> Perhaps there should be some runtime udelay > maximum supported check.
Having both a runtime check _and_ a compile time check would actually
be a good thing, but any runtime check needs to be suitably rate-
limited.
The compile time check is very important because it catches a lot of
cases which wouldn't otherwise be found (eg, in drivers which hardly
anyone uses on ARM.)
Maybe the compile time check should be something which is implemented
in a cross-architecture way in linux/delay.h with the maximum set to
the lowest that any architecture can do?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/3] clk: rcar-h2: fix sd0/sd1 divisor table
From: Ben Dooks @ 2014-02-05 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F226A0.5070301@codethink.co.uk>
On 05/02/14 11:55, Ben Dooks wrote:
> On 05/02/14 10:56, Laurent Pinchart wrote:
>> Hi William,
>>
>> Thank you for the patch.
>>
>> On Tuesday 04 February 2014 18:17:36 William Towle wrote:
>>> The clk_div_table for cpg_sd01_div_table[] concurs with the manual
>>> but not with values found in the device itself (which are also the
>>> same as the ones in arch/arm/mach-shmobile/clock-r8a7790.c).
>>>
>>> Update the clk-rcar-gen2.c driver to have the same table as the one
>>> used by the mach-shmobile driver which work once further issues are
>>> fixed in the clk-rcar-gen2.c driver.
>>>
>>> Part of the fix for the following error where the driver reports the
>>> output as 1MHz but is really 97.5MHz:
>>> sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1
>>> MHz
>>>
>>> [ben.dooks at codethink.co.uk: updated patch description]
>>> Signed-off-by: William Towle <william.towle@codethink.co.uk>
>>> Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>> ---
>>> drivers/clk/shmobile/clk-rcar-gen2.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c
>>> b/drivers/clk/shmobile/clk-rcar-gen2.c index a59ec21..df4a1e6 100644
>>> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
>>> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
>>> @@ -170,6 +170,8 @@ static const struct clk_div_table
>>> cpg_sdh_div_table[] =
>>> { };
>>>
>>> static const struct clk_div_table cpg_sd01_div_table[] = {
>>> + { 0, 2 }, { 1, 3 }, { 2, 4 }, { 3, 6 },
>>> + { 4, 8 },
>>> { 5, 12 }, { 6, 16 }, { 7, 18 }, { 8, 24 },
>>> { 10, 36 }, { 11, 48 }, { 12, 10 }, { 0, 0 },
>>
>> With this applied the only difference between the sdh and sd0/1 dividers
>> tables would be the { 12, 10 } entry, available for sd0/1 only. Given
>> that the
>> hardware does not match the documentation, could you check whether
>> that entry
>> is supported by sdh as well ? If so we could merge the two tables.
>> Otherwise
>> this patch looks good, could you please just reformat the table to
>> avoid the
>> mostly empty line in the middle ?
>
> I would like feedback from Renesas on this issue if possible. I can
> have a quick try at setting the clock value to 10 in u-boot and scope
> it out and see what happens.
>
> Magnus or Morimoto-san, is there a chance this could be reviewed by
> someone in Renesas who has knowledge of the hardware block?
>
> [PS, added Kuninori Morimoto to this[
I got William to do a quick test with the following u-boot command
mw.l 0xE6150074 0xCCC
sdhi0 showed 156MHz output, and it seemed to work. So there is a
distinct possibility that the sdh clock also supports setting 12
for a /10
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Joe Perches @ 2014-02-05 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205115035.GO26684@n2100.arm.linux.org.uk>
On Wed, 2014-02-05 at 11:50 +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 04, 2014 at 08:36:36AM -0800, Joe Perches wrote:
> > On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:
> > > Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
> > > cannot handle large values because of lost-of-precision.
> > >
> > > IMHO udelay on ARM is broken, because it also cannot work with fast
> > > ARM processors (where bogomips >= 3355, which is in sight now). It's
> > > just not broken enought that someone did something against it ... so
> > > the current kludge is good enought.
> >
> > Maybe something like this would be better?
>
> No, the point of __bad_udelay() is that people doing stupidly large
> udelay()s result in build errors,
Apparently, people just convert stupidly large udelay()s
to mdelay and not be bothered.
> rather than having to run the kernel
> and trip over a non-existent debugging message beacuse they haven't
> built the kernel with DEBUG defined.
>
> NAK.
<shrug>
Perhaps there should be some runtime udelay > maximum
supported check.
^ permalink raw reply
* [GIT PULL] ARM: imx: device tree changes for 3.15, take 1
From: Shawn Guo @ 2014-02-05 12:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi arm-soc folks,
This is basically imx-dt-3.14 pull request that missed the 3.14 merge
window with the pingrp removal series applied on top of. It also
includes a few additional board support I collected since imx-dt-3.14.
There will be another round of IMX DT changes for 3.15 later, but this
one should be the majority. Please pull, thanks.
Shawn
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.15
for you to fetch changes up to 6e63728deb5340f6a4988d98ff86227abf62c81d:
ARM: dts: imx28-m28cu3: Remove 'reset-active-high' (2014-02-03 22:57:45 +0800)
----------------------------------------------------------------
i.MX device tree changes for 3.15:
- New SoC device tree support for imx35 and imx50.
- A good number of new i.MX6 boards support: SolidRun HummingBoard,
cm-fx6, dmo-edmqmx6, nitrogen6x, Gateworks Ventana gw5xxx family,
DFI FS700-M60 and Zealz GK802.
- A few other new i.MX boards support: imx25-eukrea, imx28-duckbill,
imx28-eukrea, Eukrea cpuimx35, imx50-evk, imx51-eukrea, imx53-voipac,
MCIMX53-START-R and Ka-Ro TX53.
- Add pinfunc headers for imx25, imx27 and imx50.
- Make pinctrl nodes board specific to avoid floating board specific
device tree blob with so many unused pinctrl data.
- Use clock defines in imx5 DTS files.
- Update imx6q-sabrelite device tree and add Dual Lite/Solo support.
- Use GPIO_6 for FEC interrupt to workaround a hardware bug (ERR006687
ENET: Only the ENET wake-up interrupt request can wake the system
from Wait mode.)
- A plenty of random updates on various SoC and board device tree
sources, adding pinctrl settings, device nodes, properties, etc.
----------------------------------------------------------------
Aida Mynzhasova (1):
ARM: dts: mxs: add auart2 pinmux to imx28.dtsi
Alexander Shiyan (26):
ARM: dts: i.MX51: Update CPU node
ARM: dts: i.MX51: Add dummy clock to AUDMUX
ARM: dts: i.MX51: Switch to use standard IRQ flags definitions
ARM: dts: i.MX51: Move usbphy0 node from AIPS1
ARM: dts: i.MX51 boards: Switch to use standard GPIO flags definitions
ARM: dts: imx51-babbage: Fix chipselect level for dataflash on spi0.1
ARM: dts: imx51-babbage: Define FEC reset pin
ARM: dts: imx27-phytec-phycore-som: Add on-flash BBT support
ARM: dts: imx27-phytec-phycore-rdk: Add DT node for camera module
ARM: dts: imx27-phytec-phycore-som: Update FEC node
ARM: dts: i.MX27 boards: Switch to use standard GPIO and IRQ flags definitions
ARM: dts: i.MX27: Configure GPIOs as "input" by default
ARM: dts: i.MX: Move include "imxXX-pinfunc.h" into "imxXX-pingrp.h"
ARM: dts: imx27-phytec-phycore-rdk: Change pinctrl settings for I2C1
ARM: dts: imx27-phytec-phycore-som: trivial: Typo fix
ARM: dts: imx27-phytec-phycore-som: Add pinctrl for CSPI1 and GPIOs used on module
ARM: dts: imx27-phytec-phycore-som: Rename file to .dtsi
ARM: dts: imx27-phytec-phycore-som: Add NFC pin group
ARM: dts: imx27-phytec-phycore-rdk: Enable 1-Wire module
ARM: dts: imx27-phytec-phycore-som: Add spi-cs-high property to PMIC
ARM: dts: i.MX27: Add missing pullup settings for SDHC pin groups
ARM: dts: imx27-phytec-phycore-rdk: Add pingrp for SDHC
ARM: dts: imx27-phytec-phycore-rdk: Add pinctrl definitions for WEIM
ARM: dts: i.MX27: Add SSI nodes
ARM: dts: imx53-evk: Remove board support
ARM: dts: i.MX51: Switch to use standard definitions for input subsystem
Alexandre Belloni (3):
ARM: dts: mxs: add #io-channel-cells to mx28 lradc
ARM: dts: mxs: Add iio-hwmon to mx28 soc
ARM: dts: mxs: Add iio-hwmon to mx23 soc
Anson Huang (7):
ARM: dts: imx6q: update setting of VDDARM_CAP voltage
ARM: dts: imx6q: add vddsoc/pu setpoint info
ARM: dts: imx6dl: enable cpufreq support
ARM: dts: imx6qdl: add necessary thermal clk
ARM: dts: imx6qdl-sabresd: Add power key support
ARM: dts: imx6sl: add ocram device support
ARM: dts: imx6sl: add keypad support for i.mx6sl-evk board.
Denis Carikli (15):
of: add vendor prefix for Eukrea Electromatique.
ARM: dts: i.MX25: Add ssi clocks and DMA events.
ARM: dts: i.MX25: Add sdma script path.
ARM: dts: imx25.dtsi: Add a label for the Audio Multiplexer.
ARM: dts: imx51.dtsi: Add some pinmux pins.
ARM: dts: Add support for the cpuimx51 board from Eukrea and its baseboard.
ARM: dts: imx25: Add pinctrl functions and groups.
ARM: dts: imx25.dtsi: label the iomuxc.
ARM: dts: mxs: Add 18bit pin config for lcdif.
ARM: dts: mxs: Add a new pin config for the usb0 ID.
ARM: dts: Add support for the cpuimx25 board from Eukrea and its baseboard.
ARM: dts: mbimxsd25: Add sound support.
ARM: dts: mbimxsd51: Add sound support.
ARM: dts: imx53: Add gpio and input dt includes.
ARM: dts: Add support for the cpuimx35 board from Eukrea and its baseboard.
Eric B?nard (1):
ARM: mxs: Add support for the eukrea-cpuimx28.
Fabio Estevam (8):
ARM: dts: imx6q-udoo: Add Ethernet support
ARM: dts: imx6q-sabrelite: Remove duplicate GPIO entry
ARM: dts: imx6q-sabrelite: Place 'status' as the last node
ARM: dts: imx28-evk: Run I2C0 at 400kHz
ARM: dts: imx6: Use 'vddarm' as the regulator name
ARM: dts: imx6qdl-sabresd: Add PFUZE100 support
ARM: dts: imx6qdl-sabreauto: Add LVDS support
ARM: dts: imx28-m28cu3: Remove 'reset-active-high'
Frank Li (1):
ARM: dts: imxqdl: enable dma for spi
Greg Ungerer (3):
ARM: dts: imx: add device tree pin definitions for the IMX50
ARM: dts: imx: add IMX50 SoC device tree
ARM: dts: imx: add device tree support for Freescale imx50evk board
Gwenhael Goavec-Merou (10):
ARM: imx27-apf27dev: Add sdhci support
ARM: dts: imx27-apf27dev: fix display size
ARM: imx27: add pingroups for cspi, sdhc and framebuffer
ARM: dts: imx27: imx27-apf27: add pinctrl for fec and uart1
ARM: dts: imx27: imx27-apf27dev: add pinctrl for cspi, i2c, sdhc and framebuffer
ARM: dts: apf28dev: set gpio polarity for usb regulator and pinctrl for regulator gpio
ARM: imx28: add apf28 specific initialization (macaddr)
ARM: imx27: add pwm pingrp
ARM: dts: apf27dev: Add pwm support
ARM: dts: imx27-apf27dev: Add pinctrl for cspi, sdhci, leds and keys
Huang Shijie (1):
ARM: dts: vf610: use the interrupt macros
John Tobias (1):
ARM: dts: imx6sl: Adding cpu frequency and VDDSOC/PU table.
Lothar Wa?mann (4):
ARM: dts: imx6qdl: add aliases for can interfaces
ARM: dts: imx6qdl: add pingroup for enet interface in RMII mode
ARM: dts: imx6qdl: add new pingroup for audmux
ARM: dts: imx53: add support for Ka-Ro TX53 modules
Lucas Stach (3):
ARM: imx53: use clock defines in DTS files
ARM: imx51: use clock defines in DTS files
ARM: imx50: use clock defines in DTS files
Marek Vasut (6):
ARM: dts: imx53: Fix display pinmux for M53EVK
ARM: dts: imx53: Fix backlight for M53EVK
ARM: dts: imx53: Add USB support for M53EVK
ARM: dts: imx53: Add AHCI SATA DT node
ARM: dts: imx53: Enable AHCI SATA for M53EVK
ARM: dts: imx6q-sabrelite: Enable PCI express
Markus Pargmann (7):
ARM: dts: imx27 pin functions
ARM: dts: imx27 pingroups
ARM: dts: imx27 iomux device node
ARM: dts: imx27 phyCARD-S pinctrl
ARM: dts: imx27 phycore move uart1 to rdk
ARM: dts: imx27 phycore pinctrl
ARM: DTS: imx5* imx6*, use imx51-ssi
Maxime Ripard (2):
ARM: mxs: cfa10049: Add NAU7802 ADCs to the device tree
ARM: dts: cfa10036: Add dr_mode and phy_type properties to the DT
Michael Grzeschik (1):
ARM: i.MX28: dts: rename usbphy pin names
Michael Heimpold (1):
ARM: mxs: add support for I2SE's duckbill series
Nicolin Chen (2):
ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000
ARM: dts: imx6qdl: add spdif support for sabreauto
Peter Chen (3):
ARM: dts: imx6q-arm2: enable USB OTG
ARM: dts: imx6: add anatop phandle for usbphy
ARM: dts: imx: add mxs phy controller id
Philipp Zabel (2):
ARM: dts: imx6q-sabrelite: PHY reset is active-low
ARM: dts: imx6: edmqmx6: add PF0100 PMIC to device tree
Robert Nelson (1):
ARM: dts: imx53: Enable AHCI SATA for imx53-qsb
Rostislav Lisovy (8):
ARM: dts: i.MX53: Add alternate pinmux option for i2c_3
ARM: dts: i.MX53: Internal keyboard controller
ARM: dts: Add vendor prefix for Voipac Technologies s.r.o.
ARM: dts: i.MX53: dts for Voipac x53-dmm-668 module
ARM: dts: i.MX53: Devicetree for Voipac Baseboard using x53-dmm-668 module
ARM: dts: voipac: Improve fixed voltage regulator definition
ARM: i.MX53: dts: NAND flash controller
ARM: i.MX53: dts: USB host controller
Sascha Hauer (9):
ARM: dts: imx53: Add mmc aliases
ARM: dts: imx6q: Add spi4 alias
ARM: dts: imx6qdl: Add mmc aliases
ARM: dts: imx51: Add mmc aliases
ARM: dts: imx6: Add DFI FS700-M60 board support
ARM: dts: imx6: edmqmx6: Add usdhc4 (emmc) support
ARM: dts: imx6: edmqmx6: Add sata support
ARM: dts: imx6: edmqmx6: Add LED support
ARM: dts: imx6q: Add support for Zealz GK802
Shawn Guo (17):
ARM: dts: imx6qdl: make pinctrl nodes board specific
ARM: dts: imx6sl: make pinctrl nodes board specific
ARM: dts: imx53: make pinctrl nodes board specific
ARM: dts: imx51: make pinctrl nodes board specific
ARM: dts: imx50: make pinctrl nodes board specific
ARM: dts: imx53-mba53: create a container for fixed regulators
ARM: dts: imx: use generic node name for fixed regulator
ARM: dts: vf610: make pinctrl nodes board specific
ARM: dts: imx6qdl: remove the use of pingrp macros
ARM: dts: imx6sl: remove the use of pingrp macros
ARM: dts: imx53: remove the use of pingrp macros
ARM: dts: imx51: remove the use of pingrp macros
ARM: dts: imx50: remove the use of pingrp macros
ARM: dts: imx35: remove the use of pingrp macros
ARM: dts: imx25: remove the use of pingrp macros
ARM: dts: imx27: remove the use of pingrp macros
ARM: dts: vf610: remove the use of pingrp macros
Silvio F (2):
DT: Add Data Modul vendor prefix
ARM: dts: imx6: Add support for imx6q dmo edmqmx6
Steffen Trumtrar (3):
ARM: dts: Add support for the i.MX35.
ARM: i.MX53: dts: move common QSB nodes to new file
ARM: i.MX53: dts: add support for MCIMX53-START-R
S?bastien Szymanski (1):
ARM: dts: imx28-apf28dev: add user button
Tim Harvey (3):
ARM: dts: disable flexcan by default
ARM: dts: added several new imx-pinmux groups
ARM: dts: add Gateworks Ventana support
Troy Kisky (30):
ARM: dts: imx: pinfunc: add MX6QDL_PAD_SD1_CLK__OSC32K_32K_OUT
ARM: dts: imx: imx6qdl.dtsi: add mipi_csi tag
ARM: dts: imx: imx6q.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6dl.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6sl.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6qdl.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6sl/qdl-pingrp: reorganize USDHCx pad groups
ARM: dts: imx: sabrelite: add Dual Lite/Solo support
ARM: dts: imx6qdl-sabrelite: Add uart1 support
ARM: dts: imx6qdl-sabrelite: remove usdhc4 wp-gpio
ARM: dts: imx6qdl-sabrelite: move pcie to imx6qdl-sabrelite.dtsi
ARM: dts: imx6qdl-sabrelite: move USDHC4 CD to pinctrl_usdhc4
ARM: dts: imx6qdl-sabrelite: move USDHC3 CD/WP to pinctrl_usdhc3
ARM: dts: imx6qdl-sabrelite: move spi-nor CS to pinctrl_ecspi1
ARM: dts: imx6qdl-sabrelite: move usbotg power enable to pinctrl_usbotg
ARM: dts: imx6qdl-sabrelite: move phy reset to pinctrl_enet
ARM: dts: imx6qdl-sabrelite: explicitly set pad for SGTL5000 sys_mclk
ARM: dts: imx6qdl-sabrelite: add pwms for backlights
ARM: dts: imx6qdl-sabrelite: add skews for Micrel phy
ARM: dts: imx6qdl-sabrelite: fix ENET group
ARM: dts: imx6qdl-sabrelite: Add over-current pin to usbotg
ARM: dts: imx: add nitrogen6x board
ARM: dts: imx6qdl-sabrelite: add gpio-keys
ARM: dts: imx: pinfunc: add MX6QDL_PAD_GPIO_6__ENET_IRQ
ARM: dts: imx6qdl: add pingroups for enet with GPIO6 interrupt
ARM: dts: imx6qdl-sabrelite: use MX6QDL_ENET_PINGRP_RGMII_MD
ARM: dts: imx6qdl: use interrupts-extended for fec
ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC interrupt.
ARM: dts: imx6qdl-sabreauto: use GPIO_6 for FEC interrupt.
ARM: dts: imx6q-arm2: use GPIO_6 for FEC interrupt.
Valentin Raevsky (1):
ARM: dts: Add initial support for cm-fx6.
.../devicetree/bindings/vendor-prefixes.txt | 3 +
arch/arm/boot/dts/Makefile | 30 +-
arch/arm/boot/dts/imx23-evk.dts | 8 +-
arch/arm/boot/dts/imx23-olinuxino.dts | 5 +-
arch/arm/boot/dts/imx23-stmp378x_devb.dts | 5 +-
arch/arm/boot/dts/imx23.dtsi | 8 +-
arch/arm/boot/dts/imx25-eukrea-cpuimx25.dtsi | 73 ++
.../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts | 174 ++++
arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
arch/arm/boot/dts/imx25.dtsi | 18 +-
arch/arm/boot/dts/imx27-apf27.dts | 38 +
arch/arm/boot/dts/imx27-apf27dev.dts | 149 +++-
arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 61 +-
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 42 +-
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 97 +-
...ycore-som.dts => imx27-phytec-phycore-som.dtsi} | 95 +-
arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
arch/arm/boot/dts/imx27.dtsi | 151 ++--
arch/arm/boot/dts/imx28-apf28dev.dts | 29 +-
arch/arm/boot/dts/imx28-apx4devkit.dts | 5 +-
arch/arm/boot/dts/imx28-cfa10036.dts | 2 +
arch/arm/boot/dts/imx28-cfa10037.dts | 7 +-
arch/arm/boot/dts/imx28-cfa10049.dts | 31 +-
arch/arm/boot/dts/imx28-cfa10057.dts | 7 +-
arch/arm/boot/dts/imx28-cfa10058.dts | 7 +-
arch/arm/boot/dts/imx28-duckbill.dts | 121 +++
arch/arm/boot/dts/imx28-eukrea-mbmx283lc.dts | 71 ++
arch/arm/boot/dts/imx28-eukrea-mbmx287lc.dts | 50 ++
arch/arm/boot/dts/imx28-eukrea-mbmx28lc.dtsi | 326 +++++++
arch/arm/boot/dts/imx28-evk.dts | 24 +-
arch/arm/boot/dts/imx28-m28cu3.dts | 17 +-
arch/arm/boot/dts/imx28-m28evk.dts | 18 +-
arch/arm/boot/dts/imx28-sps1.dts | 7 +-
arch/arm/boot/dts/imx28-tx28.dts | 23 +-
arch/arm/boot/dts/imx28.dtsi | 65 +-
arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi | 81 ++
.../boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts | 143 +++
arch/arm/boot/dts/imx35.dtsi | 359 ++++++++
arch/arm/boot/dts/imx50-evk.dts | 119 +++
arch/arm/boot/dts/imx50-pinfunc.h | 923 +++++++++++++++++++
arch/arm/boot/dts/imx50.dtsi | 478 ++++++++++
arch/arm/boot/dts/imx51-apf51.dts | 40 +-
arch/arm/boot/dts/imx51-apf51dev.dts | 102 ++-
arch/arm/boot/dts/imx51-babbage.dts | 248 +++++-
arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi | 93 ++
.../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 174 ++++
arch/arm/boot/dts/imx51.dtsi | 459 ++--------
arch/arm/boot/dts/imx53-ard.dts | 33 +-
arch/arm/boot/dts/imx53-evk.dts | 126 ---
arch/arm/boot/dts/imx53-m53evk.dts | 233 ++++-
arch/arm/boot/dts/imx53-mba53.dts | 40 +-
arch/arm/boot/dts/imx53-qsb-common.dtsi | 336 +++++++
arch/arm/boot/dts/imx53-qsb.dts | 210 +----
arch/arm/boot/dts/imx53-qsrb.dts | 158 ++++
arch/arm/boot/dts/imx53-smd.dts | 119 ++-
arch/arm/boot/dts/imx53-tqma53.dtsi | 175 +++-
arch/arm/boot/dts/imx53-tx53-x03x.dts | 315 +++++++
arch/arm/boot/dts/imx53-tx53-x13x.dts | 243 +++++
arch/arm/boot/dts/imx53-tx53.dtsi | 511 ++++++++++-
arch/arm/boot/dts/imx53-voipac-bsb.dts | 159 ++++
arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi | 277 ++++++
arch/arm/boot/dts/imx53.dtsi | 663 +++-----------
arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts | 23 +
arch/arm/boot/dts/imx6dl-gw51xx.dts | 19 +
arch/arm/boot/dts/imx6dl-gw52xx.dts | 19 +
arch/arm/boot/dts/imx6dl-gw53xx.dts | 19 +
arch/arm/boot/dts/imx6dl-gw54xx.dts | 19 +
arch/arm/boot/dts/imx6dl-nitrogen6x.dts | 21 +
arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
arch/arm/boot/dts/imx6dl-sabrelite.dts | 20 +
arch/arm/boot/dts/imx6dl.dtsi | 29 +-
arch/arm/boot/dts/imx6q-arm2.dts | 140 ++-
arch/arm/boot/dts/imx6q-cm-fx6.dts | 107 +++
arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts | 23 +
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 372 ++++++++
arch/arm/boot/dts/imx6q-gk802.dts | 171 ++++
arch/arm/boot/dts/imx6q-gw51xx.dts | 19 +
arch/arm/boot/dts/imx6q-gw52xx.dts | 23 +
arch/arm/boot/dts/imx6q-gw53xx.dts | 23 +
arch/arm/boot/dts/imx6q-gw5400-a.dts | 546 ++++++++++++
arch/arm/boot/dts/imx6q-gw54xx.dts | 23 +
arch/arm/boot/dts/imx6q-nitrogen6x.dts | 25 +
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 85 +-
arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
arch/arm/boot/dts/imx6q-sabrelite.dts | 178 +---
arch/arm/boot/dts/imx6q-sbc6x.dts | 58 +-
arch/arm/boot/dts/imx6q-udoo.dts | 54 +-
arch/arm/boot/dts/imx6q.dtsi | 21 +-
arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi | 199 +++++
arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 374 ++++++++
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 490 ++++++++++
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 553 ++++++++++++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 580 ++++++++++++
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 422 +++++++++
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 246 ++++-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 423 +++++++++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 272 +++++-
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 128 ++-
arch/arm/boot/dts/imx6qdl.dtsi | 938 +++-----------------
arch/arm/boot/dts/imx6sl-evk.dts | 210 ++++-
arch/arm/boot/dts/imx6sl.dtsi | 385 +++-----
arch/arm/boot/dts/vf610-cosmic.dts | 29 +-
arch/arm/boot/dts/vf610-twr.dts | 66 +-
arch/arm/boot/dts/vf610.dtsi | 207 +----
arch/arm/mach-mxs/mach-mxs.c | 33 +
105 files changed, 14073 insertions(+), 3127 deletions(-)
create mode 100644 arch/arm/boot/dts/imx25-eukrea-cpuimx25.dtsi
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts
create mode 100644 arch/arm/boot/dts/imx25-pinfunc.h
rename arch/arm/boot/dts/{imx27-phytec-phycore-som.dts => imx27-phytec-phycore-som.dtsi} (61%)
create mode 100644 arch/arm/boot/dts/imx27-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx28-duckbill.dts
create mode 100644 arch/arm/boot/dts/imx28-eukrea-mbmx283lc.dts
create mode 100644 arch/arm/boot/dts/imx28-eukrea-mbmx287lc.dts
create mode 100644 arch/arm/boot/dts/imx28-eukrea-mbmx28lc.dtsi
create mode 100644 arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
create mode 100644 arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts
create mode 100644 arch/arm/boot/dts/imx35.dtsi
create mode 100644 arch/arm/boot/dts/imx50-evk.dts
create mode 100644 arch/arm/boot/dts/imx50-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx50.dtsi
create mode 100644 arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
create mode 100644 arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
delete mode 100644 arch/arm/boot/dts/imx53-evk.dts
create mode 100644 arch/arm/boot/dts/imx53-qsb-common.dtsi
create mode 100644 arch/arm/boot/dts/imx53-qsrb.dts
create mode 100644 arch/arm/boot/dts/imx53-tx53-x03x.dts
create mode 100644 arch/arm/boot/dts/imx53-tx53-x13x.dts
create mode 100644 arch/arm/boot/dts/imx53-voipac-bsb.dts
create mode 100644 arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
create mode 100644 arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw51xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw52xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw53xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw54xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-nitrogen6x.dts
create mode 100644 arch/arm/boot/dts/imx6dl-sabrelite.dts
create mode 100644 arch/arm/boot/dts/imx6q-cm-fx6.dts
create mode 100644 arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts
create mode 100644 arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
create mode 100644 arch/arm/boot/dts/imx6q-gk802.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw51xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw52xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw53xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw5400-a.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw54xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6x.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
^ permalink raw reply
* [PATCH 3/3] arm: dts: Add Siemens am335x-dxr2-e.dts
From: Stefan Roese @ 2014-02-05 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391602361-2666-1-git-send-email-sr@denx.de>
Add support for the Siemens DXR2 board. The DXR2-E is the first one
that is pushed now. It uses the Draco SOM and therefor includes this
dtsi file for the common device nodes.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Lukas Stockmann <lukas.stockmann@siemens.com>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am335x-dxr2-e.dts | 242 ++++++++++++++++++++++++++++++++++++
1 file changed, 242 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-dxr2-e.dts
diff --git a/arch/arm/boot/dts/am335x-dxr2-e.dts b/arch/arm/boot/dts/am335x-dxr2-e.dts
new file mode 100644
index 0000000..5fef637
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-dxr2-e.dts
@@ -0,0 +1,242 @@
+/*
+ * Support for Siemens DXR2.E board
+ *
+ * Copyright (C) 2013,2014 - Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include "am335x-draco.dtsi"
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Siemens DXR2.E";
+ compatible = "siemens,dxr2", "ti,am33xx";
+
+ /* ethernet alias is needed for the MAC address passing from U-Boot */
+ aliases {
+ ethernet0 = &cpsw_emac0;
+ mdio-gpio0 = &mdio0;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ button0 {
+ label = "button0";
+ gpios = <&gpio0 27 0>;
+ linux,code = <KEY_F1>; /* button0 */
+ };
+ };
+
+ am33xx_pinmux: pinmux at 44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_mux_pins>;
+
+ gpio_mux_pins: gpio_mux_pins {
+ pinctrl-single,pins = <
+ 0x020 (PIN_OUTPUT | MUX_MODE4) /* GPMC_AD8, sinus inverter */
+ 0x024 (PIN_OUTPUT | MUX_MODE4) /* GPMC_AD9, sinus inverter */
+ 0x028 (PIN_INPUT | MUX_MODE4) /* GPMC_AD10, sinus inverter */
+ 0x02c (PIN_INPUT | MUX_MODE7) /* GPMC_AD11, button */
+ 0x030 (PIN_OUTPUT | MUX_MODE7) /* GPMC_AD12, UI */
+ 0x034 (PIN_OUTPUT | MUX_MODE7) /* GPMC_AD13, UI */
+ 0x038 (PIN_OUTPUT | MUX_MODE7) /* conf_gpmc_ad14, relay0 */
+ 0x03c (PIN_OUTPUT | MUX_MODE7) /* GPMC_AD15, UI */
+ 0x08c (PIN_OUTPUT | MUX_MODE7) /* GPMC_CLK, UI */
+ 0x0d4 (PIN_OUTPUT | MUX_MODE7) /* LCD_DATA13, AO_EN */
+ 0x0dc (PIN_OUTPUT | MUX_MODE7) /* LCD_DATA15, UI */
+ 0x0ec (PIN_INPUT | MUX_MODE7) /* LCD_AC_BIAS_EN, PWfail */
+ 0x0f0 (PIN_OUTPUT | MUX_MODE7) /* MMC0_DAT3, UI */
+ 0x0f4 (PIN_OUTPUT | MUX_MODE7) /* MMC0_DAT2, UI */
+ 0x0f8 (PIN_OUTPUT | MUX_MODE7) /* MMC0_DAT1, UI */
+ 0x0fc (PIN_OUTPUT | MUX_MODE7) /* MMC0_DAT0, UI */
+ 0x108 (PIN_OUTPUT | MUX_MODE7) /* MII1_COL, relay1 */
+ 0x100 (PIN_OUTPUT | MUX_MODE7) /* MMC0_CLK, UI */
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* MII1_RX_DV.gpio3.4, di0 */
+ 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* MII1_TXD2.gpio0.17, di1 */
+ 0x12c (PIN_OUTPUT | MUX_MODE1) /* MII1_TXCLK, MSTP RX2 */
+ 0x164 (PIN_OUTPUT | MUX_MODE7) /* ECAP0_IN_PWM0_OUT, relay2 */
+ 0x168 (PIN_INPUT | MUX_MODE1) /* MII1_RXCLK, tpuart RX4 */
+ 0x16c (PIN_OUTPUT | MUX_MODE1) /* LCD_DATA9, tpuart TX4 */
+ 0x178 (PIN_OUTPUT | MUX_MODE7) /* UART1_CTS, UI */
+ 0x1b0 (PIN_OUTPUT | MUX_MODE7) /* XDMA_EVENT_INTR0, KNX Power */
+ 0x1d0 (PIN_INPUT | MUX_MODE0) /* tms jtag */
+ 0x1d4 (PIN_INPUT | MUX_MODE0) /* tdi jtag */
+ 0x1d8 (PIN_OUTPUT | MUX_MODE0) /* tdo jtag */
+ 0x1dc (PIN_INPUT | MUX_MODE0) /* tck jtag */
+ 0x1e0 (PIN_INPUT | MUX_MODE0) /* trstn jtag */
+ >;
+ };
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins = <
+ 0x88 (PIN_INPUT | MUX_MODE7) /* gpmc_csn3.gpio2_0 */
+ 0x1e4 (PIN_INPUT | MUX_MODE7) /* emu0.gpio3_7 */
+ >;
+ };
+
+ epwmss0_pins: epwmss0_pins {
+ pinctrl-single,pins = <
+ 0x150 (PIN_OUTPUT | MUX_MODE3) /* conf_spi0_sclk.ehrpwm0A */
+ 0x154 (PIN_OUTPUT | MUX_MODE3) /* conf_spi0_d0.ehrpwm0B */
+ >;
+ };
+
+ epwmss1_pins: epwmss1_pins {
+ pinctrl-single,pins = <
+ 0x0c8 (PIN_OUTPUT | MUX_MODE2) /* lcd_data10.lcd_data10 */
+ 0x0cc (PIN_OUTPUT | MUX_MODE2) /* lcd_data11.lcd_data11 */
+ >;
+ };
+
+ ecap1_pins: ecap1_pins {
+ pinctrl-single,pins = <
+ 0x160 (PIN_OUTPUT | MUX_MODE2) /* conf_spi0_cs1*/
+ >;
+ };
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins = <
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* mii1_crs.rmii1_crs_dv */
+ 0x114 (PIN_OUTPUT | MUX_MODE1) /* mii1_txen.mii1_txen */
+ 0x124 (PIN_OUTPUT | MUX_MODE1) /* mii1_txd1.mii1_txd1 */
+ 0x128 (PIN_OUTPUT | MUX_MODE1) /* mii1_txd0.mii1_txd0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* mii1_rxd1.mii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /* mii1_rxd0.mii1_rxd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* rmii1_refclk.rmii1_refclk */
+ >;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins = <
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ >;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins = <
+ /* MDIO */
+ 0x148 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE0) /* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT | MUX_MODE0) /* mdio_clk.mdio_clk */
+ >;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins = <
+ /* MDIO reset value */
+ 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ >;
+ };
+
+ gpio_mdio_default: gpio_mdio_default {
+ pinctrl-single,pins = <
+ /* MDIO via GPIO */
+ 0x148 (PIN_INPUT | MUX_MODE7) /* mdio_data.mdio_data GPIO0_0 */
+ 0x14c (PIN_OUTPUT | MUX_MODE7) /* mdio_clk.mdio_clk GPIO0_1 */
+ >;
+ };
+ };
+
+ ocp {
+ epwmss0: epwmss at 48300000 {
+ status = "okay";
+ compatible = "ti,am33xx-pwmss";
+
+ ehrpwm0: ehrpwm at 48300200 {
+ compatible = "ti,am33xx-ehrpwm";
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&epwmss0_pins>;
+ };
+ };
+
+ epwmss1: epwmss at 48302000 {
+ status = "okay";
+ compatible = "ti,am33xx-pwmss";
+
+ ecap1: ecap at 48302100 {
+ compatible = "ti,am33xx-ecap";
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap1_pins>;
+ };
+
+ ehrpwm1: ehrpwm at 48302200 {
+ compatible = "ti,am33xx-ehrpwm";
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&epwmss1_pins>;
+ };
+ };
+ };
+
+ leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+ compatible = "gpio-leds";
+
+ led at 0 {
+ label = "led0";
+ gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led at 1 {
+ label = "led1";
+ gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+};
+
+&mac {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&cpsw_default>;
+ pinctrl-1 = <&cpsw_sleep>;
+ slaves = <1>; /* use only one emac if */
+
+ mdio0: gpio {
+ compatible = "virtual,mdio-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_mdio_default>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = <&gpio0 1 GPIO_ACTIVE_HIGH /* MDIO-CLK */
+ &gpio0 0 GPIO_ACTIVE_HIGH>; /* MDIO-DATA */
+
+ phy0: ethernet-phy at 1 {
+ reg = <0>;
+ };
+ };
+};
+
+/* Disable davinci/am335x mdio interface on this platform */
+&davinci_mdio {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&davinci_mdio_default>;
+ pinctrl-1 = <&davinci_mdio_sleep>;
+ status = "disabled";
+};
+
+&cpsw_emac0 {
+ phy_id = <&mdio0>, <0>;
+ phy-mode = "rmii";
+};
+
+&phy_sel {
+ rmii-clock-ext;
+};
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/3] arm: dts: Add Siemens Draco SOM dtsi
From: Stefan Roese @ 2014-02-05 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391602361-2666-1-git-send-email-sr@denx.de>
This patch adds support for the Siemens Draco SOM (System On Module) which
is used by multiple Siemens boards. Support for one is posted in this
series as well, the dxr2-e.
This SOM is based on the TI AM3352 with the following configuration:
- CPU: AM3352BZCEA30
- RAM: 128MB DDR3 at 303MHz
- NAND FLASH: 256MB
- RTC: disabled via hw wiring (registers not available!)
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Lukas Stockmann <lukas.stockmann@siemens.com>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am335x-draco.dtsi | 163 ++++++++++++++++++++++++++++++++++++
1 file changed, 163 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-draco.dtsi
diff --git a/arch/arm/boot/dts/am335x-draco.dtsi b/arch/arm/boot/dts/am335x-draco.dtsi
new file mode 100644
index 0000000..88b414a
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-draco.dtsi
@@ -0,0 +1,163 @@
+/*
+ * Common support for Siemens Draco SOM (AM335x based)
+ *
+ * Copyright (C) 2013,2014 - Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x08000000>; /* 128 MB */
+ };
+
+ am33xx_pinmux: pinmux at 44e10800 {
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins = <
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ >;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins = <
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */
+ >;
+ };
+
+ nandflash_pins: nandflash_pins {
+ pinctrl-single,pins = <
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /* gpmc_wpn.gpio0_30 */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /* gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
+ };
+
+ ocp {
+ uart0: serial at 44e09000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+ };
+
+ i2c0: i2c at 44e0b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ eeprom: eeprom at 50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ pagesize = <64>;
+ };
+ };
+
+ musb: usb at 47400000 {
+ status = "okay";
+
+ control at 44e10000 {
+ status = "okay";
+ };
+
+ usb-phy at 47401300 {
+ status = "okay";
+ };
+
+ usb-phy at 47401b00 {
+ status = "okay";
+ };
+
+ usb at 47401000 {
+ status = "okay";
+ };
+
+ usb at 47401800 {
+ status = "okay";
+ dr_mode = "host";
+ };
+
+ dma-controller at 07402000 {
+ status = "okay";
+ };
+ };
+ };
+};
+
+&timer3 {
+ status = "disabled";
+};
+
+&uart4 {
+ status = "disabled";
+};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nandflash_pins>;
+
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+
+ nand at 0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ nand-bus-width = <8>;
+ ti,nand-ecc-opt = "bch8";
+ gpmc,device-nand = "true";
+ gpmc,device-width = <1>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-on-ns = <0>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ elm_id = <&elm>;
+ };
+};
+
+/* disable the RTC node as its not accessible on the draco/dxr2 board */
+&rtc {
+ status = "disabled";
+ ti,hwmods = "disabled";
+};
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/3] arm: dts: am33xx.dtsi: Add node name to rtc device node
From: Stefan Roese @ 2014-02-05 12:12 UTC (permalink / raw)
To: linux-arm-kernel
Making it possible to reference and therefor change (disable) this
device node from other dts file which import this dtsi file.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Lukas Stockmann <lukas.stockmann@siemens.com>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am33xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..b8daf8c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -399,7 +399,7 @@
ti,timer-pwm;
};
- rtc at 44e3e000 {
+ rtc: rtc at 44e3e000 {
compatible = "ti,da830-rtc";
reg = <0x44e3e000 0x1000>;
interrupts = <75
--
1.8.5.3
^ permalink raw reply related
* [PATCH v4] of: add functions to count number of elements in a property
From: Grant Likely @ 2014-02-05 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13514940.URVnEJ4NF0@phil>
On Tue, 04 Feb 2014 19:48:17 +0100, Heiko St??bner <heiko@sntech.de> wrote:
> Hi Grant,
>
> On Tuesday, 4. February 2014 17:30:34 Grant Likely wrote:
> > On Sat, 18 Jan 2014 09:07:30 -0600, Rob Herring <robherring2@gmail.com>
> wrote:
> > > On Sat, Jan 18, 2014 at 6:02 AM, Heiko St????bner <heiko@sntech.de> wrote:
> > > > The need to know the number of array elements in a property is
> > > > a common pattern. To prevent duplication of open-coded implementations
> > > > add a helper static function that also centralises strict sanity
> > > > checking and DTB format details, as well as a set of wrapper functions
> > > > for u8, u16, u32 and u64.
> > > >
> > > > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > > ---
> > >
> > > Looks good. Do you plan to convert some users to use this?
> >
> > I'll take that as an acked-by. Merged, thanks.
>
> before you taking this patch, I was planning on simply sending this as part of
> my rockchip-smp series - as I'm currently the only user of it :-) .
>
> This going through your tree is most likely the better way, but now I need it
> to somehow make its way into arm-soc too ... I guess some sort of stable
> branch arm-soc could pull?
Nah, I'll drop it from my tree. Add my acked-by and merge it via
arm-soc.
g.
^ permalink raw reply
* [PATCH 1/2] clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
From: Ben Dooks @ 2014-02-05 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4232876.LkjsLLbJbc@avalon>
On 05/02/14 10:51, Laurent Pinchart wrote:
> Hi Ben,
>
> On Wednesday 05 February 2014 10:34:49 Ben Dooks wrote:
>> On 07/01/14 16:47, Laurent Pinchart wrote:
>>> The lb, qspi, sdh, sd0 and sd1 clocks have the PLL1 (divided by 2) as
>>> their parent, not the main clock. Fix it.
>>
>> William Towle has already sent a patch to move this to device tree
>> which I think is a better solution for this.
>
> I actually disagree. The CPG is an IP core that generates a bunch of clocks
> from a single external parent. The fact that clocks are not flat but organized
> as a tree internally is an internal property of the CPG, and I prefer keeping
> it that way instead of exposing it in the device tree.
If you feel that the block is unlikely to change if it gets
re-used then that'll be fine. We can always revisit the changes
if needed.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH v7 2/7] dt-bindings: sram: describe option to reserve parts of the memory
From: Heiko Stübner @ 2014-02-05 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205111247.476B7C40A89@trevor.secretlab.ca>
Am Mittwoch, 5. Februar 2014, 11:12:47 schrieb Grant Likely:
> On Mon, 20 Jan 2014 16:42:58 +0100, Heiko St??bner <heiko@sntech.de> wrote:
> > Some SoCs need parts of their sram for special purposes. So while being
> > part of the peripheral, it should not be part of the genpool controlling
> > the sram.
> >
> > Therefore add an option mmio-sram-reserved to keep arbitrary portions of
> > the sram from general usage.
> >
> > Suggested-by: Rob Herring <robherring2@gmail.com>
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> >
> > Documentation/devicetree/bindings/misc/sram.txt | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/sram.txt
> > b/Documentation/devicetree/bindings/misc/sram.txt index 4d0a00e..09ee7a3
> > 100644
> > --- a/Documentation/devicetree/bindings/misc/sram.txt
> > +++ b/Documentation/devicetree/bindings/misc/sram.txt
> >
> > @@ -8,9 +8,17 @@ Required properties:
> > - reg : SRAM iomem address range
> >
> > +Optional properties:
> > +
> > +- mmio-sram-reserved: ordered list of reserved chunks inside the sram
> > that
> > + should not be used by the operating system.
> > + Format is <base size>, <base size>, ...; with base being relative to
> > the
> > + reg property base.
> > +
>
> We've now got a draft binding for reserved memory. Can you use the format
> here? Basically each reserved region is a sub node with either a reg
> property or a size property.
>
> This is specifically for sram, so I won't make a big deal about it, but
> it would be good to have some commonality.
I guess you're talking about "[PATCH v2 0/5] reserved-memory regions/CMA in
devicetree, again", right?
In general I'm all for commonality :-). So I guess you mean it to look
something like the following:
sram: sram at 10080000 {
compatible = "rockchip,rk3066-sram", "mmio-sram";
reg = <0x10080000 0x8000>;
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
smp at 200 {
/* hmm, relative or absolute, aka 0x200 or 0x10080200? */
reg = <0x200 0x50>;
};
};
};
As it looks like only a slight modification of my "parsing" code this should be
doable. Do you suggest more changes to the example above?
Heiko
^ permalink raw reply
* [PATCH 1/3] clk: rcar-h2: fix sd0/sd1 divisor table
From: Ben Dooks @ 2014-02-05 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2083213.7oCTVAqWbC@avalon>
On 05/02/14 10:56, Laurent Pinchart wrote:
> Hi William,
>
> Thank you for the patch.
>
> On Tuesday 04 February 2014 18:17:36 William Towle wrote:
>> The clk_div_table for cpg_sd01_div_table[] concurs with the manual
>> but not with values found in the device itself (which are also the
>> same as the ones in arch/arm/mach-shmobile/clock-r8a7790.c).
>>
>> Update the clk-rcar-gen2.c driver to have the same table as the one
>> used by the mach-shmobile driver which work once further issues are
>> fixed in the clk-rcar-gen2.c driver.
>>
>> Part of the fix for the following error where the driver reports the
>> output as 1MHz but is really 97.5MHz:
>> sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
>>
>> [ben.dooks at codethink.co.uk: updated patch description]
>> Signed-off-by: William Towle <william.towle@codethink.co.uk>
>> Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>> drivers/clk/shmobile/clk-rcar-gen2.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c
>> b/drivers/clk/shmobile/clk-rcar-gen2.c index a59ec21..df4a1e6 100644
>> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
>> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
>> @@ -170,6 +170,8 @@ static const struct clk_div_table cpg_sdh_div_table[] =
>> { };
>>
>> static const struct clk_div_table cpg_sd01_div_table[] = {
>> + { 0, 2 }, { 1, 3 }, { 2, 4 }, { 3, 6 },
>> + { 4, 8 },
>> { 5, 12 }, { 6, 16 }, { 7, 18 }, { 8, 24 },
>> { 10, 36 }, { 11, 48 }, { 12, 10 }, { 0, 0 },
>
> With this applied the only difference between the sdh and sd0/1 dividers
> tables would be the { 12, 10 } entry, available for sd0/1 only. Given that the
> hardware does not match the documentation, could you check whether that entry
> is supported by sdh as well ? If so we could merge the two tables. Otherwise
> this patch looks good, could you please just reformat the table to avoid the
> mostly empty line in the middle ?
I would like feedback from Renesas on this issue if possible. I can
have a quick try at setting the clock value to 10 in u-boot and scope
it out and see what happens.
Magnus or Morimoto-san, is there a chance this could be reviewed by
someone in Renesas who has knowledge of the hardware block?
[PS, added Kuninori Morimoto to this[
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH v2 1/2] arm64: vdso: fix coarse clock handling
From: Catalin Marinas @ 2014-02-05 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205100945.GA28623@mudshark.cambridge.arm.com>
On Wed, Feb 05, 2014 at 10:09:45AM +0000, Will Deacon wrote:
> On Wed, Feb 05, 2014 at 05:53:04AM +0000, Nathan Lynch wrote:
> > When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
> > CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
> > caller has placed in x2 ("ret x2" to return from the fast path). Fix
> > this by saving x30/LR to x2 only in code that will call
> > __do_get_tspec, restoring x30 afterward, and using a plain "ret" to
> > return from the routine.
> >
> > Also: while the resulting tv_nsec value for CLOCK_REALTIME and
> > CLOCK_MONOTONIC must be computed using intermediate values that are
> > left-shifted by cs_shift (x12, set by __do_get_tspec), the results for
> > coarse clocks should be calculated using unshifted values
> > (xtime_coarse_nsec is in units of actual nanoseconds). The current
> > code shifts intermediate values by x12 unconditionally, but x12 is
> > uninitialized when servicing a coarse clock. Fix this by setting x12
> > to 0 once we know we are dealing with a coarse clock id.
> >
> > Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
> > ---
>
> Thanks for the quick update Nathan!
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Catalin: both of these are candidates for stable.
And by this you mean Cc: stable...
Applied, thanks.
--
Catalin
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Russell King - ARM Linux @ 2014-02-05 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391531796.2538.21.camel@joe-AO722>
On Tue, Feb 04, 2014 at 08:36:36AM -0800, Joe Perches wrote:
> On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:
> > Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
> > cannot handle large values because of lost-of-precision.
> >
> > IMHO udelay on ARM is broken, because it also cannot work with fast
> > ARM processors (where bogomips >= 3355, which is in sight now). It's
> > just not broken enought that someone did something against it ... so
> > the current kludge is good enought.
>
> Maybe something like this would be better?
No, the point of __bad_udelay() is that people doing stupidly large
udelay()s result in build errors, rather than having to run the kernel
and trip over a non-existent debugging message beacuse they haven't
built the kernel with DEBUG defined.
NAK.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
From: Catalin Marinas @ 2014-02-05 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391480133-27149-1-git-send-email-ccross@android.com>
On Tue, Feb 04, 2014 at 02:15:32AM +0000, Colin Cross wrote:
> Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
> selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to
> prevent selinux failures launching 32-bit static executables that
> are mapped at 0x8000.
>
> Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 1/4] ARM: STi: add stid127 soc support
From: srinivas kandagatla @ 2014-02-05 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401312115.33731.arnd@arndb.de>
Hi Arnd,
On 31/01/14 20:15, Arnd Bergmann wrote:
> On Friday 31 January 2014, srinivas kandagatla wrote:
>
>>> Sorry if I missed the initial review, but can you explain
>>> why this is needed to start with?
>>
>> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we set
>> the way-size explicit here.
>
> Unfortunately, we keep going back and forth on the L2 cache controller
> setup between "it should work automatically" and "we don't want to
> have configuration data in DT", where my personal opinion is that
> the first one is more important here.
>
> Now, there are a couple of properties that are defined in
> Documentation/devicetree/bindings/arm/l2cc.txt to let some of the
> things get set up automatically already. Can you check which bits
> are missing there, if any? Are they better described as "configuration"
> or "hardware" settings?
Currently l2cc bindings has few optional properties like.
- arm,data-latency
- arm,tag-latency
- arm,dirty-latency
- arm,filter-ranges
- interrupts :
- cache-id-part:
- wt-override:
These does not include properties to set "way-size", "associativity",
"enabling prefetching", "Prefetch drop enable", "prefetch offset",
"Double linefill" and few more in prefect control register and
aux-control register.
This is not just a issue with STi SOCs, having a quick look, I can see
that few more SOCs have similar requirements to set these properties.
We could do two things to get l2 setup automatically on STi SOCS.
1> Either define these properties case-by-case basic, which might be
useful for other SOCs too.
2> Or Add new compatible string for STi SoCs so that they can
automatically setup these values in cache-l2x0.c
Am Ok with either approaches.
Thanks,
srini
>
> Arnd
>
>
^ permalink raw reply
* [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Lukasz Majewski @ 2014-02-05 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9agAQRK8NjkYU7Pr-z2AxyUoD7+NH+Y+6Ar9eCi_tbatgQ@mail.gmail.com>
Hi Thomas,
Fist of all, thanks for your patches.
> Hi Lukasz,
>
> On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski
> <l.majewski@samsung.com> wrote:
> > Hi Thomas,
> >
> >> From: Thomas Abraham <thomas.ab@samsung.com>
> >>
> >> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched
> >> over to use cpufreq-cpu0 driver for cpufreq functionality. So the
> >> Exynos specific cpufreq drivers for these platforms can be removed.
> >>
>
> <snip>
>
> >> -static unsigned int exynos4x12_volt_table[] = {
> >> - 1350000, 1287500, 1250000, 1187500, 1137500, 1087500,
> >> 1037500,
> >> - 1000000, 987500, 975000, 950000, 925000, 900000, 900000
> >> -};
> >> -
> >> -static struct cpufreq_frequency_table exynos4x12_freq_table[] = {
> >> - {CPUFREQ_BOOST_FREQ, 1500 * 1000},
> >
> > Here, you are removing BOOST support for Exynos4412, without any
> > code, which brings back this functionality in the new code.
> >
> > I'd propose adding new property to cpus node and during
> > operating-points parsing mark the entry at the
> > cpufreq_frequency_table accordingly.
>
> I tried doing this as you suggested with [1] but looks like that will
> not go through at this point.
I've read your patches regarding OPP. In my opinion, despite the problem
with further OPP format discussion (which is ongoing and probably will
take some time), there is a palatable solution (presented below).
> The other alternative would be to use
> exynos specific cpufreq drivers only if multiplatform config is not
> selected or use cpufreq-cpu0 if multiplatform config is selected (but
> this is not something I would want to do). With this, there are issues
> like clock blocks encapsulated within the opaque clock type cannot be
> removed since exynos specific cpufreq drivers need it and hence it is
> not really a clean solution.
It would be a maintenance nightmare. We cannot afford to do such huge
cleanup only partially. The rationale for the whole clean up is to
remove exynosXXXX-cpufreq.c files.
I also share your doubts here. We shall NOT do it this way.
>The other option is to drop the support
> for boost on exynos4x12 for now and reintroduce that when the OPP
> bindings have been finalized.
So you want to drop the BOOST kernel functionality just because you are
doing clean up and this feature is problematic to provide at new
approach?
> Would that be okay?
It is NOT acceptable. Sorry, but NAK.
> Any other
> suggestions will also be helpful.
For me it would be perfectly fine to see at device tree CPU0 node code
proposed by Nishanth:
operating-points = < Fa Va
Fb Vb
Fc Vc
Fd Vd
>;
boost-frequencies = <Fc Fd>;
And then the cpufreq table could be properly modified by marking
relevant frequencies as CPUFREQ_BOOST_FREQ.
>
> Thanks,
> Thomas.
>
> >
> >> - {L1, 1400 * 1000},
> >> - {L2, 1300 * 1000},
> >> - {L3, 1200 * 1000},
> >> - {L4, 1100 * 1000},
> >> - {L5, 1000 * 1000},
> >> - {L6, 900 * 1000},
> >> - {L7, 800 * 1000},
> >> - {L8, 700 * 1000},
> >> - {L9, 600 * 1000},
> >> - {L10, 500 * 1000},
> >> - {L11, 400 * 1000},
> >> - {L12, 300 * 1000},
> >> - {L13, 200 * 1000},
> >> - {0, CPUFREQ_TABLE_END},
> >> -};
> >> -
> >> -static struct apll_freq *apll_freq_4x12;
> >> -
> >> -static struct apll_freq apll_freq_4212[] = {
> >> - /*
> >> - * values:
> >> - * freq
> >> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
> >> PCLK_DBG, APLL, CORE2
> >> - * clock divider for COPY, HPM, RESERVED
> >> - * PLL M, P, S
> >> - */
> >> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 250, 4, 0),
> >> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 175, 3, 0),
> >> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 325, 6, 0),
> >> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 200, 4, 0),
> >> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 2, 0, 275, 6, 0),
> >> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 2, 0, 125, 3, 0),
> >> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 150, 4, 0),
> >> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 0),
> >> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 175, 3, 1),
> >> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 200, 4, 1),
> >> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 125, 3, 1),
> >> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 1),
> >> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 2, 0, 200, 4, 2),
> >> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 2, 0, 100, 3, 2),
> >> -};
> >> -
> >> -static struct apll_freq apll_freq_4412[] = {
> >> - /*
> >> - * values:
> >> - * freq
> >> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
> >> PCLK_DBG, APLL, CORE2
> >> - * clock divider for COPY, HPM, CORES
> >> - * PLL M, P, S
> >> - */
> >> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 7, 250, 4, 0),
> >> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 6, 175, 3, 0),
> >> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 6, 325, 6, 0),
> >> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 5, 200, 4, 0),
> >> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 0, 5, 275, 6, 0),
> >> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 0, 4, 125, 3, 0),
> >> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 4, 150, 4, 0),
> >> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 3, 100, 3, 0),
> >> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 3, 175, 3, 1),
> >> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 200, 4, 1),
> >> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 125, 3, 1),
> >> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 1, 100, 3, 1),
> >> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 0, 1, 200, 4, 2),
> >> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 0, 0, 100, 3, 2),
> >> -};
> >> -
> >> -static void exynos4x12_set_clkdiv(unsigned int div_index)
> >> -{
> >> - unsigned int tmp;
> >> - unsigned int stat_cpu1;
> >> -
> >> - /* Change Divider - CPU0 */
> >> -
> >> - tmp = apll_freq_4x12[div_index].clk_div_cpu0;
> >> -
> >> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU);
> >> -
> >> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU) & 0x11111111)
> >> - cpu_relax();
> >> -
> >> - /* Change Divider - CPU1 */
> >> - tmp = apll_freq_4x12[div_index].clk_div_cpu1;
> >> -
> >> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU1);
> >> - if (soc_is_exynos4212())
> >> - stat_cpu1 = 0x11;
> >> - else
> >> - stat_cpu1 = 0x111;
> >> -
> >> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU1) & stat_cpu1)
> >> - cpu_relax();
> >> -}
> >> -
> >> -static void exynos4x12_set_apll(unsigned int index)
> >> -{
> >> - unsigned int tmp, freq = apll_freq_4x12[index].freq;
> >> -
> >> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
> >> - clk_set_parent(moutcore, mout_mpll);
> >> -
> >> - do {
> >> - cpu_relax();
> >> - tmp = (__raw_readl(EXYNOS4_CLKMUX_STATCPU)
> >> - >> EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT);
> >> - tmp &= 0x7;
> >> - } while (tmp != 0x2);
> >> -
> >> - clk_set_rate(mout_apll, freq * 1000);
> >> -
> >> - /* MUX_CORE_SEL = APLL */
> >> - clk_set_parent(moutcore, mout_apll);
> >> -
> >> - do {
> >> - cpu_relax();
> >> - tmp = __raw_readl(EXYNOS4_CLKMUX_STATCPU);
> >> - tmp &= EXYNOS4_CLKMUX_STATCPU_MUXCORE_MASK;
> >> - } while (tmp != (0x1 << EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
> >> -}
> >> -
> >> -static void exynos4x12_set_frequency(unsigned int old_index,
> >> - unsigned int new_index)
> >> -{
> >> - if (old_index > new_index) {
> >> - exynos4x12_set_clkdiv(new_index);
> >> - exynos4x12_set_apll(new_index);
> >> - } else if (old_index < new_index) {
> >> - exynos4x12_set_apll(new_index);
> >> - exynos4x12_set_clkdiv(new_index);
> >> - }
> >> -}
> >> -
> >> -int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
> >> -{
> >> - unsigned long rate;
> >> -
> >> - cpu_clk = clk_get(NULL, "armclk");
> >> - if (IS_ERR(cpu_clk))
> >> - return PTR_ERR(cpu_clk);
> >> -
> >> - moutcore = clk_get(NULL, "moutcore");
> >> - if (IS_ERR(moutcore))
> >> - goto err_moutcore;
> >> -
> >> - mout_mpll = clk_get(NULL, "mout_mpll");
> >> - if (IS_ERR(mout_mpll))
> >> - goto err_mout_mpll;
> >> -
> >> - rate = clk_get_rate(mout_mpll) / 1000;
> >> -
> >> - mout_apll = clk_get(NULL, "mout_apll");
> >> - if (IS_ERR(mout_apll))
> >> - goto err_mout_apll;
> >> -
> >> - if (soc_is_exynos4212())
> >> - apll_freq_4x12 = apll_freq_4212;
> >> - else
> >> - apll_freq_4x12 = apll_freq_4412;
> >> -
> >> - info->mpll_freq_khz = rate;
> >> - /* 800Mhz */
> >> - info->pll_safe_idx = L7;
> >> - info->cpu_clk = cpu_clk;
> >> - info->volt_table = exynos4x12_volt_table;
> >> - info->freq_table = exynos4x12_freq_table;
> >> - info->set_freq = exynos4x12_set_frequency;
> >> -
> >> - return 0;
> >> -
> >> -err_mout_apll:
> >> - clk_put(mout_mpll);
> >> -err_mout_mpll:
> >> - clk_put(moutcore);
> >> -err_moutcore:
> >> - clk_put(cpu_clk);
> >> -
> >> - pr_debug("%s: failed initialization\n", __func__);
> >> - return -EINVAL;
> >> -}
> >> diff --git a/drivers/cpufreq/exynos5250-cpufreq.c
> >> b/drivers/cpufreq/exynos5250-cpufreq.c deleted file mode 100644
> >> index 5f90b82..0000000
> >> --- a/drivers/cpufreq/exynos5250-cpufreq.c
> >> +++ /dev/null
> >> @@ -1,183 +0,0 @@
> >> -/*
> >> - * Copyright (c) 2010-20122Samsung Electronics Co., Ltd.
> >> - * http://www.samsung.com
> >> - *
> >> - * EXYNOS5250 - CPU frequency scaling support
> >> - *
> >> - * This program is free software; you can redistribute it and/or
> >> modify
> >> - * it under the terms of the GNU General Public License version 2
> >> as
> >> - * published by the Free Software Foundation.
> >> -*/
> >> -
> >> -#include <linux/module.h>
> >> -#include <linux/kernel.h>
> >> -#include <linux/err.h>
> >> -#include <linux/clk.h>
> >> -#include <linux/io.h>
> >> -#include <linux/slab.h>
> >> -#include <linux/cpufreq.h>
> >> -
> >> -#include <mach/map.h>
> >> -
> >> -#include "exynos-cpufreq.h"
> >> -
> >> -static struct clk *cpu_clk;
> >> -static struct clk *moutcore;
> >> -static struct clk *mout_mpll;
> >> -static struct clk *mout_apll;
> >> -
> >> -static unsigned int exynos5250_volt_table[] = {
> >> - 1300000, 1250000, 1225000, 1200000, 1150000,
> >> - 1125000, 1100000, 1075000, 1050000, 1025000,
> >> - 1012500, 1000000, 975000, 950000, 937500,
> >> - 925000
> >> -};
> >> -
> >> -static struct cpufreq_frequency_table exynos5250_freq_table[] = {
> >> - {L0, 1700 * 1000},
> >> - {L1, 1600 * 1000},
> >> - {L2, 1500 * 1000},
> >> - {L3, 1400 * 1000},
> >> - {L4, 1300 * 1000},
> >> - {L5, 1200 * 1000},
> >> - {L6, 1100 * 1000},
> >> - {L7, 1000 * 1000},
> >> - {L8, 900 * 1000},
> >> - {L9, 800 * 1000},
> >> - {L10, 700 * 1000},
> >> - {L11, 600 * 1000},
> >> - {L12, 500 * 1000},
> >> - {L13, 400 * 1000},
> >> - {L14, 300 * 1000},
> >> - {L15, 200 * 1000},
> >> - {0, CPUFREQ_TABLE_END},
> >> -};
> >> -
> >> -static struct apll_freq apll_freq_5250[] = {
> >> - /*
> >> - * values:
> >> - * freq
> >> - * clock divider for ARM, CPUD, ACP, PERIPH, ATB, PCLK_DBG,
> >> APLL, ARM2
> >> - * clock divider for COPY, HPM, RESERVED
> >> - * PLL M, P, S
> >> - */
> >> - APLL_FREQ(1700, 0, 3, 7, 7, 7, 3, 5, 0, 0, 2, 0, 425, 6, 0),
> >> - APLL_FREQ(1600, 0, 3, 7, 7, 7, 1, 4, 0, 0, 2, 0, 200, 3, 0),
> >> - APLL_FREQ(1500, 0, 2, 7, 7, 7, 1, 4, 0, 0, 2, 0, 250, 4, 0),
> >> - APLL_FREQ(1400, 0, 2, 7, 7, 6, 1, 4, 0, 0, 2, 0, 175, 3, 0),
> >> - APLL_FREQ(1300, 0, 2, 7, 7, 6, 1, 3, 0, 0, 2, 0, 325, 6, 0),
> >> - APLL_FREQ(1200, 0, 2, 7, 7, 5, 1, 3, 0, 0, 2, 0, 200, 4, 0),
> >> - APLL_FREQ(1100, 0, 3, 7, 7, 5, 1, 3, 0, 0, 2, 0, 275, 6, 0),
> >> - APLL_FREQ(1000, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 125, 3, 0),
> >> - APLL_FREQ(900, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 150, 4, 0),
> >> - APLL_FREQ(800, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 100, 3, 0),
> >> - APLL_FREQ(700, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 175, 3, 1),
> >> - APLL_FREQ(600, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 200, 4, 1),
> >> - APLL_FREQ(500, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 125, 3, 1),
> >> - APLL_FREQ(400, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 100, 3, 1),
> >> - APLL_FREQ(300, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 200, 4, 2),
> >> - APLL_FREQ(200, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 100, 3, 2),
> >> -};
> >> -
> >> -static void set_clkdiv(unsigned int div_index)
> >> -{
> >> - unsigned int tmp;
> >> -
> >> - /* Change Divider - CPU0 */
> >> -
> >> - tmp = apll_freq_5250[div_index].clk_div_cpu0;
> >> -
> >> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU0);
> >> -
> >> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU0) & 0x11111111)
> >> - cpu_relax();
> >> -
> >> - /* Change Divider - CPU1 */
> >> - tmp = apll_freq_5250[div_index].clk_div_cpu1;
> >> -
> >> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU1);
> >> -
> >> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU1) & 0x11)
> >> - cpu_relax();
> >> -}
> >> -
> >> -static void set_apll(unsigned int index)
> >> -{
> >> - unsigned int tmp;
> >> - unsigned int freq = apll_freq_5250[index].freq;
> >> -
> >> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
> >> - clk_set_parent(moutcore, mout_mpll);
> >> -
> >> - do {
> >> - cpu_relax();
> >> - tmp = (__raw_readl(EXYNOS5_CLKMUX_STATCPU) >> 16);
> >> - tmp &= 0x7;
> >> - } while (tmp != 0x2);
> >> -
> >> - clk_set_rate(mout_apll, freq * 1000);
> >> -
> >> - /* MUX_CORE_SEL = APLL */
> >> - clk_set_parent(moutcore, mout_apll);
> >> -
> >> - do {
> >> - cpu_relax();
> >> - tmp = __raw_readl(EXYNOS5_CLKMUX_STATCPU);
> >> - tmp &= (0x7 << 16);
> >> - } while (tmp != (0x1 << 16));
> >> -}
> >> -
> >> -static void exynos5250_set_frequency(unsigned int old_index,
> >> - unsigned int new_index)
> >> -{
> >> - if (old_index > new_index) {
> >> - set_clkdiv(new_index);
> >> - set_apll(new_index);
> >> - } else if (old_index < new_index) {
> >> - set_apll(new_index);
> >> - set_clkdiv(new_index);
> >> - }
> >> -}
> >> -
> >> -int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
> >> -{
> >> - unsigned long rate;
> >> -
> >> - cpu_clk = clk_get(NULL, "armclk");
> >> - if (IS_ERR(cpu_clk))
> >> - return PTR_ERR(cpu_clk);
> >> -
> >> - moutcore = clk_get(NULL, "mout_cpu");
> >> - if (IS_ERR(moutcore))
> >> - goto err_moutcore;
> >> -
> >> - mout_mpll = clk_get(NULL, "mout_mpll");
> >> - if (IS_ERR(mout_mpll))
> >> - goto err_mout_mpll;
> >> -
> >> - rate = clk_get_rate(mout_mpll) / 1000;
> >> -
> >> - mout_apll = clk_get(NULL, "mout_apll");
> >> - if (IS_ERR(mout_apll))
> >> - goto err_mout_apll;
> >> -
> >> - info->mpll_freq_khz = rate;
> >> - /* 800Mhz */
> >> - info->pll_safe_idx = L9;
> >> - info->cpu_clk = cpu_clk;
> >> - info->volt_table = exynos5250_volt_table;
> >> - info->freq_table = exynos5250_freq_table;
> >> - info->set_freq = exynos5250_set_frequency;
> >> -
> >> - return 0;
> >> -
> >> -err_mout_apll:
> >> - clk_put(mout_mpll);
> >> -err_mout_mpll:
> >> - clk_put(moutcore);
> >> -err_moutcore:
> >> - clk_put(cpu_clk);
> >> -
> >> - pr_err("%s: failed initialization\n", __func__);
> >> - return -EINVAL;
> >> -}
> >
> >
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-02-05 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F2021A.9020804@metafoo.de>
On Wed, Feb 05, 2014 at 10:19:22AM +0100, Lars-Peter Clausen wrote:
> On 02/05/2014 10:11 AM, Jean-Francois Moine wrote:
> >So, in the CODEC, I don't see how I could update the parameters
> >dictated by the EDID otherwise in changing the DAI driver parameters.
> The startup function is the right place. But instead of modifying
> the DAI use snd_pcm_hw_constraint_mask64(),
> snd_pcm_hw_constraint_list(), etc. to setup the additional
> constraints that come from the EDID.
Right.
> Bonus points for making this a generic helper function that takes a
> runtime and a EDID and then applies the EDID constraints on the
> runtime.
...as previously requested. I know there was some discusion of broader
moves to factor this stuff out but it'd still be good to keep it
separated out even prior to a final non-EDID based solution so it's
easier to refactor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/f91a9e51/attachment.sig>
^ permalink raw reply
* [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Grant Likely @ 2014-02-05 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129175331.GA27143@localhost>
On Wed, 29 Jan 2014 14:53:32 -0300, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> wrote:
> On Wed, Jan 29, 2014 at 03:34:13PM +0100, Boris BREZILLON wrote:
> > nand-ecc-level property statically defines NAND chip's ECC requirements.
> >
> > Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
> > ---
> > Documentation/devicetree/bindings/mtd/nand.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> > index 03855c8..0c962296 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> > @@ -3,5 +3,8 @@
> > - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> > Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> > "soft_bch".
> > +- nand-ecc-level : Two cells property defining the ECC level requirements.
> > + The first cell represent the strength and the second cell the ECC block size.
> > + E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
> > - nand-bus-width : 8 or 16 bus width if not present 8
> > - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
>
> Hm.. when was this proposal agreed? It seems I've missed the
> discussion...
>
> FWIW, we've already proposed an equivalent one, but it received no
> feedback from the devicetree maintainers:
Sorry, binding review has become a huge undertaking.
>
> http://comments.gmane.org/gmane.linux.drivers.devicetree/58764
>
> Maybe we can discuss about it now?
>
> nand-ecc-strength : integer ECC required strength.
> nand-ecc-size : integer step size associated to the ECC strength.
I'm okay with either, but the above binding is indeed more readable.
g.
^ 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