Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
* Tomi Valkeinen tomi.valkei...@ti.com [131215 23:26]: On 2013-12-14 16:09, Tony Lindgren wrote: Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's not a fix, just a cleanup. Hmm OK sorry looks like I removed some non-legacy mux framework code by accident. The omap_mux_* parts clearly are dead code for omap4 as it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not using omap_mux_* functions. Yes, let's revert e30b06f4d5f0 except for the dead code parts, which seems to be omap4_tpd12s015_mux_pads(), right? Yes. I tested the below patch on 4430SDP, both DSI and HDMI works. OK thanks applying for the -rc cycle. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-14 16:09, Tony Lindgren wrote:
Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
not a fix, just a cleanup.
Hmm OK sorry looks like I removed some non-legacy mux framework code
by accident. The omap_mux_* parts clearly are dead code for omap4 as
it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
using omap_mux_* functions.
Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
seems to be omap4_tpd12s015_mux_pads(), right?
Yes. I tested the below patch on 4430SDP, both DSI and HDMI works.
Tomi
From cc38cdb5c77c82f526ebce855711a6b4d4c51180 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon, 16 Dec 2013 09:14:48 +0200
Subject: [PATCH] Revert ARM: OMAP2+: Remove legacy mux code for display.c
Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove
legacy mux code for display.c) removed non-DT DSI and HDMI pinmuxing.
However, DSI pinmuxing is still needed, and removing that caused DSI
displays not to work.
This reverts the DSI parts of the commit.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 58347bb874a0..4cf165502b35 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -101,13 +101,51 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initconst = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
+{
+ u32 enable_mask, enable_shift;
+ u32 pipd_mask, pipd_shift;
+ u32 reg;
+
+ if (dsi_id == 0) {
+ enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
+ pipd_mask = OMAP4_DSI1_PIPD_MASK;
+ pipd_shift = OMAP4_DSI1_PIPD_SHIFT;
+ } else if (dsi_id == 1) {
+ enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
+ pipd_mask = OMAP4_DSI2_PIPD_MASK;
+ pipd_shift = OMAP4_DSI2_PIPD_SHIFT;
+ } else {
+ return -ENODEV;
+ }
+
+ reg = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
+
+ reg = ~enable_mask;
+ reg = ~pipd_mask;
+
+ reg |= (lanes enable_shift) enable_mask;
+ reg |= (lanes pipd_shift) pipd_mask;
+
+ omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
+ if (cpu_is_omap44xx())
+ return omap4_dsi_mux_pads(dsi_id, lane_mask);
+
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
+ if (cpu_is_omap44xx())
+ omap4_dsi_mux_pads(dsi_id, 0);
}
static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
--
1.8.3.2
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
* Tomi Valkeinen tomi.valkei...@ti.com [131213 23:36]:
On 2013-12-13 19:22, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [131213 07:49]:
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on
platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
That commit is not in the mainline. I'm talking about mainline.
v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
breaks DSI displays (just tested). It needs to be reverted (although the
HDMI parts can probably be removed).
Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
not a fix, just a cleanup.
Hmm OK sorry looks like I removed some non-legacy mux framework code
by accident. The omap_mux_* parts clearly are dead code for omap4 as
it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
using omap_mux_* functions.
Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
seems to be omap4_tpd12s015_mux_pads(), right?
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
We don't have any DT configured displays in the mainline.
Yes sorry omap4_dsi_mux_pads() should not have been removed.
pinctrl-single doesn't support the kind of register that contains the
DSI muxing. I don't know yet how that should be done. In any case, the
muxing via DT should've been added at the same time as removing the
muxing via platform callback in e30b06f4d5f000c31a77.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Only 4430sdp has a DSI display in the mainline. Those boards have DPI
displays.
Oops right, those are DPI.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On Fri, Dec 13, 2013 at 4:45 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
That's great, and I fully support that. This also calls for refactoring
the V4L2 DT bindings and support code to share them with display devices.
A bikeshedding question is where to put the common code.
Thanks very much for review!
I know drivers/video is in practice fbdev, but drivers/video (the
words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev and
generic video in a single directory. We could use a subdirectory of
drivers/video.
Or reshuffle the various graphics/video/fb/console directories (more
bikeshedding). With git it's not that painful.
Frame buffer devices ended up in drivers/video because at that time, graphics
cards were called video cards. Moving video only entered the picture later.
drivers/fb/ (currently most of drivers/video/)
drivers/console/ (currently drivers/video/console/)
...
Or should fb be under gpu?
What about drivers/media? Video and audio are multi-media, too...
Baah, bad idea... too much bikeshedding ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-13 05:45, Laurent Pinchart wrote: I know drivers/video is in practice fbdev, but drivers/video (the words) sound like the best place for things related to video. That's an option as well, but I'm not sure I like the idea of mixing fbdev and generic video in a single directory. We could use a subdirectory of drivers/video. Right, that's what I meant. I also don't supply the same data for both endpoints, when the data is about the link. E.g. I think the V4L2 binding doc suggests to supply things like bus-width for both endpoints. I only supply the data for the endpoint that uses that data. With some encoders/panels the same data could be needed on both ends, but not in these patches. How do you handle the situation where the two drivers (for each end of the link) need to know the bus width for instance ? Then I fill the bus-width for both ends, as shown in the V4L2 bindings. That's what I mean with I only supply the data for the endpoint that uses that data. If both ends use the data, I supply it for both. The most important thing in the DSS DT bindings for now is that they should contain enough information so that any future DT bindings changes can be handled with a boot-time conversion code. I'm afraid I can't give you any guarantee here. The bindings will be unstable for some time, and we'll have to deal with that somehow. I'm not asking for a guarantee. Just yes, feels fine =). The omapdss platform data structure contains the following fields - get_context_loss_count: What is that used for ? To find out if a HW block has been turned off and it has lost its registers contents. It's an optimization, without it we need to restore registers each time when runtime_resume() hook is called. However, that's on its way out. I've already made new PM code for dispc which doesn't use that. But I can't merge it before omapdrm has been fixed to properly set things up when enabling a display. - num_devices, devices, default_device: What are those used for ? Nothing anymore. They can be removed. - default_display_name: This should be easy to move to DT. How? I handled it so that I assign the aliases for displays, and display0 is always the default display. default display name is not really a hw property =). I think this should not be used for DT, and just use the display0 as default (if we use aliases). If we don't use aliases, and instead use the label properties as discussed in other thread, then there has to be some other mechanism to tell which display should be used. - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline. What's their purpose, and how are they implemented on platforms that make use of them ? Is the pinmux API an option ? They are used in mainline, grep again =). They set pinmuxing for DSI. Pinmux API is an option, but I think it would require a new driver. The DSI pins for DSI1 and DSI2 are configured in a single register, where the fields go in seemingly random order with varying widths. pinmux-single cannot be used. - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic solution is needed here. - version: Given that we detect the DSS revision based on the SoC revision, I'm tempted to either explicitly encode the DSS revision in the compatible string, or let the DSS driver query the SoC revision somehow. The later is considered as a layering violation, but let's face it, I can't see the DSS being used on a non-OMAP platform. I also would just use the compatible string, but we need to separate between different OMAP ES versions. Doing that would mean we'd need different .dtsi and .dts files for the different OMAP ES versions. It would be a mess. I have a TODO item to study this. There are only a few things that are problematic (changed between ES versions without changing DSS HW revision). If I can find a way around those, the compatible string should be enough. One example is the width of a blanking interval. Newer OMAP3 revisions have a slightly wider field. I didn't try, but maybe I can write 1-bits to the register, then read it, and if only part of those 1 bits stick, I know it's an old revision. Anyway, I think this platform data thing is not strictly related. None of these items affect the DT data (except the pinmuxing, but I think it's fine to add that later). So while the above issues need to be fixed at some point, I think they don't affect this series (well, the default display is there which may affect). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Tomi,
On Friday 13 December 2013 12:05:20 Tomi Valkeinen wrote:
On 2013-12-13 05:45, Laurent Pinchart wrote:
I know drivers/video is in practice fbdev, but drivers/video (the
words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev
and generic video in a single directory. We could use a subdirectory of
drivers/video.
Right, that's what I meant.
I also don't supply the same data for both endpoints, when the data is
about the link. E.g. I think the V4L2 binding doc suggests to supply
things like bus-width for both endpoints. I only supply the data for the
endpoint that uses that data. With some encoders/panels the same data
could be needed on both ends, but not in these patches.
How do you handle the situation where the two drivers (for each end of the
link) need to know the bus width for instance ?
Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
That's what I mean with I only supply the data for the endpoint that
uses that data. If both ends use the data, I supply it for both.
That sounds good to me.
The most important thing in the DSS DT bindings for now is that they
should contain enough information so that any future DT bindings changes
can be handled with a boot-time conversion code.
I'm afraid I can't give you any guarantee here. The bindings will be
unstable for some time, and we'll have to deal with that somehow.
I'm not asking for a guarantee. Just yes, feels fine =).
The omapdss platform data structure contains the following fields
- get_context_loss_count: What is that used for ?
To find out if a HW block has been turned off and it has lost its
registers contents. It's an optimization, without it we need to restore
registers each time when runtime_resume() hook is called.
However, that's on its way out. I've already made new PM code for dispc
which doesn't use that. But I can't merge it before omapdrm has been
fixed to properly set things up when enabling a display.
OK.
- num_devices, devices, default_device: What are those used for ?
Nothing anymore. They can be removed.
- default_display_name: This should be easy to move to DT.
How? I handled it so that I assign the aliases for displays, and
display0 is always the default display. default display name is not
really a hw property =).
I think this should not be used for DT, and just use the display0 as
default (if we use aliases). If we don't use aliases, and instead use
the label properties as discussed in other thread, then there has to be
some other mechanism to tell which display should be used.
Another option would be to add a phandle that references the default display.
I don't have a strong preference at the moment.
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
They set pinmuxing for DSI. Pinmux API is an option, but I think it would
require a new driver. The DSI pins for DSI1 and DSI2 are configured in a
single register, where the fields go in seemingly random order with varying
widths. pinmux-single cannot be used.
Or, as Archit mentioned, we could pass the SYSCONF registers as resources.
That might not be very clean though.
- set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a
generic solution is needed here.
- version: Given that we detect the DSS revision based on the SoC
revision, I'm tempted to either explicitly encode the DSS revision in the
compatible string, or let the DSS driver query the SoC revision somehow.
The later is considered as a layering violation, but let's face it, I
can't see the DSS being used on a non-OMAP platform.
I also would just use the compatible string, but we need to separate between
different OMAP ES versions. Doing that would mean we'd need different .dtsi
and .dts files for the different OMAP ES versions. It would be a mess.
I have a TODO item to study this. There are only a few things that are
problematic (changed between ES versions without changing DSS HW revision).
If I can find a way around those, the compatible string should be enough.
One example is the width of a blanking interval. Newer OMAP3 revisions have
a slightly wider field. I didn't try, but maybe I can write 1-bits to the
register, then read it, and if only part of those 1 bits stick, I know
it's an old revision.
Anyway, I think this platform data thing is not strictly related. None of
these items affect the DT data (except the pinmuxing, but I
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
* Tomi Valkeinen tomi.valkei...@ti.com [131213 07:49]:
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-13 19:22, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [131213 07:49]:
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
That commit is not in the mainline. I'm talking about mainline.
v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
breaks DSI displays (just tested). It needs to be reverted (although the
HDMI parts can probably be removed).
Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
not a fix, just a cleanup.
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
We don't have any DT configured displays in the mainline.
pinctrl-single doesn't support the kind of register that contains the
DSI muxing. I don't know yet how that should be done. In any case, the
muxing via DT should've been added at the same time as removing the
muxing via platform callback in e30b06f4d5f000c31a77.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Only 4430sdp has a DSI display in the mainline. Those boards have DPI
displays.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi, On 2013-12-12 02:39, Laurent Pinchart wrote: Hi Tomi, On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote: Hi, Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. That's great, and I fully support that. This also calls for refactoring the V4L2 DT bindings and support code to share them with display devices. A bikeshedding question is where to put the common code. Thanks very much for review! I know drivers/video is in practice fbdev, but drivers/video (the words) sound like the best place for things related to video. We should establish a committee to ponder this important question. Btw, I don't know if you noticed (or did I mention it somewhere): I use a bit shortened form of the V4L2 bindings. If there's just one endpoint, I omit the port node. I think that's always unambiguous (compared to also omitting the endpoint node, and having the properties in the main node, as was mentioned in some other thread). I also don't supply the same data for both endpoints, when the data is about the link. E.g. I think the V4L2 binding doc suggests to supply things like bus-width for both endpoints. I only supply the data for the endpoint that uses that data. With some encoders/panels the same data could be needed on both ends, but not in these patches. However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. That's perfectly fine, there's no need to implement unused features just for the sake of it, as long as the bindings are forward-compatible in that respect. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. I've quickly reviewed the patch set, concentrating on the .dts changes. Overall it looks good to me, but I suspect that we will need quite some time to finalize standard bindings as there's lots of small details that need to be taken care of. Yes. I want to get this forward as it's becoming too much pain to manage things without DSS DT support, when the rest of the OMAP platform code is using DT. The most important thing in the DSS DT bindings for now is that they should contain enough information so that any future DT bindings changes can be handled with a boot-time conversion code. Actually, even the endpoint/port stuff is extra, as that could be deduced even from the video-source method I used in earlier DT versions. The major point that bothers we, as explained in my reply to one of the patches, is that I feel like the multi-device model (virtual DSS core + DSS modules) might not accurately represent the hardware. Departing from it probably sounds scary but might not be such a large change. There are actually two separate things here. One is the multi-device model, having separate device for each DSS submodule. The other is having the 'omapdss' virtual platform device. Note that the dss_core device is a real HW block, and depicted as the dss node in DT data, whereas omapdss device is not present in the DT data, and is created dynamically at boot time. The omapdss device is a legacy thing, but nowadays it is mainly used to pass platform data. Removing omapdss device is not easy, but the only questions around that is how to implement the required platform-data functionalities, and it doesn't affect the DT data. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Tomi, On Thursday 12 December 2013 10:54:48 Tomi Valkeinen wrote: On 2013-12-12 02:39, Laurent Pinchart wrote: On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote: Hi, Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. That's great, and I fully support that. This also calls for refactoring the V4L2 DT bindings and support code to share them with display devices. A bikeshedding question is where to put the common code. Thanks very much for review! I know drivers/video is in practice fbdev, but drivers/video (the words) sound like the best place for things related to video. That's an option as well, but I'm not sure I like the idea of mixing fbdev and generic video in a single directory. We could use a subdirectory of drivers/video. We should establish a committee to ponder this important question. Btw, I don't know if you noticed (or did I mention it somewhere): I use a bit shortened form of the V4L2 bindings. If there's just one endpoint, I omit the port node. I think that's always unambiguous (compared to also omitting the endpoint node, and having the properties in the main node, as was mentioned in some other thread). Yes, I've seen that. I need to analyze this in detail, that's planned for when I'll work on sharing the DT parsing code. I also don't supply the same data for both endpoints, when the data is about the link. E.g. I think the V4L2 binding doc suggests to supply things like bus-width for both endpoints. I only supply the data for the endpoint that uses that data. With some encoders/panels the same data could be needed on both ends, but not in these patches. How do you handle the situation where the two drivers (for each end of the link) need to know the bus width for instance ? However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. That's perfectly fine, there's no need to implement unused features just for the sake of it, as long as the bindings are forward-compatible in that respect. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. I've quickly reviewed the patch set, concentrating on the .dts changes. Overall it looks good to me, but I suspect that we will need quite some time to finalize standard bindings as there's lots of small details that need to be taken care of. Yes. I want to get this forward as it's becoming too much pain to manage things without DSS DT support, when the rest of the OMAP platform code is using DT. The most important thing in the DSS DT bindings for now is that they should contain enough information so that any future DT bindings changes can be handled with a boot-time conversion code. I'm afraid I can't give you any guarantee here. The bindings will be unstable for some time, and we'll have to deal with that somehow. Actually, even the endpoint/port stuff is extra, as that could be deduced even from the video-source method I used in earlier DT versions. The major point that bothers we, as explained in my reply to one of the patches, is that I feel like the multi-device model (virtual DSS core + DSS modules) might not accurately represent the hardware. Departing from it probably sounds scary but might not be such a large change. There are actually two separate things here. One is the multi-device model, having separate device for each DSS submodule. The other is having the 'omapdss' virtual platform device. Note that the dss_core device is a real HW block, and depicted as the dss node in DT data, whereas omapdss device is not present in the DT data, and is created dynamically at boot time. That's a distinction I've missed. The omapdss device is a legacy thing, but nowadays it is mainly used to pass platform data. Removing omapdss device is not easy, but the only questions around that is how to implement the required platform-data functionalities, and it doesn't affect the DT data. The omapdss platform data structure contains the following fields - get_context_loss_count: What is that used for ? - num_devices, devices, default_device: What are those used for ? - default_display_name: This should be easy to move to DT. - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Tomi, On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote: Hi, Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. That's great, and I fully support that. This also calls for refactoring the V4L2 DT bindings and support code to share them with display devices. A bikeshedding question is where to put the common code. However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. That's perfectly fine, there's no need to implement unused features just for the sake of it, as long as the bindings are forward-compatible in that respect. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. I've quickly reviewed the patch set, concentrating on the .dts changes. Overall it looks good to me, but I suspect that we will need quite some time to finalize standard bindings as there's lots of small details that need to be taken care of. The major point that bothers we, as explained in my reply to one of the patches, is that I feel like the multi-device model (virtual DSS core + DSS modules) might not accurately represent the hardware. Departing from it probably sounds scary but might not be such a large change. The patches can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt A few notes: - The DT data are added separately in the end of .dts files for clarity. In the final version I will move them to appropriate places in the .dts files. - No binding documentation. I will add them for the next version, if there are no major changes needed. Hopefully the bindings are quite self- explanatory for people with understanding of the hardware in question. My plan is to split the connection information from the V4L2 bindings and make that a separate document. If all goes well I should be able to spend Saturday on this. - The connectors' compatible strings are ti,xxx. As there's nothing TI specific there, I think I will rename them to be without ti. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-07 06:28, Javier Martinez Canillas wrote:
Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the
right
thing for legacy platform data probing but no for DT probing:
static int dvic_probe_pdata(struct platform_device *pdev)
{
..
adapter = i2c_get_adapter(i2c_bus_num);
if (!adapter) {
dev_err(pdev-dev,
Failed to get I2C adapter, bus %d\n,
i2c_bus_num);
return -EPROBE_DEFER;
}
..
}
static int dvic_probe_of(struct platform_device *pdev)
{
..
adapter = of_find_i2c_adapter_by_node(adapter_node);
if (adapter == NULL) {
dev_err(pdev-dev, failed to parse i2c-bus\n);
omap_dss_put_device(ddata-in);
return -EINVAL;
}
..
}
The following patch solves the issue if you want to include in your patch-set:
Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On Mon, Dec 9, 2013 at 1:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-07 06:28, Javier Martinez Canillas wrote:
Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the
right
thing for legacy platform data probing but no for DT probing:
static int dvic_probe_pdata(struct platform_device *pdev)
{
..
adapter = i2c_get_adapter(i2c_bus_num);
if (!adapter) {
dev_err(pdev-dev,
Failed to get I2C adapter, bus %d\n,
i2c_bus_num);
return -EPROBE_DEFER;
}
..
}
static int dvic_probe_of(struct platform_device *pdev)
{
..
adapter = of_find_i2c_adapter_by_node(adapter_node);
if (adapter == NULL) {
dev_err(pdev-dev, failed to parse i2c-bus\n);
omap_dss_put_device(ddata-in);
return -EINVAL;
}
..
}
The following patch solves the issue if you want to include in your
patch-set:
Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
Great, thanks a lot for working on this!
I'm very happy that we will have proper display support for IGEPv2 on
v3.14 without any DT hacks or pdata-quirks :-)
Tomi
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
Here's a new version for DT support to OMAP Display Subsystem. See
http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
the
previous version, which contains thoughts about the related problems.
The major change in this version is the use of V4L2 and CDF style
port/endpoint
style in the DT data. However, note that even if the DT data contains proper
port endpoint data, the drivers only use the first endpoint. This is to
simplify the patches, as adding full support for the ports and endpoints to
the
drivers will be a big task. This approach still works with more or less all
the
boards, as the only cases where the simpler model is an issue are the boards
with multiple display devices connected to a single output.
Laurent, I'd appreciate if you could have a look at the .dts changes, to see
if
there's anything that's clearly not CDF compatible.
The patches can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
I tested your branch on my DM3730 IGEPv2 board by cherry-picking the following
commits from latest Linus tree on top of your work/dss-dt branch:
d526daeb (ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices)
50592dc3 (ARM: dts: omap3-igep0020: Add pinmuxing for DVI output)
And adding the display information using your DSS bindings to omap3-igep0020.dts
[0].
But it failed for me because of a probing order. The problem is that the probing
order is:
omap_i2c
pinctrl-single
OMAP DSS
connector-dvi
omapfb
Now DT good practices says that the pinmux setup needed for a device have to be
initialized in a pin control state for the device using these pins (i.e: i2c3)
instead of doing globally by being part of a pinctrl state of the pinmux device
(i.e: omap3_pmx_core).
But due this init order the omap_i2c probe is deferred due pinctrl-single not
being initialized yet:
[0.565246] omap_i2c 4806.i2c: could not find pctldev for node /ocp/pinmu
x@48002030/pinmux_i2c3_pins, deferring probe
This is ok since eventually the pinctrl-single driver will be initialized and
the next time the omap_i2c probe is called it will succeed. But before omap_i2c
has a chance to be probed again the connector-dvi driver is probed and fails due
the i2c bus not being initialized yet:
[1.064300] OMAP DSS rev 2.0
[1.073669] connector-dvi connector.12: failed to parse i2c-bus
[1.073730] connector-dvi: probe of connector.12 failed with error -22
[1.078216] omapfb omapfb: no displays
[1.080871] omapfb omapfb: failed to setup omapfb
[1.080932] platform omapfb: Driver omapfb requests probe deferral
..
Later the omap_i2c driver probe succees since the pinctrl-single driver was
initialized but by then it is already too late:
[3.293914] omap_i2c 4807.i2c: bus 0 rev4.4 at 2600 kHz
[3.301940] omap_i2c 48072000.i2c: bus 1 rev4.4 at 400 kHz
[3.310882] omap_i2c 4806.i2c: bus 2 rev4.4 at 100 kHz
[3.317565] omapfb omapfb: no displays
[3.321716] omapfb omapfb: failed to setup omapfb
[3.326751] platform omapfb: Driver omapfb requests probe deferral
..
[3.694915] omapfb omapfb: no displays
[3.699127] omapfb omapfb: failed to setup omapfb
[3.704071] platform omapfb: Driver omapfb requests probe deferral
..
If I move the i2c3 pinmux definitions from the i2c3 device node to
omap3_pmx_core then the display works correctly.
So, I think that we should add deferred probing to drivers/video/omap2/*.c too
to avoid the scenario I described above.
Also, would you mind to include [0] on your patch-set so display continue
working for IGEPv2 after you remove the pdata-quirks and dss-common.c hacks?
Thanks a lot and best regards,
Javier
[0]:
From a9af54a3b63bccade241e056d153d8bf04a6a5d5 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Fri, 6 Dec 2013 02:53:38 +0100
Subject: [PATCH 1/1] ARM: dts: omap3-igep0020: add display information
The IGEPv2 has a TFP410 DPI-to-DVI encoder attached
to OMAP's Display SubSystem (DSS). Add DeviceTree
nodes for these devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts | 51
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 76509de..2569d60 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -215,3 +215,54 @@
usbhsehci {
phys = hsusb1_phy;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+
+/ {
+ aliases {
+ display0 = dvi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio6 10
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 12/07/2013 04:48 AM, Javier Martinez Canillas wrote:
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
Here's a new version for DT support to OMAP Display Subsystem. See
http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
the
previous version, which contains thoughts about the related problems.
The major change in this version is the use of V4L2 and CDF style
port/endpoint
style in the DT data. However, note that even if the DT data contains proper
port endpoint data, the drivers only use the first endpoint. This is to
simplify the patches, as adding full support for the ports and endpoints to
the
drivers will be a big task. This approach still works with more or less all
the
boards, as the only cases where the simpler model is an issue are the boards
with multiple display devices connected to a single output.
Laurent, I'd appreciate if you could have a look at the .dts changes, to see
if
there's anything that's clearly not CDF compatible.
The patches can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
I tested your branch on my DM3730 IGEPv2 board by cherry-picking the following
commits from latest Linus tree on top of your work/dss-dt branch:
d526daeb (ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices)
50592dc3 (ARM: dts: omap3-igep0020: Add pinmuxing for DVI output)
And adding the display information using your DSS bindings to
omap3-igep0020.dts
[0].
But it failed for me because of a probing order. The problem is that the
probing
order is:
omap_i2c
pinctrl-single
OMAP DSS
connector-dvi
omapfb
Now DT good practices says that the pinmux setup needed for a device have to
be
initialized in a pin control state for the device using these pins (i.e: i2c3)
instead of doing globally by being part of a pinctrl state of the pinmux
device
(i.e: omap3_pmx_core).
But due this init order the omap_i2c probe is deferred due pinctrl-single not
being initialized yet:
[0.565246] omap_i2c 4806.i2c: could not find pctldev for node
/ocp/pinmu
x@48002030/pinmux_i2c3_pins, deferring probe
This is ok since eventually the pinctrl-single driver will be initialized and
the next time the omap_i2c probe is called it will succeed. But before
omap_i2c
has a chance to be probed again the connector-dvi driver is probed and fails
due
the i2c bus not being initialized yet:
[1.064300] OMAP DSS rev 2.0
[1.073669] connector-dvi connector.12: failed to parse i2c-bus
[1.073730] connector-dvi: probe of connector.12 failed with error -22
[1.078216] omapfb omapfb: no displays
[1.080871] omapfb omapfb: failed to setup omapfb
[1.080932] platform omapfb: Driver omapfb requests probe deferral
..
Later the omap_i2c driver probe succees since the pinctrl-single driver was
initialized but by then it is already too late:
[3.293914] omap_i2c 4807.i2c: bus 0 rev4.4 at 2600 kHz
[3.301940] omap_i2c 48072000.i2c: bus 1 rev4.4 at 400 kHz
[3.310882] omap_i2c 4806.i2c: bus 2 rev4.4 at 100 kHz
[3.317565] omapfb omapfb: no displays
[3.321716] omapfb omapfb: failed to setup omapfb
[3.326751] platform omapfb: Driver omapfb requests probe deferral
..
[3.694915] omapfb omapfb: no displays
[3.699127] omapfb omapfb: failed to setup omapfb
[3.704071] platform omapfb: Driver omapfb requests probe deferral
..
If I move the i2c3 pinmux definitions from the i2c3 device node to
omap3_pmx_core then the display works correctly.
So, I think that we should add deferred probing to drivers/video/omap2/*.c too
to avoid the scenario I described above.
Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the right
thing for legacy platform data probing but no for DT probing:
static int dvic_probe_pdata(struct platform_device *pdev)
{
..
adapter = i2c_get_adapter(i2c_bus_num);
if (!adapter) {
dev_err(pdev-dev,
Failed to get I2C adapter, bus %d\n,
i2c_bus_num);
return -EPROBE_DEFER;
}
..
}
static int dvic_probe_of(struct platform_device *pdev)
{
..
adapter = of_find_i2c_adapter_by_node(adapter_node);
if (adapter == NULL) {
dev_err(pdev-dev, failed to parse i2c-bus\n);
omap_dss_put_device(ddata-in);
return -EINVAL;
}
..
}
The following patch solves the issue if you want to include in your patch-set:
From c85d46b94c3d27d30218af23a6a8d61e6c7d2ae8 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Sat, 7 Dec 2013 05:18:56 +0100
Subject: [PATCH 1/1] OMAPDSS: connector-dvi: add deferred probing support for
OF path
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-04 18:01, Sebastian Reichel wrote: Hi, On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote: Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. The patches can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt Will this be ready for 3.14? Depending on that I would handle That is my hope. We have been missing DSS DT bindings for too long, and maintaining and adding new mixed DT/non-DT panels, as done for omap4 now, is just a big headache. The bindings in my series are probably not perfect, but I believe they should be fine enough. I didn't get any NACKs for the previous versions of this series, and the only reason I haven't been pushing these to mainline is that I haven't been satisfied with the bindings. Laurent promised to have a look at the bindings to see if he notices anything that would conflict with Common Display Framework bindings. If he's ok with the bindings, I think we can decide next week if these will be merged for 3.14. omapdss support for the N900 differently. If this code gets merged into 3.14 I will update the N900 patches [0] accordingly. Otherwise I would suggest to take the N900 patches as is for 3.14 and I will take care of adding the omapdss DT support to the panel (and the N900.dts) separately. I really would not like to add any more hacks for DSS. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi, Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. The patches can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt A few notes: - The DT data are added separately in the end of .dts files for clarity. In the final version I will move them to appropriate places in the .dts files. - No binding documentation. I will add them for the next version, if there are no major changes needed. Hopefully the bindings are quite self-explanatory for people with understanding of the hardware in question. - The connectors' compatible strings are ti,xxx. As there's nothing TI specific there, I think I will rename them to be without ti. Tomi Tomi Valkeinen (26): OMAPDSS: rename display-sysfs 'name' entry OMAPDSS: DSI: fix fifosize ARM: OMAP: remove DSS DT hack OMAPDSS: remove DT hacks for regulators ARM: OMAP2+: add omapdss_init_of() OMAPDSS: if dssdev-name==NULL, use alias OMAPDSS: get dssdev-alias from DT alias OMAPFB: clean up default display search OMAPFB: search for default display with DT alias OMAPDSS: add of helpers OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC OMAPDSS: Add DT support to DSI ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add display information ARM: omap3-beagle-xm.dts: add display information OMAPDSS: panel-dsi-cm: Add DT support OMAPDSS: encoder-tfp410: Add DT support OMAPDSS: connector-dvi: Add DT support OMAPDSS: encoder-tpd12s015: Add DT support OMAPDSS: hdmi-connector: Add DT support OMAPDSS: panel-dpi: Add DT support OMAPDSS: connector-analog-tv: Add DT support arch/arm/boot/dts/omap3-beagle-xm.dts | 67 ++ arch/arm/boot/dts/omap3-beagle.dts | 67 ++ arch/arm/boot/dts/omap3-tobi.dts | 40 arch/arm/boot/dts/omap3.dtsi | 43 arch/arm/boot/dts/omap4-panda-common.dtsi | 102 arch/arm/boot/dts/omap4-sdp.dts| 91 arch/arm/boot/dts/omap4.dtsi | 58 + arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/board-generic.c| 2 + arch/arm/mach-omap2/common.h | 2 + arch/arm/mach-omap2/display.c | 62 + arch/arm/mach-omap2/dss-common.c | 259 - arch/arm/mach-omap2/dss-common.h | 13 -- arch/arm/mach-omap2/pdata-quirks.c | 4 - .../video/omap2/displays-new/connector-analog-tv.c | 66 +- drivers/video/omap2/displays-new/connector-dvi.c | 43 drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++ drivers/video/omap2/displays-new/encoder-tfp410.c | 43 +++- .../video/omap2/displays-new/encoder-tpd12s015.c | 56 + drivers/video/omap2/displays-new/panel-dpi.c | 64 - drivers/video/omap2/displays-new/panel-dsi-cm.c| 65 +- drivers/video/omap2/dss/Makefile | 2 +- drivers/video/omap2/dss/dispc.c| 7 + drivers/video/omap2/dss/display-sysfs.c| 4 +- drivers/video/omap2/dss/display.c | 23 +- drivers/video/omap2/dss/dpi.c | 50 drivers/video/omap2/dss/dsi.c | 166 +++-- drivers/video/omap2/dss/dss-of.c | 160 + drivers/video/omap2/dss/dss.c | 10 + drivers/video/omap2/dss/hdmi4.c| 10 +- drivers/video/omap2/dss/venc.c | 34 +++ drivers/video/omap2/omapfb/omapfb-main.c | 67 -- include/video/omapdss.h| 6 + 33 files changed, 1390 insertions(+), 328 deletions(-) delete mode 100644 arch/arm/mach-omap2/dss-common.c delete mode 100644 arch/arm/mach-omap2/dss-common.h create mode 100644 drivers/video/omap2/dss/dss-of.c -- 1.8.3.2 -- To unsubscribe from this
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi, On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote: Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. The patches can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt Will this be ready for 3.14? Depending on that I would handle omapdss support for the N900 differently. If this code gets merged into 3.14 I will update the N900 patches [0] accordingly. Otherwise I would suggest to take the N900 patches as is for 3.14 and I will take care of adding the omapdss DT support to the panel (and the N900.dts) separately. [...] - No binding documentation. I will add them for the next version, if there are no major changes needed. Hopefully the bindings are quite self-explanatory for people with understanding of the hardware in question. It is :) [0] http://marc.info/?l=linux-omapm=138524030509240w=2 -- Sebastian signature.asc Description: Digital signature
