On Wed, Jun 30, 2010 at 11:28 PM, Hiroshi DOYU wrote:
> From: Hiroshi DOYU
>
> Hibernation (a.k.a: Suspend-To-Disk) support for ARM
>
> Based on the original work from Romit and Raghu at TI. The original
> patch(*1) was sent to LOML by Teerth Reddy
>
> *1: https://patchwork.kernel.org/patch/9644
On Thu, Nov 25, 2010 at 10:22 PM, David Brownell wrote:
> So there's no strong reason to think this is
> actually "ggeneric". Function names no longer
> specify OMAP, but without other hardware under
> the interface, calling it "generic" reflects
> more optimism than reality. (That was the
> imp
On Thu, Nov 25, 2010 at 9:59 PM, Olof Johansson wrote:
> On Tue, Nov 23, 2010 at 05:38:57PM +0200, Ohad Ben-Cohen wrote:
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>
> Not used.
pr_fmt() is a magic #define that changes the behaviour of the pr_*()
macros. See include/linux/kernel.h
g.
--
To
Hello,
We were wondering how to test McSPI on N800.
Is there any peripheral connected to McSPI?
Any inputs are welcome.
Thanking you,
With Regards,
Shubhro
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordom
On Thu, Nov 11, 2010 at 5:31 AM, Guenter Roeck
wrote:
> On Tue, Nov 09, 2010 at 04:20:57AM -0500, Keerthy wrote:
>> Introducing a driver for MADC on TWL4030 powerIC. MADC stands for
> monitoring
>> ADC. This driver monitors the real time conversion of analog signals
> like
>> battery temperature,
Olof Johansson,
On Fri, Nov 26, 2010 at 10:08, Olof Johansson wrote:
> Hi,
>
> On Tue, Nov 23, 2010 at 08:26:43PM +0530, Varadarajan, Charulatha wrote:
>> +static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
>> +{
>> + if (cpu_class_is_omap2()) {
>
> Why check class when you're che
Hi,
In addition to other comments from others, here are a few on the
implementation.
There's a fair amount of potentially spammy and redundant debug code
left in the generic code. I've commented on some of them below, but the
same comments would apply to other locations as well.
On Tue, Nov 23,
Hi,
On Tue, Nov 23, 2010 at 08:26:43PM +0530, Varadarajan, Charulatha wrote:
> +static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
> +{
> + if (cpu_class_is_omap2()) {
Why check class when you're checking for all possible variants anyway?
> + if (cpu_is_omap44xx()) {
On Wed, Nov 24, 2010 at 10:24:01PM +0800, Axel Lin wrote:
> In current implementation, there are resources leak in the error path.
> This patch properly reclaims the allocated resources in the error path.
>
> Also adds a missing clk_put in osk_soc_exit.
>
> Signed-off-by: Axel Lin
> Acked-by: Ja
On Thu, Nov 25, 2010 at 07:49:05PM +0200, Sakari Ailus wrote:
> Currently when two media entities are connected they will be powered up
> for the duration of the link setup, just in case the drivers would need
> to access hardware for some reason. I don't think we have a need for
> that at the mom
On Thu, 2010-11-25 at 08:40 +0200, Ohad Ben-Cohen wrote:
> On Thu, Nov 25, 2010 at 5:59 AM, David Brownell wrote:
> > My rule of thumb is that nothing is "generic"
> > until at least three whatever-it-is instances
> > plug in to it. Sometimes this is called
> > the "Rule of Three".
> >
> > Other
On Thursday, November 25, 2010, Oliver Neukum wrote:
> Am Donnerstag, 25. November 2010, 16:52:39 schrieb Alan Stern:
> > When a device is declared irq-safe in this way, the PM core increments
> > the parent's usage count, so the parent will never be runtime
> > suspended. This prevents difficult
unsubscribe linux-omap--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Donnerstag, 25. November 2010, 16:52:39 schrieb Alan Stern:
> When a device is declared irq-safe in this way, the PM core increments
> the parent's usage count, so the parent will never be runtime
> suspended. This prevents difficult situations in which an irq-safe
> device can't resume because
Paul,
On Thu, Nov 25, 2010 at 7:15 PM, Paul Walmsley wrote:
> Hi
>
> On Thu, 25 Nov 2010, Jean Pihet wrote:
>
>> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley wrote:
>> >
>> > The console semaphore must be held while the OMAP UART devices are
>> > disabled, lest a console write cause an ARM ab
On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley wrote:
> Hello Jean
>
> On Thu, 25 Nov 2010, Jean Pihet wrote:
>
>> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley wrote:
>> >
>> > The console semaphore must be held while the OMAP UART devices are
>> > disabled, lest a console write cause an ARM a
Hi
On Thu, 25 Nov 2010, Jean Pihet wrote:
> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley wrote:
> >
> > The console semaphore must be held while the OMAP UART devices are
> > disabled, lest a console write cause an ARM abort (and a kernel crash)
> > when the underlying console device is inacc
On Thu, 25 Nov 2010 12:20:31 -0500
Andy Walls wrote:
> The signedness of char is ambiguous for 8 bit data, which is why an API would
> normally use u8 (or s8, I guess).
>
> Since this is known to be character data, I would think char would be fine.
> I am assuming C compilers would never assu
Laurent Pinchart wrote:
> Hi Mark,
Hi Laurent, others,
> On Thursday 25 November 2010 14:49:08 Mark Brown wrote:
>> On Thu, Nov 25, 2010 at 03:28:12AM +0100, Laurent Pinchart wrote:
>>> If the entity is of node type, the power change is distributed to
>>> all connected entities. For non-n
On Thu, 25 Nov 2010, Janusz Krzysztofik wrote:
> Thursday 25 November 2010 08:02:01 Jarkko Nikula wrote:
> > On Wed, 24 Nov 2010 15:53:42 -0800
> >
> > Tony Lindgren wrote:
> > > * Tony Lindgren [101124 15:25]:
> > > > Anyways, Paul's patch should be merged during the -rc cycle
> > > > because i
Hello Jean
On Thu, 25 Nov 2010, Jean Pihet wrote:
> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley wrote:
> >
> > The console semaphore must be held while the OMAP UART devices are
> > disabled, lest a console write cause an ARM abort (and a kernel crash)
> > when the underlying console device
Hi Andy,
On Thursday 25 November 2010 18:20:31 Andy Walls wrote:
> The signedness of char is ambiguous for 8 bit data, which is why an API
> would normally use u8 (or s8, I guess).
>
> Since this is known to be character data, I would think char would be fine.
I think so too.
> I am assuming C
The signedness of char is ambiguous for 8 bit data, which is why an API would
normally use u8 (or s8, I guess).
Since this is known to be character data, I would think char would be fine. I
am assuming C compilers would never assume multibyte "char"s.
Regards,
Andy
Laurent Pinchart wrote:
>
Hi,
On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley wrote:
>
> The console semaphore must be held while the OMAP UART devices are
> disabled, lest a console write cause an ARM abort (and a kernel crash)
> when the underlying console device is inaccessible. These crashes
> only occur when the con
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
> +static struct regulator_consumer_supply rx51_vdac_supply[] = {
> + {
> +#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
> + .supply = "vdda_dac",
> +
To support tvout on rx51,added the venc vdac regulator
consumer supply data and also intialised the vdac regulator
with vdac regulator consumer supply data which enables the
power supply to venc through twl4030 on rx51
Signed-off-by: Srikar
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 1
To support tvout on rx51,added Intilization data,
tvout as display device and enabled venc through gpio
on rx51
Signed-off-by: Srikar
---
arch/arm/mach-omap2/board-rx51-video.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-oma
This patch (as1431c) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers. Subsystems can call the new
pm_runtime_irq_safe() function to tell the PM core that a device's
runtime_suspend and runtime_resume callbacks should be invoked with
interrupts disabled and the spi
To support tsc2005 driver on rx51,added tsc2005
intialization data ,functions to enable/disable
tsc2005 and loading driver on rx51.
Signed-off-by: Srikar
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 46 -
1 files changed, 44 insertions(+), 2 deletions(-)
diff --
On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote:
> On Thursday 25 November 2010 14:36:50 Mark Brown wrote:
> > On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote:
> > > + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
> > > + used to transfer med
Hi Mark,
On Thursday 25 November 2010 14:53:51 Mark Brown wrote:
> On Thu, Nov 25, 2010 at 03:28:16AM +0100, Laurent Pinchart wrote:
> > Link states must not be modified while streaming is in progress on a
> > graph they belong or connect to. The entity locking API helps drivers
> > enforcing that
Hi Mark,
On Thursday 25 November 2010 14:49:08 Mark Brown wrote:
> On Thu, Nov 25, 2010 at 03:28:12AM +0100, Laurent Pinchart wrote:
> > If the entity is of node type, the power change is distributed to
> > all connected entities. For non-nodes it only affects that very
> > node. A mut
Hi Mark,
On Thursday 25 November 2010 14:36:50 Mark Brown wrote:
> On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote:
> > +Links have flags that describe the link capabilities and state.
> >
> > + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
> > + used to
On Thu, Nov 25, 2010 at 04:29:53PM +0100, Laurent Pinchart wrote:
> It depends on how you define nodes. I can certainly imagine a graph with 100
> controls, but maybe several controls can be part of the same node ? On the
> video side we've decided to split entities depending on the possible dat
On Mon, Aug 2, 2010 at 4:51 AM, Tony Lindgren wrote:
> * Cory Maccarrone [100720 06:59]:
>> This change copies from the s3c24xx the ability for a board to specify
>> if it wants 64 or 128 more GPIOs in the board space. This is needed
>> to get the HTC Herald board's extra htcpld gpios to work as
Hi Mark,
On Thursday 25 November 2010 14:41:35 Mark Brown wrote:
> On Thu, Nov 25, 2010 at 10:38:05AM +0100, Clemens Ladisch wrote:
> > In USB and HD audio devices, all links are immutable, and the routing
> > is controlled by 'selector' entities that activate exactly one of their
> > input pads.
On Thu, Nov 25, 2010 at 04:21:38PM +0100, Laurent Pinchart wrote:
> On Thursday 25 November 2010 10:38:05 Clemens Ladisch wrote:
> > ALSA has PCM and MIDI devices, and several types of mixer controls.
> > (It also has hardware dependent and timer devices, but I don't think
> > these would need top
2010/9/30 Tony Lindgren :
> * Tony Lindgren [100930 12:07]:
>> * Michał Mirosław [100930 11:57]:
>> > 2010/9/30 Tony Lindgren :
>> > > * Cory Maccarrone [100930 11:34]:
>> > >> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
>> > >> > same spotty voltage range.
>> > >> > Cory, c
Hi Clemens,
Thanks a lot for the review.
On Thursday 25 November 2010 10:38:05 Clemens Ladisch wrote:
> Laurent Pinchart wrote:
> > A link is a point-to-point oriented connection between two pads, either
> > on the same entity or on different entities. Data flows from a source
> > pad to a sink p
Hi Clemens,
Thanks for the review.
On Thursday 25 November 2010 10:33:02 Clemens Ladisch wrote:
> Laurent Pinchart wrote:
> > +struct media_device {
> > ...
> > + u8 model[32];
> > + u8 serial[40];
> > + u8 bus_info[32];
>
> All drivers and userspace applications have to treat this as char
Hi Hans,
Thanks for the review.
On Thursday 25 November 2010 12:38:15 Hans Verkuil wrote:
> On Thursday, November 25, 2010 03:28:18 Laurent Pinchart wrote:
> > V4L2 devices are media entities. As such they need to inherit from
> > (include) the media_entity structure.
> >
> > When registering/un
On Thu, Nov 25, 2010 at 8:05 AM, Kamoolkar, Mugdha wrote:
> Consider a software module on top of the hwspinlock, which provides a
> generic way for multi-core critical section, say GateMP. This module enables
> users to create critical section objects by name. Any other client can open
> the criti
On Thu, Nov 25, 2010 at 03:28:07AM +0100, Laurent Pinchart wrote:
> I want to emphasize that the media controller API does *not* replace the V4L,
> DVB or ALSA APIs. It complements them.
Overall this looks relatively good and should be mappable onto the
embedded audio stack. I'd need to sit down
On Thu, Nov 25, 2010 at 1:04 AM, Varadarajan, Charulatha wrote:
> Hari,
>
> On Wed, Nov 24, 2010 at 18:31, Kanigeri, Hari wrote:
>> On Wed, Nov 24, 2010 at 2:50 AM, Varadarajan, Charulatha
>> wrote:
>>> On Wed, Nov 24, 2010 at 13:52, Felipe Balbi wrote:
On Wed, Nov 24, 2010 at 10:46:04AM
On Thu, Nov 25, 2010 at 03:28:16AM +0100, Laurent Pinchart wrote:
> Link states must not be modified while streaming is in progress on a
> graph they belong or connect to. The entity locking API helps drivers
> enforcing that requirement.
This is not desirable for embedded audio - for example, it
On Thu, Nov 25, 2010 at 03:28:12AM +0100, Laurent Pinchart wrote:
> If the entity is of node type, the power change is distributed to
> all connected entities. For non-nodes it only affects that very
> node. A mutex is used to serialise access to the entity graph.
ASoC has its o
On Thu, Nov 25, 2010 at 10:38:05AM +0100, Clemens Ladisch wrote:
> In USB and HD audio devices, all links are immutable, and the routing
> is controlled by 'selector' entities that activate exactly one of their
> input pads. In userspace, this entity shows up as a mixer control.
> I guess it woul
Currently cpufreq transition latency value does not really reflect the actual
OMAP OPP transition delay. This patch has the actual latency value.
I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for
worstcase(MPU and Core together) and found that in none of these platforms,
transito
On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote:
> +Links have flags that describe the link capabilities and state.
> + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
> + used to transfer media data. When two or more links target a sink pad,
> + o
Add GPIO hwmod data for OMAP3
Also remove "omap34xx.h" header file as it is not required
anymore.
Signed-off-by: Charulatha V
Signed-off-by: Rajendra Nayak
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 361 +++-
1 files changed, 360 inserti
Implement GPIO as a platform device.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before board_init. Therefore
GPIO device register and driver register are implemented as
postcore_initcalls.
omap_gpio_init() does nothing now and this function would be
From: Benoit Cousson
Add GPIO hwmod data for OMAP4
Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 341
1 files changed, 341 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx
Add GPIO hwmod data for OMAP2430
Also remove "omap24xx.h" header file as it is not required
anymore.
Signed-off-by: Charulatha V
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 280 +++-
1 files changed, 279 insertions(+), 1 deletions(-)
diff
Remove the usage of omap_gpio_init() from all omap board files
since omap_gpio_init() does nothing, after gpio is implemented
as a platform device.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c|1 -
arch/arm/m
Add GPIO hwmod data for OMAP2420 and add the required
GPIO device attributes in the gpio header file
Also remove "omap24xx.h" header file as it is not required
anymore.
Signed-off-by: Charulatha V
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 230 ++
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the c
Add support for handling OMAP7xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/gpio7xx.c | 261 +
1 files changed, 261 insertions(+), 0 deletions(-)
create mode 100
Use omap_device_build() API to do platform_device_register of
GPIO devices. For OMAP2+ chips, the device specific data defined
in the centralized hwmod database will be used.
gpio_init needs to be done before machine_init functions access
gpio APIs. Hence gpio_init is made as a postcore_initcall.
Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
module uses hwmod FW.
Tested on OMAP2430, OMAP4430, OMAP3430 SDP boards, OMAP4430 Blaze board
and zoom3 board. Verified that this patch series does not break the OMAP1
build.
This patch series are created on top of origin/p
dropping e3-hacking, the problem has been solved from their POV
Thursday 25 November 2010 08:02:01 Jarkko Nikula wrote:
> On Wed, 24 Nov 2010 15:53:42 -0800
>
> Tony Lindgren wrote:
> > * Tony Lindgren [101124 15:25]:
> > > Anyways, Paul's patch should be merged during the -rc cycle
> > > becaus
Add support for handling OMAP15xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/gpio15xx.c | 98
arch/arm/plat-omap/gpio.c | 10 +---
arch/arm/plat-
Add support for handling OMAP16xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/gpio16xx.c | 199
1 files changed, 199 insertions(+), 0 deletions(-)
create mode 10
The supported set of color modes varies for different DISPC pipelines(plane)
and omap version. This makes the checks for validation of a color mode more
complicated as new omap versions are added.
A dss_feature function is created which tells if a color_mode is supported
for a plane on the current
On Wed, Nov 24, 2010 at 05:51:50PM +0100, ext Sripathy, Vishwanath wrote:
> Nishant,
>
> On Fri, Nov 19, 2010 at 7:24 AM, Nishanth Menon wrote:
> > From: Peter 'p2' De Schrijver
> >
> > Errata i581 impacts OMAP3 platforms.
> > PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing
On Thursday, November 25, 2010 03:28:18 Laurent Pinchart wrote:
> V4L2 devices are media entities. As such they need to inherit from
> (include) the media_entity structure.
>
> When registering/unregistering the device, the media entity is
> automatically registered/unregistered. The entity is acq
Hi,
On Thu, Nov 25, 2010 at 12:17:59PM +0100, Laurent Pinchart wrote:
pass platform_data as an argument to this call ? Then remove the static
inline and export this one ?
Yes indeed, why ? :-)
I guess things like that are difficult to spot when you've had your nose on
the code for too long. T
Hi Felipe,
On Thursday 25 November 2010 08:02:41 Felipe Balbi wrote:
> On Thu, Nov 25, 2010 at 03:54:37AM +0100, Laurent Pinchart wrote:
> >From: Stanimir Varbanov
> >
> >The omap3isp platform device requires platform data. As the data can be
> >provided by a kernel module, the device can't be re
Thanks Guru, and everyone for all your help!
I am afraid that I am unable to find the h264vdec_sn.tcf file, perhaps
it is not part of the publicly released files?
However, Guru has very clearly explained the size limitations so that
answers my original question, many thanks.
Our application need
Laurent Pinchart wrote:
> A link is a point-to-point oriented connection between two pads, either
> on the same entity or on different entities. Data flows from a source
> pad to a sink pad.
>
> Links are stored in the source entity.
In the descriptors of USB Audio and HDAudio devices, the links
Laurent Pinchart wrote:
> +struct media_device {
> ...
> + u8 model[32];
> + u8 serial[40];
> + u8 bus_info[32];
All drivers and userspace applications have to treat this as char[], so
why u8[]?
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
On Thu, Nov 25, 2010 at 14:01, Varadarajan, Charulatha wrote:
> On Thu, Nov 25, 2010 at 13:32, Cousson, Benoit wrote:
>> On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
>>>
>>> Benoit,
>>>
>>> On Thu, Nov 25, 2010 at 03:43, Cousson, Benoit wrote:
On 11/23/2010 3:56 PM, Varadaraja
- Original Message -
From: "Gregory CLEMENT"
To: "linux-omap" ;
Cc: "David Brownell" ; "Grant Likely"
; "Kevin Hilman"
Sent: Thursday, November 25, 2010 3:49 AM
Subject: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after
off-mode transition
As request by Grant Like
On Thu, Nov 25, 2010 at 13:32, Cousson, Benoit wrote:
> On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
>>
>> Benoit,
>>
>> On Thu, Nov 25, 2010 at 03:43, Cousson, Benoit wrote:
>>>
>>> On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP2420
>>>
On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
Benoit,
On Thu, Nov 25, 2010 at 03:43, Cousson, Benoit wrote:
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP2420
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 229
74 matches
Mail list logo
