On Wednesday 13 March 2013 11:12 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
Kevin,
On Wednesday 13 February 2013 02:25 PM, Santosh Shilimkar wrote:
Current CPU PM code code make use of common cpu_suspend() path for all the
CPU power states which is not
On Thursday 14 March 2013 12:01 AM, Thomas Gleixner wrote:
On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote:
Though making the rating of the dummy lower is definitely a good
thing, so a real hardware device which is detected later can
On Wednesday 13 March 2013 10:16 PM, Benoit Cousson wrote:
Hi Sourav,
I've just applied your branch after a minor subject cleanup for consistency.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts
Thanks for the tree Benoit. I shall update my v2 DT
Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
Some PHYs load too early (twl4030) making omap glue to miss cable connect events
if the board is booted with cable connected. So adding usb_phy_init in
omap2430_musb_init lets PHYs to report events once glue is ready.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is
This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
fixes-for-v3.9-rc3 after applying
http://www.spinics.net/lists/linux-usb/msg81563.html
(Grazvydas Ignotas patch series)
Tested for g_zero enumeration in
No functional change. otg_set_vbus is already protected so removed the
check before calling otg_set_vbus.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git
Will,
On Wednesday 13 March 2013 05:59 PM, Lokesh Vutla wrote:
Hi Dietmar,
On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote:
On 13/03/13 06:52, Lokesh Vutla wrote:
Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for
self-hosted
debug} introduces debug powerdown
On Mon, 2013-03-11 at 09:33 -0700, Tony Lindgren wrote:
* Paul Bolle pebo...@tiscali.nl [130309 11:52]:
In the meantime, how do you prefer I solve the (trivial) issue of an
useless select for MACH_NOKIA_RM696? Drop that select or add an (equally
useless) config entry for MACH_NOKIA_RM696?
On Wed, Mar 13, 2013 at 10:34 PM, Anna, Suman s-a...@ti.com wrote:
On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna s-a...@ti.com wrote:
From: Omar Ramirez Luna omar.l...@linaro.org
(...)
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
[s-a...@ti.com: Kconfig fixes for build errors]
On 03/13/2013 11:33 PM, Andrew Chew wrote:
Many backlights are enabled via GPIO. We can generalize the GPIO to a
fixed regulator.
The enable regulator needs to be mandatory because there was no good way
to determine the difference between opting out of the regulator, and probe
deferral.
On Thu, 14 Mar 2013, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.
I think what you treat as lockup is
(Looping Greg KH.)
Greg,
On Wednesday 20 February 2013 09:14 PM, Santosh Shilimkar wrote:
On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART IP slave idle handling now taken care by runtime pm backend(hwmod
layer)
so remove
On 14/03/13 09:13, Artem Bityutskiy wrote:
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix
On 3/13/2013 3:04 PM, Mark Jackson wrote:
On 18/02/13 08:19, Mugunthan V N wrote:
CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
On 14/03/13 10:21, Mugunthan V N wrote:
On 3/13/2013 3:04 PM, Mark Jackson wrote:
On 18/02/13 08:19, Mugunthan V N wrote:
CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api
On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
On Wed, Mar 13, 2013 at 11:24:01AM +,
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
On 14/03/13 09:13, Artem Bityutskiy wrote:
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I
Hello guys,
This is v2 of my patch https://patchwork.kernel.org/patch/1232871/
rebased on v3.9-rc2. Removes deprecated flags and structures
and saves few bytes of memory.
Regards,
Ruslan
Ruslan Bilovol (1):
omap: usb: host: remove deprecated flags and structures
These flags and structures are deprecated and there is
no anymore users of them, so it's safe to remove them.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
include/linux/platform_data/usb-omap.h | 20
1 file changed, 20 deletions(-)
diff --git
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Felipe Balbi ba...@ti.com
CC: Kukjin Kim kgene@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c |6 +++---
1
This patch-set modifies dwc3-exynos as per latest bindings
available for dwc3. Now the dwc3 core also has device support,
there's no need to add platform device for core in glue layers.
This change has come as a result of discussion happened in:
[PATCH RFC] usb: dwc3: Get PHY from platform
Hi,
On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote:
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Felipe Balbi ba...@ti.com
CC: Kukjin Kim
On 14/03/13 10:30, Artem Bityutskiy wrote:
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
On 14/03/13 09:13, Artem Bityutskiy wrote:
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim,
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote:
[ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte=
[ 28.545173] Internal error: Oops: 7 [#1] ARM
[ 28.549685] CPU: 0Not tainted
(3.8.0-next-20130225-2-g678576f-dirty #40)
[ 28.557595] PC is at
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, March 04, 2013 5:06 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; khil...@linaro.org; p...@pwsan.com; Nayak,
Rajendra; linux-arm-ker...@lists.infradead.org; Hiremath, Vaibhav
Subject: [RFC PATCH 0/3] ARM: OMAP2+:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, March 12, 2013 10:10 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: OMAP baseline test results for
On Thursday 14 March 2013 04:59 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, March 12, 2013 10:10 PM
To: linux-omap@vger.kernel.org
Cc:
On Thu, Mar 14, 2013 at 4:21 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
@@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
-
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote:
But there's also a call to crc with a size of 122880 bytes, and that's
when the oops occurs.
This is when we do the atomic LEB change.
Is this size larger than the allocated buffer ?
I believe so.
--
Best Regards,
Artem Bityutskiy
--
These patches mainly fix the crash that was reported with
CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock
initializations.
Tested on Panda ES (omap4460), beagle Xm (omap3630) and
BeagleBoneBlack (AM335x)
Rajendra Nayak (2):
ARM: OMAP2+: clocks: Have consistent naming for parent name
Missed out Mike, copied now.
On Thursday 14 March 2013 06:06 PM, Rajendra Nayak wrote:
These patches mainly fix the crash that was reported with
CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock
initializations.
Tested on Panda ES (omap4460), beagle Xm (omap3630) and
On Thu, Mar 14, 2013 at 12:41:13PM +0200, Ruslan Bilovol wrote:
These flags and structures are deprecated and there is
no anymore users of them, so it's safe to remove them.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
--
balbi
signature.asc
On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote:
This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
fixes-for-v3.9-rc3 after applying
On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote:
From: Graeme Gregory g...@slimlogic.co.uk
This is the driver for the OTG transceiver built into the Palmas chip. It
handles the various USB OTG events that can be generated by cable
insertion/removal.
Signed-off-by:
On 14/03/13 12:23, Artem Bityutskiy wrote:
On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
Is this size larger than the allocated buffer ?
I believe so.
Err, I mean, the buffer is large enough. I do not believe there is a
stupid bug like too small buffer. This code has worked
On Tue, Mar 12, 2013 at 11:57:56AM -0400, Alan Stern wrote:
On Tue, 12 Mar 2013, Roger Quadros wrote:
Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
On Thursday 14 March 2013 07:03 PM, Felipe Balbi wrote:
On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote:
This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
fixes-for-v3.9-rc3 after
On Thu, 14 Mar 2013, Felipe Balbi wrote:
if (IS_ERR(phy) || !phy) {
+ /* Don't bail out if PHY is not absolutely necessary */
+ if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
+ continue;
+
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a previous call to gpmc_cs_program_settings()
that had to succeed or
On 03/13/2013 06:57 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130313 09:40]:
On 03/13/2013 06:24 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130313 06:46]:
On 03/12/2013 06:40 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130312 04:47]:
Hi Tony,
These
On 03/11/2013 06:56 PM, Jon Hunter wrote:
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote:
Yes you are correct. In general, I have been
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
On 03/14/2013 12:41 PM, Ruslan Bilovol wrote:
These flags and structures are deprecated and there is
no anymore users of them, so it's safe to remove them.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
Acked-by: Roger Quadros rog...@ti.com
Tony,
Do you prefer to take this directly or
On 03/14/2013 10:45 AM, Benoit Cousson wrote:
On 03/11/2013 06:56 PM, Jon Hunter wrote:
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote:
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter jon-hun...@ti.com wrote:
Yes, I full agree with that as well. The size should be purely HW
related. So we should not take any assumption about the page size /
alignment.
Ok, what is best to use? The size from hwmod structures or the size from
the
On 03/14/2013 04:50 PM, Jon Hunter wrote:
On 03/14/2013 10:45 AM, Benoit Cousson wrote:
On 03/11/2013 06:56 PM, Jon Hunter wrote:
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Fri, Mar 8, 2013 at
On 03/14/2013 10:45 AM, Florian Vaussard wrote:
Hi Benoit,
On 03/14/2013 03:57 PM, Benoit Cousson wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent
On 03/14/2013 05:00 PM, Jon Hunter wrote:
On 03/14/2013 10:58 AM, Benoit Cousson wrote:
On 03/14/2013 04:50 PM, Jon Hunter wrote:
On 03/14/2013 10:45 AM, Benoit Cousson wrote:
On 03/11/2013 06:56 PM, Jon Hunter wrote:
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
On Fri, Mar 8, 2013
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as
Hi guys,
This is a resend of my patch:
http://permalink.gmane.org/gmane.linux.usb.general/67238
At this moment it has been successfully tested and
used on top of 3.0 and 3.4 kernels on omap4 devices
so it would be great to have it in upstream too.
Regards,
Ruslan
Ruslan Bilovol (1):
usb:
MUSB controller cannot work in DMA mode with misaligned buffers,
switching in PIO mode.
HCD core has hooks that allow to override the default DMA
mapping and unmapping routines for host controllers that have
special DMA requirements, such as alignment contraints.
It is observed that work in PIO
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a
Here are some basic OMAP test results for Linux v3.9-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc2/20130314094808/
Test summary
Build:
FAIL ( 4/16): am33xx_only, omap1_defconfig,
omap1_defconfig_5912osk_only,
On 03/14/13 03:28, Mark Rutland wrote:
On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
I do
On Thu, Mar 14, 2013 at 7:49 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
migrating the cpufreq support only through device tree (part of the effort
to migrate away from non-DT configurations for OMAP). Unfortunately,
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar
With OMAP3+ and AM33xx supported SoC having defined CPU DT
entries with operating-points defined, we can now
use the SoC generic cpu0-cpufreq driver to start
using it, lets now switch to the generic driver.
As part of this change, switch the dummy clock node to use
cpufreq-cpu0. This is an
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
Add DT OPP table for OMAP446x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc:
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP3 platforms.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc:
Javier
Hi Jon,
On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as
On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote:
Javier
Hi Jon,
On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
migrating the cpufreq support only through device tree (part of the effort
to migrate away
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
No mention here about what you are removing ;-)
Jon
--
To
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
Not sure I following the last sentence. The tables are in a
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
FYI, I had to create a similar file for PMU [1]. However, I called it
omap4460.dtsi and not omap446x.dtsi as there is
On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon n...@ti.com wrote:
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson
75 matches
Mail list logo
