On 07/30/2013 01:07 AM, Chen Baozi wrote:
On Jul 30, 2013, at 11:52 AM, Lokesh Vutla wrote:
Hi Chen,
On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote:
Hi all,
I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux
On Tue, Jul 30, 2013 at 1:52 AM, Tony Lindgren wrote:
> * Benoit Cousson [130729 15:24]:
>> On 29/07/2013 19:03, Nishanth Menon wrote:
>> > Due to wrong older revision of documentation used as reference, we
>> > seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
>> > series is ba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095:
Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
tags/fo
Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast(). It turns out that g
From: R Sricharan
The IO descriptor tables for DRA7 are a complete reuse from OMAP5.
A new dra7xx_init_early() does the base address inits.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c | 22 +
From: R Sricharan
Describe minimal DT boot machine details for DRA7xx based SoC's. DRA7xx
family is based on dual core ARM CORTEX A15 using GIC as the interrupt
controller.
The PRCM and timer infrastructure is reused from OMAP5 and so are the io
descriptor tables.
Signed-off-by: R Sricharan
Si
The soc_ops for dra7xx devices can be completed reused
from the ones used for omap4 and omap5 devices.
Signed-off-by: Rajendra Nayak
Signed-off-by: R Sricharan
---
arch/arm/mach-omap2/omap_hwmod.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hw
Changes in v2:
-1- Fixed minor changelog details
-2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c
-3- Added DTS update patches to this series which were earlier posted as
part of the data series (Since they don't have much objections as against the
other in-kernel dat
From: R Sricharan
The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture integrated on a 28-nm technology.
DRA7xx family is composed of DRA75x and DRA74x devices.
Adding the DRA752 ES1.0 cpu revision detection support.
Signed-off-by: R Sricharan
From: R Sricharan
DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
and other TWL GPIOs, ARCH_NR_GPIO is set to 512 using the
kconfig default for DRA7.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/Kconf
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart
From: R Sricharan
All of OMAP5 timer support for clocksource and clockevent is completely
reused across DRA7.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/Kconfig |2 +-
arch/arm/mach-omap2/timer.c |3 ++-
2 files changed, 3 insertions(+), 2 deletio
From: R Sricharan
The PRCM and MPUSS parts of DRA7 devices are quite identical
to OMAP5 so as to reuse all the existing infrastructure around it.
Makefile updates to do just that.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/Makefile |8
1 file
Hi Will
On Mon, 29 Jul 2013, Will Deacon wrote:
> I wouldn't worry about checking for CPU_V6. Besides, we probably need this
> to be re-evaluated across barrier() when we get CPU migration on a
> big-little platform anyway (we should probably also drop the
> __attribute_const__ for that).
>
> So
On Tue, 30 Jul 2013, Rajendra Nayak wrote:
> Looks like this one is already been queued by Greg.
OK, thanks for letting me know; I've dropped it.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On 07/30/2013 09:56 AM, Tony Lindgren wrote:
> A separate minimal branch against -rc3 sounds good to me.
Great. Felipe, can you please put this change in a separate -rc3 based
branch which you and Tony will pull in?
> Regards,
>
> Tony
>
Sebastian
--
To unsubscribe from this list: send the lin
On 07/30/2013 07:19 AM, George Cherian wrote:
>> So from what I see now, it is most likely the easiest thing to just add
>> that wakeup to the phy driver I posted. Do you agree?
>
> The whole idea of writing a seperate phy driver was to use the generic
> phy framework
> and most of the am devi
On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
> We certainly don't want error conditions to be cleared anywhere
'anywhere' is a really loaded term.
> as this will make us 'forget' about missed events. We depend on
> knowing which events were missed in order to be able to reissue them.
>
On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> >> the list of controller device (names) it can support (PHY framework
> >>
On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
>> the list of controller device (names) it can support (PHY framework does
>> not
>> maintain a separate list for binding like how we had in USB PHY
* Sebastian Andrzej Siewior [130730 00:41]:
> On 07/30/2013 09:08 AM, Tony Lindgren wrote:
> > Looking at this patch there's a pretty high probability of introducing
> > pointless merge conflicts.
> >
> > How about do the platform data related changes as a separate follow-up
> > series? You can t
Hi,
On Tue, Jul 30, 2013 at 01:04:28PM +0530, Sourav Poddar wrote:
> Hi Felipe,
> On Monday 29 July 2013 06:05 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Mon, Jul 29, 2013 at 04:45:02PM +0530, Sourav Poddar wrote:
> + irq = platform_get_irq(pdev, 0);
> + if (irq< 0) {
> >
On 07/30/2013 06:53 AM, George Cherian wrote:
> Control module have 2 separate registers for phy on/off per instance
> (offset 0x620 and 0x628), where as
> wkup_ctrl is a shared control module register (offset 0x648). Currently
> the control module driver maps
> memory from 0x620 till beyond 0x64
On 07/30/2013 09:08 AM, Tony Lindgren wrote:
> Looking at this patch there's a pretty high probability of introducing
> pointless merge conflicts.
>
> How about do the platform data related changes as a separate follow-up
> series? You can typically do this by keeping the old features around,
> th
Hi Felipe,
On Monday 29 July 2013 06:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 29, 2013 at 04:45:02PM +0530, Sourav Poddar wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq< 0) {
+ dev_err(&pdev->dev, "no irq resource?\n");
+ return irq;
+ }
Hi,
On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> the list of controller device (names) it can support (PHY framework does
> not
> maintain a separate list for binding like how we had in USB PHY
> library). e.g.
> http://www.mail-archive.com/l
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
> On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
> > On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
> > > Hi,
> > >
> > > On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> > > > Hi,
> > > >
> > > > On Sat
On Tuesday 30 July 2013 12:09 PM, Tomi Valkeinen wrote:
On 30/07/13 09:21, Archit Taneja wrote:
Hi,
On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
Use the new display drivers for OMAP3 Overo board.
The new OMAP display drivers were merged for 3.11, and we can now change
the board file
* Felipe Balbi [130729 05:27]:
> On Fri, Jul 26, 2013 at 10:15:54PM +0200, Sebastian Andrzej Siewior wrote:
> > The "nop" driver isn't a do-nothing-stub but supports a couple functions
> > like clock on/off or is able to use a voltage regulator. This patch
> > simply renames the driver to "generic
On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
> In an effort to move to using Scatter gather lists of any size with
> EDMA as discussed at [1] instead of placing limitations on the driver,
> we work through the limitations of the EDMAC hardware to find missed
> events and issue them.
>
>
101 - 130 of 130 matches
Mail list logo
