| Message ID | 53D783CC.2080108@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Am 29.07.2014 13:36, schrieb Thierry Reding: > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote: >> Hi Ajay, >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote: >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar: >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>>>> >>>>> I have tested this after adding few DT changes for exynos5250-snow, >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards. >>>> >>>> I'm trying to test this with a modified exynos5250-spring DT [...] >> Unfortunately the most I got on Spring with attached DT was a blank >> screen with a white horizontal line in the middle. >> >> Do I need to specify a specific panel model for Spring? [...] >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> >> Date: Sun, 27 Jul 2014 21:58:06 +0200 >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 8bit >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> >> [AF: Redone for v6] >> Signed-off-by: Andreas F??rber <afaerber@suse.de> >> --- >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++- >> 1 file changed, 31 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts >> index 687dfab86bc8..517b1ff2bfdf 100644 >> --- a/arch/arm/boot/dts/exynos5250-spring.dts >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts >> @@ -64,10 +64,14 @@ >> vdd_pll-supply = <&s5m_ldo8_reg>; >> }; >> >> + panel: panel { >> + compatible = "simple-panel"; >> + }; > > You can't do this. "simple-panel" isn't a valid panel model. It should > probably be removed from the platform_of_match table in the driver. Okay, that means the Snow DT is wrong, too: https://patchwork.kernel.org/patch/4625441/ And the others specify it as fallback: https://patchwork.kernel.org/patch/4625461/ https://patchwork.kernel.org/patch/4625451/ Cheers, Andreas
On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote: > Hi Thierry, > > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote: > >> Am 29.07.2014 13:36, schrieb Thierry Reding: > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote: > >> >> Hi Ajay, > >> >> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: > >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote: > >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar: > >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at: > >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > >> >>>>> > >> >>>>> I have tested this after adding few DT changes for exynos5250-snow, > >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards. > >> >>>> > >> >>>> I'm trying to test this with a modified exynos5250-spring DT > >> [...] > >> >> Unfortunately the most I got on Spring with attached DT was a blank > >> >> screen with a white horizontal line in the middle. > >> >> > >> >> Do I need to specify a specific panel model for Spring? > >> [...] > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001 > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200 > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring > >> >> MIME-Version: 1.0 > >> >> Content-Type: text/plain; charset=UTF-8 > >> >> Content-Transfer-Encoding: 8bit > >> >> > >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> > >> >> [AF: Redone for v6] > >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de> > >> >> --- > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++- > >> >> 1 file changed, 31 insertions(+), 1 deletion(-) > >> >> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts > >> >> index 687dfab86bc8..517b1ff2bfdf 100644 > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts > >> >> @@ -64,10 +64,14 @@ > >> >> vdd_pll-supply = <&s5m_ldo8_reg>; > >> >> }; > >> >> > >> >> + panel: panel { > >> >> + compatible = "simple-panel"; > >> >> + }; > >> > > >> > You can't do this. "simple-panel" isn't a valid panel model. It should > >> > probably be removed from the platform_of_match table in the driver. > >> > >> Okay, that means the Snow DT is wrong, too: > >> https://patchwork.kernel.org/patch/4625441/ > >> > >> And the others specify it as fallback: > >> https://patchwork.kernel.org/patch/4625461/ > >> https://patchwork.kernel.org/patch/4625451/ > > > > A quick grep shows that many (all?) devices that use DRM panels provide > > simple-panel as fallback. That's probably fine as long as they also do > > provide the specific model. But given that simple-panel does not have a > > mode or physical size, I don't think even that makes sense. > On snow, the bridge chip provides the display mode instead of the panel. > That is why display was working for me. Okay, I suppose under some circumstances that might make sense. Although it's still always the panel that dictates the display timings, so the panel node needs to have a panel model specific compatible value with a matching entry in the panel-simple driver so that it can even be used in setups without a bridge. One other thing: how does the bridge know which mode to drive? I suspect that it can drive more than one mode? Can it freely be configured or does it have a predefined set of modes? If the latter, then according to what you said above there needs to be a way to configure the bridge (via DT?) so that it reports the mode matching the panel. I wonder if that should be handled completely in code, so that for example a bridge has a panel attached it can use the panel's .get_modes() and select a matching mode among the set that it supports. Thierry
On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote: >> Hi Thierry, >> >> On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding >> <thierry.reding@gmail.com> wrote: >> > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote: >> >> Am 29.07.2014 13:36, schrieb Thierry Reding: >> >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote: >> >> >> Hi Ajay, >> >> >> >> >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: >> >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote: >> >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar: >> >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >> >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> >>>>> >> >> >>>>> I have tested this after adding few DT changes for exynos5250-snow, >> >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards. >> >> >>>> >> >> >>>> I'm trying to test this with a modified exynos5250-spring DT >> >> [...] >> >> >> Unfortunately the most I got on Spring with attached DT was a blank >> >> >> screen with a white horizontal line in the middle. >> >> >> >> >> >> Do I need to specify a specific panel model for Spring? >> >> [...] >> >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001 >> >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> >> >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200 >> >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring >> >> >> MIME-Version: 1.0 >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> Content-Transfer-Encoding: 8bit >> >> >> >> >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> >> >> >> [AF: Redone for v6] >> >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de> >> >> >> --- >> >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++- >> >> >> 1 file changed, 31 insertions(+), 1 deletion(-) >> >> >> >> >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts >> >> >> index 687dfab86bc8..517b1ff2bfdf 100644 >> >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts >> >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts >> >> >> @@ -64,10 +64,14 @@ >> >> >> vdd_pll-supply = <&s5m_ldo8_reg>; >> >> >> }; >> >> >> >> >> >> + panel: panel { >> >> >> + compatible = "simple-panel"; >> >> >> + }; >> >> > >> >> > You can't do this. "simple-panel" isn't a valid panel model. It should >> >> > probably be removed from the platform_of_match table in the driver. >> >> >> >> Okay, that means the Snow DT is wrong, too: >> >> https://patchwork.kernel.org/patch/4625441/ >> >> >> >> And the others specify it as fallback: >> >> https://patchwork.kernel.org/patch/4625461/ >> >> https://patchwork.kernel.org/patch/4625451/ >> > >> > A quick grep shows that many (all?) devices that use DRM panels provide >> > simple-panel as fallback. That's probably fine as long as they also do >> > provide the specific model. But given that simple-panel does not have a >> > mode or physical size, I don't think even that makes sense. >> On snow, the bridge chip provides the display mode instead of the panel. >> That is why display was working for me. > > Okay, I suppose under some circumstances that might make sense. Although > it's still always the panel that dictates the display timings, so the > panel node needs to have a panel model specific compatible value with a > matching entry in the panel-simple driver so that it can even be used in > setups without a bridge. Well, I am okay with adding the compatible value for specific panel model because "simple-panel" alone cannot provide width/height of the panel. > One other thing: how does the bridge know which mode to drive? I suspect > that it can drive more than one mode? Can it freely be configured or > does it have a predefined set of modes? If the latter, then according to > what you said above there needs to be a way to configure the bridge (via > DT?) so that it reports the mode matching the panel. I wonder if that > should be handled completely in code, so that for example a bridge has a > panel attached it can use the panel's .get_modes() and select a matching > mode among the set that it supports. ptn3460 supports a standard list of "edid-emulation" ids. As of now, we receive that as a DT entry. And, these are the list of emulation ids supported: | Value | Resolution | Description | 0 | 1024x768 | NXP Generic | 1 | 1920x1080 | NXP Generic | 2 | 1920x1080 | NXP Generic | 3 | 1600x900 | Samsung LTM200KT | 4 | 1920x1080 | Samsung LTM230HT | 5 | 1366x768 | NXP Generic | 6 | 1600x900 | ChiMei M215HGE As you can see, the same resolutions have different emulator ids. May be, it depends on panel vendor also. I am really not sure if we can do this. For snow(which has 1366x768 panel), we set edid-emulation as 5. Ajay
On Wed, Jul 30, 2014 at 03:54:13PM +0530, Ajay kumar wrote: > On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote: > >> Hi Thierry, > >> > >> On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding > >> <thierry.reding@gmail.com> wrote: > >> > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote: > >> >> Am 29.07.2014 13:36, schrieb Thierry Reding: > >> >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote: > >> >> >> Hi Ajay, > >> >> >> > >> >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: > >> >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote: > >> >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar: > >> >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree at: > >> >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > >> >> >>>>> > >> >> >>>>> I have tested this after adding few DT changes for exynos5250-snow, > >> >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards. > >> >> >>>> > >> >> >>>> I'm trying to test this with a modified exynos5250-spring DT > >> >> [...] > >> >> >> Unfortunately the most I got on Spring with attached DT was a blank > >> >> >> screen with a white horizontal line in the middle. > >> >> >> > >> >> >> Do I need to specify a specific panel model for Spring? > >> >> [...] > >> >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001 > >> >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> > >> >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200 > >> >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring > >> >> >> MIME-Version: 1.0 > >> >> >> Content-Type: text/plain; charset=UTF-8 > >> >> >> Content-Transfer-Encoding: 8bit > >> >> >> > >> >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> > >> >> >> [AF: Redone for v6] > >> >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de> > >> >> >> --- > >> >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++- > >> >> >> 1 file changed, 31 insertions(+), 1 deletion(-) > >> >> >> > >> >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts > >> >> >> index 687dfab86bc8..517b1ff2bfdf 100644 > >> >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts > >> >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts > >> >> >> @@ -64,10 +64,14 @@ > >> >> >> vdd_pll-supply = <&s5m_ldo8_reg>; > >> >> >> }; > >> >> >> > >> >> >> + panel: panel { > >> >> >> + compatible = "simple-panel"; > >> >> >> + }; > >> >> > > >> >> > You can't do this. "simple-panel" isn't a valid panel model. It should > >> >> > probably be removed from the platform_of_match table in the driver. > >> >> > >> >> Okay, that means the Snow DT is wrong, too: > >> >> https://patchwork.kernel.org/patch/4625441/ > >> >> > >> >> And the others specify it as fallback: > >> >> https://patchwork.kernel.org/patch/4625461/ > >> >> https://patchwork.kernel.org/patch/4625451/ > >> > > >> > A quick grep shows that many (all?) devices that use DRM panels provide > >> > simple-panel as fallback. That's probably fine as long as they also do > >> > provide the specific model. But given that simple-panel does not have a > >> > mode or physical size, I don't think even that makes sense. > >> On snow, the bridge chip provides the display mode instead of the panel. > >> That is why display was working for me. > > > > Okay, I suppose under some circumstances that might make sense. Although > > it's still always the panel that dictates the display timings, so the > > panel node needs to have a panel model specific compatible value with a > > matching entry in the panel-simple driver so that it can even be used in > > setups without a bridge. > Well, I am okay with adding the compatible value for specific panel model > because "simple-panel" alone cannot provide width/height of the panel. > > > One other thing: how does the bridge know which mode to drive? I suspect > > that it can drive more than one mode? Can it freely be configured or > > does it have a predefined set of modes? If the latter, then according to > > what you said above there needs to be a way to configure the bridge (via > > DT?) so that it reports the mode matching the panel. I wonder if that > > should be handled completely in code, so that for example a bridge has a > > panel attached it can use the panel's .get_modes() and select a matching > > mode among the set that it supports. > ptn3460 supports a standard list of "edid-emulation" ids. > As of now, we receive that as a DT entry. > And, these are the list of emulation ids supported: > > | Value | Resolution | Description > | 0 | 1024x768 | NXP Generic > | 1 | 1920x1080 | NXP Generic > | 2 | 1920x1080 | NXP Generic > | 3 | 1600x900 | Samsung LTM200KT > | 4 | 1920x1080 | Samsung LTM230HT > | 5 | 1366x768 | NXP Generic > | 6 | 1600x900 | ChiMei M215HGE > > As you can see, the same resolutions have different emulator ids. > May be, it depends on panel vendor also. I am really not sure if we can do this. > For snow(which has 1366x768 panel), we set edid-emulation as 5. Well, modes 1, 2 and 4 as well as modes 3 and 6 must differ in some ways, otherwise there wouldn't be much point in using different IDs for them. You could try to match on more than just the active horizontal and vertical resolution. The reason behind this is that it would allow us to keep the device tree content to a minimum and determine the proper emulation ID at runtime. But if it's too difficult to implement I won't object to keeping the edid-emulation property in DT. It just means that the device tree will contain some duplicate information that needs to be kept in sync. Thierry
Hi Thierry, On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote: > On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote: > > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote: > > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote: > > >> Am 29.07.2014 13:36, schrieb Thierry Reding: > > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote: > > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: > > >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote: > > >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar: > > >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree > > >> >>>>> at: > > >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos. > > >> >>>>> git > > >> >>>>> > > >> >>>>> I have tested this after adding few DT changes for > > >> >>>>> exynos5250-snow, > > >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards. > > >> >>>> > > >> >>>> I'm trying to test this with a modified exynos5250-spring DT > > >> > > >> [...] > > >> > > >> >> Unfortunately the most I got on Spring with attached DT was a blank > > >> >> screen with a white horizontal line in the middle. > > >> >> > > >> >> Do I need to specify a specific panel model for Spring? > > >> > > >> [...] > > >> > > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 > > >> >> 2001 > > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> > > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200 > > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring > > >> >> MIME-Version: 1.0 > > >> >> Content-Type: text/plain; charset=UTF-8 > > >> >> Content-Transfer-Encoding: 8bit > > >> >> > > >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> > > >> >> [AF: Redone for v6] > > >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de> > > >> >> --- > > >> >> > > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++- > > >> >> 1 file changed, 31 insertions(+), 1 deletion(-) > > >> >> > > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts > > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index > > >> >> 687dfab86bc8..517b1ff2bfdf 100644 > > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts > > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts > > >> >> @@ -64,10 +64,14 @@ > > >> >> vdd_pll-supply = <&s5m_ldo8_reg>; > > >> >> }; > > >> >> > > >> >> + panel: panel { > > >> >> + compatible = "simple-panel"; > > >> >> + }; > > >> > > > >> > You can't do this. "simple-panel" isn't a valid panel model. It > > >> > should probably be removed from the platform_of_match table in the > > >> > driver. > > >> > > >> Okay, that means the Snow DT is wrong, too: > > >> https://patchwork.kernel.org/patch/4625441/ > > >> > > >> And the others specify it as fallback: > > >> https://patchwork.kernel.org/patch/4625461/ > > >> https://patchwork.kernel.org/patch/4625451/ > > > > > > A quick grep shows that many (all?) devices that use DRM panels provide > > > simple-panel as fallback. That's probably fine as long as they also do > > > provide the specific model. But given that simple-panel does not have a > > > mode or physical size, I don't think even that makes sense. > > > > On snow, the bridge chip provides the display mode instead of the panel. > > That is why display was working for me. > > Okay, I suppose under some circumstances that might make sense. Although > it's still always the panel that dictates the display timings, so the > panel node needs to have a panel model specific compatible value with a > matching entry in the panel-simple driver so that it can even be used in > setups without a bridge. > > One other thing: how does the bridge know which mode to drive? I suspect > that it can drive more than one mode? Can it freely be configured or > does it have a predefined set of modes? If the latter, then according to > what you said above there needs to be a way to configure the bridge (via > DT?) so that it reports the mode matching the panel. I wonder if that > should be handled completely in code, so that for example a bridge has a > panel attached it can use the panel's .get_modes() and select a matching > mode among the set that it supports. Yes, pretty please :-) I don't think it would be a good idea to duplicate mode information in the bridge DT node, as that's not a property of the bridge. Querying the mode at runtime is in my opinion a much better option, and would also allow switching between different modes at runtime when that makes sense. Now, I'm not sure whether it should be the bridge driver querying the panel driver directly, or the display controller driver doing it and then configuring the bridge accordingly. The latter seems more generic to me and doesn't rely on the assumption that the bridge output will always be directly connected to a panel.
Hi Laurent, Please find the latest series here: http://www.spinics.net/lists/dri-devel/msg66740.html On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Thierry, > > On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote: >> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote: >> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote: >> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote: >> > >> Am 29.07.2014 13:36, schrieb Thierry Reding: >> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote: >> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: >> > >> >>> On 7/27/14, Andreas Färber <afaerber@suse.de> wrote: >> > >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar: >> > >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree >> > >> >>>>> at: >> > >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos. >> > >> >>>>> git >> > >> >>>>> >> > >> >>>>> I have tested this after adding few DT changes for >> > >> >>>>> exynos5250-snow, >> > >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards. >> > >> >>>> >> > >> >>>> I'm trying to test this with a modified exynos5250-spring DT >> > >> >> > >> [...] >> > >> >> > >> >> Unfortunately the most I got on Spring with attached DT was a blank >> > >> >> screen with a white horizontal line in the middle. >> > >> >> >> > >> >> Do I need to specify a specific panel model for Spring? >> > >> >> > >> [...] >> > >> >> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 >> > >> >> 2001 >> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> >> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200 >> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring >> > >> >> MIME-Version: 1.0 >> > >> >> Content-Type: text/plain; charset=UTF-8 >> > >> >> Content-Transfer-Encoding: 8bit >> > >> >> >> > >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> >> > >> >> [AF: Redone for v6] >> > >> >> Signed-off-by: Andreas F??rber <afaerber@suse.de> >> > >> >> --- >> > >> >> >> > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++- >> > >> >> 1 file changed, 31 insertions(+), 1 deletion(-) >> > >> >> >> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts >> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index >> > >> >> 687dfab86bc8..517b1ff2bfdf 100644 >> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts >> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts >> > >> >> @@ -64,10 +64,14 @@ >> > >> >> vdd_pll-supply = <&s5m_ldo8_reg>; >> > >> >> }; >> > >> >> >> > >> >> + panel: panel { >> > >> >> + compatible = "simple-panel"; >> > >> >> + }; >> > >> > >> > >> > You can't do this. "simple-panel" isn't a valid panel model. It >> > >> > should probably be removed from the platform_of_match table in the >> > >> > driver. >> > >> >> > >> Okay, that means the Snow DT is wrong, too: >> > >> https://patchwork.kernel.org/patch/4625441/ >> > >> >> > >> And the others specify it as fallback: >> > >> https://patchwork.kernel.org/patch/4625461/ >> > >> https://patchwork.kernel.org/patch/4625451/ >> > > >> > > A quick grep shows that many (all?) devices that use DRM panels provide >> > > simple-panel as fallback. That's probably fine as long as they also do >> > > provide the specific model. But given that simple-panel does not have a >> > > mode or physical size, I don't think even that makes sense. >> > >> > On snow, the bridge chip provides the display mode instead of the panel. >> > That is why display was working for me. >> >> Okay, I suppose under some circumstances that might make sense. Although >> it's still always the panel that dictates the display timings, so the >> panel node needs to have a panel model specific compatible value with a >> matching entry in the panel-simple driver so that it can even be used in >> setups without a bridge. >> >> One other thing: how does the bridge know which mode to drive? I suspect >> that it can drive more than one mode? Can it freely be configured or >> does it have a predefined set of modes? If the latter, then according to >> what you said above there needs to be a way to configure the bridge (via >> DT?) so that it reports the mode matching the panel. I wonder if that >> should be handled completely in code, so that for example a bridge has a >> panel attached it can use the panel's .get_modes() and select a matching >> mode among the set that it supports. > > Yes, pretty please :-) I don't think it would be a good idea to duplicate mode > information in the bridge DT node, as that's not a property of the bridge. > Querying the mode at runtime is in my opinion a much better option, and would > also allow switching between different modes at runtime when that makes sense. > > Now, I'm not sure whether it should be the bridge driver querying the panel > driver directly, or the display controller driver doing it and then > configuring the bridge accordingly. The latter seems more generic to me and > doesn't rely on the assumption that the bridge output will always be directly > connected to a panel. > > -- > Regards, > > Laurent Pinchart >
Hi Ajay, On Wednesday 17 September 2014 15:43:04 Ajay kumar wrote: > Hi Laurent, > > Please find the latest series here: > http://www.spinics.net/lists/dri-devel/msg66740.html Thank you. My comment was meant to be general though, not just for your patch series. > On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart wrote: > > On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote: [snip] > >> One other thing: how does the bridge know which mode to drive? I suspect > >> that it can drive more than one mode? Can it freely be configured or > >> does it have a predefined set of modes? If the latter, then according to > >> what you said above there needs to be a way to configure the bridge (via > >> DT?) so that it reports the mode matching the panel. I wonder if that > >> should be handled completely in code, so that for example a bridge has a > >> panel attached it can use the panel's .get_modes() and select a matching > >> mode among the set that it supports. > > > > Yes, pretty please :-) I don't think it would be a good idea to duplicate > > mode information in the bridge DT node, as that's not a property of the > > bridge. Querying the mode at runtime is in my opinion a much better > > option, and would also allow switching between different modes at runtime > > when that makes sense. > > > > Now, I'm not sure whether it should be the bridge driver querying the > > panel driver directly, or the display controller driver doing it and then > > configuring the bridge accordingly. The latter seems more generic to me > > and doesn't rely on the assumption that the bridge output will always be > > directly connected to a panel.
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de> Date: Sun, 27 Jul 2014 21:58:06 +0200 Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> [AF: Redone for v6] Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm/boot/dts/exynos5250-spring.dts | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts index 687dfab86bc8..517b1ff2bfdf 100644 --- a/arch/arm/boot/dts/exynos5250-spring.dts +++ b/arch/arm/boot/dts/exynos5250-spring.dts @@ -64,10 +64,14 @@ vdd_pll-supply = <&s5m_ldo8_reg>; }; + panel: panel { + compatible = "simple-panel"; + }; + dp-controller@145B0000 { status = "okay"; pinctrl-names = "default"; - pinctrl-0 = <&dp_hpd>; + pinctrl-0 = <&dp_hpd_gpio>; samsung,color-space = <0>; samsung,dynamic-range = <0>; samsung,ycbcr-coeff = <0>; @@ -75,6 +79,7 @@ samsung,link-rate = <0x0a>; samsung,lane-count = <1>; samsung,hpd-gpio = <&gpc3 0 0>; + bridge = <&ps8622>; }; fixed-rate-clocks { @@ -387,6 +392,17 @@ status = "okay"; samsung,i2c-sda-delay = <100>; samsung,i2c-max-bus-freq = <66000>; + + ps8622: ps8622-bridge@08 { + compatible = "parade,ps8622"; + reg = <0x08>; + sleep-gpios = <&gpc3 6 0>; + reset-gpios = <&gpc3 1 0>; + lane-count = <1>; + panel = <&panel>; + pinctrl-names = "default"; + pinctrl-0 = <&ps8622_gpios>; + }; }; &i2c_8 { @@ -450,6 +466,20 @@ samsung,pin-pud = <0>; }; + dp_hpd_gpio: dp-hpd-gpio { + samsung,pins = "gpc3-0"; + samsung,pin-function = <0>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + ps8622_gpios: ps8622-gpios { + samsung,pins = "gpc3-1", "gpc3-6"; + samsung,pin-function = <1>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + s5m8767_dvs: s5m8767-dvs { samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2"; samsung,pin-function = <0>; -- 1.9.3