Hello,
The ASoC HDMI codec used to be embedded in the DSS HDMI driver. In order
to give the OMAP HDMI code a more logical arrangement and to remove
some dependency breaks[1][2], such ASoC HDMI codec was removed[3]. Instead, the
DSS HDMI audio functionality[4] is now provided through the new DSS de
Make Kconfig and Makefile more generic to encompass not only
OMAP4 but other OMAP processors featuring HDMI.
Also, relax the dependency list to depend only on any OMAP processor
supporting OMAP2_DSS and OMAP4_DSS_HDMI. As HDMI support for
future OMAP versions is added, the dependency list must cha
Rename sound card driver source file to encompass not only OMAP4 but future
OMAP versions that feature HDMI.
Signed-off-by: Ricardo Neri
---
sound/soc/omap/Makefile |4 +-
sound/soc/omap/omap-hdmi-card.c | 87 ++
sound/soc/omap/omap4-hdmi-card.
Instead of accessing the HDMI IP directly, the CPU DAI driver takes
advantage of the audio interface provided by the DSS device driver.
The ASoC driver will link the DSS audio functionality with ALSA by
calling the appropriate DSS device driver functions at the relevant
moments. For this, three new
According to the HDMI specification, a source is permitted to
transmit L-PCM audio in the following sample rates: 32kHz, 44.1kHz,
48kHz, 88.2kHz, 96kHz, 176.4kHz or 192kHz.
It also supports up to 8 audio channels.
The sink may not necessarily support all these sample rates and
channels. However,
Before starting to play audio, we need to make sure that the
display is active and the current video mode supports audio. instead
of using the overlay manager in the machine driver, we use the DSS audio
interface's audio_supported function. As we already have a pointer to
the correct dssdev, we do
Rename all the relevant structures, variables and functions to not
make specific reference to OMAP4. This is to make the driver encompass
future OMAP versions that feature HDMI and not only OMAP4. These
changes are only in naming. There are not functional changes.
Signed-off-by: Ricardo Neri
---
Expand the configuration of the hw_params to include the IEC-60958
channel status word and the CEA-861 audio infoframe. The configuration
of such structures depends on the snd_pcm_hw_params received. A
omap_dss_audio is used to pass the configuration parameters to DSS.
Signed-off-by: Ricardo Neri
In order to utilize the new OMAP HDMI codec and the updated name of
the device of the CPU DAI, update the names at the drivers accordingly.
While there, also update the name of the machine driver to be more
generic and encompass more OMAP processors featuring HDMI and not
only OMAP4.
Signed-off-b
Create a struct hdmi_priv to store the relevant data of the CPU DAI
driver. As more data is added to the driver, having all the data
in the same location eases its handling. At the moment, only the DMA
configuration parameters are included in the structure.
Also, the required memory is allocated u
Introduce codec for HDMI. At the moment, this is a dummy codec. In the
future it will parse the EDID to modify the supported parameters, such
as the number of channels and the sample rates. At the moment, it blindly
supports all the sample rates and audio channels described in the HDMI
1.4a specifi
When getting the needed resources fails, return -ENODEV. This is more
in line with other drivers do and it gives a more descriptive error.
Signed-off-by: Ricardo Neri
---
sound/soc/omap/omap-hdmi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-hd
On Fri, May 18, 2012 at 5:26 AM, Kevin Hilman wrote:
> Tony Lindgren writes:
>
>> * Kevin Hilman [120517 15:29]:
>>>
>>> I just noticed that this patch has caused some strange problems, notably
>>> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>>>
>>> The patch itself
On Thu, May 17, 2012 at 10:45 PM, Kevin Hilman wrote:
> "Shilimkar, Santosh" writes:
>
>> On Wed, May 16, 2012 at 10:21 PM, Kevin Hilman wrote:
>>> Santosh Shilimkar writes:
>>>
Kevin,
On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
> On Wednesday 16 May 2012 03:1
On Thu, May 17, 2012 at 10:17 PM, Kevin Hilman wrote:
> "Shilimkar, Santosh" writes:
>
>> On Thu, May 17, 2012 at 5:45 AM, Kevin Hilman wrote:
>>> Tero Kristo writes:
>>>
From: Santosh Shilimkar
Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
Transition Wh
On Thu, May 17, 2012 at 10:15 PM, Kevin Hilman wrote:
> "Shilimkar, Santosh" writes:
>
>> On Thu, May 17, 2012 at 4:35 AM, Kevin Hilman wrote:
>>> Tero Kristo writes:
>>>
From: Santosh Shilimkar
The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
IVA and
On Thu, May 17, 2012 at 10:12 PM, Kevin Hilman wrote:
> "Shilimkar, Santosh" writes:
>
>> On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman wrote:
>>> Tero Kristo writes:
>>>
From: Santosh Shilimkar
The SAR RAM is maintained during Device OFF mode.
>>>
>>> so why is this patch bothe
On Fri, May 18, 2012 at 3:51 AM, Kevin Hilman wrote:
> Tarun, Santosh,
>
> Tarun Kanti DebBarma writes:
>
>> We do checking for bank->enabled_non_wakeup_gpios in order
>> to skip redundant operations. Somehow, the check got missed
>> while doing the cleanup series.
>>
>> Just to make sure that we
On Fri, May 18, 2012 at 5:26 AM, Kevin Hilman wrote:
> Tony Lindgren writes:
>
>> * Kevin Hilman [120517 15:29]:
>>>
>>> I just noticed that this patch has caused some strange problems, notably
>>> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>>>
>>> The patch itself
The IRQ52 on OMAP2+ is not a shared interrupt line. If IRQF_SHARED
is passed to request_irq and dev_id is set as NULL, request_irq will
return -EINVAL.
This patch just removes the flag of IRQF_SHARED to make the irq
registration successful.
Cc: Kevin Hilman
Cc: Tony Lindgren
Signed-off-by: Ming
On Thu, May 17, 2012 at 8:55 PM, Dmitry Torokhov
wrote:
> Hi Sourav,
>
> On Thu, May 17, 2012 at 07:01:49PM +0530, Poddar, Sourav wrote:
>> Hi Dmitry,
>>
>> Gentle Ping on this..
>
> The patch has been committed to my 'next' branch for 3.5 on 05/11/12:
>
Thanks.
> http://git.kernel.org/?p=linux/ke
* Kevin Hilman [120517 17:00]:
>
> Argh, then $SUBJECT patch here has caused brokeness in multiple ways.
> It managed to break both runtime suspend and runtime resume at the same
> time. :(
>
> The change added by this patch to runtime_suspend effectively disables
> the fix I did in 68942edb09 (
* Ohad Ben-Cohen [120516 02:58]:
> Hi Tony,
>
> Two important fixes from Juan that are necessary to utilize the DSP on
> OMAP4, and a trivial hwspinlock cleanup.
>
> I tried to keep things as simple as possible, but please tell me if
> you want this pull request anyway differently (e.g. split to
Tony Lindgren writes:
> * Kevin Hilman [120517 15:29]:
>>
>> I just noticed that this patch has caused some strange problems, notably
>> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>>
>> The patch itself is OK, but it has exposed a bug in other parts of the
>> con
On Thu, 17 May 2012 15:21:07 -0700, Kevin Hilman wrote:
> Tarun, Santosh,
>
> Tarun Kanti DebBarma writes:
>
> > We do checking for bank->enabled_non_wakeup_gpios in order
> > to skip redundant operations. Somehow, the check got missed
> > while doing the cleanup series.
> >
> > Just to make su
* Kevin Hilman [120517 15:29]:
>
> I just noticed that this patch has caused some strange problems, notably
> with the GPIO IRQ used by smsc911x NIC (Overo, Zoom3, 2430SDP, etc. etc.)
>
> The patch itself is OK, but it has exposed a bug in other parts of the
> context restore path that was previ
Tarun, Santosh,
Tarun Kanti DebBarma writes:
> We do checking for bank->enabled_non_wakeup_gpios in order
> to skip redundant operations. Somehow, the check got missed
> while doing the cleanup series.
>
> Just to make sure that we do context restore correctly in
> *_runtime_resume(), the bank->
Jon Hunter writes:
> From: Jon Hunter
>
> The OMAP2+ timer code has a definition for the maximum number of timers that
> OMAP2+ devices have. This defintion is not used anywhere in the code and
> appears to be left over. Furthermore the definition is not accurate for OMAP4
> devices that only ha
On 05/16/2012 03:16 PM, Jassi Brar wrote:
> On 17 May 2012 01:12, Arnd Bergmann wrote:
...
>> More importantly, you make it very hard to add devices in a board file
>> to a dma controller that already has descriptions for some channels,
>> because you cannot easily extend the chan-map unless you r
Hi Michal,
On Sat, Mar 17, 2012 at 8:39 AM, Ohad Ben-Cohen wrote:
> IOW: you can probably just wait a bit until this patch is ready and
> take it into your tree. It will most likely bring back the behavior you
> need :)
Does something like the attached help ?
Thanks,
Ohad.
0001-remoteproc-all
"Shilimkar, Santosh" writes:
> On Wed, May 16, 2012 at 10:21 PM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> Kevin,
>>>
>>> On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
> Santosh,
>
> Tero Kristo
On Thu, 17 May 2012, Jon Hunter wrote:
> Yes that's right. What is your preference here, the options are ...
>
> 1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
> omap2_xxx API names to omap_xxx.
> 2. Add the functions in clkt_clksel.c to arch/arm/plat-omap/clock.c and
> get r
"Shilimkar, Santosh" writes:
> On Thu, May 17, 2012 at 5:45 AM, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>>> From: Santosh Shilimkar
>>>
>>> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
>>> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
>>> The is
"Shilimkar, Santosh" writes:
> On Thu, May 17, 2012 at 4:35 AM, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>>> From: Santosh Shilimkar
>>>
>>> The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
>>> IVA and Tesla execution.
>>>
>>> At wakeup from MPU OFF on HS device onl
"Shilimkar, Santosh" writes:
> On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>>> From: Santosh Shilimkar
>>>
>>> The SAR RAM is maintained during Device OFF mode.
>>
>> so why is this patch bothering to save and restore it?
>>
> SAR RAM is maintained(not powere
"Shilimkar, Santosh" writes:
> On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh
> wrote:
>> On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman wrote:
>>> Tero Kristo writes:
>>>
From: Rajendra Nayak
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from
Hi Tarun,
On 05/17/2012 12:07 AM, DebBarma, Tarun Kanti wrote:
> On Thu, May 17, 2012 at 1:44 AM, Jon Hunter wrote:
>> Hi Benoit,
>>
>> On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
>>> Hi Jon,
>>>
>>> On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunter
In order to migrate th
Hi Paul,
On 05/16/2012 06:30 PM, Paul Walmsley wrote:
> Hello Jon,
>
> On Wed, 16 May 2012, Jon Hunter wrote:
>
>> I have been looking into this and in order to get rid for the above
>> function pointer we would need to move at a minimum the following
>> functions from omap-mach2/clkt_clksel.c i
Hi Sourav,
On Thu, May 17, 2012 at 07:01:49PM +0530, Poddar, Sourav wrote:
> Hi Dmitry,
>
> Gentle Ping on this..
The patch has been committed to my 'next' branch for 3.5 on 05/11/12:
http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=f77621cc640a7c50b3d8c5254ecc5d91eaa99d0d
T
Hi,
On Thu, May 17 2012, S, Venkatraman wrote:
> On Thu, May 17, 2012 at 7:57 AM, Ming Lei wrote:
>> The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
>> otherwise the following failure message should be dumped because
>> hardware handler is defined as NULL:
>>
>> [ 3.383483]
On Thu, May 17, 2012 at 02:52:36PM +0100, Mark Brown wrote:
> On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
>
> > DMA on the other hand seems to have cases where you can make a choice
> > between two or more providers of the service. The impression that I'm
> > getting
On Thu, May 17, 2012 at 7:57 AM, Ming Lei wrote:
> The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
> otherwise the following failure message should be dumped because
> hardware handler is defined as NULL:
>
> [ 3.383483] genirq: Threaded irq requested with handler=NULL and
>
On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
> DMA on the other hand seems to have cases where you can make a choice
> between two or more providers of the service. The impression that I'm
> getting from this thread is that it's difficult to describe that kind
> of re
Hi Dmitry,
Gentle Ping on this..
~Sourav
On Wed, May 9, 2012 at 3:37 PM, Poddar, Sourav wrote:
> Hi Dmitry,
>
> On Wed, May 9, 2012 at 3:14 PM, Poddar, Sourav wrote:
>> Hi Dmitry,
>>
>> I did some minor fixes to the patch which you suggested above and
>> the keypad is functional now.
>>
>> Chan
On Wed, May 16, 2012 at 07:42:20PM +, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Jassi Brar wrote:
> > The assumed model of the DMAC, in this binding, has P peripheral
> > interfaces (P request signals) that could request a data transfer
> > and C physical channels that actually do the d
On Thu, May 10, 2012 at 11:00:53AM -0600, Stephen Warren wrote:
> To solve Russell's HW, we need some way of representing the mux directly
> in DT irrespective of how the DMA controller or DMA client specify what
> they're connected to. Anything else isn't representing the HW in DT.
Note that it's
Hi Tony,
This is the updated DTS patch for Vatiscite OMAP4 SOM support
Regatds,
Uri Yosef
Signed-off-by: Uri Yosef
---
arch/arm/boot/dts/omap4-var_som.dts | 96 +++
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4
Hi,
On Thu, May 10 2012, T Krishnamoorthy, Balaji wrote:
> On Tue, May 8, 2012 at 5:05 PM, Venkatraman S wrote:
>> Cleanups for the legacy omap mmc driver to remove clutter and
>> make it well behaved as module.
>>
>> Venkatraman S (3):
>> mmc: omap: convert to per instance workqueue
>> mmc: om
On 5/16/2012 3:34 PM, Jon Hunter wrote:
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunter
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform
clkdm assocations with clocks in the clock framework are useful
only for 'gate' clocks which have enable/disable ops populated.
Get rid of the clkdm_names populated in any other type of clocks.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock2420_data.c | 16
arch/arm/m
Jean,
On Tuesday 08 May 2012 02:10 PM, Jean Pihet wrote:
> Paul,
>
> On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley wrote:
>> Hi
>>
>> On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
>>
>>> From: Jean Pihet
>>>
>>> Introduce functional (or logical) states for power domains and the
>>> API
On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh
wrote:
> On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>>> From: Rajendra Nayak
>>>
>>> SAR/ROM code restores only CORE DPLL to its original state
>>> post wakeup from OFF mode.
>>> The rest of the DPLL's in O
From: Rob Clark
Add support for mmap'ing buffers via dmabuf. For handling mmap of
cached buffers correctly, fault handling and PTE shootdown are used
to track dirty pages and automagically handle cache flushes before
dma access to the buffer.
Signed-off-by: Rob Clark
---
drivers/staging/omapd
From: Rob Clark
This adds support to re-import omapdrm's own buffers. Importing buffers
allocated by other drivers can be added later, but for now is not needed
(we don't yet have any other exportering drivers to test with).
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c
From: Rob Clark
Now that dmabuf mmap support is in dmabuf-next, here is support for it
in omapdrm. Also some basic support to import dmabuf's. For now it
can only re-import dmabuf's that it exported itself, mainly because I
don't yet need anything else and also because at the moment I don't
hav
On Thu, May 17, 2012 at 5:45 AM, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> From: Santosh Shilimkar
>>
>> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
>> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
>> The issue occurs when EMIF_SDRAM_CONFIG is res
On Thu, May 17, 2012 at 4:06 AM, Kevin Hilman wrote:
> +Jean for functional power states
>
> Tero Kristo writes:
>
>> This patch adds device off support to OMAP4 device type.
>
> Description is rather thin for a patch that is doing so much.
>
>> OFF mode is disabled by default,
>
> why?
>
>> howe
On Thu, May 17, 2012 at 4:18 AM, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> From: Rajendra Nayak
>>
>> Restore all CM1/2 module registers as they are lost in OFF mode.
>
> Save and restore?
>
> Also, as in the previous patch. Can this be done using cluster PM
> notifier as well? (I reali
On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> From: Rajendra Nayak
>>
>> SAR/ROM code restores only CORE DPLL to its original state
>> post wakeup from OFF mode.
>> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
>> are saved and restored here dur
On Thu, May 17, 2012 at 4:28 AM, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> From: Santosh Shilimkar
>>
>> The SAR RAM is maintained during Device OFF mode.
>
> so why is this patch bothering to save and restore it?
>
SAR RAM is maintained(not powered down) but somebody needs to
feel the cont
60 matches
Mail list logo
