Hi Randy,
Thanks for your comments !
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap wrote:
>> +hardware accelerators, and therefore are often used to offload cpu-intensive
>
> prefer: CPU-
> throughout.
Isn't that changing the meaning a b
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Reported-By:Nishanth Menon
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |9 -
1 files changed, 4 insertions(+), 5
On Tue, 2011-06-28 at 09:19 -0700, Archit Taneja wrote:
> Hi,
>
> On Monday 27 June 2011 10:31 AM, Dima Zavin wrote:
> > There's no guarantee that the error handler worker thread
> > will run while the dispc clocks are on. Explicitly enable/disable
> > them.
>
> I agree with this.
Yes, I think t
Use generic gpio call to check the validity of the gpio. Note that
this includes gpio 0 also which was missing before.
Signed-off-by: Silesh C V
---
arch/arm/mach-omap2/hsmmc.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/m
Without this the HSMMC driver takes GPIO 0 to be the card detect gpio
and requests/configures it. This will give rise to issues when another
driver needs to use GPIO 0. On 4430SDP, the card detection is through
TWL 6030.
Signed-off-by: Silesh C V
---
Changes for v2 :
- Made it a series to
Hi Igor,
On Tue, Jun 28, 2011 at 10:50 PM, Igor Grinberg wrote:
> Hi Silesh,
>
>
> IMHO, you should not separate the patches
> (this one and OMAP: 4430SDP: Register the card detect GPIO properly),
> because the 4430sdp fix should come before or together with this patch,
> otherwise 4430sdp will b
On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross wrote:
>> I don't think it affects bogomips - loops_per_jiffy can still be
>> calibrated and updated by cpufreq, udelay just wont use them.
>
> No, you can't avoid it. __delay(
On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross wrote:
> I don't think it affects bogomips - loops_per_jiffy can still be
> calibrated and updated by cpufreq, udelay just wont use them.
No, you can't avoid it. __delay(), udelay(), and the global
loops_per_jiffy are all linked together - for
On Tue, 21 Jun 2011 10:18:33 +0300 Ohad Ben-Cohen wrote:
> Add a virtio-based IPC bus, which enables kernel users to communicate
> with remote processors over shared memory using a simple messaging
> protocol.
>
> Assign a local address for every local endpoint that is created,
> and bind it to t
On Tue, Jun 28, 2011 at 4:17 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 28, 2011 at 03:58:57PM -0700, Colin Cross wrote:
>> On Tue, Jun 28, 2011 at 3:55 PM, Russell King - ARM Linux
>> wrote:
>> > On Tue, Jun 28, 2011 at 03:29:57PM -0700, Colin Cross wrote:
>> >> Can't this rewrite the loo
+Rajendra
Balaji T K writes:
> add runtime pm support to HSMMC host controller
> Use runtime pm API to enable/disable HSMMC clock
> Use runtime autosuspend APIs to enable auto suspend delay
>
> Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
>
> Signed-off-by: Balaji
On Tue, Jun 28, 2011 at 03:58:57PM -0700, Colin Cross wrote:
> On Tue, Jun 28, 2011 at 3:55 PM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 28, 2011 at 03:29:57PM -0700, Colin Cross wrote:
> >> Can't this rewrite the loops_per_jiffy for the other CPU while it is
> >> in a udelay? If it has
On 6/28/2011 4:03 PM, Russell King - ARM Linux wrote:
On Tue, Jun 28, 2011 at 03:45:22PM -0700, Santosh Shilimkar wrote:
The udelay code doesn't use the per-cpu lpj variable. It uses the global
lpj. Secondly the calibration of no. of loops to be done is
precalculateed so overwrite shouldn't impa
On 6/28/2011 4:00 PM, Santosh Shilimkar wrote:
On 6/28/2011 3:53 PM, Colin Cross wrote:
On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
mailto:santosh.shilim...@ti.com>> wrote:
[]
Can't this rewrite the loops_per_jiffy for the other CPU while it is
in a udelay? If it has already calcu
On Tue, Jun 28, 2011 at 03:45:22PM -0700, Santosh Shilimkar wrote:
> The udelay code doesn't use the per-cpu lpj variable. It uses the global
> lpj. Secondly the calibration of no. of loops to be done is
> precalculateed so overwrite shouldn't impact the scenario you mentioned.
>
> Though it has an
On 6/28/2011 3:53 PM, Colin Cross wrote:
On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
mailto:santosh.shilim...@ti.com>> wrote:
[]
Can't this rewrite the loops_per_jiffy for the other CPU while it is
in a udelay? If it has already calculated the number of loops
On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely wrote:
> It's not the device_for_each_child() that you're 'putting' back from
> here. Its the original kref initialization when the device was
> created.
device_unregister() is already calling put_device(), doesn't that deal
with the original kref in
On Tue, Jun 28, 2011 at 3:55 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 28, 2011 at 03:29:57PM -0700, Colin Cross wrote:
>> Can't this rewrite the loops_per_jiffy for the other CPU while it is
>> in a udelay? If it has already calculated the number of loops
>> necessary, and the CPU freque
On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
wrote:
>
> On 6/28/2011 3:29 PM, Colin Cross wrote:
>>
>>
>>
>> On Fri, Jun 24, 2011 at 6:53 AM, Sanjeev Premi wrote:
>>>
>
>>> +#ifdef CONFIG_SMP
>>> + /* Adjust jiffies before transition */
>>> + for_each_cpu(i, policy->cpus) {
>
On Tue, Jun 28, 2011 at 03:29:57PM -0700, Colin Cross wrote:
> Can't this rewrite the loops_per_jiffy for the other CPU while it is
> in a udelay? If it has already calculated the number of loops
> necessary, and the CPU frequency increases, it could end up returning
> too early from udelay.
udel
On Tue, Jun 28, 2011 at 4:46 PM, Ohad Ben-Cohen wrote:
> Hi Grant,
>
> On Tue, Jun 28, 2011 at 1:21 AM, Grant Likely
> wrote:
>>> +static int rpmsg_remove_device(struct device *dev, void *data)
>>> +{
>>> + struct rpmsg_channel *rpdev = to_rpmsg_channel(dev);
>>> +
>>> + device_unregiste
Hi Grant,
On Tue, Jun 28, 2011 at 1:21 AM, Grant Likely wrote:
> Nice patch. I'm quite thrilled to see this implemented. Some
> comments below, but otherwise I think it looks pretty good.
Thanks !
>> +source "drivers/virtio/Kconfig"
>
> What happens when kvm and rpmsg both get enabled on the
On 6/28/2011 3:29 PM, Colin Cross wrote:
On Fri, Jun 24, 2011 at 6:53 AM, Sanjeev Premi wrote:
+#ifdef CONFIG_SMP
+ /* Adjust jiffies before transition */
+ for_each_cpu(i, policy->cpus) {
+ unsigned long lpj = per_cpu(cpu_data, i).loops_per_jiffy;
+
+
On Fri, Jun 24, 2011 at 6:53 AM, Sanjeev Premi wrote:
>
> Currently, loops_per_jiffy is being calculated twice for
> non-SMP processors.
> - Before calling cpufreq_notify_transition()
> - From within cpufreq_notify_transition()
>
> Double adjustment leads to incorrect value being assigned to
>
On 6/29/2011 12:03 AM, Nayak, Rajendra wrote:
On 6/28/2011 6:05 AM, Cousson, Benoit wrote:
Hi Kevin,
On 6/28/2011 2:11 AM, Hilman, Kevin wrote:
Benoit Coussonwrites:
From: Rajendra Nayak
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clk
On 6/28/2011 6:05 AM, Cousson, Benoit wrote:
Hi Kevin,
On 6/28/2011 2:11 AM, Hilman, Kevin wrote:
Benoit Cousson writes:
From: Rajendra Nayak
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Config
On Tue, Jun 28, 2011 at 2:29 AM, Russell King - ARM Linux
wrote:
> (Don't have the original message to reply to...)
Sorry about that.
My recent emails to linux-arm-kernel were bounced with a "Message has
a suspicious header" reason. not sure what am I doing wrong..
> Do we really want to end up
On 6/28/2011 2:33 PM, Cousson, Benoit wrote:
On 6/28/2011 7:16 PM, Hilman, Kevin wrote:
Benoit Cousson writes:
From: Rajendra Nayak
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Configure desired m
Hi Grant,
Thanks a lot for the exhaustive review and comments !
On Mon, Jun 27, 2011 at 11:49 PM, Grant Likely
wrote:
>> + my_rproc = rproc_get("ipu");
>
> I tend to be suspicious of apis whose primary interface is by-name
> lookup. It works fine when the system is small, but it can get
> u
On 6/28/2011 7:16 PM, Hilman, Kevin wrote:
Benoit Cousson writes:
From: Rajendra Nayak
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Configure desired module mode to "enable" or "auto"
-4- Wait for
"T Krishnamoorthy, Balaji" writes:
> On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley wrote:
>> (cc'ing Adrian also)
>>
>> Hi Balaji
>>
>> On Wed, 22 Jun 2011, Balaji T K wrote:
>>
>>> Use runtime autosuspend APIs to enable auto suspend delay
>>
>> Does this really need to use runtime autosuspend
On 6/28/2011 8:21 PM, Todd Poynor wrote:
On Tue, Jun 28, 2011 at 04:10:55PM +0200, Cousson, Benoit wrote:
On 6/27/2011 8:56 PM, Todd Poynor wrote:
On Mon, Jun 27, 2011 at 06:33:06PM +0200, Benoit Cousson wrote:
...
+ r = clk_get_sys(dev_name(&od->pdev.dev), clk_alias);
+ if (!IS_ER
Hello Arve,
On Fri, 24 Jun 2011, Arve Hjønnevåg wrote:
> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley wrote:
> >
> > As I understand it, in the original Android implementation, the hardware
> > that they were using didn't have fine-grained power management. So
> > system-wide suspend made mo
On Mon, May 16, 2011 at 2:11 AM, Hiroshi DOYU wrote:
> From: "ext Anna, Suman"
> Subject: [PATCH] omap: iommu: fix pte attributes for super section
> Date: Tue, 10 May 2011 10:25:17 -0700
>
>> From 5796d8d8a0ea5aee342b78ca6ead229971cff6c5 Mon Sep 17 00:00:00 2001
>> From: Suman Anna
>> Date: Wed
On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
> On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley wrote:
> >
> > On Wed, 22 Jun 2011, Balaji T K wrote:
> >
> >> Use runtime autosuspend APIs to enable auto suspend delay
> >
> > Does this really need to use runtime autosuspend? Seems to me th
On Tue, Jun 28, 2011 at 04:10:55PM +0200, Cousson, Benoit wrote:
> On 6/27/2011 8:56 PM, Todd Poynor wrote:
> >On Mon, Jun 27, 2011 at 06:33:06PM +0200, Benoit Cousson wrote:
> >...
> >>+ r = clk_get_sys(dev_name(&od->pdev.dev), clk_alias);
> >>+ if (!IS_ERR(r)) {
> >>+ pr_warning("om
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley wrote:
> (cc'ing Adrian also)
>
> Hi Balaji
>
> On Wed, 22 Jun 2011, Balaji T K wrote:
>
>> Use runtime autosuspend APIs to enable auto suspend delay
>
> Does this really need to use runtime autosuspend? Seems to me that since
> PM runtime is just c
After runtime conversion to handle clk,
iclk node is not used
However fclk node is still used to get clock rate.
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs to enable auto suspend delay
Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
Signed-off-by: Balaji T K
---
changes since v1
Removed pm_runtim
lazy_disable framework in OMAP HSMMC manages multiple low power states
and Card is powered off after inactivity time of 8 seconds.
Based on previous discussion on the list, card power (regulator)
handling (when to power OFF/ON) should ideally be handled by core layer.
Remove usage of lazy disable t
Removing the custom state machine - lazy disable framework in omap_hsmmc
to make way for runtime pm to handle host controller
power states.
This allows mmc_host_enable/mmc_host_disable to be replaced by
runtime get_sync and put_sync at host controller driver.
Enable runtime PM in omap_hsmmc
Rebas
(cc'ing Adrian also)
Hi Balaji
On Wed, 22 Jun 2011, Balaji T K wrote:
> Use runtime autosuspend APIs to enable auto suspend delay
Does this really need to use runtime autosuspend? Seems to me that since
PM runtime is just controlling the MMC IP blocks and not the regulators in
this instance,
Benoit Cousson writes:
> From: Rajendra Nayak
>
> On OMAP4, the PRCM recommended sequence for enabling
> a module after power-on-reset is:
> -1- Force clkdm to SW_WKUP
> -2- Enabling the clocks
> -3- Configure desired module mode to "enable" or "auto"
> -4- Wait for the desired module idle statu
Hi,
On Monday 27 June 2011 10:31 AM, Dima Zavin wrote:
There's no guarantee that the error handler worker thread
will run while the dispc clocks are on. Explicitly enable/disable
them.
I agree with this.
Tomi,
We could get prevent scheduling of the error worker by registering
omap_dispc_irq
"Koyamangalath, Abhilash" writes:
> powerdomains3xxx_data.c defines core_3xxx_pre_es3_1_pwrdm and
> core_3xxx_es3_1_pwrdm to take care of differences in "core_pwrdm"
> implementations across revisions.
> However,_pwrdm_lookup("core_pwrdm") always matches the first definition for
> 3630 ES 1.1 and
"Cousson, Benoit" writes:
> On 6/28/2011 2:19 AM, Hilman, Kevin wrote:
>> Benoit Cousson writes:
>>
>>> Since the timer is still not pm_runtime adapted, it is still
>>> using directly the physical clock nodes at init time.
>>>
>>> Replace the clock node by the original one in the clock data
>>>
Axel Lin writes:
> The gpio-omap driver has been converted to use generic IRQ chip.
> Thus select GENERIC_IRQ_CHIP for TI OMAP1 to fix below build error.
>
> LD vmlinux
> drivers/built-in.o: In function `omap_mpuio_alloc_gc':
> drivers/gpio/gpio-omap.c:1087: undefined reference to `irq_all
On Tue, 2011-06-14 at 04:50 -0700, Tony Lindgren wrote:
> * Kevin Hilman [110607 16:58]:
> > OMAP1 needs this also since GPIO driver (common for all OMAPs) is
> > being converted to use generic IRQ chip.
> >
> > Signed-off-by: Kevin Hilman
>
> Maybe queue this together with your GPIO patches?
>
Hi Kevin,
On 6/28/2011 2:30 AM, Hilman, Kevin wrote:
Hi Benoit,
Benoit Cousson writes:
Here is the second part of the modulemode series.
The goal here is to do the cleanup on the clock nodes and PRCM macros
that are not needed anymore by the hwmod data.
Some macros are still needed because o
On 6/27/2011 8:56 PM, Todd Poynor wrote:
On Mon, Jun 27, 2011 at 06:33:06PM +0200, Benoit Cousson wrote:
...
+ r = clk_get_sys(dev_name(&od->pdev.dev), clk_alias);
+ if (!IS_ERR(r)) {
+ pr_warning("omap_device: %s: %s already exist\n",
+ dev_nam
Hi Silesh,
On 06/28/11 11:45, Silesh C V wrote:
> Use generic gpio call to check the validity of the gpio. Note that
> this includes gpio 0 also which was missing before.
>
> Signed-off-by: Silesh C V
> ---
> arch/arm/mach-omap2/hsmmc.c |7 +++
> 1 files changed, 3 insertions(+), 4 dele
Hi Carlos,
> > What about information about the supported transmission speeds?
> > Is it any way to obtain this information, so we can know the legal
> > values for speed in hsi_config?
>
> For TX speed sets the max tx speed the HSI should go. The controller
> driver will try to get as close as
Hi Kevin,
On 6/28/2011 2:11 AM, Hilman, Kevin wrote:
> Benoit Cousson writes:
>
>> From: Rajendra Nayak
>>
>> On OMAP4, the PRCM recommended sequence for enabling
>> a module after power-on-reset is:
>> -1- Force clkdm to SW_WKUP
>> -2- Enabling the clocks
>> -3- Configure desired module mode to
On Tue, Jun 28, 2011 at 2:15 PM, Silesh C V wrote:
> Use generic gpio call to check the validity of the gpio. Note that
> this includes gpio 0 also which was missing before.
>
> Signed-off-by: Silesh C V
> ---
> arch/arm/mach-omap2/hsmmc.c | 7 +++
> 1 files changed, 3 insertions(+), 4 de
On Tue, Jun 28, 2011 at 4:26 AM, Ohad Ben-Cohen wrote:
> On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark wrote:
>> 2. We added a special section (resource table) that is interpreted as part
>> of the loading process. The tool that generates our simple format just
>> recognizes a named section (".r
On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark wrote:
> 2. We added a special section (resource table) that is interpreted as part
> of the loading process. The tool that generates our simple format just
> recognizes a named section (".resource_table"), so perhaps that could be
> done with the PIL
Hello.
On 21.06.2011 11:18, Ohad Ben-Cohen wrote:
From: Mark Grosen
Add davinci remoteproc device for the da850's C674x dsp remote
processor, and support it on the da850-evm and omapl138-hawk boards.
Signed-off-by: Mark Grosen
Signed-off-by: Ohad Ben-Cohen
[...]
diff --git a/arch/arm/
Signed-off-by: Peter Ujfalusi
---
Hello Tony,
While rebasing my series on top of your devel-cleanup branch,
I found this compillation error.
You can pick it right away, or I can queue this within my series.
But I still waiting for Samuel's saying on the series, so it might
be faster if you just
powerdomains3xxx_data.c defines core_3xxx_pre_es3_1_pwrdm and
core_3xxx_es3_1_pwrdm to take care of differences in "core_pwrdm"
implementations across revisions.
However,_pwrdm_lookup("core_pwrdm") always matches the first definition for
3630 ES 1.1 and 1.2 which is incorrect. This patch fixes this
On 6/28/2011 2:17 AM, Hilman, Kevin wrote:
Benoit Cousson writes:
Since the MMC driver is not pm_runtime adapted, do not put
them in idle after boot.
It will allow the driver to work as expected until the migration
to pm_runtime.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Na
Hi Mark,
On Mon, Jun 27, 2011 at 23:50:25, Grosen, Mark wrote:
> > >>> +static inline int davinci_rproc_start(struct rproc *rproc, u64
> > >> bootaddr)
> > >>> +{
> > >>> + struct device *dev = rproc->dev;
> > >>> + struct davinci_rproc_pdata *pdata = dev->platform_data;
> > >>> +
On 6/28/2011 2:19 AM, Hilman, Kevin wrote:
> Benoit Cousson writes:
>
>> Since the timer is still not pm_runtime adapted, it is still
>> using directly the physical clock nodes at init time.
>>
>> Replace the clock node by the original one in the clock data
>> file.
>>
>> Keep the original name u
On Tue, 2011-06-28 at 11:14 +0200, Cousson, Benoit wrote:
> On 6/28/2011 10:29 AM, Valkeinen, Tomi wrote:
> > My current pm_runtime patch set removes the omapdss clock aliases from
> > arch/arm/mach-omap2/clock44xx_data.c, as the driver uses the opt-clock
> > names. Isn't that correct way?
>
> Ye
On 6/28/2011 10:29 AM, Valkeinen, Tomi wrote:
On Tue, 2011-06-28 at 10:14 +0200, Cousson, Benoit wrote:
On 6/28/2011 8:56 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
Hi Paul,
Here is the second part of the modulemode series.
The goal here is to do the c
The gpio-omap driver has been converted to use generic IRQ chip.
Thus select GENERIC_IRQ_CHIP for TI OMAP1 to fix below build error.
LD vmlinux
drivers/built-in.o: In function `omap_mpuio_alloc_gc':
drivers/gpio/gpio-omap.c:1087: undefined reference to `irq_alloc_generic_chip'
drivers/gpio/
Use generic gpio call to check the validity of the gpio. Note that
this includes gpio 0 also which was missing before.
Signed-off-by: Silesh C V
---
arch/arm/mach-omap2/hsmmc.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/m
On Tue, 2011-06-28 at 10:27 +0200, Cousson, Benoit wrote:
> On 6/28/2011 10:14 AM, Valkeinen, Tomi wrote:
> > On Tue, 2011-06-28 at 10:10 +0200, Cousson, Benoit wrote:
> >> Hi Tomi,
> >>
> >> On 6/28/2011 8:40 AM, Valkeinen, Tomi wrote:
> >>> On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
On Tue, 2011-06-28 at 10:14 +0200, Cousson, Benoit wrote:
> On 6/28/2011 8:56 AM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
> >> Hi Paul,
> >>
> >> Here is the second part of the modulemode series.
> >> The goal here is to do the cleanup on the clock nodes
On 6/28/2011 10:14 AM, Valkeinen, Tomi wrote:
On Tue, 2011-06-28 at 10:10 +0200, Cousson, Benoit wrote:
Hi Tomi,
On 6/28/2011 8:40 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
Previously, main_clk was a fake clock node that was accessing the
PRCM modulem
On Tue, 2011-06-28 at 10:10 +0200, Cousson, Benoit wrote:
> Hi Tomi,
>
> On 6/28/2011 8:40 AM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
> >> Previously, main_clk was a fake clock node that was accessing the
> >> PRCM modulemode register. Since the module
On 6/28/2011 8:56 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
Hi Paul,
Here is the second part of the modulemode series.
The goal here is to do the cleanup on the clock nodes and PRCM macros
that are not needed anymore by the hwmod data.
Some macros are s
Hi Tomi,
On 6/28/2011 8:40 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
Previously, main_clk was a fake clock node that was accessing the
PRCM modulemode register. Since the module mode is directly
controlled by the hwmod fmwk, these fake clock node are no
On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
> Hi Paul,
>
> Here is the second part of the modulemode series.
> The goal here is to do the cleanup on the clock nodes and PRCM macros
> that are not needed anymore by the hwmod data.
> Some macros are still needed because of clock data.
73 matches
Mail list logo
