On Tue, Jun 21, 2011 at 10:18:28AM +0300, Ohad Ben-Cohen wrote:
From: Guzman Lugo, Fernando fernando.l...@ti.com
Add remoteproc implementation for OMAP4, so we can load the M3 and DSP
remote processors.
Based on code by Hari Kanigeri h-kanige...@ti.com
While this code is functional, and
On Tue, Jun 21, 2011 at 10:18:33AM +0300, Ohad Ben-Cohen wrote:
Add a virtio-based IPC bus, which enables kernel users to communicate
with remote processors over shared memory using a simple messaging
protocol.
Assign a local address for every local endpoint that is created,
and bind it to
On Mon, Jun 27, 2011 at 09:52:30PM +, Grosen, Mark wrote:
From: Grant Likely
Sent: Monday, June 27, 2011 1:50 PM
Grant, thanks for the feedback. I'll try to answer one of your
questions below and leave the rest for Ohad.
Mark
+Every remoteproc implementation must provide
On Mon, Jun 27, 2011 at 5:29 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jun 27, 2011 at 02:49:58PM -0600, Grant Likely wrote:
+struct {
+ char magic[4] = { 'R', 'P', 'R', 'C' };
+ u32 version;
+ u32 header_len;
+ char header
On Tue, Jun 21, 2011 at 8:20 AM, Arnd Bergmann a...@arndb.de wrote:
Hi Ohad,
On Tuesday 21 June 2011, Ohad Ben-Cohen wrote:
This patch set adds a generic AMP/IPC framework which makes it possible to
control (power on, boot, power off) and communicate (simply send and receive
messages) with
On Wed, Jun 15, 2011 at 01:40:45PM -0700, Ambresh K wrote:
From: Ambresh K ambr...@ti.com
If gpio pins from bank[2-5] are marked as wakeup enable and if the wake is
through gpio IO pad wakeup, then that wakeup gpio interrupt is lost.
In the current implementation, GPIO driver stores the
On Thu, Jun 16, 2011 at 09:07:39AM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote:
Start moving SoC-specific register handling out of the driver by passing
in register offsets in via platform data
On Thu, Jun 16, 2011 at 11:16:38AM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Thu, Jun 16, 2011 at 09:07:39AM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote
On Tue, Jun 07, 2011 at 05:08:27PM -0700, Kevin Hilman wrote:
Grant,
Here's a small set of OMAP GPIO fixes for v3.0-rc.
Thanks,
Kevin
Merged, thanks.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
On Tue, Jun 7, 2011 at 10:04 AM, Kevin Hilman khil...@ti.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Mon, Jun 6, 2011 at 5:18 PM, Kevin Hilman khil...@ti.com wrote:
Hi Colin,
Colin Cross ccr...@android.com writes:
Setting the IRQWAKEN bit was overwriting previous IRQWAKEN
these two to send on to Linus
Acked-by: Grant Likely grant.lik...@secretlab.ca
Or, if they are only gpio fixes, then I'd also be happy to get a git
pull req for the changes. :-)
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
On Fri, May 27, 2011 at 1:35 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote:
Move OMAP GPIO driver to drivers/gpio. Builds whenever
CONFIG_ARCH_OMAP=y.
Signed-off-by: Kevin Hilman khil...@ti.com
Patch unfortunately doesn't
On Fri, May 27, 2011 at 09:04:37AM -0700, Kevin Hilman wrote:
Kevin Hilman khil...@ti.com writes:
[...]
OK, I rebased onto RMK's for-linus branch (already pulled by Linus),
which contained some other changes touching gpio.c.I also s/_/-/ in
the filename.
Below is pull
On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote:
Start moving SoC-specific register handling out of the driver by passing
in register offsets in via platform data.
Also, move OMAP1 MPUIO IRQ handling over to genric IRQ chip.
Applies on top of Tony's for-next branch (which
On Thu, May 12, 2011 at 02:57:04AM +0200, Linus Walleij wrote:
2011/5/4 Tony Lindgren t...@atomide.com:
* Linus Walleij linus.wall...@linaro.org [110504 00:37]:
2011/5/3 Kevin Hilman khil...@ti.com:
Are you OK with a move of the current OMAP GPIO drivers (rather ugly)
into
On Thu, May 12, 2011 at 11:42:39AM +0200, Kevin Hilman wrote:
Linus Walleij linus.wall...@linaro.org writes:
[...]
For TI I guess this currently means you simply cannot work
on GPIO stuff until you know where to go with it unless you
allow the OMAP GPIO authors to keep churning in
On Fri, Apr 15, 2011 at 9:26 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Apr 15, 2011 at 04:40:00PM +0200, Arnd Bergmann wrote:
On Friday 15 April 2011 15:39:55 Rob Herring wrote:
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
(platform_bus_set_pm_ops()), this patch moves the OMAP runtime PM
implementation over to using device power domains.
Since OMAP is the only user of platform_bus_set_pm_ops(), that
interface can be removed (and will be in a forthcoming patch.)
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Magnus
On Mon, Mar 21, 2011 at 04:27:30PM +0200, Jarkko Nikula wrote:
Commit adef658 spi/omap_mcspi: catch xfers of non-multiple SPI word size
broke the transmission of last word in cases where access is multiple of
word size and word size is 16 or 32 bits.
Fix this by replacing the test c
this in the current McSPI
initialization code.
On Thu, 03 Mar 2011 14:42:07 -0700, Grant Likely grant.lik...@secretlab.ca
wrote:
The spi_master platform device is registered somewhere in the
inappropriate support code. You need to arrange to make sure the
correct pdata is attached to it when it gets
On Sun, Mar 13, 2011 at 03:05:19PM -0400, Ben Gamari wrote:
Many applications require more chip select lines than the board or
processor allow. Introduce a mechanism to allow use of GPIO pins as
chip select lines with the McSPI controller. To use this functionality,
one simply provides a table
On Mon, Mar 14, 2011 at 10:06:40PM -0400, Ben Gamari wrote:
On Mon, 14 Mar 2011 13:27:18 -0600, Grant Likely grant.lik...@secretlab.ca
wrote:
What if the board wanted to use both the native SPI ss line as well as
one or more GPIOs? You probably want to reserve cs0 for the native
gpio
On Mon, Mar 14, 2011 at 10:22:31PM -0400, Ben Gamari wrote:
On Mon, 14 Mar 2011 13:25:36 -0600, Grant Likely grant.lik...@secretlab.ca
wrote:
I see two solutions:
1) platform code registers a bus notifier so that it gets called back
before the device gets bound to a driver. Then it can
On Fri, Feb 25, 2011 at 04:55:11PM +0100, Michael Jones wrote:
If an SPI access was not a multiple of the SPI word size,
the while() loop would spin and the rx/tx ptrs would be incremented
indefinitely.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
Applied, thanks.
g.
---
On Thu, Feb 24, 2011 at 04:13:31PM +0200, Hannu Heikkinen wrote:
Off-by-one error, gave erroneous divisor value 16 if speed_hz is over zero but
less than OMAP2_MCSPI_MAX_FREQ / (1 15), that is, [1..1463].
Also few overly complex bit shifts in divisor fixed.
Also one dev_dgb line fixed,
On Thu, Feb 24, 2011 at 9:00 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, Feb 24, 2011 at 04:13:31PM +0200, Hannu Heikkinen wrote:
Off-by-one error, gave erroneous divisor value 16 if speed_hz is over zero
but
less than OMAP2_MCSPI_MAX_FREQ / (1 15), that is, [1..1463].
Also
On Thu, Feb 24, 2011 at 09:31:33PM +0200, hann...@iki.fi wrote:
From: Hannu Heikkinen ext-hannu.m.heikki...@nokia.com
Off-by-one error, gave erroneous divisor value 16 if speed_hz is over zero but
less than OMAP2_MCSPI_MAX_FREQ / (1 15), that is, [1..1463].
Also few overly complex bit
On Fri, Dec 24, 2010 at 01:05:56AM -0500, Ben Gamari wrote:
On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely grant.lik...@secretlab.ca
wrote:
On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
I understand your concerns, but I'm not sure how to satisfy them without
crippling
.
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
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
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
:
- 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
/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
);
+ 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
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
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 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 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, 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, 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 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 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
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
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
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
}
} 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 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
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
. 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 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
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 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
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, 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
://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
);
+ 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
-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
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
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
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
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 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
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
301 - 399 of 399 matches
Mail list logo
