On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
Benoit,
On Thu, Nov 25, 2010 at 03:43, Cousson, Benoitb-cous...@ti.com wrote:
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP2420
Signed-off-by: Charulatha Vch...@ti.com
---
On Thu, Nov 25, 2010 at 13:32, Cousson, Benoit b-cous...@ti.com wrote:
On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
Benoit,
On Thu, Nov 25, 2010 at 03:43, Cousson, Benoitb-cous...@ti.com wrote:
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for
- Original Message -
From: Gregory CLEMENT gregory.clem...@free-electrons.com
To: linux-omap linux-omap@vger.kernel.org;
spi-devel-gene...@lists.sourceforge.net
Cc: David Brownell dbrown...@users.sourceforge.net; Grant Likely
grant.lik...@secretlab.ca; Kevin Hilman
On Thu, Nov 25, 2010 at 14:01, Varadarajan, Charulatha ch...@ti.com wrote:
On Thu, Nov 25, 2010 at 13:32, Cousson, Benoit b-cous...@ti.com wrote:
On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
Benoit,
On Thu, Nov 25, 2010 at 03:43, Cousson, Benoitb-cous...@ti.com wrote:
On
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 in
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 are
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
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 svarba...@mm-sol.com
The omap3isp platform device requires platform data. As the data can be
provided by a kernel module, the device
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.
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
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 n...@ti.com wrote:
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Errata i581 impacts OMAP3 platforms.
PRCM DPLL control FSM removes
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
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 t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [101124 15:25]:
Anyways, Paul's patch should be merged during
Add support for handling OMAP15xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c | 98
arch/arm/plat-omap/gpio.c | 10 +---
Add support for handling OMAP16xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/gpio16xx.c | 199
1 files changed, 199 insertions(+), 0 deletions(-)
Add support for handling OMAP7xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/gpio7xx.c | 261 +
1 files changed, 261 insertions(+), 0 deletions(-)
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
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 ch...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
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
From: Benoit Cousson b-cous...@ti.com
Add GPIO hwmod data for OMAP4
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 341
1 files changed, 341 insertions(+), 0 deletions(-)
Add GPIO hwmod data for OMAP2430
Also remove omap24xx.h header file as it is not required
anymore.
Signed-off-by: Charulatha V ch...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 280 +++-
1 files changed, 279
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 ch...@ti.com
---
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c|1
Add GPIO hwmod data for OMAP3
Also remove omap34xx.h header file as it is not required
anymore.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 361
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
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,
+ only
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,
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 would
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 own
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 is
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 8:05 AM, Kamoolkar, Mugdha mug...@ti.com 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
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
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[], so
why
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 pad.
2010/9/30 Tony Lindgren t...@atomide.com:
* Tony Lindgren t...@atomide.com [100930 12:07]:
* Michał Mirosław mir...@gmail.com [100930 11:57]:
2010/9/30 Tony Lindgren t...@atomide.com:
* Cory Maccarrone darkstar6...@gmail.com [100930 11:34]:
Looks like also board-sx1-mmc.c and
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 topology
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. In
On Mon, Aug 2, 2010 at 4:51 AM, Tony Lindgren t...@atomide.com wrote:
* Cory Maccarrone darkstar6...@gmail.com [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
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 data
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
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 mutex is
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
To support tsc2005 driver on rx51,added tsc2005
intialization data ,functions to enable/disable
tsc2005 and loading driver on rx51.
Signed-off-by: Srikar ext-srikar.1.bhavanaray...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 46 -
1 files changed, 44
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
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 ext-srikar.1.bhavanaray...@nokia.com
---
To support tvout on rx51,added Intilization data,
tvout as display device and enabled venc through gpio
on rx51
Signed-off-by: Srikar ext-srikar.1.bhavanaray...@nokia.com
---
arch/arm/mach-omap2/board-rx51-video.c | 29 -
1 files changed, 28 insertions(+), 1
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,
+ .dev
Hi,
On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com 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
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 chars.
Regards,
Andy
Laurent Pinchart
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
Hello Jean
On Thu, 25 Nov 2010, Jean Pihet wrote:
On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com 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
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 t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [101124 15:25]:
Anyways, Paul's patch should be merged during the -rc
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-nodes it
On Thu, 25 Nov 2010 12:20:31 -0500
Andy Walls awa...@md.metrocast.net 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
Hi
On Thu, 25 Nov 2010, Jean Pihet wrote:
On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com 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
On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley p...@pwsan.com wrote:
Hello Jean
On Thu, 25 Nov 2010, Jean Pihet wrote:
On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com wrote:
The console semaphore must be held while the OMAP UART devices are
disabled, lest a console write
Paul,
On Thu, Nov 25, 2010 at 7:15 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Thu, 25 Nov 2010, Jean Pihet wrote:
On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com wrote:
The console semaphore must be held while the OMAP UART devices are
disabled, lest a console write
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 it
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
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
On Thu, 2010-11-25 at 08:40 +0200, Ohad Ben-Cohen wrote:
On Thu, Nov 25, 2010 at 5:59 AM, David Brownell davi...@pacbell.net 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.
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
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 axel@gmail.com
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()) {
+
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
Olof Johansson,
On Fri, Nov 26, 2010 at 10:08, Olof Johansson o...@lixom.net 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
On Thu, Nov 11, 2010 at 5:31 AM, Guenter Roeck
guenter.ro...@ericsson.com 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
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 majordomo
On Thu, Nov 25, 2010 at 9:59 PM, Olof Johansson o...@lixom.net 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
On Thu, Nov 25, 2010 at 10:22 PM, David Brownell davi...@pacbell.net 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
On Wed, Jun 30, 2010 at 11:28 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: Hiroshi DOYU hiroshi.d...@nokia.com
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
72 matches
Mail list logo
