On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote:
Hi Archit,
On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info() when the physical address for the overlay is still not
configured. This happens in
On Thu, 2012-03-08 at 12:46 -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120308 12:11]:
Otherwise we will get:
arch/arm/plat-omap/fb.c:101: error: expected ‘)’ before ‘*’ token
Signed-off-by: Tony Lindgren t...@atomide.com
---
Tomi, you need something like
Hi Paul,
On Fri, Mar 9, 2012 at 4:51 AM, Paul Walmsley p...@pwsan.com wrote:
Dropping this patch from this series due to conflicts with the SmartReflex
branch. It will be moved to a subsequent series.
I can take this change as part of the series I am preparing for the SR
conversion to
On Wed, Mar 7, 2012 at 4:45 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote:
This local variable is just assigned zero and then OR'ed
with isr. It does not appear to serve any purpose and so
removing it.
Missed following comments from Kevin given in v2. Sorry about that.
I have updated the
Hi,
Since the McBSP driver has been moved out from arch/arm/plat-omap/ and it is
combined as a single driver with the sound/soc/omap/omap-mcbsp.c there is no
longer need to have CONFIG_OMAP_MCBSP.
This series cleans up the Kconfigs, and Makefiles.
Also it is fixes the issue that the OMAP audio
The McBSP driver stack has been moved to ASoC. The CONFIG_OMAP_MCBSP will
be removed since the CONFIG_SND_OMAP_SOC_MCBSP will trigger to build the
McBSP (audio) drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap1/Kconfig |3 ---
arch/arm/mach-omap1/Makefile
The McBSP driver stack has been moved, and rewritten resulting a single
driver - selected by CONFIG_SND_OMAP_SOC_MCBSP. There is no longer need to
have CONFIG_OMAP_MCBSP anymore.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig |6 --
This series mainly splits the platform callbacks implemented in
hsmmc.c (for clk source selection and pbiascell programming)
rather than doing everything in a single callback which
is what is done today. This cleanup is ground work before all these
callbacks are moved into hsmmc/system-control
While the pbias programming is something needed every time a regulator
output voltage is changed, the clock source selection to select between
an internal loopback and external clock seems like a one time setting.
These are today clubbed into a single platform callback, called from
the driver for
hsmmc2_before_set_reg() seems to do a clock source selection (supported
only on some mmc IP blocks) but decides to do so based on a 'HSMMC_HAS_PBIAS'
feature flag which seems completely wrong. Fix this by adding a new controller
flag 'OMAP_HSMMC_SUPPORTS_CLKSRC_SELECT' which can be then used to
As stated in the latest 2430 TRM version Z, Table 7-135 and Table 7-154,
omap2430 does not support switching between internal loopback and external
clock for MMC modules. This is supported only on some instances of MMC
modules on omap3430 only.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc:
The omap2_hsmmc_info structure provides a way for board files to specify
if an external transciever exists for the mmc module. So get rid of the
assumption based on external clock.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Venkatraman S svenk...@ti.com
---
Hi Grant,
On Friday 09 March 2012 11:12 AM, Grant Likely wrote:
On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayakrna...@ti.com wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Signed-off-by:
On Thu, Mar 8, 2012 at 12:49 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, Mar 8, 2012 at 4:58 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Wed, Mar 7, 2012 at 5:37 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Wednesday 07 March 2012 12:16 PM, Tarun
On Friday 09 March 2012 11:16 AM, Grant Likely wrote:
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgrent...@atomide.com wrote:
* Rajendra Nayakrna...@ti.com [120223 19:29]:
On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
--- a/arch/arm/boot/dts/omap3.dtsi
+++
Hi Paul,
On Friday 09 March 2012 12:21 PM, Paul Walmsley wrote:
On Thu, 8 Mar 2012, Grant Likely wrote:
Yes, absolutely use separate compatible values. It is always important
to be specific as to the silicon implementing the IP.
In that case, it is probably best to use the full chip name
Hi,
When i suspend the system, i get
0 : OFF, 1 : RETENTION, 2 : ON-INACTIVE, 3 : ON-ACTIVE
Powerdomain (core_pwrdm) entered state 1
Powerdomain (gfx_pwrdm) is in state 0
Powerdomain (abe_pwrdm) entered state 0
Powerdomain (dss_pwrdm) is in state 0
Powerdomain (tesla_pwrdm) entered state 0
Hi Tomi,
On Tue, Feb 14, 2012 at 5:52 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
The color range is something that desktops have to handle also, so
there's probably ways to handle it in DRM. DisplayPort also has the same
range setting, so it's not specific to HDMI.
So I propose
On Fri, Mar 9, 2012 at 2:42 AM, Kevin Hilman khil...@ti.com wrote:
Hi Tomi,
A while ago you were asking about why DSS pwrdm counts were so high on
OMAP3, and why DSS was transitioning even though it was completely
unused. Paul and I just spent some a little time debugging this, and
narrowed
On Thu, 2012-03-08 at 16:42 -0800, Kevin Hilman wrote:
Hi Tomi,
A while ago you were asking about why DSS pwrdm counts were so high on
OMAP3, and why DSS was transitioning even though it was completely
unused. Paul and I just spent some a little time debugging this, and
narrowed it down to
On Thu, Mar 08, 2012 at 04:32:18PM -0800, Tony Lindgren wrote:
* Kevin Hilman khil...@ti.com [120308 09:37]:
Tony Lindgren t...@atomide.com writes:
Oh, that's because it depends on the regulator core changes that are in
Mark's regulator tree. You need the for-next branch of :
When rotation is enabled and driver is configured in USERPTR
buffer exchange mechanism, in specific use-case driver reports
an error,
DMA transaction error with device 0.
In driver _buffer_prepare funtion, we were using
vout-buf_phy_addr[vb-i] for buffer physical address to
configure SDMA
Patch fixes below build warning and section miss-match warning
from omap_vout driver -
Build warnings:
=
drivers/media/video/omap/omap_vout.c: In function 'omapvid_setup_overlay':
drivers/media/video/omap/omap_vout.c:381:17: warning: 'mode' may be used
uninitialized in this function
On Fri, 2012-03-09 at 16:17 +0530, K, Mythri P wrote:
I also only now realized that we have full/limited range setting in
video overlay's ATTRIBUTEs also. And it seems that we currently set it
always to 0, i.e. limited range. I wonder if this causes color
degradation in case the HDMI/DP
On Fri, Mar 09, 2012 at 10:51:18AM +0200, Peter Ujfalusi wrote:
The McBSP driver stack has been moved, and rewritten resulting a single
driver - selected by CONFIG_SND_OMAP_SOC_MCBSP. There is no longer need to
have CONFIG_OMAP_MCBSP anymore.
Acked-by: Mark Brown
Hi Grant,
On Friday 09 March 2012 11:07 AM, Grant Likely wrote:
On Thu, 8 Mar 2012 22:03:57 +0530, Aneesh Vane...@ti.com wrote:
Cc: Rajendra Nayakrna...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Aneesh Vane...@ti.com
---
Changes since RFC v4:
- Rebased to the latest version of
From: Mythri P K mythr...@ti.com
Add basic functionality support for HDMI OMAP5 core driver.
Across OMAP4 and OMAP5 HDMI core IP block differs where as the PHY, PLL and
the wrapper blocks are reused, using the existing framework and extention to
support OMAP5 core driver is added.
Mythri P K
From: Mythri P K mythr...@ti.com
HDMI wrapper is same across OMAP4 and OMAP5, so the wrapper
functions can be re-used. Thus making wrapper functions as non-static.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 10 +-
From: Mythri P K mythr...@ti.com
Add support for configuration of the basic HDMI OMAP5 core IP
driver.HDMI shares the wrapper, PHY and PLL code with OMAP4.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |2 +
drivers/video/omap2/dss/ti_hdmi_5xxx_ip.c
-Original Message-
From: Chris Ball [mailto:c...@laptop.org]
Sent: Thursday, March 08, 2012 10:39 PM
To: Maupin, Chase
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
Hi Chase,
On Thu, Mar 01 2012,
On Wed, Mar 7, 2012 at 12:05 PM, yang gqyang hustgqy...@gmail.com wrote:
dear all:
I am working on arm cortex a8 now, trying to implement suspend to ram
based on linux 3.0.8.
Which CPU exactly are you using?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of
Luciano Coelho coe...@ti.com writes:
Hi Kevin,
On Thu, 2012-03-08 at 13:21 -0800, Kevin Hilman wrote:
Luciano Coelho coe...@ti.com writes:
[...]
Thanks, Paul! I was just chatting with Kevin about this on IRC. With
your patch and no_console_suspend, it works. :)
Just FYI... I've
Mark Brown broo...@opensource.wolfsonmicro.com writes:
On Thu, Mar 08, 2012 at 04:32:18PM -0800, Tony Lindgren wrote:
* Kevin Hilman khil...@ti.com [120308 09:37]:
Tony Lindgren t...@atomide.com writes:
Oh, that's because it depends on the regulator core changes that are in
Mark's
Hi Paul, Tony,
On 03/06/2012 10:55 AM, Peter Ujfalusi wrote:
CLKS signal for McBSP ports can be selected from internal (PRCM) or external
(ABE_CLKS pin) source.
To be able to use existing code we need to create clock aliases consistent
among OMAP2/3/4.
Would you be able to take a look at
On Fri, 24 Feb 2012 15:56:52 +0530, Rajendra Nayak rna...@ti.com wrote:
On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++
Hi Grant,
Please pull the patches for OMAP GPIO DT support.
It is based on your current gpio/next branch.
Thanks,
Benoit
The following changes since commit e4e449e82871c53ef3b22bd3a50fceabc0638926:
Mark Brown (1):
gpiolib: Add comments explaining the _cansleep() WARN_ON()s
are
On Fri, Mar 9, 2012 at 9:33 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Grant,
Please pull the patches for OMAP GPIO DT support.
It is based on your current gpio/next branch.
Thanks,
Benoit
Merged, thanks.
g.
The following changes since commit
Hi Grant,
Gentle ping for these patches.
Thanks,
Benoit
On 3/7/2012 1:57 PM, Cousson, Benoit wrote:
Hi Grant,
That fix is tightly coupled with the previous twl4030-irq change, so it
will be good to pulled it with the twl series through MFD if you are OK
with that?
Care to ack this one and
Hi
On Fri, 9 Mar 2012, Jean Pihet wrote:
On Fri, Mar 9, 2012 at 4:51 AM, Paul Walmsley p...@pwsan.com wrote:
Dropping this patch from this series due to conflicts with the SmartReflex
branch. It will be moved to a subsequent series.
I can take this change as part of the series I am
Hi Grant,
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Mar 9, 2012 at 9:33 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Grant,
Please pull the patches for OMAP GPIO DT support.
It is based on your current gpio/next branch.
Thanks,
Benoit
Merged, thanks.
Since you're
On Fri, 9 Mar 2012, Tomi Valkeinen wrote:
I didn't get very far with the patch =(. Tested on omap3 overo, with
-rc6 based dss tree.
Thanks for testing and the .config. Probably the best thing to do in the
medium term is to fix the hwmod iclk handling; I think that will also fix
the DSS
On Tue, Mar 06, 2012 at 04:25:30, Tony Lindgren wrote:
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120119 06:01]:
OMAP device has 32k-sync timer which is currently used as a
clocksource in the kernel (omap2plus_defconfig).
The current implementation uses compile time selection between
* Peter Ujfalusi peter.ujfal...@ti.com [120309 07:47]:
Hi Paul, Tony,
On 03/06/2012 10:55 AM, Peter Ujfalusi wrote:
CLKS signal for McBSP ports can be selected from internal (PRCM) or external
(ABE_CLKS pin) source.
To be able to use existing code we need to create clock aliases
On Fri, 9 Mar 2012, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [120309 07:47]:
Hi Paul, Tony,
On 03/06/2012 10:55 AM, Peter Ujfalusi wrote:
CLKS signal for McBSP ports can be selected from internal (PRCM) or
external
(ABE_CLKS pin) source.
To be able to use
On Fri, 9 Mar 2012, Paul Walmsley wrote:
Please let's not merge this one yet. It should not be necessary to change
the clkdev aliases, this change should occur in the hwmod code.
Sorry, sent this too quickly. Not the hwmod code, but the opt_clks
aliases in the hwmod data.
- Paul
--
To
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Thu, 2012-03-08 at 16:42 -0800, Kevin Hilman wrote:
Hi Tomi,
A while ago you were asking about why DSS pwrdm counts were so high on
OMAP3, and why DSS was transitioning even though it was completely
unused. Paul and I just spent some a little
* Tomi Valkeinen tomi.valkei...@ti.com [120309 00:14]:
On Thu, 2012-03-08 at 12:46 -0800, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120308 12:11]:
Otherwise we will get:
arch/arm/plat-omap/fb.c:101: error: expected ‘)’ before ‘*’ token
Signed-off-by: Tony Lindgren
Hi Luca,
* Mircea Gherzan mgher...@gmail.com [120306 14:23]:
The uim deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c | 14 --
include/linux/ti_wilink_st.h
* Peter Ujfalusi peter.ujfal...@ti.com [120309 00:54]:
The McBSP driver stack has been moved to ASoC. The CONFIG_OMAP_MCBSP will
be removed since the CONFIG_SND_OMAP_SOC_MCBSP will trigger to build the
McBSP (audio) drivers.
Great, glad to see this! Thanks for working on this:
Acked-by: Tony
On 03/08/2012 05:21 PM, Marc Butler wrote:
All,
This patch provides generic functions for encoding/decoding SLIMbus
messages (Section 8 of the specification).
Thanks for providing this patch. My understanding is that this patch
provides helper functions for h/w controllers which rely on s/w
On Fri, Mar 09, 2012 at 12:50:24PM -0700, Sagar Dharia wrote:
On 03/08/2012 05:21 PM, Marc Butler wrote:
Thanks for providing this patch. My understanding is that this patch
provides helper functions for h/w controllers which rely on s/w to
provide the exact message to be sent out on the
cc Rajendra
Hi Tero,
a few comments:
On Tue, 6 Mar 2012, Tero Kristo wrote:
...
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Mohan V moh...@ti.com
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the Sec 3.5.7.2.2
I/O Wake-Up Mechanism in OMAP3630 Public
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Rajendra Nayak rna...@ti.com
IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
On Tue, 6 Mar 2012, Tero Kristo wrote:
Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux. This
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can
On Tue, 6 Mar 2012, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Hi
On Tue, 6 Mar 2012, Tero Kristo wrote:
Changes compared to previous version:
- patch2:
* fixed the timeout for waiting for ST_IO_CHAIN == 1
* added clear for ST_IO_CHAIN bit (as per spec + implementation in patch 1)
* replaced the timeout at the end of function with a simple
On Fri, 2012-03-09 at 10:31 -0800, Tony Lindgren wrote:
Hi Luca,
Hi Tony,
* Mircea Gherzan mgher...@gmail.com [120306 14:23]:
The uim deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
Hello Péter
could you please try this patch instead of the clkdev change?
It is based on my 'hwmod_enable_remaining_hwmods_devel_3.4' branch, but
the basic idea should work on v3.3-rc6 as well.
If it works for you, please let us know and we can queue this up along
with the hwmod data
On Thu, 2012-03-08 at 07:29 -0800, Greg KH wrote:
On Thu, Mar 08, 2012 at 09:35:13AM +0200, Tomi Valkeinen wrote:
On Wed, 2012-03-07 at 12:01 -0800, Greg KH wrote:
On Thu, Mar 01, 2012 at 02:26:35PM +0200, Tomi Valkeinen wrote:
From: Rob Clark r...@ti.com
The OMAPDSS: HDMI: PHY
62 matches
Mail list logo
