On Thursday, November 18, 2010, Greg KH wrote:
On Wed, Nov 17, 2010 at 09:11:30AM -0700, Grant Likely wrote:
Also, any dependency tracking must work across bus_types. It is not
sufficient to only handle the platform_devices use-case. All bus
types have this need.
Agreed.
I see a
On Tue, Nov 16, 2010 at 07:17:18PM -0500, Cyril Chemparathy wrote:
The ability to wait on multiple devices may come handy. In this
This is essential for any helpers, otherwise we can't cope easily with
mixes of GPIO and power or with regulators from multiple chips (like an
extra DCDC, for
On Tue, Nov 16, 2010 at 07:17:18PM
-0500, Cyril Chemparathy wrote:
The ability to wait on multiple devices may come
handy.
... You mean you'd like to add such a
mechanism to the framework?
Or do you want a driver-specific
mechanism (non-portable)?
If I had
to do that, I'd just use
On Tue, Nov 16, 2010 at 07:17:18PM -0500, Cyril Chemparathy wrote:
On 11/16/2010 02:47 AM, Grant Likely wrote:
On Tue, Nov 16, 2010 at 12:22 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Mon, Nov 15, 2010 at 02:12:06PM -0500, Cyril Chemparathy wrote:
This patch adds an SPI master
On Wed, Nov 17, 2010 at 09:11:30AM -0700, Grant Likely wrote:
To start, I'm not a fan of matching by name. It's fragile because it
makes assumptions about how devices will be names when they actually
appear (ie. Sometimes .id is dynamically assigned). Ideally I'd
prefer to have direct
On 11/17/2010 10:25 AM, David Brownell wrote:
On Tue, Nov 16, 2010 at 07:17:18PM
-0500, Cyril Chemparathy wrote:
The ability to wait on multiple devices may come
handy.
... You mean you'd like to add such a
mechanism to the framework?
Ideally in the framework. This appears to be a
On Wed, Nov 17, 2010 at 09:11:30AM -0700, Grant Likely wrote:
Also, any dependency tracking must work across bus_types. It is not
sufficient to only handle the platform_devices use-case. All bus
types have this need.
Agreed.
I see a few potential approaches.
Option 1: Add a list of
On Tue, Nov 16, 2010 at 12:47:04AM -0700, Grant Likely wrote:
On Tue, Nov 16, 2010 at 12:22 AM, Grant Likely
Instead, it is now incumbent on the board support code to ensure that
any device that depends on another device (including i2c or spi
regulators) will defer registration until the
On Tue, Nov 16, 2010 at 01:45:54PM -0700, Grant Likely wrote:
On Tue, Nov 16, 2010 at 11:34:09AM +, Mark Brown wrote:
You did also say you were going to write helpers to make this easier - I
do fear that we're going to end up with far too much boiler plate code
in machine drivers if we
On 11/16/2010 02:47 AM, Grant Likely wrote:
On Tue, Nov 16, 2010 at 12:22 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Mon, Nov 15, 2010 at 02:12:06PM -0500, Cyril Chemparathy wrote:
This patch adds an SPI master implementation that operates on top of an
underlying TI-SSP port.
This patch adds an SPI master implementation that operates on top of an
underlying TI-SSP port.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/mfd/Kconfig| 10 +
drivers/mfd/Makefile |1 +
drivers/mfd/ti-ssp-spi.c | 402
On 11/16/2010 08:12 AM, Cyril Chemparathy wrote:
This patch adds an SPI master implementation that operates on top of an
underlying TI-SSP port.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/mfd/Kconfig| 10 +
drivers/mfd/Makefile |1 +
On Mon, Nov 15, 2010 at 02:12:06PM -0500, Cyril Chemparathy wrote:
This patch adds an SPI master implementation that operates on top of an
underlying TI-SSP port.
Signed-off-by: Cyril Chemparathy cy...@ti.com
[...]
+static int __init ti_ssp_spi_init(void)
+{
+ return
13 matches
Mail list logo
