Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
Hi, On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote: The main goal is to avoid duplicating data both in hwmod and DT. That's pretty much solved as we can have the driver probe populate the common data for hwmod from DT as Santosh has already demonstrated. Then we also want the driver specific idle and reset code to be done in the drivers rather than in hwmod and glue it together with hwmod using runtime PM. The biggest issue there is how do we reset and idle some piece of hardware for PM purposes when there's no driver loaded. right, this will be a tough nut to crack. I guess the only way would be reset all IPs early in the boot process, before even creating the platform-devices. Can we do that ? I mean, from omap_device_build_from_dt() we have access to address space of all devices, through ti,hwmods we can figure out which hwmods are linked to that particular device, so whenever you build a device, you could just call _reset(). Thats what we do today and it works perfectly. As per Tony's suggestion, we need to move the non-probed devices reset and idle setup to late_init which is also doable. In that case when probed driver calls runtime_get(), we reset that device and setup the idle settings. And remainder of the devices are managed in late_init(). what's the point in moving it to late_initcall() ? It makes no difference, if no driver binds to that device it will stay in reset anyway. Maybe what we're missing is properly idling (not exactly) all devices before driver probe kicks in. The only problem is that now omap_device_build_from_dt() is called after we notify that a new device/driver pair has been registered with the platform_bus, right ? So we would still need a way to call _reset() for those which are on DTS but don't have a driver bound to them... The only special requirement for reset remains(which today handled by hwmod function calls) is for devices which needs specific reset sequence. And this one can be handled through a runtime_reset() kind of hook. Does that sound reasonable ? Depends on Rafael. If he says no to the -runtime_reset() I suggested earlier, another aproach needs to be found. In any case, -runtime_reset() is only for devices which actually have a driver, so it matters little. The difficult part is handling special reset requirements for devices without drivers as there'd be no -runtime_reset() to call. -- balbi signature.asc Description: Digital signature
Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
+ Rafael, On Saturday 16 February 2013 02:25 PM, Felipe Balbi wrote: Hi, On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote: The main goal is to avoid duplicating data both in hwmod and DT. That's pretty much solved as we can have the driver probe populate the common data for hwmod from DT as Santosh has already demonstrated. Then we also want the driver specific idle and reset code to be done in the drivers rather than in hwmod and glue it together with hwmod using runtime PM. The biggest issue there is how do we reset and idle some piece of hardware for PM purposes when there's no driver loaded. right, this will be a tough nut to crack. I guess the only way would be reset all IPs early in the boot process, before even creating the platform-devices. Can we do that ? I mean, from omap_device_build_from_dt() we have access to address space of all devices, through ti,hwmods we can figure out which hwmods are linked to that particular device, so whenever you build a device, you could just call _reset(). Thats what we do today and it works perfectly. As per Tony's suggestion, we need to move the non-probed devices reset and idle setup to late_init which is also doable. In that case when probed driver calls runtime_get(), we reset that device and setup the idle settings. And remainder of the devices are managed in late_init(). what's the point in moving it to late_initcall() ? It makes no difference, if no driver binds to that device it will stay in reset anyway. Maybe what we're missing is properly idling (not exactly) all devices before driver probe kicks in. I think it is largely reducing the early init dependencies and also reducing the role of platform code who today takes care of every device idle and reset initialization. That way late_init() will only have to care about the devices which are not probed by drivers. Tony, Is that right ? The only problem is that now omap_device_build_from_dt() is called after we notify that a new device/driver pair has been registered with the platform_bus, right ? So we would still need a way to call _reset() for those which are on DTS but don't have a driver bound to them... The only special requirement for reset remains(which today handled by hwmod function calls) is for devices which needs specific reset sequence. And this one can be handled through a runtime_reset() kind of hook. Does that sound reasonable ? Depends on Rafael. If he says no to the -runtime_reset() I suggested earlier, another aproach needs to be found. In any case, -runtime_reset() is only for devices which actually have a driver, so it matters little. I agree. Looping Rafael to hear from him. To add a bit of context, On OMAP we do have few IP blocks which needs a special reset sequence during init as well as working state of the driver. Some of this was worked around such cases by populating function pointers from platform data which drivers can use. This obviously doesn't scale and won't work with DT based builds. We have been thinking of having a runtime_reset() generic callback which drivers can use. Whats you take on it ? The difficult part is handling special reset requirements for devices without drivers as there'd be no -runtime_reset() to call. I don't think that requirement exists so if we address the driver requirement, we are good. Even otherwise also, it can be managed from platform code. Regards, Sasntosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
Hi, On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote: On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote: The main goal is to avoid duplicating data both in hwmod and DT. That's pretty much solved as we can have the driver probe populate the common data for hwmod from DT as Santosh has already demonstrated. Then we also want the driver specific idle and reset code to be done in the drivers rather than in hwmod and glue it together with hwmod using runtime PM. The biggest issue there is how do we reset and idle some piece of hardware for PM purposes when there's no driver loaded. right, this will be a tough nut to crack. I guess the only way would be reset all IPs early in the boot process, before even creating the platform-devices. Can we do that ? I mean, from omap_device_build_from_dt() we have access to address space of all devices, through ti,hwmods we can figure out which hwmods are linked to that particular device, so whenever you build a device, you could just call _reset(). Thats what we do today and it works perfectly. As per Tony's suggestion, we need to move the non-probed devices reset and idle setup to late_init which is also doable. In that case when probed driver calls runtime_get(), we reset that device and setup the idle settings. And remainder of the devices are managed in late_init(). what's the point in moving it to late_initcall() ? It makes no difference, if no driver binds to that device it will stay in reset anyway. Maybe what we're missing is properly idling (not exactly) all devices before driver probe kicks in. I think it is largely reducing the early init dependencies and also reducing the role of platform code who today takes care of every device idle and reset initialization. That way late_init() will only have to care about the devices which are not probed by drivers. Tony, Is that right ? Makes not much difference, except that you will have to keep track of which devices have gotten a driver probed and which haven't. IMO, it sounds a lot better to reset everything early on, so we know we're starting at a known stage (and thus drop all bootloader dependencies) then to follow the other route. The difficult part is handling special reset requirements for devices without drivers as there'd be no -runtime_reset() to call. I don't think that requirement exists so if we address the driver requirement, we are good. Even otherwise also, it can be managed Look back at what you want to do at late_initcall() time. You want to reset all devices which haven't gotten a driver bound to them. from platform code. right, the you will need even more data in hwmod to let it know about the special devices. /me wonders when the amount of data will actually decrease. -- balbi signature.asc Description: Digital signature
Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
On Saturday 16 February 2013 02:52 PM, Felipe Balbi wrote: Hi, On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote: On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote: The main goal is to avoid duplicating data both in hwmod and DT. That's pretty much solved as we can have the driver probe populate the common data for hwmod from DT as Santosh has already demonstrated. Then we also want the driver specific idle and reset code to be done in the drivers rather than in hwmod and glue it together with hwmod using runtime PM. The biggest issue there is how do we reset and idle some piece of hardware for PM purposes when there's no driver loaded. right, this will be a tough nut to crack. I guess the only way would be reset all IPs early in the boot process, before even creating the platform-devices. Can we do that ? I mean, from omap_device_build_from_dt() we have access to address space of all devices, through ti,hwmods we can figure out which hwmods are linked to that particular device, so whenever you build a device, you could just call _reset(). Thats what we do today and it works perfectly. As per Tony's suggestion, we need to move the non-probed devices reset and idle setup to late_init which is also doable. In that case when probed driver calls runtime_get(), we reset that device and setup the idle settings. And remainder of the devices are managed in late_init(). what's the point in moving it to late_initcall() ? It makes no difference, if no driver binds to that device it will stay in reset anyway. Maybe what we're missing is properly idling (not exactly) all devices before driver probe kicks in. I think it is largely reducing the early init dependencies and also reducing the role of platform code who today takes care of every device idle and reset initialization. That way late_init() will only have to care about the devices which are not probed by drivers. Tony, Is that right ? Makes not much difference, except that you will have to keep track of which devices have gotten a driver probed and which haven't. IMO, it sounds a lot better to reset everything early on, so we know we're starting at a known stage (and thus drop all bootloader dependencies) then to follow the other route. I tend to agree with you. This was exactly the reason Paul and Benoit added that support first up as part of early init code. The difficult part is handling special reset requirements for devices without drivers as there'd be no -runtime_reset() to call. I don't think that requirement exists so if we address the driver requirement, we are good. Even otherwise also, it can be managed Look back at what you want to do at late_initcall() time. You want to reset all devices which haven't gotten a driver bound to them. from platform code. right, the you will need even more data in hwmod to let it know about the special devices. /me wonders when the amount of data will actually decrease. Well that is already supported. There is no need to add any additional information. Device which are initialized, there state is set as initialized. So the late_init() will just have to iterate over un-initialised devices. Just to be clear, I am also in favor of just keeping that part as it is today but we were exploring other options based on comments from Tony during OMAP5 data review. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] arm/dts: OMAP3: Add gpmc DT node support
Add gpmc DT node in dtsi file. Add nand DT node and partitions information for devkit8000. This series is based on top of branch âomap-for-v3.9/gpmcâ git tree http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git and patches. Anil Kumar:- ARM: dts: add minimal DT support for DevKit8000 Jon Hunter:- ARM: OMAP2+: Fix-up gpmc merge error Done basic testing:- - #cat /proc/mtd (shows nand partitions) - Nand partitions by command line. Anil Kumar (2): ARM: dts: omap3: Add gpmc node ARM: dts: omap3-devkit8000: add nand dt node arch/arm/boot/dts/omap3-devkit8000.dts | 52 arch/arm/boot/dts/omap3.dtsi | 11 +++ 2 files changed, 63 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: omap3-devkit8000: add nand dt node
Add the needed sections to enable nand support on
Devkit8000.
Add nand partitions information.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
:100644 100644 6338993... 6c6decf... M arch/arm/boot/dts/omap3-devkit8000.dts
arch/arm/boot/dts/omap3-devkit8000.dts | 52
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 6338993..6c6decf 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -101,3 +101,55 @@
mcbsp5 {
status = disabled;
};
+
+gpmc {
+ ranges = 0 0 0x3000 0x04; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 44;
+ gpmc,cs-wr-off = 44;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 34;
+ gpmc,adv-wr-off = 44;
+ gpmc,we-off = 40;
+ gpmc,oe-off = 54;
+ gpmc,access = 64;
+ gpmc,rd-cycle = 82;
+ gpmc,wr-cycle = 82;
+ gpmc,wr-access = 40;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ x-loader@0 {
+ label = X-Loader;
+ reg = 0 0x8;
+ };
+
+ bootloaders@8 {
+ label = U-Boot;
+ reg = 0x8 0x1e;
+ };
+
+ bootloaders_env@26 {
+ label = U-Boot Env;
+ reg = 0x26 0x2;
+ };
+
+ kernel@28 {
+ label = Kernel;
+ reg = 0x28 0x40;
+ };
+
+ filesystem@68 {
+ label = File System;
+ reg = 0x68 0xf98;
+ };
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: omap3: Add gpmc node
Add gpmc DT node.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
:100644 100644 1acc261... 9f36531... M arch/arm/boot/dts/omap3.dtsi
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9f36531 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap3: Add gpmc node
Hi Anil,
On Sat, Feb 16, 2013 at 05:08:27PM +0530, Anil Kumar wrote:
Add gpmc DT node.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
:100644 100644 1acc261... 9f36531... March/arm/boot/dts/omap3.dtsi
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9f36531 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch has been already sent twice to the mailing list.
Perhaps it would be more polite if you could base your work on
one of those instead of sending it yourself again.
Florian Vaussard sent one on January 28th:
[PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Javier Martinez Canillas sent another one on February 09th:
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
Moreover, you could help to get patches merged faster by sending
your Acked-by or Tested-by.
Thanks,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap3: Add gpmc node
Hi,
On Sat, Feb 16, 2013 at 5:54 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Hi Anil,
On Sat, Feb 16, 2013 at 05:08:27PM +0530, Anil Kumar wrote:
Add gpmc DT node.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
:100644 100644 1acc261... 9f36531... March/arm/boot/dts/omap3.dtsi
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9f36531 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch has been already sent twice to the mailing list.
Perhaps it would be more polite if you could base your work on
one of those instead of sending it yourself again.
Florian Vaussard sent one on January 28th:
[PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
ok, I missed this patch. I will re base my changes on of this patch.
Javier Martinez Canillas sent another one on February 09th:
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
Moreover, you could help to get patches merged faster by sending
your Acked-by or Tested-by.
Sure i do that.
Thanks,
Anil
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Hi Florian,
On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
Tested on devkit8000 (omap3 based board)
Please take my Tested-by: Anil Kumar anilk...@gmail.com
Thanks,
Anil
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar anilkumar...@gmail.com wrote:
Hi Florian,
On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
Tested on devkit8000 (omap3 based board)
Please take my Tested-by: Anil Kumar anilk...@gmail.com
Thanks,
Anil
Hello Tony and Benoit,
Could this patch be merged to one of your branches?
It has already my Reviewed-by and now Anil's Tested-by.
Now that Daniel's OMAP GPMC binding were merged, there seems to be
many people working on adding support on their boards DT for
peripherals connected through the GPMC (NAND, OneNAND, SMSC LAN, etc).
I think it will be easier if people can base their work on top of this
patch instead of duplicating the work and sending the same patch to
add a GPMC device node to omap3.dtsi on each patch-set.
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
On Thu, Feb 14, 2013 at 2:04 PM, Philip, Avinash avinashphi...@ti.com wrote: Hi Tony, On Sat, Feb 09, 2013 at 21:25:49, Ezequiel Garcia wrote: On Fri, Feb 08, 2013 at 04:56:19PM -0600, Jon Hunter wrote: Without this patch, GPMC is currently broken on my igep board setup, if initialized through a device tree. Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Without this patch GPMC is not working in am335x-evm. Tested-by: Philip Avinash avinashphi...@ti.com See Jon's comments. JON Hi Tony, this one appears to be merged incorrectly. The unreserve ended JON up in the gpmc_calc_timings() function. Here is a patch to fix. Just wasted a hour or a few trying to figure out this problem, can we get this merged now? Maybe Jon can resend this with all the tested-bys to catch Tony's attention? Tested-by: Grazvydas Ignotas nota...@gmail.com -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts
This driver uses omap_dss_device that it gets from a board file through
SPI platfrom_data pointer to pass data from SPI to DSS portion of the
driver by using dev_set_drvdata(). However this trick no longer works,
as DSS core no longer uses omap_dss_device from a board file to create
the real device, so use a global pointer to accomplish this instead,
like other SPI panel drivers do.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
.../video/omap2/displays/panel-tpo-td043mtea1.c| 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 6b66439..048c983 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -63,6 +63,9 @@ struct tpo_td043_device {
u32 power_on_resume:1;
};
+/* used to pass spi_device from SPI to DSS portion of the driver */
+static struct tpo_td043_device *g_tpo_td043;
+
static int tpo_td043_write(struct spi_device *spi, u8 addr, u8 data)
{
struct spi_message m;
@@ -403,7 +406,7 @@ static void tpo_td043_disable(struct omap_dss_device
*dssdev)
static int tpo_td043_probe(struct omap_dss_device *dssdev)
{
- struct tpo_td043_device *tpo_td043 = dev_get_drvdata(dssdev-dev);
+ struct tpo_td043_device *tpo_td043 = g_tpo_td043;
int nreset_gpio = dssdev-reset_gpio;
int ret = 0;
@@ -440,6 +443,8 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
if (ret)
dev_warn(dssdev-dev, failed to create sysfs files\n);
+ dev_set_drvdata(dssdev-dev, tpo_td043);
+
return 0;
fail_gpio_req:
@@ -505,6 +510,9 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENODEV;
}
+ if (g_tpo_td043 != NULL)
+ return -EBUSY;
+
spi-bits_per_word = 16;
spi-mode = SPI_MODE_0;
@@ -521,7 +529,7 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
tpo_td043-spi = spi;
tpo_td043-nreset_gpio = dssdev-reset_gpio;
dev_set_drvdata(spi-dev, tpo_td043);
- dev_set_drvdata(dssdev-dev, tpo_td043);
+ g_tpo_td043 = tpo_td043;
omap_dss_register_driver(tpo_td043_driver);
@@ -534,6 +542,7 @@ static int tpo_td043_spi_remove(struct spi_device *spi)
omap_dss_unregister_driver(tpo_td043_driver);
kfree(tpo_td043);
+ g_tpo_td043 = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
