On 08/30/2013 10:10 AM, jean-philippe francois wrote:
2013/8/30 Christian Hoffmann :
This also went to: linaro-ker...@lists.linaro.org
Hi,
current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack below.
System is generally quite unstable. Light usage (postfix+dovecot...)
Full dm
On Wed, Sep 4, 2013 at 11:06 AM, Tony Lindgren wrote:
> * Russ Dill [130903 09:52]:
>> The generic SRAM mechanism does not ioremap memory in a
>> manner that allows code to be executed from SRAM. There is
>> currently no generic way to request ioremap to return a
>> memory area with execution all
On Thursday 04 April 2013 15:11:27 Laurent Pinchart wrote:
> Hi Sakari,
>
> On Thursday 04 April 2013 01:22:28 Sakari Ailus wrote:
> > On Tue, Mar 26, 2013 at 12:07:01AM +0100, Laurent Pinchart
wrote:
> > > On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote:
> > > > Pali Rohár wrote:
> > > > > O
On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote:
> On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote:
> > Hi,
> >
> > On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote:
> > > I'm sending ADP1653 flash torch board code for Nokia
> > > RX-51. Kernel driver ADP1653 is already in u
On 09/06/2013 02:15 PM, Mark Jackson wrote:
> On 06/09/13 20:13, Mark Jackson wrote:
>> On 23/08/13 20:53, Joel Fernandes wrote:
>>> HWMOD removal for MMC and Crypto is breaking edma_start as the events are
>>> being manually triggered due to unused channel list not being clear. Atleast
>>> breakag
On Fri, Sep 6, 2013 at 9:19 AM, Dave Martin wrote:
> On Fri, Sep 06, 2013 at 12:12:21PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
>> > SRAM handling code is in the process of being moved from arch directories
>> > into drivers/misc/sram.c
On Fri, Sep 6, 2013 at 4:12 AM, Russell King - ARM Linux
wrote:
> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
>> SRAM handling code is in the process of being moved from arch directories
>> into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
>> patchset builds
On 23/08/13 20:53, Joel Fernandes wrote:
> HWMOD removal for MMC and Crypto is breaking edma_start as the events are
> being manually triggered due to unused channel list not being clear. Atleast
> breakage has been seen on these peripherals, but it is expected Audio (McASP)
> maybe breaking too.
>
On 06/09/13 20:13, Mark Jackson wrote:
> On 23/08/13 20:53, Joel Fernandes wrote:
>> HWMOD removal for MMC and Crypto is breaking edma_start as the events are
>> being manually triggered due to unused channel list not being clear. Atleast
>> breakage has been seen on these peripherals, but it is ex
On Fri, Sep 6, 2013 at 9:40 AM, Dave Martin wrote:
> On Fri, Sep 06, 2013 at 12:14:08PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
>> > I think this is already taken care of by the way sram.c is using
>> > genalloc. The allocation returned
On Fri, Sep 6, 2013 at 4:14 AM, Russell King - ARM Linux
wrote:
> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
>> I think this is already taken care of by the way sram.c is using
>> genalloc. The allocation returned should be aligned to 32 bytes. The
>> thumb bit shouldn't be an issu
Hi George,
On 09/06/2013 03:21 AM, George Cherian wrote:
> Add mmc nodes for am33xx platforms
>
> Signed-off-by: George Cherian
> ---
> Verified after applying [1] and [2]
> [1] - [PATCH v4 0/6] dma: edma: Support scatter-lists of any length -
> https://lkml.org/lkml/2013/8/29/466
> [2] - [PATC
On Fri, Sep 06, 2013 at 12:12:21PM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
> > SRAM handling code is in the process of being moved from arch directories
> > into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
> > patc
On Fri, Sep 06, 2013 at 12:14:08PM +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
> > I think this is already taken care of by the way sram.c is using
> > genalloc. The allocation returned should be aligned to 32 bytes. The
> > thumb bit shouldn'
Hi Linus,
Sorry for the late reply.
On Thursday 22 August 2013 00:02:39 Linus Walleij wrote:
> On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart wrote:
> > On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
> >> I don't see how sharing works here, or how another user, i.e. another one
> >>
Op 6 sep. 2013, om 10:51 heeft Koen Kooi het
volgende geschreven:
>
> Op 6 sep. 2013, om 09:10 heeft Koen Kooi het
> volgende geschreven:
>
>>
>> Op 6 sep. 2013, om 08:57 heeft George Cherian het
>> volgende geschreven:
>>
>>> On 9/6/2013 12:03 PM, Koen Kooi wrote:
The BeagleBone B
On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
> I think this is already taken care of by the way sram.c is using
> genalloc. The allocation returned should be aligned to 32 bytes. The
> thumb bit shouldn't be an issue as code is copied based on the start
> and end makers made by the li
On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
> SRAM handling code is in the process of being moved from arch directories
> into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
> patchset builds on that, including the limitation that the SRAM address is
> not known
On Thursday 05 September 2013 03:17 AM, Russ Dill wrote:
> On Wed, Sep 4, 2013 at 12:52 PM, Emilio López wrote:
>> I'm interested in this, as I'll need something like it for suspend/resume on
>> sunxi. Unfortunately, I only got the cover letter on my email, and the web
>> lakml archives don't see
The primary function of VPDMA is to move data between external memory and
internal processing modules(in our case, VPE) that source or sink data. VPDMA is
capable of buffering this data and then delivering the data as demanded to the
modules as programmed. The modules that source or sink data are r
Create functions which the VPE driver can use to create a VPDMA descriptor and
add it to a VPDMA descriptor list. These functions take a pointer to an existing
list, and append the configuration/data/control descriptor header to the list.
In the case of configuration descriptors, the creation of a
Add support for the de-interlacer block in VPE.
For de-interlacer to work, we need to enable 2 more sets of VPE input ports
which fetch data from the 'last' and 'last to last' fields of the interlaced
video. Apart from that, we need to enable the Motion vector output and input
ports, and also allo
VPE(Video Processing Engine) is an IP found on DRA7xx, this series adds VPE as a
mem to mem v4l2 driver, and VPDMA as a helper library.
The first version of the patch series described VPE in detail, you can have a
look at it here:
http://www.spinics.net/lists/linux-media/msg66518.html
Changes in
Op 6 sep. 2013, om 09:10 heeft Koen Kooi het
volgende geschreven:
>
> Op 6 sep. 2013, om 08:57 heeft George Cherian het
> volgende geschreven:
>
>> On 9/6/2013 12:03 PM, Koen Kooi wrote:
>>> The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI
>>> added,
>>> so create
> "Olof" == Olof Johansson writes:
Hi Olof,
Thanks for the review!
>> +/**
>> + * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
>> + * ethernet hwaddr from efuse
>> + * @np:Pointer to the cpsw slave to set mac address of
>> + * @idx: Mac address index
Add mmc nodes for am33xx platforms
Signed-off-by: George Cherian
---
Verified after applying [1] and [2]
[1] - [PATCH v4 0/6] dma: edma: Support scatter-lists of any length -
https://lkml.org/lkml/2013/8/29/466
[2] - [PATCH v2] ARM: dts: add AM33XX EDMA support -
https://lkml.org/lkml/2013/8/26
On 9/6/2013 12:40 PM, Koen Kooi wrote:
Op 6 sep. 2013, om 08:57 heeft George Cherian het
volgende geschreven:
On 9/6/2013 12:03 PM, Koen Kooi wrote:
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use. MMC support for AM335x s
The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added,
so create a common dtsi both can use. MMC support for AM335x still isn't in, so
only the LDO change has been added.
Signed-off-by: Koen Kooi
---
Changes since v1:
Added the Makefile entry for the new dts
a
Op 6 sep. 2013, om 08:57 heeft George Cherian het
volgende geschreven:
> On 9/6/2013 12:03 PM, Koen Kooi wrote:
>> The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI
>> added,
>> so create a common dtsi both can use. MMC support for AM335x still isn't in,
>> so
>> only
29 matches
Mail list logo
