Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. BR, Konstantin Baydarov. Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hello, On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. 4460: [root@(none) ~]# omapconf read 0x4A002000 4A00 [root@(none) ~]# omapconf read 0x4A002004 4470: [root@(none) ~]# omapconf read 0x4A002000 4B00 [root@(none) ~]# omapconf read 0x4A002004 BR, Konstantin Baydarov. Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/31/2012 2:49 PM, Eduardo Valentin wrote: Hello, On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. 4460: [root@(none) ~]# omapconf read 0x4A002000 4A00 [root@(none) ~]# omapconf read 0x4A002004 4470: [root@(none) ~]# omapconf read 0x4A002000 4B00 [root@(none) ~]# omapconf read 0x4A002004 Nice! We do have a cool progression 1 - 2 - 3 for each revision. Well at least for the SCM. Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi.
On 05/31/2012 04:52 PM, Cousson, Benoit wrote:
On 5/31/2012 2:49 PM, Eduardo Valentin wrote:
Hello,
On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards for
System Control Module (SCM).
...
I believe that CPU-specific bandgap definition should be moved to
bard specific dts.
Mmm, why, since it is CPU specific and not board specific. I has to
be in the SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
if omap4430 bandgap support will be added to omap-bandgap driver the
version of bandgap should specified in dts file. omap4.dtsi is a
common for omap4 boards, that is why I'm suggesting to move bandgap
description to probably board specific file.
OK, I got your point, but in that case we could potentially define a
omap4460.dtsi file.
Another solution is to
determine bandgap type in driver probe function, but in that case
ti,omap4460-bandgap in omap4.dtsi should be replaced to
ti,omap4-bandgap.
Yes, this is the best solution, but that assume that we can identify the
control module version from the HW, which is not necessarily true :-(
The IP_REVISION (offset = 0) value are unfortunately not documented, so we
should read it to check if they are different from omap4430 and 4460.
The bitfield layout in that register is:
IP_REV_MAJOR: 8..10
IP_REV_CUSTOM: 6..7
IP_REV_MINOR: 0..5
The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
CONTROL_GEN_CORE_REVISION: 0x4900
CONTROL_GEN_CORE_HWINFO: 0x0
Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
4460:
[root@(none) ~]# omapconf read 0x4A002000
4A00
[root@(none) ~]# omapconf read 0x4A002004
4470:
[root@(none) ~]# omapconf read 0x4A002000
4B00
[root@(none) ~]# omapconf read 0x4A002004
Nice! We do have a cool progression 1 - 2 - 3 for each revision.
Well at least for the SCM.
Benoit
This patch allows checking of bandgap type dynamically in bandgap driver
probe function by reading omap core control module revision register
CONTROL_GEN_CORE_REVISION. It lets bandgap module to be defined in common
omap4.dtsi, because all cpu specific attributes(irq and tshut number)
were moved to driver.
Patch wasn't tested because I have panda 4430 board.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Index: omap-thermal/arch/arm/boot/dts/omap4.dtsi
===
--- omap-thermal.orig/arch/arm/boot/dts/omap4.dtsi
+++ omap-thermal/arch/arm/boot/dts/omap4.dtsi
@@ -277,9 +277,7 @@
compatible = ti,omap4-control;
ti,hwmods = ctrl_module_core;
bandgap {
- compatible = ti,omap4460-bandgap;
- interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86; /* tshut */
+ compatible = ti,omap4-bandgap;
};
usb {
compatible = ti,omap4-usb-phy;
Index: omap-thermal/drivers/thermal/omap-bandgap.c
===
--- omap-thermal.orig/drivers/thermal/omap-bandgap.c
+++ omap-thermal/drivers/thermal/omap-bandgap.c
@@ -219,12 +219,14 @@ struct omap_temp_sensor {
struct omap_bandgap_data {
boolhas_talert;
boolhas_tshut;
+ int tshut_gpio;
const int *conv_table;
char*fclock_name;
char*div_ck_name;
int sensor_count;
int (*report_temperature)(struct omap_bandgap *bg_ptr, int id);
int (*expose_sensor)(struct omap_bandgap *bg_ptr, int id, char *domain);
+ int irq;
/* this needs to be at the end */
struct omap_temp_sensor sensors[];
@@ -1189,10 +1191,12 @@ static int omap_bandgap_talert_init(stru
static const struct omap_bandgap_data omap4460_data = {
.has_talert = true,
.has_tshut = true,
+ .tshut_gpio = 86,
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
.conv_table = omap4460_adc_to_temp,
.expose_sensor = omap4_thermal_expose_sensor,
+ .irq = 126,
.sensors = {
{
.registers = omap4460_mpu_temp_sensor_registers,
@@ -1206,9 +1210,11 @@ static const struct omap_bandgap_data om
static const struct
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ ti,hwmods = ctrl_module_core;
+ bandgap {
+ compatible = ti,omap4460-bandgap;
+ interrupts =0 126 4; /* talert */
+ ti,tshut-gpio =86; /* tshut */
+ };
I believe that CPU-specific bandgap definition should be moved to bard specific
dts.
Mmm, why, since it is CPU specific and not board specific. I has to be
in the SoC file.
Regards,
Benoit
--
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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+compatible = ti,omap4-control;
+ti,hwmods = ctrl_module_core;
+bandgap {
+compatible = ti,omap4460-bandgap;
+interrupts =0 126 4; /* talert */
+ti,tshut-gpio =86; /* tshut */
+};
I believe that CPU-specific bandgap definition should be moved to bard
specific dts.
Mmm, why, since it is CPU specific and not board specific. I has to be in the
SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if
omap4430 bandgap support will be added to omap-bandgap driver the version of
bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards,
that is why I'm suggesting to move bandgap description to probably board
specific file.
Another solution is to determine bandgap type in driver probe function, but in
that case ti,omap4460-bandgap in omap4.dtsi should be replaced to
ti,omap4-bandgap.
BR,
Konstantin Baydarov.
Regards,
Benoit
--
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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c BR, Konstantin Baydarov. Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/30/2012 12:17 PM, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): No, we cannot, we are in the process of getting rid of that. A driver should only focus on the IP version in theory. The CPU version is not the proper way of getting that. It will make the driver not scalable at all for future OMAP revision. drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c Yeah, these are the ones that still need to be fixed... Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hello, On Wed, May 30, 2012 at 12:22:49PM +0200, Cousson Benoit wrote: On 5/30/2012 12:17 PM, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 I have the weird deja vu feeling... The DT entry I sent, I already knew it would cause troubles :-) Having it per board it would be really a PITA. Image that every body doing a 4430 board needs to define a BG entry... That would work, but still do we want this? Benoit, I guess you should know my option by now. Ideally we should rely on revision register to decide what to do in the driver. And as we discussed, looks like for BG this is somewhat non-existing. If we go with the SCM revision register, what do we do if the BG goes away from SCM? If we go with ti,omap4-bandgap, we still need a way to say if it is 4430, 4460 or 4470. There are configuration / settings specific for each. Not only on bandgap, but also wrt to sensor location and hotspot extrapolation rules. Because we lack a revision register for bandgap, one way to go is to have still the revisioning on the same way: ti,omap-bandgap, but having a omap.dtsi per omap revision. But do we want to this only due to bandgap? BTW, is it only BG which is suffering of this issue? Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): No please! Let's not use that stuff... No, we cannot, we are in the process of getting rid of that. A driver should only focus on the IP version in theory. The CPU version is not the proper way of getting that. It will make the driver not scalable at all for future OMAP revision. drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c Yeah, these are the ones that still need to be fixed... agreed with Benoit here. Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/30/2012 12:42 PM, Eduardo Valentin wrote: Hello, On Wed, May 30, 2012 at 12:22:49PM +0200, Cousson Benoit wrote: On 5/30/2012 12:17 PM, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 I have the weird deja vu feeling... I know :-) The DT entry I sent, I already knew it would cause troubles :-) Having it per board it would be really a PITA. Image that every body doing a 4430 board needs to define a BG entry... That would work, but still do we want this? No, in fact I do not want to do that if we can avoid it. Benoit, I guess you should know my option by now. Ideally we should rely on revision register to decide what to do in the driver. And as we discussed, looks like for BG this is somewhat non-existing. Oops, sorry I was thinking about the SCM revision :-( The register seems to be there with the layout detailed before. I just do not have a clue about the value we should expect. That's why we have to read it on both 4430 and 4460 to check if some bits are different. If we go with the SCM revision register, what do we do if the BG goes away from SCM? Yeah, good point. But, if at some point the BG becomes a real IP with an OCP port, then we will have a TI wrapper on top of it with the proper revision register... at least in theory :-) If we go with ti,omap4-bandgap, we still need a way to say if it is 4430, 4460 or 4470. Yeah, so we should check if at least that SCM revision field is meaningful. There are configuration / settings specific for each. Not only on bandgap, but also wrt to sensor location and hotspot extrapolation rules. Assuming the SCM version is usable we can extract from that some SW revision for each sub IP. But it is still not clear how the children will be aware of the parent revision :-( Exported a get_scm_revision is doable potentially. Because we lack a revision register for bandgap, one way to go is to have still the revisioning on the same way: ti,omap-bandgap, but having a omap.dtsi per omap revision. But do we want to this only due to bandgap? BTW, is it only BG which is suffering of this issue? Mmm, probably not, that being said, SCM is probably the worst IP we have on OMAP :-) Regards, Benoit Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): No please! Let's not use that stuff... No, we cannot, we are in the process of getting rid of that. A driver should only focus on the IP version in theory. The CPU version is not the proper way of getting that. It will make the driver not scalable at all for future OMAP revision. drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c Yeah, these are the ones that still need to be fixed... agreed with Benoit here. Regards, Benoit -- 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 PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ ti,hwmods = ctrl_module_core;
+ bandgap {
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86; /* tshut */
+ };
I believe that CPU-specific bandgap definition should be moved to bard specific
dts.
BR,
Konstantin Baydarov.
+ usb {
+ compatible = ti,omap4-usb-phy;
+ };
+ };
};
};
--
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
