On Wednesday 28 March 2012 12:02 PM, Hiremath, Vaibhav wrote:
On Tue, Mar 27, 2012 at 15:28:31, Nayak, Rajendra wrote:
Some functions like _omap4_disable_module() and _omap4_wait_target_disable()
are (will be) used on all OMAPs OMAP4 and beyond which support module level
control. Fix the error c
On Thu, Mar 29, 2012 at 10:28 AM, Olof Johansson wrote:
> Hi,
>
> Sorry for the slow reply, I noticed this when dealing with merge
> conflicts pulling in this patch and others from Tony.
>
> On Mon, Mar 19, 2012 at 5:06 AM, Tarun Kanti DebBarma
> wrote:
>> With dynamic allocation of IRQ the usage
Hi Tony,
On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren wrote:
> Hi Arnd & Olof,
>
> Here's a set of fixes that would be nice to get merged during
> the merge window before the GPIO changes get merged to avoid
> boot issues on many omap boards.
>
> The changes queued in the GPIO tree require get
Hi,
Sorry for the slow reply, I noticed this when dealing with merge
conflicts pulling in this patch and others from Tony.
On Mon, Mar 19, 2012 at 5:06 AM, Tarun Kanti DebBarma
wrote:
> With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
> is no longer valid. We should be using gpio_to_irq
VENC type (composite/svideo) doesn't have to be fixed by board wiring,
it is possible to provide both connectors, which is what pandora does.
Having to recompile the kernel for users who have TV connector types
that's don't match default board setting is very inconvenient, especially
for users of a
Decouple the enablement of the HDMI audio wrapper from audio start.
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: Ricardo Neri
---
drivers/video/omap2/dss/dss_features.c|1 +
The N and CTS parameters are relevant to all HDMI implmentations 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 functionality
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
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 the DMA, format an
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.
A HW-safe spinlock is used to protect the audio functions. This is because
the audio functions may be call
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_f
Hi,
This set of patches is inteded to prepare the HDMI driver to implement the DSS
device driver interface for audio proposed here:
http://www.spinics.net/lists/linux-omap/msg67303.html
In preparation for that, it removes the current ASoC HDMI codec driver and
decouples HDMI audio build configura
Provide more configuration parameters for the IEC-60958 channel status word.
For this, a new structure containing the relevant parameters is created. Some
of the parameters previously located in the I2S structure are moved
to the new IEC-60958 struct to improve the logical organization of the code.
In order to avoid duplication of definitions. Use the definitions provided
by asoundef.h. Furthermore, as CEA-861 and IEC-60958 are used by both
DisplayPort and HDMI, this helps to make the code more generic.
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 15 +++---
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index d6b49b6..9fa5cb1 100644
--- a/drivers/video/omap2/dss/ti
Instead of having an ASoC codec embedded into DSS code, use the generic DSS
device driverinterface for audio support. This allows to any potential user,
including an ASoC driver, take advantage of the HDMI audio functionality.
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/hdmi.c | 236
* H Hartley Sweeten [2012-03-28 11:13:09-0700]:
>
> Use the default partition parser, cmdlinepart, provided by the plat_nand
> driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Imre Kaloz
> Cc: Krzysztof Halasa
> Cc: Tony Lindgren
> Cc: Alexander Clouter
> Cc: Nicolas Pi
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)
As discussed in the description of the patch, this is intended to cover
audio implementation based on CEA-861 and IEC-6
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 or any other driver interested in the
functionality.
The DSS audio functions are intended to be used a
From: Konstantin Shlyakhovoy
RTC stores time and date in several registers. Due to the fact that
these registers can't be read instantaneously, there is a chance
that reading from counting registers gives an error of one minute,
one hour, one day, etc.
To address this issue, the RTC has hardware
Dear H Hartley Sweeten,
> Use the default partition parser, cmdlinepart, provided by the plat_nand
> driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Imre Kaloz
> Cc: Krzysztof Halasa
> Cc: Tony Lindgren
> Cc: Alexander Clouter
> Cc: Nicolas Pitre
> Cc: Eric Miao
> Cc:
Use the default partition parser, cmdlinepart, provided by the plat_nand driver.
Signed-off-by: H Hartley Sweeten
Cc: Ryan Mallon
Cc: Imre Kaloz
Cc: Krzysztof Halasa
Cc: Tony Lindgren
Cc: Alexander Clouter
Cc: Nicolas Pitre
Cc: Eric Miao
Cc: Haojian Zhuang
Cc: Marek Vasut
---
diff --gi
This patch series adds cmdlinepart as the default partition parser for the
plat_nand driver and updates all the arch setup code to use it.
Arch setup code that requires other partition parsers can still pass that
information as chip.part_probe_types.
Signed-off-by: H Hartley Sweeten
mtd: plat_
+Paul, NeilBrown who both have worked on/around recent UART breakage
since v3.2
"Joe Woodward" writes:
[...]
> This patch fixes the suspend problem for me, but there is another UART
> issue...
>
> Basically I've got a fairly high speed data source (in UART terms,
> >900KBaud) pumping data to
* Igor Grinberg [120327 23:36]:
> Hi Tony,
>
> On 03/27/12 19:28, Tony Lindgren wrote:
> > * Igor Grinberg [120327 08:56]:
> >> Hi Russ,
> >>
> >> This patch works, but can we, please use the attached patch instead?
> >
> > Hmm what's the difference here? Do you have some real controllable
> >
Hi Govindraj,
On 3/28/2012 6:09, Raja, Govindraj wrote:
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter wrote:
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
From: "Govindraj.R"
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version che
Hi Paul,
On 3/27/2012 21:39, Paul Walmsley wrote:
Hi Jon,
On Tue, 27 Mar 2012, Jon Hunter wrote:
On 3/27/2012 4:58, Rajendra Nayak wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 8ac26f2..f2a9afa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
From: "Govindraj.R"
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now
-Original Message-
From: "Raja, Govindraj"
To: Kevin Hilman
Cc: Joe Woodward , "linux-omap@vger.kernel.org"
, Felipe Balbi
Date: Wed, 28 Mar 2012 16:29:53 +0530
Subject: Re: Suspend broken on 3.3?
> On Wed, Mar 28, 2012 at 3:07 AM, Kevin Hilman wrote:
> > "Raja, Govindraj" writes:
>
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav wrote:
> On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
>> On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav wrote:
>> > On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
>> >> On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Va
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
> On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav wrote:
> > On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
> >> On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav wrote:
> >> > On Mon, Mar 19, 2012 at 17:45:32, Shilimkar
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav wrote:
> On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
>> On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav wrote:
>> > On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
>> >> On Monday 19 March 2012 05:14 PM, Ming Lei wr
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
> On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav wrote:
> > On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
> >> On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
> >> > On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
Hi Igor,
On Wed, Mar 28, 2012 at 4:43 PM, Igor Grinberg wrote:
> Hi Shubhrajyoti,
>
> On 03/28/12 12:03, Shubhrajyoti wrote:
>> On Tuesday 27 March 2012 07:38 PM, Igor Grinberg wrote:
>>> When PHY reset pin is connected to a GPIO on external GPIO chip
>>> (e.g. I2C), we should not call the gpio_s
On Wed, Mar 28, 2012 at 4:23 PM, Raja, Govindraj wrote:
> On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi wrote:
>> On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote:
>>> When PHY reset pin is connected to a GPIO on external GPIO chip
>>> (e.g. I2C), we should not call the gpio_set_valu
On 03/28/12 12:53, Raja, Govindraj wrote:
> On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi wrote:
>> On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote:
>>> When PHY reset pin is connected to a GPIO on external GPIO chip
>>> (e.g. I2C), we should not call the gpio_set_value() function, b
Hi Shubhrajyoti,
On 03/28/12 12:03, Shubhrajyoti wrote:
> On Tuesday 27 March 2012 07:38 PM, Igor Grinberg wrote:
>> When PHY reset pin is connected to a GPIO on external GPIO chip
>> (e.g. I2C), we should not call the gpio_set_value() function, but
>> gpio_set_value_cansleep().
> Why so ? Whats t
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter wrote:
> Hi Govindraj,
>
>
> On 3/21/2012 5:24, Govindraj.R wrote:
>>
>> From: "Govindraj.R"
>>
>> Currently the errata is populated based on cpu checks this can
>> be removed and replaced with module version check of uart ip block.
>> MVR reg is provide
On Wed, Mar 28, 2012 at 3:07 AM, Kevin Hilman wrote:
> "Raja, Govindraj" writes:
>
>> Hi Kevin,
>>
>> On Tue, Mar 27, 2012 at 6:04 AM, Kevin Hilman wrote:
>>> +Govindraj,
>>>
>>> "Joe Woodward" writes:
>>>
Right, I've stepped back a bit and dug out a GUSMTIX Palo43 carrier
board on wh
On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi wrote:
> On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote:
>> When PHY reset pin is connected to a GPIO on external GPIO chip
>> (e.g. I2C), we should not call the gpio_set_value() function, but
>> gpio_set_value_cansleep().
>>
>> Signed-o
Enable the power off feature of the TPS65930 on-board PMIC.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 8770be1..462
On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote:
> When PHY reset pin is connected to a GPIO on external GPIO chip
> (e.g. I2C), we should not call the gpio_set_value() function, but
> gpio_set_value_cansleep().
>
> Signed-off-by: Igor Grinberg
Acked-by: Felipe Balbi
Keshava, ple
On Mon, Mar 26, 2012 at 7:14 PM, Shubhrajyoti D wrote:
> From: Benoit Cousson
>
> bus_num was used to reference the mcspi controller instance in a fixed array.
> Remove this array and store this information directly inside drvdata
> structure.
>
> bus_num is now just set if the pdev->id is prese
43 matches
Mail list logo
