Hi,
On Mon, Sep 5, 2011 at 11:03 PM, K, Mythri P mythr...@ti.com wrote:
Hi,
On Mon, Sep 5, 2011 at 4:31 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 16:17 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible
Hi,
diff --git a/drivers/usb/musb/musb_core.c
b/drivers/usb/musb/musb_core.c index 20a2873..07f3faf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1014,7 +1014,9 @@ static void musb_shutdown(struct
platform_device *pdev)
||
On 9/5/2011 7:46 PM, Mitch Bradley wrote:
On 9/5/2011 7:23 AM, Arnd Bergmann wrote:
On Monday 05 September 2011, Cousson, Benoit wrote:
Yeah, I saw that in the cpus node documentation. My point here is that
I do need to represent the MPU subsystem that will contain the cpus. And
thus the
Hi,
On Tue, Sep 06, 2011 at 12:30:15PM +0530, Gupta, Ajay Kumar wrote:
diff --git a/drivers/usb/musb/musb_core.c
b/drivers/usb/musb/musb_core.c index 20a2873..07f3faf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1014,7 +1014,9 @@ static void
The Devkit8000 uses a TWL4030 pin for card detection.
Thats why the error:
_omap_mux_init_gpio: Could not set gpio192
occurs.
This patch checks that the pin is on OMAP before
calling omap_mux_init_gpio.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/hsmmc.c |6
Hello Thomas,
On Tue, Sep 06, 2011 at 10:08:03AM +0200, Thomas Weber wrote:
The Devkit8000 uses a TWL4030 pin for card detection.
Thats why the error:
_omap_mux_init_gpio: Could not set gpio192
occurs.
This patch checks that the pin is on OMAP before
calling omap_mux_init_gpio.
Hi,
On Mon, Sep 5, 2011 at 6:52 PM, K, Mythri P mythr...@ti.com wrote:
Hi,
On Mon, Sep 5, 2011 at 5:45 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 16:17 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
HDMI IP block is common between TI OMAP4
On Fri, Sep 02, 2011 at 01:32:29PM -0400, Ohad Ben-Cohen wrote:
5 first patches are relatively small iommu fixes/cleanups.
2 last patches are proposals for core iommu extensions:
- Add fault report mechanism, needed for recovery of remote processors
trying to access unmapped addresses.
-
On Tue, 2011-09-06 at 11:38 +0530, K, Mythri P wrote:
Did you consider how the code would look if the function pointers
were
just included into struct hdmi_ip_data, without any ops struct at
all?
I tried without ops structure , but then using it in dss_features to
initialize would be a
Hi,
On Tue, Sep 6, 2011 at 3:47 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2011-09-06 at 11:38 +0530, K, Mythri P wrote:
Did you consider how the code would look if the function pointers
were
just included into struct hdmi_ip_data, without any ops struct at
all?
I tried
Hi,
On Tue, Sep 6, 2011 at 3:09 PM, K, Mythri P mythr...@ti.com wrote:
Hi,
On Mon, Sep 5, 2011 at 6:52 PM, K, Mythri P mythr...@ti.com wrote:
Hi,
On Mon, Sep 5, 2011 at 5:45 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 16:17 +0530, mythr...@ti.com wrote:
From:
From: Hemanth V heman...@ti.com
Date: Fri, 26 Aug 2011 10:49:29 +0530
Subject: [PATCH] Add PWM1 and PWM2 support to twl6030-pwm driver
Samuel, any comments on this patch.
Thanks
Hemanth
This patch adds support for PWM1/PWM2. TWL6030 PWM driver also
supports Indicator LED PWM. Function
On Tue, Sep 6, 2011 at 1:15 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Ok, I applied 1-5 to their respective branches. Patch 6 needs some more
discussion to make sure the interface is generally usable. Patch 7 seems
to be a starting point for now. This definitly requires conversion of
the
Arnd,
Care to pull the following fixes to the -rc series from Paul?
* Paul Walmsley p...@pwsan.com [110904 18:53]:
The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132:
Linux 3.1-rc4 (2011-08-28 21:16:01 -0700)
are available in the git repository at:
Hi all,
As kernel.org git servers still cannot be updated, I've set up
a git branch at:
http://github.com/tmlind/linux
You can pull from that to your existing tree with:
$ git pull http://github.com/tmlind/linux master
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe
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 was hosted on that machine.
--
To unsubscribe from this list: send the
On Thu, Sep 1, 2011 at 5:26 AM, Paul Walmsley p...@pwsan.com wrote:
Hi,
On Wed, 31 Aug 2011, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user
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 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 pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data structure. Also the functions are modified
accordingly to take care of this movement.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
Clean up to move the EDID definition to hdmi.c from the header file which is IP
dependent.
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
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
Define HDMI timings structure for hdmi.c to use instead of OMAP DSS timing
strucutre, As hdmi has few additional parameters such as vsync and hsync
polarity which is missing in DSS timing structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
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
Some of the header file definitions of HDMI IP are needed by audio driver thus
moving the common defintion to more generic location Include/video.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c |2 +-
From: Mythri P K mythr...@ti.com
Move HDMI IP dependent audio funtions 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 +
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
As the base_address of the HDMI might differ across SoC's, offset of the HDMI
logical blocks and base address got from the platform data are passed
dynamically to the functions that modify HDMI IP registers.
Signed-off-by: Mythri P K mythr...@ti.com
---
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future OMAP having
different IP blocks( A combination of different core, PHY, PLL blocks),
Add HDMI hdmi functions as a function pointer in dss_features to abstract
hdmi dss driver IP agnostic, hdmi dss driver
From: Mythri P K mythr...@ti.com
Splitting HDMI IP dependent IP configuring code from HDMI DSS dependent code and
moving to a new IP file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |2 +-
drivers/video/omap2/dss/hdmi.c
On Mon, 2011-09-05 at 23:03 +0530, K, Mythri P wrote:
Hi,
On Mon, Sep 5, 2011 at 4:31 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 16:17 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future OMAP having
different IP blocks( A combination of different core, PHY, PLL blocks),
Add HDMI hdmi functions as a function pointer in dss_features to abstract
hdmi dss driver IP agnostic, hdmi dss driver
Hi,
On Tue, Sep 6, 2011 at 6:15 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-09-05 at 23:03 +0530, K, Mythri P wrote:
Hi,
On Mon, Sep 5, 2011 at 4:31 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 16:17 +0530, mythr...@ti.com wrote:
From: Mythri P K
Hi,
On Mon, 5 Sep 2011, Paul Walmsley wrote:
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.
Signed-off-by: Paul Walmsley p...@pwsan.com
[...]
int __init
The following build error occurs with 3.1-rc5:
CC drivers/media/video/omap3isp/ispccdc.o
/home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c: In
function 'ccdc_lsc_config':
/home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c:427:2:
error: implicit
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Monday, September 05, 2011 6:20 PM
To: Mauro Carvalho Chehab
Cc: Hiremath, Vaibhav; Ravi, Deepthy; linux-me...@vger.kernel.org; linux-
ker...@vger.kernel.org; linux-omap@vger.kernel.org
Hi Vaibhav,
On Tuesday 06 September 2011 16:12:35 Hiremath, Vaibhav wrote:
On Monday, September 05, 2011 6:20 PM Laurent Pinchart wrote:
On Sunday 04 September 2011 15:32:28 Mauro Carvalho Chehab wrote:
snip
I don't mind splitting the config option. An alternative would be to
compile
Hi Joerg,
On Tuesday 06 September 2011 16:02:15 Joerg Roedel wrote:
The following build error occurs with 3.1-rc5:
CC drivers/media/video/omap3isp/ispccdc.o
/home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c: In
function 'ccdc_lsc_config':
Remove the init of card detect pin because
omap_mux_init_gpio() is called during hsmmc initialization
for the write protect and card detect pin.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
TWL6030 devices have an interrupt line which is connected to
application processor like OMAP. These devices support multiple features
such as MMC card detect, USB cable detect, RTC interrupt, etc. that must
wake up the application processor.
With this change, TWL6030 client drivers can make use
On Thu, Sep 1, 2011 at 6:06 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
Some comments.
On Wed, 31 Aug 2011, Keerthy wrote:
diff --git a/drivers/hwmon/omap_temp_sensor.c
b/drivers/hwmon/omap_temp_sensor.c
new file mode 100644
index 000..67fa424
--- /dev/null
+++
On Thu, Sep 1, 2011 at 9:39 AM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 31 Aug 2011, Guenter Roeck wrote:
On Wed, Aug 31, 2011 at 08:36:43PM -0400, Paul Walmsley wrote:
Hi
Some comments.
On Wed, 31 Aug 2011, Keerthy wrote:
[ ... ]
+}
+
+/* Sysfs hook functions */
On Thu, Sep 1, 2011 at 10:10 AM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Sep 01, 2011 at 12:09:14AM -0400, Paul Walmsley wrote:
On Wed, 31 Aug 2011, Guenter Roeck wrote:
On Wed, Aug 31, 2011 at 08:36:43PM -0400, Paul Walmsley wrote:
Hi
Some comments.
On Wed, 31
On Tue, 2011-09-06 at 14:02 -0400, J, KEERTHY wrote:
On Thu, Sep 1, 2011 at 10:10 AM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Sep 01, 2011 at 12:09:14AM -0400, Paul Walmsley wrote:
On Wed, 31 Aug 2011, Guenter Roeck wrote:
On Wed, Aug 31, 2011 at 08:36:43PM -0400, Paul
On Thu, Sep 1, 2011 at 4:46 AM, Paul Walmsley p...@pwsan.com wrote:
Hi Keerthy, Benoît,
On Wed, 31 Aug 2011, Keerthy wrote:
From: Benoit Cousson b-cous...@ti.com
OMAP4460 temperature sensor hwmod cannot be auto generated
since it is part of ctrl module. Hence populating the
necessary
On Tue, Sep 6, 2011 at 11:42 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Tue, 2011-09-06 at 14:02 -0400, J, KEERTHY wrote:
On Thu, Sep 1, 2011 at 10:10 AM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Sep 01, 2011 at 12:09:14AM -0400, Paul Walmsley wrote:
On Wed, 31
On Fri, Sep 2, 2011 at 12:35 AM, Venkatraman S svenk...@ti.com wrote:
Reuse omap_hsmmc_dma_cleanup even for normal dma teardown in
omap_hsmmc_dma_cb. Consolidate multiple points of dma unmap into a
single location in post_req function, to prevent double unmapping.
Signed-off-by: Venkatraman S
Russell,
On 08/01/2011 06:14 PM, Kevin Hilman wrote:
Add omap_device pointer to the ARM-specific arch data in the
platform_device. This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.
Suggested-by: Russell Kingrmk+ker...@arm.linux.org.uk
Cc: Grant
On 09/01/2011 02:57 PM, Rafael J. Wysocki wrote:
On Thursday, September 01, 2011, Arnd Bergmann wrote:
On Thursday 01 September 2011 11:12:02 Kevin Hilman wrote:
The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops
struct.
On 09/06/2011 01:13 PM, Kevin Hilman wrote:
On 09/01/2011 02:57 PM, Rafael J. Wysocki wrote:
On Thursday, September 01, 2011, Arnd Bergmann wrote:
On Thursday 01 September 2011 11:12:02 Kevin Hilman wrote:
The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but
This adds MODULE_ALIAS directives to the omap-mcbsp-dai and
omap-pcm-audio drivers so they can be auto-loaded when platform
devices are scanned.
Signed-off-by: Mans Rullgard mans.rullg...@linaro.org
---
sound/soc/omap/omap-mcbsp.c |2 ++
sound/soc/omap/omap-pcm.c |2 ++
2 files
javier Martin javier.mar...@vista-silicon.com writes:
On 2 September 2011 19:14, Kevin Hilman khil...@ti.com wrote:
javier Martin javier.mar...@vista-silicon.com writes:
On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote:
Other usual things to check that display is off
Hi Ben,
On 08/23/2011 05:10 PM, Kevin Hilman wrote:
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2/i2c-fixes branch just submitted.
Please pull into your tree for linux-next.
I see you pulled the other two, can you pull this one as well?
Since
Grant,
Please pull the following OMAP GPIO cleanups for v3.2.
Just a heads up: we're also working on another large series of cleanup
for this driver that we'll be trying to merge for v3.2.
Kevin
The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
Linux 3.1-rc3
Hi Tarun,
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value
Hi Tarun,
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove syscore_ops and
instead use dev_pm_ops now.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Cleanup omap2_gpio_prepare_for_idle() and omap2_gpio_resume_after_idle()
by moving most of the stuff to *_runtime_suspend() and *_runtime_resume().
Why?
(I know the answer, but it should be in the changelog.)
Signed-off-by: Tarun Kanti
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Most operations within runtime callbacks should be skipped when
*_runtime_get_sync() and *_runtime_put_sync() are called in probe(),
*_gpio_request() and *_gpio_free().
Why?
(again, I know the answer, but should be described in the changelog
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Context is now saved dynamically in respective functions whenever and
whichever registers are modified. This avoid overhead of saving all
registers context in the runtime callback.
Nice!
s/runtime callback/runtime suspend callback/
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishant Menon n...@ti.com
Check spelling of first name (I believe version in signed-off-by below
is the correct one.)
GPIO debounce registers need to be saved and restored for proper functioning
of driver. To save the registers, we cannot
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
Setup the dataout register before setting the GPIO to output mode
in restore path.
Please summarize why. (again, it may seem obvious now, but may not be for
those not familiar with the driver or when coming
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on what is available restore the dataout settings
to the right register.
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
Setup the interrupt enable registers only after we have configured the
required edge and required configurations, not before, to prevent
spurious events as part of restore routine.
Signed-off-by: Nishanth
From: Vikram Pandita vikram.pand...@ti.com
Recent tests with OFF mode on OMAP44xx brings out these bugs
Hema HK (1):
usb: musb: omap2+: save and restore OTG_INTERFSEL
Vikram Pandita (1):
usb: musb: omap2+: fix context api's
drivers/usb/musb/musb_core.c |4 ++--
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: I6c29c69596d5f47e00cf74ab0e32bb44ef71dda9
Reported-by: Devaraj Rangasamy d...@ti.com
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Kishon
Hi
On Sat, Sep 3, 2011 at 2:32 AM, Ohad Ben-Cohen o...@wizery.com wrote:
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
True. It is important for the peripheral devices
Em 06-09-2011 11:47, Laurent Pinchart escreveu:
Hi Vaibhav,
On Tuesday 06 September 2011 16:12:35 Hiremath, Vaibhav wrote:
On Monday, September 05, 2011 6:20 PM Laurent Pinchart wrote:
On Sunday 04 September 2011 15:32:28 Mauro Carvalho Chehab wrote:
snip
I don't mind splitting the
[...]
+ /*
+ * If this is the first gpio_request for the bank,
+ * enable the bank module.
+ */
+ if (!bank-mod_usage)
+ if (IS_ERR_VALUE(pm_runtime_get_sync(bank-dev) 0)) {
All of the IS_ERR_VALUE() usage is wrong here. You're checking if the
result
On Wed, Sep 7, 2011 at 5:23 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Cleanup omap2_gpio_prepare_for_idle() and omap2_gpio_resume_after_idle()
by moving most of the stuff to *_runtime_suspend() and *_runtime_resume().
Why?
(I know the answer,
On Wed, Sep 7, 2011 at 4:29 AM, Kevin Hilman khil...@ti.com wrote:
Hi Tarun,
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list
On Wed, Sep 7, 2011 at 4:55 AM, Kevin Hilman khil...@ti.com wrote:
Hi Tarun,
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list
On Wed, Sep 7, 2011 at 5:24 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Most operations within runtime callbacks should be skipped when
*_runtime_get_sync() and *_runtime_put_sync() are called in probe(),
*_gpio_request() and *_gpio_free().
Why?
72 matches
Mail list logo
