On Wed, Sep 7, 2011 at 10:32 PM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
From: Ravi Babu ravib...@ti.com
The usb subsystem (usbss) in ti81xx has two musb interfaces. There are three
irqs and three address spaces for usbss, musb0 and musb1 respectively. Created
one hwmod with three irq and
Resend with linux-kernel mail list included.
On Wed, Sep 7, 2011 at 10:22 PM, TAO HU tgh...@motorola.com wrote:
Hi, All
We seems got a schedule/migration issue in a OMAP4430 dual-core system.
The kernel base is 2.6.35.7 and we're using CFS.
In a stress testing, we created a huge amount of
Hi Ohad,
On 9/7/2011 9:58 PM, Ohad Ben-Cohen wrote:
On Wed, Aug 24, 2011 at 4:09 PM, Benoit Coussonb-cous...@ti.com wrote:
Add a device-tree node for the spinlock.
Remove the static device build code if CONFIG_OF
is set.
Update the hwspinlock driver to use the of_match method.
Add the
On Thu, Sep 08, 2011 at 02:47:08PM +0800, TAO HU wrote:
Resend with linux-kernel mail list included.
Hmm, could you give a try with commit da7a735e?
Thanks,
Yong
---
commit da7a735e51f9622eb3e1672594d4a41da01d7e4f
Author: Peter Zijlstra a.p.zijls...@chello.nl
Date: Mon Jan 17 17:03:27 2011
On Thu, Sep 08, 2011 at 03:28:01PM +0800, Yong Zhang wrote:
On Thu, Sep 08, 2011 at 02:47:08PM +0800, TAO HU wrote:
Resend with linux-kernel mail list included.
Hmm, could you give a try with commit da7a735e?
Thanks,
Yong
---
commit da7a735e51f9622eb3e1672594d4a41da01d7e4f
Author:
Hi Sricharan,
On 9/8/2011 7:22 AM, Shilimkar, Santosh wrote:
From: sricharanr.sricha...@ti.com
The address space count API returns the number of address space
entries for a hwmod including a additional null value present in the
address space structure introduced recently.
That's a minor nit,
Hi Benoit,
On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hehe, I'm not the one who wrote that driver :-)
This is not wrong for the current HW. The point is do we want to anticipate
potential HW evolution that might never happen on that IP?
I originally really
Hi,
On Thu, Sep 08, 2011 at 11:56:25AM +0530, Munegowda, Keshava wrote:
On Wed, Sep 7, 2011 at 10:32 PM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
From: Ravi Babu ravib...@ti.com
The usb subsystem (usbss) in ti81xx has two musb interfaces. There are three
irqs and three address spaces
Hi,
On Wed, Sep 07, 2011 at 02:52:02PM +0400, Sergei Shtylyov wrote:
Hello.
On 07-09-2011 4:49, Vikram Pandita wrote:
From: Hema HK hem...@ti.com
we need to save and restore OTG_INTERFSEL register
else we will be unable to function on resume after
OFF mode.
Change-Id:
On 9/8/2011 9:56 AM, Ohad Ben-Cohen wrote:
Hi Benoit,
On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hehe, I'm not the one who wrote that driver :-)
This is not wrong for the current HW. The point is do we want to anticipate
potential HW evolution that might never
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoit b-cous...@ti.com wrote:
The (small) issue for my point of view is that the #hwspinlock is already
encoded in the IP itself. So adding a baseid directly in DT will look like
duplicating indirectly something that is already there in the HW.
That
On Thu, Sep 8, 2011 at 1:30 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Sep 08, 2011 at 11:56:25AM +0530, Munegowda, Keshava wrote:
On Wed, Sep 7, 2011 at 10:32 PM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
From: Ravi Babu ravib...@ti.com
The usb subsystem (usbss) in ti81xx has two
Hi Benoit,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Thursday, September 08, 2011 2:35 PM
To: Sricharan R
Subject: Re: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
Hi Sricharan,
On 9/8/2011 7:22 AM, Shilimkar, Santosh wrote:
From:
On Thursday 08 September 2011 02:45 PM, Sricharan R wrote:
Hi Benoit,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Thursday, September 08, 2011 2:35 PM
To: Sricharan R
Subject: Re: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
[...]
diff --git
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.
Add function dispc_disable_outputs() which disables
Hello.
On 07-09-2011 21:02, Ajay Kumar Gupta wrote:
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com
Signed-off-by: Ravi Baburavib...@ti.com
---
Hi,
On 07-09-2011 21:02, Ajay Kumar Gupta wrote:
Adding ti81xx_musb_phy_power() which will be used by musb driver
through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com
Signed-off-by: Ravi Baburavib...@ti.com
---
Hi,
ajay.gu...@ti.com wrote:
[...]
--
1.6.2.4
looks good to me.
how about you reply with your Acked-by then ?
--
balbi
yes balbi,
here it is
Acked-By: Keshava Munegowda keshava_mgo...@ti.com
Tony and Benoit,
Please review this patch and provide your input on
Hi,
I guess this should go through Paul. Paul, this is based on the DSS
HWMOD patches from me, and needed for cases where the bootloader has
enabled the DSS.
On Thu, 2011-09-08 at 15:26 +0530, Archit Taneja wrote:
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
Hi,
+static int __devinit dsps_probe(struct platform_device *pdev) {
+ const struct platform_device_id *id =
platform_get_device_id(pdev);
+ const struct dsps_musb_wrapper *wrp =
+ (struct dsps_musb_wrapper *)id-driver_data;
+ struct dsps_glue *glue;
+
This patch-set gets the kernel booting up on a AM3517 EVM.
The board is able to boot with ramdisk after this,but the MMC and Ethernet
drivers are not up yet. Lots of warnings remain which will be addressed in
subsequent patches.
The patches are tested on master of tmlind/linux-omap-2.6.git.
This patch enables AM35x SoCs to use generic OMAP3 hwmods
(i,e. omap3xxx_hwmods) by allowing am35xx_init_early() to
disable the modules which are not present in AM3517.
Reviewed-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/io.c
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
This is as per discussion at
http://marc.info/?l=linux-omapm=131417482924928w=2
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
This patch-set fixes the power and voltage management initialization sequence
for AM35x.
These patches are dependent on the following patch-set
[PATCH v3 0/2] AM3517: Booting up
at http://marc.info/?l=linux-kernelm=131548351225196w=2
which gets the AM3517 EVM booting.
The patches are
From: Sanjeev Premi pr...@ti.com
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
Many functions have been defined to plug into existing
voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V
From: Sanjeev Premi pr...@ti.com
This patch adds support for TPS65023 used with
OMAP3 devices. The PMIC is currently hooked to
AM35x devices, but can easily be extended for
other OMAP3 devices.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
The current implementation almost assumes that only
TWL4030/TWL5030/TWl6030 are (or can be) used with the
OMAP processors. This is, however, not true.
This patch removes the automatic selection of the PMIC
from Kconfig.
All currently used PMICs are now added to omap2plus_defconfig;
any new PMIC
Hi Ohad,
On Wed, Sep 7, 2011 at 6:16 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Hmm this sounds a bit like a red herring to me; optimization of the
:) I agree. sorry.
map function is not the main subject here. Especially not when we're
discussing mapping of large physically contiguous memory
On Thu, 2011-09-08 at 14:47 +0800, TAO HU wrote:
We seems got a schedule/migration issue in a OMAP4430 dual-core system.
The kernel base is 2.6.35.7 and we're using CFS.
step 1, try with a kernel that isn't quite as fossilized
(3.0 or even better 3.1-rc)
step 2, if no luck, report
Add partition table for NAND device on TI8168 EVM
and initialise the NAND module.
Signed-off-by: Saxena, Parth parth.sax...@ti.com
Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com
---
This patch is tested on top of linux-omap/master and
Hemant's patches submitted recently.
[...]
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Thursday, September 08, 2011 2:35 PM
To: Sricharan R
Subject: Re: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
This patchset
-add support for tvp514x video decoder on omap3evm and also migrate the
decoder driver to media controller framework.
-add support for BT656 interface.
-enable multimedia driver and tvp514x decoder support in
omap2plus_defconfig.
It is dependent on
From: Vaibhav Hiremath hvaib...@ti.com
Enabled 1v8 and 2v8 regulator output, which is being used by
camera module.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 40 ++
From: Vaibhav Hiremath hvaib...@ti.com
In OMAP3EVM Rev G, TVP5146 video decoder is populated on the
main board. This decoder is registered as a subdevice to the
media-controller/omap3isp.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
From: Vaibhav Hiremath hvaib...@ti.com
Migrate tvp5146 driver to media controller framework. The
driver registers as a sub-device entity to MC framwork
and sub-device to V4L2 layer. The default format code was
V4L2_MBUS_FMT_YUYV10_2X10. Changed it to V4L2_MBUS_FMT_UYVY8_2X8
and hence added the
From: Vaibhav Hiremath hvaib...@ti.com
In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
From: Vaibhav Hiremath hvaib...@ti.com
Configure the CCDC registers for YUV and non YUV
data. Also some code clean-up for making it compact.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
drivers/media/video/omap3isp/ispccdc.c | 65
Enables multimedia driver, media controller api,
v4l2-subdev-api, and tvp514x video decoder support
in omap2plus_defconfig.
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
arch/arm/configs/omap2plus_defconfig | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git
From: Vaibhav Hiremath hvaib...@ti.com
Add support for BT656 interface in omap3isp ccdc driver.
In addition, this corrects some build errors associated
with isp_video_mbus_to_pix(). The function was declared
as static. Made it extern.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
arch/arm/mach-omap2/board-omap3evm-camera.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git
Hi,
On Wed, Sep 7, 2011 at 5:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Tue, 2011-09-06 at 17:28 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor
although
the Display subsytem is
From: Mythri P K mythr...@ti.com
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
the Display subsytem is different. Also the IP block in future OMAP's may differ
from the one existing in OMAP4. Thus to reuse the code between these two
processors , and maintain the
From: Mythri P K mythr...@ti.com
As the base_address of the HDMI might differ across SoC's, offset of the HDMI
logical blocks(PHY, PLL and Core) and base address procured from the platform
data are passed dynamically to the functions that modify HDMI IP registers.
Signed-off-by: Mythri P K
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data, pll
and video structures are moved to the ip_data structure. Also the pll and
video configuration functions are modified accordingly to take care of the
structure movement.
Signed-off-by: Mythri
From: Mythri P K mythr...@ti.com
As hdmi has few additional parameters such as vsync and hsync
polarity which is missing in DSS timing structure, define HDMI timings
structure for hdmi to use instead of OMAP DSS timing structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
As the panel driver will remain generic across OMAP's renaming it to
hdmi_panel.c
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |2 +-
.../omap2/dss/{hdmi_omap4_panel.c = hdmi_panel.c} |2 +-
2 files
From: Mythri P K mythr...@ti.com
HDMI IP fundamentally has replaceable core PHY and PLL blocks.
These blocks might vary across OMAP's but the end functionality such as to
enable or disable PLL, PHY, function to read EDID would remain the same.
Thus to make the current hdmi DSS driver compatible
From: Mythri P K mythr...@ti.com
Split the current HDMI driver to move the HDMI IP dependent ( PLL/PHY/Core
configuration code) to a new IP file (ti_hdmi_4xxx_ip.c.
This is to separate IP dependent OMAP agnostic code from OMAP specific DSS
dependent code.
Signed-off-by: Mythri P K
From: Mythri P K mythr...@ti.com
Functions that are included in HDMI IP driver is renamed to have
IP specific names so that it will not conflict with similar functions
from other IP.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 18
From: Mythri P K mythr...@ti.com
Clean up to move the EDID definition from the IP dependent header file to
hdmi.c
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 10 ++
drivers/video/omap2/dss/hdmi.h | 10 --
2 files changed, 10
From: Mythri P K mythr...@ti.com
Some of the header file definitions that are there in the hdmi.h are generic
and can be used across OMAP's, Thus moving generic definition to new file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h | 18 ---
From: Mythri P K mythr...@ti.com
Move HDMI IP dependent audio functions from HDMI DSS file to IP library.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 257 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 260
Hi Tero,
Tero Kristo t-kri...@ti.com writes:
On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote:
Tero Kristo t-kri...@ti.com writes:
[...]
After thinking about this problem and looking at possible ways to fix
it, I am planning to change the PRCM chain handler to be a driver, which
Hi KyongHo,
On Thu, Sep 8, 2011 at 3:51 PM, KyongHo Cho pullip@samsung.com wrote:
16MB page is less practical in Linux because Linux kernel is unable
to allocated larger physically contiguous memory than 4MB by default.
But I also think that it is needed to support 16MB mapping for IO
On Thursday 08 September 2011, Ohad Ben-Cohen wrote:
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoit b-cous...@ti.com wrote:
The (small) issue for my point of view is that the #hwspinlock is already
encoded in the IP itself. So adding a baseid directly in DT will look like
duplicating
On 9/8/2011 11:32 AM, Shilimkar, Santosh wrote:
On Thursday 08 September 2011 02:45 PM, Sricharan R wrote:
Hi Benoit,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Thursday, September 08, 2011 2:35 PM
To: Sricharan R
Subject: Re: [PATCH 1/8] OMAP: hwmod: Fix
This converts the per-board modules to platform drivers for a
device created by in main platform setup. These drivers call
snd_soc_register_card() directly instead of going via a soc-audio
device and the corresponding driver in soc-core.
Signed-off-by: Mans Rullgard mans.rullg...@linaro.org
---
On 09/08/2011 05:05 PM, Mans Rullgard wrote:
This converts the per-board modules to platform drivers for a
device created by in main platform setup. These drivers call
snd_soc_register_card() directly instead of going via a soc-audio
device and the corresponding driver in soc-core.
diff
On Tuesday 06 September 2011, Russell King - ARM Linux wrote:
On Tue, Sep 06, 2011 at 04:29:14AM -0700, Tony Lindgren wrote:
Arnd,
Care to pull the following fixes to the -rc series from Paul?
Tony,
I don't think that will happen until master.kernel.org is back online
as the tree
Hello,
This is a preliminary review set for the PRCM chain handler driver work.
This set is still missing the PRM hwmod interaction, which should replace
patches 5 and 6. I am planning to post a new series as soon as this part
is done (waiting for a little bit of help from Paul here.) Anyway,
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
Added wakeup and io event definitions for the PRCM interrupt handler.
This should eventually be generated from PRM hwmod data.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/power/omap_prm.c | 34 +++---
1 files changed, 31 insertions(+), 3 deletions(-)
This driver will eventually support OMAP soc PRM module features, e.g. PRCM
chain interrupts.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/power/Kconfig|7
drivers/power/Makefile |1 +
drivers/power/omap_prm.c | 83 ++
3
The implementation in this patch still requires the irq_setup to be done
properly, and also lacks the supported interrupts. These will be added
in separate patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/power/omap_prm.c | 214 +++-
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c | 37
This is a temporary hack until PRM hwmod data is available.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/power/omap_prm.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c
index ce0a872..7d59d92 100644
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c|3 +-
arch/arm/mach-omap2/pm34xx.c | 104 +++---
2 files changed, 39 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git
On Thu, Sep 08, 2011 at 03:29:11PM -0700, Mark Brown wrote:
On Thu, 2011-09-08 at 22:28 +0200, Arnd Bergmann wrote:
On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
I had the same thought, but I couldn't find a suitable string anywhere.
Are you suggesting an
In driver probe use sys_timer_reserved to identify which all timers
have already been used for clocksource and clockevent. Mark all those
timers as reserved so that no one else can use them.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
Add dmtimer platform driver functions which include:
(1) platform driver initialization
(2) driver probe function
(3) driver remove function
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Add pm_runtime feature to dmtimer whereby *_runtime_get_sync()
is called within omap_dm_timer_enable(), pm_runtime_put()
is called in omap_dm_timer_disable(). In addition to calling
pm_runtime_enable, we are calling pm_runtime_irq_safe so that
they can be called from interrupt context.
The low-level read and write access routines wait on write-pending register
in posted mode to make sure that previous write is complete on respective
registers. This waiting is done in an infinite while loop. Now it is being
modified to use timeout instead.
Signed-off-by: Tarun Kanti DebBarma
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara
Convert OMAP1 dmtimers into a platform devices and then registers with
device model framework so that it can be bound to corresponding driver.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is enabled
and then disabled back at the end of access. Context save is done dynamically
whenever the registers are modified. Context restore is called
Register timer devices by going through hwmod database using
hwmod API. The driver probes each of the registered devices.
Functionality which are already performed by hwmod framework
are removed from timer code. New set of timers present on
OMAP4 are now supported.
Signed-off-by: Tarun Kanti
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver.
In addition, capability attribute of each of the timers is added in
hwmod database.
Signed-off-by:
On 9/8/2011 8:01 PM, Grant Likely wrote:
On Wed, Aug 24, 2011 at 03:09:07PM +0200, Benoit Cousson wrote:
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Tony
Adaptation of dmtimer code to platform driver using omap_device and
omap_hwmod abstraction. It also include pm-runtime and off-mode support.
Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Branch: Master
Commit: c6a389f Linux 3.1-rc4
Test Info:
- OMAP4430SDP:
Since the exported APIs can be called from interrupt context
extend spinlock protection to some more relevant APIs to avoid
race condition.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 34
OMAP4 has two groups of timers: version 1 timers are 1, 2, 10,
while the rest of the timers, 3-9, 11 are version 2 timers.
The version information is required by the driver so that they
could be handled correctly by it.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh
On 9/8/2011 4:47 PM, Arnd Bergmann wrote:
On Thursday 08 September 2011, Ohad Ben-Cohen wrote:
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoitb-cous...@ti.com wrote:
The (small) issue for my point of view is that the #hwspinlock is already
encoded in the IP itself. So adding a baseid
Add error handling code to exported APIs. Currently, the APIs assume they
are operating on valid parameters passed to it.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 101
On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
On Thu, Sep 08, 2011 at 11:37:20PM +0100, Russell King - ARM Linux wrote:
With DT of course, all devices get instantiated from the device tree,
so there should not be any more platform specific chunks of code in
these locations
On Thu, Sep 08, 2011 at 11:37:20PM +0100, Russell King - ARM Linux wrote:
With DT of course, all devices get instantiated from the device tree,
so there should not be any more platform specific chunks of code in
these locations (ha, it couldn't be solved with platform data so I
suspect it
On Thu, 2011-09-08 at 22:28 +0200, Arnd Bergmann wrote:
On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
I had the same thought, but I couldn't find a suitable string anywhere.
Are you suggesting an if(machine_is_foo()) cascade in omap_init_audio()?
I'll be the first to agree
On Thu, Sep 08, 2011 at 11:47:16PM +0530, Jassi Brar wrote:
Can't we do by having omap_init_audio() in arch/arm/mach-omap2/devices.c
generate a platform device of name depending upon machine_is_* ?
That's not a bad idea. If we were going to do that it shouldn't be OMAP
specific, any platform
Hi,
On Thursday 08 September 2011 15:34:44 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
In OMAP3EVM Rev G, TVP5146 video decoder is populated on the
main board. This decoder is registered as a subdevice to the
media-controller/omap3isp.
Thanks for the patch.
We're getting
On Thu, Sep 08, 2011 at 04:41:30PM +0100, Mans Rullgard wrote:
On 8 September 2011 16:15, Lars-Peter Clausen l...@metafoo.de wrote:
Use different device driver names for different drivers.
I guess this worked by accident on my system.
Are there any other changes needed?
Check the N810
Hi Deepathy,
Thanks for the patches.
On Thu, Sep 08, 2011 at 07:05:22PM +0530, Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.
Why on video
On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
Can't we do by having omap_init_audio() in arch/arm/mach-omap2/devices.c
generate a platform device of name depending upon machine_is_* ?
I had the same thought, but I couldn't find a suitable string anywhere.
Are you suggesting
Hi,
Thanks for the patch.
On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.
Why so ? Shouldn't it be
Hi,
On Thursday 08 September 2011 15:35:00 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Migrate tvp5146 driver to media controller framework. The
driver registers as a sub-device entity to MC framwork
and sub-device to V4L2 layer. The default format code was
On Wed, Aug 24, 2011 at 03:09:11PM +0200, Benoit Cousson wrote:
Add documentation for the OMAP4 processors bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14
On Thu, Sep 08, 2011 at 04:05:53PM +0100, Mans Rullgard wrote:
+static struct platform_device omap_soc_audio = {
+ .name = omap-soc-audio,
+ .id = -1,
+};
+
This isn't really accomplishing anything as you're using the same device
name for all boards, it's essentially the same
Hi,
Thanks for the patch.
On Thursday 08 September 2011 15:35:44 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Configure the CCDC registers for YUV and non YUV
data. Also some code clean-up for making it compact.
I've already posted patches to the linux-media mailing list for
On Wed, Aug 24, 2011 at 03:09:13PM +0200, Benoit Cousson wrote:
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
.../bindings/hwspinlock/omap-spinlock.txt |5 +
1 files changed, 5
This converts the per-board modules to platform drivers for a
device created by in main platform setup. These drivers call
snd_soc_register_card() directly instead of going via a soc-audio
device and the corresponding driver in soc-core.
Signed-off-by: Mans Rullgard mans.rullg...@linaro.org
---
1 - 100 of 129 matches
Mail list logo
