On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote:
Hello Vaibhav,
I've reworked these patches somewhat to separate the PRM and CM changes
into their own patches. Also, the omap_hwmod changes have been separated
and moved into a different series, as have the clock tree changes.
So
Hi,
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 00:16]:
I really like it
I was working on something simillar
but can we split the group management so we can use it on other
bindings
Hmm I'm not sure I follow on the group management
Hi,
* Hiremath, Vaibhav hvaib...@ti.com [120502 02:37]:
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X EVM.
The approach taken here is to add
On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
family of SoC's which is OMAP-based. The incorporation is
clip
@@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
pwrdm_for_each(pwrdms_setup, (void *)d);
- (void) debugfs_create_file(enable_off_mode, S_IRUGO | S_IWUSR, d,
- enable_off_mode, pm_dbg_option_fops);
+ if
On Thu, May 3, 2012 at 8:08 PM, Jeff Moyer jmo...@redhat.com wrote:
Venkatraman S svenk...@ti.com writes:
From: Ilan Smith ilan.sm...@sandisk.com
When exp_swapin and exp_dmpg are set, treat read requests
marked with DMPG and SWAPIN as high priority and move to
the front of the queue.
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
Hi,
* Hiremath, Vaibhav hvaib...@ti.com [120502 02:37]:
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds
Hi Paul,
On 04/20/2012 01:59 PM, Paul Walmsley wrote:
[...]
This looks great, looks like it will finally fix this longstanding bug. I
think Santosh hit it too a long time ago, so I suspect he will be happy
too.
One comment: I think that omap2_wd_timer_reset() needs to be updated in
light of
Hi Vaibhav,
On 05/03/2012 12:07 AM, Hiremath, Vaibhav wrote:
On Thu, May 03, 2012 at 01:26:18, Hunter, Jon wrote:
Hi Vaibhav,
On 05/02/2012 08:56 AM, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz
On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
On Thu, May 03, 2012 at 06:21:27PM +, Bedia, Vaibhav wrote:
On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com
wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
[...]
So, if I understood this correctly, it's effectively like blocking a low
power
state transition (here wfi execution) when EMAC is active?
Assuming it is my patch, correct.
Recently I was thinking about how to get certain
* Hiremath, Vaibhav hvaib...@ti.com [120503 09:45]:
What about cpu_is_omap34xx() true for am33xx? Should we follow it?
Well are there components that could be used as is with that?
If not, then it probably does not make sense.
BTW, you should post your patches on top of the clean-up patches
Daniel Lezcano daniel.lezc...@linaro.org writes:
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
I don't think this changelog is valid anymore as you're not doing
anything to decrease the number of states.
I
Daniel Lezcano daniel.lezc...@linaro.org writes:
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1 files changed, 4 insertions(+), 1
On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote:
On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
[...]
So, if I understood this correctly, it's effectively like blocking a low
power
state transition (here wfi execution) when EMAC is active?
Assuming it is my
On 05/03/2012 10:19 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
I don't think this changelog is valid anymore as you're not doing
Daniel Lezcano daniel.lezc...@linaro.org writes:
Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean
Hi Daniel,
Daniel Lezcano daniel.lezc...@linaro.org writes:
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
I think I said it before, but it's worth repeating: Very nice cleanup!
Thanks for your persistence.
I've now been through
Hiremath, Vaibhav hvaib...@ti.com writes:
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
Hi,
* Hiremath, Vaibhav hvaib...@ti.com [120502 02:37]:
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal
Santosh Shilimkar santosh.shilim...@ti.com writes:
cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code
cpu checks accordingly so that there is no need to patch
the file for any future OMAP2+ devices.
In long run, all these attributes should come from hwmod dev_attr based
On 04/30/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I'll reply to the binding
On 05/03/2012 09:27 AM, Tony Lindgren wrote:
Hi,
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 00:16]:
I really like it
I was working on something simillar
but can we split the group management so we can use it on other
bindings
Hmm I'm not sure
On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
Hi Santosh,
Can you send Greg a patch that adds proper dependencies to the Kconfig?
I was going to simply add an ARM dependency, but
Hi Kevin,
On Thu, 3 May 2012, Kevin Hilman wrote:
On 04/20/2012 01:59 PM, Paul Walmsley wrote:
[...]
This looks great, looks like it will finally fix this longstanding bug. I
think Santosh hit it too a long time ago, so I suspect he will be happy
too.
One comment: I think that
On 05/03/2012 10:26 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org
Reviewed-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1
On 05/03/2012 10:34 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.
Signed-off-by: Daniel
On Thu, May 03, 2012 at 04:26:12PM -0600, Stephen Warren wrote:
On 04/30/2012 03:17 PM, Jon Hunter wrote:
+Example:
+
+ sdma: dmaengine@4800 {
+ compatible = ti,omap4-sdma
+ reg = 0x4800 0x1000;
+ interrupts = 4;
+ #dma-cells = 2;
On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote:
On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
Hi Santosh,
Can you send Greg a patch that adds proper dependencies
There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio driver or any other driver interested in
the functionality.
The audio_enable function is intended to
Hi,
This patch is proposed as a result of a previous discussion related to
include audio support in the DSS device driver
(http://www.spinics.net/lists/linux-omap/msg64748.html)
At the moment, this is intended to cover display technologies with audio based
on CEA-861 and IEC-60958, such as HDMI
To improve readability, split the video_enable HDMI IP operation
into two separate functions for enabling and disabling video.
The video_enable function is also modified to return an error value.
While there, update these operations for the OMAP4 IP accordingly.
Signed-off-by: Ricardo Neri
To improve readability, split the audio_enable HDMI IP operation
into two separate functions for enabling and disabling audio.
The audio_enable function is also modified to return an error value.
While there, update these operations for the OMAP4 IP accordingly.
Signed-off-by: Ricardo Neri
Utilize a snd_aes_iec958 struct to write the parameters of the IEC-60958
channel status word into the HDMI IP registers. Hence, the user of the
driver has full control of what parameters are written in the word.
Also, some of the parameters of the I2S structure have been removed
as they are
The N and CTS parameters are relevant to all HDMI implementations and
not specific to a given IP. Hence, the calculation is relocated
into the generic HDMI driver.
Also, deep color is not queried but it is still considered in the
calculation of N. This is to be changed when deep color
Remove the ASoC OMAP HDMI audio codec. The goal of removing the codec
is to, in subsequent patches, give way to the implementation of the HDMI
audio support using the DSS device driver audio interface. This
approach will expose the HDMI audio functionality to any interested entity.
In a separate
Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.
At the moment, a hardirq-safe spinlock is used to protect the audio
functions. This is because such
As the hdmi_lock mutex is inside the hdmi struct, rename to simply
lock. This is only a change in the name. There are not changes
in functionality.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi_panel.c | 41 +
1 files changed,
According to the most up-to-date documentation from Texas Instruments,
the configuration of High Bitrate Audio is not possible. Also, it is
not possible to set polarity of the I2S Word Select signal. This patch
removes the invalid settings.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
As of today, the only know user of the DSS HDMI audio support is
ASoC. Hence, it makes sense to remap the speaker order to match
the ALSA speaker order. In the future, a dynamic mapping mechanism
may be implemented.
Remapping is needed as the HDMI speaker order is FL/FR/LFE/C/RL/RR/
The generic HDMI driver does not need to know about the specific
settings of a given IP. Hence, it just passes the audio configuration
and the IP library parses such configuration and sets the IP
accordingly. This patch introduces an IP-specific audio configuration
function.
Also, this patch
Add support for more sample rates when calculating N and CTS. This
covers all the audio sample rates that an HDMI source is allowed
to transmit according to the HDMI 1.4a specification.
Also, reorganize the logic for the calculation when using deep color.
Signed-off-by: Ricardo Neri
Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/Kconfig |4
Instead of having its own definitions for CEA-861 and IEC-60958, the HDMI
driver should use those provided by ALSA. This patch removes the definitions
that are already provided by ALSA.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 34
From: Axel Castaneda Gonzalez x0055...@ti.com
Decouple the enable/disable operation of the HDMI audio wrapper from
audio start/stop. Otherwise, an audio FIFO underflow may occur. The
audio wrapper enablement must be done after configuration and
before audio playback is started.
Signed-off-by:
Hi,
This set of patches is intended to prepare the HDMI driver to implement the DSS
device driver interface for audio proposed here:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67804.html
In preparation for that, it removes the current ASoC HDMI codec driver and
decouples HDMI
Hi Tony,
This is me again; asking if you had any chance to look at these patches.
Thanks!
Ricardo
On 04/25/2012 06:29 PM, Ricardo Neri wrote:
Hi Tony,
I was wondering if you've had the time to take a look at these patches.
Thanks!
Ricardo
On 04/17/2012 07:40 PM, Ricardo Neri wrote:
This
Hi Sakari,
On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre
On 16:34 Thu 03 May , Stephen Warren wrote:
On 05/03/2012 09:27 AM, Tony Lindgren wrote:
Hi,
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 00:16]:
I really like it
I was working on something simillar
but can we split the group management so we
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY j-keer...@ti.com wrote:
On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman khil...@ti.com wrote:
Mark Brown broo...@opensource.wolfsonmicro.com writes:
On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
Mark Brown
On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
Why not simply managing the pending bit for level irqs ?
Hi Thomas,
thanks again for the patch. I finally made time to test it and it works as
expected. I've included it below with a change-log entry and
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct
101 - 153 of 153 matches
Mail list logo
