* [alsa-devel] [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB
From: Arnd Bergmann @ 2011-10-03 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003143553.GG23811@sirena.org.uk>
On Monday 03 October 2011 15:35:53 Mark Brown wrote:
> On Mon, Oct 03, 2011 at 02:45:27PM +0100, Russell King - ARM Linux wrote:
> > On Sun, Oct 02, 2011 at 09:41:07PM +0100, Mark Brown wrote:
>
> > > No, gpiolib is one implementation of the GPIO API but if platforms want
> > > to go and define their own that's currently OK (personally I think at
> > > this point we should just be converting all the stragglers over to
> > > gpiolib). As things stand we shouldn't have dependencies on a
> > > particular implementation of the API.
>
> > Then it should depend on GENERIC_GPIO (not to be confused with GPIO_GENERIC,
> > the generic gpiolib driver), which is the symbol meaning that the GPIO API
> > is provided by something.
>
> Not for devices like this where the GPIOs are an optional thing the
> driver can use, a dependency is far too strong. Devices like that
> should be able to rely on the stubs.
FWIW, while trying to reproduce this (I still could not), I stumbled over a
different build error with
CONFIG_ARCH_PRIMA2=y
CONFIG_SND_SOC_ALL_CODECS=m
CONFIG_SND_SOC_WM1250_EV1=m
sound/soc/codecs/wm1250-ev1.c:32:14: error: array type has incomplete element type
sound/soc/codecs/wm1250-ev1.c: In function 'wm1250_ev1_pdata':
sound/soc/codecs/wm1250-ev1.c:126:87: error: negative width in bit-field '<anonymous>'
sound/soc/codecs/wm1250-ev1.c:134:111: error: negative width in bit-field '<anonymous>'
sound/soc/codecs/wm1250-ev1.c: In function 'wm1250_ev1_free':
sound/soc/codecs/wm1250-ev1.c:155:103: error: negative width in bit-field '<anonymous>'
Arnd
^ permalink raw reply
* [PATCH v3] ASoC: samsung: wm8994 depends on mfd_wm8994
From: Mark Brown @ 2011-10-03 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1373438.oHCphrxVRr@wuerfel>
On Mon, Oct 03, 2011 at 04:35:46PM +0200, Arnd Bergmann wrote:
> I'm still confused, I thought you had NAKed the patch that selects the
> core because it ignores the dependencies. Here comes another variant,
> this time for your branch, and selecting the MFD driver directly while
> respecting its dependencies.
The problem with that one was that you had the select on the Kconfig for
the CODEC driver rather than on the machine drivers so you ended up with
the select being done from a symbol that is itself selected.
Applied this version, thanks.
^ permalink raw reply
* [alsa-devel] [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB
From: Mark Brown @ 2011-10-03 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003134527.GF11710@n2100.arm.linux.org.uk>
On Mon, Oct 03, 2011 at 02:45:27PM +0100, Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 09:41:07PM +0100, Mark Brown wrote:
> > No, gpiolib is one implementation of the GPIO API but if platforms want
> > to go and define their own that's currently OK (personally I think at
> > this point we should just be converting all the stragglers over to
> > gpiolib). As things stand we shouldn't have dependencies on a
> > particular implementation of the API.
> Then it should depend on GENERIC_GPIO (not to be confused with GPIO_GENERIC,
> the generic gpiolib driver), which is the symbol meaning that the GPIO API
> is provided by something.
Not for devices like this where the GPIOs are an optional thing the
driver can use, a dependency is far too strong. Devices like that
should be able to rely on the stubs.
^ permalink raw reply
* [PATCH v3] ASoC: samsung: wm8994 depends on mfd_wm8994
From: Arnd Bergmann @ 2011-10-03 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003140824.GM3731@opensource.wolfsonmicro.com>
Any driver that selects SND_SOC_WM8994 should also make sure that
MFD_WM8994 is set, since the codec relies on the mfd code:
sound/built-in.o: In function `wm8994_read':
last.c:(.text+0x20160): undefined reference to `wm8994_reg_read'
sound/built-in.o: In function `wm8994_write':
last.c:(.text+0x20e68): undefined reference to `wm8994_reg_write'
This solves the problem by selecting the MFD driver directly
and adding extra 'depends on' statements to make sure that we
respect the dependencies of that driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
On Monday 03 October 2011 15:08:24 Mark Brown wrote:
> On Mon, Oct 03, 2011 at 03:43:10PM +0200, Arnd Bergmann wrote:
>
> > > You've not sent a seprate patch for that one yet...
>
> > I wasn't sure any more which version you wanted. Is this this right one?
>
> I was expecting something that selects the core. I was also expecting
> something that can be applied against -next which this patch can't be,
I'm still confused, I thought you had NAKed the patch that selects the
core because it ignores the dependencies. Here comes another variant,
this time for your branch, and selecting the MFD driver directly while
respecting its dependencies.
> this doesn't feel like something we should be rushing into 3.1.
No, certainly not. This patch by itself helps nobody, the only reason
for doing it is to make randconfig work and that requires lots of
other patches.
Arnd
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -64,6 +64,8 @@ config SND_SOC_SAMSUNG_SMDK_WM8580
config SND_SOC_SAMSUNG_SMDK_WM8994
tristate "SoC I2S Audio support for WM8994 on SMDK"
depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 || MACH_SMDK4212)
+ depends on I2C=y && GENERIC_HARDIRQS
+ select MFD_WM8994
select SND_SOC_WM8994
select SND_SAMSUNG_I2S
help
@@ -150,7 +152,9 @@ config SND_SOC_SMARTQ
config SND_SOC_GONI_AQUILA_WM8994
tristate "SoC I2S Audio support for AQUILA/GONI - WM8994"
depends on SND_SOC_SAMSUNG && (MACH_GONI || MACH_AQUILA)
+ depends on I2C=y && GENERIC_HARDIRQS
select SND_SAMSUNG_I2S
+ select MFD_WM8994
select SND_SOC_WM8994
help
Say Y if you want to add support for SoC audio on goni or aquila
@@ -174,6 +178,8 @@ config SND_SOC_SMDK_WM8580_PCM
config SND_SOC_SMDK_WM8994_PCM
tristate "SoC PCM Audio support for WM8994 on SMDK"
depends on SND_SOC_SAMSUNG && (MACH_SMDKC210 || MACH_SMDKV310 || MACH_SMDK4212)
+ depends on I2C=y && GENERIC_HARDIRQS
+ select MFD_WM8994
select SND_SOC_WM8994
select SND_SAMSUNG_PCM
help
^ permalink raw reply
* [PATCH v16 00/12] OMAP: dmtimer: adaptation to platform_driver
From: Cousson, Benoit @ 2011-10-03 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316518227-28116-1-git-send-email-tarun.kanti@ti.com>
+ Arnd
Hi Tony,
After rebasing by DT series on top of your dt-base, I noticed two minor
issues from this timer series.
First some new warnings:
[ 0.260009] omap_timer.1: alias fck already exists
[ 0.260345] omap_timer.2: alias fck already exists
[ 0.260650] omap_timer.3: alias fck already exists
[ 0.260955] omap_timer.4: alias fck already exists
[ 0.261260] omap_timer.5: alias fck already exists
[ 0.261566] omap_timer.6: alias fck already exists
[ 0.261871] omap_timer.7: alias fck already exists
[ 0.262207] omap_timer.8: alias fck already exists
[ 0.262512] omap_timer.9: alias fck already exists
[ 0.262847] omap_timer.10: alias fck already exists
[ 0.263153] omap_timer.11: alias fck already exists
These warnings are due to the commit
318c3e15cd55c73a26ae22a65a8183655b3003f9 ARM: OMAP2+: dmtimer: add
device names to flck nodes
Since 3.1, the fck clock nodes are added automatically based on hwmod
main_clk attribute.
+ CLK("omap_timer.1", "fck", &timer1_fck, CK_443X),
+ CLK("omap_timer.2", "fck", &timer2_fck, CK_443X),
+ CLK("omap_timer.3", "fck", &timer3_fck, CK_443X),
+ CLK("omap_timer.4", "fck", &timer4_fck, CK_443X),
+ CLK("omap_timer.5", "fck", &timer5_fck, CK_443X),
+ CLK("omap_timer.6", "fck", &timer6_fck, CK_443X),
+ CLK("omap_timer.7", "fck", &timer7_fck, CK_443X),
+ CLK("omap_timer.8", "fck", &timer8_fck, CK_443X),
+ CLK("omap_timer.9", "fck", &timer9_fck, CK_443X),
+ CLK("omap_timer.10", "fck", &timer10_fck, CK_443X),
+ CLK("omap_timer.11", "fck", &timer11_fck, CK_443X),
So they should not exist in this patch.
Moreover, all the legacy clockdev should be removed at the same time.
CLK(NULL, "gpt1_fck", &timer1_fck, CK_443X),
CLK(NULL, "gpt10_fck", &timer10_fck, CK_443X),
CLK(NULL, "gpt11_fck", &timer11_fck, CK_443X),
CLK(NULL, "gpt2_fck", &timer2_fck, CK_443X),
CLK(NULL, "gpt3_fck", &timer3_fck, CK_443X),
CLK(NULL, "gpt4_fck", &timer4_fck, CK_443X),
CLK(NULL, "gpt5_fck", &timer5_fck, CK_443X),
CLK(NULL, "gpt6_fck", &timer6_fck, CK_443X),
CLK(NULL, "gpt7_fck", &timer7_fck, CK_443X),
CLK(NULL, "gpt8_fck", &timer8_fck, CK_443X),
CLK(NULL, "gpt9_fck", &timer9_fck, CK_443X),
CLK(NULL, "gpt1_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt2_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt3_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt4_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt5_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt6_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt7_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt8_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt9_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt10_ick", &dummy_ck, CK_443X),
CLK(NULL, "gpt11_ick", &dummy_ck, CK_443X),
That will reduce a little bit the size of these static data files.
Secondly, in commit c345c8b09d7a131f3571af55341038054a79efbd ARM:
OMAP2+: dmtimer: convert to platform devices
+struct omap_device_pm_latency omap2_dmtimer_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
That structure should be removed, since I added a default one in the
omap_device cleanup series for 3.2. Assuming that the cleanup is pulled
before the new feature, the timer series could avoid adding that.
How do you want to handle that, using some cleanup patch on top of your
current branch or by resubmitting the series?
The point is that this branch was already pulled by Arnd in
arm-soc/next/dmtimer feature branch.
Regards,
Benoit
^ permalink raw reply
* [PATCH] arm: proc-v7: pc phy addresses before disable MMU
From: Dave Martin @ 2011-10-03 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7DA3C0.7000208@stericsson.com>
On Sat, Sep 24, 2011 at 11:32:48AM +0200, Per F?rlin wrote:
> On 09/24/2011 10:13 AM, Mika Westerberg wrote:
> > On Sat, Sep 24, 2011 at 10:02:50AM +0200, Per Forlin wrote:
> >> PC runs virtual addresses when calling cpu_v7_reset(). The MMU
> >> is switched off and "mov pc, r0" sets pc back to
> >> virtual addresses even though the MMU is switched off.
> >> This will result in a crash if the pipeline delay after
> >> MMU disable is one instruction. To prevent this set PC
> >> to physical addresses before disabling the MMU.
> >>
> >> Signed-off-by: Per Fransson <per.xx.fransson@stericsson.com>
> >> Signed-off-by: Per Forlin <per.forlin@stericsson.com>
> >> ---
> >> arch/arm/mm/proc-v7.S | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> >> index 9049c07..f26e831 100644
> >> --- a/arch/arm/mm/proc-v7.S
> >> +++ b/arch/arm/mm/proc-v7.S
> >> @@ -64,6 +64,7 @@ ENDPROC(cpu_v7_proc_fin)
> >> */
> >> .align 5
> >> ENTRY(cpu_v7_reset)
> >> + sub pc, pc, #PAGE_OFFSET+4 @ go to physical addresses
> >
> > This only works on machines where PHYS_OFFSET is zero.
> >
> You are right! Russell was very quick to point out the same thing.
For reference, I'll also point out that except for "mov pc,<Rm>",
almost no instruction involving an explicit reference to the pc will
safely do what you want in Thumb-2 kernels, due to the variable instruction
size.
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Mark Brown @ 2011-10-03 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89C3FA.9020206@gmail.com>
On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
A lot of stuff that should really have been cut plus...
> > + if (clk->ops->get_parent)
> > + /* We don't to lock against prepare/enable here, as
> > + * the clock is not yet accessible from anywhere */
> > + clk->parent = clk->ops->get_parent(clk->hw);
> I don't think this is going to work. This implies that the parent clock
> is already registered. For simple clk trees, that's probably not an
> issue, but for chips with lots of muxing it will be impossible to get
> the order correct for all cases. This is not an issue today as most
> clocks are statically created.
> I think what is needed is a 2 stage init. The 1st stage to create all
> the clocks and a 2nd stage to build the tree once all clocks are created.
> Tracking the parents using struct clk_hw instead would help as long as
> clocks are still statically allocated. However, that won't help for
> devicetree.
This isn't in any way specific to clocks, right now the likely solution
looks to be Grant's changes for retrying probe() as new devices come on
line. With that devices can return a code from their probe() which
tells the driver core that they couldn't get all the resources they need
and that it should retry the probe() if more devices come on-line.
^ permalink raw reply
* [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
From: Sylwester Nawrocki @ 2011-10-03 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89B505.3060501@samsung.com>
On 10/03/2011 03:13 PM, Kukjin Kim wrote:
> On 10/03/11 12:53, Kyungmin Park wrote:
>> On Mon, Oct 3, 2011 at 12:41 PM, Kukjin Kim<kgene.kim@samsung.com> wrote:
>>>
>>> +#define SAMSUNG_RES_MEM(soc, ip, sz) DEFINE_RES_MEM(soc##_PA_##ip, sz)
>>> +#define SAMSUNG_RES_IRQ(ip) DEFINE_RES_IRQ(IRQ_##ip)
>>> +
>>> +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \
>>> + DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, name)
>>> +#define SAMSUNG_RES_IRQ_NAMED(ip, name) \
>>> + DEFINE_RES_IRQ_NAMED(IRQ_##ip, name)
>>> +#define SAMSUNG_RES_DMA_NAMED(ch, name) \
>>> + DEFINE_RES_DMA_NAMED(DMACH_##ch, name)
>>
>> It's good for readability. but do you think that it's hard to find out
>> defined macros are used at real place?
>> e.g., Now I want to find out the S3C_PA_USB_HSOTG. it's difficult if
>> you use the SAMSUNG_RES_* series macro.
>> but if you use the DEFINED_RES_* series directly. it's easy to find
>> out at real codes.
>>
> Well, I don't think so because the XXX_PA_XXX addresses are defined in each
> mach/map.h and they are usually used in here so it's not hard to find it.
Some minor disadvantage is that tagging tools like e.g. gtags don't handle
these things properly. But I don't think it's really important.
>
> And now the 'S3C', 'S5P' and 'SAMSUNG' are used in the 'soc' part. I'm
> preparing to consolidate the name and to remove duplicated resources.
Do you also have any specific plans for supporting single image build for
multiple SoC's while working on this ?
Thanks,
--
Sylwester
^ permalink raw reply
* [PATCH v4] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-10-03 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003134145.GE11710@n2100.arm.linux.org.uk>
2011/10/3 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Oct 03, 2011 at 11:57:03AM +0100, Lorenzo Pieralisi wrote:
>> On Sat, Oct 01, 2011 at 04:06:46PM +0100, Russell King - ARM Linux wrote:
>> > On Fri, Sep 30, 2011 at 02:42:53AM -0700, Barry Song wrote:
>> > > From: Barry Song <Baohua.Song@csr.com>
>> > >
>> > > we save the l2x0 registers at the first initialization, and platform codes
>> > > can get them to restore l2x0 status after wakeup.
>> > >
>> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> > > Signed-off-by: Barry Song <Baohua.Song@csr.com>
>> > > Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > > Tested-by: Shawn Guo <shawn.guo@linaro.org>
>> >
>> > This looks fine, thanks Barry.
>> >
>> > The one remaining issue is whether we use this or use Lorenzo's patches.
>> > I feel that Barry's version is a lot simpler and easier to use, so this
>> > is my preference. ?Anyone else got another opinion between the two?
>> >
>>
>> Basically the two patches do the same thing except that Barry's generic
>> resume code cannot be called before the MMU is turned on. On the other hand
>> Barry's patch is certainly simpler to maintain and I think it should be
>> merged, preference shared; I would not say it is easier to use though, usage
>> is identical.
>>
>> It is agreed, better to have it in C than in asm for maintenance reasons,
>> asm can turn out overkill.
>> If there is a compelling case for generic L2 asm we can always add it at a
>> later stage (at least Origen, latest iMX and I think Tegra will need early L2
>> resume from idle).
>
> Ok, so it sounds like we're settled on Barry's code... so can it head to
> the patch system please?
done. http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7114/1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Rob Herring @ 2011-10-03 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316730422-20027-2-git-send-email-mturquette@ti.com>
On 09/22/2011 05:26 PM, Mike Turquette wrote:
> From: Jeremy Kerr <jeremy.kerr@canonical.com>
>
> We currently have ~21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sources without making
> assumptions about struct clk, and impossible to compile two
> platforms with different struct clks into a single image.
>
> This change is an effort to unify struct clk where possible, by defining
> a common struct clk, and a set of clock operations. Different clock
> implementations can set their own operations, and have a standard
> interface for generic code. The callback interface is exposed to the
> kernel proper, while the clock implementations only need to be seen by
> the platform internals.
>
> The interface is split into two halves:
>
> * struct clk, which is the generic-device-driver interface. This
> provides a set of functions which drivers may use to request
> enable/disable, query or manipulate in a hardware-independent manner.
>
> * struct clk_hw and struct clk_hw_ops, which is the hardware-specific
> interface. Clock drivers implement the ops, which allow the core
> clock code to implement the generic 'struct clk' API.
>
> This allows us to share clock code among platforms, and makes it
> possible to dynamically create clock devices in platform-independent
> code.
>
> Platforms can enable the generic struct clock through
> CONFIG_GENERIC_CLK. In this case, the clock infrastructure consists of a
> common, opaque struct clk, and a set of clock operations (defined per
> type of clock):
>
> struct clk_hw_ops {
> int (*prepare)(struct clk_hw *);
> void (*unprepare)(struct clk_hw *);
> int (*enable)(struct clk_hw *);
> void (*disable)(struct clk_hw *);
> unsigned long (*recalc_rate)(struct clk_hw *);
> int (*set_rate)(struct clk_hw *,
> unsigned long, unsigned long *);
> long (*round_rate)(struct clk_hw *, unsigned long);
> int (*set_parent)(struct clk_hw *, struct clk *);
> struct clk * (*get_parent)(struct clk_hw *);
> };
>
> Platform clock code can register a clock through clk_register, passing a
> set of operations, and a pointer to hardware-specific data:
>
> struct clk_hw_foo {
> struct clk_hw clk;
> void __iomem *enable_reg;
> };
>
> #define to_clk_foo(c) offsetof(c, clk_hw_foo, clk)
>
> static int clk_foo_enable(struct clk_hw *clk)
> {
> struct clk_foo *foo = to_clk_foo(clk);
> raw_writeb(foo->enable_reg, 1);
> return 0;
> }
>
> struct clk_hw_ops clk_foo_ops = {
> .enable = clk_foo_enable,
> };
>
> And in the platform initialisation code:
>
> struct clk_foo my_clk_foo;
>
> void init_clocks(void)
> {
> my_clk_foo.enable_reg = ioremap(...);
>
> clk_register(&clk_foo_ops, &my_clk_foo, NULL);
> }
>
> Changes from Thomas Gleixner <tglx@linutronix.de>.
>
> The common clock definitions are based on a development patch from Ben
> Herrenschmidt <benh@kernel.crashing.org>.
>
> TODO:
>
> * We don't keep any internal reference to the clock topology at present.
>
> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Signed-off-by: Mike Turquette <mturquette@ti.com>
> ---
> Changes since v1:
> Create a dummy clk_unregister and prototype/document it and clk_register
> Constify struct clk_hw_ops
> Remove spinlock.h header, include kernel.h
> Use EOPNOTSUPP instead of ENOTSUPP
> Add might_sleep to clk_prepare/clk_unprepare stubs
> Properly init children hlist and child_node
> Whitespace and typo fixes
>
> drivers/clk/Kconfig | 3 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk.c | 232 ++++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/clk/clkdev.c | 7 ++
> include/linux/clk.h | 140 +++++++++++++++++++++++++++---
> 5 files changed, 371 insertions(+), 12 deletions(-)
> create mode 100644 drivers/clk/clk.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 3530927..c53ed59 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -5,3 +5,6 @@ config CLKDEV_LOOKUP
>
> config HAVE_MACH_CLKDEV
> bool
> +
> +config GENERIC_CLK
> + bool
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 07613fa..570d5b9 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -1,2 +1,3 @@
>
> obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
> +obj-$(CONFIG_GENERIC_CLK) += clk.o
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> new file mode 100644
> index 0000000..1cd7315
> --- /dev/null
> +++ b/drivers/clk/clk.c
> @@ -0,0 +1,232 @@
> +/*
> + * Copyright (C) 2010-2011 Canonical Ltd <jeremy.kerr@canonical.com>
> + *
> + * 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.
> + *
> + * Standard functionality for the common clock API.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +struct clk {
> + const char *name;
> + const struct clk_hw_ops *ops;
> + struct clk_hw *hw;
> + unsigned int enable_count;
> + unsigned int prepare_count;
> + struct clk *parent;
> + unsigned long rate;
> +};
> +
> +static DEFINE_SPINLOCK(enable_lock);
> +static DEFINE_MUTEX(prepare_lock);
> +
> +static void __clk_unprepare(struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + if (WARN_ON(clk->prepare_count == 0))
> + return;
> +
> + if (--clk->prepare_count > 0)
> + return;
> +
> + WARN_ON(clk->enable_count > 0);
> +
> + if (clk->ops->unprepare)
> + clk->ops->unprepare(clk->hw);
> +
> + __clk_unprepare(clk->parent);
> +}
> +
> +void clk_unprepare(struct clk *clk)
> +{
> + mutex_lock(&prepare_lock);
> + __clk_unprepare(clk);
> + mutex_unlock(&prepare_lock);
> +}
> +EXPORT_SYMBOL_GPL(clk_unprepare);
> +
> +static int __clk_prepare(struct clk *clk)
> +{
> + int ret = 0;
> +
> + if (!clk)
> + return 0;
> +
> + if (clk->prepare_count == 0) {
> + ret = __clk_prepare(clk->parent);
> + if (ret)
> + return ret;
> +
> + if (clk->ops->prepare) {
> + ret = clk->ops->prepare(clk->hw);
> + if (ret) {
> + __clk_unprepare(clk->parent);
> + return ret;
> + }
> + }
> + }
> +
> + clk->prepare_count++;
> +
> + return 0;
> +}
> +
> +int clk_prepare(struct clk *clk)
> +{
> + int ret;
> +
> + mutex_lock(&prepare_lock);
> + ret = __clk_prepare(clk);
> + mutex_unlock(&prepare_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(clk_prepare);
> +
> +static void __clk_disable(struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + if (WARN_ON(clk->enable_count == 0))
> + return;
> +
> + if (--clk->enable_count > 0)
> + return;
> +
> + if (clk->ops->disable)
> + clk->ops->disable(clk->hw);
> + __clk_disable(clk->parent);
> +}
> +
> +void clk_disable(struct clk *clk)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&enable_lock, flags);
> + __clk_disable(clk);
> + spin_unlock_irqrestore(&enable_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(clk_disable);
> +
> +static int __clk_enable(struct clk *clk)
> +{
> + int ret;
> +
> + if (!clk)
> + return 0;
> +
> + if (WARN_ON(clk->prepare_count == 0))
> + return -ESHUTDOWN;
> +
> +
> + if (clk->enable_count == 0) {
> + ret = __clk_enable(clk->parent);
> + if (ret)
> + return ret;
> +
> + if (clk->ops->enable) {
> + ret = clk->ops->enable(clk->hw);
> + if (ret) {
> + __clk_disable(clk->parent);
> + return ret;
> + }
> + }
> + }
> +
> + clk->enable_count++;
> + return 0;
> +}
> +
> +int clk_enable(struct clk *clk)
> +{
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(&enable_lock, flags);
> + ret = __clk_enable(clk);
> + spin_unlock_irqrestore(&enable_lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(clk_enable);
> +
> +unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (!clk)
> + return 0;
> + return clk->rate;
> +}
> +EXPORT_SYMBOL_GPL(clk_get_rate);
> +
> +long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk && clk->ops->round_rate)
> + return clk->ops->round_rate(clk->hw, rate);
> + return rate;
> +}
> +EXPORT_SYMBOL_GPL(clk_round_rate);
> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + /* not yet implemented */
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_rate);
> +
> +struct clk *clk_get_parent(struct clk *clk)
> +{
> + if (!clk)
> + return NULL;
> +
> + return clk->parent;
> +}
> +EXPORT_SYMBOL_GPL(clk_get_parent);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + /* not yet implemented */
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_parent);
> +
> +struct clk *clk_register(const struct clk_hw_ops *ops, struct clk_hw *hw,
> + const char *name)
> +{
> + struct clk *clk;
> +
> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> + if (!clk)
> + return NULL;
> +
> + INIT_HLIST_HEAD(&clk->children);
> + INIT_HLIST_NODE(&clk->child_node);
> +
> + clk->name = name;
> + clk->ops = ops;
> + clk->hw = hw;
> + hw->clk = clk;
> +
> + /* Query the hardware for parent and initial rate */
> +
> + if (clk->ops->get_parent)
> + /* We don't to lock against prepare/enable here, as
> + * the clock is not yet accessible from anywhere */
> + clk->parent = clk->ops->get_parent(clk->hw);
I don't think this is going to work. This implies that the parent clock
is already registered. For simple clk trees, that's probably not an
issue, but for chips with lots of muxing it will be impossible to get
the order correct for all cases. This is not an issue today as most
clocks are statically created.
I think what is needed is a 2 stage init. The 1st stage to create all
the clocks and a 2nd stage to build the tree once all clocks are created.
Tracking the parents using struct clk_hw instead would help as long as
clocks are still statically allocated. However, that won't help for
devicetree.
Rob
^ permalink raw reply
* [PATCH 5/6] ASoC: samsung: wm8994 depends on mfd_wm8994
From: Mark Brown @ 2011-10-03 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11174515.ANsqIhx0NX@wuerfel>
On Mon, Oct 03, 2011 at 03:43:10PM +0200, Arnd Bergmann wrote:
> > You've not sent a seprate patch for that one yet...
> I wasn't sure any more which version you wanted. Is this this right one?
I was expecting something that selects the core. I was also expecting
something that can be applied against -next which this patch can't be,
this doesn't feel like something we should be rushing into 3.1.
^ permalink raw reply
* [PATCH 05/11] ARM: vfp: use -mfloat-abi=soft to build vfp
From: Dave Martin @ 2011-10-03 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-6-git-send-email-arnd@arndb.de>
On Sat, Oct 01, 2011 at 09:21:54PM +0200, Arnd Bergmann wrote:
> Distros are starting to ship with toolchains defaulting to
> hardfloat. Using such a compiler to build the kernel fails
> in the VFP directory with
>
> arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
>
> Adding -mfloat-abi=soft to the gcc command line fixes this.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/vfp/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/vfp/Makefile b/arch/arm/vfp/Makefile
> index 6de73aa..a81404c 100644
> --- a/arch/arm/vfp/Makefile
> +++ b/arch/arm/vfp/Makefile
> @@ -7,7 +7,7 @@
> # ccflags-y := -DDEBUG
> # asflags-y := -DDEBUG
>
> -KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp)
> +KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp -mfloat-abi=soft)
Although -mfpu=softvfp+vfp and -mfloat-abi=soft look mutually
contradictory, this seems to have the correct effect, i.e. the
assembler allows floating-point instructions but marks the resulting
object as using the soft-float calling conventions.
The binutils documentation also seems to confirm that that's what
should happen.
I don't see another combination of options for getting this effect.
So, if you like:
Reviewed-by: Dave Martin <dave.martin@linaro.org>
Cheers
---Dave
^ permalink raw reply
* [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
From: Arnd Bergmann @ 2011-10-03 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89AD44.80609@samsung.com>
On Monday 03 October 2011 21:40:36 Kukjin Kim wrote:
> Yes, absolutely. As I said, the 'mach-exynos' can support upcoming
> Samsung EXYNOS SoCs and the way is better than making mach-exynos5.
>
> My bigger plan is finally to make current directories to 3 mach- dir.
> (mach-s3c, mach-s5p, and mach-exynos) and 1 plat-samsung directory. Of
> course, the mach- directories can be reduced later.
>
> Firstly, as you can see, I'm merging plat-s3c24xx and plat-s5p into one
> plat-samsung directory and actually the <plat/*.h> files and dev-*.c
> files have been moved into plat-samsung. Maybe I can finish it during
> 3.2-rc.
Ok, sounds good. So for my understanding: is s5p a completely separate
line from exynos, or are they more of an evolutionary succession where
you draw the line between the last uniprocessor and the first SMP
chip?
> Secondary, upcoming Samsung EXYNOS SoCs will be supported in mach-exynos
> directory and this patch is required to that. For example, the EXYNOS5
> SoCs (Cortex A15) will be supported in that with other EXYNOS4 SoCs soon
> and of course it reduces code duplication
My feeling is that it would be nicer to just add exynos5 to the mach-exynos4
directory for now, in the same way that omap3/4/5 are in the mach-omap2
directory. We can do a big rename later once the reorganization of code
within those directories that you explained above is complete.
If you still want to do the big rename right now, I would suggest doing
it at the end of the 3.2 merge window, so that all other patches that
might need to touch the mach-exynos4 directory can go in first.
Arnd
^ permalink raw reply
* nr_cpus cmdline parameter not working
From: Mark Salter @ 2011-10-03 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001162357.GH11710@n2100.arm.linux.org.uk>
On Sat, 2011-10-01 at 17:23 +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 28, 2011 at 11:35:16AM -0400, Mark Salter wrote:
> > I noticed that nr_cpus=1 doesn't appear to have any effect on a
> > pandaboard (and probably others from the looks of things). This
> > changes seems to be needed, but I'm not really sure if this is
> > the right thing or not.
> >
> > diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> > index ce65e93..a1198ac 100644
> > --- a/arch/arm/mach-omap2/omap-smp.c
> > +++ b/arch/arm/mach-omap2/omap-smp.c
> > @@ -117,6 +117,9 @@ void __init smp_init_cpus(void)
> > ncores = NR_CPUS;
> > }
> >
> > + if (ncores > nr_cpu_ids)
> > + ncores = nr_cpu_ids;
> > +
>
> This potentially affects all SMP platforms, so the patch needs to be
> bigger than this.
>
> Also, I think the test above should be modified to use nr_cpu_ids
> rather than NR_CPUS, to be inline with what x86 does:
>
> /* nr_cpu_ids could be reduced via nr_cpus= */
> if (possible > nr_cpu_ids) {
> printk(KERN_WARNING
> "%d Processors exceeds NR_CPUS limit of %d\n",
> possible, nr_cpu_ids);
> possible = nr_cpu_ids;
> }
>
> (This is essentially the same check that we're doing.)
>
> Could you have a look at this and cook up another patch covering the
> other SMP platforms please?
Ok, I'll do that.
^ permalink raw reply
* [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB
From: Russell King - ARM Linux @ 2011-10-03 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002204106.GB5811@opensource.wolfsonmicro.com>
On Sun, Oct 02, 2011 at 09:41:07PM +0100, Mark Brown wrote:
> On Sun, Oct 02, 2011 at 10:28:00PM +0200, Arnd Bergmann wrote:
> > This driver only builds correctly on platforms that use
> > GPIOLIB. Disable it otherwise.
>
> No, gpiolib is one implementation of the GPIO API but if platforms want
> to go and define their own that's currently OK (personally I think at
> this point we should just be converting all the stragglers over to
> gpiolib). As things stand we shouldn't have dependencies on a
> particular implementation of the API.
Then it should depend on GENERIC_GPIO (not to be confused with GPIO_GENERIC,
the generic gpiolib driver), which is the symbol meaning that the GPIO API
is provided by something.
^ permalink raw reply
* [PATCH 5/6] ASoC: samsung: wm8994 depends on mfd_wm8994
From: Arnd Bergmann @ 2011-10-03 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003120741.GD23811@sirena.org.uk>
Any driver that selects SND_SOC_WM8994 should also make sure that
MFD_WM8994 is set, since the codec relies on the mfd code:
sound/built-in.o: In function `wm8994_read':
last.c:(.text+0x20160): undefined reference to `wm8994_reg_read'
sound/built-in.o: In function `wm8994_write':
last.c:(.text+0x20e68): undefined reference to `wm8994_reg_write'
This adds the missing 'depends' statements to Kconfig, as found
during ARM randconfig tests.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
sound/soc/samsung/Kconfig | 3 +++
1 file changed, 3 insertions(+)
On Monday 03 October 2011 13:07:41 Mark Brown wrote:
> On Mon, Oct 03, 2011 at 01:50:08PM +0200, Arnd Bergmann wrote:
>
> > the patch. The other problem in this patch is still there, with
> > CONFIG_SND_SOC_SMDK_WM8994_PCM=y and CONFIG_MFD_WM8994=n:
>
> You've not sent a seprate patch for that one yet...
I wasn't sure any more which version you wanted. Is this this right one?
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -65,6 +65,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8580
config SND_SOC_SAMSUNG_SMDK_WM8994
tristate "SoC I2S Audio support for WM8994 on SMDK"
depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210)
+ depends on MFD_WM8994
select SND_SOC_WM8994
select SND_SAMSUNG_I2S
help
@@ -152,6 +153,7 @@ config SND_SOC_GONI_AQUILA_WM8994
tristate "SoC I2S Audio support for AQUILA/GONI - WM8994"
depends on SND_SOC_SAMSUNG && (MACH_GONI || MACH_AQUILA)
select SND_SAMSUNG_I2S
+ depends on MFD_WM8994
select SND_SOC_WM8994
help
Say Y if you want to add support for SoC audio on goni or aquila
@@ -175,6 +177,7 @@ config SND_SOC_SMDK_WM8580_PCM
config SND_SOC_SMDK_WM8994_PCM
tristate "SoC PCM Audio support for WM8994 on SMDK"
depends on SND_SOC_SAMSUNG && (MACH_SMDKC210 || MACH_SMDKV310)
+ depends on MFD_WM8994
select SND_SOC_WM8994
select SND_SAMSUNG_PCM
help
^ permalink raw reply
* [PATCH v4] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-10-03 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003105658.GC14761@e102568-lin.cambridge.arm.com>
On Mon, Oct 03, 2011 at 11:57:03AM +0100, Lorenzo Pieralisi wrote:
> On Sat, Oct 01, 2011 at 04:06:46PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 30, 2011 at 02:42:53AM -0700, Barry Song wrote:
> > > From: Barry Song <Baohua.Song@csr.com>
> > >
> > > we save the l2x0 registers at the first initialization, and platform codes
> > > can get them to restore l2x0 status after wakeup.
> > >
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > > Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > > Tested-by: Shawn Guo <shawn.guo@linaro.org>
> >
> > This looks fine, thanks Barry.
> >
> > The one remaining issue is whether we use this or use Lorenzo's patches.
> > I feel that Barry's version is a lot simpler and easier to use, so this
> > is my preference. Anyone else got another opinion between the two?
> >
>
> Basically the two patches do the same thing except that Barry's generic
> resume code cannot be called before the MMU is turned on. On the other hand
> Barry's patch is certainly simpler to maintain and I think it should be
> merged, preference shared; I would not say it is easier to use though, usage
> is identical.
>
> It is agreed, better to have it in C than in asm for maintenance reasons,
> asm can turn out overkill.
> If there is a compelling case for generic L2 asm we can always add it at a
> later stage (at least Origen, latest iMX and I think Tegra will need early L2
> resume from idle).
Ok, so it sounds like we're settled on Barry's code... so can it head to
the patch system please?
^ permalink raw reply
* [PATCH] ARM: debug: provide dummy default option for DEBUG_LL UART choice
From: Marc Zyngier @ 2011-10-03 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317374927-4997-1-git-send-email-will.deacon@arm.com>
On 30/09/11 10:28, Will Deacon wrote:
> Defaulting to DEBUG_ICEDCC will cause systems to hang during boot unless
> a hardware debugger is listening to the debug comms. channel.
>
> This patch adds a dummy UART option as the default DEBUG_LL choice which
> requires the platform to do the right thing.
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>
> This came out of discussion on the list yesterday but I thought I'd better
> post a patch before sending to Russell.
This fixes my OMAP4 boot problems (where DEBUG_ICEDCC got silently
selected). Tested on -next-20110930.
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-10-03 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647872-22627-1-git-send-email-pdeschrijver@nvidia.com>
And this one too. will resent with proper subject.
Peter.
^ permalink raw reply
* [PATCH v7 3/3] arm/tegra: device tree support for ventana board
From: Peter De Schrijver @ 2011-10-03 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647918-22694-1-git-send-email-pdeschrijver@nvidia.com>
Change-Id: I5ed18750e6a8aa3242dae4bcd7165cfd819356d2
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 ++++++
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 26 +++++++++++++++++++++-----
4 files changed, 60 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
diff --git a/arch/arm/boot/dts/tegra-ventana.dts b/arch/arm/boot/dts/tegra-ventana.dts
new file mode 100644
index 0000000..9b29a62
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-ventana.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "NVIDIA Tegra2 Ventana evaluation board";
+ compatible = "nvidia,ventana", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/ram rdinit=/sbin/init";
+ };
+
+ memory {
+ reg = < 0x00000000 0x40000000 >;
+ };
+
+ serial at 70006300 {
+ clock-frequency = < 216000000 >;
+ };
+
+ sdhci at c8000400 {
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ };
+
+ sdhci at c8000600 {
+ power-gpios = <&gpio 70 0>; /* gpio PI6 */
+ support-8bit;
+ };
+};
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index d82ebab..91aff7c 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -69,6 +69,12 @@ config MACH_WARIO
help
Support for the Wario version of Seaboard
+config MACH_VENTANA
+ bool "Ventana board"
+ select MACH_TEGRA_DT
+ help
+ Support for the nVidia Ventana development platform
+
choice
prompt "Low-level debug console UART"
default TEGRA_DEBUG_UART_NONE
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index 5e870d2..bd12c9f 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -4,3 +4,4 @@ initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
+dtb-$(CONFIG_MACH_VENTANA) += tegra-ventana.dtb
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 9f47e04..1b4cf6e 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -47,7 +47,7 @@
void harmony_pinmux_init(void);
void seaboard_pinmux_init(void);
-
+void ventana_pinmux_init(void);
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
@@ -80,9 +80,19 @@ static struct of_device_id tegra_dt_gic_match[] __initdata = {
{}
};
+static struct {
+ char *machine;
+ void (*init)(void);
+} pinmux_configs[] = {
+ { "nvidia,harmony", harmony_pinmux_init },
+ { "nvidia,seaboard", seaboard_pinmux_init },
+ { "nvidia,ventana", ventana_pinmux_init },
+};
+
static void __init tegra_dt_init(void)
{
struct device_node *node;
+ int i;
node = of_find_matching_node_by_address(NULL, tegra_dt_gic_match,
TEGRA_ARM_INT_DIST_BASE);
@@ -91,10 +101,15 @@ static void __init tegra_dt_init(void)
tegra_clk_init_from_table(tegra_dt_clk_init_table);
- if (of_machine_is_compatible("nvidia,harmony"))
- harmony_pinmux_init();
- else if (of_machine_is_compatible("nvidia,seaboard"))
- seaboard_pinmux_init();
+ for (i = 0; i < ARRAY_SIZE(pinmux_configs); i++) {
+ if (of_machine_is_compatible(pinmux_configs[i].machine)) {
+ pinmux_configs[i].init();
+ break;
+ }
+ }
+
+ if (i == ARRAY_SIZE(pinmux_configs))
+ printk(KERN_WARNING "Unknown platform! Pinmuxing not initialized\n");
/*
* Finished with the static registrations now; fill in the missing
@@ -106,6 +121,7 @@ static void __init tegra_dt_init(void)
static const char * tegra_dt_board_compat[] = {
"nvidia,harmony",
"nvidia,seaboard",
+ "nvidia,ventana",
NULL
};
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [PATCH v7 2/3] arm/tegra: add support for ventana pinmuxing
From: Peter De Schrijver @ 2011-10-03 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647918-22694-1-git-send-email-pdeschrijver@nvidia.com>
Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
version of work done by Jong Kim <jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/board-seaboard-pinmux.c | 49 +++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f11b910..91a07e1 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -31,6 +31,7 @@ obj-${CONFIG_MACH_SEABOARD} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-dt.o
obj-${CONFIG_MACH_TEGRA_DT} += board-harmony-pinmux.o
+obj-${CONFIG_MACH_TEGRA_DT} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice-pinmux.o
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index b31c765..b62b04d 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -158,8 +158,26 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
{TEGRA_PINGROUP_XM2D, TEGRA_MUX_NONE, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
};
-
-
+static __initdata struct tegra_pingroup_config ventana_pinmux[] = {
+ {TEGRA_PINGROUP_DAP3, TEGRA_MUX_DAP3, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_DDC, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTA, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTB, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTC, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTD, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_GMD, TEGRA_MUX_SFLASH, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LPW0, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LPW2, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSC1, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSCK, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LSDA, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_PTA, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXC, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXK, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SPIA, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIC, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIG, TEGRA_MUX_SPI2_ALT, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+};
static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
@@ -172,6 +190,26 @@ static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
+static void __init update_pinmux(struct tegra_pingroup_config *newtbl, int size)
+{
+ int i, j;
+ struct tegra_pingroup_config *new_pingroup, *base_pingroup;
+
+ /* Update base seaboard pinmux table with secondary board
+ * specific pinmux table table.
+ */
+ for (i = 0; i < size; i++) {
+ new_pingroup = &newtbl[i];
+ for (j = 0; j < ARRAY_SIZE(seaboard_pinmux); j++) {
+ base_pingroup = &seaboard_pinmux[j];
+ if (new_pingroup->pingroup == base_pingroup->pingroup) {
+ *base_pingroup = *new_pingroup;
+ break;
+ }
+ }
+ }
+}
+
static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
@@ -186,3 +224,10 @@ void __init seaboard_pinmux_init(void)
{
seaboard_common_pinmux_init();
}
+
+void __init ventana_pinmux_init(void)
+{
+ update_pinmux(ventana_pinmux, ARRAY_SIZE(ventana_pinmux));
+ seaboard_common_pinmux_init();
+}
+
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [PATCH v7 1/3] arm/tegra: prepare Seaboard pinmux code for derived boards
From: Peter De Schrijver @ 2011-10-03 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647918-22694-1-git-send-email-pdeschrijver@nvidia.com>
This patch splits out the common part of pinmux and GPIO initialization for
seaboard and derived boards. This code is based on work done by Jong Kim
<jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/board-seaboard-pinmux.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index 74f78b7..b31c765 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2010 NVIDIA Corporation
+ * Copyright (C) 2010,2011 NVIDIA Corporation
+ * Copyright (C) 2011 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -160,7 +161,7 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
-static struct tegra_gpio_table gpio_table[] = {
+static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
{ .gpio = TEGRA_GPIO_SD2_WP, .enable = true },
{ .gpio = TEGRA_GPIO_SD2_POWER, .enable = true },
@@ -171,12 +172,17 @@ static struct tegra_gpio_table gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
-void __init seaboard_pinmux_init(void)
+static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
tegra_drive_pinmux_config_table(seaboard_drive_pinmux,
ARRAY_SIZE(seaboard_drive_pinmux));
- tegra_gpio_config(gpio_table, ARRAY_SIZE(gpio_table));
+ tegra_gpio_config(common_gpio_table, ARRAY_SIZE(common_gpio_table));
+}
+
+void __init seaboard_pinmux_init(void)
+{
+ seaboard_common_pinmux_init();
}
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [PATCH v7 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-10-03 13:18 UTC (permalink / raw)
To: linux-arm-kernel
This patch set adds support for the tegra2 based ventana development board.
Boot tested on ventana.
Uses a table based approach to select the correct init function.
Fix some compiler errors.
Peter De Schrijver (3):
arm/tegra: prepare Seaboard pinmux code for derived boards
arm/tegra: add support for ventana pinmuxing
arm/tegra: device tree support for ventana board
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 +++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 5 ++-
arch/arm/mach-tegra/board-seaboard-pinmux.c | 63 ++++++++++++++++++++++++---
6 files changed, 101 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
^ permalink raw reply
* [[PATCH v7] 1/3] arm/tegra: prepare Seaboard pinmux code for derived boards
From: Peter De Schrijver @ 2011-10-03 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647872-22627-1-git-send-email-pdeschrijver@nvidia.com>
This patch splits out the common part of pinmux and GPIO initialization for
seaboard and derived boards. This code is based on work done by Jong Kim
<jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/board-seaboard-pinmux.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index 74f78b7..b31c765 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2010 NVIDIA Corporation
+ * Copyright (C) 2010,2011 NVIDIA Corporation
+ * Copyright (C) 2011 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -160,7 +161,7 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
-static struct tegra_gpio_table gpio_table[] = {
+static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
{ .gpio = TEGRA_GPIO_SD2_WP, .enable = true },
{ .gpio = TEGRA_GPIO_SD2_POWER, .enable = true },
@@ -171,12 +172,17 @@ static struct tegra_gpio_table gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
-void __init seaboard_pinmux_init(void)
+static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
tegra_drive_pinmux_config_table(seaboard_drive_pinmux,
ARRAY_SIZE(seaboard_drive_pinmux));
- tegra_gpio_config(gpio_table, ARRAY_SIZE(gpio_table));
+ tegra_gpio_config(common_gpio_table, ARRAY_SIZE(common_gpio_table));
+}
+
+void __init seaboard_pinmux_init(void)
+{
+ seaboard_common_pinmux_init();
}
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [PATCH v7 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-10-03 13:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch set adds support for the tegra2 based ventana development board.
Boot tested on ventana.
Uses a table based approach to select the correct init function.
Fix some compiler errors.
Peter De Schrijver (3):
arm/tegra: prepare Seaboard pinmux code for derived boards
arm/tegra: add support for ventana pinmuxing
arm/tegra: device tree support for ventana board
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 +++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 5 ++-
arch/arm/mach-tegra/board-seaboard-pinmux.c | 63 ++++++++++++++++++++++++---
6 files changed, 101 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
^ 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