gmane.linux.ports.arm.omap

RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

Hiremath, Vaibhav — 2012-05-23T10:15:04

Paul,

Just an update on the status,

I used your cleaned version of clocktree data, where you have removed all 
leaf-nodes and merged multiple clocks nodes into one; but it did not work. I 
attempted to review the cleanup and tried to debug, but found it bit hard to 
come back to working clocktree from stripped version. So moved back to my 
submitted clocktree and started stripping the clock leaf-nodes, same way you 
had done it. Now I reached to the stage where I have working clocktree 
without peripheral leaf-nodes and booting on BeagleBone.

I will start working on migrating to common clock framework now, and hoping 
to finish it soon.


Just FYI (may need your help), I got into some issues (still open) during 
this cleanup -


1. In cases where we have clock selection option for node-leafs, like, 
   Timers, I removed enable_reg entry from the node, which results into a 
   kernel error message from function omap2_dflt_clk_disable()

clock: clk_disable called on independent clock %s which has no enable

MP-23

scott owen — 2012-05-23T09:16:17

You are a great winner of 5crore 45larks by microsoft. send Name:Mobile:Address:Country for claims
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states

Santosh Shilimkar — 2012-05-23T06:39:30

Jean,

On Monday 21 May 2012 07:55 PM, Shilimkar, Santosh wrote:

[...]

I have scanned the series again. Somehow I still find myself
not convinced with the approach. I found having PD OSWR
CSWR state is the only change from this series helps to
some extent. But if you look from PRCM point of view,
they are already two distinct power domain states. Only
bad part from programming perspective, is, it's needs
to take care of additional bit to set and get PD state.

If we actually support 'PWRDM_POWER_OSWRET" and
'PWRDM_POWER_CSWRET" as valid state then we can do
everything without the functional power state series.
I mean we can use 'omap_set_pwrdm_state()' as a single
API for programming the PD, instead of duplicating
these all over the place.

OSWR by definition can be customised per power
domain based on various supported logic and
memory states.With this series, OSWR definition
also become static and if that is agreed then
we should cab just make that as a state like
ON/OFF/INACTIVE.

But I don't want to ob

Re: [PATCH 5/5] ARM: OMAP: For all OMAP devices use clock framework to set dmtimer clock source

Jon Hunter — 2012-05-23T00:13:20

On 05/22/2012 03:17 PM, Jon Hunter wrote:

One comment ...

For now, I have not removed the "timer_ip_version" test when attempting
to set the dmtimer to an external clock source (see below). I plan to
remove this in a follow-up series to clean-up the platform data for the
dmtimer. I could have also done it here, but I was thinking that this
should be in its own patch. Hence for now, I am also setting the
timer_ip_version for OMAP1 devices to OMAP_TIMER_IP_VERSION_1 so an
external clock source can be selected.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] ARM: OMAP1: Add dmtimer clock data

Jon Hunter — 2012-05-23T00:06:12

On 05/22/2012 03:17 PM, Jon Hunter wrote:

A couple additional comments here. This patch also ...

1. Adds clock nodes for the omap1 32kHz clock source and the dmtimer
   external clock source.
2. Defines a clk_set_parent() function for OMAP1 devices.
3. Adds a call to propagate_rate() for the 32kHz clock source, so that
   any clocks that default to the 32kHz clock are populated with the
   correct rate on start-up. I noticed that when rebooting the 5912 OSK
   that if the dmtimer was previously set to the 32kHz clock on the
   next boot the parent would still be 32kHz but the rate would show up
   as 0. This fixed the problem.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree

Jon Hunter — 2012-05-22T20:33:05

Hi Tony, Paul,

On 05/17/2012 11:48 AM, Paul Walmsley wrote:

I have posted a new series here [1] to fix omap1 dmtimers and commonise
the code to set dmtimer source clock between omap1 and omap2.

My plan is to rebase this series on top of that, if you are ok with
those changes.

[1] http://marc.info/?l=linux-omap&m=133771799505501&w=2

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] OMAPDSS: write-through caching support for omapfb

Siarhei Siamashka — 2012-05-22T20:25:26

On Tue, May 22, 2012 at 10:54 PM, Siarhei Siamashka
<siarhei.siamashka< at >gmail.com> wrote:

I don't have Pandaboard ES, but still tried to experiment changing the
following line in the kernel sources to benchmark different types of
caching for the framebuffer on Origen board (Exynos 4210):
    https://github.com/torvalds/linux/blob/v3.4/drivers/media/video/videobuf2-memops.c#L158

It was not a totally clean experiment, because 500x500 16bpp pixel
buffer is much smaller than 1MiB L2 cache and the performance numbers
may be a bit odd. Also I have not checked whether the same buffer may
be mapped with different cacheability attributes anywhere else (which
would be bad). But still it was interesting to see whether
write-through cache is of any use and whether it could serve as a
replacement for shadowfb.

Origen board, Exynos 4210, Cortex-A9 1.2GHz, 1920x1080 screen
resolution, 16bpp desktop color depth (I did not find any obvious way
how to change it to 32bpp yet):

$ x11perf -scroll500 -copywinwin500 -copypixpix

[PATCH 4/5] ARM: OMAP1: Add dmtimer clock data

Jon Hunter — 2012-05-22T20:17:49

From: Jon Hunter <jon-hunter< at >ti.com>

Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.

Signed-off-by: Jon Hunter <jon-hunter< at >ti.com>
---
 arch/arm/mach-omap1/clock_data.c |  140 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 140 insertions(+)

diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index d60f690..27acf4c 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
< at >< at > -83,6 +83,12 < at >< at > static struct clk ck_ref = {
 .rate= 12000000,
 };
 
+static struct clk ck_32k = {
+.name= "ck_32k",
+.ops= &clkops_null,
+.rate= 32768,
+};
+
 static struct clk ck_dpll1 = {
 .name= "ck_dpll1",
 .ops= &clkops_null,
< at >< at > -677,6 +683,127 < at >< at > static struct clk i2c_ick = {
 .recalc= &followparent_recalc,
 };
 
+static const struct clksel_rate div_1_0_rates[] = {
+{ .div = 1, .v

[PATCH 5/5] ARM: OMAP: For all OMAP devices use clock framework to set dmtimer clock source

Jon Hunter — 2012-05-22T20:17:56

From: Jon Hunter <jon-hunter< at >ti.com>

OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's parent. Now OMAP1
can use the clock framework to set the parent clock, remove the architecture
specific functions and use a common function to set the parent clock for all
OMAP devices. This common function is based upon the OMAP2+
omap2_dm_timer_set_src() as this was using the clock framework.

Signed-off-by: Jon Hunter <jon-hunter< at >ti.com>
---
 arch/arm/mach-omap1/timer.c               |   15 +------
 arch/arm/mach-omap2/timer.c               |   61 -----------------------------
 arch/arm/plat-omap/dmtimer.c              |   43 +++++++++++++++++++-
 arch/arm/plat-omap/include/plat/dmtimer.h |    1 -
 4 files changed, 43 insertions(+), 77 deletions(-)

diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 64c65bc..6ef4f6d 100644
--- a/ar

[PATCH 3/5] ARM: OMAP2+: Simplify dmtimer clock aliases

Jon Hunter — 2012-05-22T20:17:42

From: Jon Hunter <jon-hunter< at >ti.com>

The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a "con-id" string to search for the appropriate functional clock.

Currently, we define a clock alias for each functional clock source each timer
supports. Some functional clock sources are common to all of the timers on a
device and so for these clock sources we can use a single alias with a unique
con-id string.

The possible functional clock sources for an OMAP device are a 32kHz clock,
a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
reduces code, speeds-up searches and clock initialisation time.

Signed-off-by: Jon Hunter <jon-hunter< at >ti.com>
---
 arch/arm/mach-omap2/clock2420_data.c |   39 +++-------------------------------
 arch/arm/mach-oma

[PATCH 2/5] ARM: OMAP2+: Remove omap2_clk_set_parent function

Jon Hunter — 2012-05-22T20:17:34

From: Jon Hunter <jon-hunter< at >ti.com>

The function omap2_clk_set_parent is just a wrapper for the
omap_clksel_set_parent() function. Now we have moved the
omap_clksel_set_parent() function into the plat-omap directory for all OMAP
devices to use, we should just use this function directly and we can eliminate
the OMAP2 function.

Signed-off-by: Jon Hunter <jon-hunter< at >ti.com>
---
 arch/arm/mach-omap2/clock.c      |   13 +------------
 arch/arm/plat-omap/clkt_clksel.c |    3 +++
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 2049cb2..b17d539 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
< at >< at > -385,17 +385,6 < at >< at > int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
 return ret;
 }
 
-int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
-{
-if (!clk->clksel)
-return -EINVAL;
-
-if (clk->parent == new_parent)
-return 0;
-
-return omap_clksel_set_parent(clk, new_parent);
-}
-
 /* OMA

[PATCH 0/5] ARM: OMAP: Fix OMAP1 dmtimer support

Jon Hunter — 2012-05-22T20:17:09

From: Jon Hunter <jon-hunter< at >ti.com>

OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the
omap_dm_timer_request() function fails to allocate a dmtimer because the call
to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply
because the clock data for the OMAP1 dmtimers is not present.

Although we can simply fix the OMAP1 dmtimers by adding the clock data for the
dmtimers, this is simply the tip of the iceberg. The OMAP1 devices do not
currently support clk_set_parent to dynamically change the clock source. So if
we just add the clock data for the dmtimers, when the dmtimer clock source is
changed by the existing omap1_dm_timer_set_src() function, the clock framework
will not be updated to reflect the current parent clock.

This patch set addresses these issues by ...
1. Making the code to set a parent clock common between OMAP1 and OMAP2+
2. Adds the OMAP1 dmtimer clock data
3. Removes architecture specific code to set the dmtimer clock source and adds
   a comm

[PATCH 1/2] ARM: pgtable: add pgprot_writethrough() macro

Siarhei Siamashka — 2012-05-22T19:54:03

Needed for remapping pages with write-through cacheable
attribute. May be useful for framebuffers.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka< at >gmail.com>
---
 arch/arm/include/asm/pgtable.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index f66626d..04297fa 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
< at >< at > -103,6 +103,9 < at >< at > extern pgprot_tpgprot_kernel;
 #define pgprot_stronglyordered(prot) \
 __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
 
+#define pgprot_writethrough(prot) \
+__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_WRITETHROUGH)
+
 #ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
 #define pgprot_dmacoherent(prot) \
 __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE | L_PTE_XN)

[PATCH 2/2] OMAPDSS: Optionally enable write-through cache for the framebuffer

Siarhei Siamashka — 2012-05-22T19:54:04

Write-through cached framebuffer eliminates the need for using shadow
framebuffer in xf86-video-fbdev DDX. At the very least this reduces
memory footprint, but the performance is also the same or better
when moving windows or scrolling on ARM11 and Cortex-A8 hardware.

Benchmark with xf86-video-fbdev on IGEPv2 board (TI DM3730, 1GHz),
1280x1024 screen resolution and 32bpp desktop color depth:

$ x11perf -scroll500 -copywinwin500 -copypixpix500 \
          -copypixwin500 -copywinpix500

[PATCH 0/2] OMAPDSS: write-through caching support for omapfb

Siarhei Siamashka — 2012-05-22T19:54:02

This is a very simple few-liner patchset, which allows to optionally
enable write-through caching for OMAP DSS framebuffer. The problem with
the current writecombine cacheability attribute is that it only speeds
up writes. Uncached reads are slow, even though the use of NEON mitigates
this problem a bit.

Traditionally, xf86-video-fbdev DDX is using shadow framebuffer in the
system memory. Which contains a copy of the framebuffer data for the
purpose of providing fast read access to it when needed. Framebuffer
read access is required not so often, but it still gets used for
scrolling and moving windows around in Xorg server. And the users
perceive their linux desktop as rather sluggish when these operations
are not fast enough.

In the case of ARM hardware, framebuffer is typically physically
located in the main memory. And the processors still support
write-through cacheability attribute. According to ARM ARM, the writes
done to write-through cached memory inside the level of cache are
visible to all observ

Re: [PATCH 0/3] GPMC NAND isr using standard API

Tony Lindgren — 2012-05-22T16:44:15

* Mohammed, Afzal <afzal< at >ti.com> [120522 00:05]:

I suggest you guys do your own merge of the two trees until -rc1
is out, then start using -rc1 as the base like Artem suggested.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc

Tony Lindgren — 2012-05-22T16:42:15

* Paul Walmsley <paul< at >pwsan.com> [120521 23:51]:

Also something to note here is that generating dynamic timings from the
fixed GPMC register values won't work for other frequencies.

As far as I remember, the main problem trying to convert fixed value
GPMC timings into dynamic timings is the fact that some GPMC values
calculated depend on clock cycles, while other values depend on time.

So the cycle values remain unknown trying to upsample from fixed timings.
 

Unfortunately for many of the older boards these values will probably
remain unknown.

So the better approach here is to just disable frequency scaling
for these cases. Otherwise we'll be breaking old boards with smsc911x
where the timings for the FPGA controlling smsc911x are unknown.

If we somehow manage to get those values without breaking support for
these boards, then yes I agree we should deprecate hardcoded and
bootloader values.
 

I'm fine with that assuming we somehow first have the values for the
most commonly used boards for smsc911x.

Re: [PATCH 3/4] ARM: OMAP: Make FS USB omap1 only

Tony Lindgren — 2012-05-22T16:07:25

* Felipe Balbi <balbi< at >ti.com> [120522 00:14]:

First one I can merge as a fix, patches 2 and 3 for v3.6, then
patch 4 up to you, I suggest v3.6.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] USB: Remove omap2 support from omap_udc.c

Tony Lindgren — 2012-05-22T16:06:09

* Felipe Balbi <balbi< at >ti.com> [120522 00:15]:

Yes you can take this one.

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] ARM: OMAP2+: Fix external clock support for dmtimers

Cousson, Benoit — 2012-05-22T15:55:53

...


Yeah, I don't know but I guess this is probably some OMAP1 legacy stuff...

Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] ARM: OMAP2+: Fix external clock support for dmtimers

Jon Hunter — 2012-05-22T15:04:23

Hi Benoit,

On 05/21/2012 11:58 AM, Cousson, Benoit wrote:

Ok, understood.


Ok, I can do this and did think about it, but then wondered why it had
been done this way in the first place? However, I prefer this approach
too as it simplifies the code :-)

So I modify how this is handled.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html