* Oleg Matcovschi oleg.matcovs...@ti.com [120515 14:40]:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch()
Hi,
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of arch/arm/*omap*/
This series,
1. provides the ability for OMAP NAND driver to configure GPMC-NAND
registers by NAND
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |
GPMC platform initialization has been modified to fill NAND
platform data with GPMC NAND register details. As these
registers are accessible in NAND driver itself, configure
NAND in GPMC by itself.
Modified prefetch and ecc functions are logically same as
the corresponding exported symbols from
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in
gpmc initialization done by platform code now updates struct resource
with the address space alloted for nand. Use this interface to obtain
memory rather than relying on platform data field - phys_base.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |1
gpmc initialization for onenand done by platform code now provides
onenand address space as memory resource. Hence remove usage of
gpmc_cs_request in onenand driver and obtain memory details from
resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/onenand/omap2.c |
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related interrupts has been considered (which is the case
even without this
Now GPMC provides its client with interrupts that can be handled
using the standard interrupt API. Modify GPMC NAND setup to work
with it.
Also disable write protect in GPMC code, so that NAND driver can
be ignorant of GPMC configuration.
Signed-off-by: Afzal Mohammed af...@ti.com
---
GPMC platform initialization provides it's clients
with interrupts that can be used through struct
resource. Make use of it for irq mode functionality.
Also now write protect disable is done by GPMC,
hence remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 70
Commit 3b511201 (ARM: OMAP: rx51: Platform support for lis3lv02d accelerometer)
added support for lis3lv02d accelerometer.
The patch was still using OMAP_GPIO_IRQ which no longer exists.
Fix it by using gpio_to_irq().
Signed-off-by: Tony Lindgren t...@atomide.com
---
Here's this one fixed.
On Thu, May 31, 2012 at 11:02:06AM +0200, Yegor Yefremov wrote:
my best choice was 3.3-rc7 so far. With final 3.3 frame buffer made problems.
wl1271 was working like a charm. I have another PMIC, so I don't know if it
works well with tps65910.
I just took the master branch of
* Ohad Ben-Cohen o...@wizery.com [120513 06:19]:
Sparse found out that hwspinlocks_init() wasn't marked static,
and it should've been.
Looks like this already got fixed by Paul's commit 8c3d4534.
Regards,
Tony
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
On Mon, Jun 04, 2012 at 09:28:23AM +0200, Ladislav Michl wrote:
does USB work for you? I forward ported support for TechNexion's TAM-3517 on
Twister board to current master, but so far no luck with mass storage
support (patch for reference http://ladislav.michl.sweb.cz/tam3517.patch).
patch
On Friday 01 June 2012 07:07 PM, Paul Walmsley wrote:
On Fri, 1 Jun 2012, Rajendra Nayak wrote:
This RFC series is based of Mikes' latest clk-next. I will
rebase it once 3.5-rc1 is out and post with more testing thats
in progress. Meanwhile, the RFC is for me to get some early
feedback on the
Hi Jon,
On Saturday 02 June 2012 04:57 AM, Jon Hunter wrote:
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
Hi,
This RFC series is based of Mikes' latest clk-next. I will
rebase it once 3.5-rc1 is out and post with more testing thats
in progress. Meanwhile, the RFC is for me to
Hi Tony,
On Monday 04 June 2012 11:14 AM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [120601 05:12]:
@@ -359,6 +391,8 @@ const struct clk_hw_omap_ops clkhwops_wait = {
.find_idlest= omap2_clk_dflt_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};
On Fri, 2012-06-01 at 04:27 -0600, Paul Walmsley wrote:
On Fri, 1 Jun 2012, Menon, Nishanth wrote:
On Thu, May 31, 2012 at 8:28 AM, Tero Kristo t-kri...@ti.com wrote:
minor comment:
+void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
snip
+void pwrdm_clkdm_disable(struct powerdomain
* Kevin Hilman khil...@ti.com [120530 16:28]:
Tony,
Here's a couple PM related fixes for v3.5-rc, based on your cleanup
branch.
Thanks pulled into fixes and merged into linux-omap master for
a few days of testing.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe
* Kevin Hilman khil...@ti.com [120530 16:47]:
Tony,
These couple patches didn't make it for v3.5 because of some cross-tree
dependencies. All the dependencies are now merged (after Linus merged
arm-soc/next/pm), so here's the remaining patches.
Not sure if you want to get them in for
Hi Rajendra,
On 06/04/2012 03:52 AM, Rajendra Nayak wrote:
Hi Jon,
On Saturday 02 June 2012 04:57 AM, Jon Hunter wrote:
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
Hi,
This RFC series is based of Mikes' latest clk-next. I will
rebase it once 3.5-rc1 is out and post with
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
Moving to COMMON clk, plat/clock.c and plat/clock.h files will no
longer be used. Move whatever is useful for OMAP2+ for implementing
platform code into mach/clock.h.
plat/clock.c which has most of usecounting/locking infrastructure
On Monday 04 June 2012 07:21 PM, Jon Hunter wrote:
I was infact thinking of moving these files into mach-omap1/ since they
are now OMAP1 specific. Is your concern coming mainly from the clksel
structs that you will need to be shared across OMAP1 and OMAP2+?
Yes, especially if we plan to
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 Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X (1 0)
+#define RATE_IN_243X (1 1)
+#define RATE_IN_3430ES1(1 2) /* 3430ES1 rates only */
+#define RATE_IN_3430ES2PLUS(1 3) /* 3430 ES= 2 rates only */
+#define RATE_IN_36XX
On 06/04/2012 09:16 AM, Rajendra Nayak wrote:
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X(1 0)
+#define RATE_IN_243X(1 1)
+#define RATE_IN_3430ES1(1 2)/* 3430ES1 rates only */
+#define RATE_IN_3430ES2PLUS(1 3)/* 3430 ES= 2
Due to the lack of a generic clock API we'd had the 32kHz clock in the
regulator driver but this is definitely a Linux-specific thing and now
we have a clock API hopefully the code can be moved elsewhere. Try to
avoid getting DTs deployed relying on the 32kHz clock by removing it
from the
Menon, Nishanth n...@ti.com writes:
Regards,
Nishanth Menon
On Fri, Jun 1, 2012 at 4:03 PM, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
From: Wenbiao Wang ww...@ti.com
Voltage Processor state machine transition to disable need to
occur from IDLE state. When we
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct
In the plat/dmtimer.h there is a structure named clk declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by: 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 have 11 timers available because the 12th timer is
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is
During early boot, two timers are reserved by the kernel as system timers (for
clocksource and clockevents). These timers are marked as reserved and the
dmtimer driver is notified which timers have been reserved via the platform
data information.
For OMAP2+ devices the timers reserved may vary
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx
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.
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this flag is set the
For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform function, we can
OMAP1 uses an architecture specific function for setting the dmtimer clock
source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
device should also use the clock framework and hence we should not any
architecture specific functions.
For now move the OMAP2+ function for
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
On 06/04/2012 12:22 PM, Jon Hunter wrote:
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
On 06/04/2012 12:22 PM, Jon Hunter wrote:
For OMAP2+ devices, a function pointer that returns the number of times a
timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function.
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct
During early boot, one or two dmtimers are reserved by the kernel as system
timers (for clocksource and clockevents). These timers are marked as reserved
and the dmtimer driver is notified which timers have been reserved via the
platform data information.
For OMAP2+ devices the timers reserved
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 have 11 timers available because the 12th timer is
In the plat/dmtimer.h there is a structure named clk declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by: Jon Hunter
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx
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.
The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this flag is set the
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform function, we can
For OMAP1 devices, it is necessary to perform a manual reset of the timer.
Currently, this is indicating by setting the needs_manual_reset variable in
the platform data. Instead of using an extra variable to indicate this add a new
timer capabilities flag to indicate this and remove the
OMAP1 uses an architecture specific function for setting the dmtimer clock
source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
device should also use the clock framework and hence we should not any
architecture specific functions.
For now move the OMAP2+ function for
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
On 06/04/2012 02:41 PM, Jon Hunter wrote:
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
(Sorry your mail was lost due to mail outage)
On 05/30/12 05:16, Ohad Ben-Cohen wrote:
On Wed, May 30, 2012 at 11:36 AM, Stephen Boyd sb...@codeaurora.org wrote:
One complaint I've gotten is that the error messages are essentially
useless now. I believe there are some ongoing discussions on
On 05/30/12 05:38, Ohad Ben-Cohen wrote:
On Wed, May 30, 2012 at 11:42 AM, Stephen Boyd sb...@codeaurora.org wrote:
- /* the rproc will only be released after its refcount drops to zero */
- kref_put(rproc-refcount, rproc_release);
+ /* unroll rproc_alloc. TODO: we may want to let
On 05/24/12 13:11, Ohad Ben-Cohen wrote:
Would it suffice to
have some new rproc-state like RPROC_UNKNOWN that we set in
rproc_register() before adding it to the list of rprocs? If we find the
firmware then we set it to RPROC_READY or RPROC_REGISTERED? Then we
wait_for_completion() and check
Hi Will,
On 06/02/2012 11:42 AM, Will Deacon wrote:
Hi Jon, Kevin,
I've been between timezones, so sorry for the slow response.
No problem. I was expecting you guys in the UK to be out of office for the
next couple days :-)
On Fri, Jun 01, 2012 at 03:42:56PM +0100, Jon Hunter wrote:
On
On Tue, 15 May 2012 14:35:08 Oleg Matcovschi wrote:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
The data is autogenerated using the OMAP autogeneration scripts (python
scripts). Thanks to Mike Turquette for the initial efforts in updating
the script which was later updated by me.
All data is added into a new cclock44xx_data.c
Hi Xiao, Tomi, Jarkko,
On 05/30/2012 11:27 PM, Xiao Jiang wrote:
Ricardo Neri wrote:
+Tomi
Hi Xiao,
On 05/30/2012 02:14 AM, Xiao Jiang wrote:
Hello,
After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got some
err infos with latest
Linus's tree, does somebody also has the same
Ricardo Neri wrote:
Hi Xiao, Tomi, Jarkko,
On 05/30/2012 11:27 PM, Xiao Jiang wrote:
Ricardo Neri wrote:
+Tomi
Hi Xiao,
On 05/30/2012 02:14 AM, Xiao Jiang wrote:
Hello,
After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got
some
err infos with latest
Linus's tree, does
Hi Jon,
+
+static const struct clksel_rate div_1_0_rates[] = {
+ { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel_rate div_1_1_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const
Hi Jon,
On 06/04/2012 09:16 AM, Rajendra Nayak wrote:
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X(1 0)
+#define RATE_IN_243X(1 1)
+#define RATE_IN_3430ES1(1 2)/* 3430ES1 rates only */
+#define RATE_IN_3430ES2PLUS(1 3)/* 3430
68 matches
Mail list logo
