Re: [PATCH] OMAPDSS: hdmi5: remove unneeded check
On 13/01/15 18:46, Sudip Mukherjee wrote: prior to this check we are checking for word_length_16b and if word_length_16b is false then we are returning with -EINVAL. So at this point word_length_16b can only be true. True, but it looks to me the code may be extended in the future. And if it would be clear that it won't be extended in the future, then there's more code changes needed to reflect that (the whole word_length_16b can be removed, etc). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] omapfb: Return error code when applying overlay settings fails
On 30/01/15 09:59, Peter Meerwald wrote:
the check of the return code is missing, user space does not get notified
about the error condition:
omapdss OVERLAY error: overlay 2 horizontally not inside the display area
(403 + 800 = 800)
omapdss APPLY error: failed to apply settings: illegal configuration.
Signed-off-by: Peter Meerwald pme...@pmeerw.net
---
drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
index 146b6f5..9ddfdd6 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
@@ -137,8 +137,11 @@ static int omapfb_setup_plane(struct fb_info *fbi,
struct omapfb_plane_info *pi)
goto undo;
}
- if (ovl-manager)
- ovl-manager-apply(ovl-manager);
+ if (ovl-manager) {
+ r = ovl-manager-apply(ovl-manager);
+ if (r)
+ goto undo;
+ }
if (pi-enabled) {
r = ovl-enable(ovl);
Thanks, queued for 3.20.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 13/02/15 17:42, Tero Kristo wrote: On 02/13/2015 05:25 PM, Nishanth Menon wrote: I would probably wait for control module to become syscon and probably model this as syscon clk - I thin we should be seeing a series sometime soon. Yeah, I will be posting a series in a bit, just running some final tests on it. I did the above with Tero's series. Adding the DES HDCP clock works ok. However, I'm not able to do this in HWMOD framework. To enable the DSS IP block I need to enable both the DSS func clock and the DES HDCP clock, but the HWMOD framework only allows one mainclock. I added the HDCP clock as an opt clock, but those are not enabled intially by the HWMOD framework, and the call in omap_hwmod.c:_enable() to soc_ops.wait_target_ready(oh) calls fails. So... Any ideas how to proceed? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 20/02/15 14:59, Tero Kristo wrote: On 02/20/2015 01:46 PM, Tomi Valkeinen wrote: On 13/02/15 17:42, Tero Kristo wrote: On 02/13/2015 05:25 PM, Nishanth Menon wrote: I would probably wait for control module to become syscon and probably model this as syscon clk - I thin we should be seeing a series sometime soon. Yeah, I will be posting a series in a bit, just running some final tests on it. I did the above with Tero's series. Adding the DES HDCP clock works ok. However, I'm not able to do this in HWMOD framework. To enable the DSS IP block I need to enable both the DSS func clock and the DES HDCP clock, but the HWMOD framework only allows one mainclock. I added the HDCP clock as an opt clock, but those are not enabled intially by the HWMOD framework, and the call in omap_hwmod.c:_enable() to soc_ops.wait_target_ready(oh) calls fails. So... Any ideas how to proceed? Add the clock enable at the end of dra7xx_dt_clk_init()? You need to disable the clock at some point though. Where would I disable it? And if the clock is disabled, doesn't this again fail when the dss driver tries to enable the IP block? The driver can enable the HDCP opt clock only later, when the IP block should be up already. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 00/14] OMAPDSS: Add TI DRA7xx support
Hi, This series adds DSS support for Texas Instrument's DRA7xx SoCs. The DSS on DRA7xx is very much like OMAP5's DSS. The main differences are in the integration of the DSS. There are three main differences to OMAP5: * DRA7xx has one (DRA72x) or two (DRA74x) video PLLs, which are almost like OMAP5's DSI PLLs, except integrated slightly differently. * DRA7xx supports 3 DPI outputs, instead of 1 DPI output. * need to set various bits in CONTROL module, which is handled via syscon This series only adds the support to DSS driver. arch/arm/ changes are not yet finalized. The main issue there is the missing support for DSS_DESHDCP clock, which probably needs to be handled via regmap. My plan is to merge the driver side changes first for 3.20, and the arch/arm/ changes for 3.21 (if solutions to the issues have been found). This will also make the merging easier, as there won't be a merge-window cross dependency between arm and fbdev trees. These patches, and the additional arch/arm/ patches needed to get DSS working on DRA7xx, can be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dra7-dss Tomi Tomi Valkeinen (14): OMAPDSS: Add enum dss_pll_id OMAPDSS: PLL: add dss_pll_wait_reset_done() OMAPDSS: constify port arrays OMAPDSS: OMAP5: fix digit output's allowed mgrs OMAPDSS: encoder-tpd12s015: Fix race issue with LS_OE OMAPDSS: add define for DRA7xx HW version Doc/DT: Add DT binding doc for DRA7xx DSS OMAPDSS: DSS: Add DRA7xx base support OMAPDSS: Add functions for external control of PLL OMAPDSS: Add Video PLLs for DRA7xx OMAPDSS: DISPC: Add DRA7xx support OMAPDSS: DISPC: program dispc polarities to control module OMAPDSS: HDMI: Add DRA7xx support OMAPDSS: DPI: DRA7xx support .../devicetree/bindings/video/ti,dra7-dss.txt | 69 +++ .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 57 +- drivers/video/fbdev/omap2/dss/Makefile | 2 +- drivers/video/fbdev/omap2/dss/dispc.c | 54 + drivers/video/fbdev/omap2/dss/dpi.c| 26 +++ drivers/video/fbdev/omap2/dss/dsi.c| 1 + drivers/video/fbdev/omap2/dss/dss.c| 219 - drivers/video/fbdev/omap2/dss/dss.h| 22 +++ drivers/video/fbdev/omap2/dss/dss_features.c | 3 +- drivers/video/fbdev/omap2/dss/hdmi5.c | 1 + drivers/video/fbdev/omap2/dss/hdmi_phy.c | 1 + drivers/video/fbdev/omap2/dss/hdmi_pll.c | 6 + drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 1 + drivers/video/fbdev/omap2/dss/pll.c| 10 + drivers/video/fbdev/omap2/dss/video-pll.c | 211 include/video/omapdss.h| 1 + 16 files changed, 627 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/ti,dra7-dss.txt create mode 100644 drivers/video/fbdev/omap2/dss/video-pll.c -- 2.2.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
[PATCH 01/14] OMAPDSS: Add enum dss_pll_id
In some cases we need global identifiers for the DSS PLLs, for example
when configuring clock muxing on DRA7. For this purpose let's add a
'enum dss_pll_id'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dsi.c | 1 +
drivers/video/fbdev/omap2/dss/dss.h | 7 +++
drivers/video/fbdev/omap2/dss/hdmi_pll.c | 1 +
3 files changed, 9 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dsi.c
b/drivers/video/fbdev/omap2/dss/dsi.c
index 3e44c580b1f8..5081f6fb1737 100644
--- a/drivers/video/fbdev/omap2/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/dss/dsi.c
@@ -5238,6 +5238,7 @@ static int dsi_init_pll_data(struct platform_device
*dsidev)
}
pll-name = dsi-module_id == 0 ? dsi0 : dsi1;
+ pll-id = dsi-module_id == 0 ? DSS_PLL_DSI1 : DSS_PLL_DSI2;
pll-clkin = clk;
pll-base = dsi-pll_base;
diff --git a/drivers/video/fbdev/omap2/dss/dss.h
b/drivers/video/fbdev/omap2/dss/dss.h
index 14fb0c23f4a2..1826ee96265b 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -100,6 +100,12 @@ enum dss_writeback_channel {
DSS_WB_LCD3_MGR = 7,
};
+enum dss_pll_id {
+ DSS_PLL_DSI1,
+ DSS_PLL_DSI2,
+ DSS_PLL_HDMI,
+};
+
struct dss_pll;
#define DSS_PLL_MAX_HSDIVS 4
@@ -150,6 +156,7 @@ struct dss_pll_hw {
struct dss_pll {
const char *name;
+ enum dss_pll_id id;
struct clk *clkin;
struct regulator *regulator;
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
index ac83ef5cfd7d..b808f7c72d83 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
@@ -185,6 +185,7 @@ static int dsi_init_pll_data(struct platform_device *pdev,
struct hdmi_pll_data
}
pll-name = hdmi;
+ pll-id = DSS_PLL_HDMI;
pll-base = hpll-base;
pll-clkin = clk;
--
2.2.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
[PATCH 09/14] OMAPDSS: Add functions for external control of PLL
Add functions which configure the control module register
CTRL_CORE_DSS_PLL_CONTROL found in DRA7xx SoCs. This register configures
whether the PLL registers are accessed internally by DSS, or externally
using OCP2SCP interface. They also configure muxes which route the PLL
output to a particular LCD overlay manager within DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss.c | 115
drivers/video/fbdev/omap2/dss/dss.h | 4 ++
2 files changed, 119 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index 8c79839fbe87..d75238f2c537 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -34,6 +34,8 @@
#include linux/pm_runtime.h
#include linux/gfp.h
#include linux/sizes.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include linux/of.h
#include video/omapdss.h
@@ -78,6 +80,8 @@ struct dss_features {
static struct {
struct platform_device *pdev;
void __iomem*base;
+ struct regmap *syscon_pll_ctrl;
+ u32 syscon_pll_ctrl_offset;
struct clk *parent_clk;
struct clk *dss_clk;
@@ -158,6 +162,99 @@ static void dss_restore_context(void)
#undef SR
#undef RR
+void dss_ctrl_pll_enable(enum dss_pll_id pll_id, bool enable)
+{
+ unsigned shift;
+ unsigned val;
+
+ if (!dss.syscon_pll_ctrl)
+ return;
+
+ val = !enable;
+
+ switch (pll_id) {
+ case DSS_PLL_VIDEO1:
+ shift = 0;
+ break;
+ case DSS_PLL_VIDEO2:
+ shift = 1;
+ break;
+ case DSS_PLL_HDMI:
+ shift = 2;
+ break;
+ default:
+ DSSERR(illegal DSS PLL ID %d\n, pll_id);
+ return;
+ }
+
+ regmap_update_bits(dss.syscon_pll_ctrl, dss.syscon_pll_ctrl_offset,
+ 1 shift, val shift);
+}
+
+void dss_ctrl_pll_set_control_mux(enum dss_pll_id pll_id,
+ enum omap_channel channel)
+{
+ unsigned shift, val;
+
+ if (!dss.syscon_pll_ctrl)
+ return;
+
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ shift = 3;
+
+ switch (pll_id) {
+ case DSS_PLL_VIDEO1:
+ val = 0; break;
+ case DSS_PLL_HDMI:
+ val = 1; break;
+ default:
+ DSSERR(error in PLL mux config for LCD\n);
+ return;
+ }
+
+ break;
+ case OMAP_DSS_CHANNEL_LCD2:
+ shift = 5;
+
+ switch (pll_id) {
+ case DSS_PLL_VIDEO1:
+ val = 0; break;
+ case DSS_PLL_VIDEO2:
+ val = 1; break;
+ case DSS_PLL_HDMI:
+ val = 2; break;
+ default:
+ DSSERR(error in PLL mux config for LCD2\n);
+ return;
+ }
+
+ break;
+ case OMAP_DSS_CHANNEL_LCD3:
+ shift = 7;
+
+ switch (pll_id) {
+ case DSS_PLL_VIDEO1:
+ val = 1; break;
+ case DSS_PLL_VIDEO2:
+ val = 0; break;
+ case DSS_PLL_HDMI:
+ val = 2; break;
+ default:
+ DSSERR(error in PLL mux config for LCD3\n);
+ return;
+ }
+
+ break;
+ default:
+ DSSERR(error in PLL mux config\n);
+ return;
+ }
+
+ regmap_update_bits(dss.syscon_pll_ctrl, dss.syscon_pll_ctrl_offset,
+ 0x3 shift, val shift);
+}
+
void dss_sdi_init(int datapairs)
{
u32 l;
@@ -923,6 +1020,7 @@ static void __exit dss_uninit_ports(struct platform_device
*pdev)
static int __init omap_dsshw_probe(struct platform_device *pdev)
{
struct resource *dss_mem;
+ struct device_node *np = pdev-dev.of_node;
u32 rev;
int r;
@@ -979,6 +1077,23 @@ static int __init omap_dsshw_probe(struct platform_device
*pdev)
dss_init_ports(pdev);
+ if (np of_property_read_bool(np, syscon-pll-ctrl)) {
+ dss.syscon_pll_ctrl = syscon_regmap_lookup_by_phandle(np,
+ syscon-pll-ctrl);
+ if (IS_ERR(dss.syscon_pll_ctrl)) {
+ dev_err(pdev-dev,
+ failed to get syscon-pll-ctrl regmap\n);
+ return PTR_ERR(dss.syscon_pll_ctrl);
+ }
+
+ if (of_property_read_u32_index(np, syscon-pll-ctrl, 1,
+ dss.syscon_pll_ctrl_offset)) {
+ dev_err(pdev-dev,
+ failed to get syscon-pll-ctrl offset\n
[PATCH 02/14] OMAPDSS: PLL: add dss_pll_wait_reset_done()
Add a helper function to wait until the PLL's reset is done.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss.h | 1 +
drivers/video/fbdev/omap2/dss/pll.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dss.h
b/drivers/video/fbdev/omap2/dss/dss.h
index 1826ee96265b..d6c9c3d3db14 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -453,5 +453,6 @@ int dss_pll_write_config_type_a(struct dss_pll *pll,
const struct dss_pll_clock_info *cinfo);
int dss_pll_write_config_type_b(struct dss_pll *pll,
const struct dss_pll_clock_info *cinfo);
+int dss_pll_wait_reset_done(struct dss_pll *pll);
#endif
diff --git a/drivers/video/fbdev/omap2/dss/pll.c
b/drivers/video/fbdev/omap2/dss/pll.c
index 335ffac224b9..f974ddcd3b6e 100644
--- a/drivers/video/fbdev/omap2/dss/pll.c
+++ b/drivers/video/fbdev/omap2/dss/pll.c
@@ -222,6 +222,16 @@ static int wait_for_bit_change(void __iomem *reg, int
bitnum, int value)
return !value;
}
+int dss_pll_wait_reset_done(struct dss_pll *pll)
+{
+ void __iomem *base = pll-base;
+
+ if (wait_for_bit_change(base + PLL_STATUS, 0, 1) != 1)
+ return -ETIMEDOUT;
+ else
+ return 0;
+}
+
static int dss_wait_hsdiv_ack(struct dss_pll *pll, u32 hsdiv_ack_mask)
{
int t = 100;
--
2.2.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
[PATCH 08/14] OMAPDSS: DSS: Add DRA7xx base support
Add base support for DRA7xx to DSS core.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss.c | 40 +++
drivers/video/fbdev/omap2/dss/dss.h | 2 ++
drivers/video/fbdev/omap2/dss/dss_features.c | 1 +
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 1 +
4 files changed, 44 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index 1884c29ef482..8c79839fbe87 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -605,6 +605,26 @@ static int dss_dpi_select_source_omap5(int port, enum
omap_channel channel)
return 0;
}
+static int dss_dpi_select_source_dra7xx(int port, enum omap_channel channel)
+{
+ switch (port) {
+ case 0:
+ return dss_dpi_select_source_omap5(port, channel);
+ case 1:
+ if (channel != OMAP_DSS_CHANNEL_LCD2)
+ return -EINVAL;
+ break;
+ case 2:
+ if (channel != OMAP_DSS_CHANNEL_LCD3)
+ return -EINVAL;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int dss_dpi_select_source(int port, enum omap_channel channel)
{
return dss.feat-dpi_select_source(port, channel);
@@ -686,6 +706,12 @@ static const enum omap_display_type omap34xx_ports[] = {
OMAP_DISPLAY_TYPE_SDI,
};
+static const enum omap_display_type dra7xx_ports[] = {
+ OMAP_DISPLAY_TYPE_DPI,
+ OMAP_DISPLAY_TYPE_DPI,
+ OMAP_DISPLAY_TYPE_DPI,
+};
+
static const struct dss_features omap24xx_dss_feats __initconst = {
/*
* fck div max is really 16, but the divider range has gaps. The range
@@ -744,6 +770,15 @@ static const struct dss_features am43xx_dss_feats
__initconst = {
.num_ports = ARRAY_SIZE(omap2plus_ports),
};
+static const struct dss_features dra7xx_dss_feats __initconst = {
+ .fck_div_max= 64,
+ .dss_fck_multiplier = 1,
+ .parent_clk_name= dpll_per_x2_ck,
+ .dpi_select_source = dss_dpi_select_source_dra7xx,
+ .ports = dra7xx_ports,
+ .num_ports = ARRAY_SIZE(dra7xx_ports),
+};
+
static int __init dss_init_features(struct platform_device *pdev)
{
const struct dss_features *src;
@@ -784,6 +819,10 @@ static int __init dss_init_features(struct platform_device
*pdev)
src = am43xx_dss_feats;
break;
+ case OMAPDSS_VER_DRA7xx:
+ src = dra7xx_dss_feats;
+ break;
+
default:
return -ENODEV;
}
@@ -1003,6 +1042,7 @@ static const struct of_device_id dss_of_match[] = {
{ .compatible = ti,omap3-dss, },
{ .compatible = ti,omap4-dss, },
{ .compatible = ti,omap5-dss, },
+ { .compatible = ti,dra7-dss, },
{},
};
diff --git a/drivers/video/fbdev/omap2/dss/dss.h
b/drivers/video/fbdev/omap2/dss/dss.h
index d6c9c3d3db14..4bca36a591ca 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -104,6 +104,8 @@ enum dss_pll_id {
DSS_PLL_DSI1,
DSS_PLL_DSI2,
DSS_PLL_HDMI,
+ DSS_PLL_VIDEO1,
+ DSS_PLL_VIDEO2,
};
struct dss_pll;
diff --git a/drivers/video/fbdev/omap2/dss/dss_features.c
b/drivers/video/fbdev/omap2/dss/dss_features.c
index 0e6f3f54749f..376270b777f8 100644
--- a/drivers/video/fbdev/omap2/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/dss/dss_features.c
@@ -943,6 +943,7 @@ void dss_features_init(enum omapdss_version version)
break;
case OMAPDSS_VER_OMAP5:
+ case OMAPDSS_VER_DRA7xx:
omap_current_dss_features = omap5_dss_features;
break;
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
index 2f0822ee3ff9..42b87f95267c 100644
--- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -186,6 +186,7 @@ static const struct of_device_id omapdss_of_match[]
__initconst = {
{ .compatible = ti,omap3-dss, },
{ .compatible = ti,omap4-dss, },
{ .compatible = ti,omap5-dss, },
+ { .compatible = ti,dra7-dss, },
{},
};
--
2.2.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
[PATCH 07/14] Doc/DT: Add DT binding doc for DRA7xx DSS
Add device tree binding documentation for DRA7xx display subsystem. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/video/ti,dra7-dss.txt | 69 ++ 1 file changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/ti,dra7-dss.txt diff --git a/Documentation/devicetree/bindings/video/ti,dra7-dss.txt b/Documentation/devicetree/bindings/video/ti,dra7-dss.txt new file mode 100644 index ..f33a05137b0e --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,dra7-dss.txt @@ -0,0 +1,69 @@ +Texas Instruments DRA7x Display Subsystem += + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core + + +Required properties: +- compatible: ti,dra7-dss +- reg: address and length of the register spaces for 'dss' +- ti,hwmods: dss_core +- clocks: handle to fclk +- clock-names: fck +- syscon: phandle to control module core syscon node + +Optional properties: + +Some DRA7xx SoCs have one dedicated video PLL, some have two. These properties +can be used to describe the video PLLs: + +- reg: address and length of the register spaces for 'pll1_clkctrl', + 'pll1', 'pll2_clkctrl', 'pll2' +- clocks: handle to video1 pll clock and video2 pll clock +- clock-names: video1_clk and video2_clk + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +- + +Required properties: +- compatible: ti,dra7-dispc +- reg: address and length of the register space +- ti,hwmods: dss_dispc +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: fck + +HDMI + + +Required properties: +- compatible: ti,dra7-hdmi +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: wp, pll, phy, core +- interrupts: the HDMI interrupt line +- ti,hwmods: dss_hdmi +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: fck, sys_clk + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) -- 2.2.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
Re: [PATCH 01/23] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
On 26/01/15 17:49, Tony Lindgren wrote: I'm not sure if I miss something, but regmap_write does not protect from problems if there are multiple users for the same registers. You need to use regmap_update_bits() to get a protected read/write sequence, in which you can change only the bits that you want to change. To me it seems that issue can be fixed by making all the code use regmap. AFAIK that should work for the legacy code too. Even if everybody uses regmap, doing v = regmap_read() modify v regmap_write(v) is racy. regmap_update_bits() has to be used to protect the read/write sequence. Which may be somewhat challenging at times with some strange registers, the like Roger Q encountered recently related to CAN. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 10/14] OMAPDSS: Add Video PLLs for DRA7xx
DRA7xx SoCs have one (DRA72x) or two (DRA74x) video PLLs. They are
basically the same as DSI PLLs on OMAPs, but without the rest of the DSI
hardware. The video PLLs also require some configuration via the CONTROL
module.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/Makefile| 2 +-
drivers/video/fbdev/omap2/dss/dss.c | 58 +++-
drivers/video/fbdev/omap2/dss/dss.h | 8 ++
drivers/video/fbdev/omap2/dss/video-pll.c | 211 ++
4 files changed, 273 insertions(+), 6 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/video-pll.c
diff --git a/drivers/video/fbdev/omap2/dss/Makefile
b/drivers/video/fbdev/omap2/dss/Makefile
index 2ea9d382354c..b5136d3d4b77 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
- output.o dss-of.o pll.o
+ output.o dss-of.o pll.o video-pll.o
# DSS compat layer files
omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d75238f2c537..a6d10d4279f3 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -37,6 +37,7 @@
#include linux/mfd/syscon.h
#include linux/regmap.h
#include linux/of.h
+#include linux/regulator/consumer.h
#include video/omapdss.h
@@ -65,9 +66,6 @@ struct dss_reg {
#define REG_FLD_MOD(idx, val, start, end) \
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
-static int dss_runtime_get(void);
-static void dss_runtime_put(void);
-
struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
@@ -99,6 +97,9 @@ static struct {
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
const struct dss_features *feat;
+
+ struct dss_pll *video1_pll;
+ struct dss_pll *video2_pll;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -760,7 +761,7 @@ static void dss_put_clocks(void)
clk_put(dss.parent_clk);
}
-static int dss_runtime_get(void)
+int dss_runtime_get(void)
{
int r;
@@ -771,7 +772,7 @@ static int dss_runtime_get(void)
return r 0 ? r : 0;
}
-static void dss_runtime_put(void)
+void dss_runtime_put(void)
{
int r;
@@ -1023,6 +1024,7 @@ static int __init omap_dsshw_probe(struct platform_device
*pdev)
struct device_node *np = pdev-dev.of_node;
u32 rev;
int r;
+ struct regulator *pll_regulator;
dss.pdev = pdev;
@@ -1094,6 +1096,40 @@ static int __init omap_dsshw_probe(struct
platform_device *pdev)
}
}
+ pll_regulator = devm_regulator_get(pdev-dev, vdda_video);
+ if (IS_ERR(pll_regulator)) {
+ r = PTR_ERR(pll_regulator);
+
+ switch (r) {
+ case -ENOENT:
+ pll_regulator = NULL;
+ break;
+
+ case -EPROBE_DEFER:
+ return -EPROBE_DEFER;
+
+ default:
+ DSSERR(can't get DPLL VDDA regulator\n);
+ return r;
+ }
+ }
+
+ if (of_property_match_string(np, reg-names, pll1) = 0) {
+ dss.video1_pll = dss_video_pll_init(pdev, 0, pll_regulator);
+ if (IS_ERR(dss.video1_pll)) {
+ r = PTR_ERR(dss.video1_pll);
+ goto err_pll_init;
+ }
+ }
+
+ if (of_property_match_string(np, reg-names, pll2) = 0) {
+ dss.video2_pll = dss_video_pll_init(pdev, 1, pll_regulator);
+ if (IS_ERR(dss.video2_pll)) {
+ r = PTR_ERR(dss.video2_pll);
+ goto err_pll_init;
+ }
+ }
+
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO OMAP DSS rev %d.%d\n,
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -1104,6 +1140,12 @@ static int __init omap_dsshw_probe(struct
platform_device *pdev)
return 0;
+err_pll_init:
+ if (dss.video1_pll)
+ dss_video_pll_uninit(dss.video1_pll);
+
+ if (dss.video2_pll)
+ dss_video_pll_uninit(dss.video2_pll);
err_runtime_get:
pm_runtime_disable(pdev-dev);
err_setup_clocks:
@@ -1113,6 +1155,12 @@ err_setup_clocks:
static int __exit omap_dsshw_remove(struct platform_device *pdev)
{
+ if (dss.video1_pll)
+ dss_video_pll_uninit(dss.video1_pll);
+
+ if (dss.video2_pll)
+ dss_video_pll_uninit(dss.video2_pll);
+
dss_uninit_ports(pdev);
pm_runtime_disable(pdev-dev);
diff --git a/drivers/video
[PATCH 14/14] OMAPDSS: DPI: DRA7xx support
Add support for DRA7xx DPI output.
DRA7xx has three DPI outputs, each of which gets its input from a DISPC
channel. However, DRA72x has only one video PLL, and DRA74x has two
video PLLs. In both cases the video PLLs need to be shared between
multiple outputs. The driver doesn't handle this at the moment.
Also, DRA7xx requires configuring CONTROL module bits to route the clock
from the PLL to the used DISPC channel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dpi.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c
b/drivers/video/fbdev/omap2/dss/dpi.c
index 9a2f8c3b102d..f83e7b030249 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -106,6 +106,17 @@ static struct dss_pll *dpi_get_pll(enum omap_channel
channel)
return NULL;
}
+ case OMAPDSS_VER_DRA7xx:
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ case OMAP_DSS_CHANNEL_LCD2:
+ return dss_pll_find(video0);
+ case OMAP_DSS_CHANNEL_LCD3:
+ return dss_pll_find(video1);
+ default:
+ return NULL;
+ }
+
default:
return NULL;
}
@@ -590,6 +601,10 @@ static void dpi_init_pll(struct dpi_data *dpi)
if (!pll)
return;
+ /* On DRA7 we need to set a mux to use the PLL */
+ if (omapdss_get_version() == OMAPDSS_VER_DRA7xx)
+ dss_ctrl_pll_set_control_mux(pll-id,
dpi-output.dispc_channel);
+
if (dpi_verify_dsi_pll(pll)) {
DSSWARN(DSI PLL not operational\n);
return;
@@ -615,6 +630,17 @@ static enum omap_channel dpi_get_channel(int port_num)
case OMAPDSS_VER_AM43xx:
return OMAP_DSS_CHANNEL_LCD;
+ case OMAPDSS_VER_DRA7xx:
+ switch (port_num) {
+ case 2:
+ return OMAP_DSS_CHANNEL_LCD3;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD2;
+ case 0:
+ default:
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
case OMAPDSS_VER_OMAP4430_ES1:
case OMAPDSS_VER_OMAP4430_ES2:
case OMAPDSS_VER_OMAP4:
--
2.2.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
[PATCH 03/14] OMAPDSS: constify port arrays
The port arrays are constant data, so set them as 'const'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index 9987154d50b4..1884c29ef482 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -70,7 +70,7 @@ struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
- enum omap_display_type *ports;
+ const enum omap_display_type *ports;
int num_ports;
int (*dpi_select_source)(int port, enum omap_channel channel);
};
@@ -677,11 +677,11 @@ void dss_debug_dump_clocks(struct seq_file *s)
#endif
-static enum omap_display_type omap2plus_ports[] = {
+static const enum omap_display_type omap2plus_ports[] = {
OMAP_DISPLAY_TYPE_DPI,
};
-static enum omap_display_type omap34xx_ports[] = {
+static const enum omap_display_type omap34xx_ports[] = {
OMAP_DISPLAY_TYPE_DPI,
OMAP_DISPLAY_TYPE_SDI,
};
--
2.2.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
[PATCH 12/14] OMAPDSS: DISPC: program dispc polarities to control module
On DRA7xx, DISPC needs to write output signal polarities not only to a
DISPC register, like for all earlier DSS versions, but to control
module's CTRL_CORE_SMA_SW_1 register.
This patch adds support to write the polarities to control module.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 40 +++
1 file changed, 40 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 48429bab294a..31b743c70272 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -36,6 +36,9 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/sizes.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
+#include linux/of.h
#include video/omapdss.h
@@ -117,6 +120,9 @@ static struct {
const struct dispc_features *feat;
bool is_enabled;
+
+ struct regmap *syscon_pol;
+ u32 syscon_pol_offset;
} dispc;
enum omap_color_component {
@@ -2958,6 +2964,25 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsw,
FLD_VAL(vsync_level, 12, 12);
dispc_write_reg(DISPC_POL_FREQ(channel), l);
+
+ if (dispc.syscon_pol) {
+ const int shifts[] = {
+ [OMAP_DSS_CHANNEL_LCD] = 0,
+ [OMAP_DSS_CHANNEL_LCD2] = 1,
+ [OMAP_DSS_CHANNEL_LCD3] = 2,
+ };
+
+ u32 mask, val;
+
+ mask = (1 0) | (1 3) | (1 6);
+ val = (rf 0) | (ipc 3) | (onoff 6);
+
+ mask = 16 + shifts[channel];
+ val = 16 + shifts[channel];
+
+ regmap_update_bits(dispc.syscon_pol, dispc.syscon_pol_offset,
+ mask, val);
+ }
}
/* change name to mode? */
@@ -3741,6 +3766,7 @@ static int __init omap_dispchw_probe(struct
platform_device *pdev)
u32 rev;
int r = 0;
struct resource *dispc_mem;
+ struct device_node *np = pdev-dev.of_node;
dispc.pdev = pdev;
@@ -3767,6 +3793,20 @@ static int __init omap_dispchw_probe(struct
platform_device *pdev)
return -ENODEV;
}
+ if (np of_property_read_bool(np, syscon-pol)) {
+ dispc.syscon_pol = syscon_regmap_lookup_by_phandle(np,
syscon-pol);
+ if (IS_ERR(dispc.syscon_pol)) {
+ dev_err(pdev-dev, failed to get syscon-pol
regmap\n);
+ return PTR_ERR(dispc.syscon_pol);
+ }
+
+ if (of_property_read_u32_index(np, syscon-pol, 1,
+ dispc.syscon_pol_offset)) {
+ dev_err(pdev-dev, failed to get syscon-pol
offset\n);
+ return -EINVAL;
+ }
+ }
+
pm_runtime_enable(pdev-dev);
r = dispc_runtime_get();
--
2.2.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
[PATCH 06/14] OMAPDSS: add define for DRA7xx HW version
Add define for DRA7xx DSS version.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 6a84498ea513..60de61fea8e3 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -314,6 +314,7 @@ enum omapdss_version {
OMAPDSS_VER_OMAP4, /* All other OMAP4s */
OMAPDSS_VER_OMAP5,
OMAPDSS_VER_AM43xx,
+ OMAPDSS_VER_DRA7xx,
};
/* Board specific data */
--
2.2.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
[PATCH 11/14] OMAPDSS: DISPC: Add DRA7xx support
Add DRA7xx support to DISPC driver. The DISPC block is the same as on
OMAP5, except the PLL's used for clocking are videoX, not dsiX.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 9850d9ef9a9d..48429bab294a 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -3037,10 +3037,16 @@ unsigned long dispc_fclk_rate(void)
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
pll = dss_pll_find(dsi0);
+ if (!pll)
+ pll = dss_pll_find(video0);
+
r = pll-cinfo.clkout[0];
break;
case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
pll = dss_pll_find(dsi1);
+ if (!pll)
+ pll = dss_pll_find(video1);
+
r = pll-cinfo.clkout[0];
break;
default:
@@ -3069,10 +3075,16 @@ unsigned long dispc_mgr_lclk_rate(enum omap_channel
channel)
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
pll = dss_pll_find(dsi0);
+ if (!pll)
+ pll = dss_pll_find(video0);
+
r = pll-cinfo.clkout[0];
break;
case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
pll = dss_pll_find(dsi1);
+ if (!pll)
+ pll = dss_pll_find(video1);
+
r = pll-cinfo.clkout[0];
break;
default:
@@ -3668,6 +3680,7 @@ static int __init dispc_init_features(struct
platform_device *pdev)
break;
case OMAPDSS_VER_OMAP5:
+ case OMAPDSS_VER_DRA7xx:
src = omap54xx_dispc_feats;
break;
@@ -3832,6 +3845,7 @@ static const struct of_device_id dispc_of_match[] = {
{ .compatible = ti,omap3-dispc, },
{ .compatible = ti,omap4-dispc, },
{ .compatible = ti,omap5-dispc, },
+ { .compatible = ti,dra7-dispc, },
{},
};
--
2.2.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
[PATCH 04/14] OMAPDSS: OMAP5: fix digit output's allowed mgrs
The OMAP5 HW supports directing DIGIT channel to DPI output, but the
driver doesn't support that. However, we have marked that configuration
as possible in the dss features, so in certain cases the driver tries to
use that configuration, leading to broken display.
Fix the problem by allowing DIGIT channel to go only to HDMI output.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss_features.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss_features.c
b/drivers/video/fbdev/omap2/dss/dss_features.c
index 0e3da809473c..0e6f3f54749f 100644
--- a/drivers/video/fbdev/omap2/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/dss/dss_features.c
@@ -223,7 +223,7 @@ static const enum omap_dss_output_id
omap5_dss_supported_outputs[] = {
OMAP_DSS_OUTPUT_DSI1 | OMAP_DSS_OUTPUT_DSI2,
/* OMAP_DSS_CHANNEL_DIGIT */
- OMAP_DSS_OUTPUT_HDMI | OMAP_DSS_OUTPUT_DPI,
+ OMAP_DSS_OUTPUT_HDMI,
/* OMAP_DSS_CHANNEL_LCD2 */
OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
--
2.2.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
[PATCH 05/14] OMAPDSS: encoder-tpd12s015: Fix race issue with LS_OE
A race issue has been observed with the encoder-tpd12s015 driver, which
leads to errors when trying to read EDID. This has only now been
observed, as OMAP4 and OMAP5 boards used SoC's GPIOs for LS_OE GPIO. On
dra7-evm boards, the LS_OE is behind a i2c controlled GPIO expander,
which increases the time to set the LS_OE.
This patch simplifies the handling of the LS_OE gpio in the driver by
removing the interrupt handling totally. The only time we actually need
to enable LS_OE is when we are reading the EDID, and thus we can just
set and clear the LS_OE gpio inside the read_edid() function.
This also has the additional benefit of very slightly decreasing the
power consumption.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../fbdev/omap2/displays-new/encoder-tpd12s015.c | 57 --
1 file changed, 10 insertions(+), 47 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
index 7f3e11b16c86..990af6baeb0f 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
@@ -29,33 +29,10 @@ struct panel_drv_data {
int hpd_gpio;
struct omap_video_timings timings;
-
- struct completion hpd_completion;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
-static irqreturn_t tpd_hpd_irq_handler(int irq, void *data)
-{
- struct panel_drv_data *ddata = data;
- bool hpd;
-
- hpd = gpio_get_value_cansleep(ddata-hpd_gpio);
-
- dev_dbg(ddata-dssdev.dev, hpd %d\n, hpd);
-
- if (gpio_is_valid(ddata-ls_oe_gpio)) {
- if (hpd)
- gpio_set_value_cansleep(ddata-ls_oe_gpio, 1);
- else
- gpio_set_value_cansleep(ddata-ls_oe_gpio, 0);
- }
-
- complete_all(ddata-hpd_completion);
-
- return IRQ_HANDLED;
-}
-
static int tpd_connect(struct omap_dss_device *dssdev,
struct omap_dss_device *dst)
{
@@ -70,23 +47,10 @@ static int tpd_connect(struct omap_dss_device *dssdev,
dst-src = dssdev;
dssdev-dst = dst;
- reinit_completion(ddata-hpd_completion);
-
gpio_set_value_cansleep(ddata-ct_cp_hpd_gpio, 1);
/* DC-DC converter needs at max 300us to get to 90% of 5V */
udelay(300);
- /*
-* If there's a cable connected, wait for the hpd irq to trigger,
-* which turns on the level shifters.
-*/
- if (gpio_get_value_cansleep(ddata-hpd_gpio)) {
- unsigned long to;
- to = wait_for_completion_timeout(ddata-hpd_completion,
- msecs_to_jiffies(250));
- WARN_ON_ONCE(to == 0);
- }
-
return 0;
}
@@ -179,11 +143,20 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata-in;
+ int r;
if (!gpio_get_value_cansleep(ddata-hpd_gpio))
return -ENODEV;
- return in-ops.hdmi-read_edid(in, edid, len);
+ if (gpio_is_valid(ddata-ls_oe_gpio))
+ gpio_set_value_cansleep(ddata-ls_oe_gpio, 1);
+
+ r = in-ops.hdmi-read_edid(in, edid, len);
+
+ if (gpio_is_valid(ddata-ls_oe_gpio))
+ gpio_set_value_cansleep(ddata-ls_oe_gpio, 0);
+
+ return r;
}
static bool tpd_detect(struct omap_dss_device *dssdev)
@@ -309,8 +282,6 @@ static int tpd_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
- init_completion(ddata-hpd_completion);
-
if (dev_get_platdata(pdev-dev)) {
r = tpd_probe_pdata(pdev);
if (r)
@@ -340,13 +311,6 @@ static int tpd_probe(struct platform_device *pdev)
if (r)
goto err_gpio;
- r = devm_request_threaded_irq(pdev-dev, gpio_to_irq(ddata-hpd_gpio),
-NULL, tpd_hpd_irq_handler,
-IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
-IRQF_ONESHOT, hpd, ddata);
- if (r)
- goto err_irq;
-
dssdev = ddata-dssdev;
dssdev-ops.hdmi = tpd_hdmi_ops;
dssdev-dev = pdev-dev;
@@ -365,7 +329,6 @@ static int tpd_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_irq:
err_gpio:
omap_dss_put_device(ddata-in);
return r;
--
2.2.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
[PATCH 13/14] OMAPDSS: HDMI: Add DRA7xx support
Add support for DRA7xx to the HDMI driver.
The HDMI block on DRA7xx is the same as on OMAP5, except we need to
enable and disable the HDMI PLL via the CONTROL module.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi5.c| 1 +
drivers/video/fbdev/omap2/dss/hdmi_phy.c | 1 +
drivers/video/fbdev/omap2/dss/hdmi_pll.c | 5 +
3 files changed, 7 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 39aae3aa7136..3f0b34a7031a 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -787,6 +787,7 @@ static const struct dev_pm_ops hdmi_pm_ops = {
static const struct of_device_id hdmi_of_match[] = {
{ .compatible = ti,omap5-hdmi, },
+ { .compatible = ti,dra7-hdmi, },
{},
};
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_phy.c
b/drivers/video/fbdev/omap2/dss/hdmi_phy.c
index bc9e07d2afbe..1f5d19c119ce 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_phy.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_phy.c
@@ -208,6 +208,7 @@ static int hdmi_phy_init_features(struct platform_device
*pdev)
break;
case OMAPDSS_VER_OMAP5:
+ case OMAPDSS_VER_DRA7xx:
src = omap54xx_phy_feats;
break;
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
index b808f7c72d83..06e23a7c432c 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
@@ -104,6 +104,8 @@ static int hdmi_pll_enable(struct dss_pll *dsspll)
struct hdmi_wp_data *wp = pll-wp;
u16 r = 0;
+ dss_ctrl_pll_enable(DSS_PLL_HDMI, true);
+
r = hdmi_wp_set_pll_pwr(wp, HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
if (r)
return r;
@@ -117,6 +119,8 @@ static void hdmi_pll_disable(struct dss_pll *dsspll)
struct hdmi_wp_data *wp = pll-wp;
hdmi_wp_set_pll_pwr(wp, HDMI_PLLPWRCMD_ALLOFF);
+
+ dss_ctrl_pll_enable(DSS_PLL_HDMI, false);
}
static const struct dss_pll_ops dsi_pll_ops = {
@@ -197,6 +201,7 @@ static int dsi_init_pll_data(struct platform_device *pdev,
struct hdmi_pll_data
break;
case OMAPDSS_VER_OMAP5:
+ case OMAPDSS_VER_DRA7xx:
pll-hw = dss_omap5_hdmi_pll_hw;
break;
--
2.2.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
Re: [PATCH 01/23] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
On 24/01/15 23:51, Paul Walmsley wrote: + Tomi On Thu, 27 Nov 2014, Tero Kristo wrote: Splits the clock provider init out of the PRM driver and moves it to clock driver. This is needed so that once the PRCM drivers are separated, they can logically just access the clock driver not needing to go through common PRM code. This would be wrong in the case of control module for example. Signed-off-by: Tero Kristo t-kri...@ti.com This patch moves things in the wrong direction (ie, rather than keeping the PRM register accesses in the PRM code, it moves PRM register accesses into the clock code). But I see that a subsequent patch in this series moves them back. So this change is temporary and that seems reasonable to me. However, as long as the clock code wants to do low-level register accesses to PRM/CM/SCM registers, there needs to be some way to keep register updates originating from the clock code from racing with register updates coming from other code (e.g. non-clock-related PRM/CM/SCM accesses). So I've changed this patch to use regmap (as below), and the followup patch later in the series will be changed too. Seems to work so far but let's see how things go with the rest of the series. I'm not sure if I miss something, but regmap_write does not protect from problems if there are multiple users for the same registers. You need to use regmap_update_bits() to get a protected read/write sequence, in which you can change only the bits that you want to change. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: DRA7xx: hwmod: set DSS submodule parent hwmods
Hi Paul, On 03/01/15 00:50, Paul Walmsley wrote: On Fri, 19 Dec 2014, Tomi Valkeinen wrote: Set DSS core hwmod as the parent for all the DSS submodules. This fixes the boot time DSS reset, removing the following warnings: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued for v3.19-rc. Note that I cannot test this patch due to lack of a DRA7xx board here. Thanks. Unfortunately, I made a mistake with the DRA7xx patch. Well, the patch itself is correct, but we have some insanity in the HW that I missed: DRA7xx has a CTRL_CORE_CONTROL_IO_2 register in the control module, which contains bits for various subsystems, including DCAN, PCIe, QSPI and DSS. At the moment only DCAN driver uses the register via syscon + regmap. For DSS, the bit 0, DSS_DESHDCP_CLKEN is critical. While the bit is rather undocumented, it presumably enables a clock for DSS's HDCP. Now, we don't support HDPC in the display driver, but unfortunately the clock is required for the DSS hardware to initialize. Without this patch, we see only the few warnings about dss hwmods cannot be enabled, but with the patch, we see those and some WARN()s from hwmod as the DSS HW module does not start. So it's a bit worse. Why I didn't notice this is that I had an u-boot version that enables the DSS_DESHDCP_CLKEN bit and leaves it enabled. So what to do about the issue? You could drop/revert this patch if we don't see a quick solution for the DSS_DESHDCP_CLKEN. It won't fix anything as such, but lessens the boot-up spam. I don't have a good idea how to manage the bit properly. As far as I see, the bit has to be managed via syscon, using remap_update_bits, so that we get proper locking. With a quick glance, I didn't see anything for that in the current clock code. And can we presume that syscon is probed before hwmods? I guess not. For the time being, I think the easiest solution would be to just set the bit and leave it enabled. My understanding (based on commits in TI's product kernel) is that leaving the DSS_DESHDCP_CLKEN enabled doesn't really affect much, and any increased power consumption would be too small to measure. If that's the route, the question is still where to enable it. As I said, I have an u-boot which enables it, but I'd rather do the enabling in the kernel. If in the kernel, where there? It has to happen before the hwmod init is ran. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v8 4/8] can: c_can: Add syscon/regmap RAMINIT mechanism
Hi Roger, On 14/11/14 20:09, Marc Kleine-Budde wrote: From: Roger Quadros rog...@ti.com Some TI SoCs like DRA7 have a RAMINIT register specification different from the other AMxx SoCs and as expected by the existing driver. To add more insanity, this register is shared with other IPs like DSS, PCIe and PWM. Provides a more generic mechanism to specify the RAMINIT register location and START/DONE bit position and use the syscon/regmap framework to access the register. This patch updates the syscon regmap using regmap_read + regmap_write. That's not a safe way to update the bits, as some other driver may touch the register between the read and write. The change has to be made using regmap_update_bits. We don't have other drivers using the register at the moment, but I presume we will sooner or later. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/3] arm: dts: omap3-gta04: Add handling for tv output
On 03/12/14 23:33, Marek Belisko wrote: Add handling for gta04 tv out chain: venc - opa362 - svideo Use invert-polarity in venc node because opa362 is doing polarity inversion also. Signed-off-by: Marek Belisko ma...@goldelico.com --- arch/arm/boot/dts/omap3-gta04.dtsi | 49 ++ 1 file changed, 49 insertions(+) Looks fine to me. Tony, do you want to pick this up? I can take the first two patches via fbdev. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] video: fbdev: omap2: dss: rfbi.c: Remove some unused functions
On 21/12/14 19:02, Rickard Strandqvist wrote: Removes some functions that are not used anywhere: rfbi_init_display() rfbi_display_disable() rfbi_display_enable() rfbi_set_interface_timings() rfbi_set_data_lines() rfbi_set_pixel_size() rfbi_set_size() rfbi_update() rfbi_configure() rfbi_enable_te() rfbi_setup_te() rfbi_write_pixels() rfbi_write_data() rfbi_read_data() rfbi_write_command() rfbi_bus_unlock() rfbi_bus_lock() This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/video/fbdev/omap2/dss/rfbi.c | 297 -- 1 file changed, 297 deletions(-) It's true those functions are not used anywhere, but RFBI is currently marked as BROKEN so it cannot be compiled and the functions do not do any harm. I'd rather keep them, as they give an insight how the rfbi should work if and when someone will fix the driver. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] video: fbdev: omap2: dss: dispc.c: Remove some unused functions
On 01/01/15 17:29, Rickard Strandqvist wrote: Removes some functions that are not used anywhere: dispc_wb_go() dispc_wb_go_busy() dispc_wb_get_framedone_irq() dispc_mgr_get_clock_div() dispc_wb_is_enabled() dispc_wb_enable() dispc_wb_setup() dispc_enable_fifomerge() dispc_wb_set_channel_in() This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/video/fbdev/omap2/dss/dispc.c | 124 - drivers/video/fbdev/omap2/dss/dss.h | 12 2 files changed, 136 deletions(-) The functions are for DSS's write-back functionality. We're going to implement that hopefully sometime soon, so I don't want to remove those functions. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] fbdev: omap2: Fix typo in tvc_probe_pdata
On 05/01/15 15:09, Rasmus Villemoes wrote: Assigning ddata-invert_polarity to itself is not very useful; the context suggests that the right-hand side should have been pdata-invert_polarity. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk --- drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c b/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c index 9a2b5ce58545..8511c648a15c 100644 --- a/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c +++ b/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c @@ -208,7 +208,7 @@ static int tvc_probe_pdata(struct platform_device *pdev) ddata-in = in; ddata-connector_type = pdata-connector_type; - ddata-invert_polarity = ddata-invert_polarity; + ddata-invert_polarity = pdata-invert_polarity; dssdev = ddata-dssdev; dssdev-name = pdata-name; Good catch, thanks! Queueing for 3.20 (as no one is using that flag in 3.19). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] can: c_can: use regmap_update_bits() to modify RAMINIT register
On 07/01/15 16:32, Roger Quadros wrote: use of regmap_read() and regmap_write() in c_can_hw_raminit_syscon() is not safe as the RAMINIT register can be shared between different drivers at least for TI SoCs. To make the modification atomic we switch to using regmap_update_bits(). Signed-off-by: Roger Quadros rog...@ti.com --- drivers/net/can/c_can/c_can_platform.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c index f363972..364209a 100644 --- a/drivers/net/can/c_can/c_can_platform.c +++ b/drivers/net/can/c_can/c_can_platform.c @@ -110,6 +110,10 @@ static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable) */ ctrl = ~(1 raminit-bits.start); ctrl |= 1 raminit-bits.done; + + /* we can't use regmap_update_bits here as it will bypass the write + * if START is already 0 and DONE is already 1. + */ regmap_write(raminit-syscon, raminit-reg, ctrl); Can you first use update_bits to change either bit, so that this update will be done? Tomi signature.asc Description: OpenPGP digital signature
[PATCH 7/9] arm/dts: dra72-evm.dts: add HDMI
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 111
1 file changed, 111 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 89085d066c65..85f9aa4fc94f 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include dra72x.dtsi
+#include dt-bindings/gpio/gpio.h
/ {
model = TI DRA722;
@@ -18,12 +19,61 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
+ aliases {
+ display0 = hdmi0;
+ };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+ pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -34,6 +84,13 @@
;
};
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins =
+ 0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda
*/
+ 0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl
*/
+ ;
+ };
+
nand_default: nand_default {
pinctrl-single,pins =
0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
@@ -121,6 +178,19 @@
0x418 (MUX_MODE15)/* wakeup0.off */
;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl
*/
+ 0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda
*/
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ ;
+ };
};
i2c1 {
@@ -245,6 +315,27 @@
};
};
+i2c5 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c5_pins;
+ clock-frequency = 40;
+
+ pcf_hdmi: pcf8575@26 {
+ compatible = nxp,pcf8575;
+ reg = 0x26;
+ gpio-controller;
+ #gpio-cells = 2;
+ /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+ lines-initial-states = 0x0f2b;
+ };
+};
+
uart1 {
status = okay;
};
@@ -461,3 +552,23 @@
pinctrl-0 = dcan1_pins_default;
pinctrl-1 = dcan1_pins_sleep;
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
DRA7xx's CTRL_CORE_CONTROL_IO_2 register contains bits for various
subsystems, including PCIe, DCAN, QSPI and DSS. At the moment only DCAN
bits are used by the SW via syscon.
For DSS there is DSS_DESHDCP_CLKEN bit. This (presumably) enables a
clock related to DSS's HDCP. If that clock is off, DSS module does not
start at all, causing OCP errors. This means that the HWMOD code is not
able to reset and initialize DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/io.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index a1bd6affb508..2206fb13f195 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -700,6 +700,17 @@ void __init dra7xx_init_early(void)
dra7xx_hwmod_init();
omap_hwmod_init_postsetup();
omap_clk_soc_init = dra7xx_dt_clk_init;
+
+ if (soc_is_dra7xx()) {
+ u32 v;
+ const u16 ctrl_core_control_io_2 = 0x558;
+
+ /* set CTRL_CORE_CONTROL_IO_2:DSS_DESHDCP_CLKEN */
+
+ v = omap_ctrl_readl(ctrl_core_control_io_2);
+ v |= 1;
+ omap_ctrl_writel(v, ctrl_core_control_io_2);
+ }
}
void __init dra7xx_init_late(void)
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] arm/dts: am57xx-beagle-x15.dts: add HDMI
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 80 +
1 file changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda68cd5..0b838d34b8a1 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -19,6 +19,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+ display0 = hdmi0;
};
memory {
@@ -80,6 +81,51 @@
default-state = off;
};
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio7 10 GPIO_ACTIVE_HIGH, /* gpio7_10, CT CP HPD
*/
+ gpio6 28 GPIO_ACTIVE_HIGH, /* gpio6_28, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -99,6 +145,13 @@
;
};
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /*
i2c2_sda.hdmi1_ddc_scl */
+ 0x40c (PIN_INPUT | MUX_MODE1) /*
i2c2_scl.hdmi1_ddc_sda */
+ ;
+ };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins =
0x2a4 (PIN_INPUT| MUX_MODE10) /*
mcasp1_aclkx.i2c3_sda */
@@ -164,6 +217,13 @@
;
};
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10
CT_CP_HPD */
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ 0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28
LS_OE */
+ ;
+ };
};
i2c1 {
@@ -403,3 +463,23 @@
pinctrl-names = default;
pinctrl-0 = usb1_pins;
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..0d76233840e6 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1451,6 +1451,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+ ti,set-rate-parent;
};
dss_hdmi_clk: dss_hdmi_clk {
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] ARM: DRA7: add display support
Hi, This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. The series is based on OMAPDSS driver patches in fbdev changes for 3.20, which have been merged to Linus' tree. The changes are very similar to OMAP5 DSS. All the other patches look fine to me except the RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN. That's been discussed earlier with Paul and Tero, but I don't think we have any good solution for it yet. Tomi Tomi Valkeinen (9): arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods ARM: OMAP: display: change compat names to array ARM: OMAP2+: display: detect DRA7 DSS arm/dts: dra7.dtsi: add DSS support arm/dts: dra72-evm.dts: add HDMI arm/dts: am57xx-beagle-x15.dts: add HDMI RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN arch/arm/boot/dts/am57xx-beagle-x15.dts | 80 + arch/arm/boot/dts/dra7.dtsi | 38 ++ arch/arm/boot/dts/dra72-evm.dts | 111 ++ arch/arm/boot/dts/dra72x.dtsi | 11 +++ arch/arm/boot/dts/dra74x.dtsi | 15 arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 + arch/arm/mach-omap2/display.c | 32 + arch/arm/mach-omap2/io.c | 11 +++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 + 9 files changed, 316 insertions(+), 15 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: OMAP2+: display: detect DRA7 DSS
Add platform code to detect DRA7 DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 156d022b1e09..7f596fe2bfeb 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -281,6 +281,8 @@ static enum omapdss_version __init
omap_display_get_version(void)
return OMAPDSS_VER_OMAP5;
else if (soc_is_am43xx())
return OMAPDSS_VER_AM43xx;
+ else if (soc_is_dra7xx())
+ return OMAPDSS_VER_DRA7xx;
else
return OMAPDSS_VER_UNKNOWN;
}
@@ -567,6 +569,7 @@ static const char * const omapdss_compat_names[]
__initconst = {
ti,omap3-dss,
ti,omap4-dss,
ti,omap5-dss,
+ ti,dra7-dss,
};
struct device_node * __init omapdss_find_dss_of_node(void)
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] ARM: DRA7: hwmod: add DMM hwmod description
Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index ffd6604cd546..47664bab5b57 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -49,6 +49,27 @@
*/
/*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class dra7xx_dmm_hwmod_class = {
+ .name = dmm,
+};
+
+/* dmm */
+static struct omap_hwmod dra7xx_dmm_hwmod = {
+ .name = dmm,
+ .class = dra7xx_dmm_hwmod_class,
+ .clkdm_name = emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'l3' class
* instance(s): l3_instr, l3_main_1, l3_main_2
*/
@@ -2312,6 +2333,14 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
* Interfaces
*/
+/* l3_main_1 - dmm */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dmm = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_dmm_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_SDMA,
+};
+
/* l3_main_2 - l3_instr */
static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
.master = dra7xx_l3_main_2_hwmod,
@@ -3264,6 +3293,7 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2
= {
};
static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+ dra7xx_l3_main_1__dmm,
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
dra7xx_mpu__l3_main_1,
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: DRA7: hwmod: set DSS submodule parent hwmods
Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 47664bab5b57..d7d2404f5f28 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -521,6 +521,7 @@ static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
},
},
.dev_attr = dss_dispc_dev_attr,
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
@@ -562,6 +563,7 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: OMAP: display: change compat names to array
Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 7a050f9c37ff..156d022b1e09 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -562,25 +562,24 @@ void __init omapdss_early_init_of(void)
}
+static const char * const omapdss_compat_names[] __initconst = {
+ ti,omap2-dss,
+ ti,omap3-dss,
+ ti,omap4-dss,
+ ti,omap5-dss,
+};
+
struct device_node * __init omapdss_find_dss_of_node(void)
{
struct device_node *node;
+ int i;
- node = of_find_compatible_node(NULL, NULL, ti,omap2-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap3-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap4-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap5-dss);
- if (node)
- return node;
+ for (i = 0; i ARRAY_SIZE(omapdss_compat_names); ++i) {
+ node = of_find_compatible_node(NULL, NULL,
+ omapdss_compat_names[i]);
+ if (node)
+ return node;
+ }
return NULL;
}
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] arm/dts: dra7.dtsi: add DSS support
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7.dtsi | 38 ++
arch/arm/boot/dts/dra72x.dtsi | 11 +++
arch/arm/boot/dts/dra74x.dtsi | 15 +++
3 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 22771bc1643a..fc35a8a06d95 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1421,6 +1421,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+ dss: dss@5800 {
+ compatible = ti,dra7-dss;
+ /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+ /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+ status = disabled;
+ ti,hwmods = dss_core;
+ /* CTRL_CORE_DSS_PLL_CONTROL */
+ syscon-pll-ctrl = dra7_ctrl_core 0x538;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,dra7-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ /* CTRL_CORE_SMA_SW_1 */
+ syscon-pol = dra7_ctrl_core 0x534;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,dra7-hdmi;
+ reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_hdmi_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..0866866c8e94 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -28,3 +28,14 @@
interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1;
+
+ clocks = dss_dss_clk,
+dss_video1_clk;
+ clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..1a4f4970aaad 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -67,3 +67,18 @@
};
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1,
+ pll2_clkctrl, pll2;
+
+ clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+ clock-names = fck, video1_clk, video2_clk;
+};
--
2.3.0
--
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 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 13/02/15 17:25, Nishanth Menon wrote:
On Fri, Feb 13, 2015 at 9:11 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
DRA7xx's CTRL_CORE_CONTROL_IO_2 register contains bits for various
subsystems, including PCIe, DCAN, QSPI and DSS. At the moment only DCAN
bits are used by the SW via syscon.
For DSS there is DSS_DESHDCP_CLKEN bit. This (presumably) enables a
clock related to DSS's HDCP. If that clock is off, DSS module does not
start at all, causing OCP errors. This means that the HWMOD code is not
able to reset and initialize DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/io.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index a1bd6affb508..2206fb13f195 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -700,6 +700,17 @@ void __init dra7xx_init_early(void)
dra7xx_hwmod_init();
omap_hwmod_init_postsetup();
omap_clk_soc_init = dra7xx_dt_clk_init;
+
+ if (soc_is_dra7xx()) {
Umm.. this code will only be executed for dra7xx :)
Better safe than sorry! But you're right, I'll remove the if =).
+ u32 v;
+ const u16 ctrl_core_control_io_2 = 0x558;
+
+ /* set CTRL_CORE_CONTROL_IO_2:DSS_DESHDCP_CLKEN */
+
+ v = omap_ctrl_readl(ctrl_core_control_io_2);
+ v |= 1;
+ omap_ctrl_writel(v, ctrl_core_control_io_2);
+ }
}
void __init dra7xx_init_late(void)
just my 2 cents.
I would probably wait for control module to become syscon and probably
model this as syscon clk - I thin we should be seeing a series
sometime soon.
Yep, I hope Tero's work will make this patch not needed. I wanted to
include something in this series that makes the DSS usable.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/9] ARM: DRA7: add display support
On 13/02/15 18:01, Nishanth Menon wrote: On 02/13/2015 09:11 AM, Tomi Valkeinen wrote: Hi, This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. The series is based on OMAPDSS driver patches in fbdev changes for 3.20, which have been merged to Linus' tree. The changes are very similar to OMAP5 DSS. All the other patches look fine to me except the RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN. That's been discussed earlier with Paul and Tero, but I don't think we have any good solution for it yet. Is there some specific tag I can test this on (some next perhaps?), I Linus's master or linux-next should work. This series is based on the fbdev changes for 3.20. So if Linus' master or linux-next doesn't work, v3.19 + fbdev-3.20 + this series should work. Further are you proposing this for 3.20 or 3.21 window? 3.20, we seem to have already missed. 3.21. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: DRA7xx: hwmod: set DSS submodule parent hwmods
On 08/01/15 12:15, Paul Walmsley wrote: For DSS, the bit 0, DSS_DESHDCP_CLKEN is critical. While the bit is rather undocumented, it presumably enables a clock for DSS's HDCP. Now, we don't support HDPC in the display driver, but unfortunately the clock is required for the DSS hardware to initialize. Do you know where this DSS_DESHDCP clock appears in the clock tree? Is it downstream of the main DSS functional clock, or does it come from somewhere else? Unfortunately not. It is not mentioned in any documentation I can find. OMAP5 has the exact same HDMI block, but it does not have this bit in the control module. There's this commit from Archit (who is no longer in TI) with some data, but I cannot find any of it in the documentation: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/247993.html Maybe OMAP5 has this clock always enabled, i.e. direct L3 clock without the gate, and the bit was added to DRA7x to give the tiny bit of power saving it might produce. This sounds quite likely scenario to me. If so, it would not sound too bad to set the bit at boot time to make the HW work like OMAP5, so that the SW could be the same. But then again, I'm purely guessing. Sounds like the thing to do in the short term is to drop that patch from the fixes series. Then we can add it back when DSS_DESHDCP_CLKEN is sorted. Are you OK with that for the time being? Yes, I think it's fine to drop it. While resetting the DSS at boot time would be nice, I think in practice the only diff with this patch (if it worked) and the current situation are the few hwmod warnings we get at boot time. However, I'm working on DRA7 display support for omapdss, and it won't work if the DSS_DESHDCP_CLKEN is not enabled. So we need some kind of solution pretty soon. I don't have a good idea how to manage the bit properly. As far as I see, the bit has to be managed via syscon, using remap_update_bits, so that we get proper locking. With a quick glance, I didn't see anything for that in the current clock code. And can we presume that syscon is probed before hwmods? I guess not. Based on the description so far, it sounds like there should be a system control module driver that registers this clock, along with all of the other clocks in the CTRL_CORE_CONTROL_IO_2 register. Just shooting from the hip here, I guess we'd probably list that DSS_DESHDCP_CLKEN clock as an optional clock for DSS in the hwmod data, and add some code to indicate that it should be enabled and disabled with the main_clk. Hmm, ok. So a syscon driver, that registers this clock (and maybe some others), and allows access to the non-clock bits via regmap, and handles locking between the clock and non-clock accesses? For the time being, I think the easiest solution would be to just set the bit and leave it enabled. My understanding (based on commits in TI's product kernel) is that leaving the DSS_DESHDCP_CLKEN enabled doesn't really affect much, and any increased power consumption would be too small to measure. If that's the route, the question is still where to enable it. As I said, I have an u-boot which enables it, but I'd rather do the enabling in the kernel. If in the kernel, where there? It has to happen before the hwmod init is ran. Yeah, that's a tricky question to answer. If DSS_DESHDCP_CLKEN is modeled as a clock, then it could be marked as ENABLE_ON_INIT, but that seems like kind of a hack. True, but the HW here also seems like a kind of hack =). Random bits from various subsystems in the same register... sigh... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] drm/omap: tiler: add hibernation callback
On 18/03/15 16:56, grygorii.stras...@linaro.org wrote:
Hi All,
On 02/25/2015 08:08 PM, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Setting a dev_pm_ops resume callback but not a set of
hibernation handler means that pm function will not be
called upon hibernation.
Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
omap_dmm_resume under CONFIG_PM_SLEEP to avoid build warnings.
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 56c6055..afb8cfc 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -941,7 +941,7 @@ error:
}
#endif
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int omap_dmm_resume(struct device *dev)
{
struct tcm_area area;
@@ -965,12 +965,10 @@ static int omap_dmm_resume(struct device *dev)
return 0;
}
-
-static const struct dev_pm_ops omap_dmm_pm_ops = {
-.resume = omap_dmm_resume,
-};
#endif
+SIMPLE_DEV_PM_OPS(omap_dmm_pm_ops, NULL, omap_dmm_resume);
+
#if defined(CONFIG_OF)
static const struct of_device_id dmm_of_match[] = {
{ .compatible = ti,omap4-dmm, },
@@ -986,9 +984,7 @@ struct platform_driver omap_dmm_driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
.of_match_table = of_match_ptr(dmm_of_match),
-#ifdef CONFIG_PM
.pm = omap_dmm_pm_ops,
-#endif
},
};
Any comments on this?
Sorry, I missed this. I'll add it to my omapdrm branch.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] omapdss: extend pm notifier to handle hibernation
On 25/02/15 19:03, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Add handling of missed events in omap_dss_pm_notif which are
needed to support hibernation (suspend to disk).
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/video/fbdev/omap2/dss/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/core.c
b/drivers/video/fbdev/omap2/dss/core.c
index 6b74f73..e60976a 100644
--- a/drivers/video/fbdev/omap2/dss/core.c
+++ b/drivers/video/fbdev/omap2/dss/core.c
@@ -178,11 +178,15 @@ static int omap_dss_pm_notif(struct notifier_block *b,
unsigned long v, void *d)
DSSDBG(pm notif %lu\n, v);
switch (v) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
+ case PM_RESTORE_PREPARE:
DSSDBG(suspending displays\n);
return dss_suspend_all_devices();
case PM_POST_SUSPEND:
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
DSSDBG(resuming displays\n);
return dss_resume_all_devices();
Why suspend displays when PM_RESTORE_PREPARE happens? Why resume when
PM_POST_RESTORE happens?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] omapdss: extend pm notifier to handle hibernation
On 20/03/15 16:57, grygorii.stras...@linaro.org wrote:
Hi Tomi,
On 03/20/2015 02:20 PM, Tomi Valkeinen wrote:
On 25/02/15 19:03, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Add handling of missed events in omap_dss_pm_notif which are
needed to support hibernation (suspend to disk).
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/video/fbdev/omap2/dss/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/core.c
b/drivers/video/fbdev/omap2/dss/core.c
index 6b74f73..e60976a 100644
--- a/drivers/video/fbdev/omap2/dss/core.c
+++ b/drivers/video/fbdev/omap2/dss/core.c
@@ -178,11 +178,15 @@ static int omap_dss_pm_notif(struct notifier_block
*b, unsigned long v, void *d)
DSSDBG(pm notif %lu\n, v);
switch (v) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
+ case PM_RESTORE_PREPARE:
DSSDBG(suspending displays\n);
return dss_suspend_all_devices();
case PM_POST_SUSPEND:
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
DSSDBG(resuming displays\n);
return dss_resume_all_devices();
Why suspend displays when PM_RESTORE_PREPARE happens? Why resume when
PM_POST_RESTORE happens?
We have following sequence when system is restored from hibernation:
- original kernel booted;
- late_initcall_sync(software_resume);
- pm_notifier_call_chain(PM_RESTORE_PREPARE);
- freeze_processes
- check read hibernation image
- suspend all devices (.freeze())
- jump to stored kernel
- restore devices
...
So, all devices should be in frozen/suspended state when we will jump to
stored kernel
(device's state should be the same as before creating hib image).
Without this patch I can see a lot of log messages like below:
Yes, I am sure a fix is needed for hibernation. But I still don't quite
understand PM_RESTORE_PREPARE and PM_POST_RESTORE.
When we enter hibernation, there's only PM_HIBERNATION_PREPARE?
When waking from hibernation, there's first PM_RESTORE_PREPARE, where we
need to disable displays that were enabled during boot. Then either
PM_POST_HIBERNATION if all went well, or PM_POST_RESTORE if there was an
error, and in both cases we want to enable the displays?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 6/7] drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
On 06/03/15 17:36, Jyri Sarha wrote: If I read Documentation/kbuild/makefiles.txt section 3.6 right, this patch should not be needed. However, without this patch the objects needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is built as module. Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/gpu/drm/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..ad7f10f 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ +obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc/ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ obj-$(CONFIG_DRM_MSM) += msm/ I don't think it's a good idea to enter the directory twice. Maybe it works fine, I don't know, but I'd suggest just using obj-y above. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
Hi, On 18/03/15 11:06, Jyri Sarha wrote: I think the patches 1-5 are ready for merging. See the details below. I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. After doing that and waiting a few secs: # ./s-bbb.sh [ 15.237139] sysrq: SysRq : Changing Loglevel [ 15.241646] sysrq: Loglevel set to 9 [ 15.319762] [drm] Initialized drm 1.1.0 20060810 [ 15.588122] tda998x 0-0070: found TDA19988 [ 15.594824] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops [tda998x]) [ 15.602034] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 15.609011] [drm] No driver support for vblank timestamp query. [ 15.700798] tilcdc 4830e000.lcdc: fb0: frame buffer device [ 15.706757] tilcdc 4830e000.lcdc: registered panic notifier [ 15.712659] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0 # # [ 25.789364] [ cut here ] [ 25.794315] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 25.805999] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 25.812325] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g5fbf26ebaf12 #7 [ 25.820893] Hardware name: Generic AM33XX (Flattened Device Tree) [ 25.827359] Workqueue: events output_poll_execute [drm_kms_helper] [ 25.833819] Backtrace: [ 25.836439] [c0013550] (dump_backtrace) from [c0013764] (show_stack+0x18/0x1c) [ 25.844380] r6:c09d4228 r5:c09d4228 r4: r3:dd3604c0 [ 25.850338] [c001374c] (show_stack) from [c066bbc0] (dump_stack+0xa4/0xd4) [ 25.857927] [c066bb1c] (dump_stack) from [c0044d28] (warn_slowpath_common+0x84/0xc0) [ 25.866401] r6:010d r5:bf0a010c r4: r3:dd3604c0 [ 25.872348] [c0044ca4] (warn_slowpath_common) from [c0044e08] (warn_slowpath_null+0x24/0x2c) [ 25.881543] r8:dd50 r7:000f r6:bf0a25f0 r5:dd6b1400 r4:dd4e6800 [ 25.888617] [c0044de4] (warn_slowpath_null) from [bf0a010c] (tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]) [ 25.898849] [bf09fb20] (tilcdc_crtc_mode_set [tilcdc]) from [bf06d874] (drm_crtc_helper_set_mode+0x2b0/0x4f0 [drm_kms_helper]) [ 25.911132] r10:dd4e6bf0 r9:dd4e6800 r8:dd4e2e80 r7:dd6b1400 r6:0001 r5:dd50 [ 25.919372] r4:bf09fb20 [ 25.922061] [bf06d5c4] (drm_crtc_helper_set_mode [drm_kms_helper]) from [bf06e450] (drm_crtc_helper_set_config+0x768/0x9c8 [drm_kms_helper]) [ 25.935612] r10: r9:dd73d980 r8:dd4e6bf0 r7:bf031808 r6:dd4e6be4 r5:dd4e6bd8 [ 25.943827] r4:dd50 [ 25.946758] [bf06dce8] (drm_crtc_helper_set_config [drm_kms_helper]) from [bf00dcfc] (drm_mode_set_config_internal+0x6c/0xf4 [drm]) [ 25.959518] r10:0001 r9: r8:dd4b4b40 r7:dd50 r6:0001 r5:0028 [ 25.967767] r4:dd4b46c0 [ 25.970558] [bf00dc90] (drm_mode_set_config_internal [drm]) from [bf077a88] (restore_fbdev_mode+0xe0/0x100 [drm_kms_helper]) [ 25.982672] r7:dd73d980 r6:0001 r5:0028 r4: [ 25.988698] [bf0779a8] (restore_fbdev_mode [drm_kms_helper]) from [bf0799cc] (drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x64 [drm_kms_helper]) [ 26.002884] r9:dd4e6be4 r8:bf031808 r7:dd4e6800 r6:dd4e6800 r5:dd4b46c0 r4:dd4b4b40 [ 26.011104] [bf0799a8] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [bf079a2c] (drm_fb_helper_set_par+0x20/0x3c [drm_kms_helper]) [ 26.025562] r6:dd4e6800 r5:dd4b46c0 r4: r3: [ 26.031556] [bf079a0c] (drm_fb_helper_set_par [drm_kms_helper]) from [bf079968] (drm_fb_helper_hotplug_event+0x90/0xd0 [drm_kms_helper]) [ 26.044753] r4:dd4b4b40 r3: [ 26.048557] [bf0798d8] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [bf07a7c4] (drm_fbdev_cma_hotplug_event+0x18/0x1c [drm_kms_helper]) [ 26.062289] r7:dd4e6a40 r6:0001 r5:dd4e6c38 r4:dd4e6800 [ 26.068300] [bf07a7ac] (drm_fbdev_cma_hotplug_event [drm_kms_helper]) from [bf0a217c] (tilcdc_fb_output_poll_changed+0x18/0x1c [tilcdc]) [ 26.081521] [bf0a2164] (tilcdc_fb_output_poll_changed [tilcdc]) from [bf06f388] (drm_kms_helper_hotplug_event+0x2c/0x30 [drm_kms_helper]) [ 26.094840] [bf06f35c] (drm_kms_helper_hotplug_event [drm_kms_helper]) from [bf06f448] (output_poll_execute+0x6c/0x18c [drm_kms_helper]) [ 26.108027] r4:dd4e6bd8 r3: [ 26.111809] [bf06f3dc] (output_poll_execute [drm_kms_helper]) from [c005c704] (process_one_work+0x1e8/0x560) [ 26.122456] r10:dfa1b700 r9: r8:c0a0c0b8 r7:dd51deb0 r6:dfa157c0 r5:dd4b4d40 [ 26.130696] r4:dd4e6c38 [ 26.133353] [c005c51c] (process_one_work) from [c005d42c] (worker_thread+0x160/0x4c4) [ 26.141914] r10:dfa157c0 r9:0008 r8:dd4b4d58 r7:dd4b4d40 r6:c005d304 r5:dfa157f0 [ 26.150153] r4:dfa157c0 [ 26.152812] [c005d2cc] (worker_thread) from [c0061e38] (kthread+0xf0/0x110) [ 26.160465] r10: r9: r8: r7:c005d2cc r6:dd4b4d40 r5:dd509cc0 [ 26.168704] r4: [ 26.171362] [c0061d48] (kthread) from [c000f6d0]
[PATCHv2 06/10] arm/dts: dra7.dtsi: add DSS support
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7.dtsi | 38 ++
arch/arm/boot/dts/dra72x.dtsi | 11 +++
arch/arm/boot/dts/dra74x.dtsi | 15 +++
3 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8e50ca3fc102..312ede660b23 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1445,6 +1445,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+ dss: dss@5800 {
+ compatible = ti,dra7-dss;
+ /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+ /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+ status = disabled;
+ ti,hwmods = dss_core;
+ /* CTRL_CORE_DSS_PLL_CONTROL */
+ syscon-pll-ctrl = scm_conf 0x538;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,dra7-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ /* CTRL_CORE_SMA_SW_1 */
+ syscon-pol = scm_conf 0x534;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,dra7-hdmi;
+ reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_hdmi_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..0866866c8e94 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -28,3 +28,14 @@
interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1;
+
+ clocks = dss_dss_clk,
+dss_video1_clk;
+ clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..1a4f4970aaad 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -67,3 +67,18 @@
};
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1,
+ pll2_clkctrl, pll2;
+
+ clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+ clock-names = fck, video1_clk, video2_clk;
+};
--
2.3.3
--
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
[PATCHv2 00/10] ARM: DRA7: add display support
Hi, This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. This series is v2, and is based on Tero's [PATCHv5 00/35] ARM: OMAP2+: PRCM/SCM cleanups against 4.0-rc series. The difference to v1 is that the DESHDCP clock is a real clock, even if we still always enable it at boot time. Tomi Tomi Valkeinen (10): arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods ARM: OMAP: display: change compat names to array ARM: OMAP2+: display: detect DRA7 DSS arm/dts: dra7.dtsi: add DSS support arm/dts: dra72-evm.dts: add HDMI arm/dts: am57xx-beagle-x15.dts: add HDMI arm: dra7: add DESHDCP clock CLK: TI: always enable DESHDCP clock arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 ++ arch/arm/boot/dts/dra7.dtsi | 43 arch/arm/boot/dts/dra72-evm.dts | 110 ++ arch/arm/boot/dts/dra72x.dtsi | 11 +++ arch/arm/boot/dts/dra74x.dtsi | 15 arch/arm/boot/dts/dra7xx-clocks.dtsi | 11 +++ arch/arm/mach-omap2/display.c | 32 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 33 + drivers/clk/ti/clk-7xx.c | 8 ++- 9 files changed, 328 insertions(+), 16 deletions(-) -- 2.3.3 -- 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
[PATCHv2 07/10] arm/dts: dra72-evm.dts: add HDMI
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 110
1 file changed, 110 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4d8711713610..c752d7aa302d 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,10 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
+ aliases {
+ display0 = hdmi0;
+ };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
@@ -35,6 +39,51 @@
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 2 GPIO_ACTIVE_HIGH;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+ pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -45,6 +94,13 @@
;
};
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins =
+ 0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda
*/
+ 0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl
*/
+ ;
+ };
+
nand_default: nand_default {
pinctrl-single,pins =
0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
@@ -144,6 +200,19 @@
0xb8 (PIN_OUTPUT | MUX_MODE1) /* gpmc_cs2.qspi1_cs0 */
;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl
*/
+ 0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda
*/
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ ;
+ };
};
i2c1 {
@@ -280,6 +349,27 @@
};
};
+i2c5 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c5_pins;
+ clock-frequency = 40;
+
+ pcf_hdmi: pcf8575@26 {
+ compatible = nxp,pcf8575;
+ reg = 0x26;
+ gpio-controller;
+ #gpio-cells = 2;
+ /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+ lines-initial-states = 0x0f2b;
+ };
+};
+
uart1 {
status = okay;
};
@@ -569,3 +659,23 @@
};
};
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.3
--
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
[PATCHv2 10/10] CLK: TI: always enable DESHDCP clock
DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.
As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.
Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.
So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 7b859ec31a14..e132d0677c03 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -308,7 +308,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
int __init dra7xx_dt_clk_init(void)
{
int rc;
- struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+ struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
ti_dt_clocks_register(dra7xx_clks);
@@ -344,5 +344,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
+ hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+ rc = clk_prepare_enable(hdcp_ck);
+ if (rc)
+ pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
}
--
2.3.3
--
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
[PATCHv2 02/10] ARM: DRA7: hwmod: add DMM hwmod description
Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..c236ea9bb940 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -49,6 +49,27 @@
*/
/*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class dra7xx_dmm_hwmod_class = {
+ .name = dmm,
+};
+
+/* dmm */
+static struct omap_hwmod dra7xx_dmm_hwmod = {
+ .name = dmm,
+ .class = dra7xx_dmm_hwmod_class,
+ .clkdm_name = emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'l3' class
* instance(s): l3_instr, l3_main_1, l3_main_2
*/
@@ -2313,6 +2334,14 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
* Interfaces
*/
+/* l3_main_1 - dmm */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dmm = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_dmm_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_SDMA,
+};
+
/* l3_main_2 - l3_instr */
static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
.master = dra7xx_l3_main_2_hwmod,
@@ -3265,6 +3294,7 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2
= {
};
static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+ dra7xx_l3_main_1__dmm,
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
dra7xx_mpu__l3_main_1,
--
2.3.3
--
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
[PATCHv2 08/10] arm/dts: am57xx-beagle-x15.dts: add HDMI
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
1 file changed, 81 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 03750af3b49a..7184fc16d31e 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -19,6 +19,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+ display0 = hdmi0;
};
memory {
@@ -102,6 +103,51 @@
pinctrl-names = default;
pinctrl-0 = extcon_usb2_pins;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio7 10 GPIO_ACTIVE_HIGH, /* gpio7_10, CT CP HPD
*/
+ gpio6 28 GPIO_ACTIVE_HIGH, /* gpio6_28, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -121,6 +167,13 @@
;
};
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /*
i2c2_sda.hdmi1_ddc_scl */
+ 0x40c (PIN_INPUT | MUX_MODE1) /*
i2c2_scl.hdmi1_ddc_sda */
+ ;
+ };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins =
0x2a4 (PIN_INPUT| MUX_MODE10) /*
mcasp1_aclkx.i2c3_sda */
@@ -277,6 +330,14 @@
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /*
uart1_ctsn.gpio7_24 */
;
};
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10
CT_CP_HPD */
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ 0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28
LS_OE */
+ ;
+ };
};
i2c1 {
@@ -560,3 +621,23 @@
usb2 {
dr_mode = peripheral;
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.3
--
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
[PATCHv2 01/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..0d76233840e6 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1451,6 +1451,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+ ti,set-rate-parent;
};
dss_hdmi_clk: dss_hdmi_clk {
--
2.3.3
--
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
[PATCHv2 05/10] ARM: OMAP2+: display: detect DRA7 DSS
Add platform code to detect DRA7 DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 9868d0bc7805..6ab13d18c636 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -287,6 +287,8 @@ static enum omapdss_version __init
omap_display_get_version(void)
return OMAPDSS_VER_OMAP5;
else if (soc_is_am43xx())
return OMAPDSS_VER_AM43xx;
+ else if (soc_is_dra7xx())
+ return OMAPDSS_VER_DRA7xx;
else
return OMAPDSS_VER_UNKNOWN;
}
@@ -573,6 +575,7 @@ static const char * const omapdss_compat_names[]
__initconst = {
ti,omap3-dss,
ti,omap4-dss,
ti,omap5-dss,
+ ti,dra7-dss,
};
struct device_node * __init omapdss_find_dss_of_node(void)
--
2.3.3
--
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
[PATCHv2 04/10] ARM: OMAP: display: change compat names to array
Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index f492ae147c6a..9868d0bc7805 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -568,25 +568,24 @@ void __init omapdss_early_init_of(void)
}
+static const char * const omapdss_compat_names[] __initconst = {
+ ti,omap2-dss,
+ ti,omap3-dss,
+ ti,omap4-dss,
+ ti,omap5-dss,
+};
+
struct device_node * __init omapdss_find_dss_of_node(void)
{
struct device_node *node;
+ int i;
- node = of_find_compatible_node(NULL, NULL, ti,omap2-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap3-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap4-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap5-dss);
- if (node)
- return node;
+ for (i = 0; i ARRAY_SIZE(omapdss_compat_names); ++i) {
+ node = of_find_compatible_node(NULL, NULL,
+ omapdss_compat_names[i]);
+ if (node)
+ return node;
+ }
return NULL;
}
--
2.3.3
--
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
[PATCHv2 09/10] arm: dra7: add DESHDCP clock
Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
drivers/clk/ti/clk-7xx.c | 1 +
4 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 312ede660b23..c06f30a76f5c 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -123,6 +123,11 @@
regulator-max-microvolt
= 300;
};
};
+
+ scm_conf_clocks: clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 0d76233840e6..a93754cf5e2f 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2057,3 +2057,13 @@
clocks = dpll_usb_ck;
};
};
+
+scm_conf_clocks {
+ dss_deshdcp_clk: dss_deshdcp_clk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = l3_iclk_div;
+ ti,bit-shift = 0;
+ reg = 0x558;
+ };
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0411b838b4fa..97e3d7a62729 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -459,6 +459,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = video2_clk, .clk = dss_video2_clk },
{ .role = video1_clk, .clk = dss_video1_clk },
{ .role = hdmi_clk, .clk = dss_hdmi_clk },
+ { .role = hdcp_clk, .clk = dss_deshdcp_clk },
};
static struct omap_hwmod dra7xx_dss_hwmod = {
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index ee32f4deebf4..7b859ec31a14 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -301,6 +301,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(48824000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(48826000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(NULL, sys_clkin, sys_clkin1),
+ DT_CLK(NULL, dss_deshdcp_clk, dss_deshdcp_clk),
{ .node_name = NULL },
};
--
2.3.3
--
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
[PATCHv2 03/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods
Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index c236ea9bb940..0411b838b4fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -521,6 +521,7 @@ static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
},
},
.dev_attr = dss_dispc_dev_attr,
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
@@ -562,6 +563,7 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
--
2.3.3
--
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 09/21] drm/omap: handle mismatching color format and buffer width
On 02/03/15 12:22, Daniel Stone wrote:
I don't know why Rob named it like that. The bpp of the stride? Shrug.
It's just the bpp of the pixel format; it's not at all associated with
the stride?
The comment says this times width is stride, so I thought the naming comes
from that train of thought. But I agree, it's just bpp.
Here's updated patch:
From af0db526ae274d47488ec49577365909eb8f629d Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 25 Sep 2014 19:24:28 +
Subject: [PATCH] drm/omap: handle incompatible buffer stride and pixel size
omapdrm doesn't check if the pitch of the framebuffer and the color
format's bits-per-pixel are compatible. omapdss requires that the stride
of a buffer is an integer number of pixels
For example, when using modetest with a display that has x resolution of
1280, and using packed 24 RGB mode (3 bytes per pixel), modetest
allocates a buffer with a byte stride of 4 * 1280 = 5120. But 5120 / 3 =
1706.666... pixels, which causes wrong colors and a tilt on the screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Note: this is not a HW requirement at least for non-rotation use cases,
but a SW driver requirement. In the future we should study if also
rotation use cases are fine with any stride size, and if so, change the
driver to allow these strides.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..e123b4dee670 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (pitch % format-planes[i].stride_bpp != 0) {
+ dev_err(dev-dev,
+ buffer pitch (%d bytes) is not a multiple of
pixel size (%d bytes)\n,
+ pitch, format-planes[i].stride_bpp);
+ ret = -EINVAL;
+ goto fail;
+ }
+
size = pitch * mode_cmd-height / format-planes[i].sub_y;
if (size (omap_gem_mmap_size(bos[i]) - mode_cmd-offsets[i]))
{
--
2.3.1
signature.asc
Description: OpenPGP digital signature
Re: [PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI
On 26/02/15 16:55, Jyri Sarha wrote:
Use new binding for the external tda19988 HDMI encoder.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@
lcdc {
status = okay;
+ port {
+ lcdc_0: endpoint@0 {
+ remote-endpoint = hdmi_0;
+ };
+ };
};
-/ {
- hdmi {
- compatible = ti,tilcdc,slave;
- i2c = i2c0;
+i2c0 {
+ tda19988 {
+ compatible = nxp,tda998x;
+ reg = 0x70;
pinctrl-names = default, off;
pinctrl-0 = nxp_hdmi_bonelt_pins;
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
- status = okay;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = lcdc_0;
+ };
+ };
};
};
This is missing the output of tda998x. It should have two ports, input
and output, output going to hdmi-connector.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH RFC 4/6] drm/tilcdc: Add DRM_TILCDC_INIT for ti,tilcdc,slave binding support
On 26/02/15 16:55, Jyri Sarha wrote: Adds a DRM_TILCDC_INIT module for ti,tilcdc,slave node conversion. The implementation is in tilcdc_boot_init.c and it uses tilcdc_slave_convert.dts as a basis for creating a DTS overlay. The DTS overlay adds an external tda998x encoder to tilcdc that corresponds to the old tda998x based slave encoder. Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/gpu/drm/tilcdc/Kconfig | 6 + drivers/gpu/drm/tilcdc/Makefile | 2 + drivers/gpu/drm/tilcdc/tilcdc_boot_init.c | 270 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts | 70 ++ 4 files changed, 348 insertions(+) create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts All this is needed to support the old bindings, right? So I would suggest scratching DRM_TILCDC_INIT, and create DRM_TILCDC_COMPAT_SLAVE or whatever, which would be a user visible option, enabled by default. This way one can just disable all this compatibility stuff if it's not needed. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH RFC 1/6] drm/tilcdc: Fix module unloading
On 26/02/15 16:55, Jyri Sarha wrote:
Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
}
+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
- WARN_ON(tilcdc_crtc-dpms == DRM_MODE_DPMS_ON);
+ tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(tilcdc_crtc-unref_work);
Looks fine to me, but makes me wonder what is the proper way to handle
this. I would presume that every DRM driver needs to shut down the
display HW when it's being unloaded.
And the current WARN_ON suggests that something is supposed to turn the
crtc off before it is destroyed. So either the tilcdc module unload has
never worked, or something has changed in the drm framework (or maybe
tilcdc).
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 09/21] drm/omap: handle mismatching color format and buffer width
On 27/02/15 16:40, Daniel Stone wrote:
Hi,
On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
omapdrm doesn't check if the width of the framebuffer and the color
s/width/pitch/
format's bits-per-pixel match.
s/match/are compatible/
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
Might be clearer to say 'i.e. byte stride of ...', and also s/with using/for/.
Above you said pitch, here you say stride. They are the same thing, right?
a 24 bits per pixel color format, leads to the following mismatch:
5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
s/bytes/pixels/
screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
width is in pixels. No idea what you're trying to check here, but this
probably isn't it.
Yep, I don't know what I was smoking when writing the patch...
stride_bpp is very misnamed: it is the bits per pixel for that plane,
and not stride at all. I think the check should in fact be be (pitch %
I don't know why Rob named it like that. The bpp of the stride? Shrug.
format-planes[i].stride_bpp), which would achieve the desired result,
i.e. that the stride can be expressed as an integer number of pixels.
Yes, that looks correct.
Also drm checks that things fit into the specified pitch (which is in
bytes), see the pichtes[i] width * cpp check in framebuffer_check.
This isn't that check. At some stages, OMAP IIRC requires pitch to be
specified in pixels rather than bytes, so this makes sure that's
possible to express.
Right, that's what this patch was trying to achieve.
However... After thinking about this and going through some of the DISPC
code, I think that's not a strict requirement. We do calculate all the
configs using pixels as units, so at the moment the stride has to be an
integer number of pixels. But the hardware actually takes the row-inc
and pix-inc as bytes.
That said, the HW supports features like rotation and whatnot, and it
was not clear with a quick study if there are corner cases where the
hardware also requires the stride to be an integer number of pixels.
Also, the HW documentation only talks about pixels in this context, even
if the final value written to the registers is in bytes. I don't know if
that's just to make the documentation simpler, or if there's some
reasoning to only use pixel units.
So I think for the time being I'll just fix this patch, and look at the
possibility of allowing any stride size in the future.
Thanks for the review!
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder
On 26/02/15 16:55, Jyri Sarha wrote:
Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The support has only
been tested with tda998x encoder, but other encoders should work too
with a little tweaking.
I got the idea and some lines of code from Jean-Francois Moine's
drm/tilcdc: Change the interface with the tda998x driver-patch.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
snip
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
new file mode 100644
index 000..7254151
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ */
+#define DEBUG 1
You probably didn't mean to include this.
+
+#include linux/component.h
+#include linux/of_graph.h
+
+#include tilcdc_drv.h
+#include tilcdc_external.h
+
+static const struct tilcdc_panel_info panel_info_defaults = {
+ .ac_bias= 255,
+ .ac_bias_intrpt = 0,
+ .dma_burst_sz = 16,
+ .bpp= 16,
+ .fdd= 0x80,
+ .tft_alt_mode = 0,
+ .invert_pxl_clk = 1,
+ .sync_edge = 1,
+ .sync_ctrl = 1,
+ .raster_order = 0,
+};
+
+static int tilcdc_add_external_encoder(struct drm_device *dev, int *bpp,
+struct drm_connector *connector)
+{
+ struct tilcdc_drm_private *priv = dev-dev_private;
+
+ priv-connectors[priv-num_connectors++] = connector;
+ priv-encoders[priv-num_encoders++] = connector-encoder;
+
+ tilcdc_crtc_set_simulate_vesa_sync(priv-crtc, true);
+ tilcdc_crtc_set_panel_info(priv-crtc, panel_info_defaults);
Setting of the simulate vesa sync and the panel info here look a bit
like a hack to me. Both of them are for tda998x, not defaults.
So... I don't know. You could state that at the moment tilcdc only
supports tda998x as an external encoder. Then the above would be ok, but
still it would be good to clearly state this in the desc, comments and
variable names.
Doing this properly may be more difficult. Some parameters should be
defined in the .dts, some should probably come from tda998x driver, and
some should be deduced by tilcdc driver internally.
+ *bpp = panel_info_defaults.bpp;
+
+ dev_info(dev-dev, External encoder '%s' connected\n,
+ connector-encoder-name);
This and the other dev_info in this patch look more like dev_dbg to me.
+
+ return 0;
+}
+
+
+int tilcdc_add_external_encoders(struct drm_device *dev, int *bpp)
+{
+ struct tilcdc_drm_private *priv = dev-dev_private;
+ struct drm_connector *connector;
+ int num_internal_connectors = priv-num_connectors;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ bool found = false;
+ int i, ret;
+
+ for (i = 0; i num_internal_connectors; i++)
+ if (connector == priv-connectors[i])
+ found = true;
+ if (!found) {
+ ret = tilcdc_add_external_encoder(dev, bpp, connector);
+ if (ret)
+ return ret;
+ }
+ }
+ if (priv-num_connectors - num_internal_connectors 1) {
+ dev_err(dev-dev, Only one external encoder is supported.);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev-of_node == data;
+}
+
+int tilcdc_add_external_components(struct device *master,
+struct master *m)
+{
+ struct device_node *ep = NULL;
+
+ while ((ep = of_graph_get_next_endpoint(master-of_node, ep))) {
+ struct device_node *node;
+ int ret;
+
+ node = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
Note that there's an unmerged series Add of-graph helpers to loop over
endpoints and find ports by id from Philipp which changes the behavior
of of_graph_get_next_endpoint.
+ if (!node || !of_device_is_available(node))
+ continue;
Should you of_node_put(node) if node != NULL above?
+
+ dev_info(master, Subdevice node '%s' found\n, node-name);
+ ret = component_master_add_child(m, of_dev_node_match, node);
+ of_node_put(node);
+ if (ret) {
Re: [PATCH RFC 5/6] drm/tilcdc: Force building of DRM_TILCDC_INIT
On 26/02/15 16:55, Jyri Sarha wrote: If I read Documentation/kbuild/makefiles.txt section 3.6 right, this patch should not be needed. However, without this patch the objects needed for DRM_TILCDC_INIT are not linked, if DRM_TILCDC is built as module. I also think there's something funny either with the documentation or the kernel build system. To summarize (Jyri correct me if I'm wrong): We enter tilcdc directory using obj-$(CONFIG_DRM_TILCDC), and CONFIG_DRM_TILCDC is either y or m. Inside the directory we have the necessary makefile and code to build the driver as module or built-in. And this works fine. But now Jyri added new piece of code to tilcdc directory, which is always built-in, even if the tilcdc driver itself is a module. So now if we enter the directory with obj-m, and inside the tilcdc/Makefile we do obj-y += foo.o line, the result is that foo.o is compiled, but it is not linked either to the kernel image nor to the tilcdc.ko. The doc says: Kbuild only uses this information to decide that it needs to visit the directory, it is the Makefile in the subdirectory that specifies what is modular and what is built-in. which doesn't seem to work for us. Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/gpu/drm/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..62c6158 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ +obj-$(CONFIG_DRM_TILCDC_INIT)+= tilcdc/ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ obj-$(CONFIG_DRM_MSM) += msm/ I don't think the above is right. You add two rules for tilcdc directory. I presume you meant to replace the current tilcdc line with the new one? But I don't think the new line makes sense. Using obj-$(CONFIG_DRM_TILCDC) above makes sense, and also obj-y makes sense, but obj-$(CONFIG_DRM_TILCDC_INIT) doesn't. So I think it should be just obj-y, if obj-$(CONFIG_DRM_TILCDC) does not work. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 06/21] drm/omap: check CRTC color format earlier
On 27/02/15 14:07, Daniel Vetter wrote:
On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 1f4f2b866379..bedd6f7af0f1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+int i;
+
+/*
+ * Check whether this plane supports the fb pixel format.
+ * I don't think this should really be needed, but it looks like the
+ * drm core only checks the format for planes, not for the crtc. So
+ * when setting the format for crtc, without this check we would
+ * get an error later when trying to program the color format into the
+ * HW.
+ */
I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.
Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
Laurent is working on universal planes and atomic modesetting for
omapdrm. In fact, I think universal planes is already done in his WIP
branch.
So, if this check is already done with universal planes (if I understood
correctly), I'm fine with dropping this patch.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 14/21] drm/omap: stop connector polling during suspend
On 26/02/15 15:57, grygorii.stras...@linaro.org wrote: Could I ask you to update this patch as below, pls? Your changes look ok to me, but they are not related to my patch so I don't see any reason to merge them. I'll pick your patch to my series. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH RFC 0/6] Use DRM component API in tilcdc to connect to tda998x
Hi Rob, You weren't cc'd to this series. I don't know if you're still interested in tilcdc, but if you are, any comments appreciated =). Tomi On 26/02/15 16:55, Jyri Sarha wrote: Remove tilcdc slave support and connect to tda998x trough its component DRM API. For dtb backward compatibility the code creates at boot time a DT overlay based on the earlier binding. The overlay conforms to the new graph based binding. The first patch is just a bugfix and can be applied or dropped independenty. Jyri Sarha (6): drm/tilcdc: Fix module unloading drm/tilcdc: Remove tilcdc slave support for tda998x driver drm/tilcdc: Add support for external compontised DRM encoder drm/tilcdc: Add DRM_TILCDC_INIT for ti,tilcdc,slave binding support drm/tilcdc: Force building of DRM_TILCDC_INIT ARM: dts: am335x-boneblack: Use new binding for HDMI .../devicetree/bindings/drm/tilcdc/slave.txt | 18 - .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 27 ++ arch/arm/boot/dts/am335x-boneblack.dts | 20 +- drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/tilcdc/Kconfig | 6 + drivers/gpu/drm/tilcdc/Makefile| 4 +- drivers/gpu/drm/tilcdc/tilcdc_boot_init.c | 270 ++ drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 36 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c| 69 ++-- drivers/gpu/drm/tilcdc/tilcdc_drv.h| 3 +- drivers/gpu/drm/tilcdc/tilcdc_external.c | 105 ++ drivers/gpu/drm/tilcdc/tilcdc_external.h | 24 ++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 411 - drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 -- drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts| 70 15 files changed, 601 insertions(+), 489 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts signature.asc Description: OpenPGP digital signature
Re: [PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI
On 02/03/15 18:06, Russell King - ARM Linux wrote: This is missing the output of tda998x. It should have two ports, input and output, output going to hdmi-connector. We don't have that kind of level of modelling in DRM right now - as far as DRM is concerned, the tda998x is both the encoder _and_ the connector since it supplies both functionalities. That's fine, but these are DT bindings which should reflect the hardware, not the SW stack. We did discuss this ages ago, but afaik no concensus was reached how to model physical connectors in DT, so it never moved forward in DRM (and I don't know about consensus, but omapdss is using connectors in DT, and they were discussed in lists, and everyone seemed to be ok with that model (Documentation/devicetree/bindings/video/hdmi-connector.txt). If I recall right, the only real question was how the links should be modeled (two way, one way, something else), but that's not specific to connectors. So while it's open how they should be implemented in the DRM, I don't see why we couldn't/shouldn't specify them in the .dts. That said, if and when DRM supports connectors defined in .dts, we can just assume that if tda998x does not have an output defined in the .dts, it's connected to a HDMI connector. So we should do just fine even if we end up not defining the connectors at this time. besides, everyone seems to be off doing their own thing when it comes to writing DT descriptions for video hardware.) Yep... I've been trying to push the video ports/endpoints system which afaik covers about all the use cases that have been raised. But the counter argument usually is that it's too complex. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI
On 02/03/15 19:42, Russell King - ARM Linux wrote: On Mon, Mar 02, 2015 at 07:08:39PM +0200, Tomi Valkeinen wrote: On 02/03/15 18:06, Russell King - ARM Linux wrote: This is missing the output of tda998x. It should have two ports, input and output, output going to hdmi-connector. We don't have that kind of level of modelling in DRM right now - as far as DRM is concerned, the tda998x is both the encoder _and_ the connector since it supplies both functionalities. That's fine, but these are DT bindings which should reflect the hardware, not the SW stack. I still don't buy your argument. The principle is right, but I think you're taking it too far. snip When we say DT should follow the hardware we're not talking about making DT be an alternative to the hardware's schematic. I agree, and that's not what I'm suggesting. We should only model HW in the DT when it makes sense, when it gives us something. A HDMI connector can have (at least) two functionalities that the driver for it may need to handle: HPD and +5V. On some SoCs/boards those are handled by the HDMI encoder, but I have boards where they are not. So we need to have the data somewhere, and a HDMI connector node at the end of the video path is a logical choice. The HDMI connector node is also a good place for a symbolic name which can be shown to the user. In this particular board, the HDMI encoder handles the HPD and the +5V is always enabled, so there's no strict need to have the HDMI connector node. However, I still feel it's better to have the HDMI connector in .dts: 1) It's not said that a HDMI encoder always has a HDMI connector as the next component. The next component could be a integrated panel, needing a specific driver and there's no HDMI connector at all. Or there could be something else, as is the case on some OMAP boards which have an ESD protection chip (that requires controlling, i.e. a driver) between the encoder and the connector. 2) I like that the beginning and the end of the video pipeline are clearly defined. A video pipeline starts at a display controller, and ends at a panel or a connector. This makes it easier to understand the .dts as you know what to expect. In the SW side these mean that every encoder (or whatever is doing this stuff) should be able to handle any component after the encoder, be it a connector, panel or something else. If we allow leaving out the connector node, the code also needs to handle the case when there's nothing after the encoder, which probably means fabricating some connector data (at least if and when DRM can handle arbitrary video pipelines). But as I said earlier, we can do just fine without the HDMI connector node on boards where the connector just works. We can handle that in the drivers with some extra code. So if people think it's a big chore to add the connectors and don't see the benefit in them (and they don't want the symbolic labels that could be added there), I'm fine with having them optional. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] OMAPDSS: restore name sysfs entry.
Hi, On 24/02/15 11:37, NeilBrown wrote: commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b OMAPDSS: rename display-sysfs 'name' entry broke the xorg X server on my device as it couldn't find the display any more. It needs the 'name' file and now there isn't one. That commit claims that 'name' is not compatible with i2c or spi. i2c does register it own 'name' file, but spi does not, hence my problem - I have an spi display. So create a special case for i2c: add the name attribute for non-i2c devices. What X driver is that? What's it doing with the display name? Is it just using the display name to show something for the user, and the returned value can be essentially any string? Tomi signature.asc Description: OpenPGP digital signature
[PATCH 06/21] drm/omap: check CRTC color format earlier
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 1f4f2b866379..bedd6f7af0f1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+ int i;
+
+ /*
+* Check whether this plane supports the fb pixel format.
+* I don't think this should really be needed, but it looks like the
+* drm core only checks the format for planes, not for the crtc. So
+* when setting the format for crtc, without this check we would
+* get an error later when trying to program the color format into the
+* HW.
+*/
+ for (i = 0; i plane-format_count; i++)
+ if (fb-pixel_format == plane-format_types[i])
+ break;
+ if (i == plane-format_count) {
+ DBG(Invalid pixel format %s,
+ drm_get_format_name(fb-pixel_format));
+ return -EINVAL;
+ }
win-crtc_x = crtc_x;
win-crtc_y = crtc_y;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/21] drm/omap: fix race condition with dev-obj_list
omap_gem_objects are added to dev-obj_list in omap_gem_new, and removed
in omap_gem_free_object. Unfortunately there's no locking for
dev-obj_list, which eventually leads to a crash:
WARNING: CPU: 1 PID: 1123 at lib/list_debug.c:59 __list_del_entry+0xa4/0xe0()
list_del corruption. prev-next should be e9281344, but was ea722b84
Add a spinlock to protect dev-obj_list.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
drivers/gpu/drm/omapdrm/omap_drv.h | 3 +++
drivers/gpu/drm/omapdrm/omap_gem.c | 5 +
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index d0b1aece8cc5..2a85221e0604 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -479,6 +479,7 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
priv-wq = alloc_ordered_workqueue(omapdrm, 0);
+ spin_lock_init(priv-list_lock);
INIT_LIST_HEAD(priv-obj_list);
omap_gem_init(dev);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 60e47b33c801..dac9f8ef3b15 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -105,6 +105,9 @@ struct omap_drm_private {
struct workqueue_struct *wq;
+ /* lock for obj_list below */
+ spinlock_t list_lock;
+
/* list of GEM objects: */
struct list_head obj_list;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index d37ee756a0b1..e9718b99a8a9 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1273,13 +1273,16 @@ unlock:
void omap_gem_free_object(struct drm_gem_object *obj)
{
struct drm_device *dev = obj-dev;
+ struct omap_drm_private *priv = dev-dev_private;
struct omap_gem_object *omap_obj = to_omap_bo(obj);
evict(obj);
WARN_ON(!mutex_is_locked(dev-struct_mutex));
+ spin_lock(priv-list_lock);
list_del(omap_obj-mm_list);
+ spin_unlock(priv-list_lock);
drm_gem_free_mmap_offset(obj);
@@ -1377,7 +1380,9 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
if (!omap_obj)
goto fail;
+ spin_lock(priv-list_lock);
list_add(omap_obj-mm_list, priv-obj_list);
+ spin_unlock(priv-list_lock);
obj = omap_obj-base;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/21] drm/omap: clear omap_obj-paddr in omap_gem_put_paddr()
Clear omap_obj's paddr when unmapping the memory, so that it's easier to catch bad use of the paddr. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/gpu/drm/omapdrm/omap_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index aeb91ed653c9..9b250c93b046 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem.c +++ b/drivers/gpu/drm/omapdrm/omap_gem.c @@ -828,6 +828,7 @@ int omap_gem_put_paddr(struct drm_gem_object *obj) dev_err(obj-dev-dev, could not release unmap: %d\n, ret); } + omap_obj-paddr = 0; omap_obj-block = NULL; } } -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/21] drm/omap: keep ref to old_fb
We store the fb being page-flipped to 'old_fb' field, but we don't increase the ref count of the fb when doing that. While I am not sure if it can cause problem in practice, it's still safer to keep a ref when storing a pointer to a fb. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/gpu/drm/omapdrm/omap_crtc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c index 4b06c039e9af..faa20fbc2ad9 100644 --- a/drivers/gpu/drm/omapdrm/omap_crtc.c +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c @@ -301,6 +301,7 @@ static void vblank_cb(void *arg) struct drm_device *dev = crtc-dev; struct omap_crtc *omap_crtc = to_omap_crtc(crtc); unsigned long flags; + struct drm_framebuffer *fb; spin_lock_irqsave(dev-event_lock, flags); @@ -308,10 +309,15 @@ static void vblank_cb(void *arg) if (omap_crtc-event) drm_send_vblank_event(dev, omap_crtc-pipe, omap_crtc-event); + fb = omap_crtc-old_fb; + omap_crtc-event = NULL; omap_crtc-old_fb = NULL; spin_unlock_irqrestore(dev-event_lock, flags); + + if (fb) + drm_framebuffer_unreference(fb); } static void page_flip_worker(struct work_struct *work) @@ -368,6 +374,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc, omap_crtc-event = event; omap_crtc-old_fb = primary-fb = fb; + drm_framebuffer_reference(omap_crtc-old_fb); spin_unlock_irqrestore(dev-event_lock, flags); -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/21] drm/omap: fix encoder-crtc mapping
OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.
However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the moment, and has a hardcoded
overlay manager per output.
omapdrm, on the other hand, uses the hardware features to find out which
overlay manager to use for an output, which causes problems. For
example, on OMAP5, omapdrm tries to use DIGIT overlay manager for DPI
output, instead of the LCD3 required by the omapdss driver.
This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 8241ed9b353c..95e0356bf047 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -286,14 +286,13 @@ static int omap_modeset_init(struct drm_device *dev)
for (id = 0; id priv-num_crtcs; id++) {
struct drm_crtc *crtc = priv-crtcs[id];
enum omap_channel crtc_channel;
- enum omap_dss_output_id supported_outputs;
crtc_channel = omap_crtc_channel(crtc);
- supported_outputs =
- dss_feat_get_supported_outputs(crtc_channel);
- if (supported_outputs output-id)
+ if (output-dispc_channel == crtc_channel) {
encoder-possible_crtcs |= (1 id);
+ break;
+ }
}
omap_dss_put_device(output);
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/21] drm/omap: add a comment why locking is missing
unpin_worker() calls omap_framebuffer_unpin() without any locks, which looks very suspicious. However, both pin and unpin are always called via the driver's private workqueue, so the access is synchronized that way. Add a comment to make this clear. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/gpu/drm/omapdrm/omap_plane.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index ee8e2b3a117e..1f4f2b866379 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -71,6 +71,10 @@ static void unpin_worker(struct drm_flip_work *work, void *val) container_of(work, struct omap_plane, unpin_work); struct drm_device *dev = omap_plane-base.dev; + /* +* omap_framebuffer_pin/unpin are always called from priv-wq, +* so there's no need for locking here. +*/ omap_framebuffer_unpin(val); mutex_lock(dev-mode_config.mutex); drm_framebuffer_unreference(val); -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/21] drm/omap: fix TILER on OMAP5
On OMAP5 it is not possible to use TILER buffer with CPU when caching or
write-combining is used. Doing so leads to errors from the memory
manager.
However, on OMAP4, write-combining works fine.
This patch adds platform specific data for the TILER, and a function
tiler_get_cpu_cache_flags() which can be used to get the caching mode to
be used.
Note that without write-combining the use of the TILER buffer with CPU
is unusably slow. It's still good to have it operational for testing
purposes.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 6 +
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 39 ++--
drivers/gpu/drm/omapdrm/omap_dmm_tiler.h | 1 +
drivers/gpu/drm/omapdrm/omap_gem.c | 4 ++--
4 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index 58bcd6ae0255..d96660573076 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -153,6 +153,10 @@ struct refill_engine {
struct list_head idle_node;
};
+struct dmm_platform_data {
+ uint32_t cpu_cache_flags;
+};
+
struct dmm {
struct device *dev;
void __iomem *base;
@@ -183,6 +187,8 @@ struct dmm {
/* allocation list and lock */
struct list_head alloc_head;
+
+ const struct dmm_platform_data *plat_data;
};
#endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 56c60552abba..ef3d14d9cfa1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -39,6 +39,10 @@
static struct tcm *containers[TILFMT_NFORMATS];
static struct dmm *omap_dmm;
+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[];
+#endif
+
/* global spinlock for protecting lists */
static DEFINE_SPINLOCK(list_lock);
@@ -529,6 +533,11 @@ size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w,
uint16_t h)
return round_up(geom[fmt].cpp * w, PAGE_SIZE) * h;
}
+uint32_t tiler_get_cpu_cache_flags(void)
+{
+ return omap_dmm-plat_data-cpu_cache_flags;
+}
+
bool dmm_is_available(void)
{
return omap_dmm ? true : false;
@@ -592,6 +601,18 @@ static int omap_dmm_probe(struct platform_device *dev)
init_waitqueue_head(omap_dmm-engine_queue);
+ if (dev-dev.of_node) {
+ const struct of_device_id *match;
+
+ match = of_match_node(dmm_of_match, dev-dev.of_node);
+ if (!match) {
+ dev_err(dev-dev, failed to find matching device
node\n);
+ return -ENODEV;
+ }
+
+ omap_dmm-plat_data = match-data;
+ }
+
/* lookup hwmod data - base address and irq */
mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
if (!mem) {
@@ -972,9 +993,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
#endif
#if defined(CONFIG_OF)
+static const struct dmm_platform_data dmm_omap4_platform_data = {
+ .cpu_cache_flags = OMAP_BO_WC,
+};
+
+static const struct dmm_platform_data dmm_omap5_platform_data = {
+ .cpu_cache_flags = OMAP_BO_UNCACHED,
+};
+
static const struct of_device_id dmm_of_match[] = {
- { .compatible = ti,omap4-dmm, },
- { .compatible = ti,omap5-dmm, },
+ {
+ .compatible = ti,omap4-dmm,
+ .data = dmm_omap4_platform_data,
+ },
+ {
+ .compatible = ti,omap5-dmm,
+ .data = dmm_omap5_platform_data,
+ },
{},
};
#endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
index 4fdd61e54bd2..e83c78372db8 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
@@ -106,6 +106,7 @@ uint32_t tiler_stride(enum tiler_fmt fmt, uint32_t orient);
size_t tiler_size(enum tiler_fmt fmt, uint16_t w, uint16_t h);
size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w, uint16_t h);
void tiler_align(enum tiler_fmt fmt, uint16_t *w, uint16_t *h);
+uint32_t tiler_get_cpu_cache_flags(void);
bool dmm_is_available(void);
extern struct platform_driver omap_dmm_driver;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 9b250c93b046..d37ee756a0b1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1359,8 +1359,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
/* currently don't allow cached buffers.. there is some caching
* stuff that needs to be handled better
*/
- flags = ~(OMAP_BO_CACHED|OMAP_BO_UNCACHED);
- flags |= OMAP_BO_WC;
+ flags = ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
+ flags |= tiler_get_cpu_cache_flags();
/* align
[PATCH 08/21] drm/omap: fix error handling in omap_framebuffer_create()
When an error happens in omap_framebuffer_create(),
omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb
struct has been allocated. However, that crashes, as
omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(),
should only be called after drm_framebuffer_init()
Fix this by just calling kfree() for the allocated fb when an error
happens.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 58f2af32ede8..2975096abdf5 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -420,7 +420,7 @@ struct drm_framebuffer *omap_framebuffer_create(struct
drm_device *dev,
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos)
{
- struct omap_framebuffer *omap_fb;
+ struct omap_framebuffer *omap_fb = NULL;
struct drm_framebuffer *fb = NULL;
const struct format *format = NULL;
int ret, i, n = drm_format_num_planes(mode_cmd-pixel_format);
@@ -491,8 +491,7 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
return fb;
fail:
- if (fb)
- omap_framebuffer_destroy(fb);
+ kfree(omap_fb);
return ERR_PTR(ret);
}
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/21] drm/omap: add pin refcounting to omap_framebuffer
omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS.
This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2a5cacdc344b..58f2af32ede8 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -86,6 +86,7 @@ struct plane {
struct omap_framebuffer {
struct drm_framebuffer base;
+ int pin_count;
const struct format *format;
struct plane planes[4];
};
@@ -261,6 +262,11 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int ret, i, n = drm_format_num_planes(fb-pixel_format);
+ if (omap_fb-pin_count 0) {
+ omap_fb-pin_count++;
+ return 0;
+ }
+
for (i = 0; i n; i++) {
struct plane *plane = omap_fb-planes[i];
ret = omap_gem_get_paddr(plane-bo, plane-paddr, true);
@@ -269,6 +275,8 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
omap_gem_dma_sync(plane-bo, DMA_TO_DEVICE);
}
+ omap_fb-pin_count++;
+
return 0;
fail:
@@ -287,6 +295,11 @@ int omap_framebuffer_unpin(struct drm_framebuffer *fb)
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int ret, i, n = drm_format_num_planes(fb-pixel_format);
+ omap_fb-pin_count--;
+
+ if (omap_fb-pin_count 0)
+ return 0;
+
for (i = 0; i n; i++) {
struct plane *plane = omap_fb-planes[i];
ret = omap_gem_put_paddr(plane-bo);
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/21] drm/omap: do not use BUG_ON(!spin_is_locked(x))
spin_is_locked(x) returns always 0 on uniprocessor, triggering BUG() in omapdrm. Change it to use assert_spin_locked() to fix the issue. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/gpu/drm/omapdrm/omap_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c b/drivers/gpu/drm/omapdrm/omap_irq.c index f035d2bceae7..3eb097efc488 100644 --- a/drivers/gpu/drm/omapdrm/omap_irq.c +++ b/drivers/gpu/drm/omapdrm/omap_irq.c @@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev) struct omap_drm_irq *irq; uint32_t irqmask = priv-vblank_mask; - BUG_ON(!spin_is_locked(list_lock)); + assert_spin_locked(list_lock); list_for_each_entry(irq, priv-irq_list, node) irqmask |= irq-irqmask; -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/21] drm/omap: only ignore DIGIT SYNC LOST for TV output
We need to ignore DIGIT SYNC LOST error when enabling/disabling TV
output. The code does that, but it ignores the DIGI SYNC LOST when
enabling any output. Normally this does no harm, but it could make us
miss DIGIT SYNC LOST on some rare occasions.
Fix the code to only ignore DIGIT SYNC LOST when enabling/disabling TV.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 2175b9b7c725..4b06c039e9af 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -557,11 +557,13 @@ static void set_enabled(struct drm_crtc *crtc, bool
enable)
if (dispc_mgr_is_enabled(channel) == enable)
return;
- /*
-* Digit output produces some sync lost interrupts during the first
-* frame when enabling, so we need to ignore those.
-*/
- omap_crtc-ignore_digit_sync_lost = true;
+ if (omap_crtc-channel == OMAP_DSS_CHANNEL_DIGIT) {
+ /*
+* Digit output produces some sync lost interrupts during the
+* first frame when enabling, so we need to ignore those.
+*/
+ omap_crtc-ignore_digit_sync_lost = true;
+ }
framedone_irq = dispc_mgr_get_framedone_irq(channel);
vsync_irq = dispc_mgr_get_vsync_irq(channel);
@@ -592,9 +594,11 @@ static void set_enabled(struct drm_crtc *crtc, bool enable)
omap_crtc-name, enable ? enable : disable);
}
- omap_crtc-ignore_digit_sync_lost = false;
- /* make sure the irq handler sees the value above */
- mb();
+ if (omap_crtc-channel == OMAP_DSS_CHANNEL_DIGIT) {
+ omap_crtc-ignore_digit_sync_lost = false;
+ /* make sure the irq handler sees the value above */
+ mb();
+ }
}
static void omap_crtc_pre_apply(struct omap_drm_apply *apply)
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/15] OMAPDSS: HDMI: hdmi synclost work-around
DISPC and HDMI have synchronization issues when enabling or disabling
the output. The symptoms are a lot of sync-lost errors and occasionally
dispc gets stuck and we never get FRAMEDONE when disabling.
Testing has shown that this is somehow related to the time when DISPC's
output gets enabled:
- If DISPC is disabled when HDMI is in vertical blanking area, DISPC
often gets stuck.
- If DISPC is disabled after vertical blanking area, no sync lost errors
are seen.
- If DISPC is enabled right after HDMI VSYNC event, no sync lost errors
are seen.
This patch is a simple work-around for the above issues:
- Before enabling DISPC output, we wait for HDMI VSYNC.
- Before disabling DISPC output, we wait for HDMI VSYNC and VSW+VBP.
This is not perfect WA, as it relies on the enable/disable of DISPC
happening relatively soon after the wait has ended. In practice I
presume there is at least ~10ms timewindow to accomplish the DISPC
enable/disable, which I hope is enough.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 50 +++
drivers/video/fbdev/omap2/dss/hdmi5.c | 50 +++
2 files changed, 100 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 916d47978f41..39cdd164d2ae 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -217,6 +217,26 @@ static int hdmi_power_on_full(struct omap_dss_device
*dssdev)
if (r)
goto err_vid_enable;
+ /*
+* XXX Seems that on we easily get a flood of sync-lost errors when
+* enabling the output. This seems to be related to the time between
+* HDMI VSYNC and enabling the DISPC output.
+*
+* Testing shows that the sync-lost errors do not happen if we enable
+* the DISPC output very soon after HDMI VBLANK. So wait here for
+* VBLANK to reduce the chances of sync-losts.
+*/
+ hdmi_write_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS, HDMI_IRQ_VIDEO_VSYNC);
+
+ while (true) {
+ u32 v = hdmi_read_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS_RAW);
+
+ if (v HDMI_IRQ_VIDEO_VSYNC)
+ break;
+
+ usleep_range(500, 1000);
+ }
+
r = dss_mgr_enable(mgr);
if (r)
goto err_mgr_enable;
@@ -242,9 +262,39 @@ err_pll_enable:
static void hdmi_power_off_full(struct omap_dss_device *dssdev)
{
struct omap_overlay_manager *mgr = hdmi.output.manager;
+ const struct omap_video_timings *t;
+ unsigned vblank;
hdmi_wp_clear_irqenable(hdmi.wp, 0x);
+ /*
+* XXX Seems that on we easily get a flood of sync-lost errors when
+* disabling the output, and sometimes the DISPC seems to get stuck and
+* we never get FRAMEDONE. This seems to happen if we disable DISPC
+* output during HDMI VBLANK.
+*
+* To reduce the possibility for sync-lost errors, calculate the time
+* for the vertical blanking, wait for VBLANK, then wait until VBLANK
+* ends.
+*/
+ t = hdmi.cfg.timings;
+ vblank = t-hfp + t-hsw + t-hbp + t-x_res;
+ vblank *= t-vsw + t-vbp;
+ vblank = (vblank * 1000) / (t-pixelclock / 1000);
+
+ hdmi_write_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS, HDMI_IRQ_VIDEO_VSYNC);
+
+ while (true) {
+ u32 v = hdmi_read_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS_RAW);
+
+ if (v HDMI_IRQ_VIDEO_VSYNC)
+ break;
+
+ usleep_range(500, 1000);
+ }
+
+ usleep_range(vblank, vblank + 1000);
+
dss_mgr_disable(mgr);
hdmi_wp_video_stop(hdmi.wp);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 3f0b34a7031a..65a91ac87a6a 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -234,6 +234,26 @@ static int hdmi_power_on_full(struct omap_dss_device
*dssdev)
if (r)
goto err_vid_enable;
+ /*
+* XXX Seems that on we easily get a flood of sync-lost errors when
+* enabling the output. This seems to be related to the time between
+* HDMI VSYNC and enabling the DISPC output.
+*
+* Testing shows that the sync-lost errors do not happen if we enable
+* the DISPC output very soon after HDMI VBLANK. So wait here for
+* VBLANK to reduce the chances of sync-losts.
+*/
+ hdmi_write_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS, HDMI_IRQ_VIDEO_VSYNC);
+
+ while (true) {
+ u32 v = hdmi_read_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS_RAW);
+
+ if (v HDMI_IRQ_VIDEO_VSYNC)
+ break;
+
+ usleep_range(500, 1000);
+ }
+
r = dss_mgr_enable(mgr);
if (r
[PATCH 15/15] OMAPDSS: disable VT switch
We don't need VT switch when suspending/resuming, so disable it. This speeds up suspend/resume. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: NeilBrown n...@brown.name --- drivers/video/fbdev/omap2/dss/dss.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c index a6d10d4279f3..7f978b6a34e8 100644 --- a/drivers/video/fbdev/omap2/dss/dss.c +++ b/drivers/video/fbdev/omap2/dss/dss.c @@ -38,6 +38,7 @@ #include linux/regmap.h #include linux/of.h #include linux/regulator/consumer.h +#include linux/suspend.h #include video/omapdss.h @@ -1138,6 +1139,8 @@ static int __init omap_dsshw_probe(struct platform_device *pdev) dss_debugfs_create_file(dss, dss_dump_regs); + pm_set_vt_switch(0); + return 0; err_pll_init: -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] OMAPDSS: DISPC: explicit handling for sync and de levels
When configuring the lcd timings, instead of writing enum values
directly to the HW, use switch-case to get the value to be programmed.
This is safer and also allows us to change the enum values.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 41 +++
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 11bd780fcdfa..8805266a52f4 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2915,7 +2915,7 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsw,
{
u32 timing_h, timing_v, l;
- bool onoff, rf, ipc;
+ bool onoff, rf, ipc, vs, hs, de;
timing_h = FLD_VAL(hsw-1, dispc.feat-sw_start, 0) |
FLD_VAL(hfp-1, dispc.feat-fp_start, 8) |
@@ -2927,6 +2927,39 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel
channel, int hsw,
dispc_write_reg(DISPC_TIMING_H(channel), timing_h);
dispc_write_reg(DISPC_TIMING_V(channel), timing_v);
+ switch (vsync_level) {
+ case OMAPDSS_SIG_ACTIVE_LOW:
+ vs = true;
+ break;
+ case OMAPDSS_SIG_ACTIVE_HIGH:
+ vs = false;
+ break;
+ default:
+ BUG();
+ }
+
+ switch (hsync_level) {
+ case OMAPDSS_SIG_ACTIVE_LOW:
+ hs = true;
+ break;
+ case OMAPDSS_SIG_ACTIVE_HIGH:
+ hs = false;
+ break;
+ default:
+ BUG();
+ }
+
+ switch (de_level) {
+ case OMAPDSS_SIG_ACTIVE_LOW:
+ de = true;
+ break;
+ case OMAPDSS_SIG_ACTIVE_HIGH:
+ de = false;
+ break;
+ default:
+ BUG();
+ }
+
switch (data_pclk_edge) {
case OMAPDSS_DRIVE_SIG_RISING_EDGE:
ipc = false;
@@ -2954,10 +2987,10 @@ static void _dispc_mgr_set_lcd_timings(enum
omap_channel channel, int hsw,
l = FLD_VAL(onoff, 17, 17) |
FLD_VAL(rf, 16, 16) |
- FLD_VAL(de_level, 15, 15) |
+ FLD_VAL(de, 15, 15) |
FLD_VAL(ipc, 14, 14) |
- FLD_VAL(hsync_level, 13, 13) |
- FLD_VAL(vsync_level, 12, 12);
+ FLD_VAL(hs, 13, 13) |
+ FLD_VAL(vs, 12, 12);
dispc_write_reg(DISPC_POL_FREQ(channel), l);
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/15] OMAPDSS: DISPC: lock access to DISPC_CONTROL DISPC_CONFIG
Dispc driver presumes that the callers handle locking for all normal
functions. However, omapdrm doesn't handle this, and presumes that all
overlay manager registers are private to that overlay manager, and thus
presumes that configurations for overlay managers can be written via
different threads freely.
For many registers the above is true. The exceptions are DISPC_CONTROL
and DISPC_CONFIG registers, which contain bits for both LCD and TV
overlay managers.
Fixing this properly in omapdrm means a big omapdrm rewrite. So, for
now, add locking to dispc for the problematic registers.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Somnath Mukherjee somn...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 1123111d3940..766c985cbfa7 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -123,6 +123,9 @@ static struct {
struct regmap *syscon_pol;
u32 syscon_pol_offset;
+
+ /* DISPC_CONTROL DISPC_CONFIG lock*/
+ spinlock_t control_lock;
} dispc;
enum omap_color_component {
@@ -261,7 +264,16 @@ static u32 mgr_fld_read(enum omap_channel channel, enum
mgr_reg_fields regfld)
static void mgr_fld_write(enum omap_channel channel,
enum mgr_reg_fields regfld, int val) {
const struct dispc_reg_field rfld = mgr_desc[channel].reg_desc[regfld];
+ const bool need_lock = rfld.reg == DISPC_CONTROL || rfld.reg ==
DISPC_CONFIG;
+ unsigned long flags;
+
+ if (need_lock)
+ spin_lock_irqsave(dispc.control_lock, flags);
+
REG_FLD_MOD(rfld.reg, val, rfld.high, rfld.low);
+
+ if (need_lock)
+ spin_unlock_irqrestore(dispc.control_lock, flags);
}
#define SR(reg) \
@@ -3804,6 +3816,8 @@ static int __init omap_dispchw_probe(struct
platform_device *pdev)
dispc.pdev = pdev;
+ spin_lock_init(dispc.control_lock);
+
r = dispc_init_features(dispc.pdev);
if (r)
return r;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] OMAPDSS: workaround for MFLAG + NV12 issue
It was found that having two displays enabled and having an NV12 overlay
on one of the displays will cause underflows/synclosts. Debugging this
pointed to some issue with MFLAG.
It is unclear why this issue is happening, but it looks like there is a
HW bug related to MFLAG and FIFO management. Disabling MFLAG makes this
issue go away, but then we lose the benefit of MFLAG. Also forcing MFLAG
always on makes the issue go away.
Also, using certain values for MFLAG_START, MFLAG thresholds and PRELOAD
makes the issue go away, but there was no obvious logic to which values
work and which don't.
As a workaround until more information about this is found, force MFLAG
always on to make NV12 usable.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 6b056d0ce187..f4fc77d9d3bf 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -1328,8 +1328,18 @@ static void dispc_init_mflag(void)
{
int i;
+ /*
+* HACK: NV12 color format and MFLAG seem to have problems working
+* together: using two displays, and having an NV12 overlay on one of
+* the displays will cause underflows/synclosts when MFLAG_CTRL=2.
+* Changing MFLAG thresholds and PRELOAD to certain values seem to
+* remove the errors, but there doesn't seem to be a clear logic on
+* which values work and which not.
+*
+* As a work-around, set force MFLAG to always on.
+*/
dispc_write_reg(DISPC_GLOBAL_MFLAG_ATTRIBUTE,
- (2 0) | /* MFLAG_CTRL = enable */
+ (1 0) | /* MFLAG_CTRL = force always on */
(0 2)); /* MFLAG_START = disable */
for (i = 0; i dss_feat_get_num_ovls(); ++i) {
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] OMAPDSS: DISPC: change sync_pclk_edge default value
The common 'struct videomode' does not have a flag to select when the sync signals should be driven. The default behavior of DISPC HW is to drive the sync signal on the opposite pixel clock edge from data signal, which is also what the videomode_to_omap_video_timings() uses. However, it looks like what panels usually expect is that the data and sync signals are driven on the same edge, so let's change videomode_to_omap_video_timings() to set the sync_pclk_edge accordingly. Note that this only affect panels drivers that use videomode_to_omap_video_timings(), probably when getting the video timings directly from DT data. The drivers can still configure the sync_pclk_edge independently if they so wish. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/display.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/display.c b/drivers/video/fbdev/omap2/dss/display.c index a6fd2d35ad60..ef5b9027985d 100644 --- a/drivers/video/fbdev/omap2/dss/display.c +++ b/drivers/video/fbdev/omap2/dss/display.c @@ -295,9 +295,7 @@ void videomode_to_omap_video_timings(const struct videomode *vm, OMAPDSS_DRIVE_SIG_RISING_EDGE : OMAPDSS_DRIVE_SIG_FALLING_EDGE; - ovt-sync_pclk_edge = vm-flags DISPLAY_FLAGS_PIXDATA_POSEDGE ? - OMAPDSS_DRIVE_SIG_FALLING_EDGE : - OMAPDSS_DRIVE_SIG_RISING_EDGE; + ovt-sync_pclk_edge = ovt-data_pclk_edge; } EXPORT_SYMBOL(videomode_to_omap_video_timings); -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] OMAPDSS: setup default fifo thresholds
At the moment we don't setup FIFO thresholds by default in omapdss. It's
supposed to be done by the user of omapdss. And that is missing from
omapdrm, causing unoptimal thresholds to be used when using omapdrm.
While I believe it's in theory better to allow the user of omapdss to
setup the fifo thresholds, in practice we always use the same values,
and we could as well setup the thresholds in omapdss.
Furthermore, in omapdss init we always swap the FIFO used for GFX and WB
overlays, but we don't swap the FIFO thresholds for those overlays
(which is the reason for omapdrm using unoptimal HW reset values). So
it would make sense to setup the thresholds to account for the swapping
of the FIFOs.
So, this patch adds code to setup default FIFO tresholds at omapdss
init.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 766c985cbfa7..6296a3e5124f 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -1138,6 +1138,7 @@ static void dispc_init_fifos(void)
int fifo;
u8 start, end;
u32 unit;
+ int i;
unit = dss_feat_get_buffer_size_unit();
@@ -1177,6 +1178,20 @@ static void dispc_init_fifos(void)
dispc.fifo_assignment[OMAP_DSS_GFX] = OMAP_DSS_WB;
dispc.fifo_assignment[OMAP_DSS_WB] = OMAP_DSS_GFX;
}
+
+ /*
+* Setup default fifo thresholds.
+*/
+ for (i = 0; i dss_feat_get_num_ovls(); ++i) {
+ u32 low, high;
+ const bool use_fifomerge = false;
+ const bool manual_update = false;
+
+ dispc_ovl_compute_fifo_thresholds(i, low, high,
+ use_fifomerge, manual_update);
+
+ dispc_ovl_set_fifo_threshold(i, low, high);
+ }
}
static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] OMAPDSS: TFP410: fix input sync signals
TFP410 requires that DE is active high and the data and syncs are driven
on rising pixel clock edge. However, at the moment the driver doesn't
request such syncs, and the end result is that the sync settings depend
on default values, which are not right in all cases.
Set the sync values explicitly.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
b/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
index 92919a74e715..d9048b3df495 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
@@ -114,12 +114,21 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
}
+static void tfp410_fix_timings(struct omap_video_timings *timings)
+{
+ timings-data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
+ timings-sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
+ timings-de_level = OMAPDSS_SIG_ACTIVE_HIGH;
+}
+
static void tfp410_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata-in;
+ tfp410_fix_timings(timings);
+
ddata-timings = *timings;
dssdev-panel.timings = *timings;
@@ -140,6 +149,8 @@ static int tfp410_check_timings(struct omap_dss_device
*dssdev,
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata-in;
+ tfp410_fix_timings(timings);
+
return in-ops.dpi-check_timings(in, timings);
}
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] OMAPDSS: fix paddr check for TILER addresses
The DISPC driver checks that the buffer address is not 0. However, when using TILER, the address space is TILER specific and 0 is a valid address. Fix the check to allow address of 0 for TILER. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: srinivas pulukuru srinivas.puluk...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index 31b743c70272..a19a1d4b2d19 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2441,7 +2441,7 @@ static int dispc_ovl_setup_common(enum omap_plane plane, unsigned long pclk = dispc_plane_pclk_rate(plane); unsigned long lclk = dispc_plane_lclk_rate(plane); - if (paddr == 0) + if (paddr == 0 rotation_type != OMAP_DSS_ROT_TILER) return -EINVAL; out_width = out_width == 0 ? width : out_width; -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] OMAPDSS: DISPC: remove OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES
DISPC can drive data lines either on rising or falling pixel clock edge,
which can be configured by the user.
Sync lines can also be driven on rising or falling pixel clock edge, but
additionally the HW can be configured to drive the sync lines on
opposite clock edge from the data lines.
This opposite edge setting does not make any sense, as the same effect
can be achieved by just setting the sync lines to be driven on the other
edge compared to the data lines. It feels like some kind of backward
compatibility option, even if all DSS versions seem to have the same
implementation.
To simplify the code and configuration of the signals, and to make the
dispc timings more compatible with what is used on other platforms,
let's just remove the whole opposite-edge support.
The drivers that used OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES setting are
changed so that they use the opposite setting from the data edge.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_connector.c | 2 +-
drivers/video/fbdev/omap2/displays-new/connector-dvi.c | 2 +-
.../video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c | 2 +-
.../video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c | 2 +-
drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 2 +-
drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c | 2 +-
drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c | 2 +-
drivers/video/fbdev/omap2/dss/dispc.c | 10 +++---
drivers/video/fbdev/omap2/dss/display.c| 4 +++-
drivers/video/fbdev/omap2/dss/dsi.c| 2 +-
drivers/video/fbdev/omap2/dss/rfbi.c | 2 +-
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 ++--
include/video/omapdss.h| 1 -
13 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index a94b11f7859d..2c2173bc3f00 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -102,7 +102,7 @@ void copy_timings_drm_to_omap(struct omap_video_timings
*timings,
timings-data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
timings-de_level = OMAPDSS_SIG_ACTIVE_HIGH;
- timings-sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
+ timings-sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE;
}
static enum drm_connector_status omap_connector_detect(
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
index 0cdc97413020..a8ce920fa797 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
@@ -37,7 +37,7 @@ static const struct omap_video_timings dvic_default_timings =
{
.hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
- .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
};
struct panel_drv_data {
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
index 27d4fcfa1824..9974a37a11af 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
@@ -37,7 +37,7 @@ static struct omap_video_timings lb035q02_timings = {
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
- .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
};
struct panel_drv_data {
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index 18b19b6e1ac2..eae263702964 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -54,7 +54,7 @@ static const struct omap_video_timings sharp_ls_timings = {
.hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
.data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
.de_level = OMAPDSS_SIG_ACTIVE_HIGH,
- .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
index 337ccc5c0f5e..90cbc4c3406c 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sony
[PATCH 02/15] OMAPDSS: HDMI5: Increase DDC SDA-HOLD time
It has been observed that the current SDA-HOLD time is too short for some board/cable/monitor combinations. Increase the SDA-HOLD time to 1000ns. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index a3cfe3d708f7..bfc0c4c297d6 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -55,7 +55,7 @@ static void hdmi_core_ddc_init(struct hdmi_core_data *core) const unsigned ss_scl_low = 4700; /* ns */ const unsigned fs_scl_high = 600; /* ns */ const unsigned fs_scl_low = 1300; /* ns */ - const unsigned sda_hold = 300; /* ns */ + const unsigned sda_hold = 1000; /* ns */ const unsigned sfr_div = 10; unsigned long long sfr; unsigned v; -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] OMAPDSS: fix AM43xx minimum pixel clock divider
AM43xx supports pixel clock divider of 1, just like all OMAP3+ SoCs. Fix
the minimum divider value.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss_features.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss_features.c
b/drivers/video/fbdev/omap2/dss/dss_features.c
index 376270b777f8..b0b6dfd657bf 100644
--- a/drivers/video/fbdev/omap2/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/dss/dss_features.c
@@ -440,7 +440,7 @@ static const struct dss_param_range omap3_dss_param_range[]
= {
static const struct dss_param_range am43xx_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK]= { 0, 2 },
- [FEAT_PARAM_DSS_PCD]= { 2, 255 },
+ [FEAT_PARAM_DSS_PCD]= { 1, 255 },
[FEAT_PARAM_DOWNSCALE] = { 1, 4 },
[FEAT_PARAM_LINEWIDTH] = { 1, 1024 },
};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/15] OMAPDSS: DISPC: fix div by zero issue in overlay scaling
omapdrm doesn't always configure the overlays correctly, causing the
overlay setup functions to be called with zero timings. This leads to
division by zero error.
This happens, for example, when a HDMI cable is not connected, but a
user tries to setup a plane with scaling.
Fixing omapdrm is a big job, so for now let's check for the bad timings
in DISPC and return an error.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 8805266a52f4..1123111d3940 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2322,6 +2322,11 @@ static int dispc_ovl_calc_scaling(unsigned long pclk,
unsigned long lclk,
if (width == out_width height == out_height)
return 0;
+ if (pclk == 0 || mgr_timings-pixelclock == 0) {
+ DSSERR(cannot calculate scaling settings: pclk is zero\n);
+ return -EINVAL;
+ }
+
if ((caps OMAP_DSS_OVL_CAP_SCALE) == 0)
return -EINVAL;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/15] OMAPDSS: change signal_level signal_edge enum values
At the moment the enum values for ACTIVE_HIGH and RISING_EDGE are 0, and
ACTIVE_LOW and FALLING_EDGE are 1, to match the values programmed to HW.
The previous patch removed this dependency.
Swap the enum values the other way around. This doesn't change the
behavior in any way, but makes it easier to debug as value of '1' means
HIGH or RISING.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 7414e4a97508..45a230190720 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -129,13 +129,13 @@ enum omap_rfbi_te_mode {
};
enum omap_dss_signal_level {
- OMAPDSS_SIG_ACTIVE_HIGH = 0,
- OMAPDSS_SIG_ACTIVE_LOW = 1,
+ OMAPDSS_SIG_ACTIVE_LOW,
+ OMAPDSS_SIG_ACTIVE_HIGH,
};
enum omap_dss_signal_edge {
- OMAPDSS_DRIVE_SIG_RISING_EDGE,
OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ OMAPDSS_DRIVE_SIG_RISING_EDGE,
};
enum omap_dss_venc_type {
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/15] OMAPDSS: Add support for MFLAG
OMAP5 has support for MFLAG feature, which allows DSS to dynamically
increase the priority of DISPC's DMA traffic. At the moment we don't
have support for it.
It was noticed that on DRA7 with high bandwidth use cases we see FIFO
underflows. Implementing MFLAG support removed those underflows.
Interestingly, on OMAP5 uEVM no such overflows were seen.
This patch adds a simple MFLAG implementation, where we use a fixed
MFLAG threshold value based on the FIFO size. The thresholds are set to
4/8 of fifo size for low threshold, and 5/8 of fifo size for high
threshold.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 50 +++
1 file changed, 50 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index 6296a3e5124f..6b056d0ce187 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -1305,6 +1305,53 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane
plane,
}
EXPORT_SYMBOL(dispc_ovl_compute_fifo_thresholds);
+static void dispc_ovl_set_mflag(enum omap_plane plane, bool enable)
+{
+ int bit;
+
+ if (plane == OMAP_DSS_GFX)
+ bit = 14;
+ else
+ bit = 23;
+
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable, bit, bit);
+}
+
+static void dispc_ovl_set_mflag_threshold(enum omap_plane plane,
+ int low, int high)
+{
+ dispc_write_reg(DISPC_OVL_MFLAG_THRESHOLD(plane),
+ FLD_VAL(high, 31, 16) | FLD_VAL(low, 15, 0));
+}
+
+static void dispc_init_mflag(void)
+{
+ int i;
+
+ dispc_write_reg(DISPC_GLOBAL_MFLAG_ATTRIBUTE,
+ (2 0) | /* MFLAG_CTRL = enable */
+ (0 2)); /* MFLAG_START = disable */
+
+ for (i = 0; i dss_feat_get_num_ovls(); ++i) {
+ u32 size = dispc_ovl_get_fifo_size(i);
+ u32 unit = dss_feat_get_buffer_size_unit();
+ u32 low, high;
+
+ dispc_ovl_set_mflag(i, true);
+
+ /*
+* Simulation team suggests below thesholds:
+* HT = fifosize * 5 / 8;
+* LT = fifosize * 4 / 8;
+*/
+
+ low = size * 4 / 8 / unit;
+ high = size * 5 / 8 / unit;
+
+ dispc_ovl_set_mflag_threshold(i, low, high);
+ }
+}
+
static void dispc_ovl_set_fir(enum omap_plane plane,
int hinc, int vinc,
enum omap_color_component color_comp)
@@ -3630,6 +3677,9 @@ static void _omap_dispc_initial_config(void)
if (dispc.feat-mstandby_workaround)
REG_FLD_MOD(DISPC_MSTANDBY_CTRL, 1, 0, 0);
+
+ if (dss_has_feature(FEAT_MFLAG))
+ dispc_init_mflag();
}
static const struct dispc_features omap24xx_dispc_feats __initconst = {
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/21] drm/omap: fix race conditon in DMM
The omapdrm DMM code sometimes crashes with:
WARNING: CPU: 0 PID: 1235 at lib/list_debug.c:36 __list_add+0x8c/0xbc()
list_add double add: new=e9265368, prev=e90139c4, next=e9265368.
This is caused by the code calling release_engine() twice for the same
engine.
dmm_txn_commit(wait=true) call is supposed to wait until the DMM
transaction has been finished. And it does that, but it does not wait
for the irq handler to finish.
What happens is that the irq handler is triggered, and it either wakes
up the thread that called dmm_txn_commit(), or that thread never even
slept because the transaction was finished in the HW very quickly. That
thread then continues executing, even if the irq handler is not yet
finished, and a new transaction may be initiated. If that transaction is
async (i.e. wait=false), a 'async' flag is set to true. The original irq
handler, which has yet not finished, then sees the transaction as
'async', even if it was supposed to be 'sync'.
When that happens, the irq handler does an extra release_engine() call
because it thinks it need to release the engine, leading to the crash.
This patch fixes the issue by using completion to ensure that the irq
handler has finished before a dmm_txn_commit(wait=true) may continue.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 2 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 15 ---
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index d96660573076..9f32a83ca507 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -148,7 +148,7 @@ struct refill_engine {
bool async;
- wait_queue_head_t wait_for_refill;
+ struct completion compl;
struct list_head idle_node;
};
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index c4563af55a82..ccf1bf06ceb7 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -29,6 +29,7 @@
#include linux/mm.h
#include linux/time.h
#include linux/list.h
+#include linux/completion.h
#include omap_dmm_tiler.h
#include omap_dmm_priv.h
@@ -146,10 +147,10 @@ static irqreturn_t omap_dmm_irq_handler(int irq, void
*arg)
for (i = 0; i dmm-num_engines; i++) {
if (status DMM_IRQSTAT_LST) {
- wake_up_interruptible(dmm-engines[i].wait_for_refill);
-
if (dmm-engines[i].async)
release_engine(dmm-engines[i]);
+
+ complete(dmm-engines[i].compl);
}
status = 8;
@@ -273,7 +274,8 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
/* mark whether it is async to denote list management in IRQ handler */
engine-async = wait ? false : true;
- /* verify that the irq handler sees the 'async' value */
+ reinit_completion(engine-compl);
+ /* verify that the irq handler sees the 'async' and completion value */
smp_mb();
/* kick reload */
@@ -281,9 +283,8 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
dmm-base + reg[PAT_DESCR][engine-id]);
if (wait) {
- if (wait_event_interruptible_timeout(engine-wait_for_refill,
- wait_status(engine, DMM_PATSTATUS_READY) == 0,
- msecs_to_jiffies(1)) = 0) {
+ if (!wait_for_completion_timeout(engine-compl,
+ msecs_to_jiffies(1))) {
dev_err(dmm-dev, timed out waiting for done\n);
ret = -ETIMEDOUT;
}
@@ -719,7 +720,7 @@ static int omap_dmm_probe(struct platform_device *dev)
(REFILL_BUFFER_SIZE * i);
omap_dmm-engines[i].refill_pa = omap_dmm-refill_pa +
(REFILL_BUFFER_SIZE * i);
- init_waitqueue_head(omap_dmm-engines[i].wait_for_refill);
+ init_completion(omap_dmm-engines[i].compl);
list_add(omap_dmm-engines[i].idle_node, omap_dmm-idle_head);
}
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/21] drm/omap: handle mismatching color format and buffer width
omapdrm doesn't check if the width of the framebuffer and the color
format's bits-per-pixel match.
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
a 24 bits per pixel color format, leads to the following mismatch:
5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
+ dev_err(dev-dev,
+ buffer width (%d) is not a multiple of pixel
width (%d)\n,
+ mode_cmd-width, format-planes[i].stride_bpp);
+ ret = -EINVAL;
+ goto fail;
+ }
+
size = pitch * mode_cmd-height / format-planes[i].sub_y;
if (size (omap_gem_mmap_size(bos[i]) - mode_cmd-offsets[i]))
{
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/21] drm/omap: fix operation without fbdev
omapdrm should work fine even if fbdev is missing. The current driver
crashes in that case, though, as it is missing checks for the fbdev.
Add the checks so that we don't free fbdev or restore fbdev mode when
there's no fbdev.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 95e0356bf047..87724fa818d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -518,7 +518,8 @@ static int dev_unload(struct drm_device *dev)
drm_kms_helper_poll_fini(dev);
- omap_fbdev_free(dev);
+ if (priv-fbdev)
+ omap_fbdev_free(dev);
/* flush crtcs so the fbs get released */
for (i = 0; i priv-num_crtcs; i++)
@@ -587,9 +588,11 @@ static void dev_lastclose(struct drm_device *dev)
}
}
- ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv-fbdev);
- if (ret)
- DBG(failed to restore crtc mode);
+ if (priv-fbdev) {
+ ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv-fbdev);
+ if (ret)
+ DBG(failed to restore crtc mode);
+ }
}
static void dev_preclose(struct drm_device *dev, struct drm_file *file)
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/21] drm/omap: remove dummy PM functions
omapdrm has dummy functions for platform_device's
suspend/resume/shutdown. The functions don't do anything, and those
platform device functions are deprecated, so remove them from omapdrm.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 87724fa818d0..0ebd1315fff8 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -663,23 +663,6 @@ static struct drm_driver omap_drm_driver = {
.patchlevel = DRIVER_PATCHLEVEL,
};
-static int pdev_suspend(struct platform_device *pDevice, pm_message_t state)
-{
- DBG();
- return 0;
-}
-
-static int pdev_resume(struct platform_device *device)
-{
- DBG();
- return 0;
-}
-
-static void pdev_shutdown(struct platform_device *device)
-{
- DBG();
-}
-
static int pdev_probe(struct platform_device *device)
{
int r;
@@ -726,9 +709,6 @@ static struct platform_driver pdev = {
},
.probe = pdev_probe,
.remove = pdev_remove,
- .suspend = pdev_suspend,
- .resume = pdev_resume,
- .shutdown = pdev_shutdown,
};
static int __init omap_drm_init(void)
--
2.3.0
--
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
