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.
Ajay
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
