Re: [PATCH 0/6] hwrng: OMAP: Updates for OMAP RNG module
On Mon, Aug 05, 2013 at 08:17:17PM +0530, Lokesh Vutla wrote: This patch series adds support for OMAP4 version of RNG module. This module produce a 64 bit random number and also allows to de tune FROs when repeated pattern is coming out of FROs. This series also has few fixes for the driver. Lokesh Vutla (6): hwrng: OMAP: Use module_platform_driver macro hwrng: OMAP: Convert to devm_kzalloc() hwrng: OMAP: Remove duplicated function call hwrng: OMAP: Add device tree support ARM: OMAP2+: Only manually add hwmod data when DT not used. hwrng: OMAP: Add OMAP4 TRNG support All applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: ARM: AM335x: Reboot broken in 3.11
Am Donnerstag, 8. August 2013, 15:50:18 schrieb Mark Jackson: Rebooting appears to have broken in 3.11 (at some point before rc1). Here is the console output:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-6-gf550793 (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #328 Thu Aug 8 14:36:16 BST 2013 ... Welcome to Buildroot nanobone login: root Password: # reboot # [ 23.867076] UBIFS: background thread ubifs_bgt0_0 stops The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 25.924496] reboot: Restarting system ... and at this point the CPU seems to just freeze. In 3v10, the board would reboot correctly back into uboot, etc. I've also noticed that some of the output LEDs light up dim when the kernel is booting on, and they come on full brightness at the reboot freeze point. There are 4 LEDs affected and they are all connected to UART transmit pins. Before I start bisecting, does anyone have any ideas ? No problem here - at least not at -rc4: Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc4-00019-g7c4368e-dirty (larsi@lem- wkst-02) (gcc version 4.4.3 (GCC) ) #90 PREEMPT Thu Aug 8 16:42:06 CEST 2013 [0.00] Machine: Generic AM33XX (Flattened Device Tree), bboxv3 login: root root@bboxv3:~# reboot Broadcast message from root@bboxv3 (ttyO2) (鈬hu May 16 16:59:11 2013): INIT: Sending processes the TERM signal INIT: SenStopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid 416) . Stopping system message bus: Stopping syslogd/klogd: stopped syslogd (pid 423) stopped klogd (pid 425) done Stopping tcf-agent: OK Stopping internet superserver: xinetd. not deconfiguring network interfaces: network file systems still mounted. Stopping Linux NFC daemon Stopping Lighttpd Web Server: stopped /usr/sbin/lighttpd (pid 440) lighttpd. Sending all processes the TERM signal... Sending all processes the KILL signal... Unmounting remote filesystems... Deactivating swap... Unmounting local filesystems... Rebooting... [ 38.285126] reboot: Restarting system U-Boot SPL 2013.04-rc2-00063-gcd27ec7-dirty (May 21 2013 - 15:14:45) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img Regards, Lars -- 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
[RFC 01/22] ARM: OMAP: remove DSS DT hack
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 11 +--
arch/arm/mach-omap2/dss-common.c| 23 ---
arch/arm/mach-omap2/dss-common.h| 2 --
3 files changed, 1 insertion(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index be5d005..d388d33 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -57,17 +57,8 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
- /*
-* HACK: call display setup code for selected boards to enable omapdss.
-* This will be removed when omapdss supports DT.
-*/
- if (of_machine_is_compatible(ti,omap4-panda)) {
- omap4_panda_display_init_of();
+ if (of_machine_is_compatible(ti,omap4-panda))
legacy_init_ehci_clk(auxclk3_ck);
-
- }
- else if (of_machine_is_compatible(ti,omap4-sdp))
- omap_4430sdp_display_init_of();
else if (of_machine_is_compatible(ti,omap5-uevm))
legacy_init_ehci_clk(auxclk1_ck);
}
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..f3282ac 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -98,12 +98,6 @@ void __init omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(omap4_panda_dss_data);
-}
-
-
/* OMAP4 Blaze display data */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
@@ -232,20 +226,3 @@ void __init omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
-
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- display_sel);
- if (r)
- pr_err(%s: Could not get display_sel GPIO\n, __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- DLP POWER ON);
- if (r)
- pr_err(%s: Could not get DLP POWER ON GPIO\n, __func__);
-
- omap_display_init(sdp4430_dss_data);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..611b341 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -7,8 +7,6 @@
*/
void __init omap4_panda_display_init(void);
-void __init omap4_panda_display_init_of(void);
void __init omap_4430sdp_display_init(void);
-void __init omap_4430sdp_display_init_of(void);
#endif
--
1.8.1.2
--
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
[RFC 00/22] OMAPDSS: DT support
Hi, This is an RFC for OMAP Display DT support. The patches work fine, at least for me, but they are not perfect. I mostly don't have any clear questions about specific issues, but I would like to get feedback on the selected approaches in general, and also ideas how to proceed with the series. This series contains the following: DT support for the following OMAP's display subsystem devices: - DSS - DISPC - DPI - HDMI - VENC - DSI - (DBI/RFBI DT is not yet implemented) DT support for the following external display devices: - panel-dsi-cm (Generic DSI command mode panel) - encoder-tfp410 (DPI-to-DVI encoder) - connector-dvi - encoder-tpd12s015 (HDMI level-shifter ESD protection) - hdmi-connector - panel-dpi (Generic DPI panel) - connector-analog-tv (S-Video Composite) DT support for the following boards: - OMAP4 PandaBoard - OMAP4 SDP - OMAP3 BeagleBoard - OMAP3 Overo with Palo43 LCD expansion-board The patches are not final, and many contain quite brief descriptions. Binding descriptions are also still missing. The code and bindings in the patches should be pretty straightforward, though. The series is based on v3.11-rc2 + a couple of non-DSS fixes. The series can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dev-model-dt Vocabulary == Display Entity - a hardware entity that takes one or more video streams as input and outputs one or more video streams. Upstream Entity - A display entity in the upstream side of the video stream, i.e. closer to the original video source. Downstream Entity - A display entity in the downstream side of the video stream, i.e. closer to the panel or monitor. Video pipeline - A chain of multiple display entities, starting from the SoC, going to the display device the user sees. Display or Panel - A display entity showing the pixels to the user Encoder - A display entity that takes video as an input and (usually) outputs it in some other format. Connector - HDMI/DVI/etc Connector on the board, to which an external monitor is connected. About Stable DT Bindings Generally speaking, the DT bindings should be stable. This brings the following problems: We already have DT bindings for some OMAP4 and OMAP3 boards, and OMAP4 boards do not even have board files anymore. There are no display bindings for those OMAP4 boards, but the display support is currently enabled as a hack, by calling board-file-like code to add the display devices for the selected boards. So, when we add the display bindings, we should still support the current DT files which do not have the display bindings. Which would mean that we'd need to keep the hacky code forever. Considering the fact that the hacky code does not work quite correct in all cases, I don't see keeping it as a very good option. CDF (Common Display Framework) is in the works, and will most likely have different or more detailed bindings. Moving to CDF would mean we'd somehow need to still support the old OMAP bindings. In theory the display DT bindings should stay the same, as they represent the HW, not any SW constructs, but in practice I find it hard to believe the OMAP display bindings would be so perfect that there would be no need for changes. We most likely should somehow represent DSS clock tree in DT. That is not a simple task, and when we manage to do it, it again means supporting the DT files without clock tree data. All in all, I'm a bit scared to push the display bindings, as it's already clear there are changes coming. Then again, supporting the current hack for OMAP4 based boards is not nice at all, and has issues, so it would be really nice to get OMAP4 boards use proper display bindings. General description of the DT bindings == All the display entities are represented as DT nodes of their own, and have a matching Linux driver. The display entities are organized by their control bus; that is, if a display entity is not controlled via any bus, it's a platform device, and if, say, it's controlled via i2c device, it's an i2c device. The exception to the above are DSI and DBI. DSI and DBI are combined control and video busses, but the use of the busses for control purposes is not independent of the video stream. Also, the the busses are, in practice, one-to-one links. And last, DSI and DBI display entities are often also controllable via, say, i2c. For these reasons there is no real Linux bus for DSI and DBI and thus the DSI and DBI devices are either platform devices or i2c devices. The display entities are connected via video-source property. The video-source points to the upstream display entity where the video data comes from, and a chain of display entities thus form a full video pipeline. All video pipelines end with either a panel or a connector. All the data related to a display entity, and how it is connected on the given board, is defined in the DT node of the display entity. This
[RFC 02/22] OMAPDSS: remove DT hacks for regulators
For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 5 -
drivers/video/omap2/dss/hdmi.c | 5 -
2 files changed, 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 99a043b..0c8bd1f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1132,11 +1132,6 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
return 0;
vdds_dsi = devm_regulator_get(dsi-pdev-dev, vdds_dsi);
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(dsi-pdev-dev, VCXIO);
-
if (IS_ERR(vdds_dsi)) {
DSSERR(can't get VDDS_DSI regulator\n);
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 44a885b..1b38f1f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -338,11 +338,6 @@ static int hdmi_init_regulator(void)
return 0;
reg = devm_regulator_get(hdmi.pdev-dev, vdda_hdmi_dac);
-
- /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
- if (IS_ERR(reg))
- reg = devm_regulator_get(hdmi.pdev-dev, VDAC);
-
if (IS_ERR(reg)) {
DSSERR(can't get VDDA_HDMI_DAC regulator\n);
return PTR_ERR(reg);
--
1.8.1.2
--
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
[RFC 04/22] OMAPDSS: if dssdev-name==NULL, use alias
To avoid the need for a nickname property for each display, change the display registration so that the display's alias (i.e. display0 etc) will be used for the dssdev-name if the display driver didn't provide a name. This means that when booting with board files, we will have more descriptive names for displays, like lcd1, hdmi. With DT we'll only have display0, etc. But as there are no nicknames for things like serials ports either, I hope we will do fine with this approach. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c index fafe7c9..64fb6e5 100644 --- a/drivers/video/omap2/dss/display.c +++ b/drivers/video/omap2/dss/display.c @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device *dssdev) snprintf(dssdev-alias, sizeof(dssdev-alias), display%d, disp_num_counter++); + if (dssdev-name == NULL) + dssdev-name = dssdev-alias; + if (drv drv-get_resolution == NULL) drv-get_resolution = omapdss_default_get_resolution; if (drv drv-get_recommended_bpp == NULL) -- 1.8.1.2 -- 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
[RFC 18/22] OMAPDSS: connector-dvi: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-dvi.c | 49
1 file changed, 49 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
b/drivers/video/omap2/displays-new/connector-dvi.c
index bc5f8ce..99ee1b2 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of_i2c.h
#include drm/drm_edid.h
@@ -274,6 +275,42 @@ static int dvic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int dvic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *src_node;
+ struct device_node *adapter_node;
+ struct i2c_adapter *adapter;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ adapter_node = of_parse_phandle(node, i2c-bus, 0);
+ if (adapter_node) {
+ adapter = of_find_i2c_adapter_by_node(adapter_node);
+ if (adapter == NULL) {
+ dev_err(pdev-dev, failed to parse i2c-bus\n);
+ return -EINVAL;
+ }
+
+ ddata-i2c_adapter = adapter;
+ }
+
+ return 0;
+}
+
static int dvic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -290,6 +327,10 @@ static int dvic_probe(struct platform_device *pdev)
r = dvic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = dvic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -335,12 +376,20 @@ static int __exit dvic_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id dvic_of_match[] = {
+ { .compatible = ti,dvi_connector, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dvic_of_match);
+
static struct platform_driver dvi_connector_driver = {
.probe = dvic_probe,
.remove = __exit_p(dvic_remove),
.driver = {
.name = connector-dvi,
.owner = THIS_MODULE,
+ .of_match_table = dvic_of_match,
},
};
--
1.8.1.2
--
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
[RFC 05/22] OMAPDSS: get dssdev-alias from DT alias
We currently create a displayX style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that display0 is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 64fb6e5..a8833ca 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/jiffies.h
#include linux/platform_device.h
+#include linux/of.h
#include video/omapdss.h
#include dss.h
@@ -133,9 +134,24 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev-driver;
+ int id;
- snprintf(dssdev-alias, sizeof(dssdev-alias),
- display%d, disp_num_counter++);
+ /*
+* Note: this presumes all the displays are either using DT or non-DT,
+* which normally should be the case. This also presumes that all
+* displays either have an DT alias, or none has.
+*/
+
+ if (dssdev-dev-of_node) {
+ id = of_alias_get_id(dssdev-dev-of_node, display);
+
+ if (id 0)
+ id = disp_num_counter++;
+ } else {
+ id = disp_num_counter++;
+ }
+
+ snprintf(dssdev-alias, sizeof(dssdev-alias), display%d, id);
if (dssdev-name == NULL)
dssdev-name = dssdev-alias;
--
1.8.1.2
--
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
[RFC 22/22] OMAPDSS: connector-analog-tv: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../video/omap2/displays-new/connector-analog-tv.c | 70 ++
1 file changed, 70 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c
b/drivers/video/omap2/displays-new/connector-analog-tv.c
index 5338f36..b4fb74b 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -28,6 +29,12 @@ struct panel_drv_data {
bool invert_polarity;
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+ enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -191,6 +198,36 @@ static int tvc_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tvc_probe_of(struct platform_device *pdev,
+ const struct tvc_of_data *data)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *src_node;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ ddata-connector_type = data-connector_type;
+
+ ddata-invert_polarity =
+ of_property_read_bool(node, invert-polarity);
+
+ return 0;
+}
+
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -208,6 +245,18 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+
+ match = of_match_node(tvc_of_match, pdev-dev.of_node);
+ if (!match) {
+ dev_err(pdev-dev, unsupported device\n);
+ return -ENODEV;
+ }
+
+ r = tvc_probe_of(pdev, match-data);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -249,12 +298,33 @@ static int __exit tvc_remove(struct platform_device *pdev)
return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+ {
+ .compatible = ti,svideo-connector,
+ .data = tv_svideo_data,
+ },
+ {
+ .compatible = ti,composite-video-connector,
+ .data = tv_composite_video_data,
+ },
+ {},
+};
+
static struct platform_driver tvc_connector_driver = {
.probe = tvc_probe,
.remove = __exit_p(tvc_remove),
.driver = {
.name = connector-analog-tv,
.owner = THIS_MODULE,
+ .of_match_table = tvc_of_match,
},
};
--
1.8.1.2
--
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
[RFC 10/22] ARM: omap3.dtsi: add omapdss information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..3308b3f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -532,5 +532,48 @@
num-eps = 16;
ram-bits = 12;
};
+
+ dss@4805 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4805 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@48050400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x48050400 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ sdi: encoder@1 {
+ compatible = ti,omap3-sdi;
+ };
+
+ dsi: encoder@4804fc00 {
+ compatible = ti,omap3-dsi;
+ reg = 0x4804fc00 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dsi1;
+ };
+
+ rfbi: encoder@48050800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x48050800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ venc: encoder@48050c00 {
+ compatible = ti,omap3-venc;
+ reg = 0x48050c00 0x100;
+ ti,hwmods = dss_venc;
+ };
+ };
};
};
--
1.8.1.2
--
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
[RFC 07/22] OMAPFB: search for default display with DT alias
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for display0 DT alias
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 8bfe973..961c5c2 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2413,7 +2413,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
const char *def_name;
int i;
- /* search with the display name from the user or the board file */
+ /*
+* Search with the display name from the user or the board file,
+* comparing to display names and aliases
+*/
def_name = omapdss_get_default_display_name();
@@ -2425,12 +2428,30 @@ omapfb_find_default_display(struct omapfb2_device
*fbdev)
if (dssdev-name strcmp(def_name, dssdev-name) == 0)
return dssdev;
+
+ if (strcmp(def_name, dssdev-alias) == 0)
+ return dssdev;
}
/* def_name given but not found */
return NULL;
}
+ /* then look for DT alias display0 */
+ for (i = 0; i fbdev-num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+ int id;
+
+ dssdev = fbdev-displays[i].dssdev;
+
+ if (dssdev-dev-of_node == NULL)
+ continue;
+
+ id = of_alias_get_id(dssdev-dev-of_node, display);
+ if (id == 0)
+ return dssdev;
+ }
+
/* return the first display we have in the list */
return fbdev-displays[0].dssdev;
}
--
1.8.1.2
--
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
[RFC 09/22] OMAPDSS: Add DT support to DSI
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.
A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 53 ++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 0c8bd1f..bccf5fc 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,7 @@
#include linux/slab.h
#include linux/debugfs.h
#include linux/pm_runtime.h
+#include linux/of.h
#include video/omapdss.h
#include video/mipi_display.h
@@ -371,6 +372,13 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
};
+struct dsi_module_id_data {
+ u32 address;
+ int id;
+};
+
+static const struct of_device_id dsi_of_match[];
+
#ifdef DEBUG
static bool dsi_perf;
module_param(dsi_perf, bool, 0644);
@@ -5537,7 +5545,6 @@ static int omap_dsihw_probe(struct platform_device
*dsidev)
if (!dsi)
return -ENOMEM;
- dsi-module_id = dsidev-id;
dsi-pdev = dsidev;
dev_set_drvdata(dsidev-dev, dsi);
@@ -5587,6 +5594,31 @@ static int omap_dsihw_probe(struct platform_device
*dsidev)
return r;
}
+ if (dsidev-dev.of_node) {
+ const struct of_device_id *match;
+ const struct dsi_module_id_data *d;
+
+ match = of_match_node(dsi_of_match, dsidev-dev.of_node);
+ if (!match) {
+ DSSERR(unsupported DSI module\n);
+ return -ENODEV;
+ }
+
+ d = match-data;
+
+ while (d-address != 0 d-address != dsi_mem-start)
+ d++;
+
+ if (d-address == 0) {
+ DSSERR(unsupported DSI module\n);
+ return -ENODEV;
+ }
+
+ dsi-module_id = d-id;
+ } else {
+ dsi-module_id = dsidev-id;
+ }
+
/* DSI VCs initialization */
for (i = 0; i ARRAY_SIZE(dsi-vc); i++) {
dsi-vc[i].source = DSI_VC_SOURCE_L4;
@@ -5641,6 +5673,7 @@ static int omap_dsihw_probe(struct platform_device
*dsidev)
else if (dsi-module_id == 1)
dss_debugfs_create_file(dsi2_irqs, dsi2_dump_irqs);
#endif
+
return 0;
err_probe:
@@ -5694,6 +5727,23 @@ static const struct dev_pm_ops dsi_pm_ops = {
.runtime_resume = dsi_runtime_resume,
};
+static const struct dsi_module_id_data dsi_of_data_omap3[] = {
+ { .address = 0x4804fc00, .id = 0, },
+ { },
+};
+
+static const struct dsi_module_id_data dsi_of_data_omap4[] = {
+ { .address = 0x58004000, .id = 0, },
+ { .address = 0x58005000, .id = 1, },
+ { },
+};
+
+static const struct of_device_id dsi_of_match[] = {
+ { .compatible = ti,omap3-dsi, .data = dsi_of_data_omap3, },
+ { .compatible = ti,omap4-dsi, .data = dsi_of_data_omap4, },
+ {},
+};
+
static struct platform_driver omap_dsihw_driver = {
.probe = omap_dsihw_probe,
.remove = __exit_p(omap_dsihw_remove),
@@ -5701,6 +5751,7 @@ static struct platform_driver omap_dsihw_driver = {
.name = omapdss_dsi,
.owner = THIS_MODULE,
.pm = dsi_pm_ops,
+ .of_match_table = dsi_of_match,
},
};
--
1.8.1.2
--
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
[RFC 11/22] ARM: omap4.dtsi: add omapdss information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..ab19f16 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -663,5 +663,64 @@
ram-bits = 12;
ti,has-mailbox;
};
+
+ dss@5800 {
+ compatible = ti,omap4-dss, simple-bus;
+ reg = 0x5800 0x80;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,omap4-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = 0 25 0x4;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap4-dpi;
+ };
+
+ rfbi: encoder@58002000 {
+ compatible = ti,omap4-rfbi;
+ reg = 0x58002000 0x1000;
+ ti,hwmods = dss_rfbi;
+ };
+
+ /*
+* Accessing venc registers cause a crash on omap4, so
+* this is disabled for now.
+*/
+ /*
+ venc: encoder@58003000 {
+ compatible = ti,omap4-venc;
+ reg = 0x58003000 0x1000;
+ ti,hwmods = dss_venc;
+ };
+ */
+
+ dsi1: encoder@58004000 {
+ compatible = ti,omap4-dsi;
+ reg = 0x58004000 0x200;
+ interrupts = 0 53 0x4;
+ ti,hwmods = dss_dsi1;
+ };
+
+ dsi2: encoder@58005000 {
+ compatible = ti,omap4-dsi;
+ reg = 0x58005000 0x200;
+ interrupts = 0 84 0x4;
+ ti,hwmods = dss_dsi2;
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = ti,omap4-hdmi;
+ reg = 0x58006000 0x1000;
+ interrupts = 0 101 0x4;
+ ti,hwmods = dss_hdmi;
+ };
+ };
};
};
--
1.8.1.2
--
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
[RFC 14/22] ARM: omap3-tobi.dts: add lcd (TEST)
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-tobi.dts | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2a..0d136d8 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -81,3 +81,36 @@
mmc3 {
status = disabled;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+};
+
+/ {
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display@0 {
+ compatible = samsung,lte430wq-f0c, panel-dpi;
+ video-source = dpi;
+ data-lines = 24;
+
+ panel-timing {
+ clock-frequency = 920;
+ hactive = 480;
+ vactive = 272;
+ hfront-porch = 8;
+ hback-porch = 4;
+ hsync-len = 41;
+ vback-porch = 2;
+ vfront-porch = 4;
+ vsync-len = 10;
+
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+ };
+};
--
1.8.1.2
--
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
[RFC 13/22] ARM: omap4-sdp.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 70 +
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..49f98b1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -532,3 +532,73 @@
mode = 3;
power = 50;
};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+};
+
+dsi2 {
+ vdds_dsi-supply = vcxio;
+};
+
+hdmi {
+ vdda_hdmi_dac-supply = vdac;
+};
+
+/ {
+ aliases {
+ display0 = lcd0;
+ display1 = lcd1;
+ display2 = hdmi0;
+ };
+
+ lcd0: display@0 {
+ compatible = tpo,taal, panel-dsi-cm;
+
+ video-source = dsi1;
+
+ lanes =
+ 0 /* clk + */
+ 1 /* clk - */
+ 2 /* data1 + */
+ 3 /* data1 - */
+ 4 /* data2 + */
+ 5 /* data2 - */
+ ;
+
+ gpios = gpio4 6 0; /* 102, reset */
+ };
+
+ lcd1: display@1 {
+ compatible = tpo,taal, panel-dsi-cm;
+
+ video-source = dsi2;
+
+ lanes =
+ 0 /* clk + */
+ 1 /* clk - */
+ 2 /* data1 + */
+ 3 /* data1 - */
+ 4 /* data2 + */
+ 5 /* data2 - */
+ ;
+
+ gpios = gpio4 8 0; /* 104, reset */
+ };
+
+ tpd12s015: encoder@0 {
+ compatible = ti,tpd12s015;
+
+ video-source = hdmi;
+
+ gpios = gpio2 28 0, /* 60, CT CP HPD */
+ gpio2 9 0, /* 41, LS OE */
+ gpio2 31 0; /* 63, HPD */
+ };
+
+ hdmi0: connector@0 {
+ compatible = ti,hdmi_connector;
+
+ video-source = tpd12s015;
+ };
+};
--
1.8.1.2
--
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
[RFC 06/22] OMAPFB: clean up default display search
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 46
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905..8bfe973 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2407,6 +2407,34 @@ static int omapfb_init_connections(struct omapfb2_device
*fbdev,
return 0;
}
+static struct omap_dss_device *
+omapfb_find_default_display(struct omapfb2_device *fbdev)
+{
+ const char *def_name;
+ int i;
+
+ /* search with the display name from the user or the board file */
+
+ def_name = omapdss_get_default_display_name();
+
+ if (def_name) {
+ for (i = 0; i fbdev-num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+
+ dssdev = fbdev-displays[i].dssdev;
+
+ if (dssdev-name strcmp(def_name, dssdev-name) == 0)
+ return dssdev;
+ }
+
+ /* def_name given but not found */
+ return NULL;
+ }
+
+ /* return the first display we have in the list */
+ return fbdev-displays[0].dssdev;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2484,23 +2512,7 @@ static int omapfb_probe(struct platform_device *pdev)
for (i = 0; i fbdev-num_managers; i++)
fbdev-managers[i] = omap_dss_get_overlay_manager(i);
- def_display = NULL;
-
- for (i = 0; i fbdev-num_displays; ++i) {
- struct omap_dss_device *dssdev;
- const char *def_name;
-
- def_name = omapdss_get_default_display_name();
-
- dssdev = fbdev-displays[i].dssdev;
-
- if (def_name == NULL ||
- (dssdev-name strcmp(def_name, dssdev-name) == 0)) {
- def_display = dssdev;
- break;
- }
- }
-
+ def_display = omapfb_find_default_display(fbdev);
if (def_display == NULL) {
dev_err(fbdev-dev, failed to find default display\n);
r = -EPROBE_DEFER;
--
1.8.1.2
--
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
[RFC 16/22] OMAPDSS: panel-dsi-cm: Add DT support
XXX ULPS and backlight missing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/panel-dsi-cm.c | 87 +
1 file changed, 87 insertions(+)
diff --git a/drivers/video/omap2/displays-new/panel-dsi-cm.c
b/drivers/video/omap2/displays-new/panel-dsi-cm.c
index aaaea64..f65ea4d 100644
--- a/drivers/video/omap2/displays-new/panel-dsi-cm.c
+++ b/drivers/video/omap2/displays-new/panel-dsi-cm.c
@@ -22,6 +22,8 @@
#include linux/sched.h
#include linux/slab.h
#include linux/workqueue.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -1156,6 +1158,79 @@ static int dsicm_probe_pdata(struct platform_device
*pdev)
return 0;
}
+static int dsicm_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct omap_dss_device *in;
+ struct property *prop;
+ struct device_node *src_node;
+ u32 lane_arr[10];
+ int gpio, len, num_pins;
+ int r, i;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(pdev-dev, failed to parse reset gpio\n);
+ return gpio;
+ }
+ ddata-reset_gpio = gpio;
+
+ if (of_gpio_count(node) 1) {
+ gpio = of_get_gpio(node, 1);
+
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-ext_te_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse TE gpio\n);
+ return gpio;
+ }
+ } else {
+ ddata-ext_te_gpio = -1;
+ }
+
+ prop = of_find_property(node, lanes, len);
+ if (prop == NULL) {
+ dev_err(pdev-dev, failed to find lane data\n);
+ return -EINVAL;
+ }
+
+ num_pins = len / sizeof(u32);
+
+ if (num_pins 4 || num_pins % 2 != 0
+ || num_pins ARRAY_SIZE(lane_arr)) {
+ dev_err(pdev-dev, bad number of lanes\n);
+ return -EINVAL;
+ }
+
+ r = of_property_read_u32_array(node, lanes, lane_arr, num_pins);
+ if (r) {
+ dev_err(pdev-dev, failed to read lane data\n);
+ return r;
+ }
+
+ ddata-pin_config.num_pins = num_pins;
+ for (i = 0; i num_pins; ++i)
+ ddata-pin_config.pins[i] = (int)lane_arr[i];
+
+ /* TODO: ulps, backlight */
+
+ return 0;
+}
+
static int dsicm_probe(struct platform_device *pdev)
{
struct backlight_properties props;
@@ -1178,6 +1253,10 @@ static int dsicm_probe(struct platform_device *pdev)
r = dsicm_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = dsicm_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -1320,12 +1399,20 @@ static int __exit dsicm_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id dsicm_of_match[] = {
+ { .compatible = panel-dsi-cm, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dsicm_of_match);
+
static struct platform_driver dsicm_driver = {
.probe = dsicm_probe,
.remove = __exit_p(dsicm_remove),
.driver = {
.name = panel-dsi-cm,
.owner = THIS_MODULE,
+ .of_match_table = dsicm_of_match,
},
};
--
1.8.1.2
--
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
[RFC 20/22] OMAPDSS: hdmi-connector: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-hdmi.c | 36 +++
1 file changed, 36 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c
b/drivers/video/omap2/displays-new/connector-hdmi.c
index c582671..13f7a5e 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include drm/drm_edid.h
@@ -301,6 +302,29 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int hdmic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *src_node;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ return 0;
+}
+
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -318,6 +342,10 @@ static int hdmic_probe(struct platform_device *pdev)
r = hdmic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = hdmic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -359,12 +387,20 @@ static int __exit hdmic_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id hdmic_of_match[] = {
+ { .compatible = ti,hdmi_connector, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, hdmic_of_match);
+
static struct platform_driver hdmi_connector_driver = {
.probe = hdmic_probe,
.remove = __exit_p(hdmic_remove),
.driver = {
.name = connector-hdmi,
.owner = THIS_MODULE,
+ .of_match_table = hdmic_of_match,
},
};
--
1.8.1.2
--
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
[RFC 19/22] OMAPDSS: encoder-tpd12s015: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../video/omap2/displays-new/encoder-tpd12s015.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
index ce0e010..4650cc7 100644
--- a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
@@ -15,6 +15,7 @@
#include linux/slab.h
#include linux/gpio.h
#include linux/platform_device.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -289,6 +290,55 @@ static int tpd_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tpd_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *src_node;
+ int gpio;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ /* CT CP HPD GPIO */
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(pdev-dev, failed to parse CT CP HPD gpio\n);
+ return gpio;
+ }
+ ddata-ct_cp_hpd_gpio = gpio;
+
+ /* LS OE GPIO */
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-ls_oe_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse LS OE gpio\n);
+ return gpio;
+ }
+
+ /* HPD GPIO */
+ gpio = of_get_gpio(node, 2);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(pdev-dev, failed to parse HPD gpio\n);
+ return gpio;
+ }
+ ddata-hpd_gpio = gpio;
+
+ return 0;
+}
+
static int tpd_probe(struct platform_device *pdev)
{
struct omap_dss_device *in, *dssdev;
@@ -307,6 +357,10 @@ static int tpd_probe(struct platform_device *pdev)
r = tpd_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tpd_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -379,12 +433,20 @@ static int __exit tpd_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id tpd_of_match[] = {
+ { .compatible = ti,tpd12s015, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tpd_of_match);
+
static struct platform_driver tpd_driver = {
.probe = tpd_probe,
.remove = __exit_p(tpd_remove),
.driver = {
.name = tpd12s015,
.owner = THIS_MODULE,
+ .of_match_table = tpd_of_match,
},
};
--
1.8.1.2
--
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
[RFC 17/22] OMAPDSS: encoder-tfp410: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/encoder-tfp410.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/video/omap2/displays-new/encoder-tfp410.c
b/drivers/video/omap2/displays-new/encoder-tfp410.c
index a04f658..120da51 100644
--- a/drivers/video/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/omap2/displays-new/encoder-tfp410.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -179,6 +180,47 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *src_node;
+ int r, gpio, datalines;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-pd_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse PD gpio\n);
+ return gpio;
+ }
+
+ r = of_property_read_u32(node, data-lines, datalines);
+ if (r) {
+ dev_err(pdev-dev, failed to parse datalines\n);
+ return r;
+ }
+
+ ddata-data_lines = datalines;
+
+ return 0;
+}
+
static int tfp410_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -195,6 +237,10 @@ static int tfp410_probe(struct platform_device *pdev)
r = tfp410_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -251,12 +297,20 @@ static int __exit tfp410_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id tfp410_of_match[] = {
+ { .compatible = ti,tfp410, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tfp410_of_match);
+
static struct platform_driver tfp410_driver = {
.probe = tfp410_probe,
.remove = __exit_p(tfp410_remove),
.driver = {
.name = tfp410,
.owner = THIS_MODULE,
+ .of_match_table = tfp410_of_match,
},
};
--
1.8.1.2
--
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
[RFC 21/22] OMAPDSS: panel-dpi: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/panel-dpi.c | 75
1 file changed, 75 insertions(+)
diff --git a/drivers/video/omap2/displays-new/panel-dpi.c
b/drivers/video/omap2/displays-new/panel-dpi.c
index 5f8f7e7..31bd184 100644
--- a/drivers/video/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
+#include video/of_display_timing.h
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -182,6 +185,66 @@ static int panel_dpi_probe_pdata(struct platform_device
*pdev)
return 0;
}
+static int panel_dpi_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *src_node;
+ int r, datalines;
+ struct display_timing timing;
+ struct videomode vm;
+ int gpio;
+
+ src_node = of_parse_phandle(node, video-source, 0);
+ if (!src_node) {
+ dev_err(pdev-dev, failed to parse video source\n);
+ return -ENODEV;
+ }
+
+ in = omap_dss_find_output_by_node(src_node);
+ if (in == NULL) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return -EPROBE_DEFER;
+ }
+ ddata-in = in;
+
+ r = of_property_read_u32(node, data-lines, datalines);
+ if (r) {
+ dev_err(pdev-dev, failed to parse datalines\n);
+ return r;
+ }
+
+ ddata-data_lines = datalines;
+
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-enable_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse enable gpio\n);
+ return gpio;
+ }
+
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-backlight_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse backlight gpio\n);
+ return gpio;
+ }
+
+ r = of_get_display_timing(node, panel-timing, timing);
+ if (r) {
+ dev_err(pdev-dev, failed to get video timing\n);
+ return r;
+ }
+
+ videomode_from_timing(timing, vm);
+ videomode_to_omap_video_timings(vm, ddata-videomode);
+
+ return 0;
+}
+
static int panel_dpi_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -198,6 +261,10 @@ static int panel_dpi_probe(struct platform_device *pdev)
r = panel_dpi_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -254,12 +321,20 @@ static int __exit panel_dpi_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id panel_dpi_of_match[] = {
+ { .compatible = panel-dpi, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, panel_dpi_of_match);
+
static struct platform_driver panel_dpi_driver = {
.probe = panel_dpi_probe,
.remove = __exit_p(panel_dpi_remove),
.driver = {
.name = panel-dpi,
.owner = THIS_MODULE,
+ .of_match_table = panel_dpi_of_match,
},
};
--
1.8.1.2
--
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
[RFC 03/22] ARM: OMAP2+: add omapdss_init_of()
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 2 ++
arch/arm/mach-omap2/common.h| 2 ++
arch/arm/mach-omap2/display.c | 34 ++
3 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index d388d33..aaf1125 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -61,6 +61,8 @@ static void __init omap_generic_init(void)
legacy_init_ehci_clk(auxclk3_ck);
else if (of_machine_is_compatible(ti,omap5-uevm))
legacy_init_ehci_clk(auxclk1_ck);
+
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dfcc182..377900c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -300,5 +300,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
/* SoC specific clock initializer */
extern int (*omap_clk_init)(void);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..c62aee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err(DSS not supported on this SoC\n);
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
+
+ return 0;
+}
--
1.8.1.2
--
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
[RFC 15/22] ARM: omap3-beagle.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..17cb9b0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -180,3 +180,32 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ video-source = dpi;
+ data-lines = 24;
+ gpios = gpio5 10 0; /* 170, power-down */
+ };
+
+ dvi0: connector@0 {
+ compatible = ti,dvi_connector;
+ video-source = tfp410;
+ i2c-bus = i2c3;
+ };
+
+ tv0: connector@1 {
+ compatible = ti,svideo_connector;
+ video-source = venc;
+ };
+};
--
1.8.1.2
--
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
[RFC 08/22] OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
Add the code to make DSS, DISPC, DPI, HDMI and VENC drivers work with
device tree on OMAP3 and OMAP4. The only change is adding the
of_match_tables.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c | 7 +++
drivers/video/omap2/dss/dpi.c | 8
drivers/video/omap2/dss/dss.c | 10 ++
drivers/video/omap2/dss/hdmi.c | 6 ++
drivers/video/omap2/dss/venc.c | 7 +++
5 files changed, 38 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 02a7340..b4dccb8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3743,12 +3743,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
};
+static const struct of_device_id dispc_of_match[] = {
+ { .compatible = ti,omap3-dispc, },
+ { .compatible = ti,omap4-dispc, },
+ {},
+};
+
static struct platform_driver omap_dispchw_driver = {
.remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = omapdss_dispc,
.owner = THIS_MODULE,
.pm = dispc_pm_ops,
+ .of_match_table = dispc_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index a6b331e..6b832c8 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/string.h
+#include linux/of.h
#include video/omapdss.h
@@ -801,12 +802,19 @@ static int __exit omap_dpi_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id dpi_of_match[] = {
+ { .compatible = ti,omap3-dpi, },
+ { .compatible = ti,omap4-dpi, },
+ {},
+};
+
static struct platform_driver omap_dpi_driver = {
.probe = omap_dpi_probe,
.remove = __exit_p(omap_dpi_remove),
.driver = {
.name = omapdss_dpi,
.owner = THIS_MODULE,
+ .of_match_table = dpi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608..d0d61b1 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -23,6 +23,7 @@
#define DSS_SUBSYS_NAME DSS
#include linux/kernel.h
+#include linux/module.h
#include linux/io.h
#include linux/export.h
#include linux/err.h
@@ -955,12 +956,21 @@ static const struct dev_pm_ops dss_pm_ops = {
.runtime_resume = dss_runtime_resume,
};
+static const struct of_device_id dss_of_match[] = {
+ { .compatible = ti,omap3-dss, },
+ { .compatible = ti,omap4-dss, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dss_of_match);
+
static struct platform_driver omap_dsshw_driver = {
.remove = __exit_p(omap_dsshw_remove),
.driver = {
.name = omapdss_dss,
.owner = THIS_MODULE,
.pm = dss_pm_ops,
+ .of_match_table = dss_of_match,
},
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 1b38f1f..1cea0ab 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1374,6 +1374,11 @@ static const struct dev_pm_ops hdmi_pm_ops = {
.runtime_resume = hdmi_runtime_resume,
};
+static const struct of_device_id hdmi_of_match[] = {
+ { .compatible = ti,omap4-hdmi, },
+ {},
+};
+
static struct platform_driver omapdss_hdmihw_driver = {
.probe = omapdss_hdmihw_probe,
.remove = __exit_p(omapdss_hdmihw_remove),
@@ -1381,6 +1386,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
.name = omapdss_hdmi,
.owner = THIS_MODULE,
.pm = hdmi_pm_ops,
+ .of_match_table = hdmi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 496a106..93e13dd 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -980,6 +980,12 @@ static const struct dev_pm_ops venc_pm_ops = {
.runtime_resume = venc_runtime_resume,
};
+
+static const struct of_device_id venc_of_match[] = {
+ { .compatible = ti,omap3-venc, },
+ {},
+};
+
static struct platform_driver omap_venchw_driver = {
.probe = omap_venchw_probe,
.remove = __exit_p(omap_venchw_remove),
@@ -987,6 +993,7 @@ static struct platform_driver omap_venchw_driver = {
.name = omapdss_venc,
.owner = THIS_MODULE,
.pm = venc_pm_ops,
+ .of_match_table = venc_of_match,
},
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
[RFC 12/22] ARM: omap4-panda.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 48 +++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..fa65b19 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -357,3 +357,51 @@
usbhsehci {
phys = hsusb1_phy;
};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+};
+
+dsi2 {
+ vdds_dsi-supply = vcxio;
+};
+
+hdmi {
+ vdda_hdmi_dac-supply = vdac;
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ video-source = dpi;
+ data-lines = 24;
+ gpios = gpio1 0 0; /* 0, power-down */
+ };
+
+ dvi0: connector@0 {
+ compatible = ti,dvi_connector;
+ video-source = tfp410;
+ i2c-bus = i2c3;
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = ti,tpd12s015;
+
+ video-source = hdmi;
+
+ gpios = gpio2 28 0, /* 60, CT CP HPD */
+ gpio2 9 0, /* 41, LS OE */
+ gpio2 31 0; /* 63, HPD */
+ };
+
+ hdmi0: connector@1 {
+ compatible = ti,hdmi_connector;
+
+ video-source = tpd12s015;
+ };
+};
--
1.8.1.2
--
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
Question about SMP boot on OMAP5432
Hi all, I'm reading OMAP5's smp boot codes and have got a question. From my understanding, the omap4_omap_prepare_cpus() would set the startup address of secondary core, while omap4_boot_secondary() would set AuxCoreBoot0 to 0x20 which may make the omap5_secondary_startup() jump out of wait loop to secondary_startup. And the comment in omap4_smp_prepare_cpus says: Write the address of secondary startup routine into the AuxCoreBoot1 where ROM code will jump and start executing on secondary core once out of *WFE* My question is: How will ROM code be out of WFE? Is it waked up by dsb_sev() in omap4_boot_secondary()? If so, how should I understand the comment in omap4_boot_secondary(): Update the AuxCoreBoot0 with boot state for secondary core. omap4(5)_secondary_startup() routine will hold the secondary core till the AuxCoreBoot1 register is update with cpu state. Since the entry to omap5_secondary_startup() is set up by AuxCoreBoot1, it seems a chicken and egg problem. And I didn't see any codes deal with AuxCoreBoot1 in either omap4_secondary_startup() or omap5_secondary_startup(). Thanks. Chen Baozi -- 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] ARM: omap2: Use a consistent AM33XX SoC option description
On Thu, Aug 8, 2013 at 11:32 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Fix the option description to match the other TI SoCs. This is just a cosmetic change. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/mach-omap2/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 76170dd..56021c6 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -64,7 +64,7 @@ config SOC_OMAP5 select ARM_ERRATA_798181 if SMP config SOC_AM33XX - bool AM33XX support + bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS select ARM_CPU_SUSPEND if PM -- 1.8.1.5 Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org -- 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
Ti-st suspend/resume hooks
Hi, Our i.Mx6 based platform has a wl12xx chip and the ti-st driver is in use. When the system goes to suspend, the st_kim module fails to suspend giving out -EOPNOTSUPP [1], which is quite evident from the the missing suspend/resume hooks in the wilink_platform_data. [2] Are there any ways to make this ti-st driver suspend/resume aware? Thanks, Vikram [1] http://lxr.linux.no/linux+v3.10.5/drivers/misc/ti-st/st_kim.c#L833 [2] http://lxr.linux.no/linux+v3.10.5/arch/arm/mach-omap2/board-omap4panda.c#L58 P.S: I'm not subscribed to the list. Please keep me Cc'd. -- 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
[RFC PATCH v2 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: Ivan T. Ivanov iiva...@mm-sol.com
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/dwc3/Kconfig|8 ++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-msm.c | 174 +++
3 files changed, 183 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 3e225d5..e2032c4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -70,6 +70,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate Qualcomm MSM/APQ Platforms
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..f442249
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,174 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/usb/phy.h
+
+struct dwc3_msm {
+ struct device *dev;
+ void __iomem*base;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+ struct clk *utmi_clk;
+
+ struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ dev_info(pdev-dev, MSM DWC3\n);
+
+ mdwc = devm_kzalloc(pdev-dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc) {
+ dev_err(pdev-dev, not enough memory\n);
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pdev, mdwc);
+ mdwc-dev = pdev-dev;
+
+ mdwc-gdsc = devm_regulator_get(mdwc-dev, gdsc);
+
+ mdwc-core_clk = devm_clk_get(pdev-dev, core_clk);
+ if (IS_ERR(mdwc-core_clk)) {
+ dev_err(pdev-dev, failed to get core_clk\n);
+ return PTR_ERR(mdwc-core_clk);
+ }
+
+ mdwc-iface_clk = devm_clk_get(pdev-dev, iface_clk);
+ if (IS_ERR(mdwc-iface_clk)) {
+ dev_err(pdev-dev, failed to get iface_clk\n);
+ return PTR_ERR(mdwc-iface_clk);
+ }
+
+ mdwc-sleep_clk = devm_clk_get(pdev-dev, sleep_clk);
+ if (IS_ERR(mdwc-sleep_clk)) {
+ dev_err(pdev-dev, failed to get sleep_clk\n);
+ return PTR_ERR(mdwc-sleep_clk);
+ }
+
+ mdwc-utmi_clk = devm_clk_get(pdev-dev, utmi_clk);
+ if (IS_ERR(mdwc-utmi_clk)) {
+ dev_err(pdev-dev, failed to get utmi_clk\n);
+ return PTR_ERR(mdwc-utmi_clk);
+ }
+
+ if (!IS_ERR(mdwc-gdsc)) {
+ ret = regulator_enable(mdwc-gdsc);
+ if (ret)
+ dev_err(mdwc-dev, unable to enable usb3 gdsc\n);
+ }
+
+ /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and 60MHZ for HSUSB mode.
+*/
+ clk_set_rate(mdwc-core_clk, 12500);
+ clk_prepare_enable(mdwc-core_clk);
+ clk_prepare_enable(mdwc-iface_clk);
+ clk_prepare_enable(mdwc-sleep_clk);
+ clk_prepare_enable(mdwc-utmi_clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(pdev-dev, res);
+ if (!tcsr) {
+
[RFC PATCH v2 0/3] DWC3 USB support for Qualcomm platform
From: Ivan T. Ivanov iiva...@mm-sol.com Hi, These patches add basic support for USB3.0 controllers found on MSM platforms. USB3.0 core is based on Synopsys DesignWare SuperSpeed IP. Changes since first version: * Split devicetree bindings description file to separate patch * Address comments for device bindings description * Fix typo in 'gdsc' requlator name. With fake regulators and clocks support drivers could be successfully loaded, but nothing more, of course. Generated on top of Felipe 'testing' branch. Regards, Ivan Ivan T. Ivanov (3): usb: dwc3: msm: Add device tree binding information usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/usb/msm-ssusb.txt | 101 + drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-msm.c| 174 + drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-msm-dwc3-hs.c | 340 + drivers/usb/phy/phy-msm-dwc3-ss.c | 387 8 files changed, 1024 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt create mode 100644 drivers/usb/dwc3/dwc3-msm.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c -- 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
[RFC PATCH v2 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
From: Ivan T. Ivanov iiva...@mm-sol.com
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile |2 +
drivers/usb/phy/phy-msm-dwc3-hs.c | 340
drivers/usb/phy/phy-msm-dwc3-ss.c | 387 +
4 files changed, 740 insertions(+)
create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 5443958..40e83b5 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -202,6 +202,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate Qualcomm DWC3 USB controller PHY's support
+ depends on (USB || USB_GADGET) ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool Generic ULPI Transceiver Driver
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 98730ca..ddaa11c 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-ss.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c
b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 000..d91c595
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,340 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/usb/phy.h
+
+/**
+ * USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG (0x04)
+#define QSCRATCH_GENERAL_CFG (0x08)
+#define PHY_CTRL_REG (0x10)
+#define PARAMETER_OVERRIDE_X_REG (0x14)
+#define CHARGING_DET_CTRL_REG (0x18)
+#define CHARGING_DET_OUTPUT_REG(0x1c)
+#define ALT_INTERRUPT_EN_REG (0x20)
+#define PHY_IRQ_STAT_REG (0x24)
+#define CGCTL_REG (0x28)
+
+#define PHY_3P3_VOL_MIN305 /* uV */
+#define PHY_3P3_VOL_MAX330 /* uV */
+#define PHY_3P3_HPM_LOAD 16000 /* uA */
+
+#define PHY_1P8_VOL_MIN180 /* uV */
+#define PHY_1P8_VOL_MAX180 /* uV */
+#define PHY_1P8_HPM_LOAD 19000 /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO 1 /* uV */
+#define USB_VDDCX_MIN 5 /* uV */
+#define USB_VDDCX_MAX 7 /* uV */
+
+struct msm_dwc3_hs_phy {
+ struct usb_phy phy;
+ void __iomem*base;
+ struct device *dev;
+
+ struct clk *xo_clk;
+ struct clk *sleep_a_clk;
+
+ struct regulator*v3p3;
+ struct regulator*v1p8;
+ struct regulator*vddcx;
+ struct regulator*vbus;
+};
+
+#definephy_to_dwc3_phy(x) container_of((x), struct
[RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS)
and HS, SS PHY's controll and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
.../devicetree/bindings/usb/msm-ssusb.txt | 101
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..7a97163
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,101 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+Required properities :
+- compatible : sould be qcom,dwc3-hsphy;
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ xo : External reference clock 19 MHz
+ sleep_a_clk : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+supply-name-supply : phandle to the regulator device tree node
+Required supply-name are:
+ v1p8 : 1.8v supply for HSPHY
+ v3p3 : 3.3v supply for HSPHY
+ vbus : vbus supply for host mode
+ vddcx : vdd supply for HS-PHY digital circuit operation
+
+Required properities :
+- compatible : sould be qcom,dwc3-ssphy;
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ xo : External reference clock 19 MHz
+ ref_clk : Reference clock - used in host mode.
+supply-name-supply : phandle to the regulator device tree node
+Required supply-name are:
+ v1p8 : 1.8v supply for SS-PHY
+ vddcx : vdd supply for SS-PHY digital circuit operation
+
+Required properties :
+- compatible : should be qcom,dwc3
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ core_clk : Master/Core clock, have to be = 125 MHz for SS
+ operation and = 60MHz for HS operation
+ iface_clk : System bus AXI clock
+ sleep_clk : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+ utmi_clk : Generated by HS-PHY. Used to clock the low power
+ parts of thr HS Link layer.
+
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+
+Sub nodes:
+- Sub node for DWC3 USB3 controller.
+ This sub node is required property for device node. The properties
+ of this subnode are specified in dwc3.txt.
+
+Example device nodes:
+
+ dwc3_hsphy: phy@f92f8800 {
+ compatible = qcom,dwc3-hsphy;
+ reg = 0xf92f8800 0x30;
+
+ clocks = cxo, usb2a_phy_sleep_cxc;
+ clock-names = xo, sleep_a_clk;
+
+ vbus-supply = supply;
+ vddcx-supply = supply;
+ v1p8-supply = supply;
+ v3p3-supply = supply;
+ };
+
+ dwc3_ssphy: phy@f92f8830 {
+ compatible = qcom,dwc3-ssphy;
+ reg = 0xf92f8830 0x30;
+
+ clocks = cxo, usb30_mock_utmi_cxc;
+ clock-names = xo, ref_clk;
+
+ vddcx-supply = supply;
+ v1p8-supply = supply;
+ };
+
+ usb@fd4ab000 {
+ compatible = qcom,dwc3;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xfd4ab000 0x4;
+
+ clocks = usb30_master_cxc, sys_noc_usb3_axi_cxc,
+ usb30_sleep_cxc, usb30_mock_utmi_cxc;
+ clock-names = core_clk, iface_clk, sleep_clk, utmi_clk;
+
+ gdsc-supply = supply;
+ ranges;
+
+ dwc3@f920 {
+ compatible = snps,dwc3;
+ reg = 0xf920 0xcd00;
+ interrupts = 0 131 0;
+ interrupt-names = irq;
+ usb-phy = dwc3_hsphy, dwc3_ssphy;
+ tx-fifo-resize;
+ };
+ };
--
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
Re: [PATCH 00/21] ARM: OMAP2+: use new display drivers
Hi Tony, Ping. It'd be nice to get this in for 3.12, so I can remove all the old drivers and the related legacy code. Note that the first patch ARM: OMAP: dss-common: fix Panda's DVI DDC channel, is a fix for 3.11, and I've sent a fbdev pull request containing that just now. Merging without that patch will cause a trivial conflict. If you want, I can also create a branch that has these on top of the fbdev-fixes branch. Tomi On 26/07/13 10:08, Tomi Valkeinen wrote: Hi, The display drivers for new OMAP DSS driver model were merged in v3.11, but the board files were not changed to use them. This series changes the board files to take those new drivers into use. There's mostly nothing special in the patches. One complication is with Overo board file, which adds two panel devices, located in add-on boards, that use the same GPIOs, meaning that the two panel devices cannot be probed at the same time. The solution used here is to parse the kernel command line, and decide the panel device to be added depending on the given default display. The omap2plus_defconfig is changed to include a few most commonly used display drivers as modules, and the old drivers are removed. Note: The first patch in this series has been sent separately (http://mid.gmane.org/1374570405-8301-2-git-send-email-tomi.valkei...@ti.com), and is a fix for v3.11. It's included here as an another patch in the series depends on it. Tested on 4430SDP, Panda, Beagle, Beagle xM, Overo. Tomi Tomi Valkeinen (21): ARM: OMAP: dss-common: fix Panda's DVI DDC channel ARM: OMAP2+: Remove legacy DSS initialization for omap4 ARM: OMAP2+: Add selected display drivers to omap2plus_defconfig ARM: OMAP: dss-common: use new display drivers ARM: OMAP: 4430SDP: remove picodlp device data ARM: OMAP: overo: use new display drivers ARM: OMAP: rx51: use new display drivers ARM: OMAP: beagle: use new display drivers ARM: OMAP: devkit8000: use new display drivers ARM: OMAP: 2430SDP: use new display drivers ARM: OMAP: LDP: use new display drivers ARM: OMAP: omap3stalker: use new display drivers ARM: OMAP: igep0020: use new display drivers ARM: OMAP: cm-t35: use new display drivers ARM: OMAP: H4: use new display drivers ARM: OMAP: 3430SDP: use new display drivers ARM: OMAP: OMAP3EVM: use new display drivers ARM: OMAP: Pandora: use new display drivers ARM: OMAP: Zoom: use new display drivers ARM: OMAP: AM3517EVM: use new display drivers ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig arch/arm/configs/omap2plus_defconfig | 12 +- arch/arm/mach-omap2/board-2430sdp.c | 57 --- arch/arm/mach-omap2/board-3430sdp.c | 83 + arch/arm/mach-omap2/board-am3517evm.c| 113 + arch/arm/mach-omap2/board-cm-t35.c | 100 +++ arch/arm/mach-omap2/board-devkit8000.c | 96 +++ arch/arm/mach-omap2/board-h4.c | 48 -- arch/arm/mach-omap2/board-igep0020.c | 36 ++-- arch/arm/mach-omap2/board-ldp.c | 68 +--- arch/arm/mach-omap2/board-omap3beagle.c | 56 +++--- arch/arm/mach-omap2/board-omap3evm.c | 87 ++ arch/arm/mach-omap2/board-omap3pandora.c | 48 +++--- arch/arm/mach-omap2/board-omap3stalker.c | 61 --- arch/arm/mach-omap2/board-overo.c| 160 +++--- arch/arm/mach-omap2/board-rx51-peripherals.c | 12 ++ arch/arm/mach-omap2/board-rx51-video.c | 35 ++-- arch/arm/mach-omap2/board-zoom-display.c | 30 ++-- arch/arm/mach-omap2/dss-common.c | 244 --- arch/arm/mach-omap2/dss-common.h | 2 - 19 files changed, 787 insertions(+), 561 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi,
On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..e509abc
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,175 @@
+#undef CONFIG_REGULATOR
why ??
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ dev_info(pdev-dev, MSM DWC3\n);
please don't. This is hardly necessary.
+ mdwc = devm_kzalloc(pdev-dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc) {
+ dev_err(pdev-dev, not enough memory\n);
this message isn't needed either
+ /*
+ * DWC3 Core requires its CORE CLK (aka master / bus clk) to
+ * run at 125Mhz in SSUSB mode and 60MHZ for HSUSB mode.
+ */
+ clk_set_rate(mdwc-core_clk, 12500);
if this is dwc3's core clock, why don't we teach dwc3.ko about this
requirement ? Just make sure to have it optional, since x86 and OMAP
wouldn't need direct fiddling with the clocks.
+ clk_prepare_enable(mdwc-core_clk);
+ clk_prepare_enable(mdwc-iface_clk);
+ clk_prepare_enable(mdwc-sleep_clk);
+ clk_prepare_enable(mdwc-utmi_clk);
do you really need to enable your clocks here ? Why don't you enable
them on runtime_resume and disable on runtime_suspend ?
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(pdev-dev, res);
+ if (!tcsr) {
+ dev_dbg(pdev-dev, tcsr ioremap failed\n);
no need to ioremap, also you're likely leaking clocks and regulators
enabled here.
Make sure to have something like:
if (!tcsr)
goto err_disable_clocks;
/* TODO This has to be revised */\
[...]
+ } else {
+ /* TODO: This has to be revised */
+
+ /* Enable USB3 on the primary USB port. */
+ writel_relaxed(0x1, tcsr);
+ /*
+ * Ensure that TCSR write is completed before
+ * USB registers initialization.
+ */
+ mb();
why don't you use writel() instead. It will add the memory barrier for
you.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi,
On Tue, Aug 06, 2013 at 01:21:38PM +0100, Pawel Moll wrote:
@@ -47,3 +64,25 @@ Example device nodes:
vddcx-supply = supply;
v1p8-supply = supply;
};
+
+ usb@fd4ab000 {
+ compatible = qcom,dwc-usb3-msm;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xfd4ab000 0x4;
+
+ clocks = usb30_master_cxc, sys_noc_usb3_axi_cxc,
usb30_sleep_cxc, usb30_mock_utmi_cxc;
+ clock-names = core_clk, iface_clk, sleep_clk, utmi_clk;
+
+ gdsc-supply = supply;
+ ranges;
+
+ dwc3@f920 {
+ compatible = snps,dwc3;
Note that the Documentation/devicetree/bindings/usb/dwc3.txt is
mentioning synopsys,dwc3 (which is clearly in opposition to the
I have a patch converting to snps,dwc3.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: dwc3-pci: Ensure system sleep PM ops are defined only when used
On Wed, Aug 07, 2013 at 06:01:00PM +0800, Andy Green wrote: On 7 August 2013 17:34, Mark Brown broo...@kernel.org wrote: On Tue, Aug 06, 2013 at 10:35:52PM -0300, Fabio Estevam wrote: On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown broo...@kernel.org wrote: From: Andy Green andy.gr...@linaro.org You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which case these are unused. Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Mark Brown broo...@linaro.org What about doing this instead? Makes sense to me - Andy? Sure, it seems a much more complete solution. looks good to me too, please send it as a real patch (if you already have, sorry about that, catching up with my inbox now). -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH v2 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Fri, Aug 09, 2013 at 12:53:47PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com DWC3 glue layer is hardware layer around Synopsys DesignWare USB3 core. Its purpose is to supply Synopsys IP with required clocks, voltages and interface it with the rest of the SoC. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com same comments from previous version. -- balbi signature.asc Description: Digital signature
[GIT PULL, FOR LINUX-OMAP] usb: nop phy rename
Hi Tony,
here's a pull request of one patch to avoid conflicts during the merge
window.
Please consider applying to your tree and I'll take this same patch
upstream.
The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095:
Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git nop-phy-rename
for you to fetch changes up to 3fa4d7344be0afebd80382ffeea6b1787cccf971:
usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv (2013-08-09 17:26:00
+0300)
Sebastian Andrzej Siewior (1):
usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv
arch/arm/mach-omap2/board-omap3beagle.c| 4 +-
arch/arm/mach-omap2/board-omap3evm.c | 4 +-
arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
arch/arm/mach-omap2/usb-host.c | 10 ++---
drivers/usb/dwc3/dwc3-exynos.c | 8 ++--
drivers/usb/dwc3/dwc3-pci.c| 8 ++--
drivers/usb/musb/am35x.c | 2 +-
drivers/usb/musb/blackfin.c| 2 +-
drivers/usb/musb/da8xx.c | 2 +-
drivers/usb/musb/davinci.c | 2 +-
drivers/usb/musb/musb_dsps.c | 2 +-
drivers/usb/musb/tusb6010.c| 2 +-
drivers/usb/phy/Makefile | 2 +-
drivers/usb/phy/{phy-nop.c = phy-generic.c} | 44 +++---
.../usb/{nop-usb-xceiv.h = usb_phy_gen_xceiv.h} | 4 +-
15 files changed, 49 insertions(+), 49 deletions(-)
rename drivers/usb/phy/{phy-nop.c = phy-generic.c} (83%)
rename include/linux/usb/{nop-usb-xceiv.h = usb_phy_gen_xceiv.h} (81%)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: dwc3-pci: Ensure system sleep PM ops are defined only when used
On Fri, Aug 9, 2013 at 10:26 AM, Felipe Balbi ba...@ti.com wrote: looks good to me too, please send it as a real patch (if you already have, sorry about that, catching up with my inbox now). Yes, I have already sent it as a formal patch. -- 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: [PATCHv3 4/9] ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec
Santosh Shilimkar santosh.shilim...@ti.com writes: On Thursday 08 August 2013 04:05 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: On Thursday 08 August 2013 02:16 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: From: Vaibhav Bedia vaibhav.be...@ti.com SDRAM controller on AM33XX requires that a modification of certain bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in AM335x-Rev H) is followed by a dummy read access to SDRAM. This scenario arises when entering a low power state like DeepSleep. To ensure that the read is not from a cached region we reserve some memory during bootup using the arm_memblock_steal() API. Hmm, sounds to me an awful lot like the existing omap_bus_sync() ? All the credit of that awful omap_bus_sync() goes to me since I introduced it. And I keep beating the hardware guys who have not left a choice but to introduce the ugly work around in software. ;-) Agreed, but what's even more awful than the current version is duplicating it in a slightly different way using yet another whole page mapping for a single read/write location. The real issue is limitation of the kernel memory steal(memblock) API which won't let you still less than 1 MB. It would have been ok for page allocation because that is any way what you will get minimum on standard non-cached allocations. All the more reason that the omap_bus_sync() should be refactored slightly in a way that would be reusable for AM33xx. Kevin -- 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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
On 08/08/2013 06:04 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 04:14 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/08/2013 10:03 AM, Santosh Shilimkar wrote: $subject and patch don't match. On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote: On 08/08/2013 03:45 AM, Russ Dill wrote: In reference to the M3 handling it, the M3 wouldn't know which devices have a driver bound and which don't. Does it need to? M3 firmware can pretty much define I will force the device into low power state, and if the drivers dont handle things properly, fix the darned driver. M3 behavior should be considered as a hardware as far as Linux running on MPU is concerned, and firmware helps change the behavior by accounting for SoC quirks. *if* we have ability to handle this in the firmware, there is no need to carry this in Linux. I agree with Nishant. I don't like this patch and IIRC, I gave same comment in the last version. Linux need not know about all such firmware quirks. Also all these M3 specific stuff, should be done somewhere else. Probably having a small M3 driver won't be a bad idea. I am not opposed to doing it this way and letting the M3 firmware handle idling these modules, however the one concern raised in the last series is that an approach that does not acknowledge drivers will hide driver PM bugs. I suppose as long as I make sure to document that the devices are being idled by the M3 firmware this may not be an issue. I will look into implementing this. No, please don't start idling devices in firmware that are otherwise managed by Linux. Keep the firmware simple and dumb. Linux is managing these devices, it should manage their bugs too. This is not just about idling devices. This is about handling broken IP blocks whose power-on reset state does not allow the the powerdomain to reach its target state. That's just bad hardware design. Right, this is where M3 can help - provide a consistent state for linux kernel to work with. by the fact that we want to keep majority of the power code inside master CPU, we are just letting M3 help us with nothing major at all.. heh, I would say HW design bugs like this are more than nothing major at all. :) tiny stuff like these can help fix the hardware design quirks by hiding it behind the firmware and modifying the hardware behavior. I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. My view is that the M3 should *ignore* the presence/existence of MPU's drivers. M3 will do whatever to force the system to go to suspend once notified - this saves us the prehistoric perpetual trouble when drivers have bugs (which get exposed in weird usage scenarios) in production systems, we dont get any hardware help to fix them up while attempting low power states and system never really hits low power state. This was always because OMAP and it's derivatives have been democratic in power management - if every hardware block achieves proper state, then we achieve a system-wide low power state. I know it breaks the purity of role, but as the next evolution, we might want to consider M3 something like an accelerator for power management activity.. (not saying it is that fast.. but conceptually). Yes, it breaks the purity of role, and makes it hard to maintain and extend to future SoCs. As a maintainer, that's a red flag. IMO, the roles need to be kept clear. The M3 manages some devices and the interconnect that MPU/Linux cannot, the rest are managed by Linux. suspend is a very controlled state as against cpuidle where driver knowledge is necessary and in fact mandatory. drivers are supposed to release their resources - and even though we test the hell out of them, we do have paths untrodden when it comes to production systems. I think the insight we have about the hardware make us(linux folks) want to own the decision making process on the master MPU - I mean, *nobody*(including me) wants to trust a firmware - that word is almost synonymous with unspeakable horror. If on the other hand, we had a non-programmable hardware which would force all systems to achieve off mode (imagine having a PRCM which was really capable of doing it), we would have probably not had to deal with those pesky stuck-in-transition and other variants of issues (where MPU went to low power state, but core refused to go down - resulting in 200mA+ power instead of the 1mA we expected to see). I consider M3 to power management similar to what Neon is to ARM. I
Re: [PATCH 3/5] omap: Properly handle resources for omap_devices
Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi Kevin, On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote: [fixing address for Benoit] Pantelis Antoniou pa...@antoniou-consulting.com writes: omap_device relies on the platform notifier callbacks managing resources behind the scenes. The resources were not properly linked causing crashes when removing the device. Rework the resource modification code so that linking is performed properly, and make sure that no resources that have no parent (which can happen for DMA IRQ resources) are ever left for cleanup by the core resource layer. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com This one failed my took more than 15 minutes to understand test. The changelog is rather vague (especially about what properly means), and the combination of moving code and changing it makes the patch rather clunky to read, so I remain a bit confused about what the actual problem is. Please elaborate. Also, could you share a crash dump as well as details about how to reproduce this problem? Thanks, Kevin It's the full patchset that fixes the problem: Let me illustrate: The kernel I use is located at: g...@github.com:pantoniou/linux-beagle-track-mainline.git branch: merge-20130806 (there are topic branches for other stuff too) Sorry, I don't have the time to go through a bunch of out of tree branches to figure this out. Can you create a simpler test case to reproduce this? e.g. Does this happen when building the serial driver as a module and then removing it? If not, why not? Kevin -- 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 v2 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi, On Fri, 2013-08-09 at 16:32 +0300, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 12:53:47PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com DWC3 glue layer is hardware layer around Synopsys DesignWare USB3 core. Its purpose is to supply Synopsys IP with required clocks, voltages and interface it with the rest of the SoC. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com same comments from previous version. Sorry, I have somehow missed Your email. I will address them shortly. Regard, Ivan -- 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 2/4] crypto: omap-sham: Add OMAP5/AM43XX SHAM Support
On Fri, Jul 26, 2013 at 07:59:15AM +0100, Lokesh Vutla wrote:
Add support for the OMAP5 version of the SHAM module
that is present on OMAP5 and AM43xx SoCs.
This module is very simialar to OMAP4 version of SHAM module,
and adds SHA384 SHA512 hardware-accelerated hash functions to it.
To handle the higher digest size of SHA512, few SHA512_DIGEST_i
(i=1-16, and first 8 registers are duplicated from SHA_DIGEST_i
registers) registers are added at the end of register set.
So adding the above register offsets and module info in pdata.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-sham.c | 44
1 file changed, 44 insertions(+)
+ {
+ .compatible = ti,omap5-sham,
+ .data = omap_sham_pdata_omap5,
+ },
No binding update?
Mark.
--
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 3/5] omap: Properly handle resources for omap_devices
Hi On Aug 9, 2013, at 6:16 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi Kevin, On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote: [fixing address for Benoit] Pantelis Antoniou pa...@antoniou-consulting.com writes: omap_device relies on the platform notifier callbacks managing resources behind the scenes. The resources were not properly linked causing crashes when removing the device. Rework the resource modification code so that linking is performed properly, and make sure that no resources that have no parent (which can happen for DMA IRQ resources) are ever left for cleanup by the core resource layer. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com This one failed my took more than 15 minutes to understand test. The changelog is rather vague (especially about what properly means), and the combination of moving code and changing it makes the patch rather clunky to read, so I remain a bit confused about what the actual problem is. Please elaborate. Also, could you share a crash dump as well as details about how to reproduce this problem? Thanks, Kevin It's the full patchset that fixes the problem: Let me illustrate: The kernel I use is located at: g...@github.com:pantoniou/linux-beagle-track-mainline.git branch: merge-20130806 (there are topic branches for other stuff too) Sorry, I don't have the time to go through a bunch of out of tree branches to figure this out. Can you create a simpler test case to reproduce this? e.g. Does this happen when building the serial driver as a module and then removing it? If not, why not? What 'bunch of out of tree branches'? There is a single merge branch against current mainline. And no you don't trigger this by removing a module. platform_driver_unregister() != platform_device_register(). I'll try to figure out something simpler, but it's pretty damn obvious that something is not right there. Do you think fixing problems in that part of platform device removal was something I did because I didn't have other things to do? It is broken and I'm trying to get it fixed. Are you? Kevin -- Pantelis -- 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 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi,
On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..e509abc
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,175 @@
+#undef CONFIG_REGULATOR
why ??
1. This shows that driver is still not fully tested
Regulators support is still missing in the MSM
2. Helps me to load driver successfully.
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ dev_info(pdev-dev, MSM DWC3\n);
please don't. This is hardly necessary.
Sure, this will be removed.
+ mdwc = devm_kzalloc(pdev-dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc) {
+ dev_err(pdev-dev, not enough memory\n);
this message isn't needed either
ok.
+ /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and 60MHZ for HSUSB mode.
+*/
+ clk_set_rate(mdwc-core_clk, 12500);
if this is dwc3's core clock, why don't we teach dwc3.ko about this
requirement ? Just make sure to have it optional, since x86 and OMAP
wouldn't need direct fiddling with the clocks.
I have to check whether DWC3 core or Qcom wrapper requires this clock.
+ clk_prepare_enable(mdwc-core_clk);
+ clk_prepare_enable(mdwc-iface_clk);
+ clk_prepare_enable(mdwc-sleep_clk);
+ clk_prepare_enable(mdwc-utmi_clk);
do you really need to enable your clocks here ? Why don't you enable
them on runtime_resume and disable on runtime_suspend ?
I will like to make it working first and then will improve
power management.
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(pdev-dev, res);
+ if (!tcsr) {
+ dev_dbg(pdev-dev, tcsr ioremap failed\n);
no need to ioremap, also you're likely leaking clocks and regulators
enabled here.
Make sure to have something like:
if (!tcsr)
goto err_disable_clocks;
/* TODO This has to be revised */\
[...]
Sure.
+ } else {
+ /* TODO: This has to be revised */
+
+ /* Enable USB3 on the primary USB port. */
+ writel_relaxed(0x1, tcsr);
+ /*
+* Ensure that TCSR write is completed before
+* USB registers initialization.
+*/
+ mb();
why don't you use writel() instead. It will add the memory barrier for
you.
Ok.
Thanks
Ivan
--
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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
Nishanth Menon n...@ti.com writes: On 08/08/2013 06:04 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 04:14 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/08/2013 10:03 AM, Santosh Shilimkar wrote: $subject and patch don't match. On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote: On 08/08/2013 03:45 AM, Russ Dill wrote: In reference to the M3 handling it, the M3 wouldn't know which devices have a driver bound and which don't. Does it need to? M3 firmware can pretty much define I will force the device into low power state, and if the drivers dont handle things properly, fix the darned driver. M3 behavior should be considered as a hardware as far as Linux running on MPU is concerned, and firmware helps change the behavior by accounting for SoC quirks. *if* we have ability to handle this in the firmware, there is no need to carry this in Linux. I agree with Nishant. I don't like this patch and IIRC, I gave same comment in the last version. Linux need not know about all such firmware quirks. Also all these M3 specific stuff, should be done somewhere else. Probably having a small M3 driver won't be a bad idea. I am not opposed to doing it this way and letting the M3 firmware handle idling these modules, however the one concern raised in the last series is that an approach that does not acknowledge drivers will hide driver PM bugs. I suppose as long as I make sure to document that the devices are being idled by the M3 firmware this may not be an issue. I will look into implementing this. No, please don't start idling devices in firmware that are otherwise managed by Linux. Keep the firmware simple and dumb. Linux is managing these devices, it should manage their bugs too. This is not just about idling devices. This is about handling broken IP blocks whose power-on reset state does not allow the the powerdomain to reach its target state. That's just bad hardware design. Right, this is where M3 can help - provide a consistent state for linux kernel to work with. by the fact that we want to keep majority of the power code inside master CPU, we are just letting M3 help us with nothing major at all.. heh, I would say HW design bugs like this are more than nothing major at all. :) tiny stuff like these can help fix the hardware design quirks by hiding it behind the firmware and modifying the hardware behavior. I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. My view is that the M3 should *ignore* the presence/existence of MPU's drivers. M3 will do whatever to force the system to go to suspend once notified - this saves us the prehistoric perpetual trouble when drivers have bugs (which get exposed in weird usage scenarios) in production systems, we dont get any hardware help to fix them up while attempting low power states and system never really hits low power state. This was always because OMAP and it's derivatives have been democratic in power management - if every hardware block achieves proper state, then we achieve a system-wide low power state. I know it breaks the purity of role, but as the next evolution, we might want to consider M3 something like an accelerator for power management activity.. (not saying it is that fast.. but conceptually). Yes, it breaks the purity of role, and makes it hard to maintain and extend to future SoCs. As a maintainer, that's a red flag. IMO, the roles need to be kept clear. The M3 manages some devices and the interconnect that MPU/Linux cannot, the rest are managed by Linux. suspend is a very controlled state as against cpuidle where driver knowledge is necessary and in fact mandatory. drivers are supposed to release their resources - and even though we test the hell out of them, we do have paths untrodden when it comes to production systems. Since folks don't seem to care about idle for AM33xx (starting with the hw designers, from what I can tell), you have the luxury of thinking only about suspend, where firmware can be heavy handed and force things into submission. Unfortunately, with cpuidle, life is not that easy and you have to have cooperation of the device drivers. Coordinating that with firmware is not so simple, to put it mildly. Any SW/firmware design that does not account for *both* static PM (suspend/resume) and dynamic PM (runtime PM + CPUidle) is not long-term maintainable, and thus ready for mainline IMO. (BTW, this is another theme from previous reviews of this
Re: [PATCHv3 4/9] ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec
On 08/09/2013 10:11 AM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: On Thursday 08 August 2013 04:05 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: On Thursday 08 August 2013 02:16 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: From: Vaibhav Bedia vaibhav.be...@ti.com SDRAM controller on AM33XX requires that a modification of certain bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in AM335x-Rev H) is followed by a dummy read access to SDRAM. This scenario arises when entering a low power state like DeepSleep. To ensure that the read is not from a cached region we reserve some memory during bootup using the arm_memblock_steal() API. Hmm, sounds to me an awful lot like the existing omap_bus_sync() ? All the credit of that awful omap_bus_sync() goes to me since I introduced it. And I keep beating the hardware guys who have not left a choice but to introduce the ugly work around in software. ;-) Agreed, but what's even more awful than the current version is duplicating it in a slightly different way using yet another whole page mapping for a single read/write location. The real issue is limitation of the kernel memory steal(memblock) API which won't let you still less than 1 MB. It would have been ok for page allocation because that is any way what you will get minimum on standard non-cached allocations. All the more reason that the omap_bus_sync() should be refactored slightly in a way that would be reusable for AM33xx. Kevin I will look in to doing it this way. I do not know if there was any specific reason for doing it the way it was done. Dave -- 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 3/5] omap: Properly handle resources for omap_devices
Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi On Aug 9, 2013, at 6:16 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi Kevin, On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote: [fixing address for Benoit] Pantelis Antoniou pa...@antoniou-consulting.com writes: omap_device relies on the platform notifier callbacks managing resources behind the scenes. The resources were not properly linked causing crashes when removing the device. Rework the resource modification code so that linking is performed properly, and make sure that no resources that have no parent (which can happen for DMA IRQ resources) are ever left for cleanup by the core resource layer. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com This one failed my took more than 15 minutes to understand test. The changelog is rather vague (especially about what properly means), and the combination of moving code and changing it makes the patch rather clunky to read, so I remain a bit confused about what the actual problem is. Please elaborate. Also, could you share a crash dump as well as details about how to reproduce this problem? Thanks, Kevin It's the full patchset that fixes the problem: Let me illustrate: The kernel I use is located at: g...@github.com:pantoniou/linux-beagle-track-mainline.git branch: merge-20130806 (there are topic branches for other stuff too) Sorry, I don't have the time to go through a bunch of out of tree branches to figure this out. Can you create a simpler test case to reproduce this? e.g. Does this happen when building the serial driver as a module and then removing it? If not, why not? What 'bunch of out of tree branches'? There is a single merge branch against current mainline. And That branch contains multiple other branches (as you stated yourself above), many of which look to be out of tree: $ git log --oneline --merges panto/master..panto/merge-20130806 031297e Merge branch 'lcdc-fixes' into merge-20130806 44cf018 Merge branch 'usb-fixes' into merge-20130806 3cc739b Merge branch 'tscadc' into merge-20130806 f0ec35d Merge branch 'capemgr' into merge-20130806 4d87712 Merge branch 'general-fixes' into merge-20130806 04535fb Merge branch 'pinctrl-fixes' into merge-20130806 5115b55 Merge branch 'i2c-fixes' into merge-20130806 e96edf5 Merge branch 'capes' into merge-20130806 1eb1779 Merge branch 'dts-fixes' into merge-20130806 ca12149 Merge branch 'mmc-fixes' into merge-20130806 41ed7a0 Merge branch 'pdev-fixes' into merge-20130806 2ba9995 Merge branch 'of-fixes' into merge-20130806 38b5cb4 Merge branch 'dtc-overlays' into merge-20130806 167648d Merge branch 'dtc-fixes' into merge-20130806 2f7de02 Merge branch 'reset' into merge-20130806 $ git log --oneline --no-merges panto/master..panto/merge-20130806 |wc -l 85 And no you don't trigger this by removing a module. platform_driver_unregister() != platform_device_register(). I'll try to figure out something simpler, but it's pretty damn obvious that something is not right there. I agree something does not seem right, and never said otherwise. I'm simply looking for an easy way to reproduce it with mainline. Since it's so damn obvious, I'll accept the insult and agree to being a moron. Please educate me by making it even more obvious with a way to reproduce it against mainline. Do you think fixing problems in that part of platform device removal was something I did because I didn't have other things to do? Settle down, I said nothing of the sort. On the contrary, I assumed you were being a generous citizen of the community and contributing back your fixes, and as a developer of this part of the kernel, I'm trying to help. If I didn't care, I wouldn't have responded in the first place. It is broken and I'm trying to get it fixed. Are you? I was, but your accusatory tone is reducing my motivation to help. Kevin -- 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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
On 08/09/2013 11:12 AM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 06:04 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 04:14 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/08/2013 10:03 AM, Santosh Shilimkar wrote: $subject and patch don't match. On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote: On 08/08/2013 03:45 AM, Russ Dill wrote: In reference to the M3 handling it, the M3 wouldn't know which devices have a driver bound and which don't. Does it need to? M3 firmware can pretty much define I will force the device into low power state, and if the drivers dont handle things properly, fix the darned driver. M3 behavior should be considered as a hardware as far as Linux running on MPU is concerned, and firmware helps change the behavior by accounting for SoC quirks. *if* we have ability to handle this in the firmware, there is no need to carry this in Linux. I agree with Nishant. I don't like this patch and IIRC, I gave same comment in the last version. Linux need not know about all such firmware quirks. Also all these M3 specific stuff, should be done somewhere else. Probably having a small M3 driver won't be a bad idea. I am not opposed to doing it this way and letting the M3 firmware handle idling these modules, however the one concern raised in the last series is that an approach that does not acknowledge drivers will hide driver PM bugs. I suppose as long as I make sure to document that the devices are being idled by the M3 firmware this may not be an issue. I will look into implementing this. No, please don't start idling devices in firmware that are otherwise managed by Linux. Keep the firmware simple and dumb. Linux is managing these devices, it should manage their bugs too. This is not just about idling devices. This is about handling broken IP blocks whose power-on reset state does not allow the the powerdomain to reach its target state. That's just bad hardware design. Right, this is where M3 can help - provide a consistent state for linux kernel to work with. by the fact that we want to keep majority of the power code inside master CPU, we are just letting M3 help us with nothing major at all.. heh, I would say HW design bugs like this are more than nothing major at all. :) tiny stuff like these can help fix the hardware design quirks by hiding it behind the firmware and modifying the hardware behavior. I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. My view is that the M3 should *ignore* the presence/existence of MPU's drivers. M3 will do whatever to force the system to go to suspend once notified - this saves us the prehistoric perpetual trouble when drivers have bugs (which get exposed in weird usage scenarios) in production systems, we dont get any hardware help to fix them up while attempting low power states and system never really hits low power state. This was always because OMAP and it's derivatives have been democratic in power management - if every hardware block achieves proper state, then we achieve a system-wide low power state. I know it breaks the purity of role, but as the next evolution, we might want to consider M3 something like an accelerator for power management activity.. (not saying it is that fast.. but conceptually). Yes, it breaks the purity of role, and makes it hard to maintain and extend to future SoCs. As a maintainer, that's a red flag. IMO, the roles need to be kept clear. The M3 manages some devices and the interconnect that MPU/Linux cannot, the rest are managed by Linux. suspend is a very controlled state as against cpuidle where driver knowledge is necessary and in fact mandatory. drivers are supposed to release their resources - and even though we test the hell out of them, we do have paths untrodden when it comes to production systems. Since folks don't seem to care about idle for AM33xx (starting with the hw designers, from what I can tell), you have the luxury of thinking only about suspend, where firmware can be heavy handed and force things into submission. Unfortunately, with cpuidle, life is not that easy and you have to have cooperation of the device drivers. Coordinating that with firmware is not so simple, to put it mildly. Any SW/firmware design that does not account for *both* static PM (suspend/resume) and dynamic PM (runtime PM + CPUidle) is not long-term maintainable, and thus ready for mainline IMO. (BTW, this is another theme from previous reviews of this
Re: [PATCH 3/5] omap: Properly handle resources for omap_devices
Hi Kevin, On Aug 9, 2013, at 7:35 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi On Aug 9, 2013, at 6:16 PM, Kevin Hilman wrote: Pantelis Antoniou pa...@antoniou-consulting.com writes: Hi Kevin, On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote: [fixing address for Benoit] Pantelis Antoniou pa...@antoniou-consulting.com writes: omap_device relies on the platform notifier callbacks managing resources behind the scenes. The resources were not properly linked causing crashes when removing the device. Rework the resource modification code so that linking is performed properly, and make sure that no resources that have no parent (which can happen for DMA IRQ resources) are ever left for cleanup by the core resource layer. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com This one failed my took more than 15 minutes to understand test. The changelog is rather vague (especially about what properly means), and the combination of moving code and changing it makes the patch rather clunky to read, so I remain a bit confused about what the actual problem is. Please elaborate. Also, could you share a crash dump as well as details about how to reproduce this problem? Thanks, Kevin It's the full patchset that fixes the problem: Let me illustrate: The kernel I use is located at: g...@github.com:pantoniou/linux-beagle-track-mainline.git branch: merge-20130806 (there are topic branches for other stuff too) Sorry, I don't have the time to go through a bunch of out of tree branches to figure this out. Can you create a simpler test case to reproduce this? e.g. Does this happen when building the serial driver as a module and then removing it? If not, why not? What 'bunch of out of tree branches'? There is a single merge branch against current mainline. And That branch contains multiple other branches (as you stated yourself above), many of which look to be out of tree: $ git log --oneline --merges panto/master..panto/merge-20130806 031297e Merge branch 'lcdc-fixes' into merge-20130806 44cf018 Merge branch 'usb-fixes' into merge-20130806 3cc739b Merge branch 'tscadc' into merge-20130806 f0ec35d Merge branch 'capemgr' into merge-20130806 4d87712 Merge branch 'general-fixes' into merge-20130806 04535fb Merge branch 'pinctrl-fixes' into merge-20130806 5115b55 Merge branch 'i2c-fixes' into merge-20130806 e96edf5 Merge branch 'capes' into merge-20130806 1eb1779 Merge branch 'dts-fixes' into merge-20130806 ca12149 Merge branch 'mmc-fixes' into merge-20130806 41ed7a0 Merge branch 'pdev-fixes' into merge-20130806 2ba9995 Merge branch 'of-fixes' into merge-20130806 38b5cb4 Merge branch 'dtc-overlays' into merge-20130806 167648d Merge branch 'dtc-fixes' into merge-20130806 2f7de02 Merge branch 'reset' into merge-20130806 $ git log --oneline --no-merges panto/master..panto/merge-20130806 |wc -l 85 Yes, but they have nothing to do with the problem at hand; the only branch that matters i pdev-fixes. And no you don't trigger this by removing a module. platform_driver_unregister() != platform_device_register(). I'll try to figure out something simpler, but it's pretty damn obvious that something is not right there. I agree something does not seem right, and never said otherwise. I'm simply looking for an easy way to reproduce it with mainline. Since it's so damn obvious, I'll accept the insult and agree to being a moron. Please educate me by making it even more obvious with a way to reproduce it against mainline. You can't reproduce it via rmmod'ing a module; it's not the same code path. That you need to do is to call platform_device_unregister() for the affected device on a DT enabled board. The only platform that triggers it currently is the beaglebone with DT overlays support. To get it to trigger on something simpler, I'll have to write a pretty elaborate module where I register the device and then immediately unregister it. Do you think fixing problems in that part of platform device removal was something I did because I didn't have other things to do? Settle down, I said nothing of the sort. On the contrary, I assumed you were being a generous citizen of the community and contributing back your fixes, and as a developer of this part of the kernel, I'm trying to help. If I didn't care, I wouldn't have responded in the first place. OK It is broken and I'm trying to get it fixed. Are you? I was, but your accusatory tone is reducing my motivation to help. I guess that's a fair accusation; sorry for coming out a bit strong here. Anyway, I'll see what it takes to come up with a test module that exhibits the issue easier. Kevin Regards -- Pantelis -- 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
Re: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
Nishanth Menon n...@ti.com writes: On 08/09/2013 11:12 AM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 06:04 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 04:14 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/08/2013 10:03 AM, Santosh Shilimkar wrote: $subject and patch don't match. On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote: On 08/08/2013 03:45 AM, Russ Dill wrote: In reference to the M3 handling it, the M3 wouldn't know which devices have a driver bound and which don't. Does it need to? M3 firmware can pretty much define I will force the device into low power state, and if the drivers dont handle things properly, fix the darned driver. M3 behavior should be considered as a hardware as far as Linux running on MPU is concerned, and firmware helps change the behavior by accounting for SoC quirks. *if* we have ability to handle this in the firmware, there is no need to carry this in Linux. I agree with Nishant. I don't like this patch and IIRC, I gave same comment in the last version. Linux need not know about all such firmware quirks. Also all these M3 specific stuff, should be done somewhere else. Probably having a small M3 driver won't be a bad idea. I am not opposed to doing it this way and letting the M3 firmware handle idling these modules, however the one concern raised in the last series is that an approach that does not acknowledge drivers will hide driver PM bugs. I suppose as long as I make sure to document that the devices are being idled by the M3 firmware this may not be an issue. I will look into implementing this. No, please don't start idling devices in firmware that are otherwise managed by Linux. Keep the firmware simple and dumb. Linux is managing these devices, it should manage their bugs too. This is not just about idling devices. This is about handling broken IP blocks whose power-on reset state does not allow the the powerdomain to reach its target state. That's just bad hardware design. Right, this is where M3 can help - provide a consistent state for linux kernel to work with. by the fact that we want to keep majority of the power code inside master CPU, we are just letting M3 help us with nothing major at all.. heh, I would say HW design bugs like this are more than nothing major at all. :) tiny stuff like these can help fix the hardware design quirks by hiding it behind the firmware and modifying the hardware behavior. I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. My view is that the M3 should *ignore* the presence/existence of MPU's drivers. M3 will do whatever to force the system to go to suspend once notified - this saves us the prehistoric perpetual trouble when drivers have bugs (which get exposed in weird usage scenarios) in production systems, we dont get any hardware help to fix them up while attempting low power states and system never really hits low power state. This was always because OMAP and it's derivatives have been democratic in power management - if every hardware block achieves proper state, then we achieve a system-wide low power state. I know it breaks the purity of role, but as the next evolution, we might want to consider M3 something like an accelerator for power management activity.. (not saying it is that fast.. but conceptually). Yes, it breaks the purity of role, and makes it hard to maintain and extend to future SoCs. As a maintainer, that's a red flag. IMO, the roles need to be kept clear. The M3 manages some devices and the interconnect that MPU/Linux cannot, the rest are managed by Linux. suspend is a very controlled state as against cpuidle where driver knowledge is necessary and in fact mandatory. drivers are supposed to release their resources - and even though we test the hell out of them, we do have paths untrodden when it comes to production systems. Since folks don't seem to care about idle for AM33xx (starting with the hw designers, from what I can tell), you have the luxury of thinking only about suspend, where firmware can be heavy handed and force things into submission. Unfortunately, with cpuidle, life is not that easy and you have to have cooperation of the device drivers. Coordinating that with firmware is not so simple, to put it mildly. Any SW/firmware design that does not account for *both* static PM (suspend/resume) and dynamic PM (runtime PM + CPUidle) is not long-term maintainable, and
Re: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? Regards, Dave -- 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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
On 08/09/2013 03:34 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/09/2013 11:12 AM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 06:04 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 04:14 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/08/2013 10:03 AM, Santosh Shilimkar wrote: $subject and patch don't match. On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote: On 08/08/2013 03:45 AM, Russ Dill wrote: In reference to the M3 handling it, the M3 wouldn't know which devices have a driver bound and which don't. Does it need to? M3 firmware can pretty much define I will force the device into low power state, and if the drivers dont handle things properly, fix the darned driver. M3 behavior should be considered as a hardware as far as Linux running on MPU is concerned, and firmware helps change the behavior by accounting for SoC quirks. *if* we have ability to handle this in the firmware, there is no need to carry this in Linux. I agree with Nishant. I don't like this patch and IIRC, I gave same comment in the last version. Linux need not know about all such firmware quirks. Also all these M3 specific stuff, should be done somewhere else. Probably having a small M3 driver won't be a bad idea. I am not opposed to doing it this way and letting the M3 firmware handle idling these modules, however the one concern raised in the last series is that an approach that does not acknowledge drivers will hide driver PM bugs. I suppose as long as I make sure to document that the devices are being idled by the M3 firmware this may not be an issue. I will look into implementing this. No, please don't start idling devices in firmware that are otherwise managed by Linux. Keep the firmware simple and dumb. Linux is managing these devices, it should manage their bugs too. This is not just about idling devices. This is about handling broken IP blocks whose power-on reset state does not allow the the powerdomain to reach its target state. That's just bad hardware design. Right, this is where M3 can help - provide a consistent state for linux kernel to work with. by the fact that we want to keep majority of the power code inside master CPU, we are just letting M3 help us with nothing major at all.. heh, I would say HW design bugs like this are more than nothing major at all. :) tiny stuff like these can help fix the hardware design quirks by hiding it behind the firmware and modifying the hardware behavior. I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. My view is that the M3 should *ignore* the presence/existence of MPU's drivers. M3 will do whatever to force the system to go to suspend once notified - this saves us the prehistoric perpetual trouble when drivers have bugs (which get exposed in weird usage scenarios) in production systems, we dont get any hardware help to fix them up while attempting low power states and system never really hits low power state. This was always because OMAP and it's derivatives have been democratic in power management - if every hardware block achieves proper state, then we achieve a system-wide low power state. I know it breaks the purity of role, but as the next evolution, we might want to consider M3 something like an accelerator for power management activity.. (not saying it is that fast.. but conceptually). Yes, it breaks the purity of role, and makes it hard to maintain and extend to future SoCs. As a maintainer, that's a red flag. IMO, the roles need to be kept clear. The M3 manages some devices and the interconnect that MPU/Linux cannot, the rest are managed by Linux. suspend is a very controlled state as against cpuidle where driver knowledge is necessary and in fact mandatory. drivers are supposed to release their resources - and even though we test the hell out of them, we do have paths untrodden when it comes to production systems. Since folks don't seem to care about idle for AM33xx (starting with the hw designers, from what I can tell), you have the luxury of thinking only about suspend, where firmware can be heavy handed and force things into submission. Unfortunately, with cpuidle, life is not that easy and you have to have cooperation of the device drivers. Coordinating that with firmware is not so simple, to put it mildly. Any SW/firmware design that does not account for *both* static PM (suspend/resume) and dynamic PM (runtime PM + CPUidle) is not long-term maintainable, and thus ready
Re: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Fri, Aug 9, 2013 at 1:34 PM, Kevin Hilman khil...@linaro.org wrote: Nishanth Menon n...@ti.com writes: On 08/09/2013 11:12 AM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 06:04 PM, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: On 08/08/2013 04:14 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/08/2013 10:03 AM, Santosh Shilimkar wrote: $subject and patch don't match. On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote: On 08/08/2013 03:45 AM, Russ Dill wrote: In reference to the M3 handling it, the M3 wouldn't know which devices have a driver bound and which don't. Does it need to? M3 firmware can pretty much define I will force the device into low power state, and if the drivers dont handle things properly, fix the darned driver. M3 behavior should be considered as a hardware as far as Linux running on MPU is concerned, and firmware helps change the behavior by accounting for SoC quirks. *if* we have ability to handle this in the firmware, there is no need to carry this in Linux. I agree with Nishant. I don't like this patch and IIRC, I gave same comment in the last version. Linux need not know about all such firmware quirks. Also all these M3 specific stuff, should be done somewhere else. Probably having a small M3 driver won't be a bad idea. I am not opposed to doing it this way and letting the M3 firmware handle idling these modules, however the one concern raised in the last series is that an approach that does not acknowledge drivers will hide driver PM bugs. I suppose as long as I make sure to document that the devices are being idled by the M3 firmware this may not be an issue. I will look into implementing this. No, please don't start idling devices in firmware that are otherwise managed by Linux. Keep the firmware simple and dumb. Linux is managing these devices, it should manage their bugs too. This is not just about idling devices. This is about handling broken IP blocks whose power-on reset state does not allow the the powerdomain to reach its target state. That's just bad hardware design. Right, this is where M3 can help - provide a consistent state for linux kernel to work with. by the fact that we want to keep majority of the power code inside master CPU, we are just letting M3 help us with nothing major at all.. heh, I would say HW design bugs like this are more than nothing major at all. :) tiny stuff like these can help fix the hardware design quirks by hiding it behind the firmware and modifying the hardware behavior. I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. My view is that the M3 should *ignore* the presence/existence of MPU's drivers. M3 will do whatever to force the system to go to suspend once notified - this saves us the prehistoric perpetual trouble when drivers have bugs (which get exposed in weird usage scenarios) in production systems, we dont get any hardware help to fix them up while attempting low power states and system never really hits low power state. This was always because OMAP and it's derivatives have been democratic in power management - if every hardware block achieves proper state, then we achieve a system-wide low power state. I know it breaks the purity of role, but as the next evolution, we might want to consider M3 something like an accelerator for power management activity.. (not saying it is that fast.. but conceptually). Yes, it breaks the purity of role, and makes it hard to maintain and extend to future SoCs. As a maintainer, that's a red flag. IMO, the roles need to be kept clear. The M3 manages some devices and the interconnect that MPU/Linux cannot, the rest are managed by Linux. suspend is a very controlled state as against cpuidle where driver knowledge is necessary and in fact mandatory. drivers are supposed to release their resources - and even though we test the hell out of them, we do have paths untrodden when it comes to production systems. Since folks don't seem to care about idle for AM33xx (starting with the hw designers, from what I can tell), you have the luxury of thinking only about suspend, where firmware can be heavy handed and force things into submission. Unfortunately, with cpuidle, life is not that easy and you have to have cooperation of the device drivers. Coordinating that with firmware is not so simple, to put it mildly. Any SW/firmware design that does not account for *both* static PM (suspend/resume)
