Hi,
* Hiremath, Vaibhav [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
> > >
> > > This patch adds minimal support for AM335X EVM.
> > > The approach taken here is to add AM335X
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"
> >
> > The davinci EMAC driver has been incorporated into the am35x
> > family of SoC's which is OMAP-based. The incorporation is
> > incomplete in
> > @@ -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 wrote:
> Venkatraman S writes:
>
>> From: Ilan Smith
>>
>> 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.
>>
> [...]
>> + if (bio_swapin(bio) && blk_qu
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
>
> * Hiremath, Vaibhav [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
> > > >
> > > > This patch adds mi
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
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"
> > >
> > > The davinci EMAC driver has been incorporated into the am35x
> > > family of
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"
> > > >
> > > > T
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj wrote:
> On Wed, May 2, 2012 at 2:17 PM, Russ Dill wrote:
>> On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj
>> wrote:
>>> On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
>>> wrote:
From: Keshava Munegowda
It is observed that
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
* Hiremath, Vaibhav [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
Santosh posted
Daniel Lezcano 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 updated the changelog lo
Daniel Lezcano writes:
> and check the powerdomain lookup is successful.
>
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> ---
> arch/arm/mach-omap2/cpuidle34xx.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>
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?
> >
> > Assu
On 05/03/2012 10:19 PM, Kevin Hilman wrote:
Daniel Lezcano 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 numb
Daniel Lezcano 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
> Reviewed-by: Jean Pihet
This patch breaks compilation for the !CO
Hi Daniel,
Daniel Lezcano 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 this version and I think
"Hiremath, Vaibhav" writes:
> On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
>> Hi,
>>
>> * Hiremath, Vaibhav [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 Moha
Ben Hutchings writes:
> 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) wh
Santosh Shilimkar 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 DMA IP version
On 04/30/2012 03:17 PM, Jon Hunter wrote:
> From: Jon Hunter
>
> 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 documentation first;
On 05/03/2012 09:27 AM, Tony Lindgren wrote:
> Hi,
>
> * Jean-Christophe PLAGNIOL-VILLARD [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
On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
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 perhaps you want to
restrict i
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:
On 05/03/2012 10:26 PM, Kevin Hilman wrote:
Daniel Lezcano writes:
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/a
On 05/03/2012 10:34 PM, Kevin Hilman wrote:
Daniel Lezcano 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
Reviewed-by: Jean Pihet
This p
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>;
> > +
On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote:
> On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
> 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?
>
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 p
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 a
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 actual
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 functionalit
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 p
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 functi
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
---
drivers/video/omap2/dss/hdmi_panel.c | 41 +
1 files changed, 21 insertions(+),
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
---
drivers/video/omap2/dss
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/
RLC-FLC/RRC-FL
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 imple
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
---
drivers
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
---
drivers/video/omap2/dss/Kconfig |4
drivers/video/omap2/dss/dss_fe
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
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 34 ++--
drivers/video/o
From: Axel Castaneda Gonzalez
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: Axel Castaneda Gon
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 aud
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 se
Hi Sakari,
On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio wrote:
> Hi Sakari,
>
> Thanks for reviewing.
>
> On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus wrote:
>>
>> Hi Sergio,
>>
>> Thanks for the patches!!
>>
>> On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
>> ...
>>> +stati
On 16:34 Thu 03 May , Stephen Warren wrote:
> On 05/03/2012 09:27 AM, Tony Lindgren wrote:
> > Hi,
> >
> > * Jean-Christophe PLAGNIOL-VILLARD [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 wrote:
> On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman wrote:
>> Mark Brown writes:
>>
>>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
Mark Brown writes:
>>>
> But presumably these things should integrate somehow - for examp
On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
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 tested-by:
in case
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 omap_display_platform_data
On Fri, May 04, 2012 at 02:47:34, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" writes:
>
> > On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> >> Hi,
> >>
> >> * Hiremath, Vaibhav [120502 02:37]:
> >> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> >> > > Hi
> >> > >
> >> > > O
Hi Russ,
On 05/03/12 22:08, Russ Dill wrote:
> On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj wrote:
>> On Wed, May 2, 2012 at 2:17 PM, Russ Dill wrote:
>>> On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj
>>> wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
wrote:
>
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the
On Fri, May 04, 2012 at 01:07:32, Tony Lindgren wrote:
> * Hiremath, Vaibhav [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.
>
I am also
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
>
> * Hiremath, Vaibhav [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
> > > >
> > > > This patch adds mi
On Friday 04 May 2012 05:33 AM, Greg KH wrote:
> On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote:
>> On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
>> wrote:
>>> Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
>>
>> Hi Santosh,
>>
>> Can you send Greg a
Hi Archit,
On Fri, 13 Apr 2012, Archit Taneja wrote:
> On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote:
> > On 4/13/2012 10:01 AM, Archit Taneja wrote:
> > > The clock for all DSS L3 slave interfaces had been recently changed to
> > > "dss_fck" from "l3_div_ck". "dss_fck" is an optional c
On 1 May 2012 02:47, Jon Hunter wrote:
> From: Jon Hunter
>
> 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.
>
> Aim of DMA helpers
> - The purpose of device-tr
101 - 160 of 160 matches
Mail list logo
