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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxx> 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@xxxxxxx>
> >> >> >> 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@xxxxxxxxxxx>
> >> >> >> [AF: Redone for v6]
> >> >> >> Signed-off-by: Andreas F??rber <afaerber@xxxxxxx>
> >> >> >> ---
> >> >> >> 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
Attachment:
pgpl4YA1QSLew.pgp
Description: PGP signature
