(+ linux-arm, Marc)
On Thursday 16 February 2012 11:54 PM, Kevin Hilman wrote:
> Hi Santosh,
>
> Using v3.3-rc3 and building an OMAP2+ kernel I noticed that CPUfreq
> transitions fault because of the TWD cpufreq notifiers being called even
> on OMAP3.
>
> Of course, the TWD doesn't exist on OMAP
Hi Kevin,
On Fri, Feb 17, 2012 at 00:50:43, Hilman, Kevin wrote:
> + /* scaling up? scale voltage before frequency */
> + if (mpu_reg && (freqs.new > freqs.old))
> + regulator_set_voltage(mpu_reg, volt, volt);
Probably voltage ranges has to be specified, otherwise
if I unders
Hi Tony,
Here is a small cleanup series to prepare for further DT series for 3.4.
Thanks,
Benoit
The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:
Linus Torvalds (1):
Linux 3.3-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linu
Hi Tony,
Here's a couple more OMAP PM fixes for v3.3-rc
Kevin
The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:
Linux 3.3-rc3 (2012-02-08 19:21:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.
Hi Grant,
I've given this a final review and testing and I believe it's ready for
3.4, so here you go.
Also note that Benoit's recently posted GPIO cleanups and DT conversion
depend on this series.
Thanks,
Kevin
The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
L
Jean Pihet writes:
> Hi Kevin,
>
> On Thu, Feb 16, 2012 at 11:20 AM, Kevin Hilman wrote:
>> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
>> index 8a36342..140c032 100644
>> --- a/arch/arm/mach-omap2/voltage.c
>> +++ b/arch/arm/mach-omap2/voltage.c
>> @@ -89,6 +89,8
Hi Kevin,
On Thu, Feb 16, 2012 at 11:20 AM, Kevin Hilman wrote:
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
> index 8a36342..140c032 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -89,6 +89,8 @@ int voltdm_scale(struct volt
This patch modifies the OMAP CPUfreq driver to use the regulator framework
to scale voltage when scaling frequency. It uses the new SMPS regulator
driver from Tero.
This patch applies on top of the recently posted SMPS regulator series
from Tero:
Subject: [PATCHv9 0/5] arm: omap: smps regulat
Use the regulator framework to get the voltage regulator associated
with the MPU voltage domain and use it to scale voltage along with
frequency.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/voltage.c |2 ++
drivers/cpufreq/omap-cpufreq.c | 29 -
2 files
Hi,
* Thomas Weber [120216 10:05]:
> Hello Tony,
>
> do you have any comments on this?
Well we're trying to remove all the board-*.c files by
using device tree, so I suggest starting to look into
that a bit. So no new board-*.c files are not being added,
unless they're device tree based.
If th
Hello Tony,
do you have any comments on this?
Thomas
On 02/01/2012 04:59 PM, Thomas Weber wrote:
Tricorder is a board which is very similar to the Devkit8000.
It is designed as a base platform for further medical devices.
www.corscience.de/en/medical-engineering/products/multiparameter/mp10-b
From: Russell King
The OMAP driver depends on CPUfreq table support for creating a table
of frequencies from the OPP layer. Ensure that it's build to avoid
link-time errors.
Signed-off-by: Russell King
[khil...@ti.com: make user-selectable, but default y]
Tested-by: Kevin Hilman
Signed-off-by
Hi Santosh,
Using v3.3-rc3 and building an OMAP2+ kernel I noticed that CPUfreq
transitions fault because of the TWD cpufreq notifiers being called even
on OMAP3.
Of course, the TWD doesn't exist on OMAP3, but the TWD init is still
setting up notifiers. I tried just adding a !cpu_is_omap44xx() c
On Thu, Feb 16, 2012 at 04:27, Tero Kristo wrote:
> VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
> to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
> are needed by DVFS.
>
> Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manual.
On Thu, Feb 16, 2012 at 11:35, Kevin Hilman wrote:
>
>>> IMO, the one thing we're still missing is the ability to take register
>>> snapshots (like immediately before and after WFI) and somehow feed those
>>> to omapconf for deciphering.
>>>
>> Something like this perhaps?
>> https://github.com/nm
Benoit Cousson writes:
> This warning becomes a little bit too verbose with the increase of
> device nodes in some DTS files.
>
> Change it to debug only.
>
> Signed-off-by: Benoit Cousson
> Cc: Kevin Hilman
Acked-by: Kevin Hilman
> ---
> arch/arm/plat-omap/omap_device.c |2 +-
> 1 fil
"Menon, Nishanth" writes:
> On Wed, Feb 15, 2012 at 09:20, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>>> On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote:
* Kevin Hilman [120214 14:28]:
> Tony Lindgren writes:
>
> > * Tero Kristo [120214 08:19]:
> >> Voltdm
Tero Kristo writes:
> On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
>> On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo wrote:
>> > On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
>> >> On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
>> >> > On Thu, Feb 16, 2012 at
On Wed, Feb 15, 2012 at 09:20, Kevin Hilman wrote:
> Tero Kristo writes:
>
>> On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote:
>>> * Kevin Hilman [120214 14:28]:
>>> > Tony Lindgren writes:
>>> >
>>> > > * Tero Kristo [120214 08:19]:
>>> > >> Voltdm, pwrdm, clkdm, hwmod and clk usecount
* Rajendra Nayak [120216 08:19]:
> On Thursday 16 February 2012 10:05 PM, Tony Lindgren wrote:
> >>On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
> >better still, I think we should just populate them statically in
> >omap2_hsmmc_info struct above, so omap_hsmmc_init() tak
On Thursday 16 February 2012 10:05 PM, Tony Lindgren wrote:
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
> >better still, I think we should just populate them statically in
> >omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
> >of it already.
>
> I just tried t
On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
> On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo wrote:
> > On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
> >> On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
> >> > On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo wrote:
On 2/16/2012 5:35 PM, Tony Lindgren wrote:
* Rajendra Nayak [120216 01:42]:
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried
* Tony Lindgren [120215 09:57]:
>
> +void omap_hsmmc_late_init(struct omap2_hsmmc_info *controllers)
> +{
> + struct platform_device *pdev;
> + int res;
> +
> + for (; controllers->mmc; controllers++) {
> + if (!controllers->deferred)
> + continue;
> +
* Russell King - ARM Linux [120216 01:40]:
> On Wed, Feb 15, 2012 at 10:28:30AM -0800, Tony Lindgren wrote:
> > Now that omap hsmmc init is split into two functions, it's safe
> > to mark omap_hsmmc_init and omap_mux related functions to __init.
> >
> > This basically reverts the following fixes
* Rajendra Nayak [120216 01:42]:
> On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
> >better still, I think we should just populate them statically in
> >omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
> >of it already.
>
> I just tried this and it seems to work...
>
Hi Aneesh,
On 2/4/2012 1:16 PM, Aneesh V wrote:
> EMIF is an SDRAM controller used in various Texas Instruments
> SoCs. EMIF supports, based on its revision, one or more of
> LPDDR2/DDR2/DDR3 protocols.
>
> Add the basic infrastructure for EMIF driver that includes
> driver registration, probe, p
On Thu, Feb 16, 2012 at 12:27:52PM +0200, Tero Kristo wrote:
> This is needed for SMPS regulators, which use the OMAP voltage
> processor for voltage get/set functions instead of the normal I2C
> channel. For this purpose, regulator_init_data->driver_data contents
> are expanded, it is now a struct
On Thu, Feb 16, 2012 at 04:21:11PM +0530, Santosh Shilimkar wrote:
> Andrew, Greg,
>
> On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> > Add a driver for the EMIF SDRAM controller used in TI SoCs
> >
> > EMIF is an SDRAM controller that supports, based on its revision,
> > one or more of
> did you try twl4030_wdt instead of omap_wdt?
Hi Enrico,
Last night I went searching around for a fix on the same watchdog problem Steve
was having, but this time on a BeagleBoard XM Rev. C., using the 37xx chip.
Using the twl4030_wdt driver instead of omap_wdt driver succeeded in rebooting
t
On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo wrote:
> On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
>> On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
>> > On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo wrote:
>> > > On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
>> > >
On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
> On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
> > On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo wrote:
> > > On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
> > >> Tero Kristo writes:
> > >>
> > >> > Attempting this will
arch/arm/mach-omap2/: included some headers tiwce:
- arch/arm/mach-omap2/board-ldp.c: 'linux/gpio.h'
- arch/arm/mach-omap2/io.c: 'common.h'
- arch/arm/mach-omap2/omap_hwmod_44xx_data.c: 'plat/i2c.h'
Remove the duplicates.
Signed-off-by: Danny Kukawka
---
arch/arm/mach-omap2/board-ldp.c
arch/arm/plat-omap/clock.c: included 'linux/debugfs.h' twice,
remove the duplicate.
Signed-off-by: Danny Kukawka
---
arch/arm/plat-omap/clock.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 567e4b5..56b6f8b
On Thu, Feb 16, 2012 at 06:45:50PM +0530, Rajendra Nayak wrote:
> On Thursday 16 February 2012 06:04 PM, Rajendra Nayak wrote:
>>> Can you test something with these patches?
>>>
>>> 1. Build the gpio-twl4030.c as a module, but with HSMMC support built in
>>> 2. Boot on the 4430SDP
>>
>> twl4030 gpi
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
> On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo wrote:
> > On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
> >> Tero Kristo writes:
> >>
> >> > Attempting this will cause problems especially with off-mode enabled.
> >>
> >> Please
On Thursday 16 February 2012 06:04 PM, Rajendra Nayak wrote:
Can you test something with these patches?
1. Build the gpio-twl4030.c as a module, but with HSMMC support built in
2. Boot on the 4430SDP
twl4030 gpio is used for card detect on OMAP3, so I tried this
on my Beagle instead of 4430SDP
On Thursday 16 February 2012 05:42 PM, Russell King - ARM Linux wrote:
On Thu, Feb 16, 2012 at 05:30:59PM +0530, Nayak, Rajendra wrote:
One more patch is needed to sort out the remaining issue with
omap4 that has yet another luck based initialization for the
same issue..
I did this patch on t
On Thu, Feb 16, 2012 at 05:30:59PM +0530, Nayak, Rajendra wrote:
> > One more patch is needed to sort out the remaining issue with
> > omap4 that has yet another luck based initialization for the
> > same issue..
> >
>
> I did this patch on top of your series which should fix the
> issue on all om
> One more patch is needed to sort out the remaining issue with
> omap4 that has yet another luck based initialization for the
> same issue..
>
I did this patch on top of your series which should fix the
issue on all omap4 boards too. Tested on omap4panda and
omap4sdp boards.
>From 5a4bbd64fd1e79
On Thursday 16 February 2012 04:14 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Add settings that are not dependent on frequency
or any other transient parameters
Expand the changelog a bit. One time settings like
SDRAM_CONFIG, PHY_CONTROL, TEMP alert etc
On Thursday 16 February 2012 04:40 PM, Alan Cox wrote:
On Thu, 16 Feb 2012 15:57:57 +0530
Aneesh V wrote:
On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
On Thursday 16 February 2012 04:11 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
On thermal events SDRAM timing parameters are
adjusted to ensure
Hi ,
On Tue, Feb 14, 2012 at 3:45 PM, Tasslehoff Kjappfot
wrote:
> Sorry about the bad mails. First time I use git send-email to follow up on a
> patch, and it seems I need to read up a bit more on it.
>
> Anyway.
>
> This patch is tested on our custom board based on Beagleboard rev C3.
thanks fo
On Thu, Feb 16, 2012 at 4:40 PM, Alan Cox wrote:
> On Thu, 16 Feb 2012 15:57:57 +0530
> Aneesh V wrote:
>
>> On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote:
>> > On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
>> >> add LPDDR2 data from the JEDEC spec JESD209-2. The data
>>
On Thursday 16 February 2012 04:08 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs s
On Thursday 16 February 2012 04:03 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructur
On Thu, 16 Feb 2012 15:57:57 +0530
Aneesh V wrote:
> On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote:
> > On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> >> add LPDDR2 data from the JEDEC spec JESD209-2. The data
> >> includes:
> >>
> >> 1. Addressing information for LPDDR
On 2/15/2012 7:13 PM, Tony Lindgren wrote:
> * Cousson, Benoit [120215 04:43]:
>> On 2/14/2012 8:52 PM, Tony Lindgren wrote:
>>> * Benoit Cousson [120213 07:59]:
Some .atag_offset entries were wrongly added during a merge conflict
resolution in 3.3.
Remove them all, since DT boot
Andrew, Greg,
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> Add a driver for the EMIF SDRAM controller used in TI SoCs
>
> EMIF is an SDRAM controller that supports, based on its revision,
> one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
> for LPDDR2.
>
> The drive
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> Add debug entries for:
> 1. calculated registers per frequency
> 2. last polled value of MR4(temperature level
> of LPDDR2 memory)
>
> Signed-off-by: Aneesh V
looks good.
Regards
santosh
--
To unsubscribe from this li
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> Add settings that are not dependent on frequency
> or any other transient parameters
>
Expand the changelog a bit. One time settings like
SDRAM_CONFIG, PHY_CONTROL, TEMP alert etc.
> Signed-off-by: Aneesh V
> ---
Patch looks fine.
Regards
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> Add an ISR for EMIF that:
> 1. reports details of access errors
> 2. takes action on thermal events
>
> On thermal events SDRAM timing parameters are
> adjusted to ensure safe operation
>
> Also clear all interrupts on shut-down
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> Change SDRAM timings and other settings as necessary
> on voltage and frequency changes. We calculate these
> register settings based on data from the device data
> sheet and inputs such a frequency, voltage state(stable
> or ramping), temper
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> EMIF is an SDRAM controller used in various Texas Instruments
> SoCs. EMIF supports, based on its revision, one or more of
> LPDDR2/DDR2/DDR3 protocols.
>
> Add the basic infrastructure for EMIF driver that includes
> driver registration, pr
On Thursday 16 February 2012 03:40 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Signed-off-by: Aneesh V
---
drivers/misc/emif_regs.h | 461 ++
1 files changed, 461 insertions(+), 0 deletions(-)
create mode 1
This is needed for SMPS regulators, which use the OMAP voltage
processor for voltage get/set functions instead of the normal I2C
channel. For this purpose, regulator_init_data->driver_data contents
are expanded, it is now a struct which contains function pointers
for the set/get voltage operations,
VDD1 and VDD2 now use voltage processor for controlling the regulators.
This is done by passing additional voltdm data during the regulator init.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/twl-common.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletio
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manual.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/twl-co
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0 deletions(-)
diff -
OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/vc3xxx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
di
Hi,
Following changes compared to previous version:
- updated to work with mainline
- added acked-by Samuel Ortiz to patch 4 MFD part (no changes done to that
part of code since previous version)
- changed min_uV parameter name from patch 4/5 to target_uV
Tested with omap3 beagle: changed + me
On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
Santosh,
Thanks for the review.
On Thursday 16 February 2012 03:32 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
From: Benoit Cousson
One line of change log will do here.
Ok. Will add.
br,
Aneesh
--
To unsubscribe from this list: send the line "unsubs
On 2/16/2012 9:22 AM, Tomi Valkeinen wrote:
On Wed, 2012-02-15 at 11:59 -0800, Kevin Hilman wrote:
"Cousson, Benoit" writes:
Kevin,
Do we still need to set the dev.parent to omap_device_parent?
Nope.
I guess the default&platform_bus parent is good enough and
potentially the DSS children
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried this and it seems to work...
---
arch/arm/mach-omap2/board-omap3beagle.c |
On Wed, Feb 15, 2012 at 10:28:30AM -0800, Tony Lindgren wrote:
> Now that omap hsmmc init is split into two functions, it's safe
> to mark omap_hsmmc_init and omap_mux related functions to __init.
>
> This basically reverts the following fixes for the case where
> TWL was compiled as a module:
>
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> Signed-off-by: Aneesh V
> ---
> drivers/misc/emif_regs.h | 461
> ++
> 1 files changed, 461 insertions(+), 0 deletions(-)
> create mode 100644 drivers/misc/emif_regs.h
>
Changelog please. O.w
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> add LPDDR2 data from the JEDEC spec JESD209-2. The data
> includes:
>
> 1. Addressing information for LPDDR2 memories of different
>densities and types(S2/S4)
> 2. AC timing data.
>
> This data will useful for memory controller device d
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> add LPDDR2 data from the JEDEC spec JESD209-2. The data
> includes:
>
> 1. Addressing information for LPDDR2 memories of different
>densities and types(S2/S4)
> 2. AC timing data.
>
> This data will useful for memory controller device d
Hi Tony,
On Wednesday 15 February 2012 11:58 PM, Tony Lindgren wrote:
Otherwise omap_device_build() and omap_mux related functions
can't be marked as __init when twl is build as a module.
If a board is using GPIO pins or regulators configured by an
external chip, such as TWL PMIC on I2C bus, th
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
> From: Benoit Cousson
>
One line of change log will do here.
Regards
santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.k
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo wrote:
> On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>> > Attempting this will cause problems especially with off-mode enabled.
>>
>> Please be more verbose about the problems seen, and the root cause(s).
>>
>
> I w
On 2/16/2012 6:53 AM, DebBarma, Tarun Kanti wrote:
On Wed, Feb 15, 2012 at 9:34 PM, Benoit Cousson wrote:
The driver does not need anymore any id to identify the GPIO instance.
Remove every occurence of the bank->id inside the driver.
Remove two trailing spaces.
Add a dev variable for better r
On Thu, 2012-02-16 at 14:13 +0530, Shilimkar, Santosh wrote:
> Tero,
> On Thu, Feb 16, 2012 at 2:09 PM, Tero Kristo wrote:
> > On Wed, 2012-02-15 at 11:35 -0800, Kevin Hilman wrote:
> >> Tero Kristo writes:
> >>
> >> > Some clockdomains can't support manual domain transitions triggered by
> >> >
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > Attempting this will cause problems especially with off-mode enabled.
>
> Please be more verbose about the problems seen, and the root cause(s).
>
I was actually looking forward for some help with this commit me
On 2/16/2012 7:37 AM, Shubhrajyoti wrote:
On Thursday 16 February 2012 11:11 AM, DebBarma, Tarun Kanti wrote:
Hi Benoit,
On Wed, Feb 15, 2012 at 9:34 PM, Benoit Cousson wrote:
Replace the regular kzalloc and ioremap with the devm_ equivalent
to simplify error handling.
Add the missing devm_r
Tero,
On Thu, Feb 16, 2012 at 2:09 PM, Tero Kristo wrote:
> On Wed, 2012-02-15 at 11:35 -0800, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>> > Some clockdomains can't support manual domain transitions triggered by
>> > clock framework, and must be prevented from doing so. Added clkdm flag
>> >
On Wed, 2012-02-15 at 11:35 -0800, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > Some clockdomains can't support manual domain transitions triggered by
> > clock framework, and must be prevented from doing so. Added clkdm flag
> > CLKDM_NO_MANUAL_TRANS for doing this.
> >
> > Signed-off-by: Ter
On Wed, 2012-02-15 at 11:59 -0800, Kevin Hilman wrote:
> "Cousson, Benoit" writes:
> > Kevin,
> >
> > Do we still need to set the dev.parent to omap_device_parent?
>
> Nope.
>
> > I guess the default &platform_bus parent is good enough and
> > potentially the DSS children should be able to over
80 matches
Mail list logo
