* [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
From: Felipe Balbi @ 2011-10-03 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3529819.LQllWhb43D@wuerfel>
Hi,
On Mon, Oct 03, 2011 at 11:40:26AM +0200, Arnd Bergmann wrote:
> On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
> > Anyway, I'll take your patches in, but their too late for this merge
> > window I already sent my last pull to Greg.
>
> No problem. I need the full set of arm-randconfig patches upstream in order
> to make randconfig work in general, and that's not happening for 3.2
> anyway. Right now, I'm just trying to as many patches as possible into
> maintainer trees.
>
> Is your tree part of linux-next, or will it only show up after the merge
> window once Greg has pulled your first set for 3.3?
My tree isn't in linux-next yet so my patches go to Greg and from there
to -next.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111003/fd2867bf/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] tty/serial: atmel_serial: __devinit_p for probe function
From: Nicolas Ferre @ 2011-10-03 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd489c1d28c26624d6b68399d222aec371045e53.1317634987.git.nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/tty/serial/atmel_serial.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index a652f8f..e40a10a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1789,7 +1789,7 @@ static int __devexit atmel_serial_remove(struct platform_device *pdev)
}
static struct platform_driver atmel_serial_driver = {
- .probe = atmel_serial_probe,
+ .probe = __devinit_p(atmel_serial_probe),
.remove = __devexit_p(atmel_serial_remove),
.suspend = atmel_serial_suspend,
.resume = atmel_serial_resume,
--
1.7.3
^ permalink raw reply related
* [GIT PULL] Samsung devel-2 for v3.2
From: Mark Brown @ 2011-10-03 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005801cc817c$5d42f9e0$17c8eda0$%kim@samsung.com>
On Mon, Oct 03, 2011 at 12:27:22PM +0900, Kukjin Kim wrote:
> Mark Brown wrote:
> > As I reported the other day this change breaks the boot early on on the
> > Cragganmore S3C6410 based systems (I've not actually fired up my
> > SMDK6410 but I suspect it may have issues too). I did make some brief
> > attempts to debug but as there's no console output at all and the diff
> > is rather large it's not easy to see what's gone wrong.
> Hmm, I thought it has no problem when I saw Thomas Abraham's 'serial:
> samsung' patches because he said it works fine with my for-next plus his
> patches on SMDK6410...Anyway, I need to sort it out.
It's possible it's something that doesn't manifest on that board, I've
no real idea what's exploding or why. There's also a bunch of other
early boot problems right now like try_to_freeze() which aren't helping.
^ permalink raw reply
* [PATCH v4] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Lorenzo Pieralisi @ 2011-10-03 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001150646.GB11710@n2100.arm.linux.org.uk>
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).
Lorenzo
^ permalink raw reply
* [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB
From: Arnd Bergmann @ 2011-10-03 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002212711.GC4506@opensource.wolfsonmicro.com>
On Sunday 02 October 2011 22:27:11 Mark Brown wrote:
> > Is there any other symbol that I can test then?
>
> You shouldn't be testing anything - the client side GPIO API (which is
> what this driver is using) is supposed to stub itself out when not in
> use so drivers should just be able to use it without worrying about
> dependencies. You didn't report the problem but I'd expect that
> whatever you saw will be an issue in whatever platform you were trying
> to build for (I'm guessing it hasn't provided gpio_request_one()),
> though it could be a problem in the gpiolib stubs if that's being used.
I don't remember where I first saw it. If the problem comes back,
I'll do a full bug report. I've verified now that it works on
various platforms with and without GPIOLIB.
I didn't know how the GPIO bits fit together, so I ended up doing
something that made the problem go away, whatever it was. This
is of course a problem with the randconfig fixing: One really needs
to understand every possible corner of the kernel to get it right,
and if you don't you end up with a patch that avoids the symptom
without fixing the underlying bug and then you make it harder to
find.
I really appreciate you doing the thorough review of the patches
to make sure we find the actual bugs, which is one of the main
things I want to achieve here anyway.
> > I noticed that a lot of places use 'depends on GPIOLIB' or
> > '#ifdef CONFIG_GPIOLIB', are those usually wrong, too?
>
> Checks for gpiolib in drivers providing GPIOs are sensible, if a
> platform hasn't used gpiolib then it's generally not even got an
> interface for drivers to provide GPIOs.
>
> On the user side these are usually due to people making the sort of
> changes you're making here due to a random build coverage issue - it
> seems unfortunately common for people to just shove a dependency in
> Kconfig when they run into a build coverage issue without looking at
> what's going on. For a lot of the stuff you see on PCs it's going to
> make sense but for some of the "service" APIs like GPIOs that are more
> commonly used only in embedded contexts the use of the API is usually
> completely optional (eg, in this case the driver is controlling power
> and reset lines which could easily just be strapped in the hardware with
> no soft control and are supplied as optional platform data) so for many
> systems the driver is going to work completely happily without doing
> anything with GPIOs.
>
> Adding dependencies to all the users needlessly restricts which systems
> can use the drivers. Adding ifdefs to the drivers is repetitive and
> isn't great for legiblity, having the header stub itself out is simpler
> and easier to use on the driver side.
Ok, makes sense. Thanks for the background information!
Arnd
^ permalink raw reply
* [PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it
From: Arnd Bergmann @ 2011-10-03 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8945CE.6070800@ti.com>
On Monday 03 October 2011 10:49:10 Santosh Shilimkar wrote:
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 57b66d5..4deeade 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2
> > select SERIAL_CORE_CONSOLE
> > select SERIAL_8250_CONSOLE
> > select REGULATOR_FIXED_VOLTAGE
> > + select TWL4030_CORE
> > + select I2C
> >
> Another option to ensure I2C is selected when
> TWL* drivers are selected is let it depends
> on I2C. That wat we can avoid patching every
> machine entry with I2C option.
> Not a strong opinion though.
I generally try to avoid having select statements where a
depends on works fine, as in the generic TWL4030_CORE config.
For platforms that require TWL4030, this does not work, although
it would be better not to have this strict dependency and make
the configuration build if the driver is disabled, even if that
is rather pointless.
Arnd
^ permalink raw reply
* [GIT PULL] Samsung devel-2 for v3.2
From: Russell King - ARM Linux @ 2011-10-03 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003103626.GA3731@opensource.wolfsonmicro.com>
On Mon, Oct 03, 2011 at 11:36:26AM +0100, Mark Brown wrote:
> On Mon, Oct 03, 2011 at 12:27:22PM +0900, Kukjin Kim wrote:
> > Mark Brown wrote:
>
> > > As I reported the other day this change breaks the boot early on on the
> > > Cragganmore S3C6410 based systems (I've not actually fired up my
> > > SMDK6410 but I suspect it may have issues too). I did make some brief
> > > attempts to debug but as there's no console output at all and the diff
> > > is rather large it's not easy to see what's gone wrong.
>
> > Hmm, I thought it has no problem when I saw Thomas Abraham's 'serial:
> > samsung' patches because he said it works fine with my for-next plus his
> > patches on SMDK6410...Anyway, I need to sort it out.
>
> It's possible it's something that doesn't manifest on that board, I've
> no real idea what's exploding or why. There's also a bunch of other
> early boot problems right now like try_to_freeze() which aren't helping.
I don't know whether I can solve that before the next merge window.
There's lots of corner cases, and I'm no longer convinced that my
previous patch doesn't introduce more problems than it solves (such
as completely breaking the -ERESTART_RESTARTBLOCK handing.)
While it's possible to shut up the warning by enabling IRQs, that makes
the race for restarting (or not restarting) syscalls *huge*, and that
could cause unexpected userspace behaviour depending on whether they
handle EINTR and _how_ they handle EINTR on system calls which they
expect would've been restarted by the kernel.
^ permalink raw reply
* [PATCH] ARM: S3C2410: Remove section mismatch warning
From: Tushar Behera @ 2011-10-03 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003095933.GC11710@n2100.arm.linux.org.uk>
Hi Russell,
On Monday 03 October 2011 03:29 PM, Russell King - ARM Linux wrote:
> On Mon, Oct 03, 2011 at 03:10:41PM +0530, Tushar Behera wrote:
>> Some of the functions and structures did not have _init or __initdata
>> attributes, even though they were referenced from functions / structures
>> with those attribute, resulting in section mismatches.
>
> Firstly - it's a good idea to include the warnings which you're fixing
> in the commit log text, so that people know exactly what is being fixed.
>
Thanks for your review.
Sure, I will add it in next revision.
[ snip ]
>> diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
>> index 28ad20d..153cb2f 100644
>> --- a/arch/arm/mach-s3c2416/irq.c
>> +++ b/arch/arm/mach-s3c2416/irq.c
>> @@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
>> return 0;
>> }
>>
>> -static struct sysdev_driver s3c2416_irq_driver = {
>> +static struct sysdev_driver s3c2416_irq_driver __initdata = {
>> .add = s3c2416_irq_add,
>> };
>>
>
> I remain entirely unconvinced that this is correct. As a result of
> the "sysdev_driver_register(&s3c2416_sysclass,&s3c2416_irq_driver);"
> call, this structure is placed on a list.
>
> If this structure is marked __initdata, then the memory behind the
> structure will be freed and overwritten - however, it's still on a
> list which might be walked. Such a walk would cause a kernel oops
> or might even be an exploitable security hole if that page ends up
> in userspace - especially as said structure contains function calls
> which would be called in privileged mode.
>
The function s3c2416_irq_add() is defined with __init attribute. Also a
cascade of functions called from s3c2416_irq_add() are also defined with
__init attribute.
Would it be a good idea to remove __init attribute of all these
functions (there are 2 of them) called from s3c2416_irq_add() instead?
> The same comment applies to the other sysdev driver structures you're
> marking __initdata too.
--
Tushar Behera
^ permalink raw reply
* [alsa-devel] [PATCH 5/6] ASoC: samsung: fix Kconfig dependencies
From: Arnd Bergmann @ 2011-10-03 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004e01cc8198$848347f0$8d89d7d0$@com>
On Monday 03 October 2011 15:48:54 Sangbeom Kim wrote:
> On Mon, Oct 03, 2011 at 6:15:03AM , Arnd Bergmann wrote:
> > It's a bug that I only observed on exynos4, and it could be that
> > this patch didn't actually solve it in the end. I'll drop it for
> > now and do a better report when the problem comes back.
>
> Could you please explain problem which observed on exynos4?
> If possible, I want to check it too.
Sorry, I can't reproduce it any more. It could have been something
unrelated like a Kconfig or toolchain problem that got fixed in
the meantime. I really should have dropped that one hunk from
the patch. The other problem in this patch is still there, with
CONFIG_SND_SOC_SMDK_WM8994_PCM=y and CONFIG_MFD_WM8994=n:
sound/built-in.o: In function `wm8994_resume':
last.c:(.text+0x1f600): undefined reference to `wm8994_reg_read'
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_codec_probe':
last.c:(.text+0x2029c): undefined reference to `wm8994_reg_read'
last.c:(.text+0x20480): undefined reference to `wm8994_reg_read'
last.c:(.text+0x204b4): undefined reference to `wm8994_reg_read'
sound/built-in.o: In function `wm8994_write':
last.c:(.text+0x20e68): undefined reference to `wm8994_reg_write'
last.c:(.text+0x20ea4): undefined reference to `wm8994_reg_write'
sound/built-in.o: In function `wm8958_dsp2_fw':
last.c:(.text+0x2159c): undefined reference to `wm8994_bulk_write'
Arnd
^ permalink raw reply
* [alsa-devel] [PATCH 5/6] ASoC: samsung: fix Kconfig dependencies
From: Mark Brown @ 2011-10-03 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1869072.QQLATNzYYx@wuerfel>
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...
^ permalink raw reply
* [GIT PULL] Samsung devel-2 for v3.2
From: Mark Brown @ 2011-10-03 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003112235.GD11710@n2100.arm.linux.org.uk>
On Mon, Oct 03, 2011 at 12:22:35PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 03, 2011 at 11:36:26AM +0100, Mark Brown wrote:
> > It's possible it's something that doesn't manifest on that board, I've
> > no real idea what's exploding or why. There's also a bunch of other
> > early boot problems right now like try_to_freeze() which aren't helping.
> I don't know whether I can solve that before the next merge window.
> There's lots of corner cases, and I'm no longer convinced that my
> previous patch doesn't introduce more problems than it solves (such
> as completely breaking the -ERESTART_RESTARTBLOCK handing.)
> While it's possible to shut up the warning by enabling IRQs, that makes
> the race for restarting (or not restarting) syscalls *huge*, and that
> could cause unexpected userspace behaviour depending on whether they
> handle EINTR and _how_ they handle EINTR on system calls which they
> expect would've been restarted by the kernel.
It looks like the patches to stop it happening constantly have been
applied so it's a much less serious problem than it was originally - we
can boot and run reasonably cleanly. It's certainly not the crippling
issue it was originally.
^ permalink raw reply
* [RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading
From: Dave Martin @ 2011-10-03 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001164655.GL11710@n2100.arm.linux.org.uk>
On Sat, Oct 01, 2011 at 05:46:55PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 30, 2011 at 05:56:39PM +0100, Dave Martin wrote:
> > Issues:
> >
> > * Do new module alises need to be globally agreed/registered
> > somewhere?
>
> I don't think there is. Having the bus prefix in there is definitely a
> good thing.
OK, I'll stick with "amba:" for now, then.
> > * Because a driver's ID table is in match-and-mask format whereas
> > udev uses string pattern matching, we effectively have to
> > maintain two ID tables per driver, containing the same
> > information in different formats. The patch to mmci.c gives an
> > example.
> >
> > I predict that maintenance of those duplicated tables will be
> > somewhat painful and error-prone. However, the necessary
> > transformations, while simple, are beyond the scope of the C
> > preprocessor.
> >
> > In order to avoid this duplication of information, an extra
> > (but simple) bit of build-time infrastructure would be needed.
> >
> > I think this effort would be worth it -- does anyone have
> > strong views on this?
>
> I think there is some support for udev to use PCI ID tables directly.
> I don't know how that works - I suspect it requires module tools
> support though. Might be worth investigating.
Hmmm, it looks like there's some magic for other bus types like PCI and
USB, where some scripting generates appropriate module aliases from
drivers' device tables (see scripts/mod/file2alias.c)
I'll see whether we can hook into that. This would allow us to avoid
having to describe the aliases explicitly.
Thanks for the feedback.
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 0/2] arm: omap4: hsmmc: pbias fixes
From: Balaji T K @ 2011-10-03 12:22 UTC (permalink / raw)
To: linux-arm-kernel
MMC1 pbias and speed control fix for SDMMC1 extended I/O cell
Rebase to git://github.com/tmlind/linux.git fixes
commit 122a98589349fe3388ffb7b996b54614951c934a
Author: Tapani Utriainen <tapani@technexion.com>
Date: Fri Sep 30 11:05:56 2011 -0700
ARM: OMAP: irq: loop counter fix in omap_init_irq()
Balaji T K (2):
arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
arm: omap4: hsmmc: configure SDMMC1_DR0 properly
arch/arm/mach-omap2/hsmmc.c | 16 +++-------------
1 files changed, 3 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
From: Balaji T K @ 2011-10-03 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317644571-25175-1-git-send-email-balajitk@ti.com>
MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF otherwise VMODE_ERROR
interrupt is generated due to mismatch in input (regulator)
voltage and MMC IO drive voltage.
Delete incorrect comments which are not applicable for OMAP4.
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
Reported-by: Viswanath Puttagunta <vishp@ti.com>
---
v2:
update description
arch/arm/mach-omap2/hsmmc.c | 14 ++------------
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 097a42d..9cc2eb7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -129,15 +129,11 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
* card with Vcc regulator (from twl4030 or whatever). OMAP has both
* 1.8V and 3.0V modes, controlled by the PBIAS register.
- *
- * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
- * is most naturally TWL VSIM; those pins also use PBIAS.
- *
- * FIXME handle VMMC1A as needed ...
*/
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK);
+ OMAP4_MMC1_PWRDNZ_MASK |
+ OMAP4_MMC1_PBIASLITE_VMODE_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
@@ -172,12 +168,6 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
reg &= ~(OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
- } else {
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
- reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_MMC1_PBIASLITE_VMODE_MASK);
- omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 2/2] arm: omap4: hsmmc: configure SDMMC1_DR0 properly
From: Balaji T K @ 2011-10-03 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317644571-25175-1-git-send-email-balajitk@ti.com>
Fix the typo, instead it should be SDMMC1
USBC1 is not related to MMC1 I/Os
Signed-off-by: Balaji T K <balajitk@ti.com>
---
arch/arm/mach-omap2/hsmmc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9cc2eb7..1a9bc52 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -495,7 +495,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
OMAP4_SDMMC1_PUSTRENGTH_GRP1_MASK);
reg &= ~(OMAP4_SDMMC1_PUSTRENGTH_GRP2_MASK |
OMAP4_SDMMC1_PUSTRENGTH_GRP3_MASK);
- reg |= (OMAP4_USBC1_DR0_SPEEDCTRL_MASK|
+ reg |= (OMAP4_SDMMC1_DR0_SPEEDCTRL_MASK |
OMAP4_SDMMC1_DR1_SPEEDCTRL_MASK |
OMAP4_SDMMC1_DR2_SPEEDCTRL_MASK);
omap4_ctrl_pad_writel(reg, control_mmc1);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
From: Kukjin Kim @ 2011-10-03 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5785830.Sj7W4aL3qy@wuerfel>
On 10/03/11 18:33, Arnd Bergmann wrote:
> On Monday 03 October 2011 13:02:16 Kyungmin Park wrote:
>> I'm afraid to change machine directory name again. mach-s5pv310 ->
>> mach-exynos4 -> mach-exynos.
>> As I remember linus blamed the renaming the file names are happened
>> frequently at ARM
>
> I tend to agree with this. While the new name does make more sense,
> I would first like to see the bigger plan. If you are eventually
> planning to consolidate all of mach-s5p64x0, mach-s5pc100, mach-s5pv210,
> mach-exynos4 and plat-s5p into one common mach-s5p or mach-exynos
> directory, I'm all for that because it reduces code duplication
> and work required for the overall cross-subarchitecture single zimage
> work.
>
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.
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 :)
And then current mach-s5pxxxx stuff will be merged into mach-s5p. As I
talked to Ben Dooks, he also have a plan to merging mach-s3cxxxx stuff.
> Simply renaming something because the name does not quite fit entirely
> should be done very carefully.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v6 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-10-03 13:06 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 v6] 1/3] arm/tegra: prepare Seaboard pinmux code for derived boards
From: Peter De Schrijver @ 2011-10-03 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647209-22303-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] arm/tegra: select AUTO_ZRELADDR by default
From: Peter De Schrijver @ 2011-10-03 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647209-22303-1-git-send-email-pdeschrijver@nvidia.com>
This patch causes the kernel uncompressor to determine the physical address
of the SDRAM at runtime. This allows the kernel to boot on both tegra2 and
tegra3 even though SDRAM is at different physical addresses on both SoCs.
Change-Id: I91857a590946bbc54168c04bea3a5bd576d87824
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4fda167..9fc0678 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -600,6 +600,7 @@ config ARCH_TEGRA
select HAVE_CLK
select HAVE_SCHED_CLOCK
select ARCH_HAS_CPUFREQ
+ select AUTO_ZRELADDR
help
This enables support for NVIDIA Tegra based systems (Tegra APX,
Tegra 6xx and Tegra 2 series).
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [[PATCH v6] 2/3] arm/tegra: add support for ventana pinmuxing
From: Peter De Schrijver @ 2011-10-03 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647209-22303-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 v6] 3/3] arm/tegra: device tree support for ventana board
From: Peter De Schrijver @ 2011-10-03 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647209-22303-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..80008e9 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].name)) {
+ 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 V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
From: Kukjin Kim @ 2011-10-03 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2Wc4M2dVFOfNE5jgsygvigE8RbPH_yLcMqarr64LfbENw@mail.gmail.com>
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:
>> This patch adds macro SAMSUNG_RES_MEM, SAMSUNG_RES_IRQ
>> and so on to cleanup regarding 'struct resource' by using
>> defined helpers at<linux/ioport.h>.
>>
>> Cc: Ben Dooks<ben-linux@fluff.org>
>> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com>
>> ---
>> Changes since v1:
>> - Address comments from Russell King
>> Using defined helpers to define resource
>>
>> arch/arm/mach-s3c2410/include/mach/map.h | 1 +
>> arch/arm/plat-samsung/devs.c | 697 +++++------------------------
>> arch/arm/plat-samsung/include/plat/devs.h | 11 +
>> 3 files changed, 129 insertions(+), 580 deletions(-)
>>
(snip)
>>
>> +#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.
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.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Peter De Schrijver @ 2011-10-03 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647209-22303-3-git-send-email-pdeschrijver@nvidia.com>
Ignore this one.
Sorry,
Peter.
^ permalink raw reply
* [PATCH v6 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-10-03 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647209-22303-1-git-send-email-pdeschrijver@nvidia.com>
Forget this one. It lacks the important fix. It's monday I guess :)
Peter
^ permalink raw reply
* [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