Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Signed-off-by: Tomi Valkeinen tomi.valkeinen@ti.com
:040000 040000 f8231d6c016e5f936908f535539d9cdbd184d596 b5ed25dd77bd2508688ca4047e3d421ff6f1e40f M drivers iMac:master hns$ git bisect log git bisect start # good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13 git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261 # bad: [2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e] Linux 4.14-rc1 git bisect bad 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e # bad: [aae3dbb4776e7916b6cd442d00159bea27a695c1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect bad aae3dbb4776e7916b6cd442d00159bea27a695c1 # bad: [bf1d6b2c76eda86159519bf5c427b1fa8f51f733] Merge tag 'staging-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging git bisect bad bf1d6b2c76eda86159519bf5c427b1fa8f51f733 # bad: [edc2988c548db05e33b921fed15821010bc74895] Merge branch 'linus' into locking/core, to fix up conflicts git bisect bad edc2988c548db05e33b921fed15821010bc74895 # skip: [e5fa05b96b02f45a91a364d2121451a4da05cd84] Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next git bisect skip e5fa05b96b02f45a91a364d2121451a4da05cd84 # skip: [d0b83d413f2254484d8e359c3eee2f0ca846e231] drm/amdgpu: add MJPEG check for UVD physical mode msg buffer git bisect skip d0b83d413f2254484d8e359c3eee2f0ca846e231 # good: [4734b4f417126e8773b3983122ca935d02af80de] IB/rdmavt: Add QP iterator API for QPs git bisect good 4734b4f417126e8773b3983122ca935d02af80de # good: [bbfb6ce86c9889a5d434e2e603d41e0ce5b552e2] drm/i915: Implement .get_format_info() hook for CCS git bisect good bbfb6ce86c9889a5d434e2e603d41e0ce5b552e2 # skip: [735f463af70e9601881ec879961ec42aef051733] Merge tag 'drm-intel-next-2017-08-18' of git://anongit.freedesktop.org/git/drm-intel into drm-next git bisect skip 735f463af70e9601881ec879961ec42aef051733 # skip: [cfcfb65ad15a1b43cf5cd434c57966fae03db96b] Merge tag 'drm-msm-next-2017-08-22' of git://people.freedesktop.org/~robclark/linux into drm-next git bisect skip cfcfb65ad15a1b43cf5cd434c57966fae03db96b # good: [eacf3e149ea64c550925b4635f854062bb535005] drm/amdgpu: make wb 256bit function names consistent git bisect good eacf3e149ea64c550925b4635f854062bb535005 # skip: [ab7c16486707f86264c73b043327c70866236722] drm/amdkfd: Fix goto usage v2 git bisect skip ab7c16486707f86264c73b043327c70866236722 # good: [ba4dd71828bce7dfa46a5e6e33e2605f65d16534] drm/msm: add modeset module param git bisect good ba4dd71828bce7dfa46a5e6e33e2605f65d16534 # good: [9b756a9d07fd34be189ccc3d3fc6dfc686e532fb] scripts/sphinx-pre-install: add minimum support for RHEL git bisect good 9b756a9d07fd34be189ccc3d3fc6dfc686e532fb # skip: [34c3db6c22a0c770c6c9a4c4e6462ee4baa64b30] drm/exynos/decon5433: refactor irq requesting code git bisect skip 34c3db6c22a0c770c6c9a4c4e6462ee4baa64b30 # good: [6aeeadab79e1d67ebb275dc4735bbbded252f637] drm/cirrus: switch to drm_*_get(), drm_*_put() helpers git bisect good 6aeeadab79e1d67ebb275dc4735bbbded252f637 # skip: [c2cade3dd15914b13de5e6d8c6241ed7919475ed] drm/amdgpu: Disable GFX PG on CZ git bisect skip c2cade3dd15914b13de5e6d8c6241ed7919475ed # good: [384548e569c82dc1e018dcdfd7e19c4b9f87c6b5] hwmon: (it87) Reapply probe path chip registers settings after resume git bisect good 384548e569c82dc1e018dcdfd7e19c4b9f87c6b5 # good: [b416bf14bdd2019ed62b1a20876a33cf2480bbfd] drm/amdgpu: ignore digest_size when loading sdma fw for raven git bisect good b416bf14bdd2019ed62b1a20876a33cf2480bbfd # good: [18daeb8e978241ca9fcf874a1c5ad9a628beddd7] drm: omapdrm: dss: Select features based on compatible string git bisect good 18daeb8e978241ca9fcf874a1c5ad9a628beddd7 # skip: [eba5e56db65b7a44d57a98f5f382b2a2b9991321] drm/nouveau/disp/gf119-: avoid creating non-existent heads git bisect skip eba5e56db65b7a44d57a98f5f382b2a2b9991321 # good: [825a51a4af82fd90c1fd98b080439d8593972457] IB/rxe: Fix up rxe_qp_cleanup() git bisect good 825a51a4af82fd90c1fd98b080439d8593972457 # skip: [ef369904aaf717e0390b483efd47daba9ba8ddf2] drm/vmwgfx: Move irq bottom half processing to threads git bisect skip ef369904aaf717e0390b483efd47daba9ba8ddf2 # good: [7a3b68b9075cf9b67692bb97497740bab1dfab41] hwmon: (ltq-cputemp) add devicetree bindings documentation git bisect good 7a3b68b9075cf9b67692bb97497740bab1dfab41 # skip: [4ab4016aaf82153d144fa678cd6b4b5b6f25ed70] drm/amdgpu: drop the extra VM huge page flag v2 git bisect skip 4ab4016aaf82153d144fa678cd6b4b5b6f25ed70 # good: [0aa1125fa8bc5e5f98317156728fa4d0293561a5] locking/rwsem-spinlock: Add killable versions of __down_read() git bisect good 0aa1125fa8bc5e5f98317156728fa4d0293561a5 # good: [ce07a9415f266e181a0a33033a5f7138760240a4] locking/lockdep: Make check_prev_add() able to handle external stack_trace git bisect good ce07a9415f266e181a0a33033a5f7138760240a4 # skip: [8eabaf54cfb34d185b7c9684bc891397d757d15e] drm/amdkfd: Clean up KFD style errors and warnings v2 git bisect skip 8eabaf54cfb34d185b7c9684bc891397d757d15e # good: [d1f08d82176246c6d8a2f1dc26be3638ed4a6083] drm/msm/mdp5: mark runtime_pm functions as __maybe_unused git bisect good d1f08d82176246c6d8a2f1dc26be3638ed4a6083 # good: [c1aa3871fa0f676559f6d0cb6941e5f4ce7de306] Documentation: stable-kernel-rules: fix broken git urls git bisect good c1aa3871fa0f676559f6d0cb6941e5f4ce7de306 # skip: [7c0059dd832cc686bf0febefdcf8295cdd93007f] Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-next git bisect skip 7c0059dd832cc686bf0febefdcf8295cdd93007f # good: [ccba59197a430ee4c295ee8f4b127c6dea954501] drm/i915/guc: Rename GuC irq trigger function git bisect good ccba59197a430ee4c295ee8f4b127c6dea954501 # bad: [7ebdb0dd52404907b8eac2bab476b43a8b8aa9f1] Merge tag 'exynos-drm-next-for-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next git bisect bad 7ebdb0dd52404907b8eac2bab476b43a8b8aa9f1 # skip: [a0aeb3b2ac3ff0608f1bc3fb46332148856d3276] Merge tag 'drm-amdkfd-next-2017-08-18' of git://people.freedesktop.org/~gabbayo/linux into drm-next git bisect skip a0aeb3b2ac3ff0608f1bc3fb46332148856d3276 # good: [3164e4e31a7ff7024d493553d22bca09c463a28f] drm/qxl: Use the drm_driver.dumb_destroy default git bisect good 3164e4e31a7ff7024d493553d22bca09c463a28f # bad: [3aadb888b1b62ba04798414cae431d3c3bd5f452] Merge tag 'drm/tegra/for-4.14-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next git bisect bad 3aadb888b1b62ba04798414cae431d3c3bd5f452 # skip: [33476319c0e8b3543c27d883e7a478ceb8648f80] drm/amdgpu: bump version for support of UVD MJPEG decode git bisect skip 33476319c0e8b3543c27d883e7a478ceb8648f80 # skip: [739a6d5d640a9811beef6a828253ee184dd431c5] drm: omapdrm: Remove omapdrm platform data git bisect skip 739a6d5d640a9811beef6a828253ee184dd431c5 # good: [efa479352fc780b305fa186cafb5f416fdf2b2cb] drm/nouveau: Fix merge commit git bisect good efa479352fc780b305fa186cafb5f416fdf2b2cb # skip: [3f4f46f624fe1cc38a37690b85723e557d858188] drm/amdkfd: Fix typo in dbgdev_wave_reset_wavefronts git bisect skip 3f4f46f624fe1cc38a37690b85723e557d858188 # skip: [f91ac470a8b1b358e9c2c7dc17da2642d125c3ac] drm/etnaviv: reduce allocation failure message severity git bisect skip f91ac470a8b1b358e9c2c7dc17da2642d125c3ac # skip: [c76cf869669eff8fa73bc0f56c87cd4d6d2e66df] drm/amdkfd: Remove bogus divide-by-sizeof(uint32_t) git bisect skip c76cf869669eff8fa73bc0f56c87cd4d6d2e66df # skip: [8cc47b3ea0822175deb8bf436e4c59a7f128ac30] drm/etnaviv: populate GEM objects on cpu_prep git bisect skip 8cc47b3ea0822175deb8bf436e4c59a7f128ac30 # skip: [dbcca4aab1b2e1983e5432cb2a1d4f5f1d8b4750] drm/amdgpu: fix Vega10 HW config for 2MB pages git bisect skip dbcca4aab1b2e1983e5432cb2a1d4f5f1d8b4750 # good: [7d1a2bf41f06b360724f9b2156cc8a2da816b15c] drm/sun4i: Remove useless atomic_check git bisect good 7d1a2bf41f06b360724f9b2156cc8a2da816b15c # skip: [6a1c9510694fe1e901a3b5b53386eac069adcea6] drm/amdkfd: Adding new IOCTL for scratch memory v2 git bisect skip 6a1c9510694fe1e901a3b5b53386eac069adcea6 # skip: [97cbb28451c21212cc20f2a5e6c074ba33150c3d] drm/amdgpu: move debug print into the MM managers git bisect skip 97cbb28451c21212cc20f2a5e6c074ba33150c3d # good: [7664b2fa42b5e962dd9ffd9e386dc20cbc966176] drm/tegra: switch to drm_*_get(), drm_*_put() helpers git bisect good 7664b2fa42b5e962dd9ffd9e386dc20cbc966176 # skip: [27c7b9aeecd7c06a3b527795807c19a0bbe25c1e] drm/amdgpu: rename VM invalidated to moved git bisect skip 27c7b9aeecd7c06a3b527795807c19a0bbe25c1e # good: [9df1baa1732a9ac125126087ffc848d6a3e08fdf] MAINTAINERS: Add drm/tinydrm maintainer entry git bisect good 9df1baa1732a9ac125126087ffc848d6a3e08fdf # skip: [111159b58d72e2f0e5c0e95fefb46415f996f19f] drm/amdgpu: Program SH_STATIC_MEM_CONFIG globally, not per-VMID git bisect skip 111159b58d72e2f0e5c0e95fefb46415f996f19f # skip: [70539bd79500245cbb4c7af00572fcce540d0105] drm/amd: Update MEC HQD loading code for KFD git bisect skip 70539bd79500245cbb4c7af00572fcce540d0105 # skip: [2419672f4c96ca678a95d0f733f44d3ee036b5c8] drm/omap: Potential NULL deref in omap_crtc_duplicate_state() git bisect skip 2419672f4c96ca678a95d0f733f44d3ee036b5c8 # skip: [e618d306ded38dc9d37c04dc37e24bf9d62e9c7b] drm/amd/amdgpu: store fragment_size in vm_manager git bisect skip e618d306ded38dc9d37c04dc37e24bf9d62e9c7b # skip: [f5af512e0f11e7895973440857b99170f68bbd5b] drm/radeon: Return dword offsets of address watch registers git bisect skip f5af512e0f11e7895973440857b99170f68bbd5b # good: [9cbcbdbaff9e5dbf1b8f4eb28b4f0e18e0f36bbc] drm/sun4i: tcon: remove unused function git bisect good 9cbcbdbaff9e5dbf1b8f4eb28b4f0e18e0f36bbc # skip: [a35ebc8c12cc724022f39b32ffb17f63ff16effd] drm/amdgpu: only bind VM shadows after validation v2 git bisect skip a35ebc8c12cc724022f39b32ffb17f63ff16effd # good: [24ab1df3665e52eda64508a2bf7c2cc688285ccc] drm: omapdrm: dss: Use supported outputs instead of display types git bisect good 24ab1df3665e52eda64508a2bf7c2cc688285ccc # skip: [438e29a25b451297a93ebd2b3c3004fa0f9ff4cd] drm/amdgpu: Remove hard-coded assumptions about compute pipes git bisect skip 438e29a25b451297a93ebd2b3c3004fa0f9ff4cd # good: [11765d163c972a68db02b41d7ad107f5baf5f4b1] drm: omapdrm: Move all debugfs code from core to dss git bisect good 11765d163c972a68db02b41d7ad107f5baf5f4b1 # skip: [09e56abbc67e364c3810f8454223918c82b4934a] drm/amdgpu: Add kgd/kfd interface to support scratch memory v2 git bisect skip 09e56abbc67e364c3810f8454223918c82b4934a # skip: [4eacc26b3b99c32deed150adff5e38ebce60527c] drm/amdkfd: Change x==NULL/false references to !x git bisect skip 4eacc26b3b99c32deed150adff5e38ebce60527c # skip: [63f5677544b3672979222fecef32c21e5131072b] drm/etnaviv: select CMA and DMA_CMA if available git bisect skip 63f5677544b3672979222fecef32c21e5131072b # skip: [dbf56ab11a09550c00edb84fc4b2197350154e99] drm/amdkfd: Remove usage of alloc(sizeof(struct... git bisect skip dbf56ab11a09550c00edb84fc4b2197350154e99 # good: [37899a5254917e17418bbb23086d55e38faaa659] drm/amdgpu/gfx7: fix function name git bisect good 37899a5254917e17418bbb23086d55e38faaa659 # skip: [c0573af349f649516863254fad386175777d5672] drm/amdgpu: SHADOW and VRAM_CONTIGUOUS flags shouldn't be used by userspace git bisect skip c0573af349f649516863254fad386175777d5672 # good: [2c9fc9bf45f854c3bad88ffaf9c1d0fc75d02440] drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver git bisect good 2c9fc9bf45f854c3bad88ffaf9c1d0fc75d02440 # bad: [df9bcb0652bbfde1b37bda98f0ad1fa7fda46d67] drm/ttm: use reservation_object_trylock in ttm_bo_individualize_resv v2 git bisect bad df9bcb0652bbfde1b37bda98f0ad1fa7fda46d67 # skip: [8824c751eb61ebffb053c291199932845bac88b4] Merge tag 'omapdrm-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next git bisect skip 8824c751eb61ebffb053c291199932845bac88b4 # skip: [1a33860d630c9cb4687ad01bda5651e96bad3694] drm/ttm: remove nonsense wait in ttm_bo_cleanup_refs_and_unlock git bisect skip 1a33860d630c9cb4687ad01bda5651e96bad3694 # bad: [ba63b6352c753f592e35b6b828f9ffd4e9ac6aa1] drm: omapdrm: hdmi: Configure the PLL from the HDMI core version git bisect bad ba63b6352c753f592e35b6b828f9ffd4e9ac6aa1 # bad: [51919572c89a0c5dcf0cfff4ba4b36e175f091c7] drm: omapdrm: Move supported outputs feature to dss driver git bisect bad 51919572c89a0c5dcf0cfff4ba4b36e175f091c7 # bad: [1ac0c894032692d3cb25583e33ceaea78cc8ab4b] drm: omapdrm: Move FEAT_* features to dispc driver git bisect bad 1ac0c894032692d3cb25583e33ceaea78cc8ab4b # bad: [4569ab757f09b9b6a3dd4eda2b0b37c7f5535e6d] drm: omapdrm: Move FEAT_LCD_CLK_SRC feature to dss_features structure git bisect bad 4569ab757f09b9b6a3dd4eda2b0b37c7f5535e6d # bad: [d178e034d5653edfbd16d0c71eeeed467e33c96f] drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f # first bad commit: [d178e034d5653edfbd16d0c71eeeed467e33c96f] drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code iMac:master hns$
Any ideas where to look what this patch did break and how to fix it?
BR and thanks, Nikolaus
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
I don't have a device up and running now, but I think the "family" string that it tries to match can also be seen somewhere under /proc, so you could perhaps find it and see if it actually is OMAP3530, which should be matched by the code.
Tomi
Hi Tomi,
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
Somehow, both seem to work (up to 4.13.x) on different devices.
Anyways, "toppoly" should be "tpo" according to Documentation/devicetree/bindings/vendor-prefixes.txt I'll add this to the patches we will need...
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ah, I see.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
I don't have a device up and running now, but I think the "family" string that it tries to match can also be seen somewhere under /proc, so you could perhaps find it and see if it actually is OMAP3530, which should be matched by the code.
Or I add a printk() to watch what it tries to find. That should be a quite simple test.
BR and thanks, Nikolaus
Hello,
On Monday, 6 November 2017 19:52:53 EET H. Nikolaus Schaller wrote:
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
Somehow, both seem to work (up to 4.13.x) on different devices.
Anyways, "toppoly" should be "tpo" according to Documentation/devicetree/bindings/vendor-prefixes.txt I'll add this to the patches we will need...
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ah, I see.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
I don't have a device up and running now, but I think the "family" string that it tries to match can also be seen somewhere under /proc, so you could perhaps find it and see if it actually is OMAP3530, which should be matched by the code.
Or I add a printk() to watch what it tries to find. That should be a quite simple test.
Sorry for having broken the Pandora :(
I believe I incorrectly matched on .family instead of .machine. Could you try the following patch ? I've only compile-tested it as I don't have access to any OMAP3 board using the DPI output right now.
From a2df9cde5b854cbb19a88b9dac9337d515dda713 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Tue, 7 Nov 2017 08:23:54 +0200 Subject: [PATCH] drm: omapdrm: Fix DPI on platforms using the DSI VDDS
Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") replaced usage of platform data version with SoC matching to configure DPI VDDS. The SoC match entries were incorrect, they should have matched on the machine name instead of the SoC family. Fix it.
Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com --- drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c index daf286fc8a40..ca1e3b489540 100644 --- a/drivers/gpu/drm/omapdrm/dss/dpi.c +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll) }
static const struct soc_device_attribute dpi_soc_devices[] = { - { .family = "OMAP3[456]*" }, - { .family = "[AD]M37*" }, + { .machine = "OMAP3[456]*" }, + { .machine = "[AD]M37*" }, { /* sentinel */ } };
Hi Laurent, sorry but I missed this mail somehow.
Am 07.11.2017 um 08:35 schrieb Laurent Pinchart laurent.pinchart@ideasonboard.com:
Hello,
On Monday, 6 November 2017 19:52:53 EET H. Nikolaus Schaller wrote:
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
Somehow, both seem to work (up to 4.13.x) on different devices.
Anyways, "toppoly" should be "tpo" according to Documentation/devicetree/bindings/vendor-prefixes.txt I'll add this to the patches we will need...
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ah, I see.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
I don't have a device up and running now, but I think the "family" string that it tries to match can also be seen somewhere under /proc, so you could perhaps find it and see if it actually is OMAP3530, which should be matched by the code.
Or I add a printk() to watch what it tries to find. That should be a quite simple test.
Sorry for having broken the Pandora :(
I believe I incorrectly matched on .family instead of .machine. Could you try the following patch ? I've only compile-tested it as I don't have access to any OMAP3 board using the DPI output right now.
From a2df9cde5b854cbb19a88b9dac9337d515dda713 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Tue, 7 Nov 2017 08:23:54 +0200 Subject: [PATCH] drm: omapdrm: Fix DPI on platforms using the DSI VDDS
Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") replaced usage of platform data version with SoC matching to configure DPI VDDS. The SoC match entries were incorrect, they should have matched on the machine name instead of the SoC family. Fix it.
Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c index daf286fc8a40..ca1e3b489540 100644 --- a/drivers/gpu/drm/omapdrm/dss/dpi.c +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll) }
static const struct soc_device_attribute dpi_soc_devices[] = {
- { .family = "OMAP3[456]*" },
- { .family = "[AD]M37*" },
- { .machine = "OMAP3[456]*" },
this pattern matches: Pandora: .machine = OMAP3430/3530 GTA04: .machine = OMAP3630/DM3730
Both devices work.
- { .machine = "[AD]M37*" },
Both devices work without this line.
So I am not sure if such a .machine value exists and we need this line at all.
Is there a list of all potential strings or do we have to reverse engineer?
Looking into the other patterns there is "AM35*" and "AM43*", but no AM37 or DM37.
iMac:master hns$ fgrep -R .machine drivers/gpu/drm/omapdrm/ drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "OMAP3[45]*", drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "OMAP3[45]*", .data = &omap34xx_rev3_0_dispc_feats }, drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "AM35*", .data = &omap34xx_rev3_0_dispc_feats }, drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "AM43*", .data = &am43xx_dispc_feats }, drivers/gpu/drm/omapdrm//dss/dsi.c: { .machine = "OMAP3[45]*", .data = &dsi_of_data_omap34xx }, drivers/gpu/drm/omapdrm//dss/dsi.c: { .machine = "AM35*", .data = &dsi_of_data_omap34xx }, drivers/gpu/drm/omapdrm//dss/dss.c: { .machine = "OMAP3430/3530", .data = &omap34xx_dss_feats }, drivers/gpu/drm/omapdrm//dss/dss.c: { .machine = "AM35??", .data = &omap34xx_dss_feats }, drivers/gpu/drm/omapdrm//dss/venc.c: { .machine = "OMAP3[45]*" }, drivers/gpu/drm/omapdrm//dss/venc.c: { .machine = "AM35*" }, iMac:master hns$ fgrep -R .family drivers/gpu/drm/omapdrm/ drivers/gpu/drm/omapdrm//dss/dpi.c: { .family = "OMAP3[456]*" }, drivers/gpu/drm/omapdrm//dss/dpi.c: { .family = "[AD]M37*" }, drivers/gpu/drm/omapdrm//dss/dss.c: { .family = "AM43xx", .data = &am43xx_dss_feats }, drivers/gpu/drm/omapdrm//dss/hdmi4_core.c: { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features }, drivers/gpu/drm/omapdrm//dss/hdmi4_core.c: { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features }, drivers/gpu/drm/omapdrm//dss/hdmi4_core.c: { .family = "OMAP4", .data = &hdmi4_es3_features }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "OMAP3", .data = (void *)0x3430 }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "OMAP4", .data = (void *)0x4430 }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "OMAP5", .data = (void *)0x5430 }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "DRA7", .data = (void *)0x0752 }, iMac:master hns$
{ /* sentinel */ } };
So here what I see to match and properly enable regulators (without the "[AD]M37*" pattern):
Pandora / OMAP3530
[ 19.895721] attr [ 19.897674] machine = OMAP3430/3530 [ 19.901519] family = OMAP3 [ 19.904571] revision = ES3.1 [ 19.908386] soc_id = null [ 19.911315] match [ 19.913360] machine = OMAP3[456]* [ 19.917297] family = null [ 19.920257] revision = null [ 19.923370] soc_id = null [ 19.926452] dpi_init_regulator() match
GTA04 / DM3730
[ 19.584136] attr [ 19.586395] machine = OMAP3630/DM3730 [ 19.590423] family = OMAP3 [ 19.593444] revision = ES1.2 [ 19.598083] soc_id = null [ 19.601043] match [ 19.603057] machine = OMAP3[456]* [ 19.606933] family = null [ 19.609863] revision = null [ 19.613006] soc_id = null [ 19.616027] dpi_init_regulator() match
BR, Nikolaus
Hi Nikolaus,
On Wednesday, 8 November 2017 09:52:27 EET H. Nikolaus Schaller wrote:
Hi Laurent, sorry but I missed this mail somehow.
No worries.
Am 07.11.2017 um 08:35 schrieb Laurent Pinchart: On Monday, 6 November 2017 19:52:53 EET H. Nikolaus Schaller wrote:
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024. jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024. jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
Somehow, both seem to work (up to 4.13.x) on different devices.
Anyways, "toppoly" should be "tpo" according to Documentation/devicetree/bindings/vendor-prefixes.txt I'll add this to the patches we will need...
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ah, I see.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
I don't have a device up and running now, but I think the "family" string that it tries to match can also be seen somewhere under /proc, so you could perhaps find it and see if it actually is OMAP3530, which should be matched by the code.
Or I add a printk() to watch what it tries to find. That should be a quite simple test.
Sorry for having broken the Pandora :(
I believe I incorrectly matched on .family instead of .machine. Could you try the following patch ? I've only compile-tested it as I don't have access to any OMAP3 board using the DPI output right now.
From a2df9cde5b854cbb19a88b9dac9337d515dda713 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Tue, 7 Nov 2017 08:23:54 +0200 Subject: [PATCH] drm: omapdrm: Fix DPI on platforms using the DSI VDDS
Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") replaced usage of platform data version with SoC matching to configure DPI VDDS. The SoC match entries were incorrect, they should have matched on the machine name instead of the SoC family. Fix it.
Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com --- drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c index daf286fc8a40..ca1e3b489540 100644 --- a/drivers/gpu/drm/omapdrm/dss/dpi.c +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll) }
static const struct soc_device_attribute dpi_soc_devices[] = {
- { .family = "OMAP3[456]*" },
- { .family = "[AD]M37*" },
- { .machine = "OMAP3[456]*" },
this pattern matches: Pandora: .machine = OMAP3430/3530 GTA04: .machine = OMAP3630/DM3730
Both devices work.
- { .machine = "[AD]M37*" },
Both devices work without this line.
So I am not sure if such a .machine value exists and we need this line at all.
The AM3703 and DM3725 chips use DSI VDDS for DPI so we need both match entries.
Is there a list of all potential strings or do we have to reverse engineer?
They are all in arch/arm/mach-omap2/id.c. You will find the old model information passed through platform data to the DSS driver in arch/arm/mach- omap2/display.c before commit d178e034d565. Matching the two isn't much fun.
As explained in another e-mail another option would be to keep matching on the family with a match string set to "OMAP3*" but I haven't ruled out the possibility of false positives in that case.
Looking into the other patterns there is "AM35*" and "AM43*", but no AM37 or DM37.
iMac:master hns$ fgrep -R .machine drivers/gpu/drm/omapdrm/ drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "OMAP3[45]*", drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "OMAP3[45]*", .data = &omap34xx_rev3_0_dispc_feats }, drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "AM35*", .data = &omap34xx_rev3_0_dispc_feats }, drivers/gpu/drm/omapdrm//dss/dispc.c: { .machine = "AM43*", .data = &am43xx_dispc_feats }, drivers/gpu/drm/omapdrm//dss/dsi.c: { .machine = "OMAP3[45]*", .data = &dsi_of_data_omap34xx }, drivers/gpu/drm/omapdrm//dss/dsi.c: { .machine = "AM35*", .data = &dsi_of_data_omap34xx }, drivers/gpu/drm/omapdrm//dss/dss.c: { .machine = "OMAP3430/3530", .data = &omap34xx_dss_feats }, drivers/gpu/drm/omapdrm//dss/dss.c: { .machine = "AM35??", .data = &omap34xx_dss_feats }, drivers/gpu/drm/omapdrm//dss/venc.c: { .machine = "OMAP3[45]*" }, drivers/gpu/drm/omapdrm//dss/venc.c: { .machine = "AM35*" }, iMac:master hns$ fgrep -R .family drivers/gpu/drm/omapdrm/ drivers/gpu/drm/omapdrm//dss/dpi.c: { .family = "OMAP3[456]*" }, drivers/gpu/drm/omapdrm//dss/dpi.c: { .family = "[AD]M37*" }, drivers/gpu/drm/omapdrm//dss/dss.c: { .family = "AM43xx", .data = &am43xx_dss_feats }, drivers/gpu/drm/omapdrm//dss/hdmi4_core.c: { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features }, drivers/gpu/drm/omapdrm//dss/hdmi4_core.c: { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features }, drivers/gpu/drm/omapdrm//dss/hdmi4_core.c: { .family = "OMAP4",
.data =
&hdmi4_es3_features }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "OMAP3", .data = (void *)0x3430 }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "OMAP4", .data = (void *)0x4430 }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "OMAP5", .data = (void *)0x5430 }, drivers/gpu/drm/omapdrm//omap_drv.c: { .family = "DRA7", .data = (void *)0x0752 }, iMac:master hns$
{ /* sentinel */ }
};
So here what I see to match and properly enable regulators (without the "[AD]M37*" pattern):
Pandora / OMAP3530
[ 19.895721] attr [ 19.897674] machine = OMAP3430/3530 [ 19.901519] family = OMAP3 [ 19.904571] revision = ES3.1 [ 19.908386] soc_id = null [ 19.911315] match [ 19.913360] machine = OMAP3[456]* [ 19.917297] family = null [ 19.920257] revision = null [ 19.923370] soc_id = null [ 19.926452] dpi_init_regulator() match
GTA04 / DM3730
[ 19.584136] attr [ 19.586395] machine = OMAP3630/DM3730 [ 19.590423] family = OMAP3 [ 19.593444] revision = ES1.2 [ 19.598083] soc_id = null [ 19.601043] match [ 19.603057] machine = OMAP3[456]* [ 19.606933] family = null [ 19.609863] revision = null [ 19.613006] soc_id = null [ 19.616027] dpi_init_regulator() match
On 06/11/17 19:52, H. Nikolaus Schaller wrote:
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
In the dts, you should never have the omapdss prefix.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
Yep, if you look at the datamanual, you'll see the pins which VDDS_DSI powers. It doesn't affect all the DPI pins.
Tomi
Am 07.11.2017 um 08:57 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 19:52, H. Nikolaus Schaller wrote:
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
In the dts, you should never have the omapdss prefix.
Ok, then we have to remove it from Pandora DTS anyways. So there will be a fix for Pandora and one for GTA04 + td028ttec1.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
Yep, if you look at the datamanual, you'll see the pins which VDDS_DSI powers. It doesn't affect all the DPI pins.
Ok! This special feature did help to find the issue... If the screen would have remained completely black, it would have been more difficult to decide between bisect bad/skip/good.
BR and thanks, Nikolaus
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ok, I think I have found it. The pattern in dpi_soc_devices[] is wrong.
Here is what my printk hack() reports on the 600 MHz Pandora (OMAP3530):
[ 20.171325] soc_device_match_attr() [ 20.175445] attr [ 20.177398] machine = OMAP3430/3530 [ 20.181274] family = OMAP3 [ 20.184295] revision = ES3.1 [ 20.188232] soc_id = null [ 20.191192] match [ 20.193237] machine = null [ 20.196411] family = OMAP3[456]* [ 20.199981] revision = null [ 20.203124] soc_id = null [ 20.182403] dpi_init_regulator() match
Changing the pattern to "OMAP[3456]*" makes it work but I am not sure what exactly is intended. Should the pattern match the .machine and not the .family?
The DM3730 based GTA04 reports (without patch):
[ 18.618621] soc_device_match_attr() [ 18.622314] attr [ 18.624237] machine = OMAP3630/DM3730 [ 18.628509] family = OMAP3 [ 18.631561] revision = ES1.2 [ 18.634765] soc_id = null [ 18.638000] match [ 18.640014] machine = null [ 18.643035] family = OMAP3[456]* [ 18.646697] revision = null [ 18.649810] soc_id = null [ 18.652770] soc_device_match_attr() [ 18.656616] attr [ 18.658538] machine = OMAP3630/DM3730 [ 18.662567] family = OMAP3 [ 18.665649] revision = ES1.2 [ 18.668853] soc_id = null [ 18.671813] match [ 18.673828] machine = null [ 18.677001] family = [AD]M37* [ 18.680297] revision = null [ 18.683410] soc_id = null [ 18.686614] dpi_init_regulator() no match
Here we have no match and don't enable VDDS_DSI - but it still works (maybe VDDS_DSI is enabled elsewhere). And I do not see how the second pattern .family = "[AD]M37*" can ever match.
According to the comment in the original patch:
"The DPI uses the DSI VDDS on OMAP34xx, OMAP35xx, OMAP36xx, AM37xx and DM37xx only."
a single match for .family = "OMAP3" should suffice. Shouldn't it? And there is no family "AM/DM37*". Or is it?
A tiny and subtle flaw which has such a strange result...
But I don't know what would be correct.
BR and thanks, Nikolaus
Hi Nikolaus,
On Tuesday, 7 November 2017 13:36:14 EET H. Nikolaus Schaller wrote:
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpe g 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpe g
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ok, I think I have found it. The pattern in dpi_soc_devices[] is wrong.
Here is what my printk hack() reports on the 600 MHz Pandora (OMAP3530):
[ 20.171325] soc_device_match_attr() [ 20.175445] attr [ 20.177398] machine = OMAP3430/3530 [ 20.181274] family = OMAP3 [ 20.184295] revision = ES3.1 [ 20.188232] soc_id = null [ 20.191192] match [ 20.193237] machine = null [ 20.196411] family = OMAP3[456]* [ 20.199981] revision = null [ 20.203124] soc_id = null [ 20.182403] dpi_init_regulator() match
Changing the pattern to "OMAP[3456]*" makes it work but I am not sure what exactly is intended. Should the pattern match the .machine and not the .family?
The DM3730 based GTA04 reports (without patch):
[ 18.618621] soc_device_match_attr() [ 18.622314] attr [ 18.624237] machine = OMAP3630/DM3730 [ 18.628509] family = OMAP3 [ 18.631561] revision = ES1.2 [ 18.634765] soc_id = null [ 18.638000] match [ 18.640014] machine = null [ 18.643035] family = OMAP3[456]* [ 18.646697] revision = null [ 18.649810] soc_id = null [ 18.652770] soc_device_match_attr() [ 18.656616] attr [ 18.658538] machine = OMAP3630/DM3730 [ 18.662567] family = OMAP3 [ 18.665649] revision = ES1.2 [ 18.668853] soc_id = null [ 18.671813] match [ 18.673828] machine = null [ 18.677001] family = [AD]M37* [ 18.680297] revision = null [ 18.683410] soc_id = null [ 18.686614] dpi_init_regulator() no match
Here we have no match and don't enable VDDS_DSI - but it still works (maybe VDDS_DSI is enabled elsewhere). And I do not see how the second pattern .family = "[AD]M37*" can ever match.
According to the comment in the original patch:
"The DPI uses the DSI VDDS on OMAP34xx, OMAP35xx, OMAP36xx, AM37xx and DM37xx only."
a single match for .family = "OMAP3" should suffice. Shouldn't it?
I think that would work. It would additionally match the TI814x, but that SoC doesn't seem to have a DSS anyway.
And there is no family "AM/DM37*". Or is it?
A tiny and subtle flaw which has such a strange result...
But I don't know what would be correct.
As explained in a patch in another e-mail in this thread, the match should have been against machine, not family. We could either test that patch, or just match against machine = "OMAP3", which would be simpler.
Tomi, do you know any OMAP3 machine that doesn't use the DSI VDDS for DPI ?
-
H. Nikolaus Schaller -
Laurent Pinchart -
Tomi Valkeinen