dt: omap hwmod-dt binding and omap3 i2c1 dt support
Subsystems (9)
cover dt: omap hwmod-dt binding and omap3 i2c1 dt support
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/
Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from omap_device.
[There is latest version posted which will be rebased later]
Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely <[email protected]>
However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call.
Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week.
git://git.secretlab.ca/git/linux-2.6.git
Branch: devicetree/test-3.0
G, Manjunath Kondaiah (6):
dt: omap: prepare hwmod to support dt
dt: Add pd_size to AUXDATA structure
dt: omap3: add soc file for handling i2c controllers
dt: omap3: beagle board: set clock freq for i2c devices
dt: omap3: add generic board file for dt support
dt: omap3: enable dt support for i2c1 controller
Kevin Hilman (7):
OMAP: omap_device: replace _find_by_pdev() with to_omap_device()
OMAP: omap_device: replace debug/warning/error prints with dev_*
macros
OMAP3: beagle: don't touch omap_device internals
OMAP: McBSP: use existing macros for converting between devices
OMAP: omap_device: remove internal functions from omap_device.h
OMAP: omap_device: when building return platform_device instead of
omap_device
ARM: platform_device: pdev_archdata: add omap_device pointer
Tony Lindgren (1):
omap2+: Use Kconfig symbol in Makefile instead of obj-y
arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +-- arch/arm/boot/dts/omap3-beagle.dts | 18 +++- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++ arch/arm/include/asm/device.h | 5 + arch/arm/mach-omap2/Kconfig | 11 ++ arch/arm/mach-omap2/Makefile | 77 ++++++------- arch/arm/mach-omap2/board-omap3-dt.c | 93 +++++++++++++++ arch/arm/mach-omap2/board-omap3beagle.c | 40 ++----- arch/arm/mach-omap2/devices.c | 44 ++++---- arch/arm/mach-omap2/display.c | 6 +- arch/arm/mach-omap2/dma.c | 16 ++-- arch/arm/mach-omap2/gpio.c | 8 +- arch/arm/mach-omap2/hsmmc.c | 8 +- arch/arm/mach-omap2/hwspinlock.c | 8 +- arch/arm/mach-omap2/mcbsp.c | 8 +- arch/arm/mach-omap2/pm.c | 8 +- arch/arm/mach-omap2/serial.c | 12 +- arch/arm/plat-omap/i2c.c | 8 +- arch/arm/plat-omap/include/plat/omap_device.h | 17 ++- arch/arm/plat-omap/mcbsp.c | 6 +- arch/arm/plat-omap/omap_device.c | 150 ++++++++++++++++--------- drivers/i2c/busses/i2c-omap.c | 23 ++++- drivers/of/platform.c | 41 +++++++ include/linux/of_platform.h | 5 + 24 files changed, 469 insertions(+), 216 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
PATCH 1/14 OMAP: omap_device: replace _find_by_pdev() with to_omap_device()
From: Kevin Hilman <[email protected]>
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 from a struct device pointer.
--- arch/arm/plat-omap/omap_device.c | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-)
arch/arm/plat-omap/omap_device.c +5 -10
@@ -236,11 +236,6 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)return 0 ; } -static inline struct omap_device *_find_by_pdev (struct platform_device *pdev) -{ - return container_of(pdev, struct omap_device, pdev); -} -/** * _add_optional_clock_clkdev - Add clkdev entry for hwmod optional clocks * @od: struct omap_device *od
@@ -316,7 +311,7 @@ u32 omap_device_get_context_loss_count(struct platform_device *pdev)struct omap_device *od;u32 ret =0 ; - od =_find_by_pdev (pdev); + od =to_omap_device (pdev);if (od->hwmods_cnt) ret =omap_hwmod_get_context_loss_count (od->hwmods[0 ]);
@@ -611,7 +606,7 @@ int omap_device_enable(struct platform_device *pdev)int ret;struct omap_device *od; - od =_find_by_pdev (pdev); + od =to_omap_device (pdev);if (od->_state ==OMAP_DEVICE_STATE_ENABLED ) { WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
@@ -650,7 +645,7 @@ int omap_device_idle(struct platform_device *pdev)int ret;struct omap_device *od; - od =_find_by_pdev (pdev); + od =to_omap_device (pdev);if (od->_state !=OMAP_DEVICE_STATE_ENABLED ) { WARN(1, "omap_device: %s.%d: %s() called from invalid state %d\n",
@@ -681,7 +676,7 @@ int omap_device_shutdown(struct platform_device *pdev)int ret, i;struct omap_device *od; - od =_find_by_pdev (pdev); + od =to_omap_device (pdev);if (od->_state !=OMAP_DEVICE_STATE_ENABLED && od->_state !=OMAP_DEVICE_STATE_IDLE ) {
@@ -722,7 +717,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,int ret = -EINVAL ;struct omap_device *od; - od =_find_by_pdev (pdev); + od =to_omap_device (pdev);if (new_wakeup_lat_limit == od->dev_wakeup_lat)return 0 ;
Signature · 1 line
1.7.1
PATCH 2/14 OMAP: omap_device: replace debug/warning/error prints with dev_* macros
In reply to G, Manjunath KondaiahFrom: Kevin Hilman <[email protected]>
For consistency in kernel printk output for devices, use dev_dbg(), dev_warn(), dev_err() instead of pr_debug(), pr_warning() and pr_err(), some of which currently use direct access of name from platform_device and others of which use dev_name(). Using the dev_* versions uses the standard device naming from the driver core.
Some pr_* prints were not converted with this patch since they are used before the platform_device and struct device are created so neither the dev_* prints or dev_name() is valid.
--- arch/arm/plat-omap/omap_device.c | 70 +++++++++++++++++++------------------- 1 files changed, 35 insertions(+), 35 deletions(-)
arch/arm/plat-omap/omap_device.c +35 -35
@@ -114,7 +114,7 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) {struct timespec a, b, c; -pr_debug ("omap_device: %s: activating\n" , od->pdev.name); +dev_dbg (&od->pdev.dev,"omap_device: activating\n" );while (od->pm_lat_level >0 ) {struct omap_device_pm_latency *odpl;
@@ -138,25 +138,24 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) c =timespec_sub (b, a); act_lat =timespec_to_ns (&c); -pr_debug ("omap_device: %s: pm_lat %d: activate: elapsed time " -"%llu nsec\n" , od->pdev.name, od->pm_lat_level, - act_lat); +dev_dbg (&od->pdev.dev, +"omap_device: pm_lat %d: activate: elapsed time " +"%llu nsec\n" , od->pm_lat_level, act_lat);if (act_lat > odpl->activate_lat) { odpl->activate_lat_worst = act_lat;if (odpl->flags &OMAP_DEVICE_LATENCY_AUTO_ADJUST ) { odpl->activate_lat = act_lat; -pr_warning ("omap_device: %s.%d: new worst case " -"activate latency %d: %llu\n" , - od->pdev.name, od->pdev.id, - od->pm_lat_level, act_lat); +dev_warn (&od->pdev.dev, +"new worst case activate latency " +"%d: %llu\n" , + od->pm_lat_level, act_lat); }else -pr_warning ("omap_device: %s.%d: activate " -"latency %d higher than exptected. " -"(%llu > %d)\n" , - od->pdev.name, od->pdev.id, - od->pm_lat_level, act_lat, - odpl->activate_lat); +dev_warn (&od->pdev.dev, +"activate latency %d " +"higher than exptected. (%llu > %d)\n" , + od->pm_lat_level, act_lat, + odpl->activate_lat); } od->dev_wakeup_lat -= odpl->activate_lat;
@@ -183,7 +182,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) {struct timespec a, b, c; -pr_debug ("omap_device: %s: deactivating\n" , od->pdev.name); +dev_dbg (&od->pdev.dev,"omap_device: deactivating\n" );while (od->pm_lat_level < od->pm_lats_cnt) {struct omap_device_pm_latency *odpl;
@@ -206,28 +205,26 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) c =timespec_sub (b, a); deact_lat =timespec_to_ns (&c); -pr_debug ("omap_device: %s: pm_lat %d: deactivate: elapsed time " -"%llu nsec\n" , od->pdev.name, od->pm_lat_level, - deact_lat); +dev_dbg (&od->pdev.dev, +"omap_device: pm_lat %d: deactivate: elapsed time " +"%llu nsec\n" , od->pm_lat_level, deact_lat);if (deact_lat > odpl->deactivate_lat) { odpl->deactivate_lat_worst = deact_lat;if (odpl->flags &OMAP_DEVICE_LATENCY_AUTO_ADJUST ) { odpl->deactivate_lat = deact_lat; -pr_warning ("omap_device: %s.%d: new worst case " -"deactivate latency %d: %llu\n" , - od->pdev.name, od->pdev.id, - od->pm_lat_level, deact_lat); +dev_warn (&od->pdev.dev, +"new worst case deactivate latency " +"%d: %llu\n" , + od->pm_lat_level, deact_lat); }else -pr_warning ("omap_device: %s.%d: deactivate " -"latency %d higher than exptected. " -"(%llu > %d)\n" , - od->pdev.name, od->pdev.id, - od->pm_lat_level, deact_lat, - odpl->deactivate_lat); +dev_warn (&od->pdev.dev, +"deactivate latency %d " +"higher than exptected. (%llu > %d)\n" , + od->pm_lat_level, deact_lat, + odpl->deactivate_lat); } - od->dev_wakeup_lat += odpl->activate_lat; od->pm_lat_level++;
@@ -609,8 +606,9 @@ int omap_device_enable(struct platform_device *pdev) od =to_omap_device (pdev);if (od->_state ==OMAP_DEVICE_STATE_ENABLED ) { -WARN (1 ,"omap_device: %s.%d: %s() called from invalid state %d\n" , - od->pdev.name, od->pdev.id, __func__, od->_state); +dev_warn (&pdev->dev, +"omap_device: %s() called from invalid state %d\n" , + __func__, od->_state);return -EINVAL ; }
@@ -648,8 +646,9 @@ int omap_device_idle(struct platform_device *pdev) od =to_omap_device (pdev);if (od->_state !=OMAP_DEVICE_STATE_ENABLED ) { -WARN (1 ,"omap_device: %s.%d: %s() called from invalid state %d\n" , - od->pdev.name, od->pdev.id, __func__, od->_state); +dev_warn (&pdev->dev, +"omap_device: %s() called from invalid state %d\n" , + __func__, od->_state);return -EINVAL ; }
@@ -680,8 +679,9 @@ int omap_device_shutdown(struct platform_device *pdev)if (od->_state !=OMAP_DEVICE_STATE_ENABLED && od->_state !=OMAP_DEVICE_STATE_IDLE ) { -WARN (1 ,"omap_device: %s.%d: %s() called from invalid state %d\n" , - od->pdev.name, od->pdev.id, __func__, od->_state); +dev_warn (&pdev->dev, +"omap_device: %s() called from invalid state %d\n" , + __func__, od->_state);return -EINVAL ; }
Signature · 1 line
1.7.1
PATCH 4/14 OMAP: McBSP: use existing macros for converting between devices
In reply to G, Manjunath KondaiahFrom: Kevin Hilman <[email protected]>
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().
--- arch/arm/plat-omap/mcbsp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
arch/arm/plat-omap/mcbsp.c +3 -3
@@ -295,9 +295,9 @@ EXPORT_SYMBOL(omap_mcbsp_dma_reg_params);#ifdef CONFIG_ARCH_OMAP3 static struct omap_device *find_omap_device_by_dev (struct device *dev) { -struct platform_device *pdev =container_of (dev, - struct platform_device, dev); - return container_of(pdev, struct omap_device, pdev); +struct platform_device *pdev =to_platform_device (dev); + +return to_omap_device (pdev); }static void omap_st_on (struct omap_mcbsp *mcbsp)
Signature · 1 line
1.7.1
PATCH 4/14 OMAP: McBSP: use existing macros for converting between devices
Hi
Quoted 11 lines · Manjunath Kondaiah
From: Kevin Hilman <[email protected]>
For converting from struct device to
platform_device, and fromplatform_deviceto struct device, there are existing macros. Use them instead of manual use ofcontainer_of().Signed-off-by Kevin Hilman <[email protected]>--- arch/arm/plat-omap/mcbsp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
Kevin dropped this patch and used mine that does more cleanups:
http://marc.info/?l=linux-omap&m=131255627918065&w=2
Worth to check also other patches since Kevin's updated set seems to have other differences too:
http://marc.info/?l=linux-omap&m=131258997416300&w=2
Signature · 1 line
Jarkko
PATCH 4/14 OMAP: McBSP: use existing macros for converting between devices
Manju,
Quoted 16 lines · Jarkko Nikula
Hi
Quoted 11 lines · Manjunath Kondaiah
From: Kevin Hilman<[email protected]>
For converting from struct device to
platform_device, and fromplatform_deviceto struct device, there are existing macros. Use them instead of manual use ofcontainer_of().Signed-off-by Kevin Hilman<[email protected]>--- arch/arm/plat-omap/mcbsp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
Quoted 8 lines
Kevin dropped this patch and used mine that does more cleanups:
http://marc.info/?l=linux-omap&m=131255627918065&w=2
Worth to check also other patches since Kevin's updated set seems to have other differences too:
In fact, you'd better point to the lastest Kevin's tree and not included the patches in this series.
Benoit
PATCH 4/14 OMAP: McBSP: use existing macros for converting between devices
Quoted 23 lines · Benoit
Manju,
Quoted 20 lines · Jarkko Nikula
Hi
Quoted 11 lines · Manjunath Kondaiah
From: Kevin Hilman<[email protected]>
For converting from struct device to
platform_device, and fromplatform_deviceto struct device, there are existing macros. Use them instead of manual use ofcontainer_of().Signed-off-by Kevin Hilman<[email protected]>--- arch/arm/plat-omap/mcbsp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)Kevin dropped this patch and used mine that does more cleanups:
Quoted 7 lines
Quoted 4 lines
Worth to check also other patches since Kevin's updated set seems to have other differences too:
In fact, you'd better point to the lastest Kevin's tree and not included the patches in this series.
Yes. I have already mentioned this in PATCH 00/14 and it will be rebased during rework for review comments.
Main focus here is on dt-hwmod binding and omap-i2c dt adaptation.
-M
PATCH 8/14 omap2+: Use Kconfig symbol in Makefile instead of obj-y
In reply to G, Manjunath KondaiahFrom: Tony Lindgren <[email protected]>
As noted by Grant Likely <[email protected]>, omap2+ Makefile unnecessarily repeats entries for common device init code instead of using Kconfig symbol.
Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o references can be removed once it has some Kconfig symbol to use.
--- arch/arm/mach-omap2/Makefile | 76 +++++++++++++++++------------------------ 1 files changed, 32 insertions(+), 44 deletions(-)
arch/arm/mach-omap2/Makefile +32 -44
@@ -175,78 +175,66 @@ endif # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o -obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \ - hsmmc.o +obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o -obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \ - hsmmc.o -obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \ - board-flash.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o \ - hsmmc.o -obj-$(CONFIG_MACH_OVERO) += board-overo.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ - hsmmc.o \ - board-flash.o +obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o +obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o +obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o +obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o +obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o +obj-$(CONFIG_MACH_OVERO) += board-overo.o +obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o +obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o +obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \ - sdram-nokia.o \ - hsmmc.o + sdram-nokia.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ sdram-nokia.o \ board-rx51-peripherals.o \ - board-rx51-video.o \ - hsmmc.o + board-rx51-video.o obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \ board-zoom-peripherals.o \ board-zoom-display.o \ - board-flash.o \ - hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \ board-zoom-peripherals.o \ board-zoom-display.o \ - board-flash.o \ - hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \ board-zoom-peripherals.o \ - board-zoom-display.o \ - board-flash.o \ - hsmmc.o -obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \ - hsmmc.o + board-zoom-display.o +obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o obj-$(CONFIG_MACH_CM_T3517) += board-cm-t3517.o -obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ - hsmmc.o +obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o +obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o \ - hsmmc.o \ omap_phy_internal.o obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \ - hsmmc.o \ + omap_phy_internal.o + +obj-$(CONFIG_MACH_PCM049) += board-omap4pcm049.o \ omap_phy_internal.o obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \ - omap_phy_internal.o \ + omap_phy_internal.o obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o -obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \ - hsmmc.o +obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o + # Platform specific device init code + +omap-flash-$(CONFIG_MTD_NAND_OMAP2) := board-flash.o +omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o +obj-y += $(omap-flash-y) $(omap-flash-m) + +omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o +obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y) + + usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o obj-y += $(usbfs-m) $(usbfs-y) obj-y += usb-musb.o
Signature · 1 line
1.7.1
PATCH 9/14 dt: omap: prepare hwmod to support dt
In reply to G, Manjunath KondaiahThe omap dt requires new omap hwmod api to be added for in order to support omap dt.
The new api is added and new parameter "np" is added for existing api. The users of hwmod api is changed accrodingly.
Build and boot tested on omap3 beagle for both dt and not dt build.
--- arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/mcbsp.c | 2 +- arch/arm/plat-omap/include/plat/omap_device.h | 11 +++++- arch/arm/plat-omap/omap_device.c | 53 ++++++++++++++++++++++--- 4 files changed, 59 insertions(+), 9 deletions(-)
arch/arm/mach-omap2/devices.c +1 -1
@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)pr_err ("could not look up %s\n" , oh_name); } - pdev =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL , + pdev =omap_device_build_ss (NULL ,"omap_l3_noc" ,0 , oh,3 ,NULL ,0 ,NULL ,0 ,0 );WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name);
arch/arm/mach-omap2/mcbsp.c +1 -1
@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone); count++; } - pdev =omap_device_build_ss (name, id, oh_device, count, pdata, + pdev =omap_device_build_ss (NULL , name, id, oh_device, count, pdata,sizeof (*pdata), omap2_mcbsp_latency,ARRAY_SIZE (omap2_mcbsp_latency), false);kfree (pdata);
arch/arm/plat-omap/include/plat/omap_device.h +10 -1
@@ -33,6 +33,7 @@#include <linux/kernel.h> #include <linux/platform_device.h> +#include <linux/of.h> #include <plat/omap_hwmod.h>
@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -struct platform_device *omap_device_build_ss (const char *pdev_name,int pdev_id, +struct platform_device *omap_device_build_ss (struct device_node *np, +const char *pdev_name,int pdev_id,struct omap_hwmod **oh,int oh_cnt,void *pdata,int pdata_len,struct omap_device_pm_latency *pm_lats,int pm_lats_cnt,int is_early_device); +struct platform_device *omap_device_build_dt (struct device_node *np, +const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device); +void __iomem *omap_device_get_rt_va (struct omap_device *od);/* OMAP PM interface */
arch/arm/plat-omap/omap_device.c +47 -6
112 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 9/14 dt: omap: prepare hwmod to support dt
Hi Manju,
Quoted 3 lines · Manjunath Kondaiah
The omap dt requires new omap hwmod api to be added for in order to support omap dt.
Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it.
You are just passing an "of_node" pointer during omap_device_build_ss.
The subject should start with OMAP: omap_device: because it does not belong to the DT subsystem.
The same comment apply to most patches in that series.
Quoted 2 lines
The new api is added and new parameter "np" is added for existing api.
I don't think np is not a super meaningful name. Some more explanation are needed as well.
Quoted 1 line
The users of hwmod api is changed accrodingly.
omap_device API + typo.
Quoted 15 lines
Build and boot tested on omap3 beagle for both dt and not dt build.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/mcbsp.c | 2 +- arch/arm/plat-omap/include/plat/omap_device.h | 11 +++++- arch/arm/plat-omap/omap_device.c | 53 ++++++++++++++++++++++--- 4 files changed, 59 insertions(+), 9 deletions(-)arch/arm/mach-omap2/devices.c +0
-0
arch/arm/mach-omap2/devices.c static int __init omap4_l3_init(void) · line 96
Quoted 6 lines
arch/arm/mach-omap2/devices.c +1
-1@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)pr_err ("could not look up %s\n" , oh_name); } - pdev =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL , + pdev =omap_device_build_ss (NULL ,"omap_l3_noc" ,0 , oh,3 ,NULL ,0 ,NULL ,0 ,0 );
OK, maybe that is just me, but in order to extend an API, I'd rather add the new parameter at the end.
Quoted 61 lines
arch/arm/mach-omap2/devices.c +0
-0WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name);arch/arm/mach-omap2/mcbsp.c +1
-1@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone); count++; } - pdev =omap_device_build_ss (name, id, oh_device, count, pdata, + pdev =omap_device_build_ss (NULL , name, id, oh_device, count, pdata,sizeof (*pdata), omap2_mcbsp_latency,ARRAY_SIZE (omap2_mcbsp_latency), false);kfree (pdata);arch/arm/plat-omap/include/plat/omap_device.h +10
-1@@ -33,6 +33,7 @@#include <linux/kernel.h> #include <linux/platform_device.h> +#include <linux/of.h> #include <plat/omap_hwmod.h> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -struct platform_device *omap_device_build_ss (const char *pdev_name,int pdev_id, +struct platform_device *omap_device_build_ss (struct device_node *np, +const char *pdev_name,int pdev_id,struct omap_hwmod **oh,int oh_cnt,void *pdata,int pdata_len,struct omap_device_pm_latency *pm_lats,int pm_lats_cnt,int is_early_device); +struct platform_device *omap_device_build_dt (struct device_node *np, +const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device); +void __iomem *omap_device_get_rt_va (struct omap_device *od);/* OMAP PM interface */ arch/arm/plat-omap/omap_device.c +1
-0@@ -85,6 +85,7 @@#include <linux/clk.h> #include <linux/clkdev.h> #include <linux/pm_runtime.h> +#include <linux/of_device.h> #include <plat/omap_device.h> #include <plat/omap_hwmod.h>
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 379
Quoted 2 lines
arch/arm/plat-omap/omap_device.c +0
-0@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,/** * omap_device_build - build and register an omap_device with one omap_hwmod
Need to update the kerneldoc.
Quoted 6 lines
arch/arm/plat-omap/omap_device.c +1
-0* @pdev_name: name of the platform_device driver to use +* @np: device node pointer for attaching it to of_node pointer * @pdev_id: this platform_device's connection ID * @oh: ptr to the single omap_hwmod that backs this omap_device * @pdata: platform_data ptr to associate with the platform_device
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 400
Quoted 9 lines
arch/arm/plat-omap/omap_device.c +2
-1@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_dt(struct device_node *np, + const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,
That function should not be needed. You have to export omap_device_build_ss, otherwise you will not build any device with multiple hwmods.
Quoted 65 lines
arch/arm/plat-omap/omap_device.c +36
-2@@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,if (!oh)return ERR_PTR (-EINVAL ); -return omap_device_build_ss (pdev_name, pdev_id, ohs,1 , pdata, +return omap_device_build_ss (np, pdev_name, pdev_id, ohs,1 , pdata, pdata_len, pm_lats, pm_lats_cnt, is_early_device); }/** +* omap_device_build - build and register an omap_device with one omap_hwmod +* @pdev_name: name of the platform_device driver to use +* @pdev_id: this platform_device's connection ID +* @oh: ptr to the single omap_hwmod that backs this omap_device +* @pdata: platform_data ptr to associate with the platform_device +* @pdata_len: amount of memory pointed to by @pdata +* @pm_lats: pointer to a omap_device_pm_latency array for this device +* @pm_lats_cnt: ARRAY_SIZE() of @pm_lats +* @is_early_device: should the device be registered as an early device or not +* +* Convenience function for building and registering a single +* omap_device record, which in turn builds and registers a +* platform_device record. See omap_device_build_ss() for more +* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, +* passes along the return value of omap_device_build_ss(). +*/ +struct platform_device *omap_device_build (const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device) +{ +struct omap_hwmod *ohs[] = { oh }; + +if (!oh) +return ERR_PTR (-EINVAL ); + +return omap_device_build_ss (NULL , pdev_name, pdev_id, ohs,1 , pdata, + pdata_len, pm_lats, pm_lats_cnt, is_early_device); +} + +/** * omap_device_build_ss - build and register an omap_device with multiple hwmods * @pdev_name: name of the platform_device driver to use * @pdev_id: this platform_device's connection ID @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,* platform_device record. Returns an ERR_PTR() on error, or passes * along the return value of omap_device_register(). */ -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(struct device_node *np, + const char *pdev_name, int pdev_id, struct omap_hwmod **ohs, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,@@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,struct resource *res =NULL ;int i, res_count;struct omap_hwmod **hwmods; +struct platform_device *pdev;if (!ohs || oh_cnt ==0 || !pdev_name)return ERR_PTR (-EINVAL );
arch/arm/plat-omap/omap_device.c struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, · line 490
Quoted 4 lines
arch/arm/plat-omap/omap_device.c +1
-0@@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (!od)return ERR_PTR (-ENOMEM ); + pdev =&od->pdev;
Why do you need that? You are just adding one more user of the pdev.
Quoted 18 lines
arch/arm/plat-omap/omap_device.c +5
-2od->hwmods_cnt = oh_cnt; hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,@@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, goto odbs_exit2;strcpy (pdev_name2, pdev_name); - od->pdev.name = pdev_name2; - od->pdev.id = pdev_id; +#ifdef CONFIG_OF_DEVICE + pdev->dev.of_node =of_node_get (np); +#endif + pdev->name = pdev_name2; + pdev->id = pdev_id; res_count =omap_device_count_resources (od);if (res_count>0 ) {
arch/arm/plat-omap/omap_device.c struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, · line 546
Quoted 8 lines
arch/arm/plat-omap/omap_device.c +1
-1@@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (ret) goto odbs_exit4; -return &od->pdev; +return pdev; odbs_exit4:kfree (res);
Regards,
Benoit
PATCH 9/14 dt: omap: prepare hwmod to support dt
Quoted 7 lines · Benoit
Hi Manju,
Quoted 3 lines · Manjunath Kondaiah
The omap dt requires new omap hwmod api to be added for in order to support omap dt.
Quoted 7 lines
Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it.
You are just passing an "of_node" pointer duringomap_device_build_ss.The subject should start with OMAP:
omap_device: because it does not belong to the DT subsystem.
The same comment apply to most patches in that series.
The goal of this patch is to make omap-hwmod ready for dt adaptation hence I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer is passed from dt and it is required for dt build.
And as you mentioned, patch does not do anything related to omap_device.
Quoted 6 lines
Quoted 3 lines
The new api is added and new parameter "np" is added for existing api.
I don't think np is not a super meaningful name. Some more explanation are needed as well.
ok. I can expand it.
Quoted 23 lines
Quoted 2 lines
The users of hwmod api is changed accrodingly.
omap_deviceAPI + typo.Quoted 18 lines
Build and boot tested on omap3 beagle for both dt and not dt build.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/mcbsp.c | 2 +- arch/arm/plat-omap/include/plat/omap_device.h | 11 +++++- arch/arm/plat-omap/omap_device.c | 53 ++++++++++++++++++++++--- 4 files changed, 59 insertions(+), 9 deletions(-)arch/arm/mach-omap2/devices.c +0
-0@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)pr_err ("could not look up %s\n" , oh_name); }
Quoted 6 lines
arch/arm/mach-omap2/devices.c static int __init omap4_l3_init(void) · line 96
Quoted 3 lines
arch/arm/mach-omap2/devices.c +1
-1- pdev =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL , + pdev =omap_device_build_ss (NULL ,"omap_l3_noc" ,0 , oh,3 ,NULL ,0 ,NULL ,0 ,0 );OK, maybe that is just me, but in order to extend an API, I'd rather add the new parameter at the end.
I feel it's fine since node pointer is first parameter is all dt api's.
Quoted 59 lines
Quoted 59 lines
arch/arm/mach-omap2/devices.c +0
-0WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name);arch/arm/mach-omap2/mcbsp.c +1
-1@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone); count++; } - pdev =omap_device_build_ss (name, id, oh_device, count, pdata, + pdev =omap_device_build_ss (NULL , name, id, oh_device, count, pdata,sizeof (*pdata), omap2_mcbsp_latency,ARRAY_SIZE (omap2_mcbsp_latency), false);kfree (pdata);arch/arm/plat-omap/include/plat/omap_device.h +10
-1@@ -33,6 +33,7 @@#include <linux/kernel.h> #include <linux/platform_device.h> +#include <linux/of.h> #include <plat/omap_hwmod.h> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -struct platform_device *omap_device_build_ss (const char *pdev_name,int pdev_id, +struct platform_device *omap_device_build_ss (struct device_node *np, +const char *pdev_name,int pdev_id,struct omap_hwmod **oh,int oh_cnt,void *pdata,int pdata_len,struct omap_device_pm_latency *pm_lats,int pm_lats_cnt,int is_early_device); +struct platform_device *omap_device_build_dt (struct device_node *np, +const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device); +void __iomem *omap_device_get_rt_va (struct omap_device *od);/* OMAP PM interface */ arch/arm/plat-omap/omap_device.c +1
-0@@ -85,6 +85,7 @@#include <linux/clk.h> #include <linux/clkdev.h> #include <linux/pm_runtime.h> +#include <linux/of_device.h>
Quoted 7 lines
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 379
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +0
-0#include <plat/omap_device.h> #include <plat/omap_hwmod.h> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,/** * omap_device_build - build and register an omap_device with one omap_hwmod Need to update the kerneldoc.
ok.
Quoted 12 lines
Quoted 12 lines
arch/arm/plat-omap/omap_device.c +2
-1* @pdev_name: name of the platform_device driver to use +* @np: device node pointer for attaching it to of_node pointer * @pdev_id: this platform_device's connection ID * @oh: ptr to the single omap_hwmod that backs this omap_device * @pdata: platform_data ptr to associate with the platform_device @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_dt(struct device_node *np,
Quoted 8 lines
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 400
Quoted 4 lines
arch/arm/plat-omap/omap_device.c +1
-0+ const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,That function should not be needed. You have to export
omap_device_build_ss, otherwise you will not build any device with multiple hwmods.
ok.
Quoted 69 lines
Quoted 69 lines
arch/arm/plat-omap/omap_device.c +36
-2@@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,if (!oh)return ERR_PTR (-EINVAL ); -return omap_device_build_ss (pdev_name, pdev_id, ohs,1 , pdata, +return omap_device_build_ss (np, pdev_name, pdev_id, ohs,1 , pdata, pdata_len, pm_lats, pm_lats_cnt, is_early_device); }/** +* omap_device_build - build and register an omap_device with one omap_hwmod +* @pdev_name: name of the platform_device driver to use +* @pdev_id: this platform_device's connection ID +* @oh: ptr to the single omap_hwmod that backs this omap_device +* @pdata: platform_data ptr to associate with the platform_device +* @pdata_len: amount of memory pointed to by @pdata +* @pm_lats: pointer to a omap_device_pm_latency array for this device +* @pm_lats_cnt: ARRAY_SIZE() of @pm_lats +* @is_early_device: should the device be registered as an early device or not +* +* Convenience function for building and registering a single +* omap_device record, which in turn builds and registers a +* platform_device record. See omap_device_build_ss() for more +* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, +* passes along the return value of omap_device_build_ss(). +*/ +struct platform_device *omap_device_build (const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device) +{ +struct omap_hwmod *ohs[] = { oh }; + +if (!oh) +return ERR_PTR (-EINVAL ); + +return omap_device_build_ss (NULL , pdev_name, pdev_id, ohs,1 , pdata, + pdata_len, pm_lats, pm_lats_cnt, is_early_device); +} + +/** * omap_device_build_ss - build and register an omap_device with multiple hwmods * @pdev_name: name of the platform_device driver to use * @pdev_id: this platform_device's connection ID @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,* platform_device record. Returns an ERR_PTR() on error, or passes * along the return value of omap_device_register(). */ -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(struct device_node *np, + const char *pdev_name, int pdev_id, struct omap_hwmod **ohs, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,@@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,struct resource *res =NULL ;int i, res_count;struct omap_hwmod **hwmods; +struct platform_device *pdev;if (!ohs || oh_cnt ==0 || !pdev_name)return ERR_PTR (-EINVAL );@@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (!od)return ERR_PTR (-ENOMEM );
Quoted 3 lines
arch/arm/plat-omap/omap_device.c struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, · line 490
Quoted 1 line
arch/arm/plat-omap/omap_device.c +1
-0+ pdev =&od->pdev;Why do you need that? You are just adding one more user of the pdev.
just improve readability otherwise we need to have &od->pdev at multiple places below.
Quoted 36 lines
Quoted 19 lines
arch/arm/plat-omap/omap_device.c +5
-2od->hwmods_cnt = oh_cnt; hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,@@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, goto odbs_exit2;strcpy (pdev_name2, pdev_name); - od->pdev.name = pdev_name2; - od->pdev.id = pdev_id; +#ifdef CONFIG_OF_DEVICE + pdev->dev.of_node =of_node_get (np); +#endif + pdev->name = pdev_name2; + pdev->id = pdev_id; res_count =omap_device_count_resources (od);if (res_count>0 ) {arch/arm/plat-omap/omap_device.c struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, · line 546
Quoted 8 lines
arch/arm/plat-omap/omap_device.c +1
-1@@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (ret) goto odbs_exit4; -return &od->pdev; +return pdev; odbs_exit4:kfree (res);Regards,
Benoit_______________________________________________
devicetree-discuss mailing list
devicetree-discuss at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
PATCH 9/14 dt: omap: prepare hwmod to support dt
Quoted 12 lines · Manjunath Kondaiah
Quoted 11 lines · Benoit
Hi Manju,
Quoted 3 lines · Manjunath Kondaiah
The omap dt requires new omap hwmod api to be added for in order to support omap dt.
Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it.
You are just passing an "of_node" pointer duringomap_device_build_ss.
Quoted 7 lines
Quoted 3 lines
The subject should start with OMAP:
omap_device: because it does not belong to the DT subsystem.
The same comment apply to most patches in that series.The goal of this patch is to make omap-hwmod ready for dt adaptation hence I used the title "dt: omap: prepare hwmod to support dt" and "
of_node" pointer is passed from dt and it is required for dt build.
I think that the goal of this patch is to update the omap_device_build_ss API in order to provide a device tree node pointer to pdev. For the moment there is nothing related to hwmod.
Quoted 1 line
And as you mentioned, patch does not do anything related to
omap_device.
You meant omap_hwmod?
Benoit
Quoted 240 lines
Quoted 5 lines
Quoted 2 lines
The new api is added and new parameter "np" is added for existing api.
I don't think np is not a super meaningful name. Some more explanation are needed as well.
ok. I can expand it.
Quoted 23 lines
Quoted 2 lines
The users of hwmod api is changed accrodingly.
omap_deviceAPI + typo.Quoted 18 lines
Build and boot tested on omap3 beagle for both dt and not dt build.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/mcbsp.c | 2 +- arch/arm/plat-omap/include/plat/omap_device.h | 11 +++++- arch/arm/plat-omap/omap_device.c | 53 ++++++++++++++++++++++--- 4 files changed, 59 insertions(+), 9 deletions(-)arch/arm/mach-omap2/devices.c +0
-0@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)pr_err ("could not look up %s\n" , oh_name); }Quoted 6 lines
arch/arm/mach-omap2/devices.c static int __init omap4_l3_init(void) · line 96
Quoted 3 lines
arch/arm/mach-omap2/devices.c +1
-1- pdev =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL , + pdev =omap_device_build_ss (NULL ,"omap_l3_noc" ,0 , oh,3 ,NULL ,0 ,NULL ,0 ,0 );OK, maybe that is just me, but in order to extend an API, I'd rather add the new parameter at the end.
I feel it's fine since node pointer is first parameter is all dt api's.
Quoted 59 lines
Quoted 59 lines
arch/arm/mach-omap2/devices.c +0
-0WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name);arch/arm/mach-omap2/mcbsp.c +1
-1@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone); count++; } - pdev =omap_device_build_ss (name, id, oh_device, count, pdata, + pdev =omap_device_build_ss (NULL , name, id, oh_device, count, pdata,sizeof (*pdata), omap2_mcbsp_latency,ARRAY_SIZE (omap2_mcbsp_latency), false);kfree (pdata);arch/arm/plat-omap/include/plat/omap_device.h +10
-1@@ -33,6 +33,7 @@#include <linux/kernel.h> #include <linux/platform_device.h> +#include <linux/of.h> #include <plat/omap_hwmod.h> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -struct platform_device *omap_device_build_ss (const char *pdev_name,int pdev_id, +struct platform_device *omap_device_build_ss (struct device_node *np, +const char *pdev_name,int pdev_id,struct omap_hwmod **oh,int oh_cnt,void *pdata,int pdata_len,struct omap_device_pm_latency *pm_lats,int pm_lats_cnt,int is_early_device); +struct platform_device *omap_device_build_dt (struct device_node *np, +const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device); +void __iomem *omap_device_get_rt_va (struct omap_device *od);/* OMAP PM interface */ arch/arm/plat-omap/omap_device.c +1
-0@@ -85,6 +85,7 @@#include <linux/clk.h> #include <linux/clkdev.h> #include <linux/pm_runtime.h> +#include <linux/of_device.h> Quoted 7 lines
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 379
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +0
-0#include <plat/omap_device.h> #include <plat/omap_hwmod.h> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,/** * omap_device_build - build and register an omap_device with one omap_hwmod Need to update the kerneldoc.
ok.
Quoted 12 lines
Quoted 12 lines
arch/arm/plat-omap/omap_device.c +2
-1* @pdev_name: name of the platform_device driver to use +* @np: device node pointer for attaching it to of_node pointer * @pdev_id: this platform_device's connection ID * @oh: ptr to the single omap_hwmod that backs this omap_device * @pdata: platform_data ptr to associate with the platform_device @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_dt(struct device_node *np,Quoted 8 lines
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 400
Quoted 4 lines
arch/arm/plat-omap/omap_device.c +1
-0+ const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,That function should not be needed. You have to export
omap_device_build_ss, otherwise you will not build any device with multiple hwmods.ok.
Quoted 69 lines
Quoted 69 lines
arch/arm/plat-omap/omap_device.c +36
-2@@ -402,12 +405,44 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,if (!oh)return ERR_PTR (-EINVAL ); -return omap_device_build_ss (pdev_name, pdev_id, ohs,1 , pdata, +return omap_device_build_ss (np, pdev_name, pdev_id, ohs,1 , pdata, pdata_len, pm_lats, pm_lats_cnt, is_early_device); }/** +* omap_device_build - build and register an omap_device with one omap_hwmod +* @pdev_name: name of the platform_device driver to use +* @pdev_id: this platform_device's connection ID +* @oh: ptr to the single omap_hwmod that backs this omap_device +* @pdata: platform_data ptr to associate with the platform_device +* @pdata_len: amount of memory pointed to by @pdata +* @pm_lats: pointer to a omap_device_pm_latency array for this device +* @pm_lats_cnt: ARRAY_SIZE() of @pm_lats +* @is_early_device: should the device be registered as an early device or not +* +* Convenience function for building and registering a single +* omap_device record, which in turn builds and registers a +* platform_device record. See omap_device_build_ss() for more +* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, +* passes along the return value of omap_device_build_ss(). +*/ +struct platform_device *omap_device_build (const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device) +{ +struct omap_hwmod *ohs[] = { oh }; + +if (!oh) +return ERR_PTR (-EINVAL ); + +return omap_device_build_ss (NULL , pdev_name, pdev_id, ohs,1 , pdata, + pdata_len, pm_lats, pm_lats_cnt, is_early_device); +} + +/** * omap_device_build_ss - build and register an omap_device with multiple hwmods * @pdev_name: name of the platform_device driver to use * @pdev_id: this platform_device's connection ID @@ -424,7 +459,8 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,* platform_device record. Returns an ERR_PTR() on error, or passes * along the return value of omap_device_register(). */ -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(struct device_node *np, + const char *pdev_name, int pdev_id, struct omap_hwmod **ohs, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,@@ -436,6 +472,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,struct resource *res =NULL ;int i, res_count;struct omap_hwmod **hwmods; +struct platform_device *pdev;if (!ohs || oh_cnt ==0 || !pdev_name)return ERR_PTR (-EINVAL );@@ -450,6 +487,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (!od)return ERR_PTR (-ENOMEM );Quoted 3 lines
arch/arm/plat-omap/omap_device.c struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, · line 490
Quoted 1 line
arch/arm/plat-omap/omap_device.c +1
-0+ pdev =&od->pdev;Why do you need that? You are just adding one more user of the pdev.
just improve readability otherwise we need to have&od->pdev at multiple places below.
Quoted 36 lines
Quoted 19 lines
arch/arm/plat-omap/omap_device.c +5
-2od->hwmods_cnt = oh_cnt; hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,@@ -465,8 +503,11 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, goto odbs_exit2;strcpy (pdev_name2, pdev_name); - od->pdev.name = pdev_name2; - od->pdev.id = pdev_id; +#ifdef CONFIG_OF_DEVICE + pdev->dev.of_node =of_node_get (np); +#endif + pdev->name = pdev_name2; + pdev->id = pdev_id; res_count =omap_device_count_resources (od);if (res_count>0 ) {arch/arm/plat-omap/omap_device.c struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, · line 546
Quoted 8 lines
arch/arm/plat-omap/omap_device.c +1
-1@@ -499,7 +540,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (ret) goto odbs_exit4; -return &od->pdev; +return pdev; odbs_exit4:kfree (res);Regards,
Benoit_______________________________________________
devicetree-discuss mailing list
devicetree-discuss at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
PATCH 9/14 dt: omap: prepare hwmod to support dt
Quoted 19 lines · Benoit
Quoted 18 lines · Manjunath Kondaiah
Quoted 15 lines · Benoit
Hi Manju,
Quoted 3 lines · Manjunath Kondaiah
The omap dt requires new omap hwmod api to be added for in order to support omap dt.
Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it.
You are just passing an "of_node" pointer duringomap_device_build_ss.The subject should start with OMAP:
omap_device: because it does not belong to the DT subsystem.
The same comment apply to most patches in that series.
Quoted 8 lines
Quoted 4 lines
The goal of this patch is to make omap-hwmod ready for dt adaptation hence I used the title "dt: omap: prepare hwmod to support dt" and "
of_node" pointer
is passed from dt and it is required for dt build.I think that the goal of this patch is to update the
omap_device_build_ssAPI in order to provide a device tree node pointer to pdev. For the moment there is nothing related to hwmod.
yes. it is to update *_ss api with device node pointer and introduce new api exported for dt builds. I can update with this description.
Quoted 4 lines
Quoted 2 lines
And as you mentioned, patch does not do anything related to
omap_device.You meant
omap_hwmod?
Yes. It should be "omap: omap_hwmod: add device node pointer"
-M
PATCH 9/14 dt: omap: prepare hwmod to support dt
Quoted 28 lines · Manjunath Kondaiah
Quoted 19 lines · Benoit
Quoted 18 lines · Manjunath Kondaiah
Quoted 15 lines · Benoit
Hi Manju,
Quoted 3 lines · Manjunath Kondaiah
The omap dt requires new omap hwmod api to be added for in order to support omap dt.
Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it.
You are just passing an "of_node" pointer duringomap_device_build_ss.The subject should start with OMAP:
omap_device: because it does not belong to the DT subsystem.
The same comment apply to most patches in that series.Quoted 8 lines
Quoted 4 lines
The goal of this patch is to make omap-hwmod ready for dt adaptation hence I used the title "dt: omap: prepare hwmod to support dt" and "
of_node" pointer
is passed from dt and it is required for dt build.I think that the goal of this patch is to update the
omap_device_build_ssAPI in order to provide a device tree node pointer to pdev. For the moment there is nothing related to hwmod.
Quoted 8 lines
yes. it is to update
*_ssapi with device node pointer and introduce new api exported for dt builds. I can update with this description.Quoted 4 lines
Quoted 2 lines
And as you mentioned, patch does not do anything related to
omap_device.You meant
omap_hwmod?Yes. It should be "omap:
omap_hwmod: add device node pointer"
... "OMAP: omap_device: Add device tree node pointer"
PATCH 9/14 dt: omap: prepare hwmod to support dt
In reply to G, Manjunath KondaiahQuoted 122 lines · Manjunath Kondaiah
Quoted 7 lines · Benoit
Hi Manju,
Quoted 3 lines · Manjunath Kondaiah
The omap dt requires new omap hwmod api to be added for in order to support omap dt.
Quoted 7 lines
Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it.
You are just passing an "of_node" pointer duringomap_device_build_ss.The subject should start with OMAP:
omap_device: because it does not belong to the DT subsystem.
The same comment apply to most patches in that series.The goal of this patch is to make omap-hwmod ready for dt adaptation hence I used the title "dt: omap: prepare hwmod to support dt" and "
of_node" pointer is passed from dt and it is required for dt build.And as you mentioned, patch does not do anything related to
omap_device.Quoted 6 lines
Quoted 3 lines
The new api is added and new parameter "np" is added for existing api.
I don't think np is not a super meaningful name. Some more explanation are needed as well.
ok. I can expand it.
Quoted 23 lines
Quoted 2 lines
The users of hwmod api is changed accrodingly.
omap_deviceAPI + typo.Quoted 18 lines
Build and boot tested on omap3 beagle for both dt and not dt build.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/mcbsp.c | 2 +- arch/arm/plat-omap/include/plat/omap_device.h | 11 +++++- arch/arm/plat-omap/omap_device.c | 53 ++++++++++++++++++++++--- 4 files changed, 59 insertions(+), 9 deletions(-)arch/arm/mach-omap2/devices.c +0
-0@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)pr_err ("could not look up %s\n" , oh_name); }Quoted 6 lines
arch/arm/mach-omap2/devices.c static int __init omap4_l3_init(void) · line 96
Quoted 3 lines
arch/arm/mach-omap2/devices.c +1
-1- pdev =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL , + pdev =omap_device_build_ss (NULL ,"omap_l3_noc" ,0 , oh,3 ,NULL ,0 ,NULL ,0 ,0 );OK, maybe that is just me, but in order to extend an API, I'd rather add the new parameter at the end.
I feel it's fine since node pointer is first parameter is all dt api's.
Quoted 59 lines
Quoted 59 lines
arch/arm/mach-omap2/devices.c +0
-0WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name);arch/arm/mach-omap2/mcbsp.c +1
-1@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone); count++; } - pdev =omap_device_build_ss (name, id, oh_device, count, pdata, + pdev =omap_device_build_ss (NULL , name, id, oh_device, count, pdata,sizeof (*pdata), omap2_mcbsp_latency,ARRAY_SIZE (omap2_mcbsp_latency), false);kfree (pdata);arch/arm/plat-omap/include/plat/omap_device.h +10
-1@@ -33,6 +33,7 @@#include <linux/kernel.h> #include <linux/platform_device.h> +#include <linux/of.h> #include <plat/omap_hwmod.h> @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -struct platform_device *omap_device_build_ss (const char *pdev_name,int pdev_id, +struct platform_device *omap_device_build_ss (struct device_node *np, +const char *pdev_name,int pdev_id,struct omap_hwmod **oh,int oh_cnt,void *pdata,int pdata_len,struct omap_device_pm_latency *pm_lats,int pm_lats_cnt,int is_early_device); +struct platform_device *omap_device_build_dt (struct device_node *np, +const char *pdev_name,int pdev_id, +struct omap_hwmod *oh,void *pdata, +int pdata_len, +struct omap_device_pm_latency *pm_lats, +int pm_lats_cnt,int is_early_device); +void __iomem *omap_device_get_rt_va (struct omap_device *od);/* OMAP PM interface */ arch/arm/plat-omap/omap_device.c +1
-0@@ -85,6 +85,7 @@#include <linux/clk.h> #include <linux/clkdev.h> #include <linux/pm_runtime.h> +#include <linux/of_device.h>
Quoted 8 lines
Quoted 7 lines
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 379
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +0
-0#include <plat/omap_device.h> #include <plat/omap_hwmod.h> @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,/** * omap_device_build - build and register an omap_device with one omap_hwmod Need to update the kerneldoc.
ok.
As these API's are interim API's and we might have alternate setup to handle hwmod in the coming days, the documentation part will be taken care along with final solution for hwmod issue.
Quoted 20 lines
Quoted 12 lines
Quoted 12 lines
arch/arm/plat-omap/omap_device.c +2
-1* @pdev_name: name of the platform_device driver to use +* @np: device node pointer for attaching it to of_node pointer * @pdev_id: this platform_device's connection ID * @oh: ptr to the single omap_hwmod that backs this omap_device * @pdata: platform_data ptr to associate with the platform_device @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_dt(struct device_node *np,Quoted 8 lines
arch/arm/plat-omap/omap_device.c static int omap_device_fill_resources(struct omap_device *od, · line 400
Quoted 4 lines
arch/arm/plat-omap/omap_device.c +1
-0+ const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,That function should not be needed. You have to export
omap_device_build_ss, otherwise you will not build any device with multiple hwmods.
Quoted 1 line
ok.
confused here. All the three API's *_dt/*_ss/*_dt are exported and can be accessed for single or multiple hwmods. Am I missing anything?
-M
PATCH 11/14 dt: omap3: add soc file for handling i2c controllers
In reply to G, Manjunath KondaiahAdd omap3 soc file for handling omap3 soc i2c controllers existing on l4-core bus.
--- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
arch/arm/boot/dts/omap3-soc.dtsi new file +62 -0
@@ -0,0 +1,62 @@ +/* + * Device Tree Source for OMAP3 SoC + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + #address-cells = <1>; + #size-cells = <1>; + model = "ti,omap3"; + + aliases { + i2c1 = &i2c1; + i2c2 = &i2c2; + i2c3 = &i2c3; + }; + + l4-core { + compatible = "ti,omap3-l4-core"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x48000000 0x1000000>; + + i2c1: i2c@70000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,omap3-i2c"; + reg = <0x70000 0x100>; + interrupts = < 88 >; + }; + + i2c2: i2c@72000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,omap3-i2c"; + reg = <0x72000 0x100>; + interrupts = < 89 >; + }; + + i2c3: i2c@60000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,omap3-i2c"; + reg = <0x60000 0x100>; + interrupts = < 93 >; + }; + }; + + l4-per { + compatible = "ti,l4-per"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x49000000 0x100000>; + }; +};
Signature · 1 line
1.7.1
PATCH 11/14 dt: omap3: add soc file for handling i2c controllers
Quoted 31 lines · Manjunath Kondaiah
Add omap3 soc file for handling omap3 soc i2c controllers existing on l4-core bus.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-)create mode 100644
arch/arm/boot/dts/omap3-soc.dtsiarch/arm/boot/dts/omap3-soc.dtsi new file +15
-0@@ -0,0 +1,62 @@ +/* + * Device Tree Source for OMAP3 SoC + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + #address-cells =<1>;
arch/arm/boot/dts/omap3-soc.dtsi line 25
Quoted 10 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +10
-0+ #size-cells =<1>; + model = "ti,omap3"; + + aliases { + i2c1 =&i2c1; + i2c2 =&i2c2; + i2c3 =&i2c3; + }; + + l4-core {
That comment is probably subject to discussion, but even if this interconnect is there physically, I'm not sure of the added value to add it. It will add an extra level of indentation and that all. Moreover, it will mess up the physical address that are expressed using absolute value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat representation of the interconnect.
arch/arm/boot/dts/omap3-soc.dtsi line 26
Quoted 1 line
arch/arm/boot/dts/omap3-soc.dtsi new file +1
-0+ compatible = "ti,omap3-l4-core";
Assuming we will keep that, you should probably add a more generic compatible name after that one. Like "ti,s3220" or even "sonics,s3220", assuming that this IP is generic enough for other SoC.
arch/arm/boot/dts/omap3-soc.dtsi line 34
Quoted 8 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +8
-0+ #address-cells =<1>; + #size-cells =<1>; + ranges =<0 0x48000000 0x1000000>; + + i2c1: i2c at 70000 { + #address-cells =<1>; + #size-cells =<0>; + compatible = "ti,omap3-i2c";
The I2C IP and thus the driver is generic across OMAP generations and is even potentially used by other non-OMAP TI chips like DSP or Davinci. So having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems mandatory.
Regards,
Benoit
PATCH 11/14 dt: omap3: add soc file for handling i2c controllers
Quoted 43 lines · Benoit
Quoted 31 lines · Manjunath Kondaiah
Add omap3 soc file for handling omap3 soc i2c controllers existing on l4-core bus.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-soc.dtsiarch/arm/boot/dts/omap3-soc.dtsi new file +15
-0@@ -0,0 +1,62 @@ +/* + * Device Tree Source for OMAP3 SoC + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + #address-cells =<1>;arch/arm/boot/dts/omap3-soc.dtsi line 25
Quoted 10 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +10
-0+ #size-cells =<1>; + model = "ti,omap3"; + + aliases { + i2c1 =&i2c1; + i2c2 =&i2c2; + i2c3 =&i2c3; + }; + + l4-core {
Quoted 8 lines
That comment is probably subject to discussion, but even if this interconnect is there physically, I'm not sure of the added value to add it.
It will add an extra level of indentation and that all. Moreover, it will mess up the physical address that are expressed using absolute value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat representation of the interconnect.
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391
Quoted 7 lines
arch/arm/boot/dts/omap3-soc.dtsi line 26
Quoted 2 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +1
-0+ compatible = "ti,omap3-l4-core";Assuming we will keep that, you should probably add a more generic compatible name after that one. Like "ti,s3220" or even "sonics,s3220", assuming that this IP is generic enough for other SoC.
will check this. I don't remember any generic names.
Quoted 14 lines
arch/arm/boot/dts/omap3-soc.dtsi line 34
Quoted 9 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +8
-0+ #address-cells =<1>; + #size-cells =<1>; + ranges =<0 0x48000000 0x1000000>; + + i2c1: i2c at 70000 { + #address-cells =<1>; + #size-cells =<0>; + compatible = "ti,omap3-i2c";The I2C IP and thus the driver is generic across OMAP generations and is even potentially used by other non-OMAP TI chips like DSP or Davinci. So having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems mandatory.
This can be updated as and when new soc/board adaptations are done. As of now, it is omap3 and when we have omap4 it will be appended with "ti,omap4-i2c" etc
-M
PATCH 11/14 dt: omap3: add soc file for handling i2c controllers
+ Tony
Quoted 52 lines · Manjunath Kondaiah
Quoted 43 lines · Benoit
Quoted 31 lines · Manjunath Kondaiah
Add omap3 soc file for handling omap3 soc i2c controllers existing on l4-core bus.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-)create mode 100644
arch/arm/boot/dts/omap3-soc.dtsiarch/arm/boot/dts/omap3-soc.dtsi new file +15
-0@@ -0,0 +1,62 @@ +/* + * Device Tree Source for OMAP3 SoC + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + #address-cells =<1>;arch/arm/boot/dts/omap3-soc.dtsi line 25
Quoted 10 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +10
-0+ #size-cells =<1>; + model = "ti,omap3"; + + aliases { + i2c1 =&i2c1; + i2c2 =&i2c2; + i2c3 =&i2c3; + }; + + l4-core {Quoted 8 lines
That comment is probably subject to discussion, but even if this interconnect is there physically, I'm not sure of the added value to add it.
It will add an extra level of indentation and that all. Moreover, it will mess up the physical address that are expressed using absolute value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat representation of the interconnect.
Quoted 2 lines
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391
So I'm asking the same question to Grant and Tony then:-)
Quoted 21 lines
Quoted 6 lines
arch/arm/boot/dts/omap3-soc.dtsi line 26
Quoted 1 line
arch/arm/boot/dts/omap3-soc.dtsi new file +1
-0+ compatible = "ti,omap3-l4-core";Assuming we will keep that, you should probably add a more generic compatible name after that one. Like "ti,s3220" or even "sonics,s3220", assuming that this IP is generic enough for other SoC.
will check this. I don't remember any generic names.
Quoted 14 lines
arch/arm/boot/dts/omap3-soc.dtsi line 34
Quoted 9 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +8
-0+ #address-cells =<1>; + #size-cells =<1>; + ranges =<0 0x48000000 0x1000000>; + + i2c1: i2c at 70000 { + #address-cells =<1>; + #size-cells =<0>; + compatible = "ti,omap3-i2c";The I2C IP and thus the driver is generic across OMAP generations and is even potentially used by other non-OMAP TI chips like DSP or Davinci. So having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems mandatory.
Quoted 3 lines
This can be updated as and when new soc/board adaptations are done. As of now, it is omap3 and when we have omap4 it will be appended with "ti,omap4-i2c" etc
To infinity and beyond?
There is no need, and we should absolutely not update the driver each time we introduce a new SoC version/revision.
The driver should match with the generic device name in that case. Until we change the IP and potentially introduce a new driver.
BTW, even omap3 should not be in the name in theory. It should be potentially "ti,i2c-v3" or whatever HW version the IP is using. But for some reason, most devices are using such convention in existing DTS:-(
This is probably due to the lack of well identified IP version in most SoC... including OMAP:-)
Benoit
PATCH 11/14 dt: omap3: add soc file for handling i2c controllers
Quoted 55 lines · Benoit
+ Tony
Quoted 52 lines · Manjunath Kondaiah
Quoted 51 lines · Benoit
Quoted 31 lines · Manjunath Kondaiah
Add omap3 soc file for handling omap3 soc i2c controllers existing on l4-core bus.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-soc.dtsiarch/arm/boot/dts/omap3-soc.dtsi new file +15
-0@@ -0,0 +1,62 @@ +/* + * Device Tree Source for OMAP3 SoC + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + #address-cells =<1>;arch/arm/boot/dts/omap3-soc.dtsi line 25
Quoted 10 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +10
-0+ #size-cells =<1>; + model = "ti,omap3"; + + aliases { + i2c1 =&i2c1; + i2c2 =&i2c2; + i2c3 =&i2c3; + }; + + l4-core {That comment is probably subject to discussion, but even if this interconnect is there physically, I'm not sure of the added value to add it.
It will add an extra level of indentation and that all. Moreover, it will mess up the physical address that are expressed using absolute value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat representation of the interconnect.
Quoted 4 lines
Quoted 2 lines
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391So I'm asking the same question to Grant and Tony then:-)
What is the conclusion here? I will go ahead with current approach since tony and grant has voted for it.
-M
Quoted 42 lines
Quoted 22 lines
Quoted 7 lines
arch/arm/boot/dts/omap3-soc.dtsi line 26
Quoted 2 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +1
-0+ compatible = "ti,omap3-l4-core";Assuming we will keep that, you should probably add a more generic compatible name after that one. Like "ti,s3220" or even "sonics,s3220", assuming that this IP is generic enough for other SoC.
will check this. I don't remember any generic names.
Quoted 14 lines
arch/arm/boot/dts/omap3-soc.dtsi line 34
Quoted 9 lines
arch/arm/boot/dts/omap3-soc.dtsi new file +8
-0+ #address-cells =<1>; + #size-cells =<1>; + ranges =<0 0x48000000 0x1000000>; + + i2c1: i2c at 70000 { + #address-cells =<1>; + #size-cells =<0>; + compatible = "ti,omap3-i2c";The I2C IP and thus the driver is generic across OMAP generations and is even potentially used by other non-OMAP TI chips like DSP or Davinci. So having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems mandatory.
Quoted 3 lines
This can be updated as and when new soc/board adaptations are done. As of now, it is omap3 and when we have omap4 it will be appended with "ti,omap4-i2c" etc
To infinity and beyond?
There is no need, and we should absolutely not update the driver each time we introduce a new SoC version/revision.
The driver should match with the generic device name in that case. Until we change the IP and potentially introduce a new driver.BTW, even omap3 should not be in the name in theory. It should be potentially "ti,i2c-v3" or whatever HW version the IP is using. But for some reason, most devices are using such convention in existing DTS:-(
This is probably due to the lack of well identified IP version in most SoC... including OMAP:-)Benoit
PATCH 12/14 dt: omap3: beagle board: set clock freq for i2c devices
In reply to G, Manjunath KondaiahUpdate omap3 beagle dts file with required clock frequencies for the i2c client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3 soc dts file.
--- arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +---------- arch/arm/boot/dts/omap3-beagle.dts | 18 +++++++++++++++--- 2 files changed, 16 insertions(+), 13 deletions(-)
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +1 -10
@@ -1,16 +1,7 @@ /include/ "omap3-beagle.dts" / { - i2c@48072000 { - compatible = "ti,omap3-i2c"; - reg = <0x48072000 0x80>; - #address-cells = <1>; - #size-cells = <0>; - - eeprom@50 { - compatible = "at,at24c01"; - reg = < 0x50 >; - }; + i2c@2 { joystick@52 { compatible = "sparkfun,wiichuck"; reg = < 0x52 >;
arch/arm/boot/dts/omap3-beagle.dts +15 -3
@@ -1,7 +1,19 @@ -/dts-v1/; -/include/ "skeleton.dtsi" +/include/ "omap3-soc.dtsi" / { model = "TI OMAP3 BeagleBoard"; - compatible = "ti,omap3-beagle"; + compatible = "ti,omap3-beagle", "ti,omap3"; + + + i2c1 { + clock-frequency = <2600000>; + }; + + i2c2 { + clock-frequency = <400000>; + }; + + i2c3 { + clock-frequency = <400000>; + }; };
Signature · 1 line
1.7.1
PATCH 12/14 dt: omap3: beagle board: set clock freq for i2c devices
Quoted 21 lines · Manjunath Kondaiah
Update omap3 beagle dts file with required clock frequencies for the i2c client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3 soc dts file.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +---------- arch/arm/boot/dts/omap3-beagle.dts | 18 +++++++++++++++--- 2 files changed, 16 insertions(+), 13 deletions(-)arch/arm/boot/dts/omap3-beagle-nunchuck.dts +0
-0@@ -1,16 +1,7 @@ /include/ "omap3-beagle.dts" / {
arch/arm/boot/dts/omap3-beagle-nunchuck.dts line 13
Quoted 10 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +0
-10- i2c at 48072000 { - compatible = "ti,omap3-i2c"; - reg =<0x48072000 0x80>; - #address-cells =<1>; - #size-cells =<0>; - - eeprom at 50 { - compatible = "at,at24c01"; - reg =< 0x50>; - };
This change should probably not be there.
arch/arm/boot/dts/omap3-beagle-nunchuck.dts line 6
Quoted 3 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +1
-0+ i2c at 2 { joystick at 52 { compatible = "sparkfun,wiichuck";
It looks like someone is having fun with a beagle connected to a Wii nunchuck:-)
arch/arm/boot/dts/omap3-beagle.dts line 1
Quoted 9 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +0
-0reg =< 0x52>;arch/arm/boot/dts/omap3-beagle.dts +1
-2@@ -1,7 +1,19 @@ -/dts-v1/; -/include/ "skeleton.dtsi" +/include/ "omap3-soc.dtsi"
There is no need for the "-soc" postfix, otherwise all the other SoCs inside DTS directory should have it.
Benoit
PATCH 12/14 dt: omap3: beagle board: set clock freq for i2c devices
Quoted 35 lines · Benoit
Quoted 21 lines · Manjunath Kondaiah
Update omap3 beagle dts file with required clock frequencies for the i2c client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3 soc dts file.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +---------- arch/arm/boot/dts/omap3-beagle.dts | 18 +++++++++++++++--- 2 files changed, 16 insertions(+), 13 deletions(-)arch/arm/boot/dts/omap3-beagle-nunchuck.dts +0
-0@@ -1,16 +1,7 @@ /include/ "omap3-beagle.dts" / {arch/arm/boot/dts/omap3-beagle-nunchuck.dts line 13
Quoted 10 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +0
-10- i2c at 48072000 { - compatible = "ti,omap3-i2c"; - reg =<0x48072000 0x80>; - #address-cells =<1>; - #size-cells =<0>; - - eeprom at 50 { - compatible = "at,at24c01"; - reg =< 0x50>; - };This change should probably not be there.
Quoted 6 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts line 6
Quoted 3 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +1
-0+ i2c at 2 { joystick at 52 { compatible = "sparkfun,wiichuck";It looks like someone is having fun with a beagle connected to a Wii nunchuck:-)
It's custom beagle belong to grant :)
Quoted 13 lines
arch/arm/boot/dts/omap3-beagle.dts line 1
Quoted 10 lines
arch/arm/boot/dts/omap3-beagle-nunchuck.dts +0
-0reg =< 0x52>;arch/arm/boot/dts/omap3-beagle.dts +1
-2@@ -1,7 +1,19 @@ -/dts-v1/; -/include/ "skeleton.dtsi" +/include/ "omap3-soc.dtsi"There is no need for the "-soc" postfix, otherwise all the other SoCs inside DTS directory should have it.
ok.
-M
PATCH 13/14 dt: omap3: add generic board file for dt support
In reply to G, Manjunath KondaiahThe generic board file is created and derived from beagle board file. The beagle board file is migrated to boot from flattened device tree and the cleanup of board specific file will happen in different stages.
The changes here focus on minimal configuration to boot beagle board with dt enabled which provides basic platform for converting device drivers for using dt.
--- arch/arm/mach-omap2/Kconfig | 11 ++++ arch/arm/mach-omap2/Makefile | 1 + arch/arm/mach-omap2/board-omap3-dt.c | 93 +++++++++++++++++++++++++++++++ arch/arm/mach-omap2/board-omap3beagle.c | 13 ---- 4 files changed, 105 insertions(+), 13 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
arch/arm/mach-omap2/Kconfig +11 -0
@@ -302,6 +302,17 @@ config MACH_OMAP_3630SDP default y select OMAP_PACKAGE_CBP +config MACH_OMAP3_DT + bool "Generic OMAP3 board(FDT support)" + depends on ARCH_OMAP3 + select OMAP_PACKAGE_CBB + select USE_OF + + help + Support for generic TI OMAP3 boards using Flattened Device Tree. + Say Y here to enable OMAP3 device tree support + More information at Documentation/devicetree + config MACH_TI8168EVM bool "TI8168 Evaluation Module" depends on SOC_OMAPTI816X
arch/arm/mach-omap2/Makefile +1 -0
@@ -187,6 +187,7 @@ obj-$(CONFIG_MACH_OVERO) += board-overo.o obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o +obj-$(CONFIG_MACH_OMAP3_DT) += board-omap3-dt.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \ sdram-nokia.o
arch/arm/mach-omap2/board-omap3-dt.c new file +93 -0
93 lines not on this page · raw message
arch/arm/mach-omap2/board-omap3beagle.c +0 -13
@@ -19,7 +19,6 @@#include <linux/err.h> #include <linux/clk.h> #include <linux/io.h> -#include <linux/of_platform.h> #include <linux/leds.h> #include <linux/gpio.h> #include <linux/input.h>
@@ -422,9 +421,7 @@ static int __init omap3_beagle_i2c_init(void)/* Bus 3 is attached to the DVI port where devices like the pico DLP * projector don't work reliably with 400kHz */ omap_register_i2c_bus (3 ,100 , beagle_i2c_eeprom,ARRAY_SIZE (beagle_i2c_eeprom)); -#ifdef CONFIG_OF omap_register_i2c_bus (2 ,100 ,NULL ,0 ); -#endif /* CONFIG_OF */ return 0 ; }
@@ -564,10 +561,6 @@ static void __init beagle_opp_init(void)static void __init omap3_beagle_init (void ) { -#ifdef CONFIG_OF -of_platform_prepare (NULL ,NULL ); -#endif /* CONFIG_OF */ -omap3_mux_init (board_mux,OMAP_PACKAGE_CBB );omap3_beagle_init_rev ();omap3_beagle_i2c_init ();
@@ -596,11 +589,6 @@ static void __init omap3_beagle_init(void)beagle_opp_init (); } -static const char *omap3_beagle_dt_match[]__initdata = { -"ti,omap3-beagle" , -NULL -}; -MACHINE_START (OMAP3_BEAGLE ,"OMAP3 Beagle Board" )/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */ .boot_params = 0x80000100,
@@ -610,5 +598,4 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board") .init_irq = omap3_beagle_init_irq, .init_machine = omap3_beagle_init, .timer = &omap_timer, - .dt_compat = omap3_beagle_dt_match,MACHINE_END
Signature · 1 line
1.7.1
PATCH 3/14 OMAP3: beagle: don't touch omap_device internals
In reply to G, Manjunath KondaiahFrom: Kevin Hilman <[email protected]>
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().
--- arch/arm/mach-omap2/board-omap3beagle.c | 27 ++++++++++++--------------- 1 files changed, 12 insertions(+), 15 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +12 -15
@@ -529,25 +529,24 @@ static void __init beagle_opp_init(void)return ; } -/* Custom OPP enabled for XM */ -if (omap3_beagle_get_rev () ==OMAP3BEAGLE_BOARD_XM ) { -struct omap_hwmod *mh =omap_hwmod_lookup ("mpu" ); -struct omap_hwmod *dh =omap_hwmod_lookup ("iva" ); -struct device *dev; +/* Custom OPP enabled for all xM versions */ +if (cpu_is_omap3630 ()) { +struct device *mpu_dev, *iva_dev; + + mpu_dev =omap2_get_mpuss_device (); + iva_dev =omap2_get_iva_device (); -if (!mh || !dh) { +if (!mpu_dev || !iva_dev) {pr_err ("%s: Aiee.. no mpu/dsp devices? %p %p\n" , - __func__, mh, dh); + __func__, mpu_dev, iva_dev);return ; }/* Enable MPU 1GHz and lower opps */ - dev = &mh->od->pdev.dev; - r =opp_enable (dev,800000000 ); + r =opp_enable (mpu_dev,800000000 );/* TODO: MPU 1GHz needs SR and ABB */ /* Enable IVA 800MHz and lower opps */ - dev = &dh->od->pdev.dev; - r |=opp_enable (dev,660000000 ); + r |=opp_enable (iva_dev,660000000 );/* TODO: DSP 800MHz needs SR and ABB */ if (r) { pr_err("%s: failed to enable higher opp %d\n",
@@ -556,10 +555,8 @@ static void __init beagle_opp_init(void)* Cleanup - disable the higher freqs - we dont care * about the results */ - dev = &mh->od->pdev.dev; -opp_disable (dev,800000000 ); - dev = &dh->od->pdev.dev; -opp_disable (dev,660000000 ); +opp_disable (mpu_dev,800000000 ); +opp_disable (iva_dev,660000000 ); } }return ;
Signature · 1 line
1.7.1
PATCH 5/14 OMAP: omap_device: remove internal functions from omap_device.h
In reply to G, Manjunath KondaiahFrom: Kevin Hilman <[email protected]>
The *_device_register() functions and the count/fill resources functions are internal to omap_device and do not need to be in the header.
--- arch/arm/plat-omap/include/plat/omap_device.h | 6 ------ arch/arm/plat-omap/omap_device.c | 12 ++++++++---- 2 files changed, 8 insertions(+), 10 deletions(-)
arch/arm/plat-omap/include/plat/omap_device.h +0 -6
@@ -83,9 +83,6 @@ int omap_device_shutdown(struct platform_device *pdev);/* Core code interface */ -int omap_device_count_resources (struct omap_device *od); -int omap_device_fill_resources (struct omap_device *od,struct resource *res); - struct omap_device *omap_device_build(const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len,
@@ -98,9 +95,6 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -int omap_device_register (struct omap_device *od); -int omap_early_device_register (struct omap_device *od); -void __iomem *omap_device_get_rt_va (struct omap_device *od);/* OMAP PM interface */
arch/arm/plat-omap/omap_device.c +8 -4
@@ -94,6 +94,9 @@#define USE_WAKEUP_LAT 0#define IGNORE_WAKEUP_LAT 1 +static int omap_device_register (struct omap_device *od); +static int omap_early_device_register (struct omap_device *od); +/* Private functions */ /**
@@ -325,7 +328,7 @@ u32 omap_device_get_context_loss_count(struct platform_device *pdev)* much memory to allocate before calling * omap_device_fill_resources(). Returns the count. */ -int omap_device_count_resources (struct omap_device *od) +static int omap_device_count_resources (struct omap_device *od) {int c =0 ;int i;
@@ -356,7 +359,8 @@ int omap_device_count_resources(struct omap_device *od)* functions to get device resources. Hacking around the existing * platform_device code wastes memory. Returns 0. */ -int omap_device_fill_resources (struct omap_device *od,struct resource *res) +static int omap_device_fill_resources (struct omap_device *od, +struct resource *res) {int c =0 ;int i, r;
@@ -520,7 +524,7 @@ odbs_exit1:* platform_early_add_device() on the underlying platform_device. * Returns 0 by default. */ -int omap_early_device_register (struct omap_device *od) +static int omap_early_device_register (struct omap_device *od) {struct platform_device *devices[1 ];
@@ -573,7 +577,7 @@ static struct dev_power_domain omap_device_power_domain = {* platform_device_register() on the underlying platform_device. * Returns the return value of platform_device_register(). */ -int omap_device_register (struct omap_device *od) +static int omap_device_register (struct omap_device *od) {pr_debug ("omap_device: %s: registering\n" , od->pdev.name);
Signature · 1 line
1.7.1
PATCH 6/14 OMAP: omap_device: when building return platform_device instead of omap_device
In reply to G, Manjunath KondaiahFrom: Kevin Hilman <[email protected]>
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 platform_device pointer or struct device pointer, so fixing all of the users was trivial.
This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals.
--- arch/arm/mach-omap2/devices.c | 44 ++++++++++++------------ arch/arm/mach-omap2/display.c | 6 ++-- arch/arm/mach-omap2/dma.c | 16 ++++---- arch/arm/mach-omap2/gpio.c | 8 ++-- arch/arm/mach-omap2/hsmmc.c | 8 ++-- arch/arm/mach-omap2/hwspinlock.c | 8 ++-- arch/arm/mach-omap2/mcbsp.c | 8 ++-- arch/arm/mach-omap2/pm.c | 8 ++-- arch/arm/mach-omap2/serial.c | 12 +++--- arch/arm/plat-omap/i2c.c | 8 ++-- arch/arm/plat-omap/include/plat/omap_device.h | 4 +- arch/arm/plat-omap/omap_device.c | 6 ++-- 12 files changed, 68 insertions(+), 68 deletions(-)
arch/arm/mach-omap2/devices.c +22 -22
@@ -44,7 +44,7 @@ static int __init omap3_l3_init(void) {int l;struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev;char oh_name[L3_MODULES_MAX_LEN ];/*
@@ -61,12 +61,12 @@ static int __init omap3_l3_init(void)if (!oh)pr_err ("could not look up %s\n" , oh_name); - od =omap_device_build ("omap_l3_smx" ,0 , oh,NULL ,0 , + pdev =omap_device_build ("omap_l3_smx" ,0 , oh,NULL ,0 ,NULL ,0 ,0 ); -WARN (IS_ERR (od),"could not build omap_device for %s\n" , oh_name); +WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name); -return IS_ERR (od) ?PTR_ERR (od) :0 ; +return IS_ERR (pdev) ?PTR_ERR (pdev) :0 ; }postcore_initcall (omap3_l3_init);
@@ -74,7 +74,7 @@ static int __init omap4_l3_init(void) {int l, i;struct omap_hwmod *oh[3 ]; -struct omap_device *od; +struct platform_device *pdev;char oh_name[L3_MODULES_MAX_LEN ];/*
@@ -92,12 +92,12 @@ static int __init omap4_l3_init(void)pr_err ("could not look up %s\n" , oh_name); } - od =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL , + pdev =omap_device_build_ss ("omap_l3_noc" ,0 , oh,3 ,NULL ,0 ,NULL ,0 ,0 ); -WARN (IS_ERR (od),"could not build omap_device for %s\n" , oh_name); +WARN (IS_ERR (pdev),"could not build omap_device for %s\n" , oh_name); -return IS_ERR (od) ?PTR_ERR (od) :0 ; +return IS_ERR (pdev) ?PTR_ERR (pdev) :0 ; }postcore_initcall (omap4_l3_init);
@@ -232,7 +232,7 @@ struct omap_device_pm_latency omap_keyboard_latency[] = {int __init omap4_keyboard_init (struct omap4_keypad_platform_data *sdp4430_keypad_data) { -struct omap_device *od; +struct platform_device *pdev;struct omap_hwmod *oh;struct omap4_keypad_platform_data *keypad_data;unsigned int id =-1 ;
@@ -247,15 +247,15 @@ int __init omap4_keyboard_init(struct omap4_keypad_platform_data keypad_data = sdp4430_keypad_data; - od =omap_device_build (name, id, oh, keypad_data, + pdev =omap_device_build (name, id, oh, keypad_data,sizeof (struct omap4_keypad_platform_data ), omap_keyboard_latency,ARRAY_SIZE (omap_keyboard_latency),0 ); -if (IS_ERR (od)) { +if (IS_ERR (pdev)) {WARN (1 ,"Can't build omap_device for %s:%s.\n" , name, oh->name); -return PTR_ERR (od); +return PTR_ERR (pdev); }return 0 ;
@@ -273,7 +273,7 @@ static struct omap_device_pm_latency mbox_latencies[] = {static inline void omap_init_mbox (void ) {struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev; oh =omap_hwmod_lookup ("mailbox" );if (!oh) {
@@ -281,10 +281,10 @@ static inline void omap_init_mbox(void)return ; } - od =omap_device_build ("omap-mailbox" ,-1 , oh,NULL ,0 , + pdev =omap_device_build ("omap-mailbox" ,-1 , oh,NULL ,0 , mbox_latencies,ARRAY_SIZE (mbox_latencies),0 ); -WARN (IS_ERR (od),"%s: could not build device, err %ld\n" , - __func__, PTR_ERR(od)); +WARN (IS_ERR (pdev),"%s: could not build device, err %ld\n" , + __func__, PTR_ERR(pdev)); }#else static inline void omap_init_mbox (void ) { }
@@ -343,7 +343,7 @@ struct omap_device_pm_latency omap_mcspi_latency[] = {static int omap_mcspi_init (struct omap_hwmod *oh,void *unused) { -struct omap_device *od; +struct platform_device *pdev;char *name ="omap2_mcspi" ;struct omap2_mcspi_platform_config *pdata;static int spi_num;
@@ -370,10 +370,10 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void *unused) } spi_num++; - od =omap_device_build (name, spi_num, oh, pdata, + pdev =omap_device_build (name, spi_num, oh, pdata,sizeof (*pdata), omap_mcspi_latency,ARRAY_SIZE (omap_mcspi_latency),0 ); -WARN (IS_ERR (od),"Can't build omap_device for %s:%s\n" , +WARN (IS_ERR (pdev),"Can't build omap_device for %s:%s\n" , name, oh->name);kfree (pdata);return 0 ;
@@ -708,7 +708,7 @@ static struct omap_device_pm_latency omap_wdt_latency[] = {static int __init omap_init_wdt (void ) {int id =-1 ; -struct omap_device *od; +struct platform_device *pdev;struct omap_hwmod *oh;char *oh_name ="wd_timer2" ;char *dev_name ="omap_wdt" ;
@@ -722,10 +722,10 @@ static int __init omap_init_wdt(void)return -EINVAL ; } - od =omap_device_build (dev_name, id, oh,NULL ,0 , + pdev =omap_device_build (dev_name, id, oh,NULL ,0 , omap_wdt_latency,ARRAY_SIZE (omap_wdt_latency),0 ); -WARN (IS_ERR (od),"Can't build omap_device for %s:%s.\n" , +WARN (IS_ERR (pdev),"Can't build omap_device for %s:%s.\n" , dev_name, oh->name);return 0 ; }
arch/arm/mach-omap2/display.c +3 -3
@@ -91,7 +91,7 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) {int r =0 ;struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev;int i, oh_count;struct omap_display_platform_data pdata;const struct omap_dss_hwmod_data *curr_dss_hwmod;
@@ -128,13 +128,13 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)return -ENODEV ; } - od =omap_device_build (curr_dss_hwmod[i].dev_name, + pdev =omap_device_build (curr_dss_hwmod[i].dev_name, curr_dss_hwmod[i].id, oh, &pdata,sizeof (struct omap_display_platform_data ), omap_dss_latency,ARRAY_SIZE (omap_dss_latency),0 ); -if (WARN ((IS_ERR (od)),"Could not build omap_device for %s\n" , +if (WARN ((IS_ERR (pdev)),"Could not build omap_device for %s\n" , curr_dss_hwmod[i].oh_name))return -ENODEV ; }
arch/arm/mach-omap2/dma.c +8 -8
@@ -228,7 +228,7 @@ static u32 configure_dma_errata(void)/* One time initializations */ static int __init omap2_system_dma_init_dev (struct omap_hwmod *oh,void *unused) { -struct omap_device *od; +struct platform_device *pdev;struct omap_system_dma_plat_info *p;struct resource *mem;char *name ="omap_dma_system" ;
@@ -258,23 +258,23 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) p->errata =configure_dma_errata (); - od =omap_device_build (name,0 , oh, p,sizeof (*p), + pdev =omap_device_build (name,0 , oh, p,sizeof (*p), omap2_dma_latency,ARRAY_SIZE (omap2_dma_latency),0 );kfree (p); -if (IS_ERR (od)) { +if (IS_ERR (pdev)) {pr_err ("%s: Can't build omap_device for %s:%s.\n" , __func__, name, oh->name); -return PTR_ERR (od); +return PTR_ERR (pdev); } - mem =platform_get_resource (&od->pdev,IORESOURCE_MEM ,0 ); + mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 );if (!mem) { -dev_err (&od->pdev.dev,"%s: no mem resource\n" , __func__); +dev_err (&pdev->dev,"%s: no mem resource\n" , __func__);return -EINVAL ; } dma_base =ioremap (mem->start,resource_size (mem));if (!dma_base) { -dev_err (&od->pdev.dev,"%s: ioremap fail\n" , __func__); +dev_err (&pdev->dev,"%s: ioremap fail\n" , __func__);return -ENOMEM ; }
@@ -283,7 +283,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) (d->lch_count), GFP_KERNEL);if (!d->chan) { -dev_err (&od->pdev.dev,"%s: kzalloc fail\n" , __func__); +dev_err (&pdev->dev,"%s: kzalloc fail\n" , __func__);return -ENOMEM ; }return 0 ;
arch/arm/mach-omap2/gpio.c +4 -4
@@ -34,7 +34,7 @@ static struct omap_device_pm_latency omap_gpio_latency[] = {static int omap2_gpio_dev_init (struct omap_hwmod *oh,void *unused) { -struct omap_device *od; +struct platform_device *pdev;struct omap_gpio_platform_data *pdata;struct omap_gpio_dev_attr *dev_attr;char *name ="omap_gpio" ;
@@ -75,16 +75,16 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)return -EINVAL ; } - od =omap_device_build (name, id -1 , oh, pdata, + pdev =omap_device_build (name, id -1 , oh, pdata,sizeof (*pdata), omap_gpio_latency,ARRAY_SIZE (omap_gpio_latency), false);kfree (pdata); -if (IS_ERR (od)) { +if (IS_ERR (pdev)) {WARN (1 ,"Can't build omap_device for %s:%s.\n" , name, oh->name); -return PTR_ERR (od); +return PTR_ERR (pdev); } gpio_bank_count++;
arch/arm/mach-omap2/hsmmc.c +4 -4
@@ -431,7 +431,7 @@ static struct omap_device_pm_latency omap_hsmmc_latency[] = {void __init omap_init_hsmmc (struct omap2_hsmmc_info *hsmmcinfo,int ctrl_nr) {struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev;struct omap_device_pm_latency *ohl;char oh_name[MAX_OMAP_MMC_HWMOD_NAME_LEN ];struct omap_mmc_platform_data *mmc_data;
@@ -472,9 +472,9 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr) mmc_data->controller_flags = mmc_dev_attr->flags; } - od =omap_device_build (name, ctrl_nr -1 , oh, mmc_data, + pdev =omap_device_build (name, ctrl_nr -1 , oh, mmc_data,sizeof (struct omap_mmc_platform_data ), ohl, ohl_cnt, false); -if (IS_ERR (od)) { +if (IS_ERR (pdev)) {WARN (1 ,"Can't build omap_device for %s:%s.\n" , name, oh->name);kfree (mmc_data->slots[0 ].name); goto done;
@@ -483,7 +483,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)* return device handle to board setup code * required to populate for regulator framework structure */ - hsmmcinfo->dev = &od->pdev.dev; + hsmmcinfo->dev = &pdev->dev; done:kfree (mmc_data);
arch/arm/mach-omap2/hwspinlock.c +4 -4
@@ -35,7 +35,7 @@ int __init hwspinlocks_init(void) {int retval =0 ;struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev;const char *oh_name ="spinlock" ;const char *dev_name ="omap_hwspinlock" ;
@@ -48,13 +48,13 @@ int __init hwspinlocks_init(void)if (oh ==NULL )return -EINVAL ; - od =omap_device_build (dev_name,0 , oh,NULL ,0 , + pdev =omap_device_build (dev_name,0 , oh,NULL ,0 , omap_spinlock_latency,ARRAY_SIZE (omap_spinlock_latency), false); -if (IS_ERR (od)) { +if (IS_ERR (pdev)) {pr_err ("Can't build omap_device for %s:%s\n" , dev_name, oh_name); - retval =PTR_ERR (od); + retval =PTR_ERR (pdev); }return retval;
arch/arm/mach-omap2/mcbsp.c +4 -4
@@ -116,7 +116,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)char *name ="omap-mcbsp" ;struct omap_hwmod *oh_device[2 ];struct omap_mcbsp_platform_data *pdata =NULL ; -struct omap_device *od; +struct platform_device *pdev;sscanf (oh->name,"mcbsp%d" , &id);
@@ -144,14 +144,14 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone); count++; } - od =omap_device_build_ss (name, id, oh_device, count, pdata, + pdev =omap_device_build_ss (name, id, oh_device, count, pdata,sizeof (*pdata), omap2_mcbsp_latency,ARRAY_SIZE (omap2_mcbsp_latency), false);kfree (pdata); -if (IS_ERR (od)) { +if (IS_ERR (pdev)) {pr_err ("%s: Can't build omap_device for %s:%s.\n" , __func__, name, oh->name); -return PTR_ERR (od); +return PTR_ERR (pdev); } omap_mcbsp_count++;return 0 ;
arch/arm/mach-omap2/pm.c +4 -4
@@ -60,19 +60,19 @@ EXPORT_SYMBOL(omap4_get_dsp_device);static int _init_omap_device (char *name,struct device **new_dev) {struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev; oh =omap_hwmod_lookup (name);if (WARN (!oh,"%s: could not find omap_hwmod for %s\n" , __func__, name))return -ENODEV ; - od =omap_device_build (oh->name,0 , oh,NULL ,0 , pm_lats,0 , false); -if (WARN (IS_ERR (od),"%s: could not build omap_device for %s\n" , + pdev =omap_device_build (oh->name,0 , oh,NULL ,0 , pm_lats,0 , false); +if (WARN (IS_ERR (pdev),"%s: could not build omap_device for %s\n" , __func__, name))return -ENODEV ; - *new_dev = &od->pdev.dev; + *new_dev = &pdev->dev;return 0 ; }
arch/arm/mach-omap2/serial.c +6 -6
@@ -711,7 +711,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata) {struct omap_uart_state *uart;struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev;void *pdata =NULL ;u32 pdata_size =0 ;char *name;
@@ -799,10 +799,10 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)if (WARN_ON (!oh))return ; - od =omap_device_build (name, uart->num, oh, pdata, pdata_size, + pdev =omap_device_build (name, uart->num, oh, pdata, pdata_size, omap_uart_latency,ARRAY_SIZE (omap_uart_latency), false); -WARN (IS_ERR (od),"Could not build omap_device for %s: %s.\n" , +WARN (IS_ERR (pdev),"Could not build omap_device for %s: %s.\n" , name, oh->name); oh->mux =omap_hwmod_mux_init (bdata->pads, bdata->pads_cnt);
@@ -811,7 +811,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata) uart->regshift =2 ; uart->mapbase = oh->slaves[0 ]->addr->pa_start; uart->membase =omap_hwmod_get_mpu_rt_va (oh); - uart->pdev = &od->pdev; + uart->pdev = pdev; oh->dev_attr = uart;
@@ -845,8 +845,8 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)if ((cpu_is_omap34xx () && uart->padconf) || (uart->wk_en && uart->wk_mask)) { -device_init_wakeup (&od->pdev.dev, true); -DEV_CREATE_FILE (&od->pdev.dev, &dev_attr_sleep_timeout); +device_init_wakeup (&pdev->dev, true); +DEV_CREATE_FILE (&pdev->dev, &dev_attr_sleep_timeout); }/* Enable the MDR1 errata for OMAP3 */
arch/arm/plat-omap/i2c.c +4 -4
@@ -135,7 +135,7 @@ static inline int omap2_i2c_add_bus(int bus_id) {int l;struct omap_hwmod *oh; -struct omap_device *od; +struct platform_device *pdev;char oh_name[MAX_OMAP_I2C_HWMOD_NAME_LEN ];struct omap_i2c_bus_platform_data *pdata;
@@ -160,12 +160,12 @@ static inline int omap2_i2c_add_bus(int bus_id)*/ if (cpu_is_omap34xx ()) pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat; - od =omap_device_build (name, bus_id, oh, pdata, + pdev =omap_device_build (name, bus_id, oh, pdata,sizeof (struct omap_i2c_bus_platform_data ), omap_i2c_latency,ARRAY_SIZE (omap_i2c_latency),0 ); -WARN (IS_ERR (od),"Could not build omap_device for %s\n" , name); +WARN (IS_ERR (pdev),"Could not build omap_device for %s\n" , name); - return PTR_ERR(od); + return PTR_ERR(pdev); }#else static inline int omap2_i2c_add_bus (int bus_id)
arch/arm/plat-omap/include/plat/omap_device.h +2 -2
@@ -83,13 +83,13 @@ int omap_device_shutdown(struct platform_device *pdev);/* Core code interface */ -struct omap_device *omap_device_build (const char *pdev_name,int pdev_id, +struct platform_device *omap_device_build (const char *pdev_name,int pdev_id,struct omap_hwmod *oh,void *pdata,int pdata_len,struct omap_device_pm_latency *pm_lats,int pm_lats_cnt,int is_early_device); -struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_hwmod **oh, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,
arch/arm/plat-omap/omap_device.c +3 -3
@@ -391,7 +391,7 @@ static int omap_device_fill_resources(struct omap_device *od,* information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct omap_device *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,
@@ -424,7 +424,7 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,* platform_device record. Returns an ERR_PTR() on error, or passes * along the return value of omap_device_register(). */ -struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_hwmod **ohs, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats,
@@ -499,7 +499,7 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,if (ret) goto odbs_exit4; -return od; +return &od->pdev; odbs_exit4:kfree (res);
Signature · 1 line
1.7.1
PATCH 7/14 ARM: platform_device: pdev_archdata: add omap_device pointer
In reply to G, Manjunath KondaiahFrom: Kevin Hilman <[email protected]>
Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime.
--- arch/arm/include/asm/device.h | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
arch/arm/include/asm/device.h +5 -0
@@ -12,7 +12,12 @@ struct dev_archdata { #endif }; +struct omap_device ; +struct pdev_archdata { +#ifdef CONFIG_ARCH_OMAP +struct omap_device *od; +#endif };#endif
Signature · 1 line
1.7.1
PATCH 10/14 dt: Add pd_size to AUXDATA structure
In reply to G, Manjunath KondaiahAdd pd_size in the AUXDATA structure so that device drivers which require platform_data size can pass along with AUXDATA.
--- drivers/of/platform.c | 2 ++ include/linux/of_platform.h | 5 +++++ 2 files changed, 7 insertions(+), 0 deletions(-)
drivers/of/platform.c +2 -0
@@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node *bus,struct platform_device *dev;const char *bus_id =NULL ;void *platform_data =NULL ; +int pd_size;int id =-1 ;int rc =0 ;
@@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus, bus_id = auxdata->name; id = auxdata->id; platform_data = auxdata->platform_data; + pd_size = auxdata->pd_size; }if (of_device_is_compatible (bus,"arm,primecell" )) {
include/linux/of_platform.h +5 -0
@@ -47,6 +47,7 @@ struct of_dev_auxdata {char *name;int id;void *platform_data; +int pd_size; };/* Macro to simplify populating a lookup table */
@@ -58,6 +59,10 @@ struct of_dev_auxdata { { .compatible = _compat, .phys_addr = _phys, .name = _name, \ .id = _id, .platform_data = _pdata } +#define OF_DEV_AUXDATA_ID_PDSIZE (_compat,_phys,_name,_id,_pdata,_pd_size) \ + { .compatible = _compat, .phys_addr = _phys, .name = _name, \ + .id = _id, .platform_data = _pdata, .pd_size = _pd_size } +/** * of_platform_driver - Legacy of-aware driver for platform devices. *
Signature · 1 line
1.7.1
PATCH 10/14 dt: Add pd_size to AUXDATA structure
Quoted 3 lines · Manjunath Kondaiah
Add
pd_sizein the AUXDATA structure so that device drivers which requireplatform_datasize can pass along with AUXDATA.
It is really needed by device driver? Or is it because omap_device_build is using platform_device_add_data that is doing a copy of the pdata and thus require the size?
Quoted 11 lines
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- drivers/of/platform.c | 2 ++ include/linux/of_platform.h | 5 +++++ 2 files changed, 7 insertions(+), 0 deletions(-)drivers/of/platform.c +0
-0
drivers/of/platform.c static int of_platform_bus_create(struct device_node *bus, · line 568
Quoted 4 lines
drivers/of/platform.c +1
-0@@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node *bus,struct platform_device *dev;const char *bus_id =NULL ;void *platform_data =NULL ; +int pd_size;
Maybe platform_data_size will be a little bit more consistent?
Regards,
Benoit
Quoted 34 lines
drivers/of/platform.c +1
-0int id =-1 ;int rc =0 ;@@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus, bus_id = auxdata->name; id = auxdata->id; platform_data = auxdata->platform_data; + pd_size = auxdata->pd_size; }if (of_device_is_compatible (bus,"arm,primecell" )) {include/linux/of_platform.h +5
-0@@ -47,6 +47,7 @@ struct of_dev_auxdata {char *name;int id;void *platform_data; +int pd_size; };/* Macro to simplify populating a lookup table */ @@ -58,6 +59,10 @@ struct of_dev_auxdata { { .compatible = _compat, .phys_addr = _phys, .name = _name, \ .id = _id, .platform_data = _pdata } +#define OF_DEV_AUXDATA_ID_PDSIZE (_compat,_phys,_name,_id,_pdata,_pd_size) \ + { .compatible = _compat, .phys_addr = _phys, .name = _name, \ + .id = _id, .platform_data = _pdata, .pd_size = _pd_size } +/** * of_platform_driver - Legacy of-aware driver for platform devices. *
PATCH 10/14 dt: Add pd_size to AUXDATA structure
Quoted 8 lines · Benoit
Quoted 3 lines · Manjunath Kondaiah
Add
pd_sizein the AUXDATA structure so that device drivers which requireplatform_datasize can pass along with AUXDATA.It is really needed by device driver? Or is it because
omap_device_buildis usingplatform_device_add_datathat is doing a copy of the pdata and thus require the size?
Yes, I have the same question. What is the reason for needing the platform data size?
g.
Quoted 66 lines
Quoted 12 lines
Signed-off-by G, Manjunath Kondaiah<[email protected]>---
?drivers/of/platform.c ? ? ? | ? ?2 ++
?include/linux/of_platform.h | ? ?5 +++++
?2 files changed, 7 insertions(+), 0 deletions(-)drivers/of/platform.c +0
-0drivers/of/platform.c static int of_platform_bus_create(struct device_node · line 569
Quoted 5 lines
drivers/of/platform.c +1
-0@@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node *bus, ? ? ? ?struct platform_device *dev; ? ? ? ?const char *bus_id = NULL; ? ? ? ?void *platform_data = NULL; + ? ? ? int pd_size;Maybe
platform_data_sizewill be a little bit more consistent?Regards,
BenoitQuoted 33 lines
drivers/of/platform.c +1
-0? ? ? ?int id = -1; ? ? ? ?int rc = 0;@@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus, ? ? ? ? ? ? ? ?bus_id = auxdata->name; ? ? ? ? ? ? ? ?id = auxdata->id; ? ? ? ? ? ? ? ?platform_data = auxdata->platform_data; + ? ? ? ? ? ? ? pd_size = auxdata->pd_size; ? ? ? ?}? ? ? ?if (
of_device_is_compatible(bus, "arm,primecell")) {include/linux/of_platform.h +1
-0@@ -47,6 +47,7 @@ struct of_dev_auxdata { ? ? ? ?char *name; ? ? ? ?int id; ? ? ? ?void *platform_data; + ? ? ? int pd_size; ?};?/* Macro to simplify populating a lookup table */
include/linux/of_platform.h +4
-0@@ -58,6 +59,10 @@ struct of_dev_auxdata { ? ? ? ?{ .compatible = _compat, .phys_addr = _phys, .name = _name, \ ? ? ? ? ?.id = _id, .platform_data = _pdata } +#define OF_DEV_AUXDATA_ID_PDSIZE (_compat,_phys,_name,_id,_pdata,_pd_size) \ + ? ? ? { .compatible = _compat, .phys_addr = _phys, .name = _name, \ + ? ? ? ? .id = _id, .platform_data = _pdata, .pd_size = _pd_size } +Quoted 3 lines
?/**
? *of_platform_driver- Legacy of-aware driver for platform devices. ? *_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 2 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
PATCH 10/14 dt: Add pd_size to AUXDATA structure
Quoted 6 lines · Grant Likely
Quoted 5 lines · Benoit
Quoted 3 lines · Manjunath Kondaiah
Add
pd_sizein the AUXDATA structure so that device drivers which requireplatform_datasize can pass along with AUXDATA.
Quoted 6 lines
Quoted 3 lines
It is really needed by device driver? Or is it because
omap_device_buildis usingplatform_device_add_datathat is doing a copy of the pdata and thus require the size?Yes, I have the same question. What is the reason for needing the platform data size?
Yes. It is required by "omap_device_build" which in turn calls "platform_device_add_data" and copies using "kmemdup" and original pdata pointer memory will get freed.
It is required by hwmod and not device driver. I can change description.
Quoted 22 lines
g.
Quoted 19 lines
Quoted 12 lines
Signed-off-by G, Manjunath Kondaiah<[email protected]>---
?drivers/of/platform.c ? ? ? | ? ?2 ++
?include/linux/of_platform.h | ? ?5 +++++
?2 files changed, 7 insertions(+), 0 deletions(-)drivers/of/platform.c +0
-0drivers/of/platform.c static int of_platform_bus_create(struct device_node · line 569
Quoted 5 lines
drivers/of/platform.c +1
-0@@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node *bus, ? ? ? ?struct platform_device *dev; ? ? ? ?const char *bus_id = NULL; ? ? ? ?void *platform_data = NULL; + ? ? ? int pd_size;Maybe
platform_data_sizewill be a little bit more consistent?
Thought shorter name is better and still it should be readable.
-M
PATCH 14/14 dt: omap3: enable dt support for i2c1 controller
In reply to G, Manjunath KondaiahAdapt dt for omap i2c1 controller and remove legacy i2c initilization in omap3 generic board file.
Tested on omap3 beagle board for dt and non-dt builds.
--- arch/arm/boot/dts/omap3-soc.dtsi | 6 ++-- arch/arm/mach-omap2/board-omap3-dt.c | 14 +++++----- drivers/i2c/busses/i2c-omap.c | 23 ++++++++++++++++-- drivers/of/platform.c | 41 +++++++++++++++++++++++++++++++++- 4 files changed, 70 insertions(+), 14 deletions(-)
arch/arm/boot/dts/omap3-soc.dtsi +3 -3
@@ -31,7 +31,7 @@ i2c1: i2c@70000 { #address-cells = <1>; #size-cells = <0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg = <0x70000 0x100>; interrupts = < 88 >; };
@@ -39,7 +39,7 @@ i2c2: i2c@72000 { #address-cells = <1>; #size-cells = <0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg = <0x72000 0x100>; interrupts = < 89 >; };
@@ -47,7 +47,7 @@ i2c3: i2c@60000 { #address-cells = <1>; #size-cells = <0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg = <0x60000 0x100>; interrupts = < 93 >; };
arch/arm/mach-omap2/board-omap3-dt.c +7 -7
@@ -36,11 +36,11 @@ static struct twl4030_platform_data beagle_twldata = {/* platform_data for children goes here */ }; -static int __init omap3_beagle_i2c_init (void ) -{ -omap3_pmic_init ("twl4030" , &beagle_twldata); -return 0 ; -} +struct of_dev_auxdata omap3_auxdata_lookup[]__initdata = { +OF_DEV_AUXDATA_ID_PDSIZE ("ti,omap3-i2c" ,0x48070000 ,"i2c1" ,1 ,\ + &beagle_twldata,sizeof (beagle_twldata)), + {} +};static void __init omap3_init_early (void ) {
@@ -70,11 +70,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {static void __init omap3_init (void ) { -omap3_beagle_i2c_init ();omap3_mux_init (board_mux,OMAP_PACKAGE_CBB );omap_serial_init (); -of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); +of_platform_populate (NULL , omap_dt_match_table, omap3_auxdata_lookup, +NULL ); }static const char *omap3_dt_match[]__initdata = {
drivers/i2c/busses/i2c-omap.c +20 -3
@@ -38,6 +38,7 @@#include <linux/clk.h> #include <linux/io.h> #include <linux/of_i2c.h> +#include <linux/of_device.h> #include <linux/slab.h> #include <linux/i2c-omap.h> #include <linux/pm_runtime.h>
@@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = { .functionality = omap_i2c_func, }; +#if defined(CONFIG_OF ) +static const struct of_device_id omap_i2c_of_match[] = { + {.compatible ="ti,omap3-i2c" , }, + {}, +} +MODULE_DEVICE_TABLE (of, omap_i2c_of_match); +#else +#define omap_i2c_of_match NULL +#endif +static int __devinit omap_i2c_probe (struct platform_device *pdev) {
@@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev) goto err_release_region; } + speed =100 ;/* Default speed */ if (pdata !=NULL ) { speed = pdata->clkrate; dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat; - }else { - speed =100 ;/* Default speed */ - dev->set_mpu_wkup_lat =NULL ; +#if defined(CONFIG_OF ) + } else if (pdev->dev.of_node) { +u32 prop; +if (!of_property_read_u32 (pdev->dev.of_node,"clock-frequency" , + &prop)) + speed = prop/100 ; +#endif } dev->speed = speed;
@@ -1178,6 +1194,7 @@ static struct platform_driver omap_i2c_driver = { .name = "omap_i2c", .owner = THIS_MODULE, .pm = OMAP_I2C_PM_OPS, + .of_match_table = omap_i2c_of_match, }, };
drivers/of/platform.c +40 -1
65 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 14/14 dt: omap3: enable dt support for i2c1 controller
Quoted 4 lines · Manjunath Kondaiah
Adapt dt for omap i2c1 controller and remove legacy i2c initilization in omap3 generic board file.
Quoted 8 lines
Tested on omap3 beagle board for dt and non-dt builds.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-soc.dtsi | 6 ++-- arch/arm/mach-omap2/board-omap3-dt.c | 14 +++++----- drivers/i2c/busses/i2c-omap.c | 23 ++++++++++++++++-- drivers/of/platform.c | 41 +++++++++++++++++++++++++++++++++-
It looks like this patch is doing a lot of things. You should probably hack the DT core first and then update the driver and the DTS.
arch/arm/boot/dts/omap3-soc.dtsi line 34
Quoted 12 lines
4 files changed, 70 insertions(+), 14 deletions(-)arch/arm/boot/dts/omap3-soc.dtsi +1
-1@@ -31,7 +31,7 @@ i2c1: i2c at 70000 { #address-cells =<1>; #size-cells =<0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device";
In that case the compatible is just a tagto identify an OMAP type of devices. You should use a more generic "ti,omap-device" entry. This is similar to the "arm,primecell" used to tag the primecell IPs.
Quoted 69 lines
arch/arm/boot/dts/omap3-soc.dtsi +2
-2reg =<0x70000 0x100>; interrupts =< 88>; };@@ -39,7 +39,7 @@ i2c2: i2c at 72000 { #address-cells =<1>; #size-cells =<0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg =<0x72000 0x100>; interrupts =< 89>; };@@ -47,7 +47,7 @@ i2c3: i2c at 60000 { #address-cells =<1>; #size-cells =<0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg =<0x60000 0x100>; interrupts =< 93>; };arch/arm/mach-omap2/board-omap3-dt.c +7
-7@@ -36,11 +36,11 @@ static struct twl4030_platform_data beagle_twldata = {/* platform_data for children goes here */ }; -static int __init omap3_beagle_i2c_init (void ) -{ -omap3_pmic_init ("twl4030" ,&beagle_twldata); -return 0 ; -} +struct of_dev_auxdata omap3_auxdata_lookup[]__initdata = { +OF_DEV_AUXDATA_ID_PDSIZE ("ti,omap3-i2c" ,0x48070000 ,"i2c1" ,1 ,\ + &beagle_twldata,sizeof (beagle_twldata)), + {} +};static void __init omap3_init_early (void ) {@@ -70,11 +70,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {static void __init omap3_init (void ) { -omap3_beagle_i2c_init ();omap3_mux_init (board_mux,OMAP_PACKAGE_CBB );omap_serial_init (); -of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); +of_platform_populate (NULL , omap_dt_match_table, omap3_auxdata_lookup, +NULL ); }static const char *omap3_dt_match[]__initdata = {drivers/i2c/busses/i2c-omap.c +1
-0@@ -38,6 +38,7 @@#include <linux/clk.h> #include <linux/io.h> #include <linux/of_i2c.h> +#include <linux/of_device.h> #include <linux/slab.h> #include <linux/i2c-omap.h> #include <linux/pm_runtime.h>
drivers/i2c/busses/i2c-omap.c static const struct i2c_algorithm omap_i2c_algo = { · line 978
Quoted 6 lines
drivers/i2c/busses/i2c-omap.c +3
-0@@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = { .functionality = omap_i2c_func, }; +#if defined(CONFIG_OF) +static const struct of_device_id omap_i2c_of_match[] = { + {.compatible = "ti,omap3-i2c", },.
This is a generic OMAP driver, so a "ti,omap-i2c" is probably much more appropriate. We should always avoid adding OMAP version information into a generic driver. Only the IP version should matter for a driver.
Quoted 64 lines
drivers/i2c/busses/i2c-omap.c +16
-3+ {}, +} +MODULE_DEVICE_TABLE (of, omap_i2c_of_match); +#else +#define omap_i2c_of_match NULL +#endif +static int __devinit omap_i2c_probe (struct platform_device *pdev) {@@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev) goto err_release_region; } + speed =100 ;/* Default speed */ if (pdata !=NULL ) { speed = pdata->clkrate; dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat; - }else { - speed =100 ;/* Default speed */ - dev->set_mpu_wkup_lat =NULL ; +#if defined(CONFIG_OF ) + } else if (pdev->dev.of_node) { +u32 prop; +if (!of_property_read_u32 (pdev->dev.of_node,"clock-frequency" , + &prop)) + speed = prop/100 ; +#endif } dev->speed = speed;@@ -1178,6 +1194,7 @@ static struct platform_driver omap_i2c_driver = { .name = "omap_i2c", .owner = THIS_MODULE, .pm = OMAP_I2C_PM_OPS, + .of_match_table = omap_i2c_of_match, }, };drivers/of/platform.c +10
-0@@ -24,6 +24,10 @@#include <linux/of_platform.h> #include <linux/platform_device.h> +#ifdef CONFIG_ARCH_OMAP2PLUS +#include <plat/omap_device.h> +#endif +const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, #ifdef CONFIG_ARM_AMBA@@ -544,6 +548,36 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *lreturn NULL ; } +static struct omap_device_pm_latency omap_device_latency[] = { + [0 ] = { + .deactivate_func = omap_device_idle_hwmods, + .activate_func = omap_device_enable_hwmods, + .flags =OMAP_DEVICE_LATENCY_AUTO_ADJUST , + },
drivers/of/platform.c static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l · line 566
Quoted 10 lines
drivers/of/platform.c +10
-0+}; + +int of_omap_device_create (struct device_node *np,const char *name,int id, +void *platform_data, +int pd_size) +{ +struct omap_hwmod *oh; +struct platform_device *pdev; + + oh =omap_hwmod_lookup (name);
This is not enough to handle multiple hwmod entries. Moreover you will force the device to be named like the hwmod. This is not necessarily bad, but we should be able to have a distinct name if needed.
Benoit
PATCH 14/14 dt: omap3: enable dt support for i2c1 controller
Quoted 187 lines · Benoit
Quoted 4 lines · Manjunath Kondaiah
Adapt dt for omap i2c1 controller and remove legacy i2c initilization in omap3 generic board file.
Quoted 8 lines
Tested on omap3 beagle board for dt and non-dt builds.
Signed-off-by G, Manjunath Kondaiah<[email protected]>--- arch/arm/boot/dts/omap3-soc.dtsi | 6 ++-- arch/arm/mach-omap2/board-omap3-dt.c | 14 +++++----- drivers/i2c/busses/i2c-omap.c | 23 ++++++++++++++++-- drivers/of/platform.c | 41 +++++++++++++++++++++++++++++++++-It looks like this patch is doing a lot of things. You should probably hack the DT core first and then update the driver and the DTS.
arch/arm/boot/dts/omap3-soc.dtsi line 34
Quoted 12 lines
4 files changed, 70 insertions(+), 14 deletions(-)arch/arm/boot/dts/omap3-soc.dtsi +1
-1@@ -31,7 +31,7 @@ i2c1: i2c at 70000 { #address-cells =<1>; #size-cells =<0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device";In that case the compatible is just a tagto identify an OMAP type of devices. You should use a more generic "ti,omap-device" entry. This is similar to the "arm,primecell" used to tag the primecell IPs.
Quoted 69 lines
arch/arm/boot/dts/omap3-soc.dtsi +2
-2reg =<0x70000 0x100>; interrupts =< 88>; };@@ -39,7 +39,7 @@ i2c2: i2c at 72000 { #address-cells =<1>; #size-cells =<0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg =<0x72000 0x100>; interrupts =< 89>; };@@ -47,7 +47,7 @@ i2c3: i2c at 60000 { #address-cells =<1>; #size-cells =<0>; - compatible = "ti,omap3-i2c"; + compatible = "ti,omap3-i2c", "ti,omap3-device"; reg =<0x60000 0x100>; interrupts =< 93>; };arch/arm/mach-omap2/board-omap3-dt.c +7
-7@@ -36,11 +36,11 @@ static struct twl4030_platform_data beagle_twldata = {/* platform_data for children goes here */ }; -static int __init omap3_beagle_i2c_init (void ) -{ -omap3_pmic_init ("twl4030" ,&beagle_twldata); -return 0 ; -} +struct of_dev_auxdata omap3_auxdata_lookup[]__initdata = { +OF_DEV_AUXDATA_ID_PDSIZE ("ti,omap3-i2c" ,0x48070000 ,"i2c1" ,1 ,\ + &beagle_twldata,sizeof (beagle_twldata)), + {} +};static void __init omap3_init_early (void ) {@@ -70,11 +70,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {static void __init omap3_init (void ) { -omap3_beagle_i2c_init ();omap3_mux_init (board_mux,OMAP_PACKAGE_CBB );omap_serial_init (); -of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); +of_platform_populate (NULL , omap_dt_match_table, omap3_auxdata_lookup, +NULL ); }static const char *omap3_dt_match[]__initdata = {drivers/i2c/busses/i2c-omap.c +1
-0@@ -38,6 +38,7 @@#include <linux/clk.h> #include <linux/io.h> #include <linux/of_i2c.h> +#include <linux/of_device.h> #include <linux/slab.h> #include <linux/i2c-omap.h> #include <linux/pm_runtime.h> drivers/i2c/busses/i2c-omap.c static const struct i2c_algorithm omap_i2c_algo = { · line 978
Quoted 6 lines
drivers/i2c/busses/i2c-omap.c +3
-0@@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = { .functionality = omap_i2c_func, }; +#if defined(CONFIG_OF) +static const struct of_device_id omap_i2c_of_match[] = { + {.compatible = "ti,omap3-i2c", },.This is a generic OMAP driver, so a "ti,omap-i2c" is probably much more appropriate. We should always avoid adding OMAP version information into a generic driver. Only the IP version should matter for a driver.
Quoted 71 lines
drivers/i2c/busses/i2c-omap.c +16
-3+ {}, +} +MODULE_DEVICE_TABLE (of, omap_i2c_of_match); +#else +#define omap_i2c_of_match NULL +#endif +static int __devinit omap_i2c_probe (struct platform_device *pdev) {@@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev) goto err_release_region; } + speed =100 ;/* Default speed */ if (pdata !=NULL ) { speed = pdata->clkrate; dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat; - }else { - speed =100 ;/* Default speed */ - dev->set_mpu_wkup_lat =NULL ; +#if defined(CONFIG_OF ) + } else if (pdev->dev.of_node) { +u32 prop; +if (!of_property_read_u32 (pdev->dev.of_node,"clock-frequency" , + &prop)) + speed = prop/100 ; +#endif } dev->speed = speed;@@ -1178,6 +1194,7 @@ static struct platform_driver omap_i2c_driver = { .name = "omap_i2c", .owner = THIS_MODULE, .pm = OMAP_I2C_PM_OPS, + .of_match_table = omap_i2c_of_match, }, };drivers/of/platform.c +17
-0@@ -24,6 +24,10 @@#include <linux/of_platform.h> #include <linux/platform_device.h> +#ifdef CONFIG_ARCH_OMAP2PLUS +#include <plat/omap_device.h> +#endif +const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, #ifdef CONFIG_ARM_AMBA@@ -544,6 +548,36 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *lreturn NULL ; } +static struct omap_device_pm_latency omap_device_latency[] = { + [0 ] = { + .deactivate_func = omap_device_idle_hwmods, + .activate_func = omap_device_enable_hwmods, + .flags =OMAP_DEVICE_LATENCY_AUTO_ADJUST , + }, +}; + +int of_omap_device_create (struct device_node *np,const char *name,int id, +void *platform_data, +int pd_size) +{ +struct omap_hwmod *oh;
Quoted 8 lines
drivers/of/platform.c static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l · line 566
Quoted 3 lines
drivers/of/platform.c +3
-0+struct platform_device *pdev; + + oh =omap_hwmod_lookup (name);This is not enough to handle multiple hwmod entries. Moreover you will force the device to be named like the hwmod. This is not necessarily bad, but we should be able to have a distinct name if needed.
I agree it supports only single hwmod entries. As of now, only mcbsp uses multiple hwmod entries. With dt enabled, most of the drivers can use single hwmod entry for omap device creation and we can upgrade this api for handling mutiple hwmod entries.
#>git grep omap_device_build_ssarch/arm/mach-omap2/devices.c: pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,arch/arm/mach-omap2/mcbsp.c: pdev = omap_device_build_ss(NULL, name, id,oh_device, count, pdata, arch/arm/plat-omap/include/plat/omap_device.h:struct platform_device *omap_device_build_ss(struct device_node *np, arch/arm/plat-omap/omap_device.c: * The function is called from inside omap_device_build_ss(), afterarch/arm/plat-omap/omap_device.c: * omap_device @od. Used by omap_device_build_ss() to determine how arch/arm/plat-omap/omap_device.c: * omap_device_build_ss() after calling omap_device_count_resources().arch/arm/plat-omap/omap_device.c: * platform_device record. See omap_device_build_ss() for morearch/arm/plat-omap/omap_device.c: * passes along the return value of omap_device_build_ss().arch/arm/plat-omap/omap_device.c: return omap_device_build_ss(np,pdev_name, pdev_id, ohs, 1, pdata, arch/arm/plat-omap/omap_device.c: * platform_device record. See omap_device_build_ss() for morearch/arm/plat-omap/omap_device.c: * passes along the return value of omap_device_build_ss().arch/arm/plat-omap/omap_device.c: return omap_device_build_ss(NULL,pdev_name, pdev_id, ohs, 1, pdata, arch/arm/plat-omap/omap_device.c: * omap_device_build_ss - build and register an omap_device with multiple hwmods arch/arm/plat-omap/omap_device.c:struct platform_device *omap_device_build_ss(struct device_node *np,
#>
-M
cover dt: omap hwmod-dt binding and omap3 i2c1 dt support
In reply to G, Manjunath KondaiahQuoted 18 lines · Manjunath Kondaiah
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from
omap_device.
[There is latest version posted which will be rebased later]Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely <[email protected]>
However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call.
Quoted 5 lines
Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week.
git://git.secretlab.ca/git/linux-2.6.git
Branch: devicetree/test-3.0
Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test?
Quoted 55 lines
G, Manjunath Kondaiah (6):
dt: omap: prepare hwmod to support dt
dt: Addpd_sizeto AUXDATA structure
dt: omap3: add soc file for handling i2c controllers
dt: omap3: beagle board: set clock freq for i2c devices
dt: omap3: add generic board file for dt support
dt: omap3: enable dt support for i2c1 controllerKevin Hilman (7):
OMAP:omap_device: replace_find_by_pdev()withto_omap_device()
OMAP:omap_device: replace debug/warning/error prints with dev_*
macros
OMAP3: beagle: don't touchomap_deviceinternals
OMAP: McBSP: use existing macros for converting between devices
OMAP:omap_device: remove internal functions fromomap_device.h
OMAP:omap_device: when building returnplatform_deviceinstead of
omap_device
ARM:platform_device:pdev_archdata: addomap_devicepointerTony Lindgren (1):
omap2+: UseKconfigsymbol inMakefileinstead of obj-yarch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +-- arch/arm/boot/dts/omap3-beagle.dts | 18 +++- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++++++++++ arch/arm/include/asm/device.h | 5 + arch/arm/mach-omap2/Kconfig | 11 ++ arch/arm/mach-omap2/Makefile | 77 ++++++------- arch/arm/mach-omap2/board-omap3-dt.c | 93 +++++++++++++++ arch/arm/mach-omap2/board-omap3beagle.c | 40 ++----- arch/arm/mach-omap2/devices.c | 44 ++++---- arch/arm/mach-omap2/display.c | 6 +- arch/arm/mach-omap2/dma.c | 16 ++-- arch/arm/mach-omap2/gpio.c | 8 +- arch/arm/mach-omap2/hsmmc.c | 8 +- arch/arm/mach-omap2/hwspinlock.c | 8 +- arch/arm/mach-omap2/mcbsp.c | 8 +- arch/arm/mach-omap2/pm.c | 8 +- arch/arm/mach-omap2/serial.c | 12 +- arch/arm/plat-omap/i2c.c | 8 +- arch/arm/plat-omap/include/plat/omap_device.h | 17 ++- arch/arm/plat-omap/mcbsp.c | 6 +- arch/arm/plat-omap/omap_device.c | 150 ++++++++++++++++--------- drivers/i2c/busses/i2c-omap.c | 23 ++++- drivers/of/platform.c | 41 +++++++ include/linux/of_platform.h | 5 + 24 files changed, 469 insertions(+), 216 deletions(-)create mode 100644
arch/arm/boot/dts/omap3-soc.dtsicreate mode 100644arch/arm/mach-omap2/board-omap3-dt.c_______________________________________________
devicetree-discuss mailing list
devicetree-discuss at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
cover dt: omap hwmod-dt binding and omap3 i2c1 dt support
Quoted 19 lines · Rajendra Nayak
Quoted 18 lines · Manjunath Kondaiah
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from
omap_device.
[There is latest version posted which will be rebased later]Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely <[email protected]>
However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call.
Quoted 8 lines
Quoted 5 lines
Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week.
git://git.secretlab.ca/git/linux-2.6.git
Branch: devicetree/test-3.0Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test?
devicetree/test was broken last week since grant has pulled latest mainline changes hence selected stable version.
-M
[...]
cover dt: omap hwmod-dt binding and omap3 i2c1 dt support
Quoted 23 lines · Manjunath Kondaiah
Quoted 22 lines · Rajendra Nayak
Quoted 21 lines · Manjunath Kondaiah
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from
omap_device.
[There is latest version posted which will be rebased later]Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely <[email protected]>
However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call.
Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
git://git.secretlab.ca/git/linux-2.6.git
Branch: devicetree/test-3.0Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test?
devicetree/test was broken last week since grant has pulled latest mainline changes hence selected stable version.
Ok, atleast mainline is fixed now.
Quoted 4 lines
-M
[...]
cover dt: omap hwmod-dt binding and omap3 i2c1 dt support
Quoted 30 lines · Rajendra Nayak
Quoted 29 lines · Manjunath Kondaiah
Quoted 27 lines · On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak<[email protected]> ?wrote:
Quoted 24 lines · Manjunath Kondaiah
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from
omap_device.
[There is latest version posted which will be rebased later]Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely <[email protected]>
However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call.
Used 3.0 stable kernel version for this patch series since latest mainline
was broken for beagle boot last week.
git://git.secretlab.ca/git/linux-2.6.git
Branch: devicetree/test-3.0
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test?
devicetree/test was broken last week since grant has pulled latest mainline changes hence selected stable version.
Ok, atleast mainline is fixed now.
These changes are for v3.2 merge window and it will be rebased later after the review.
-M