Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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.pinch...@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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Andreas, On Thu, Jul 31, 2014 at 7:52 PM, Andreas Färber afaer...@suse.de wrote: Am 31.07.2014 12:23, schrieb Thierry Reding: On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. [...] If you have something like simplefb enabled in addition to a DRM driver, then perhaps the DRM driver isn't properly taking over the framebuffer console. So, with simplefb reverted in U-Boot and ... * with just the v6 applied (...~2), I get only a black screen from Linux, no penguins, but the backlight seems on. System comes up okay, ssh available, and nothing stands out in dmesg. * with the two iommu patches on top, something breaks badly, no backlight, no USB/network, system inaccessible. I.e. U-Boot had no noticeable impact on these symptoms. * with the iommu patches, but dp-controller, ps8622, panel commented out, I do get backlight but USB/network not working, system inaccessible. With simplefb support in U-Boot and with just v6 applied, but dp-controller, ps8622, panel commented out, things work as well as before, i.e. this series has no bad side effects. Note that I never claimed Ajay's series were broken, just reported that things regressed for me from v4, which may well be DT-related. The iommu patches interfere with my USB somehow (none or not all devices powered; with v4, plugging my wifi dongle led to oops but ethernet dongle worked, so not entirely new symptom), which is bad since my rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, so USB based network is my only alternative to a working display once we reach userspace. Well, there are 2 variants here: 1) Bootloader 2) config Type of the bootloader should not matter unless its switching on FET1 and FET6 of tps65090 for you. But, config can be different! I have attached a config i used to get display with your latest spring-bridge.v6. Uncomment the DT nodes for DP and bridge chip and you should be able to get display and also the login. I think that you have not selected all the configs needed for IOMMU to work properly. When I deselected few IOMMU configs, I could see system crashing when FIMD + DP path was being initialized. May be, that is why your USB stops working. Even I have root file system on USB drive. Just give a try with this config and let me know your observation. If you still observe the same behavior, may be I need to flash new bootloader onto my board and try. :( Ajay # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.16.0-rc6 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARM_DMA_USE_IOMMU=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_NO_IOPORT_MAP=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, Am 01.08.2014 09:02, schrieb Ajay kumar: On Thu, Jul 31, 2014 at 7:52 PM, Andreas Färber afaer...@suse.de wrote: So, with simplefb reverted in U-Boot and ... * with just the v6 applied (...~2), I get only a black screen from Linux, no penguins, but the backlight seems on. System comes up okay, ssh available, and nothing stands out in dmesg. * with the two iommu patches on top, something breaks badly, no backlight, no USB/network, system inaccessible. I.e. U-Boot had no noticeable impact on these symptoms. * with the iommu patches, but dp-controller, ps8622, panel commented out, I do get backlight but USB/network not working, system inaccessible. With simplefb support in U-Boot and with just v6 applied, but dp-controller, ps8622, panel commented out, things work as well as before, i.e. this series has no bad side effects. Note that I never claimed Ajay's series were broken, just reported that things regressed for me from v4, which may well be DT-related. The iommu patches interfere with my USB somehow (none or not all devices powered; with v4, plugging my wifi dongle led to oops but ethernet dongle worked, so not entirely new symptom), which is bad since my rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, so USB based network is my only alternative to a working display once we reach userspace. Well, there are 2 variants here: 1) Bootloader 2) config Type of the bootloader should not matter unless its switching on FET1 and FET6 of tps65090 for you. But, config can be different! I have attached a config i used to get display with your latest spring-bridge.v6. Uncomment the DT nodes for DP and bridge chip and you should be able to get display and also the login. I think that you have not selected all the configs needed for IOMMU to work properly. When I deselected few IOMMU configs, I could see system crashing when FIMD + DP path was being initialized. May be, that is why your USB stops working. Even I have root file system on USB drive. Find attached a diff between our configs. The following stand out: * I have LPAE enabled * you don't have DMA enabled * I have CMA enabled (like in the new defconfigs) * I have the arch timer disabled (which you suggested earlier for delay) * I have more devices enabled (SPI, PWM, cpufreq, watchdog, ...) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg --- .config 2014-08-01 14:03:18.255022463 +0200 +++ ../config-ajay.txt 2014-08-01 13:19:01.875021197 +0200 @@ -34,7 +34,7 @@ CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= -# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y @@ -51,7 +51,7 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y -CONFIG_FHANDLE=y +# CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y @@ -106,19 +106,10 @@ # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y +# CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GENERIC_SCHED_CLOCK=y -CONFIG_CGROUPS=y -# CONFIG_CGROUP_DEBUG is not set -# CONFIG_CGROUP_FREEZER is not set -# CONFIG_CGROUP_DEVICE is not set -# CONFIG_CPUSETS is not set -# CONFIG_CGROUP_CPUACCT is not set -# CONFIG_RESOURCE_COUNTERS is not set -# CONFIG_CGROUP_SCHED is not set -# CONFIG_BLK_CGROUP is not set +# CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y @@ -204,7 +195,6 @@ CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_REL=y CONFIG_CLONE_BACKWARDS=y @@ -228,7 +218,7 @@ CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBDAF=y -CONFIG_BLK_DEV_BSG=y +# CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # CONFIG_BLK_CMDLINE_PARSER is not set @@ -267,7 +257,6 @@ CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq -CONFIG_PREEMPT_NOTIFIERS=y CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_RWSEM_SPIN_ON_OWNER=y @@ -323,7 +312,6 @@ # CONFIG_ARCH_MULTI_CPU_AUTO is not set # CONFIG_ARCH_VIRT is not set # CONFIG_ARCH_MVEBU is not set -# CONFIG_ARCH_AXXIA is not set # CONFIG_ARCH_BCM is not set # CONFIG_ARCH_BERLIN is not set # CONFIG_ARCH_HIGHBANK is not set @@ -358,10 +346,11 @@ CONFIG_SOC_EXYNOS4212=y CONFIG_SOC_EXYNOS4412=y CONFIG_SOC_EXYNOS5250=y -# CONFIG_SOC_EXYNOS5260 is not set -# CONFIG_SOC_EXYNOS5410 is not set -# CONFIG_SOC_EXYNOS5420 is not set -# CONFIG_SOC_EXYNOS5440 is not set +CONFIG_SOC_EXYNOS5260=y
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Ajay, Am 01.08.2014 09:02, schrieb Ajay kumar: On Thu, Jul 31, 2014 at 7:52 PM, Andreas Färber afaer...@suse.de wrote: Am 31.07.2014 12:23, schrieb Thierry Reding: On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. [...] If you have something like simplefb enabled in addition to a DRM driver, then perhaps the DRM driver isn't properly taking over the framebuffer console. So, with simplefb reverted in U-Boot and ... * with just the v6 applied (...~2), I get only a black screen from Linux, no penguins, but the backlight seems on. System comes up okay, ssh available, and nothing stands out in dmesg. * with the two iommu patches on top, something breaks badly, no backlight, no USB/network, system inaccessible. I.e. U-Boot had no noticeable impact on these symptoms. * with the iommu patches, but dp-controller, ps8622, panel commented out, I do get backlight but USB/network not working, system inaccessible. With simplefb support in U-Boot and with just v6 applied, but dp-controller, ps8622, panel commented out, things work as well as before, i.e. this series has no bad side effects. Note that I never claimed Ajay's series were broken, just reported that things regressed for me from v4, which may well be DT-related. The iommu patches interfere with my USB somehow (none or not all devices powered; with v4, plugging my wifi dongle led to oops but ethernet dongle worked, so not entirely new symptom), which is bad since my rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, so USB based network is my only alternative to a working display once we reach userspace. Well, there are 2 variants here: 1) Bootloader 2) config Unfortunately your config doesn't work for me either, on my latest spring-bridge.v6 branch. Type of the bootloader should not matter unless its switching on FET1 and FET6 of tps65090 for you. It does switch them on, if I'm reading correctly: https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L599 https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L907 Another observation I made is that sometimes in my testing (didn't spot a pattern yet) after reboot or power-off/power-on the initial white screen with the warning did not come up (no backlight), but Ctrl+U worked fine and chain-loaded nv u-boot came up on screen okay. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Andreas, On Thu, Jul 31, 2014 at 1:02 AM, Andreas Färber afaer...@suse.de wrote: Hi Ajay, Am 30.07.2014 08:21, schrieb Ajay kumar: On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote: Am 28.07.2014 08:13, schrieb Ajay kumar: On 7/27/14, Andreas Färber afaer...@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 based off kgene's for-next branch due to DT, and I run into the following: Unfortunately the most I got on Spring with attached DT was a blank screen with a white horizontal line in the middle. Then, I think bridge chip is working fine. You just need to configure the proper mode for FIMD. You can see backlight also, right? Do I need to specify a specific panel model for Spring? Yes! Try using chunghwa,claa101wb01 as compatible string for panel node. With just your v6 applied plus updated DT patch (attached) [1], I see backlight and a black screen (no white line any more). dmesg attached. I can see penguin's also! For testing I re-applied your iommu patches (which btw fail now for 5420 due to disp_pd) but didn't know what to do about your panel-lvds regulator patch now that it's gone. Ignore that regulator patch. Also, please attach the bootlog if possible after trying this. If I further apply the IOMMU patches [2], I get no backlight nor USB and thus can't obtain a boot log. Regards, Andreas [1] https://github.com/afaerber/linux/commits/spring-next [2] https://github.com/afaerber/linux/commits/spring-bridge.v6 With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. Even in your bootlogs, I can see DP getting probed. And, you say backlight is also visible. That means entire display path should be fine. Its just that you should start writing to the buffer. Have you enabled boot logos? Ajay P.S. Note that your Snow DT patch will conflict with my Snow cleanups, shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/ -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Ajay, Am 31.07.2014 10:38, schrieb Ajay kumar: On Thu, Jul 31, 2014 at 1:02 AM, Andreas Färber afaer...@suse.de wrote: Am 30.07.2014 08:21, schrieb Ajay kumar: On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote: Am 28.07.2014 08:13, schrieb Ajay kumar: On 7/27/14, Andreas Färber afaer...@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 based off kgene's for-next branch due to DT, and I run into the following: Unfortunately the most I got on Spring with attached DT was a blank screen with a white horizontal line in the middle. Then, I think bridge chip is working fine. You just need to configure the proper mode for FIMD. You can see backlight also, right? Do I need to specify a specific panel model for Spring? Yes! Try using chunghwa,claa101wb01 as compatible string for panel node. With just your v6 applied plus updated DT patch (attached) [1], I see backlight and a black screen (no white line any more). dmesg attached. I can see penguin's also! See below... For testing I re-applied your iommu patches (which btw fail now for 5420 due to disp_pd) but didn't know what to do about your panel-lvds regulator patch now that it's gone. Ignore that regulator patch. Also, please attach the bootlog if possible after trying this. If I further apply the IOMMU patches [2], I get no backlight nor USB and thus can't obtain a boot log. Regards, Andreas [1] https://github.com/afaerber/linux/commits/spring-next (I updated the branch meantime, so what I meant was spring-bridge.v6~2) [2] https://github.com/afaerber/linux/commits/spring-bridge.v6 With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. Even in your bootlogs, I can see DP getting probed. And, you say backlight is also visible. That means entire display path should be fine. Its just that you should start writing to the buffer. Have you enabled boot logos? Let me clarify: U-Boot uses the display [*], so it is powered and I see penguins initially. Then, when drm gets initialized, the screen goes black and no longer prints kernel messages or systemd output or X11 gdm login screen. Since drm stuff is the only variance here and it works with simplefb, surely something prints to some buffer! Andreas [*] https://github.com/afaerber/u-boot/commits/spring -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Thu, Jul 31, 2014 at 2:27 PM, Andreas Färber afaer...@suse.de wrote: Ajay, Am 31.07.2014 10:38, schrieb Ajay kumar: On Thu, Jul 31, 2014 at 1:02 AM, Andreas Färber afaer...@suse.de wrote: Am 30.07.2014 08:21, schrieb Ajay kumar: On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote: Am 28.07.2014 08:13, schrieb Ajay kumar: On 7/27/14, Andreas Färber afaer...@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 based off kgene's for-next branch due to DT, and I run into the following: Unfortunately the most I got on Spring with attached DT was a blank screen with a white horizontal line in the middle. Then, I think bridge chip is working fine. You just need to configure the proper mode for FIMD. You can see backlight also, right? Do I need to specify a specific panel model for Spring? Yes! Try using chunghwa,claa101wb01 as compatible string for panel node. With just your v6 applied plus updated DT patch (attached) [1], I see backlight and a black screen (no white line any more). dmesg attached. I can see penguin's also! See below... For testing I re-applied your iommu patches (which btw fail now for 5420 due to disp_pd) but didn't know what to do about your panel-lvds regulator patch now that it's gone. Ignore that regulator patch. Also, please attach the bootlog if possible after trying this. If I further apply the IOMMU patches [2], I get no backlight nor USB and thus can't obtain a boot log. Regards, Andreas [1] https://github.com/afaerber/linux/commits/spring-next (I updated the branch meantime, so what I meant was spring-bridge.v6~2) [2] https://github.com/afaerber/linux/commits/spring-bridge.v6 With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. Even in your bootlogs, I can see DP getting probed. And, you say backlight is also visible. That means entire display path should be fine. Its just that you should start writing to the buffer. Have you enabled boot logos? Let me clarify: U-Boot uses the display [*], so it is powered and I see penguins initially. Then, when drm gets initialized, the screen goes black and no longer prints kernel messages or systemd output or X11 gdm login screen. Since drm stuff is the only variance here and it works with simplefb, surely something prints to some buffer! Well, I cannot really help you with this. I think the ui process/X server is getting terminated for some reason. That might be some issue induced by the platform/drm lib. This cannot be an issue induced by the bridge chip series, definitely not! I am able to run modetest, and also able to see random data on display by doing cat /dev/urandom /dev/fb0 Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: [...] With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. Even in your bootlogs, I can see DP getting probed. And, you say backlight is also visible. That means entire display path should be fine. Its just that you should start writing to the buffer. Have you enabled boot logos? Let me clarify: U-Boot uses the display [*], so it is powered and I see penguins initially. Then, when drm gets initialized, the screen goes black and no longer prints kernel messages or systemd output or X11 gdm login screen. Who's displaying the penguins? If you're referring to the Linux boot logo then it shouldn't be displayed at all until after DRM has been initialized (and the framebuffer console been set up). Since drm stuff is the only variance here and it works with simplefb, surely something prints to some buffer! If you have something like simplefb enabled in addition to a DRM driver, then perhaps the DRM driver isn't properly taking over the framebuffer console. Thierry pgpCXT0Z1BLIS.pgp Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Am 31.07.2014 12:23, schrieb Thierry Reding: On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: [...] With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. Even in your bootlogs, I can see DP getting probed. And, you say backlight is also visible. That means entire display path should be fine. Its just that you should start writing to the buffer. Have you enabled boot logos? Let me clarify: U-Boot uses the display [*], so it is powered and I see penguins initially. Then, when drm gets initialized, the screen goes black and no longer prints kernel messages or systemd output or X11 gdm login screen. Who's displaying the penguins? If you're referring to the Linux boot logo then it shouldn't be displayed at all until after DRM has been initialized (and the framebuffer console been set up). Yes, I'm referring to the default boot logo, but before the boot messages (console=tty1) indicate that [drm] driver is being initialized. Since drm stuff is the only variance here and it works with simplefb, surely something prints to some buffer! If you have something like simplefb enabled in addition to a DRM driver, then perhaps the DRM driver isn't properly taking over the framebuffer console. Okay, that's worth a try. Around v4 of this series it was not a problem. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Am 31.07.2014 12:23, schrieb Thierry Reding: On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas Färber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. [...] If you have something like simplefb enabled in addition to a DRM driver, then perhaps the DRM driver isn't properly taking over the framebuffer console. So, with simplefb reverted in U-Boot and ... * with just the v6 applied (...~2), I get only a black screen from Linux, no penguins, but the backlight seems on. System comes up okay, ssh available, and nothing stands out in dmesg. * with the two iommu patches on top, something breaks badly, no backlight, no USB/network, system inaccessible. I.e. U-Boot had no noticeable impact on these symptoms. * with the iommu patches, but dp-controller, ps8622, panel commented out, I do get backlight but USB/network not working, system inaccessible. With simplefb support in U-Boot and with just v6 applied, but dp-controller, ps8622, panel commented out, things work as well as before, i.e. this series has no bad side effects. Note that I never claimed Ajay's series were broken, just reported that things regressed for me from v4, which may well be DT-related. The iommu patches interfere with my USB somehow (none or not all devices powered; with v4, plugging my wifi dongle led to oops but ethernet dongle worked, so not entirely new symptom), which is bad since my rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, so USB based network is my only alternative to a working display once we reach userspace. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Andreas, On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote: Hi Ajay, Am 28.07.2014 08:13, schrieb Ajay kumar: On 7/27/14, Andreas Färber afaer...@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 based off kgene's for-next branch due to DT, and I run into the following: CC drivers/gpu/drm/bridge/ptn3460.o drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’: drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of function ‘drm_connector_register’ [-Werror=implicit-function-declaration] drm_connector_register(ptn_bridge-connector); ^ Hope this might help: http://www.spinics.net/lists/dri-devel/msg60578.html That fixed my build, thanks. Unfortunately the most I got on Spring with attached DT was a blank screen with a white horizontal line in the middle. Then, I think bridge chip is working fine. You just need to configure the proper mode for FIMD. You can see backlight also, right? Do I need to specify a specific panel model for Spring? Yes! Try using chunghwa,claa101wb01 as compatible string for panel node. For testing I re-applied your iommu patches (which btw fail now for 5420 due to disp_pd) but didn't know what to do about your panel-lvds regulator patch now that it's gone. Ignore that regulator patch. Also, please attach the bootlog if possible after trying this. Regards, Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
thierry.red...@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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Ok. I will resend DT patches removing simple-panel fallback.
Regards,
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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.red...@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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
pgpIFkEXWHADN.pgp
Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Sat, Jul 26, 2014 at 12:52:02AM +0530, Ajay Kumar wrote: 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. Hi Ajay, I very much like where this is going. There are a few rough edges still, but generally this is pretty much what I had imagined. Thanks for bearing with me. Generally I think it would be safer to restructure some of the patches a little so that they can be more easily applied and keep bisectability. I'll go into more detail in the individual patches. Thierry pgpngbWhNwIVA.pgp Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding
thierry.red...@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.red...@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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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.red...@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.red...@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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay,
Am 30.07.2014 08:21, schrieb Ajay kumar:
On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote:
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@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 based off
kgene's for-next branch due to DT, and I run into the following:
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Then, I think bridge chip is working fine.
You just need to configure the proper mode for FIMD.
You can see backlight also, right?
Do I need to specify a specific panel model for Spring?
Yes! Try using chunghwa,claa101wb01 as compatible string for
panel node.
With just your v6 applied plus updated DT patch (attached) [1], I see
backlight and a black screen (no white line any more). dmesg attached.
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
Ignore that regulator patch.
Also, please attach the bootlog if possible after trying this.
If I further apply the IOMMU patches [2], I get no backlight nor USB and
thus can't obtain a boot log.
Regards,
Andreas
[1] https://github.com/afaerber/linux/commits/spring-next
[2] https://github.com/afaerber/linux/commits/spring-bridge.v6
P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 64fdedabdfcfa5ac8ec97ab647ccfdd4520430d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 6d1d175e910e..8baad7ebe739 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -90,6 +90,10 @@
samsung,invert-vclk;
};
+ panel: panel {
+ compatible = chunghwa,claa101wb01;
+ };
+
dp-controller@145B {
status = okay;
pinctrl-names = default;
@@ -101,6 +105,7 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 1;
samsung,hpd-gpio = gpc3 0 GPIO_ACTIVE_HIGH;
+ bridge = ps8622;
};
};
@@ -405,6 +410,17 @@
status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
+
+ ps8622: lvds-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 {
@@ -461,11 +477,18 @@
pinctrl_0 {
dp_hpd_gpio: dp-hpd-gpio {
samsung,pins = gpc3-0;
- samsung,pin-function = 1;
+ 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
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc6+ (andr...@chrome11.site) (gcc version
4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #23 SMP PREEMPT
Wed Jul 30 20:11:19 CEST 2014
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] Machine model: Google Spring
[0.00] cma: CMA: reserved 64 MiB at 6b80
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 523264
[0.00] free_area_init_node: node 0, pgdat c066b400, node_mem_map
ea7dc000
[0.00] Normal zone: 1520 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 194560 pages, LIFO batch:31
[0.00] HighMem zone: 2568 pages used for memmap
[0.00] HighMem zone: 328704 pages, LIFO batch:31
[0.00] PERCPU: Embedded 7
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@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 based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
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?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas Färber afaer...@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@145B {
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
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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 afaer...@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 based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
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?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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.
Thierry
pgpIi7FlD727t.pgp
Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:36:46PM +0200, Thierry Reding wrote:
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 afaer...@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 based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function
‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
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?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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.
Done.
Thierry
pgpymGXgkzERW.pgp
Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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 afaer...@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?= afaer...@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...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@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.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Thierry
pgpKwO2bAVLF_.pgp
Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Andreas, On 7/27/14, Andreas Färber afaer...@suse.de wrote: Hi Ajay, 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 based off kgene's for-next branch due to DT, and I run into the following: CC drivers/gpu/drm/bridge/ptn3460.o drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’: drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of function ‘drm_connector_register’ [-Werror=implicit-function-declaration] drm_connector_register(ptn_bridge-connector); ^ Hope this might help: http://www.spinics.net/lists/dri-devel/msg60578.html Switch back to drm_sysfs_connector_add if your kernel doesn't have this patch. Ajay cc1: some warnings being treated as errors scripts/Makefile.build:257: recipe for target 'drivers/gpu/drm/bridge/ptn3460.o' failed make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1 scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge' failed make[3]: *** [drivers/gpu/drm/bridge] Error 2 make[3]: *** Warte auf noch nicht beendete Prozesse... scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:899: recipe for target 'drivers' failed make: *** [drivers] Error 2 Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree, and it must be new since v4. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, 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 based off kgene's for-next branch due to DT, and I run into the following: CC drivers/gpu/drm/bridge/ptn3460.o drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’: drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of function ‘drm_connector_register’ [-Werror=implicit-function-declaration] drm_connector_register(ptn_bridge-connector); ^ cc1: some warnings being treated as errors scripts/Makefile.build:257: recipe for target 'drivers/gpu/drm/bridge/ptn3460.o' failed make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1 scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge' failed make[3]: *** [drivers/gpu/drm/bridge] Error 2 make[3]: *** Warte auf noch nicht beendete Prozesse... scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:899: recipe for target 'drivers' failed make: *** [drivers] Error 2 Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree, and it must be new since v4. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
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. The V4 series of this particular patchset was also tested by: Rahul Sharma rahul.sha...@samsung.com Javier Martinez Canillas jav...@dowhile0.org Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Changes since V5: -- Modify bridge drivers to support driver model. -- Drop the concept of bridge chain(sincle there are no 2 real bridges) Hence drop bridge-panel_binder layer. -- Drop panel-lvds driver and accomodate the required changes in panel-simple driver. -- Use gpiod interface in ptn3460 driver. -- Address all comments by Thierry Reding for V5 series. -- Address comments from Sean Paul for exynos_dp_commit issue. Ajay Kumar (6): [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel [PATCH V6 4/8] drm/exynos: Move DP setup into commit() [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model Sean Paul (1): [PATCH V6 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge Vincent Palatin (1): [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 - .../devicetree/bindings/panel/auo,b133htn01.txt|7 + .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/ps8622.txt| 19 + .../devicetree/bindings/video/bridge/ptn3460.txt | 27 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/bridge/Kconfig | 32 +- drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/ps8622.c| 602 drivers/gpu/drm/bridge/ptn3460.c | 212 --- drivers/gpu/drm/drm_bridge.c | 89 +++ drivers/gpu/drm/drm_crtc.c |9 +- drivers/gpu/drm/exynos/Kconfig |4 +- drivers/gpu/drm/exynos/exynos_dp_core.c| 165 -- drivers/gpu/drm/exynos/exynos_dp_core.h|4 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c|8 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c|7 + drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 +- drivers/gpu/drm/panel/panel-ld9040.c | 18 +- drivers/gpu/drm/panel/panel-s6e8aa0.c | 18 +- drivers/gpu/drm/panel/panel-simple.c | 96 +++- drivers/gpu/drm/tegra/output.c |2 + include/drm/bridge/ptn3460.h | 37 -- include/drm/drm_crtc.h | 16 +- include/drm/drm_panel.h| 26 + 25 files changed, 1206 insertions(+), 225 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt create mode 100644 Documentation/devicetree/bindings/video/bridge/ptn3460.txt create mode 100644 drivers/gpu/drm/bridge/ps8622.c create mode 100644 drivers/gpu/drm/drm_bridge.c delete mode 100644 include/drm/bridge/ptn3460.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
