On Tuesday 07 June 2011 17:45:35 Tony Lindgren wrote:
> > +#define TWL_COMMON_PDATA_BCI (1 << 1)
> > +#define TWL_COMMON_PDATA_MADC (1 << 2)
> > +#define TWL_COMMON_PDATA_CODEC (1 << 3)
>
> This is looking good, thanks for cleaning up the twl bloat in
> board
iovmm is erroneously using sg_dma_len with unmapped (DMA API-wise)
SG entries, and will break if CONFIG_NEED_SG_DMA_LENGTH is enabled.
Fix that by using sg->length instead.
Reported-by: Russell King
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3
On 6/8/2011 2:27 AM, Todd Poynor wrote:
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.
Signed-off-by: Todd Poynor
Looks g
On Tue, Jun 7, 2011 at 20:41, Menon, Nishanth wrote:
> On Tue, Jun 7, 2011 at 20:12, Colin Cross wrote:
>>> Bootloaders should in theory setup a frequency which is enabled in
>>> OPP table. However, there can be mismatches, and we should try
>>> both going lower in addition to the going higher to
On Tue, Jun 7, 2011 at 20:12, Colin Cross wrote:
>> Bootloaders should in theory setup a frequency which is enabled in
>> OPP table. However, there can be mismatches, and we should try
>> both going lower in addition to the going higher to find
>> a match if bootloader boots up at a OPP than the k
> Bootloaders should in theory setup a frequency which is enabled in
> OPP table. However, there can be mismatches, and we should try
> both going lower in addition to the going higher to find
> a match if bootloader boots up at a OPP than the kernel thinks it
> should be allowed. We also sequence
Bootloaders should in theory setup a frequency which is enabled in
OPP table. However, there can be mismatches, and we should try
both going lower in addition to the going higher to find
a match if bootloader boots up at a OPP than the kernel thinks it
should be allowed. We also sequence the freque
On Tue, Jun 7, 2011 at 16:49, Kevin Hilman wrote:
> Nishanth Menon writes:
>
>> Since we do module_init, cpufreq initializes before power late_init
>> where many of the required data structures are registered.
>
> What exactly are the dependencies here? The only thing I see is the
> dependency o
Grant,
Here's a small set of OMAP GPIO fixes for v3.0-rc.
Thanks,
Kevin
The following changes since commit 59c5f46fbe01a00eedf54a23789634438bb80603:
Linux 3.0-rc2 (2011-06-06 18:06:33 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/li
When runtime PM is disabled, device clocks need to be enabled on
device add and disabled on device remove. This currently is not
happening because in the !PM_RUNTIME case, no notifiers are registered
for OMAP1 devices.
Fix this by ensuring notifiers are registered, even in the !PM_RUNTIME case.
OMAP1 needs this also since GPIO driver (common for all OMAPs) is
being converted to use generic IRQ chip.
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
i
Janusz Krzysztofik writes:
> On Tue 07 Jun 2011 at 23:17:49 Kevin Hilman wrote:
>> Janusz Krzysztofik writes:
>> > ... Or should
>> > arch/arm/mach-omap1/pm_bus.c be always built in and
>> > pm_runtime_clk_add_notifier() called from there in order to enable
>> > clocks on device initialization e
"Rafael J. Wysocki" writes:
> On Tuesday, June 07, 2011, Kevin Hilman wrote:
>> "Rafael J. Wysocki" writes:
>>
>> [..]
>>
>> > While it is tempting to try to get away with only two PM callbacks per
>> > driver instead of four (or even more), it generally is not doable, simply
>> > because driv
On Tue 07 Jun 2011 at 23:24:53 Janusz Krzysztofik wrote:
> On Tue 07 Jun 2011 at 21:29:25 Rafael J. Wysocki wrote:
> > OK, below is an "official" version. Can you please double check if
> > it fixes the problem for you?
>
> Hi,
> I've tested it successfully, but only the CONFIG_PM_RUNTIME=y case,
> -Original Message-
> From: Fernandes, Joel A
> Sent: Tuesday, June 07, 2011 4:55 PM
> To: linux-omap@vger.kernel.org
> Cc: Kridner, Jason; Kooi, Koen; beaglebo...@googlegroups.com
> Subject: [PATCH v7] OMAP3: beagle: add support for beagleboard xM
> revision C
>
> OMAP3: beagle: add supp
On Tue 07 Jun 2011 at 23:17:49 Kevin Hilman wrote:
> Janusz Krzysztofik writes:
> > ... Or should
> > arch/arm/mach-omap1/pm_bus.c be always built in and
> > pm_runtime_clk_add_notifier() called from there in order to enable
> > clocks on device initialization even if CONFIG_PM_RUNTIME is not
> >
Nishanth Menon writes:
> Since we do module_init, cpufreq initializes before power late_init
> where many of the required data structures are registered.
What exactly are the dependencies here? The only thing I see is the
dependency on omap2_get_mpuss_device(), and those devices should be
crea
On Tuesday, June 07, 2011, Janusz Krzysztofik wrote:
> On Tue 07 Jun 2011 at 21:29:25 Rafael J. Wysocki wrote:
> >
> > OK, below is an "official" version. Can you please double check if
> > it fixes the problem for you?
>
> Hi,
> I've tested it successfully, but only the CONFIG_PM_RUNTIME=y case
On Tuesday, June 07, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> [..]
>
> > While it is tempting to try to get away with only two PM callbacks per
> > driver instead of four (or even more), it generally is not doable, simply
> > because driver callbacks are not executed directly
On Tue 07 Jun 2011 at 21:29:25 Rafael J. Wysocki wrote:
>
> OK, below is an "official" version. Can you please double check if
> it fixes the problem for you?
Hi,
I've tested it successfully, but only the CONFIG_PM_RUNTIME=y case, not
the other because of still another McBSP issue, I believe, d
Janusz Krzysztofik writes:
> Hi,
>
> While solving this problem:
> http://www.spinics.net/lists/linux-omap/msg52011.html,
> I found that since commit e95496d4acadd0b72c4947be61e8d44700fdaae7,
> "OMAP: McBSP: Add pm runtime support", McBSP ports, or at least McBSP1
> on my Amstrad Delta, no long
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.
Signed-off-by: Todd Poynor
---
arch/arm/mach-omap2/omap2plus-cpufreq.c |
OMAP3: beagle: add support for beagleboard xM revision C
The USB enable GPIO has been in beagleboard xM revision C.
The USER button has been moved since beagleboard xM.
Also, board specific initialization has been moved to beagle_config struct
and initialized in omap3_beagle_init_rev. Default
On Monday, June 06, 2011, Janusz Krzysztofik wrote:
> On Mon 06 Jun 2011 at 19:47:36 Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Sunday, June 05, 2011, Janusz Krzysztofik wrote:
> > > In its current form, pm_runtime_clk_notify() iterates through sub-
> > > strings of pm_clk_notifier_block.con_ids[
Hi,
While solving this problem:
http://www.spinics.net/lists/linux-omap/msg52011.html,
I found that since commit e95496d4acadd0b72c4947be61e8d44700fdaae7,
"OMAP: McBSP: Add pm runtime support", McBSP ports, or at least McBSP1
on my Amstrad Delta, no longer work when CONFIG_PM_RUNTIME is not set.
Nishanth Menon writes:
> Probably should be squashed to:
> "OMAP2+: cpufreq: fix freq_table leak"
>
> Looks like I've been lazy and added up a useless else case!
>
> Signed-off-by: Nishanth Menon
Thanks, squashed.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" i
Current usage of runtime PM is not quite correct. The actual
idle/unidle of the I2C hardware should not happen until the runtime PM
callbacks are called. Therefore, change omap_i2c_[un]idle() functions
to only be called from the runtime PM callbacks (when usage count
transitions to/from zero.)
A
Current system PM methods for this driver race with the runtime PM
methods when an i2c xfer is in progress when the system suspend path
is excuted.
These callbacks are only needed when runtime PM is disabled from
userspace, so for now we accept that this device will not hit
retention, even in susp
A pointer to the struct device associated with the i2c device is
already kept in the struct omap_i2c_dev, so use omap_i2c_device to
find the pointer to struct device.
Signed-off-by: Kevin Hilman
---
drivers/i2c/busses/i2c-omap.c | 22 +++---
1 files changed, 7 insertions(+), 15
Here's a small series of PM-related cleanups for the OMAP I2C driver.
Series applies on top of the other cleanup series from Andy Green:
[PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
and is available from git here:
git://git.kernel.org/pub/scm/linux/kernel/git/khil
On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
On 6/7/2011 8:52 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
Before doing that, could you maybe just try something to make OMAP4
looks a little bit mo
On Tue, Jun 7, 2011 at 10:04 AM, Kevin Hilman wrote:
> Grant Likely writes:
>
>> On Mon, Jun 6, 2011 at 5:18 PM, Kevin Hilman wrote:
>>> Hi Colin,
>>>
>>> Colin Cross writes:
>>>
Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
causing only the last bit set to take eff
Grant Likely writes:
> On Mon, Jun 6, 2011 at 5:18 PM, Kevin Hilman wrote:
>> Hi Colin,
>>
>> Colin Cross writes:
>>
>>> Setting the IRQWAKEN bit was overwriting previous IRQWAKEN bits,
>>> causing only the last bit set to take effect, resulting in lost
>>> wakeups when the GPIO controller is i
On Tue, May 17, 2011 at 11:39:13AM +0300, Carlos Chinea wrote:
> We are still committed to these patches. We are aiming to release a new
> version in 3 weeks max, sooner if we can.
>
> I am very sorry for the delay and I agree that starting to have several
> out-of-tree drivers is not acceptable.
* Peter Ujfalusi [110607 17:14]:
> Reduce the amount of duplicated code by moving the common
> configuration for twl4030/5030/tpsxx to the pmic-common file.
> Use the omap3_pmic_config function from board files to
> properly configure the PMIC with the common fields.
...
> --- a/arch/arm/mach-oma
Pass twl4030_codec_data instead of the twl4030_audio_data
for the ASoC codec driver.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl6040-core.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index 5abdcb2..e8
From: Misael Lopez Cruz
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The audio modules are c
Allign the platform data names for twl4030 audio submodule:
twl4030_audio_data: for the core MFD driver
twl4030_codec_data: for ASoC codec driver
twl4030_vibra_data: for the input/ForceFeedback driver
To avoid breakage, change all depending drivers, files
to use the new types.
Signed-off-by: Pete
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi
CC: Misael Lopez Cruz
---
drivers/input/misc/Kconfig |2 +-
drivers/input/misc/twl4030-vibra.c | 10 +-
drivers/mfd/Kc
In preparation of renaming the driver from twl4030-codec
to twl4030-audio, first do some clean ups in the driver,
which does not cause any problems outside.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-codec.c | 135 ++-
1 files changed, 68 inser
Reduce the amount of duplicated code by moving the common
configuration for twl4030/5030/tpsxx to the pmic-common file.
Use the omap3_pmic_config function from board files to
properly configure the PMIC with the common fields.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-3430sdp.c
Reduce the amount of duplicated code by moving the common
configuration for TWL6030 (on OMAP4 platform) to the
pmic-common file.
Use the omap4_pmic_config function from board files to
properly configure the PMIC with the common fields.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-
Hello,
The second version gowned a bit since v1...
Changes since v1:
- Common pmic related configuration moved out from board files
- Rest of the series has been rebased on top of this change
Not changed since v1:
- TWL6040 MFD driver has not been converted to i2c driver
I have looked at this, a
Add twl4030_vibra platform data, and the needed regulators
for twl6040 vibrator.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-4430sdp.c | 48 +++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
From: Misael Lopez Cruz
Add twl6040_vibra as a child of MFD device twl6040_codec. This
implementation covers the PCM-to-PWM mode of TWL6040 vibrator
module.
Signed-off-by: Jorge Eduardo Candelaria
Signed-off-by: Misael Lopez Cruz
Signed-off-by: Peter Ujfalusi
---
drivers/input/misc/Kconfig
From: Misael Lopez Cruz
Convert TWL6040 CODEC driver into a TWL6040 MFD child, it implies
that MFD-level operations like register accesses, clock setting
and power management are done through MFD APIs, not directly by
CODEC driver anymore. To avoid conflicts with the other MFD child,
vibrator reg
Some regulator config can be moved out from board files,
since they are close to identical.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-3430sdp.c | 51 --
arch/arm/mach-omap2/board-cm-t35.c | 41 +++--
arch/arm/mach-o
Introduce a new file, which will be used to configure
common pmic (TWL) devices, regulators.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/common-board-devices.c | 21 -
arch/arm/mach-omap2/common-board-devices.h | 26
On Mon, 6 Jun 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> [..]
>
> > While it is tempting to try to get away with only two PM callbacks per
> > driver instead of four (or even more), it generally is not doable, simply
> > because driver callbacks are not executed directly by the
Hi Laurent,
On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart
wrote:
>> Right now we have a BUG_ON if pa is unaligned, but that can be changed
>> if needed (do we want it to handle offsets ?).
>
> At least for the OMAP3 ISP we need to, as video buffers don't necessarily
> start on page boundaries.
On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote:
> Ben,
>
> Please pull in this series from Andy Green for the next merge window.
I'll have a look through this set as soon as possible.
> v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic
> sanity testing against w
Hi Tony,
On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
> * Archit Taneja [110504 10:30]:
> > --- a/arch/arm/mach-omap2/board-3430sdp.c
> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > @@ -401,7 +401,7 @@ static struct regulator_consumer_supply
> > sdp3430_vdda_dac_supplies[] = {
> >
On Tue, Jun 7, 2011 at 03:15, Santosh Shilimkar
wrote:
> On 6/7/2011 7:35 AM, Nishanth Menon wrote:
>>
>> Since we do module_init, cpufreq initializes before power late_init
>> where many of the required data structures are registered. Move
>> cpufreq init to late_initcall instead. Further CONFIG_
On Tue, Jun 7, 2011 at 2:40 PM, Laurent Pinchart
wrote:
> My point is that if the allocator guarantees the alignment (not as a side
> effect of the implementation, but per its API) there's no need to check it
> again. As the alignement is required, we need an allocator that guarantees it
> anyway.
On Tue, Jun 07, 2011 at 02:44:58PM +0300, Tomi Valkeinen wrote:
> On Wed, 2011-05-11 at 14:12 +0200, Mark Brown wrote:
> > On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:
> > You need to create a new regulator of some kind and then provide a way
> > for machines to set the supply_r
* Sebastian Reichel [110606 15:51]:
> On Sat, Apr 30, 2011 at 06:23:57PM +0200, Sebastian Reichel wrote:
> > I'm currently trying to get a mainline based kernel running on my
> > pandaboard.
> > The problem is, that it's crashing very early during the init phase because
> > of
> > "undefined ins
On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
> On 6/7/2011 8:52 AM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
> >
> >> Before doing that, could you maybe just try something to make OMAP4
> >> looks a little bit more like OMAP3?
> >>
> >> dss_f
Hi Mark,
Waking up this old thread again.
On Wed, 2011-05-11 at 14:12 +0200, Mark Brown wrote:
> On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:
>
> > So how should the regulator be set up?
>
> You need to create a new regulator of some kind and then provide a way
> for machines
Hi Ohad,
On Tuesday 07 June 2011 13:19:05 Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart wrote:
> >> + BUG_ON(!IS_ALIGNED((long)omap_domain->pgtable, IOPGD_TABLE_SIZE));
> >
> > Either __get_free_pages() guarantees that the allocated memory will be
> > aligned on an
On 6/7/2011 8:52 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
Before doing that, could you maybe just try something to make OMAP4
looks a little bit more like OMAP3?
dss_fck -> ick
dss_dss_fck -> main_clk
That should ensure that both modulemode and th
Hi Ohad,
On Tuesday 07 June 2011 12:28:53 Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart wrote:
> > pgsz isn't used anymore, you can remove it.
>
> Ok.
>
> >> + order = get_order(bytes);
> >
> > Does iommu_map() handle offsets correctly, or does it expect
Hi Laurent,
On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart
wrote:
>> + BUG_ON(!IS_ALIGNED((long)omap_domain->pgtable, IOPGD_TABLE_SIZE));
>
> Either __get_free_pages() guarantees that the allocated memory will be aligned
> on an IOPGD_TABLE_SIZE boundary, in which case the BUG_ON() is unne
Am 07.06.2011 11:50, schrieb Igor Grinberg:
On 06/07/11 11:01, Alexander Holler wrote:
Am 31.05.2011 12:29, schrieb Tony Lindgren:
* Alexander Holler [110405 06:38]:
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Adding this into fi
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg wrote:
> Btw, mind to split out your changes which move the iommu-api into
> drivers/iommu? I can merge them meanwhile into my iommu tree and start
> working on a proposal for the generic large page-size support.
Sure, that will be great. Thanks!
--
Hi Laurent,
On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart
wrote:
> pgsz isn't used anymore, you can remove it.
Ok.
>> + order = get_order(bytes);
>
> Does iommu_map() handle offsets correctly, or does it expect pa to be aligned
> to an order (or other) boundary ?
Right now we h
On Tue, Jun 07, 2011 at 05:22:11AM -0400, Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg wrote:
> > Yup. Btw, is there any IOMMU hardware which supports non-natural
> > alignment? In this case we need to expose these requirements somehow.
>
> Not sure there are. Let's star
On 06/07/11 11:01, Alexander Holler wrote:
> Am 31.05.2011 12:29, schrieb Tony Lindgren:
>> * Alexander Holler [110405 06:38]:
>>> Without msecure beeing high it isn't possible to set (or start)
>>> the RTC.
>>>
>>> Tested with a BeagleBoard C4.
>>
>> Adding this into fixes.
>>
>> Tony
>>
>>> Sig
Hi Ohad,
Thanks for the patch.
On Friday 03 June 2011 00:27:38 Ohad Ben-Cohen wrote:
> Migrate OMAP's iommu to the generic iommu api, so users can stay
> generic, and non-omap-specific code can be removed and eventually
> consolidated into a generic framework.
>
> Tested on both OMAP3 and OMAP4.
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg wrote:
> Yup. Btw, is there any IOMMU hardware which supports non-natural
> alignment? In this case we need to expose these requirements somehow.
Not sure there are. Let's start with natural alignment, and extend it
only if someone with additional re
On Tue, 2011-06-07 at 09:52 +0300, Tomi Valkeinen wrote:
> On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote:
>
> > Before doing that, could you maybe just try something to make OMAP4
> > looks a little bit more like OMAP3?
> >
> > dss_fck -> ick
> > dss_dss_fck -> main_clk
> >
> > That
Hi Ohad,
Thanks for the patch.
On Friday 03 June 2011 00:27:39 Ohad Ben-Cohen wrote:
> Migrate omap's iovmm (virtual memory manager) to the generic iommu api.
>
> This brings iovmm a step forward towards being completely non
> omap-specific (it's still assuming omap's iommu page sizes, and also
On 6/7/2011 7:35 AM, Nishanth Menon wrote:
Since we do module_init, cpufreq initializes before power late_init
where many of the required data structures are registered. Move
cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ
on which the build depends is bool and does'nt support modu
Am 31.05.2011 12:29, schrieb Tony Lindgren:
* Alexander Holler [110405 06:38]:
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Adding this into fixes.
Tony
Signed-off-by: Alexander Holler
---
arch/arm/mach-omap2/board-omap3beagle.c
On Mon, Jun 06, 2011 at 04:09:33PM -0400, Ohad Ben-Cohen wrote:
> On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg wrote:
> > Well, it certainly makes sense to have a single implementation for this.
> > But I want to hide this complexity to the user of the IOMMU-API. The
> > best choice is to put th
On 6/7/2011 9:21 AM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 09:12 +0200, Cousson, Benoit wrote:
On 6/7/2011 8:47 AM, Valkeinen, Tomi wrote:
I'd rather hope the optional clock could be enabled whenever the driver
needs it, between enabling and disabling the hwmod.
Yeah, this is the cas
On Tue, 2011-06-07 at 09:12 +0200, Cousson, Benoit wrote:
> On 6/7/2011 8:47 AM, Valkeinen, Tomi wrote:
> > I'd rather hope the optional clock could be enabled whenever the driver
> > needs it, between enabling and disabling the hwmod.
>
> Yeah, this is the case most of the time, except for you.
On 6/7/2011 8:47 AM, Valkeinen, Tomi wrote:
On Mon, 2011-06-06 at 14:56 +0200, Cousson, Benoit wrote:
That terminology in the PRCM just means that an opt clock will not be
handled automatically by the PRCM and will require SW control.
This is not the case for mandatory clock. Upon module enable
77 matches
Mail list logo
