On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. Since we don't have an OMAP-specific bus, override
the runtime PM hooks for the platform_bus for the OMAP specific
. It is certainly an area for more research
and experimental implementations.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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
On Tue, Aug 3, 2010 at 5:56 PM, Greg KH gre...@suse.de wrote:
On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct
platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
On Thu, Aug 5, 2010 at 9:57 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Patrick Pannuto ppann...@codeaurora.org writes:
On 08/04/2010 05:16 PM, Kevin Hilman wrote:
Patrick Pannuto ppann...@codeaurora.org writes:
Inspiration for this comes from:
On Fri, Aug 6, 2010 at 8:27 AM, Greg KH gre...@suse.de wrote:
On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote:
(On that point Greg, what is the reason for even having the
/sys/devices/platform/ parent? Why not just let the platform devices
sit at the root of the device tree
On Fri, Aug 6, 2010 at 5:46 PM, Greg KH gre...@suse.de wrote:
On Fri, Aug 06, 2010 at 09:12:27AM -0600, Grant Likely wrote:
On Fri, Aug 6, 2010 at 8:27 AM, Greg KH gre...@suse.de wrote:
On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote:
(On that point Greg, what is the reason
On Thu, Aug 5, 2010 at 7:25 PM, Patrick Pannuto ppann...@codeaurora.org wrote:
On 08/05/2010 04:16 PM, Grant Likely wrote:
The relevant question before going down this path is, Is the
omap/sh/other-soc behaviour something fundamentally different from the
platform bus? Or is it something
On Sat, Aug 7, 2010 at 12:35 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, Aug 6, 2010 at 5:46 PM, Greg KH gre...@suse.de wrote:
That would be nice, but take your standard PC today:
ls /sys/devices/platform/
Fixed MDIO bus.0 i8042 pcspkr power serial8250 uevent
}
} while (c);
}
--
1.7.1
--
balbi
DefectiveByDesign.org
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Mon, Aug 9, 2010 at 11:21 PM, Felipe Balbi felipe.ba...@nokia.com wrote:
Hi,
On Mon, Aug 09, 2010 at 03:22:31PM +0200, ext Grant Likely wrote:
It didn't get sent to the spi-devel-general list, so it didn't get
picked up by patchwork and wasn't there for me to pick up when I
On Mon, Aug 09, 2010 at 01:36:18PM +0300, Felipe Balbi wrote:
On Thu, Jun 03, 2010 at 01:09:01PM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
From: Felipe Balbi felipe.ba...@nokia.com
dev_vdbg() is only compiled when VERBOSE is defined, so
there's no need to wrap dev_dbg() on #ifdef
/omap_spi_100k.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
[...]
Adding another name to the list.
This patch has been in my next-spi branch for a while, and I have a
pull request pending out to Linus.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd
support.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Hemanth V heman...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/devices.c | 5 +
arch/arm/plat-omap/include/plat/mcspi.h | 29
On Fri, Aug 13, 2010 at 4:25 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, Aug 13, 2010 at 7:58 AM, Govindraj.R govindraj.r...@ti.com wrote:
+ *
+ * @fifo_depth when set to non zero values enables FIFO. fifo_depth
+ * should be set as a multiple of buffer size used for read/write
be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.
Auto chip select mode can be enabled by setting force_cs_mode
to zero
Hi Hemanth, comments below.
Cc: Tony Lindgren t...@atomide.com
Cc: Grant Likely grant.lik...@secretlab.ca
-omap/include/plat/mcspi.h | 27 +++
drivers/spi/omap2_mcspi.c | 273
+---
8 files changed, 1034 insertions(+), 333 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line
= THIS_MODULE,
+ .pm = omap_mcspi_dev_pm_ops,
nit: Unrelated whitespace changes.
},
.remove = __exit_p(omap2_mcspi_remove),
};
-
static int __init omap2_mcspi_init(void)
{
omap2_mcspi_wq = create_singlethread_workqueue(
--
1.6.3.3
--
Grant
CONFIG_PM_RUNTIME is unset.
Once you've fixed that you can add my a-b line:
Acked-by: Grant Likely grant.lik...@secretlab.ca
I think this should go via Greg's tree to avoid ordering issues.
---
NOTE: this depends on the driver core patch from me:
[PATCH v2] driver core: platform_bus: allow
.
This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the runtime PM API to manage clocks.
OMAP1 compile fixes Manjunatha GK manj...@ti.com
Cc: Manjunatha GK manj...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
Acked-by: Grant Likely grant.lik
On Wed, Sep 08, 2010 at 10:24:48AM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote:
+ omap_pm-runtime_suspend = omap_pm_runtime_suspend;
+ omap_pm-runtime_resume = omap_pm_runtime_resume
On Wed, Sep 08, 2010 at 10:08:42AM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
Implement the new runtime PM framework as a thin layer on top
On Fri, Sep 10, 2010 at 03:15:35PM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com wrote
On Mon, Oct 18, 2010 at 1:44 AM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Simon Que s...@ti.com
Add driver for OMAP's Hardware Spinlock module.
The OMAP Hardware Spinlock module, initially introduced in OMAP4,
provides hardware assistance for synchronization between the
multiple
appropriate here.
I would've suspected that any users of hwspinlocks will be dependent on
drivers for the other cores (e.g. syslink) which would likely be
initialized much later.
On that note, is there any reason why this file cannot be selected as a module?
g.
--
Grant Likely, B.Sc., P.Eng
On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Oct 19, 2010 at 7:03 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
+postcore_initcall(hwspinlocks_init);
Any reason this needs to be a postcore_initcall? Are there users of
hwspinlocks this early in boot?
On Wed, Oct 20, 2010 at 04:09:22PM +0200, Ohad Ben-Cohen wrote:
On Wed, Oct 20, 2010 at 1:12 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen o...@wizery.com wrote:
...
i2c-omap, which is subsys_initcall (the I2C bus is shared between
On Wed, Oct 20, 2010 at 04:38:32PM +0200, Ohad Ben-Cohen wrote:
On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
And to allow early board code to reserve specific hwspinlock numbers
for predefined use-cases, we probably want to be before arch_initcall.
On Tue, Oct 19, 2010 at 06:03:27PM +0800, Jason Wang wrote:
In the TX_ONLY transfer, the SPI controller also receives data
simultaneously and saves them in the rx register. After the TX_ONLY
transfer, the rx register will hold the random data received during
the last tx transaction.
If the
On Wed, Oct 20, 2010 at 09:23:57AM -0700, Tony Lindgren wrote:
* Ilkka Koskinen ilkka.koski...@nokia.com [101019 06:55]:
In case of TX only with DMA, the driver assumes that the data
has been transferred once DMA callback in invoked. However,
SPI's shift register may still contain data.
On Fri, Oct 22, 2010 at 09:56:13AM -0700, Tony Lindgren wrote:
* Ohad Ben-Cohen o...@wizery.com [101020 12:12]:
On Wed, Oct 20, 2010 at 8:37 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Let's take the i2c-omap for example.
It sounds like it must have a predefined hwspinlock,
On Wed, Nov 10, 2010 at 11:32:59AM +0100, Gregory CLEMENT wrote:
When SPI wake up from OFF mode, CS is in the wrong state: force it
to the inactive state.
During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver
On Wed, Nov 10, 2010 at 11:32:54AM +0100, Gregory CLEMENT wrote:
Some spi masters need to do some actions when system is going to suspend
or when it will be resumed.
Spi driver offer possibility to handle suspend and resume only for device.
Spi master will do its suspend actions after the
On Wed, Nov 10, 2010 at 9:41 AM, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
On 11/10/2010 04:57 PM, Grant Likely wrote:
On Wed, Nov 10, 2010 at 11:32:59AM +0100, Gregory CLEMENT wrote:
When SPI wake up from OFF mode, CS is in the wrong state: force it
to the inactive state
On Fri, Nov 12, 2010 at 4:44 PM, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
We notice that when system wake up from OFF mode, then CS is in inactive
state until the first SPI transfer.
For our design it lead to some conflict on this I/O.
Inactive state for CS when there is no
On Sat, Nov 13, 2010 at 12:44:42AM +0100, Gregory CLEMENT wrote:
When SPI wake up from OFF mode, CS is in the wrong state: force it
to the inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver
On Thu, Nov 25, 2010 at 9:59 PM, Olof Johansson o...@lixom.net wrote:
On Tue, Nov 23, 2010 at 05:38:57PM +0200, Ohad Ben-Cohen wrote:
+#define pr_fmt(fmt) %s: fmt, __func__
Not used.
pr_fmt() is a magic #define that changes the behaviour of the pr_*()
macros. See include/linux/kernel.h
);
+ MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
+ mcspi_write_chconf0(spi, l);
+ }
}
static void omap2_mcspi_set_master_mode(struct spi_master *master)
--
1.7.1
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from
On Wed, Nov 24, 2010 at 04:49:47PM -0800, Kevin Hilman wrote:
Gregory CLEMENT gregory.clem...@free-electrons.com writes:
As request by Grant Likely, there is no more cover letter. Full changelog
is following.
I am still reluctant to add this changelog in the patch description
On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari bgamari.f...@gmail.com wrote:
On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely grant.lik...@secretlab.ca
wrote:
On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari bgamari.f...@gmail.com wrote:
This mechanism is in large part stolen from the s3c64xx-spi
On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely grant.lik...@secretlab.ca
wrote:
On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari bgamari.f...@gmail.com wrote:
The reason I left this up to the board is it's easy to foresee cases
/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each
On Wed, Dec 29, 2010 at 12:57:35PM +0530, Govindraj wrote:
Hi Grant,
On Wed, Dec 1, 2010 at 7:31 PM, Govindraj.R govindraj.r...@ti.com wrote:
Changes invloves:
1) Addition of hwmod data for omap2/3/4.
1) McSPI driver hwmod adaptation with cleanup of base address
:
- Rebase on linus/master (after 2.6.37-rc1)
- Do some clean-up and fix indentation on both patches
- Add more explanations for patch 2
* Change from v2 to v3:
- Use directly resume function of spi_master instead of using function
- from spi_device as Grant Likely pointed it out
On Wed, Dec 01, 2010 at 07:31:22PM +0530, Govindraj.R wrote:
From: Charulatha V ch...@ti.com
Update the 2430 hwmod data file with McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Hmmm; this patch is virtually identical to the first
On Wed, Dec 01, 2010 at 07:31:38PM +0530, Govindraj.R wrote:
From: Benoit Cousson b-cous...@ti.com
Update omap4 hwmod file with McSPI info.
Ditto here. A lot of this data is identical to the OMAP2 data from
patches 1 2. It looks like this should be shared.
g.
Signed-off-by: Benoit
On Wed, Dec 01, 2010 at 07:32:00PM +0530, Govindraj.R wrote:
From: Charulatha V ch...@ti.com
Cleans up all base address definitions for omap_mcspi
and adapts the device registration and driver to hwmod framework.
Changes involves:
1) Removing all base address macro defines.
2) Using
the original).
Or if you want to pick it up:
Acked-by: Grant Likely grant.lik...@secretlab.ca
Nothing in my tree touches omap_mcspi.c for this merge window, so
there won't be a merge conflict (I'm assuming you want this fix to go
into 2.6.28).
g.
* Russell King - ARM Linux li...@arm.linux.org.uk
.
Changes from v2:
---
1) Fixing minor comments and adding ack from Grant Likely.
https://patchwork.kernel.org/patch/371321/
https://patchwork.kernel.org/patch/371331/
Hi Govindraj,
My comment still stands that it looks like a lot of duplicate data is
being generated
it means that my pull requests are less obvious for
Linus and there is greater chance of conflict.
But if you still really want me to merge it through my tree, (or if
getting the patches out of order will break things) then I'll pick it
up. Just let me know.
g.
--
Grant Likely, B.Sc., P.Eng
On Tue, Feb 9, 2010 at 4:07 PM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [100209 14:38]:
On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote:
* Hemanth V heman...@ti.com [100203 02:19]:
From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon
On Tue, Feb 16, 2010 at 7:38 AM, Hemanth V heman...@ti.com wrote:
* Tony Lindgren t...@atomide.com [100209 15:03]:
* Grant Likely grant.lik...@secretlab.ca [100209 14:38]:
On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote:
* Hemanth V heman...@ti.com [100203 02:19
specified\n);
+ }
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
--
1.5.6.3
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
on this
one. Thoughts?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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
On Thu, Feb 18, 2010 at 10:09 AM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [100218 08:26]:
On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote:
* Hemanth V heman...@ti.com [100203 02:19]:
From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon
in linux-next
by that time.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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
On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [091130 09:01]:
http://www.elinux.org/Device_Trees
I expect to have my prototype ready for review mid-January, and most
of the common code should be either merged or queued up
On Wed, Dec 2, 2009 at 8:53 AM, Olof Johansson o...@lixom.net wrote:
On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote:
Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
connections in the device tree:
Documentation/powerpc/dts-bindings/gpio/gpio.txt
On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson o...@lixom.net wrote:
On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
Ah, you're talking about pin muxing configuration, right? Yes, that
GPIO binding deals with controllers, not pin mux. Pin mux is very
much an SoC specific thing
transfers altogether, since they are broken, and
thus, obviously, unused.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list
-dma_tx_channel != -1) {
+ omap_free_dma(mcspi_dma-dma_tx_channel);
+ mcspi_dma-dma_tx_channel = -1;
+ }
}
}
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line
);
+ mcspi_dma-dma_tx_channel = -1;
+ }
}
}
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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
://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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
On Fri, Jun 25, 2010 at 12:04 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Implement the new runtime PM framework as a thin layer on top of the
omap_device
On Fri, Jun 25, 2010 at 2:06 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jun 25, 2010 at 09:26:43AM -0600, Grant Likely wrote:
This approach is also not multiplatform friendly (cc'ing Eric and
Nicolas who are working on ARM multiplatform). It won't work for
building
On Fri, Jun 25, 2010 at 3:58 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
Yes, I've got patches which merge of_platform_bus_type with the
platform bus. This was an easy decision to make because the
of-specific bits (specifically, matching
On Fri, Jun 25, 2010 at 4:46 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
Another way to look at the problem is that these runtime
customizations are kind of a property of the parent device (the bus,
not the bus_type). Would it make sense
On Mon, Jun 28, 2010 at 2:49 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Jun 25, 2010 at 4:46 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
Another way to look at the problem
On Mon, Jun 28, 2010 at 4:27 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
[...]
This affects many aspects of all drivers, from register and probe (for
early devices/drivers too!) to all the plaform_get_resource() usage, all
of which
On Thu, Feb 18, 2010 at 11:29 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Thu, Feb 18, 2010 at 10:09 AM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [100218 08:26]:
On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote:
* Hemanth V
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
I think Uwe could provide his script and add it to the kernel tree.
Then all architectures could benefit from it. Having the defconfig
2010/7/13 Uwe Kleine-König u.kleine-koe...@pengutronix.de:
Hi
On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
I think
On Wed, Aug 24, 2011 at 03:09:11PM +0200, Benoit Cousson wrote:
Add documentation for the OMAP4 processors bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14
On Wed, Aug 24, 2011 at 03:09:13PM +0200, Benoit Cousson wrote:
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
.../bindings/hwspinlock/omap-spinlock.txt |5 +
1 files changed, 5
On Thu, Sep 08, 2011 at 11:59:18PM +0200, Cousson, Benoit wrote:
On 9/8/2011 8:01 PM, Grant Likely wrote:
On Wed, Aug 24, 2011 at 03:09:07PM +0200, Benoit Cousson wrote:
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time
On Wed, Aug 24, 2011 at 03:09:08PM +0200, Benoit Cousson wrote:
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if CONFIG_OF is defined.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh
On Wed, Aug 24, 2011 at 03:09:14PM +0200, 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.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely
On Fri, Sep 09, 2011 at 02:30:24AM +0200, Cousson, Benoit wrote:
On 9/8/2011 8:09 PM, Grant Likely wrote:
+- compatible : Should be:
+ - ti,ivahd, ti,iva for OMAP4
+ - ti,iva2, ti,iva for OMAP3
+ - ti,iva1, ti,iva for OMAP2
Again, be specific to the instantiation and encode the omap
On Fri, Sep 09, 2011 at 02:10:08AM +0200, Cousson, Benoit wrote:
On 9/8/2011 8:03 PM, Grant Likely wrote:
On Wed, Aug 24, 2011 at 03:09:08PM +0200, Benoit Cousson wrote:
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if CONFIG_OF is defined
On Mon, Aug 29, 2011 at 09:41:47PM +0300, Luciano Coelho wrote:
---
@@ -417,7 +417,6 @@ config GPIO_TIMBERDALE
config GPIO_RDC321X
tristate RDC R-321x GPIO support
depends on PCI
- select MFD_SUPPORT
select MFD_CORE
select MFD_RDC321X
help
diff --git
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
Pass regulator_init_data information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Add documentation for TWL regulator specific
On Thu, Sep 15, 2011 at 02:46:18PM +0100, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
+ xyz-regulator: regulator@0 {
+
On Thu, Sep 15, 2011 at 04:52:01PM +0530, Rajendra Nayak wrote:
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak rna...@ti.com
---
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
The helper routine defined here (of_get_fixed_voltage_config) can
be used to extract information about fixed regulators (which are not
software controlable) from device tree.
Add documenation about additional bindings for fixed
On Thu, Sep 15, 2011 at 02:54:16PM +0100, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:05PM +0530, Rajendra Nayak wrote:
regulator = regulator1,regulator2;
regulator-names = supply1,supply2;
};
This syntax is really painful - we're relying on keeping two
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 is still the same, but
the omap_device_alloc
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 the device-tree are overloaded.
DT does
On Sat, Sep 17, 2011 at 05:27:01PM +0100, Russell King - ARM Linux wrote:
On Sat, Sep 17, 2011 at 10:05:14AM -0600, Grant Likely wrote:
+static struct omap_device *omap_device_alloc(struct platform_device
*pdev,
+ struct omap_hwmod **ohs, int oh_cnt
...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-panda.dts
diff --git a/arch
: Grant Likely grant.lik...@secretlab.ca
Cc: Kevin Hilman khil...@ti.com
Series looks good to me on brief review.
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 ++
Documentation/devicetree/bindings/arm/omap/iva.txt | 19
On Fri, Sep 23, 2011 at 04:12:08PM -0700, Tony Lindgren wrote:
* Benoit Cousson b-cous...@ti.com [110923 12:50]:
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.
That sounds OK to me for
directly.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann a...@arndb.de
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/include/asm/device.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch
On Thu, Sep 22, 2011 at 10:52:25PM +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 the device-tree are overloaded.
DT does
On Mon, Sep 26, 2011 at 06:50:20PM +0200, Benoit Cousson wrote:
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:
On Wed, Sep 28, 2011 at 10:47:32AM -0700, Kevin Hilman wrote:
Cousson, Benoit b-cous...@ti.com writes:
Hi Grant, Kevin,
Should I go ahead with this version and repost the series with that
third patch?
Fine with me.
Grant let me know if you prefer if I merge it (with your ack) with
On Tue, Sep 27, 2011 at 03:42:49PM +0530, Rajendra Nayak wrote:
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak rna...@ti.com
---
On Tue, Sep 27, 2011 at 03:42:43PM +0530, Rajendra Nayak wrote:
Hi Mark, Grant,
This is a respin of my RFC series I posted sometime back
and is now based on top of the latest omap i2c-twl support
series posted by Benoit
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
some
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+GFP_KERNEL);
+ if (!init_data)
+
1 - 100 of 399 matches
Mail list logo
