From: Kevin Hilman khil...@ti.com
There are certain fields inside 'struct dpll_data' which are
included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it
difficult to use it for new devices like, am33xx, ti81xx, etc...
So remove the ifdef completely, this will add few fields to the struct
On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
The function __omap2_set_globals() can be common across all
platforms/architectures, even
Vaibhav,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..095bee8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,7 @@ struct dpll_data {
u8
Hi Vaibhav,
Sricharan,
Yesterday, Paul confirmed that, removing ifdef is the way to go. So
just few mins back I had submitted patch for the same.
http://permalink.gmane.org/gmane.linux.ports.arm.omap/76972
oh ya, was just looking at that.
Thanks,
Sricharan
--
To unsubscribe from this
On Fri, May 11, 2012 at 11:46:32, R, Sricharan wrote:
Vaibhav,
[snip]
Waiting for Paul to conform here.
Thanks for pointing that out. Will check on this and Paul's PRCM series
cleanup series then.
Sricharan,
Yesterday, Paul confirmed that, removing ifdef is the way to go. So
just few
On Fri, May 11, 2012 at 11:32 AM, Vaibhav Hiremath hvaib...@ti.com wrote:
From: Kevin Hilman khil...@ti.com
There are certain fields inside 'struct dpll_data' which are
included under ARCH_OMAP3 and ARCH_OMAP4 option, which makes it
difficult to use it for new devices like, am33xx, ti81xx,
Vaibhav,
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle
sdrc,
so that we can reuse same function across omap2/3/4...
But what happens when a single kernel is built that has support
for an
SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
As such
On Fri, May 11, 2012 at 12:07:59, R, Sricharan wrote:
Vaibhav,
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle
sdrc,
so that we can reuse same function across omap2/3/4...
But what happens when a single kernel is built that has support
for an
SoC with an
On Fri, May 11, 2012 at 03:19:21, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 00:09:34, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
With addition to TI81XX, AM33XX family of devices, the number
of interrupts supported has
On Fri, May 11, 2012 at 03:06:48, Janusz Krzysztofik wrote:
Dnia czwartek, 3 maja 2012 13:28:58 Vaibhav Hiremath pisze:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or
On Fri, May 11, 2012 at 04:32:11, Paul Walmsley wrote:
On Wed, 9 May 2012, Vaibhav Hiremath wrote:
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops
[+sfr]
On Thu, May 10, 2012 at 1:24 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [120510 11:55]:
* Tony Lindgren t...@atomide.com [120510 11:49]:
The following changes since commit
bfd17879866b36e95c58721da070d9f2ac7f8901:
Merge tag
Tony,
I've pulled all 10 requests. Many of them ended up going into the same
next/ branch, but that's quite OK. Please double check my merge
conflict resolutions.
One nit is that at least one of the branches had a few varying patch
subjects, so just a friendly reminder to sanitize them to ARM:
arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
arch/arm/plat-omap/usb.c:40: warning: unused variable 'status'
caused by:
commit eeb3711b89d68e147e05e7b43a49ecc5009dc157
Author: Paul Walmsley p...@pwsan.com
Date: Fri Apr 13 06:34:32 2012 -0600
ARM: OMAP2+: clean up some cppcheck
On Fri, May 11, 2012 at 11:25:24AM +0530, joseph daniel wrote:
The warning shown up when ran with randconfig,
warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct
dependencies (USB_SUPPORT USB_XHCI_HCD)
Signed-off-by: joseph daniel josephdanielwal...@gmail.com
---
Hello Olof,
On Fri, 11 May 2012, Olof Johansson wrote:
I did notice that omap2plus_defconfig has grown a new warning caused
by ARM: OMAP2+: clean up some cppcheck warnings (oh, the irony!):
arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
arch/arm/plat-omap/usb.c:40:6: warning:
On Fri, 11 May 2012, Russell King - ARM Linux wrote:
arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
arch/arm/plat-omap/usb.c:40: warning: unused variable 'status'
caused by:
commit eeb3711b89d68e147e05e7b43a49ecc5009dc157
Author: Paul Walmsley p...@pwsan.com
Date: Fri Apr 13
On Thu, May 10, 2012 at 6:05 AM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup
On Fri, May 11, 2012 at 1:33 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Olof,
On Fri, 11 May 2012, Olof Johansson wrote:
I did notice that omap2plus_defconfig has grown a new warning caused
by ARM: OMAP2+: clean up some cppcheck warnings (oh, the irony!):
arch/arm/plat-omap/usb.c: In
Hi Paul,
On 5/10/2012 7:29 PM, Paul Walmsley wrote:
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 1 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled state can only be
On Fri, May 11, 2012 at 12:41 AM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120510 06:09]:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where
On Fri, May 11, 2012 at 2:04 PM, Russ Dill russ.d...@gmail.com wrote:
On Thu, May 10, 2012 at 6:05 AM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart
Hi Benoît
On Fri, 11 May 2012, Cousson, Benoit wrote:
I do not have any clue about that chip, but is this clock really what it is
supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or
something like that. Don't we just have an issue becasue the clock names are
not
Hi Kevin,
On Tue, May 08, 2012 at 10:19:02AM -0700, Kevin Hilman wrote:
After converstion to SPARSE_IRQ, the driver doesn't use the
pdata-irq_base/irq_end fields anymore. The last users
have been cleanup up, and now these fields can be removed.
Cc: Benoit Cousson b-cous...@ti.com
Cc:
On 5/11/2012 11:22 AM, Paul Walmsley wrote:
Hi Benoît
On Fri, 11 May 2012, Cousson, Benoit wrote:
I do not have any clue about that chip, but is this clock really what it is
supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or
something like that. Don't we just have
On Fri, 11 May 2012, Cousson, Benoit wrote:
On 5/11/2012 11:22 AM, Paul Walmsley wrote:
On the rest of the OMAPs, as far as I know, the UART clocks are all
separate.
In fact, not really. The same PER_48M_GFCLK clock is used for every UART
instances in OMAP4. We do have a separate
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads were used in
different mode by any other module then it
On 5/11/2012 11:35 AM, Paul Walmsley wrote:
On Fri, 11 May 2012, Cousson, Benoit wrote:
On 5/11/2012 11:22 AM, Paul Walmsley wrote:
On the rest of the OMAPs, as far as I know, the UART clocks are all
separate.
In fact, not really. The same PER_48M_GFCLK clock is used for every UART
Hi Felipe,
On Fri, May 11, 2012 at 1:27 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, May 11, 2012 at 11:25:24AM +0530, joseph daniel wrote:
The warning shown up when ran with randconfig,
warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct
dependencies (USB_SUPPORT
The warning shown up when ran with randconfig,
warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct
dependencies (USB_SUPPORT USB_XHCI_HCD)
Signed-off-by: joseph daniel josephdanielwal...@gmail.com
---
drivers/usb/dwc3/Kconfig |2 +-
1 file changed, 1 insertion(+), 1
On Fri, 11 May 2012, Cousson, Benoit wrote:
But they are not separately gated for OMAP4 either. This is the modulemode
trick that make us think that, but it just means that the PRCM should ensure
that this clock is needed when at least one UART modulemode is enabled. In
fact the SPI modules
Hello.
On 11-05-2012 9:55, joseph daniel wrote:
The warning shown up when ran with randconfig,
warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies
(USB_SUPPORT USB_XHCI_HCD)
Signed-off-by: joseph danieljosephdanielwal...@gmail.com
---
On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
For my testing I have just been reading the PM_EMU_PWRSTST register which
shows the power state of the EMU power domain. It should read 3 when the
power domain is ON and 0 when it is off. I did something like the
Hi Tony,
Here are some remaining DT patches I was not able to push at 3.4 due to some
missing dependency.
It applies now fine on top of lo/dt branch.
Regards,
Benoit
The following changes since commit 40364b9f5a4d167d97bb6a76cd239ca8cfff056a:
Benoit Cousson (1):
arm/dts:
On Thu, 2012-05-10 at 20:56 -0500, Ricardo Neri wrote:
Sorry, some hunks where missing in the patch that I submitted yesterday.
I just pushed a branch containing the whole most up-to-date series here:
git://gitorious.org/omap-audio/linux-audio.git
ricardon/topic/dss_audio-for-tomi
On Fri, 2012-05-04 at 12:29 -0700, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [120425 05:32]:
On Tue, 2012-04-24 at 10:16 -0700, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [120423 00:43]:
Add statics to board-omap4-panda.c's internal functions and data
Hi Will
On 05/11/2012 07:25 AM, Will Deacon wrote:
On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
For my testing I have just been reading the PM_EMU_PWRSTST register which
shows the power state of the EMU power domain. It should read 3 when the
power
On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
On 05/11/2012 07:25 AM, Will Deacon wrote:
I figured I may as well take perf for a spin and see how I got on. The good
news is that the hwmod bits all seem to work as before and the correct IRQs
are requested:
Timers in PER domain periodically report old time from TCRR in posted mode
unless ICLK = 4 * FCLK. The problem is addressed in the following manner:
Patch 1: Adds ick alias in the clkdev table so that dmtimer code can
extract the iclk rate using clk_get_rate().
Patch 2: The final logic added in
From: Rajendra Nayak rna...@ti.com
For all hwmods' with just one slave interface, use the
slave-clk to add an 'ick' clkdev alias in the table.
This is useful for drivers of such devices to get
the interface clock using 'clk_get(dev, ick)'
Signed-off-by: Rajendra Nayak rna...@ti.com
---
Timers in PER domain periodically report old time from TCRR in
posted mode if ick 4*fck. Therefore, set timer to non-posted
whenever ick 4*fck for all timers.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 12
1 files changed, 12
On Wed, 2012-05-09 at 16:27 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
Restore all CM1/2 module registers as they are lost in OFF mode.
Except they are still lost since nobody calls these new functions (in
this patch.) :)
For
Hi Will,
On 05/11/2012 08:49 AM, Will Deacon wrote:
On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
On 05/11/2012 07:25 AM, Will Deacon wrote:
I figured I may as well take perf for a spin and see how I got on. The good
news is that the hwmod bits all seem to work as before and the
On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
Hi Will,
Hello,
On 05/11/2012 08:49 AM, Will Deacon wrote:
I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
I tried the same (make omap2plus_defconfig and enabled the above
option), and I do see the
* Olof Johansson o...@lixom.net [120511 00:25]:
Tony,
I've pulled all 10 requests. Many of them ended up going into the same
next/ branch, but that's quite OK. Please double check my merge
conflict resolutions.
One nit is that at least one of the branches had a few varying patch
* Olof Johansson o...@lixom.net [120511 01:41]:
On Fri, May 11, 2012 at 1:33 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Olof,
On Fri, 11 May 2012, Olof Johansson wrote:
I did notice that omap2plus_defconfig has grown a new warning caused
by ARM: OMAP2+: clean up some cppcheck
On Thu, 2012-05-10 at 19:45 +0200, Ivan Djelic wrote:
On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote:
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote:
But in order to do so, I need the changes that Afzal has submitted
(in particular [3]). Those changes (and as a
Hi,
This series provides the ability for OMAP NAND driver to configure
GPMC_NAND registers by NAND driver itself instead of using GPMC
exported symbols.
Regards
Afzal
Afzal Mohammed (3):
ARM: OMAP2+: gpmc: update nand register helper
ARM: OMAP2+: gpmc-nand: update gpmc-nand regs
mtd:
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |
GPMC driver has been modified to fill NAND platform data with GPMC
NAND register details. As these registers are accessible in NAND
driver itself, configure NAND in GPMC by itself.
Modified prefetch and ecc functions are logically same as the
corresponding exported symbols from GPMC code.
Note:
Hi Ivan,
On Thu, May 10, 2012 at 23:15:27, Ivan Djelic wrote:
So, when Afzal's patches are pushed, I'll submit a new, single MTD patch.
But this is not going to happen this merge window as I understood, may
be not even the next one. We need to make UBIFS happy sooner than that,
I
Hi Will,
On 05/11/2012 10:02 AM, Will Deacon wrote:
On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
Hi Will,
Hello,
On 05/11/2012 08:49 AM, Will Deacon wrote:
I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
I tried the same (make omap2plus_defconfig
On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
Can you send me your .config?
Sent off-list.
At the same time, maybe just try make omap2plus_defconfig and enable
the OMAP3 debug devices config. That's all I am doing.
Excellent, that works for me. Once we've worked out the problem
* Paul Walmsley p...@pwsan.com [120510 15:31]:
Janusz Krzysztofik reported the following build break on OMAP1 builds that
don't include CONFIG_ARCH_OMAP16XX:
LD .tmp_vmlinux1
arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init':
lcd_dma.c:(.init.text+0x1420): undefined
* Paul Walmsley p...@pwsan.com [120509 15:41]:
Tony reported the following compile warning after commit
eeb3711b89d68e147e05e7b43a49ecc5009dc157 (ARM: OMAP2+: clean up some
cppcheck warnings):
arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
arch/arm/plat-omap/usb.c:40: warning:
On Thu, 10 May 2012 07:23:56 -0700, Kevin Hilman khil...@ti.com wrote:
Grant,
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
Hi,
On Thu, May 10, 2012 at 3:06 AM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
On Mon, 7 May 2012 10:52:28 DebBarma, Tarun Kanti wrote:
On Sun, May
On Mon, 7 May 2012 10:52:28 +0530, DebBarma, Tarun Kanti tarun.ka...@ti.com
wrote:
Hi,
On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas nota...@gmail.com wrote:
I've noticed that current mainline enables _all_ possible GPIO
interrupts, this patch fixes that problem.
OK, thanks.
Also
On 05/10/2012 11:27 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120510 10:09]:
On 05/09/2012 02:49 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504
On Wed, May 9, 2012 at 6:15 AM, Minchan Kim minc...@kernel.org wrote:
On 05/09/2012 01:31 AM, S, Venkatraman wrote:
On Tue, May 8, 2012 at 1:16 PM, Minchan Kim minc...@kernel.org wrote:
On 05/03/2012 11:22 PM, Venkatraman S wrote:
Standard eMMC (Embedded MultiMedia Card) specification
Hi Arnd Olof,
Here are the fixes needed for the regressions caused by
omap-cleanup-sparse-for-v3.5. I suggest pulling this into
arm-soc/omap/cleanup-sparse where the issues got introduced.
Regards,
Tony
The following changes since commit 09f45b83109cb8e23a06d5efb1096a08a9545974:
Merge tag
On 05/10/2012 01:59 PM, Jassi Brar wrote:
On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/09/2012 03:38 PM, Jassi Brar wrote:
One point is about 'qos' here something like bandwidth allocation.
If the dmac driver knew up-front the max possible clients that could be
* Stephen Warren swar...@wwwdotorg.org [120511 12:21]:
The mapping of GPIO to pinctrl pins would presumably be driven solely by
the HW design of the pin controller and GPIO, and not by the mux
selection in the pin controller (otherwise, I'd argue this isn't a
simple case that should be
Hi,
* Cousson, Benoit b-cous...@ti.com [120511 05:51]:
Hi Tony,
Here are some remaining DT patches I was not able to push at 3.4 due to some
missing dependency.
It applies now fine on top of lo/dt branch.
It seems that there are still patches being discussed for those SoCs
and we're
* Mohammed, Afzal af...@ti.com [120509 23:39]:
Hi Tony,
On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote:
To resolve this and as per your earlier question on whether old along
with new interface can be made to work parallely, here is suggestion
from my end to deal with it.
* Afzal Mohammed af...@ti.com [120511 08:48]:
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Hmm this seems that it might
Hi,
* Sricharan R r.sricha...@ti.com [120510 10:47]:
Hi Tony,
-Original Message-
From: R Sricharan [mailto:r.sricha...@ti.com]
Sent: Thursday, May 03, 2012 12:56 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com;
On 05/11/2012 01:51 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120511 12:21]:
The mapping of GPIO to pinctrl pins would presumably be driven solely by
the HW design of the pin controller and GPIO, and not by the mux
selection in the pin controller (otherwise, I'd argue
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
I think arbitrary numerical tokens are a reasonable price to pay for the
robustness and simplicity they bring.
I have to disagree here.
Using phandle+ID is almost as simple, and much
From: Mark A. Greer mgr...@animalcreek.com
Paul, Kevin,
These patches convert the davinci emac support for the am35x SoC
to use hwmod and add enable_hlt()/disable_hlt() calls to the
pm_runtime hooks for that driver.
I have converted the davinci_emac driver to use pm_runtime but I
can't formally
From: Mark A. Greer mgr...@animalcreek.com
Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 92 ++--
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction
Hiremath, Vaibhav hvaib...@ti.com writes:
On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
The function __omap2_set_globals() can be common
Hi Kevin,
On Wed, 2 May 2012, Kevin Hilman wrote:
From 22726db6fc514cc5110db43fdf05d5afda8e4a59 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 1 May 2012 07:06:42 -0700
Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until
explicitly enabled.
By
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we
Hi Will,
On 05/11/2012 11:38 AM, Will Deacon wrote:
On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
Can you send me your .config?
Sent off-list.
At the same time, maybe just try make omap2plus_defconfig and enable
the OMAP3 debug devices config. That's all I am doing.
On 05/11/2012 07:51 AM, Tomi Valkeinen wrote:
On Thu, 2012-05-10 at 20:56 -0500, Ricardo Neri wrote:
Sorry, some hunks where missing in the patch that I submitted yesterday.
I just pushed a branch containing the whole most up-to-date series here:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
The following changes since commit 6edd94db250038c8fdf176f23ca4017d2f312509:
gpio/omap: fix incorrect initialization of omap_gpio_mod_init (2012-05-10
On Fri, 11 May 2012 17:30:48 -0700, Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
The following changes since commit 6edd94db250038c8fdf176f23ca4017d2f312509:
Hi Paul,
On Thu, May 10, 2012 at 11:33:44, Mohammed, Afzal wrote:
Hi Paul,
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break
On Fri, May 11, 2012 at 12:22 PM, Tony Lindgren t...@atomide.com wrote:
Hi Arnd Olof,
Here are the fixes needed for the regressions caused by
omap-cleanup-sparse-for-v3.5. I suggest pulling this into
arm-soc/omap/cleanup-sparse where the issues got introduced.
Regards,
Tony
The
81 matches
Mail list logo
