On Tue, Nov 16, 2010 at 11:34:09AM +, Mark Brown wrote:
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
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 +
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 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
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.
Signed-off-by: Cyril Chemparathy cy...@ti.com
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, 2010-11-16 at 00:22 -0700, Grant Likely wrote:
After discussions about device init dependencies at plumbers, and
since this is the first SPI device driver I've reviewed since that
dicussion, this driver gets to be the first to implement the proposed
policy. :-)
Change this to
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 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 11/17/2010 11:11 AM, 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 references (ie.
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 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.
16 matches
Mail list logo