On 01/04/2013 12:26 AM, Paul Walmsley wrote:
On Thu, 3 Jan 2013, Jon Hunter wrote:
I am not sure that this change to the comment is completely accurate. On
OMAP4430 I did not see any issues with the DPLL failing to turn on if
the DPLL was not locked. I only saw this particular problem on the
Hello,
Changes since v1:
- Update the comment in cclock44xx_data.c as suggested by Jon Hunter
I have noticed that in 3.8-rc2 kernel OMAP4 audio is not working correctly. The
audio playback is in 'slow motion' mode.
The following two patch fixes this regression.
We need to lock the ABE DPLL for
To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
asda d
---
arch/arm/mach-omap2/cclock44xx_data.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git
McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, Jan 03, 2013 at 11:33:12AM -0600, Ricardo Neri wrote:
Just wondering if you had a chance to take a look at these patches.
Don't top post. Whatever patches you're talking about I don't have them
(given that they say ARM: OMAP4: I'm likely to have just discarded
them if you sent them to
This patch serie extends the the hwmod HWMOD_EXT_OPT_MAIN_CLK flag for the
AESS IP. This IP has additional register for Auto Gatting configuration. As
it is used only for Audio the driver is not always loaded. We can reuse the
same flag as McPDM to work around the HW problem due to bad reset value
Rename HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to
be present during initialization. Same flag can be use for IP with
additional HW registers to control Auto IDLE mode.
Signed-off-by: Sebastien Guiriec
The AESS on OMAP4 has additional register on top of SYS_CONFIG for
auto gatting configuration. In order to avoid running clock after
boot up we should avoid to enable and reset the module during boot up.
Audio driver will be in charge of configuring the addition register.
At its core, this patch
Enable AESS data in hwmod in order to be able to probe
audio driver.
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
Hi Paul,
I just tested this + next two powerdomain series from you on omap3beagle
+ omap4panda boards. This set seems fine, for the code I don't have any
major complaints either, thus you can add my ack if you like. I'll send
comments for the next two sets soon also.
-Tero
On Sat, 2012-12-08 at
Hi Gary,
On 01/04/2013 02:20 PM, Gary Thomas wrote:
On Thursday, January 3, 2013 9:21:19 AM UTC-7, Felipe Balbi wrote:
Hi,
On Wednesday, January 2, 2013 10:44:50 PM UTC+2, Gary Thomas wrote:
I have a video adapter attached to my EHCI port which runs full
Hi Paul / Jean,
On Wed, 2012-12-12 at 11:33 +0100, Jean Pihet wrote:
clip
+/**
+ * _match_pwrst: determine the closest supported power state
+ * @pwrsts: list of allowed states, defined as a bitmask
+ * @pwrst: initial state to be used as a starting point
+ * @min: minimum (i.e.
Hi Paul,
On Sun, 2012-12-09 at 10:53 -0700, Paul Walmsley wrote:
clip
@@ -112,24 +112,26 @@ static void omap3_core_restore_context(void)
static void omap3_save_secure_ram_context(void)
{
u32 ret;
- int mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
+ int
Hi Paul,
On Sun, 2012-12-09 at 10:53 -0700, Paul Walmsley wrote:
clip
@@ -40,20 +39,19 @@ static LIST_HEAD(pwrst_list);
static int omap4_pm_suspend(void)
{
struct power_state *pwrst;
- int state, ret = 0;
+ int prev_fpwrst;
+ int ret = 0;
u32 cpu_id =
On 01/03/2013 02:52 PM, Sergei Shtylyov wrote:
Hello.
On 02-01-2013 19:00, Roger Quadros wrote:
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of
Hi Paul,
On Sun, 2012-12-09 at 10:53 -0700, Paul Walmsley wrote:
From: Jean Pihet jean.pi...@newoldbits.com
The PM code uses some counters to keep track of the power domains
transitions, in order to provide the information to drivers (in
pwrdm_get_context_loss_count) and to expose the
Hi Paul,
As mentioned with the previous set, I have tested this one also on
omap3beagle + omap4panda boards. omap4 has one regression caused by this
set, as commented on the patch itself. Also posted a couple of other
minor comments. Other than that, you can consider this set as acked by
me.
Hi Samuel,
Below is the pull request for this series. I've addressed the recent
indentation issue pointed out by Sergei.
The following changes since commit cfa7abd7a92396923889fc870090b5d748c603ab:
Merge branch 'heads/fixes' into for-next (2013-01-02 12:40:04 -0800)
are available in the git
Hi Paul,
Tested this whole set on omap3beagle and omap4panda. The only regression
I noticed was that cpu0 debug counters do not increment on omap4 after
this set. The patch at the end fixes this problem. Other than that, you
can add acked-by tag from me if you want, I went the code through
Hi,
On Tue, 2012-12-11 at 17:02 +, Jack Mitchell wrote:
On 11/12/12 16:24, Jack Mitchell wrote:
On 11/12/12 15:22, Ben Gamari wrote:
Jack Mitchell m...@communistcode.co.uk writes:
Thank you, the reordering dma patch fixed the dma issue I was having!
However, the bad news, I now get
On 01/04/2013 04:09 AM, Peter Ujfalusi wrote:
To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
asda d
Not sure what the above is ;-)
---
On 01/04/2013 04:10 PM, Jon Hunter wrote:
On 01/04/2013 04:09 AM, Peter Ujfalusi wrote:
To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
asda d
Not sure what the above
On 04/01/13 14:46, Jan Lübbe wrote:
Hi,
On Tue, 2012-12-11 at 17:02 +, Jack Mitchell wrote:
On 11/12/12 16:24, Jack Mitchell wrote:
On 11/12/12 15:22, Ben Gamari wrote:
Jack Mitchell m...@communistcode.co.uk writes:
Thank you, the reordering dma patch fixed the dma issue I was having!
Am 04.01.2013 14:20, schrieb Roger Quadros:
Hi Gary,
On 01/04/2013 02:20 PM, Gary Thomas wrote:
On Thursday, January 3, 2013 9:21:19 AM UTC-7, Felipe Balbi wrote:
Hi,
On Wednesday, January 2, 2013 10:44:50 PM UTC+2, Gary Thomas wrote:
I have a video adapter attached to
On 04/01/13 16:21, Jack Mitchell wrote:
On 04/01/13 14:46, Jan Lübbe wrote:
Hi,
On Tue, 2012-12-11 at 17:02 +, Jack Mitchell wrote:
On 11/12/12 16:24, Jack Mitchell wrote:
On 11/12/12 15:22, Ben Gamari wrote:
Jack Mitchell m...@communistcode.co.uk writes:
Thank you, the reordering dma
On Fri, Jan 04, 2013 at 09:10:02AM -0600, Jon Hunter wrote:
On 01/04/2013 04:09 AM, Peter Ujfalusi wrote:
To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
asda d
On Fri, 4 Jan 2013, Peter Ujfalusi wrote:
On 01/04/2013 04:10 PM, Jon Hunter wrote:
On 01/04/2013 04:09 AM, Peter Ujfalusi wrote:
To avoid issues with audio caused by non locked ABE DPLL we should
make sure it is locked in all OMAP4 revisions.
Signed-off-by: Peter Ujfalusi
Hi Sebastien
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
Rename HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to
be present during initialization. Same flag can be use for IP with
additional HW registers to
Hi Sebastien
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
The AESS on OMAP4 has additional register on top of SYS_CONFIG for
auto gatting configuration. In order to avoid running clock after
boot up we should avoid to enable and reset the module during boot up.
Audio driver will be in
The following patchset introduces Device Tree overlays, a method
of dynamically altering the kernel's live Device Tree.
This patchset is against mainline as of Friday Jan 4 2013.
(4956964 Merge tag 'driver-core-3.8-rc2' of \
Helper functions for working with device node flags.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
include/linux/of.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index 5ebcc5c..2ff35b5 100644
---
There are other users for the proc DT functions.
Export them.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/base.c | 108 -
include/linux/of.h | 29 ++
2 files changed, 87 insertions(+), 50
Introduce helper functions for working with the live DT tree.
__of_free_property() frees a dynamically created property
__of_free_tree() recursively frees a device node tree
__of_copy_property() copies a property dynamically
__of_create_empty_node() creates an empty node
Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare a device tree that's
been loaded on runtime to be modified and inserted at the kernel
live tree.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
of_property_notify can be utilized by other users too, export it.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/base.c | 8 +---
include/linux/of.h | 11 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/of/base.c
On 01/04/2013 07:35 PM, Paul Walmsley wrote:
Hi Sebastien
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
The AESS on OMAP4 has additional register on top of SYS_CONFIG for
auto gatting configuration. In order to avoid running clock after
boot up we should avoid to enable and reset the module
On 01/04/2013 07:19 PM, Paul Walmsley wrote:
Hi Sebastien
On Fri, 4 Jan 2013, Sebastien Guiriec wrote:
Rename HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to
be present during initialization. Same flag can be
On Thu, Jan 03, 2013 at 10:23:24PM +0100, Laurent Pinchart wrote:
The plat/*.h headers are not available to drivers in multiplatform
kernels. As the header isn't needed, just remove it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus
Hi Mark,
On 01/04/2013 04:42 AM, Mark Brown wrote:
On Thu, Jan 03, 2013 at 11:33:12AM -0600, Ricardo Neri wrote:
Just wondering if you had a chance to take a look at these patches.
Don't top post.
Sorry, my bad. Won't do it again.
Whatever patches you're talking about I don't have them
Hi Mark, Tomi, Liam, Tony,
I am resending this series as Mark and possibly other people missed it.
This set aims to be the version 3 of my previous submission[1] and aims to
address the comments that Mark and Tomi kindly provided on such submission.
The creation of the platform device for the
Assign more logical and meaningful names to the platform devices used
by ASoC OMAP HDMI drivers.
The previous omap-hdmi-audio device is renamed as omap-hdmi-audio-card
This is to better illustrate the fact that it describes the whole HDMI
audio in a given board.
The previous omap-hdmi-audio-dai
While Pandaboard and SDP4430 have only one HDMI output connector, it may be
possible that future boards and SoCs support more than one HDMI output.
Thus, we define the identifier of the device. This is used by display
common code to identify and create the platform devices for HDMI audio drivers.
Relocate the creation the platform devices for audio the HDMI audio codec and
the audio card to display.c. This allows the display code to create the required
platform devices based on what is wired on the board. Thus, as many devices as
required are created; or none if the HDMI ouptut is not
The HDMI display and audio functionality share the same resources (e.g.,
register
spaces). The ASoC HDMI CPU-DAI driver needs access to some (but not all) the
resources of the dss_hdmi platform device. As such resources are within the
address space of omapdss_hdmi, it makes sense to have the DSS
Instead of passing the complete address space to the platform device for audio,
just pass the address offset of the DMA port for audio samples. Thus, we prevent
that two drivers try to ioremap the same resources. This is to be safe, as the
ASoC HDMI CPU-DAI driver will not need to ioremap such
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote:
The following patchset introduces Device Tree overlays, a method
of dynamically altering the kernel's live Device Tree.
It would be nice to know the motivation for this code.
What is the use case? What problem or issue is being
Hi Richard,
On Fri, Jan 4, 2013 at 9:35 PM, Richard Cochran
richardcoch...@gmail.com wrote:
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote:
The following patchset introduces Device Tree overlays, a method
of dynamically altering the kernel's live Device Tree.
It would be
47 matches
Mail list logo
