.
Regards,
Benoit
--
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.kernel.org/majordomo-info.html
, right. We should really be churning the device tree like this - the
idea is that the device tree should be stable and independant of kernel
versions. It would be better if we were able to go straight to the one
without hwmod, especially if Benoit is able to get the underlying
changes done soon
On 12/2/2011 3:00 PM, Mark Brown wrote:
On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:
Even if the reg-names and interrupts-names are accepted, which is
still not obvious due to a little bit of resistance, we still do not
Yeah, it seems like there's very little traction
of such feature.
From driver's perspective I think this only makes things more complex,
as the driver is not interested in the parent, only about the dss fck.
Fully agree. It should transparent for the driver.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap
On 12/1/2011 1:02 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Hilman, Kevin
Sent: Thursday, December 01, 2011 7:12 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
arm-ker...@lists.infradead.org; Cousson, Benoit
Subject: Re: [RFC
Hi Paul,
On 11/29/2011 7:11 PM, Paul Walmsley wrote:
On Tue, 29 Nov 2011, Cousson, Benoit wrote:
On 11/27/2011 3:07 AM, Paul Walmsley wrote:
So just out of curiosity, do those SYSCONFIG registers in the STM address
space apply to the entire DEBUGSS, or just the STM IP block?
The STM IP
should modify this flag to
highlight the SYSCONFIG / SYSSTATUS availability.
Maybe with something like ADDR_SYSCONFIG?
Any thought?
Regards,
Benoit
--
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
*/
+ ret = oh-prcm.omap4.context_lost_counter;
+ } else {
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+ if (pwrdm)
+ ret = pwrdm_get_context_loss_count(pwrdm);
+ }
return ret;
}
Regards,
Benoit
--
To unsubscribe from this list: send
independently.
I think that AVS does belong to the voltage control infrastructure more
than the DVFS/freq one.
But that just my .2 cents
Regards,
Benoit
--
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
to base branches on some
recent tag like v3.2 or v3.2-rc2. Of course, that is assuming there's
no dependency to some recent fix :)
Oops, sorry, I thought the latest HEAD would be better than rc2.
Next time, I'll stick to the latest tag.
Thanks,
Benoit
Regards,
Tony
It might already be in Paul's
is not needed for my point of view. The device is
already properly enabled. I don't think it was even needed in the
previous code. The hwmod was already enabled properly, only the
omap_device was disabled. So the original omap_console_hwmod_enable
should just do nothing.
Regards,
Benoit
on mainline for your convenience.
git://gitorious.org/omap-pm/linux.git wip-emu/debuss_hwmod
Regards,
Benoit
---
From: Benoit Cousson b-cous...@ti.com
Date: Fri, 18 Nov 2011 11:42:12 +0100
Subject: [PATCH] ARM: OMAP4: hwmod data: Add support for the debug modules
The OMAP4 DEBUG subsystem contains all
to be handled in some way in the framework
itself like the one above.
For the moment, it looks like only the serial is requiring such custom
stuff, but anyway, we should have a mechanism to allow that...
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
approve...
Oops, sorry its not Gerrit :-)
Acked-by: Benoit Cousson b-cous...@ti.com
Thanks,
Benoit
--
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.kernel.org/majordomo-info.html
(omap_console_latency).
I'm wondering how it can work with zero since the code is doing that in
omap_device_alloc:
od-pm_lats = kmemdup(pm_lats,
sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
GFP_KERNEL);
Regards,
Benoit
--
To unsubscribe from
properties for platform-specific configuration data.
Does that mean that this is supported only if the bootloader does not
support cmdline?
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Tony,
That bug is becoming annoying, and a bunch of folks are hitting that issue
during DT dev for 3.3, so it will be cool to fix that ASAP.
It might already be in Paul's queue for 3.2-rc3.
Thanks,
Benoit
The following changes since commit 6aaf05f472c97ebceff47d9eef464574f1a55727:
Linus
On 11/16/2011 4:41 PM, Rob Herring wrote:
Benoit,
On 11/16/2011 09:14 AM, Cousson, Benoit wrote:
Hi Rob,
On 11/16/2011 3:50 PM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
console device on OMAP is never reset or idled by hwmod post
initial setup, early during boot
On 11/11/2011 12:47 PM, Jamie Iles wrote:
On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote:
[Adding Benoit to CC].
On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote:
On Wed, 9 Nov 2011, Ming Lei wrote:
Also, current arm perf code don't handle three IRQs(one pl310 irq
Hi Will,
On 11/11/2011 3:58 PM, Will Deacon wrote:
Hi Benoit,
On Fri, Nov 11, 2011 at 02:56:05PM +, Cousson, Benoit wrote:
It will come soon... along with the updated patch for reg-names support.
Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
And I'll do
the original file and use instead the
status = disabled field for any variant that will not have the
functionality?
It will be a nightmare for us to maintain a consistent OMAP3 file if
every variants force us to change the original file.
Regards,
Benoit
--
To unsubscribe from this list: send
Hi Igor,
On 11/10/2011 6:26 PM, Igor Grinberg wrote:
On 11/10/11 19:09, Cousson, Benoit wrote:
+ devicetree ml
On 11/10/2011 1:18 PM, Igor Grinberg wrote:
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
Split omap3.dtsi file into common part, OM3xxx specific part and
AM35xx specific part
/lists/linux-omap/msg59847.html
This is the missing semi-colon that still need to be fixed.
Regards,
Benoit
--
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.kernel.org/majordomo-info.html
as a module, and that's not
possible yet for the l3_noc.
The fix is still good to have, but the changelog should probably be updated.
Regards,
Benoit
--
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
don't know where these defines are used, but we'd better use the existing
ones.
Benoit
--
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.kernel.org/majordomo-info.html
posted and applied by Tony on linux-omap master.
Except the missing semicolon... This is a similar issue that Ohad
reported for hwspinlock.
It will build fine until you will try to build the omap_l3_noc as a module.
Govind,
You can maybe repost a fix for that one only.
Regards,
Benoit
.
need to find out a way to create all devices via devicetree. Do you have
a branch which I could patch on top of ?
The latest mainline master branch does contain the first DT patches for
basic OMAP3 4 support. You can probably start from here for OMAP2 DT
support as well.
Regards,
Benoit
straightforward and mandatory for starting any
OMAP device tree migration until we have the proper reg-names, irq-names
and dma-names generic binding.
Did you had any concern with that binding?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
On 10/11/2011 12:35 AM, Paul Walmsley wrote:
On Tue, 11 Oct 2011, Cousson, Benoit wrote:
On 10/10/2011 10:42 PM, Paul Walmsley wrote:
If it's the 3xxx that you're objecting to in the name, we could call it
prm2 or prmxyz - the '3xxx' just seemed like the most logical
approach. The name
On 10/11/2011 1:26 AM, Paul Walmsley wrote:
On Tue, 11 Oct 2011, Cousson, Benoit wrote:
In fact the device name does not have to match the hwmod name. So we can just
create an omap2_prm omap_device for OMAP2, omap3_prm omap_device for
OMAP3...
That will allow the relevant PRM driver
clocks, that why I did not populate the main_clk.
IIRC, we decided to not duplicate the iclk into the main_clk in case of
module that are using only the interface clock as their functional clock.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
On 10/10/2011 11:34 PM, Hunter, Jon wrote:
Hi Benoit,
On 10/10/2011 4:54, Cousson, Benoit wrote:
Hi Jon,
On 10/8/2011 12:46 AM, Hunter, Jon wrote:
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep
Hi Jon,
On 10/8/2011 12:46 AM, Hunter, Jon wrote:
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two
On 10/10/2011 12:05 PM, DebBarma, Tarun Kanti wrote:
On Mon, Oct 10, 2011 at 11:10 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Wed, Oct 5, 2011 at 3:06 AM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Tarun,
On 10/4/2011 11:20 PM, Cousson, Benoit wrote:
Hi Tony,
Here
in the case of the prm.
Regards,
Benoit
- Paul
From: Paul Walmsleyp...@pwsan.com
Date: Mon, 10 Oct 2011 13:11:11 -0600
Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod
Add a hwmod for the Power Reset Management (PRM) IP block that is
present on OMAP3xxx SoCs.
Signed-off-by: Paul Walmsleyp
On 10/10/2011 10:42 PM, Paul Walmsley wrote:
Hi Benoît
On Mon, 10 Oct 2011, Cousson, Benoit wrote:
On 10/10/2011 9:24 PM, Paul Walmsley wrote:
On Fri, 23 Sep 2011, Tero Kristo wrote:
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristot-kri...@ti.com
= fclk_1, .clk = slimbus2_fclk_1 },
{ .role = fclk_0, .clk = slimbus2_fclk_0 },
{ .role = slimbus_clk, .clk = slimbus2_slimbus_clk },
};
Jon,
Do you know if that one is indeed mandatory to use the slimbus IP?
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe
alias.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock2420_data.c | 12
arch/arm/mach-omap2/clock2430_data.c | 12
arch/arm/mach-omap2/clock3xxx_data.c | 12
://gitorious.org/omap-pm/linux.git for_3.2/timer_fixes
Regards,
Benoit
Benoit Cousson (2):
ARM: OMAP2+: clock data: Remove redundant timer clkdev
ARM: OMAP2+: timer: Remove omap_device_pm_latency
arch/arm/mach-omap2/clock2420_data.c | 12
arch/arm/mach-omap2/clock2430_data.c | 12
Remove the structure since a default one is now available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/timer.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm
Hi Tarun,
On 10/4/2011 11:20 PM, Cousson, Benoit wrote:
Hi Tony,
Here is the series to fix the warning and remove the redundant
latency structure that be removed since the timer runtime PM
adaptation was just pulled.
I was just able to test that on OMAP4.
It will be nice if you can test
on IOMMU DT description?
Unless Benoit is, I'll happily pick this up.
Cool, a volunteer... You're in.
Thanks,
Benoit
--
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.kernel.org
as a backend, but the
idea is that for 3.3, we start removing some information from hwmod to
rely on device tree only.
Regards,
Benoit
--
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
cleanup patch on top of your
current branch or by resubmitting the series?
The point is that this branch was already pulled by Arnd in
arm-soc/next/dmtimer feature branch.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
several lines at the same
voltage to spread the current load, assuming it does exist, I'm not sure
to understand the need.
Mark,
What usage do you have in mind for such supply node with several outputs?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap
;
That kind of binding does not really exist in the real world:
vmmc-supply = regulator1 regulator2;
At least not without a power switch in between.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
Second thought... I was too fast to say OK :-)
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
+ if (match) {
+ of_property_read_u32(node, bank-width,bank-width);
Bank width should be u32.
I guess you
Hi Tony,
Please pull the initial OMAP device tree support for v3.2.
Thanks,
Benoit
The following changes since commit 1c3543a34a8ce3e050d7706135bdffd5921c42f5:
Tony Lindgren (1):
Merge branch 'for_3.2/omap_device-2' of
git://github.com/khilman/linux-omap-pm into dt
are available
a negative charge pump to generate -1.9v from 3.8v to
supply the audio power amplifier part in twl6040 for example.
Benoit
--
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.kernel.org
in OMAP dts, in order to build an
omap_device that will be mainly used for the DVFS on the MPU.
And even before DT migration, we used to build statically some
omap_device to represent the various processors in the system (MPU, DSP,
CortexM3...).
Regards,
Benoit
--
To unsubscribe from this list
Hi Rajendra,
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Add
I missed one comment...
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
+Required properties:
+- compatible:
+ - ti,omap2-gpio for OMAP2 and OMAP3 controllers
Would it be more readable to have
ti,omap2-gpio for OMAP2
On 9/27/2011 7:42 AM, Nayak, Rajendra wrote:
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
Add initial device-tree support for twl familly chips.
s/familly/family
Oops.
The current version is missing the regulator entries due
to the lack of DT regulator bindings
Hi Grant, Kevin,
Should I go ahead with this version and repost the series with that
third patch?
Thanks,
Benoit
On 9/27/2011 6:04 PM, Cousson, Benoit wrote:
[...]
From 4403f8a00090e5ea1814a5242947b81c348947a1 Mon Sep 17 00:00:00 2001
From: Benoit Coussonb-cous...@ti.com
Date: Tue, 27
On 9/28/2011 8:23 PM, Scott Wood wrote:
On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
+Required properties:
+- compatible:
+ - ti,omap2-gpio for OMAP2 and OMAP3 controllers
Would
On 9/27/2011 3:46 AM, Grant Likely wrote:
On Thu, Sep 22, 2011 at 10:52:25PM +0200, Benoit Cousson wrote:
[...]
+Required properties:
+- compatible: Every devices present in OMAP SoC should be in the
+ form: ti,XXX
+- ti,hwmods: list of hwmods attached to a device. Must contain at least
Hi Kevin,
Here are a couple of cleanups on top of your for_3.2/omap_device branch.
patches are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/1_omap_device_cleanup
Regards,
Benoit
Changes since v1: http://www.spinics.net/lists/linux-omap/msg55801.html
- Update the 2 patches
pointer inside od,
remove the unneeded helpers, and fold the next patch here]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 36 +
2 files changed, 37 insertions(+), 0
Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4 ++--
1 files changed, 2
Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c | 47
structures.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/omap_device.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap
Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.
Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/devices.c| 46 +++--
arch/arm/mach-omap2/display.c| 11 +
arch
On 9/26/2011 8:32 AM, Nayak, Rajendra wrote:
Hi Benoit,
On Saturday 24 September 2011 01:53 AM, Benoit Cousson wrote:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed
On 9/24/2011 12:58 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110923 12:50]:
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -16,6
On 9/24/2011 1:08 AM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [110923 12:50]:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
I'd suggest
On 9/24/2011 1:21 AM, Grant Likely wrote:
On Fri, Sep 23, 2011 at 10:23:11PM +0200, Benoit Cousson wrote:
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK
on PandaBoard, sdp4430 and BeagleBoard-xM with and without CONFIG_OF.
Comments are welcome.
Regards,
Benoit
Benoit Cousson (13):
hwspinlock: OMAP4: Add spinlock support in DT
gpio/omap: Adapt GPIO driver to DT
arm/dts: OMAP4: Add gpio nodes
irq: Add stub for none DT build in irqdomain.h
i2c
Add a device-tree node for the spinlock.
Remove the static device build code if CONFIG_OF
is set.
Update the hwspinlock driver to use the of_match method.
Add the information in Documentation/devicetree.
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson b-cous
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Add documentation for GPIO properties specific to OMAP.
Remove an un-needed whitespace.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Add the 6 GPIOs controller nodes.
Since the GPIO driver is still under cleanup, a couple of temp
hacks are needed. They will be removed as soon as the driver will
be cleaned.
Remove gpio static device initialisation if DT is populated.
Remove un-needed LF.
Signed-off-by: Benoit Cousson b-cous
Add an empty funtion to allow building a file without
adding some #ifdef CONFIG_OF around of APIs.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Grant Likely grant.lik...@secretlab.ca
---
include/linux/irqdomain.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Alessandro Zummo a.zu...@towertech.it
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c
for the Texas Instruments TWL Integrated Chip.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Graeme Gregory g...@slimlogic.co.uk
Cc: Samuel Ortiz sa...@linux.intel.com
---
.../devicetree/bindings/mfd/twl-familly.txt| 47 +
drivers/mfd/twl-core.c
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts
later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-panda.dts | 44 +
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks ben-li
later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-sdp.dts
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson b
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c
Hi Paul,
On 9/23/2011 1:31 AM, Paul Walmsley wrote:
Hi
On Thu, 22 Sep 2011, Cousson, Benoit wrote:
ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so
why should we use it in this case?
Just for consistency, since the flag isn't defined to be
SYSCONFIG-specific
here:
git://gitorious.org/omap-pm/linux.git for_3.2/3_omap_devicetree
Please note that the Device Tree source files will be stored as well
in the following repository:
git://gitorious.org/omap/devicetree.git master
Comments are welcome.
Regards,
Benoit
Benoit Cousson (11):
OMAP2+: Add SoC
...).
Note: Since reg, irq and dma are provided by hwmod for the
moment, these attributes will not be present at all in DTS
to highlight the gap. They will be added as soon as dma bindings
will be there and drivers will be adapted.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/common.c | 18
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath
Add initial OMAP3 soc file with empty ocp bus.
Based on initial patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55830.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3
Add OMAP3 beagleboard DTS file to use the omap3.dtsi
SoC file.
Add a default bootargs line to allow a boot from RAMDISK
Add memory node information.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 29
Add the SDP/Blaze (Software Development Board) support with
device tree.
That file is based on the omap4-panda.dts.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 29
Still needed to boot until the i2c twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 41
generic DT aware
functions.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |8 ++-
arch/arm/mach-omap2/board-generic.c | 129 ++
2 files changed, 89 insertions(+), 48 deletions(-)
diff
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time.
Add documentation for the l3-noc bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |3
Add nodes for devices used by PM code (mpu, dsp, iva).
Add an empty cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if dt is populated.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kevin Hilman khil...@ti.com
will not have that limitation once we will have migrated
that to DT :-)
Regards,
Benoit
--
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.kernel.org/majordomo-info.html
://gitorious.org/omap-pm/linux.git for_3.2/2_omap_device_dt
It is tested on OMAP4 SDP, Panda and Beagle-xM with and without CONFIG_OF.
Regards,
Benoit
Changes since v1: http://www.spinics.net/lists/linux-omap/msg55814.html
- delete omap_device structure during BUS_NOTIFY_DEL_DEVICE callback
as suggested
-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 177 +
1 files changed, 119 insertions(+), 58 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 54bbe7b
OMAP bindings
needed for device-tree support.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt | 42 ++
arch/arm/plat-omap/omap_device.c | 145
2 files changed, 187
On 9/17/2011 6:05 PM, Grant Likely wrote:
On Fri, Sep 16, 2011 at 04:43:18PM +0200, Benoit Cousson wrote:
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss
On 9/17/2011 6:13 PM, Grant Likely wrote:
On Fri, Sep 16, 2011 at 04:43:19PM +0200, Benoit Cousson wrote:
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from
901 - 1000 of 1897 matches
Mail list logo
