On Thu, Jul 21, 2011 at 04:52:17PM -0700, Kevin Hilman wrote:
The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: Kevin Hilman khil...@ti.com
FWIW, all 6 of these cleanups
Hi,
Shawn Guo writes:
On Mon, Jul 11, 2011 at 09:15:34AM +0200, Lothar Waßmann wrote:
Hi,
Shawn Guo writes:
spi_imx_devtype_data has already been driver private data. There is
really no need to make a copy in spi_imx_data. Instead, a reference
pointer works perfectly fine.
Hi,
Shawn Guo writes:
spi_imx_devtype_data has already been driver private data. There is
really no need to make a copy in spi_imx_data. Instead, a reference
pointer works perfectly fine.
You obviously overlooked, that the copy is done on purpose to keep
only the data that is actually
On 7/21/2011 2:39 PM, Felipe Balbi wrote:
Hi,
On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote:
On 7/20/2011 3:04 AM, Grant Likely wrote:
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote:
* Grant Likelygrant.lik...@secretlab.ca [110716 22:08]:
The way I see it,
Board code should not touch omap_device internals. To get the MPU/IVA devices,
use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 23 ++-
1 files changed, 10
Here's a first whack, proof-of-concept on how we could start to
decouple the platform_device from an omap_device.
The main RFC is in the last patch, and everything leading up to it are
misc. omap_device cleanups that make the last patch cleaner and
clearer. It's really the last patch that does
Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.
This patch uses devres to allocate and attach the omap_device to the
struct device, so finding an omap_device from a struct device means
All of the device init and device driver interaction with omap_device
is done using platform_device pointers. To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.
All current users of the omap_device pointer were only using it to get
at
The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 22 +++---
1 files changed, 11
The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.
Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing to_platform_device()
used when getting a platform_device pointer
For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros. Use
them instead of manual use of container_of().
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/mcbsp.c |6 +++---
1 files changed, 3
Grant Likely grant.lik...@secretlab.ca writes:
[...]
The way I see it, you've got two options:
1) modify the of_platform_bus_create() to call some kind of
of_platform_bus_create_omap() for devices that match ti,omap3-device
or something.
2) Leave of_platform_bus_create(), and instead us a
Hello,
(These two issues occured on 3.0-rc7-rt0, I think they apply to
mainline, too.)
On Fri, Jul 22, 2011 at 07:43:34AM +0200, hermann wrote:
well, I run into 2 ops, witch, I guess not related to the rt patch.
first one was with CONFIG_SENSORS_LTC4245, module build stage 2 failed
with
* G, Manjunath Kondaiah manj...@ti.com [110719 09:59]:
On Tue, Jul 19, 2011 at 2:00 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
No, the i2c bus node should still appear in the SoC .dtsi file. If a
board doesn't use a particular i2c bus, then the board.dts file can
add a status =
On Thu, Jul 21, 2011 at 04:52:11PM -0700, Kevin Hilman wrote:
The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.
Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing
Add device tree probe support for Samsung's s3c2410 i2c driver.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/i2c/samsung-i2c.txt| 44 +
drivers/i2c/busses/i2c-s3c2410.c | 51 +++-
2 files
This patchset adds device tree support for Samsung's I2C driver. The
Exynos4 DT enabled machine is updated to support device tree based probe
for I2C instance 0 and 1.
Changes since v1:
- Addressed all comments from Grant Likely
- s3c24xx_i2c_is2440 function is simpler now.
-
On Thu, Jul 21, 2011 at 03:46:02PM +0100, Daniel Drake wrote:
Hi,
We're working on enabling the HDD LED on the XO-1.5 laptop using
gpio-leds and its automatic interaction with the device tree. I have
it working locally, but there is something not quite right.
We have modified the device
Hi Shawn,
It adds device tree probe support for imx2_wdt driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Wim Van Sebroeck w...@iguana.be
Patch added to linux-2.6-watchdog-next.
Kind regards,
Wim.
On 22 July 2011 18:35, Grant Likely grant.lik...@secretlab.ca wrote:
of_platform_bus_probe() from the root of the tree is the wrong
approach for registering 'deep' devices. of_platform_bus_probe() only
knows how to deal with platform_devices. The moment something
non-trivial appears in
we have a special section for const data
which is only needed during init, that's
__initconst. Use that instead of __initdata
which is for non-const data.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-igep0020.c|2 +-
that should be the approved way of calculating
the size of resources. No functional changes.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/of/address.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/of/address.c
Hi Sergei,
Sergei Shtylyov sshtyl...@mvista.com writes:
On 22-07-2011 3:52, Kevin Hilman wrote:
For converting from struct device to platform_device, and from
platform_device to struct device,
You mean from platform_device to omap_device?
Yes indeed, thanks. Updated patch below (only
23 matches
Mail list logo
