Re: [PATCH RESEND] iosys-map: fix typos
Hi Am 12.02.24 um 05:28 schrieb Randy Dunlap: Correct spellos/typos in comments. Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org --- include/linux/iosys-map.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/include/linux/iosys-map.h b/include/linux/iosys-map.h --- a/include/linux/iosys-map.h +++ b/include/linux/iosys-map.h @@ -34,7 +34,7 @@ * the same driver for allocation, read and write operations. * * Open-coding access to :c:type:`struct iosys_map ` is considered - * bad style. Rather then accessing its fields directly, use one of the provided + * bad style. Rather than accessing its fields directly, use one of the provided Ok. * helper functions, or implement your own. For example, instances of * :c:type:`struct iosys_map ` can be initialized statically with * IOSYS_MAP_INIT_VADDR(), or at runtime with iosys_map_set_vaddr(). These @@ -85,7 +85,7 @@ *if (iosys_map_is_equal(_map, _map)) *// always false * - * A set up instance of struct iosys_map can be used to access or manipulate the + * A setup instance of struct iosys_map can be used to access or manipulate the That's not a typo. This refers to "an instance that has been set up". Best regards Thomas * buffer memory. Depending on the location of the memory, the provided helpers * will pick the correct operations. Data can be copied into the memory with * iosys_map_memcpy_to(). The address can be manipulated with iosys_map_incr(). -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
[PATCH RESEND] iosys-map: fix typos
Correct spellos/typos in comments. Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org --- include/linux/iosys-map.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/include/linux/iosys-map.h b/include/linux/iosys-map.h --- a/include/linux/iosys-map.h +++ b/include/linux/iosys-map.h @@ -34,7 +34,7 @@ * the same driver for allocation, read and write operations. * * Open-coding access to :c:type:`struct iosys_map ` is considered - * bad style. Rather then accessing its fields directly, use one of the provided + * bad style. Rather than accessing its fields directly, use one of the provided * helper functions, or implement your own. For example, instances of * :c:type:`struct iosys_map ` can be initialized statically with * IOSYS_MAP_INIT_VADDR(), or at runtime with iosys_map_set_vaddr(). These @@ -85,7 +85,7 @@ * if (iosys_map_is_equal(_map, _map)) * // always false * - * A set up instance of struct iosys_map can be used to access or manipulate the + * A setup instance of struct iosys_map can be used to access or manipulate the * buffer memory. Depending on the location of the memory, the provided helpers * will pick the correct operations. Data can be copied into the memory with * iosys_map_memcpy_to(). The address can be manipulated with iosys_map_incr().
Re: [PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
Hi Tony, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.8-rc3 next-20240209] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Tony-Lindgren/dt-bindings-display-bridge-tc358775-make-stby-gpio-optional/20240211-180213 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240211095144.2589-4-tony%40atomide.com patch subject: [PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765 compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240212/202402120510.uibwazki-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/r/202402120510.uibwazki-...@intel.com/ dtcheck warnings: (new ones prefixed by >>) >> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml:87:8: >> [error] empty value in block mapping (empty-values) -- >> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: >> allOf:0:if: None is not of type 'object', 'boolean' from schema $id: http://json-schema.org/draft-07/schema# >> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: >> allOf:0:then: 'anyOf' conditional failed, one must be fixed: 'stby-gpios' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems'] 'type' was expected from schema $id: http://devicetree.org/meta-schemas/keywords.yaml# -- >> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: >> ignoring, error in schema: allOf: 0: if vim +87 Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml 8b0d47e879b8fe Vinay Simha BN 2020-07-101 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 8b0d47e879b8fe Vinay Simha BN 2020-07-102 %YAML 1.2 8b0d47e879b8fe Vinay Simha BN 2020-07-103 --- 8b0d47e879b8fe Vinay Simha BN 2020-07-104 $id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml# 8b0d47e879b8fe Vinay Simha BN 2020-07-105 $schema: http://devicetree.org/meta-schemas/core.yaml# 8b0d47e879b8fe Vinay Simha BN 2020-07-106 84e85359f4999a Krzysztof Kozlowski 2022-12-167 title: Toshiba TC358775 DSI to LVDS bridge 8b0d47e879b8fe Vinay Simha BN 2020-07-108 8b0d47e879b8fe Vinay Simha BN 2020-07-109 maintainers: 8b0d47e879b8fe Vinay Simha BN 2020-07-10 10- Vinay Simha BN 8b0d47e879b8fe Vinay Simha BN 2020-07-10 11 8b0d47e879b8fe Vinay Simha BN 2020-07-10 12 description: | 6b27cbab742a1a Tony Lindgren 2024-02-11 13This binding supports DSI to LVDS bridges TC358765 and TC358775 8b0d47e879b8fe Vinay Simha BN 2020-07-10 14 8b0d47e879b8fe Vinay Simha BN 2020-07-10 15MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane. 8b0d47e879b8fe Vinay Simha BN 2020-07-10 16Video frame size: 8b0d47e879b8fe Vinay Simha BN 2020-07-10 17Up to 1600x1200 24-bit/pixel resolution for single-link LVDS display panel 8b0d47e879b8fe Vinay Simha BN 2020-07-10 18limited by 135 MHz LVDS speed 8b0d47e879b8fe Vinay Simha BN 2020-07-10 19Up to WUXGA (1920x1200 24-bit pixels) resolution for dual-link LVDS display 8b0d47e879b8fe Vinay Simha BN 2020-07-10 20panel, limited by 270 MHz LVDS speed. 8b0d47e879b8fe Vinay Simha BN 2020-07-10 21 8b0d47e879b8fe Vinay Simha BN 2020-07-10 22 properties: 8b0d47e879b8fe Vinay Simha BN 2020-07-10 23compatible: 6b27cbab742a1a Tony Lindgren 2024-02-11 24 enum: 6b27cbab742a1a Tony Lindgren 2024-02-11 25- toshiba,tc358765 6b27cbab742a1a Tony Lindgren 2024-02-11 26- toshiba,tc358775 8b0d47e879b8fe Vinay Simha BN 2020-07-10 27 8b0d47e879b8fe Vinay Simha BN 2020-07-10 28reg: 8b0d47e879b8fe Vinay Simha BN 2020-07-10 29 maxItems: 1 8b0d47e879b8fe Vinay Simha BN 2020-07-10 30 description: i2c address of the bridge, 0x0f 8b0d47e879b8fe Vinay Simha B
Re: [PATCH v3 1/4] dt-bindings: display: bridge: add sam9x75-lvds compatible
Hi Krzysztof, On 09/02/24 9:40 pm, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 09/02/2024 17:05, Krzysztof Kozlowski wrote: >> On 09/02/2024 16:02, dharm...@microchip.com wrote: >>> On 09/02/24 7:50 pm, Dharma B wrote: On 08/02/24 2:31 pm, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know > the content is safe > > On 07/02/2024 11:27, Dharma Balasubiramani wrote: >> Add the 'sam9x75-lvds' compatible binding, which describes the Low >> Voltage >> Differential Signaling (LVDS) Controller found on some Microchip's >> sam9x7 >> series System-on-Chip (SoC) devices. This binding will be used to define >> the properties and configuration for the LVDS Controller in DT. >> >> Signed-off-by: Dharma Balasubiramani > > Not tested... > > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC. It might happen, that command when run on an older > kernel, gives you outdated entries. Therefore please be sure you base > your patches on recent Linux kernel. > > Tools like b4 or scripts/get_maintainer.pl provide you proper list of > people, so fix your workflow. Tools might also fail if you work on some > ancient tree (don't, instead use mainline), work on fork of kernel > (don't, instead use mainline) or you ignore some maintainers (really > don't). Just use b4 and everything should be fine, although remember > about `b4 prep --auto-to-cc` if you added new patches to the patchset. > > You missed at least devicetree list (maybe more), so this won't be > tested by automated tooling. Performing review on untested code might be > a waste of time. Apologies for the oversight, somehow it got missed. >>> >>> The get_maintainer.pl seems to be inconsistent with the results. >>> >>> linux$ ./scripts/get_maintainer.pl *patch | wc -l >>> ./scripts/get_maintainer.pl: file '-cover-letter.patch' doesn't >>> appear to be a patch. Add -f to options? >>> 31 >>> linux$ ./scripts/get_maintainer.pl *patch | wc -l >>> ./scripts/get_maintainer.pl: file '-cover-letter.patch' doesn't >>> appear to be a patch. Add -f to options? >>> 29 >>> linux$ ./scripts/get_maintainer.pl *patch | wc -l >>> ./scripts/get_maintainer.pl: file '-cover-letter.patch' doesn't >>> appear to be a patch. Add -f to options? >>> 30 >>> linux$ ./scripts/get_maintainer.pl *patch | wc -l >>> ./scripts/get_maintainer.pl: file '-cover-letter.patch' doesn't >>> appear to be a patch. Add -f to options? >>> 30 >> >> Why would you add 30 addresses, including many unrelated people, to the >> cc-list? You must add only maintainers (so also reviewers) and mailing >> lists. > > Really, why do you Cc MM folks on this patch? Just read what > get_maintainer.pl tells you, e.g. when it says that someone made one > commit to maintainers file, shall this person be Cc-ed? No, it should be > obvious... Thank you for bringing this to my attention. I sincerely apologize for any oversight. Moving forward, I will ensure to utilize 'b4 prep --auto-to-cc' to obtain the accurate To and CC list. > > Best regards, > Krzysztof > -- With Best Regards, Dharma B.
[drm-misc:for-linux-next 49/49] drivers/gpu/drm/tests/drm_mm_test.c:191:25: error: implicit declaration of function 'drm_debug_printer' is invalid in C99
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 7edd06233958d9086a9e3eb723a8768d3c5a9ce1
commit: e154c4fc7bf2d5c3f86d07628ab1cb03e8085c25 [49/49] drm: remove
drm_debug_printer in favor of drm_dbg_printer
config: powerpc-randconfig-002-20240211
(https://download.01.org/0day-ci/archive/20240212/202402120908.e1oazn0i-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240212/202402120908.e1oazn0i-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402120908.e1oazn0i-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/tests/drm_mm_test.c:191:25: error: implicit declaration of
>> function 'drm_debug_printer' is invalid in C99
>> [-Werror,-Wimplicit-function-declaration]
struct drm_printer p = drm_debug_printer(test->name);
^
drivers/gpu/drm/tests/drm_mm_test.c:191:25: note: did you mean
'drm_dbg_printer'?
include/drm/drm_print.h:328:34: note: 'drm_dbg_printer' declared here
static inline struct drm_printer drm_dbg_printer(struct drm_device *drm,
^
drivers/gpu/drm/tests/drm_mm_test.c:191:21: error: initializing 'struct
drm_printer' with an expression of incompatible type 'int'
struct drm_printer p = drm_debug_printer(test->name);
^ ~
2 errors generated.
vim +/drm_debug_printer +191 drivers/gpu/drm/tests/drm_mm_test.c
393b50f30566ba drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 188
961bcdf956a464 drivers/gpu/drm/tests/drm_mm_test.c Maíra Canal
2022-09-11 189 static void drm_test_mm_debug(struct kunit *test)
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 190 {
3eb791c891aa91 drivers/gpu/drm/tests/drm_mm_test.c Michał Winiarski
2024-01-16 @191 struct drm_printer p = drm_debug_printer(test->name);
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 192 struct drm_mm mm;
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 193 struct drm_mm_node nodes[2];
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 194
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 195 /* Create a small drm_mm with a couple of nodes and a
few holes, and
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 196 * check that the debug iterator doesn't explode over a
trivial drm_mm.
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 197 */
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 198 drm_mm_init(, 0, 4096);
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 199
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 200 memset(nodes, 0, sizeof(nodes));
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 201 nodes[0].start = 512;
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 202 nodes[0].size = 1024;
fc8d29e298cf47 drivers/gpu/drm/tests/drm_mm_test.c Arthur Grillo
2022-07-08 203 KUNIT_ASSERT_FALSE_MSG(test, drm_mm_reserve_node(,
[0]),
fc8d29e298cf47 drivers/gpu/drm/tests/drm_mm_test.c Arthur Grillo
2022-07-08 204"failed to reserve node[0]
{start=%lld, size=%lld)\n",
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 205nodes[0].start, nodes[0].size);
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 206
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 207 nodes[1].size = 1024;
06df8ac682e6a0 drivers/gpu/drm/selftests/test-drm_mm.c Chris Wilson
2016-12-22 208 nodes[1].start = 4096 - 512 - nodes[1].size;
fc8d29e298cf47 drivers/gpu/drm/tests/drm_mm_test.c Arthur Grillo
2022-07-08 209 KUNIT_ASSERT_FALSE_MSG(test, drm_mm_reserve_node(,
[1]),
fc8d29e298cf47 drivers/gpu/drm/tests/drm_mm_test.c Arthur Grillo
2022-07-08 210"failed to reserve node[0]
{start=%lld, size=%lld)\n",
fc8d29e298cf47 drivers/gpu/drm/tests/drm_mm_test.c Arthur Grillo
2022-07-08 211nodes[0].start,
Re: PROBLEM: MT8192 panel_edp_probe trace despite recent eDP and aux-bus support patches
Hello Angelo,
thank you for taking a look at these MT8192 issues before. The panel issue
reported in this thread is resolved on v6.8, possibly by the "drm for 6.8"
changes including "chromebook panel support" and we can thus "close" this
thread. Unfortunately, suspend [1] and sound still do not work and I'll follow
up on them in separate threads.
Thank you
Leonard
[1] PROBLEM: mtk_pcie_suspend_noirq sleep hang breaking suspend on MT8192
Asurada Spherion
https://lore.kernel.org/linux-mediatek/600bf03e-3be3-e675-1d59-ecc5aaa2a...@collabora.com/T/#t
September 20, 2023 at 4:14 AM, "AngeloGioacchino Del Regno"
wrote:
> Il 20/09/23 02:58, Leonard Lausen ha scritto:
>
> >
> > Dear AngeloGioacchino, Dear Maintainers,
> >
> > on MT8192 Asurada Spherion (Acer 514), I observe the following trace
> > related to
> >
> > eDP and aux-bus during bootup with tags/mediatek-drm-next-6.6 merged to
> > v6.5.4
> >
> > as well as on plain v6.5.4. Despite the trace, the laptop display works.
> > Given
> >
> > your recent eDP and aux-bus support patches are included in
> >
> > tags/mediatek-drm-next-6.6, I thought reporting this may be helpful. (I'm
> >
> > unable to validate v6.6-rc2 currently, as there's a regression breaking
> > boot.)
> >
>
> Hello Leonard,
>
> thanks for sending me this snippet.
>
> This is not in any way connected to my eDP/aux-bus patch series, infact this
>
> warning happens because your machine has got a new/different panel, read
> below:
>
> if (WARN_ON(!panel->detected_panel)) {
>
> dev_warn(dev,
>
> "Unknown panel %s %#06x, using conservative timings\n",
>
> vend, product_id);
>
> [ 4.089721] panel-simple-dp-aux aux-3-0058: Unknown panel CMN 0x142b, using
> conservative timings
>
> I'll try to retrieve informations about this new panel and add it to panel-edp
>
> as soon as possible.
>
> Thanks!
>
> Angelo
>
> >
> > [ 3.808189] [ cut here ]
> >
> > [ 3.812840] WARNING: CPU: 7 PID: 10 at
> > drivers/gpu/drm/panel/panel-edp.c:758 panel_edp_probe+0x488/0x4f0
> >
> > [ 3.822370] Modules linked in:
> >
> > [ 3.825428] CPU: 7 PID: 10 Comm: kworker/u16:0 Not tainted 6.5.4-cos-mt9+
> > #1
> >
> > [ 3.832476] Hardware name: Google Spherion (rev0 - 3) (DT)
> >
> > [ 3.837959] Workqueue: events_unbound deferred_probe_work_func
> >
> > [ 3.843797] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> >
> > [ 3.850757] pc : panel_edp_probe+0x488/0x4f0
> >
> > [ 3.855025] lr : panel_edp_probe+0x29c/0x4f0
> >
> > [ 3.859291] sp : 8000800d3710
> >
> > [ 3.862600] x29: 8000800d3710 x28: x27:
> >
> >
> > [ 3.869737] x26: 60b44002d005 x25: a4a68e990418 x24:
> >
> >
> > [ 3.875193] usb 1-1: new high-speed USB device number 2 using xhci-mtk
> >
> > [ 3.876862] x23: 60b446542680 x22: a4a68db8d5b0 x21:
> > 60b4452d
> >
> > [ 3.876869] x20: x19: 60b441052480 x18:
> > 000a8360
> >
> > [ 3.876873] x17: 001f x16: x15:
> > 0001
> >
> > [ 3.904812] x14: 0060f827 x13: 9b00200a4341452d x12:
> >
> >
> > [ 3.911948] x11: 0001 x10: x9 :
> > 60b446523900
> >
> > [ 3.919084] x8 : 60b446523900 x7 : 435e6d06 x6 :
> > 40395246b460
> >
> > [ 3.926220] x5 : 0043 x4 : 142b x3 :
> > 004e
> >
> > [ 3.933356] x2 : x1 : a4a68db8d9a0 x0 :
> > 0dae142b
> >
> > [ 3.940492] Call trace:
> >
> > [ 3.942933] panel_edp_probe+0x488/0x4f0
> >
> > [ 3.946851] panel_edp_dp_aux_ep_probe+0x38/0x50
> >
> > [ 3.951466] dp_aux_ep_probe+0x34/0xf4
> >
> > [ 3.955211] really_probe+0x148/0x2ac
> >
> > [ 3.958868] __driver_probe_device+0x78/0x12c
> >
> > [ 3.963221] driver_probe_device+0x3c/0x160
> >
> > [ 3.967400] __device_attach_driver+0xb8/0x138
> >
> > [ 3.971841] bus_for_each_drv+0x80/0xdc
> >
> > [ 3.975672] __device_attach+0x9c/0x188
> >
> > [ 3.979503] device_initial_probe+0x14/0x20
> >
> > [ 3.983683] bus_probe_device+0xac/0xb0
> >
> > [ 3.987515] device_add+0x5bc/0x778
> >
> > [ 3.990999] device_register+0x20/0x30
> >
> > [ 3.994742] of_dp_aux_populate_bus+0xc8/0x19c
> >
> > [ 3.999181] devm_of_dp_aux_populate_bus+0x18/0x80
> >
> > [ 4.003968] anx7625_i2c_probe+0x7bc/0x9b4
> >
> > [ 4.008062] i2c_device_probe+0x148/0x290
> >
> > [ 4.011724] usb 1-1: New USB device found, idVendor=05e3, idProduct=0610,
> > bcdDevice=65.01
> >
> > [ 4.012062] really_probe+0x148/0x2ac
> >
> > [ 4.012064] __driver_probe_device+0x78/0x12c
> >
> > [ 4.020243] usb 1-1: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> >
> > [ 4.023879] driver_probe_device+0x3c/0x160
> >
> > [ 4.023882] __device_attach_driver+0xb8/0x138
> >
> > [ 4.023884] bus_for_each_drv+0x80/0xdc
> >
> > [ 4.028232] usb
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/tests/drm_mm_test.c: In function 'drm_test_mm_debug':
drivers/gpu/drm/tests/drm_mm_test.c:191:32: error: implicit declaration of
function 'drm_debug_printer'; did you mean 'drm_dbg_printer'?
[-Werror=implicit-function-declaration]
191 | struct drm_printer p = drm_debug_printer(test->name);
|^
|drm_dbg_printer
drivers/gpu/drm/tests/drm_mm_test.c:191:32: error: invalid initializer
cc1: all warnings being treated as errors
Caused by commit
e154c4fc7bf2 ("drm: remove drm_debug_printer in favor of drm_dbg_printer")
I have used the drm-misc tree from next-20240209 for today.
--
Cheers,
Stephen Rothwell
pgprCG0cLsddX.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Tue, 6 Feb 2024 15:28:50 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> In function 'i915_ttm_placement_from_obj',
> inlined from 'i915_ttm_get_pages' at
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: error: 'places[0].flags' is
> used uninitialized [-Werror=uninitialized]
> 165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
> | ~^~
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'i915_ttm_get_pages':
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:837:26: note: 'places' declared here
> 837 | struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
> | ^~
>
> Caused by commit
>
> a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
>
> I applied the following hack for today:
>
> From: Stephen Rothwell
> Date: Tue, 6 Feb 2024 15:17:54 +1100
> Subject: [PATCH] drm/ttm: initialise places
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 80c6cafc8887..34e699e67c25 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -834,7 +834,7 @@ static int __i915_ttm_get_pages(struct
> drm_i915_gem_object *obj,
>
> static int i915_ttm_get_pages(struct drm_i915_gem_object *obj)
> {
> - struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
> + struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1] = {};
> struct ttm_placement placement;
>
> /* restricted by sg_alloc_table */
> --
> 2.43.0
I am still applying the above patch :-(
--
Cheers,
Stephen Rothwell
pgppH_ubB7Kvw.pgp
Description: OpenPGP digital signature
[PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not sync properly. In these instances, adjust htotal
and hsync to round the HFP up, and recalculate the htotal.
Tested-by: Frieder Schrempf # Kontron BL i.MX8MM
with HDMI monitor
Signed-off-by: Adam Ford
---
V2: No changes
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 8476650c477c..52939211fe93 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
*bridge,
adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
}
+ /*
+* When using video sync pulses, the HFP, HBP, and HSA are divided
between
+* the available lanes if there is more than one lane. For certain
+* timings and lane configurations, the HFP may not be evenly divisible.
+* If the HFP is rounded down, it ends up being too small which can
cause
+* some monitors to not sync properly. In these instances, adjust htotal
+* and hsync to round the HFP up, and recalculate the htotal. Through
trial
+* and error, it appears that the HBP and HSA do not appearto need the
same
+* correction that HFP does.
+*/
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1)
{
+ int hfp = adjusted_mode->hsync_start - adjusted_mode->hdisplay;
+ int remainder = hfp % dsi->lanes;
+
+ if (remainder) {
+ adjusted_mode->hsync_start += remainder;
+ adjusted_mode->hsync_end += remainder;
+ adjusted_mode->htotal += remainder;
+ }
+ }
+
return 0;
}
--
2.43.0
[PATCH V2 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
As noted by Frieder, there are descripencies between the reference
manuals of the Mini, Nano and Plus, so I reached out to my NXP
rep and got the following response regarding the varing notes
in the documentation.
"Yes it is definitely wrong, the one that is part of the NOTE in
MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
not correct. I will report this to Doc team, the one customer should
be take into account is the Table 13-40 DPHY PLL Parameters and the
Note above."
With this patch, the clock rates now match the values used in NXP's
downstream kernel.
Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
Signed-off-by: Adam Ford
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
---
V2: Only update the commit message to reflect why these values
were chosen. No code change present
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 95fedc68b0ae..8476650c477c 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -574,8 +574,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
samsung_dsim *dsi,
u16 _m, best_m;
u8 _s, best_s;
- p_min = DIV_ROUND_UP(fin, (12 * MHZ));
- p_max = fin / (6 * MHZ);
+ p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
+ p_max = fin / (driver_data->pll_fin_min * MHZ);
for (_p = p_min; _p <= p_max; ++_p) {
for (_s = 0; _s <= 5; ++_s) {
--
2.43.0
Re: [PATCH][next] drm/i915/gvt: remove redundant assignment to pointer map
On Fri, 9 Feb 2024 16:08:29 +
Colin Ian King wrote:
> The pointer map is being initialized with a value that is never
> read, it is being re-assigned later on in a for-loop. The
> initialization is redundant and can be removed.
>
> Cleans up clang scan build warning:
> drivers/gpu/drm/i915/gvt/interrupt.c:346:28: warning: Value stored to
> 'map' during its initialization is never read [deadcode.DeadStores]
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
> b/drivers/gpu/drm/i915/gvt/interrupt.c index
> c8e7dfc9f791..8c8e37f50a45 100644 ---
> a/drivers/gpu/drm/i915/gvt/interrupt.c +++
> b/drivers/gpu/drm/i915/gvt/interrupt.c @@ -343,7 +343,7 @@ static
> void update_upstream_irq(struct intel_vgpu *vgpu, {
> struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
> struct intel_gvt_irq *irq = >gvt->irq;
> - struct intel_gvt_irq_map *map = irq->irq_map;
> + struct intel_gvt_irq_map *map;
> struct intel_gvt_irq_info *up_irq_info = NULL;
> u32 set_bits = 0;
> u32 clear_bits = 0;
Thanks for the patch!
Reviewed-by: Zhi Wang
Re: [PATCH v2 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On Sun, 11 Feb 2024 at 19:18, Abhinav Kumar wrote:
>
>
>
> On 2/10/2024 10:57 PM, Dmitry Baryshkov wrote:
> > On Sun, 11 Feb 2024 at 06:06, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/10/2024 1:46 PM, Dmitry Baryshkov wrote:
> >>> On Sat, 10 Feb 2024 at 20:50, Abhinav Kumar
> >>> wrote:
>
>
>
> On 2/10/2024 10:14 AM, Abhinav Kumar wrote:
> >
> >
> > On 2/10/2024 2:09 AM, Dmitry Baryshkov wrote:
> >> On Sat, 10 Feb 2024 at 03:52, Paloma Arellano
> >> wrote:
> >>>
> >>> Add support to pack and send the VSC SDP packet for DP. This therefore
> >>> allows the transmision of format information to the sinks which is
> >>> needed for YUV420 support over DP.
> >>>
> >>> Changes in v2:
> >>>- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
> >>>- Remove dp_sdp from the dp_catalog struct since this data
> >>> is
> >>> being allocated at the point used
> >>>- Create a new function in dp_utils to pack the VSC SDP
> >>> data
> >>> into a buffer
> >>>- Create a new function that packs the SDP header bytes
> >>> into a
> >>> buffer. This function is made generic so that it can be
> >>> utilized by dp_audio
> >>> header bytes into a buffer
> >>>- Create a new function in dp_utils that takes the packed
> >>> buffer
> >>> and writes to the DP_GENERIC0_* registers
> >>>- Split the dp_catalog_panel_config_vsc_sdp() function
> >>> into two
> >>> to disable/enable sending VSC SDP packets
> >>>- Check the DP HW version using the original useage of
> >>> dp_catalog_hw_revision() and correct the version checking
> >>> logic
> >>>- Rename dp_panel_setup_vsc_sdp() to
> >>> dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
> >>> currently VSC SDP is only being set up to support YUV420
> >>> modes
> >>>
> >>> Signed-off-by: Paloma Arellano
> >>> ---
> >>> drivers/gpu/drm/msm/dp/dp_catalog.c | 105
> >>>
> >>> drivers/gpu/drm/msm/dp/dp_catalog.h | 6 ++
> >>> drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 ++
> >>> drivers/gpu/drm/msm/dp/dp_panel.c | 59
> >>> drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
> >>> drivers/gpu/drm/msm/dp/dp_utils.c | 80 +
> >>> drivers/gpu/drm/msm/dp/dp_utils.h | 3 +
> >>> 7 files changed, 260 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> >>> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> >>> index 5d84c089e520a..0f28a4897b7b7 100644
> >>> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> >>> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> >>> @@ -901,6 +901,111 @@ int dp_catalog_panel_timing_cfg(struct
> >>> dp_catalog *dp_catalog)
> >>>return 0;
> >>> }
> >>>
> >>
> >>
> >>
> >>> +static int dp_panel_setup_vsc_sdp_yuv_420(struct dp_panel *dp_panel)
> >>> +{
> >>> + struct dp_catalog *catalog;
> >>> + struct dp_panel_private *panel;
> >>> + struct dp_display_mode *dp_mode;
> >>> + struct dp_sdp_header sdp_header;
> >>> + struct drm_dp_vsc_sdp vsc_sdp_data;
> >>> + size_t buff_size;
> >>> + u32 gen_buffer[10];
> >>> + int rc = 0;
> >>> +
> >>> + if (!dp_panel) {
> >>> + DRM_ERROR("invalid input\n");
> >>> + rc = -EINVAL;
> >>> + return rc;
> >>> + }
> >>> +
> >>> + panel = container_of(dp_panel, struct dp_panel_private,
> >>> dp_panel);
> >>> + catalog = panel->catalog;
> >>> + dp_mode = _panel->dp_mode;
> >>> + buff_size = sizeof(gen_buffer);
> >>> +
> >>> + memset(_header, 0, sizeof(sdp_header));
> >>> + memset(_sdp_data, 0, sizeof(vsc_sdp_data));
> >>> +
> >>> + /* VSC SDP header as per table 2-118 of DP 1.4 specification
> >>> */
> >>> + sdp_header.HB0 = 0x00;
> >>> + sdp_header.HB1 = 0x07;
> >>> + sdp_header.HB2 = 0x05;
> >>> + sdp_header.HB3 = 0x13;
> >>
> >> This should go to the packing function.
> >>
> >
> > We can but
> >
> > the header bytes can change based on the format. These values are
> > specific to YUV420. Thats why this part was kept outside of the generic
> > vsc sdp packing. Today we support only YUV420 VSC SDP so we can move it
> > but this was the reason.
> >>>
> >>> These values can be set from the sdp_type, revision and length fields
> >>> of struct drm_dp_vsc_sdp.
> >>> The function
Re: [PATCH v2 0/6] Pinephone video out fixes (flipping between two frames)
Hi Frank,
On Sun, Feb 11, 2024 at 04:09:16PM +0100, Frank Oltmanns wrote:
> Hi Ondřej,
>
> On 2024-02-05 at 17:02:00 +0100, Ondřej Jirman wrote:
> > On Mon, Feb 05, 2024 at 04:54:07PM +0100, Ondřej Jirman wrote:
> >> On Mon, Feb 05, 2024 at 04:22:23PM +0100, Frank Oltmanns wrote:
> >>
> >> [...]
> >>
> >> Also sunxi-ng clk driver does apply NM factors at once to PLL_GPU clock,
> >> which can cause sudden frequency increase beyond intended output frequency,
> >> because division is applied immediately while multiplication is reflected
> >> slowly.
> >>
> >> Eg. if you're changing divider from 7 to 1, you can get a sudden 7x output
> >> frequency spike, before PLL VCO manages to lower the frequency through N
> >> clk
> >> divider feedback loop and lock on again. This can mess up whatever's
> >> connected
> >> to the output quite badly.
> >>
> >> You'd have to put logging on kernel writes to PLL_GPU register to see what
> >> is written in there and if divider is lowered significantly on some GPU
> >> devfreq frequency transitions.
>
> By looking at the clocks in clk_summary in debugfs, the rate of PLL-GPU
> always matches the rate of the GPU (at least at 120, 312, and 432 MHz).
> This is further underlined by the fact, that none of the rates can be
> achieved by integer dividing one of the other rates. sunxi-ng would
> only favor a different rate for pll-gpu than the one that is requested
> for the gpu, if pll-gpu is already running at a rate such that there
> exists an M ∈ {1, 2, 3, 4, 5, 6, 7, 8}, where
> rate of pll-gpu / M = requested gpu rate
> or if the requested rate could not be reached directly by pll-gpu. Both
> is not the case for the rates in question (120, 192, 312, and 432 MHz).
>
> This means that the following divisor/multipliers are used by sunxi-ng's
> ccu_nm:
> N = 5, M = 1 for 120 MHz (min value without PATCH 6)
> N = 8, M = 1 for 192 MHz (min value after applying PATCH 6)
> N = 13, M = 1 for 312 MHz
> N = 18, M = 1 for 432 MHz
>
> So, with or without PATCH 6, the divider stays constant and it's only
> the multiplier that changes. This means, there should be no unexpected
> frequency spikes, right?
Maybe. Thanks for giving it a try. There may still be other kinds of glitches
even if the divisor stays the same. It all depends how the register update is
implemented in the PLL block. It's hard to say. I guess, unless Allwinner
guarantees glitchless output from a given PLL when changing its parameters,
you can't rely on the output being clean during changes.
> >> It's also unclear what happens when FRAC_CLK_OUT or PLL_MODE_SEL changes.
>
> Those are not changed once the clock is initialized. The bug however
> occurs hours or days after booting. IMO, this makes it unlikely that this
> could be the culprit.
>
> >> Maybe not much because M is supposed to be set to 1, but you still need to
> >> care when enabling fractional mode, and setting M to 1 because that's
> >> exactly
> >> the bad scenario if M was previously higher than 1.
> >>
> >> It's tricky.
> >>
> >> Having GPU module clock gated during PLL config changes may help! You can
> >> do that without locking yourself out, unlike with the CPU PLL.
> >>
> >> There's a gate enable bit for it at GPU_CLK_REG.SCLK_GATING. (page 122)
>
> The GPU should already be properly gated:
> https://elixir.bootlin.com/linux/v6.7.4/source/drivers/clk/sunxi-ng/ccu-sun50i-a64.c#L599
How so? That's just clock declaration. How does it guarantee the clock to the
module is gated during parent PLL configuration changes?
CLK_SET_RATE_PARENT only gates output on re-parenting, not on parent rate
changes,
according to the header:
https://elixir.bootlin.com/linux/v6.7.4/source/include/linux/clk-provider.h#L19
You'd need perhaps CLK_SET_RATE_GATE *and* still verify that it actually works
as expected via some tracing of gpu clock enable/disable/set_rate and pll-gpu
set_rate. CLK_SET_RATE_GATE seems confusingly docummented:
https://elixir.bootlin.com/linux/v6.7.4/source/drivers/clk/clk.c#L1034
so I don't particularly trust it does exaclty what the header claims and what
would be needed to test the theory that gating gpu clock during rate change
might help.
kind regards,
o.
> Thank you for your detailed proposal! It was insightful to read. But
> while those were all great ideas, they have all already been taken care
> of. I'm fresh out of ideas again (except for pinning the GPU rate).
>
> Again, thank you so much,
> Frank
>
> >>
> >> Kind regards,
> >>o.
> >>
> >> > I very much appreciate your feedback!
> >> >
> >> > [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805
> >> >
> >> > Signed-off-by: Frank Oltmanns
> >> > ---
> >> > Changes in v2:
> >> > - dts: Increase minimum GPU frequency to 192 MHz.
> >> > - nkm and a64: Add minimum and maximum rate for PLL-MIPI.
> >> > - nkm: Use the same approach for skipping invalid rates in
> >> > ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj().
> >> > - nkm: Improve
Re: [PATCH] drm/lcdif: Do not disable clock on already suspended hardware
On 1/18/24 19:39, Marek Vasut wrote:
In case the LCDIF is enabled in DT but unused, the clock used by the
LCDIF are not enabled. Those clock may even have a use count of 0 in
case there are no other users of those clock. This can happen e.g. in
case the LCDIF drives HDMI bridge which has no panel plugged into the
HDMI connector.
Do not attempt to disable clock in the suspend callback and re-enable
clock in the resume callback unless the LCDIF is enabled and was in
use before the system entered suspend, otherwise the driver might end
up trying to disable clock which are already disabled with use count
0, and would trigger a warning from clock core about this condition.
Note that the lcdif_rpm_suspend() and lcdif_rpm_resume() functions
internally perform the clock disable and enable operations and act
as runtime PM hooks too.
Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
---
Cc: Daniel Vetter
Cc: David Airlie
Cc: Fabio Estevam
Cc: Liu Ying
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: NXP Linux Team
Cc: Pengutronix Kernel Team
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Stefan Agner
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index ea10bf81582e9..0f895b8a99d62 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -343,6 +343,9 @@ static int __maybe_unused lcdif_suspend(struct device *dev)
if (ret)
return ret;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
return lcdif_rpm_suspend(dev);
}
@@ -350,7 +353,8 @@ static int __maybe_unused lcdif_resume(struct device *dev)
{
struct drm_device *drm = dev_get_drvdata(dev);
- lcdif_rpm_resume(dev);
+ if (!pm_runtime_suspended(dev))
+ lcdif_rpm_resume(dev);
return drm_mode_config_helper_resume(drm);
}
Is this OK to pick up ? Some AB/RB/input would be appreciated, thanks !
[PATCH] drm/amdgpu/swsmu: Fix if statement in smu_baco_get_state()
In smu_baco_get_state() smu->ppt_funcs->baco_get_state is checked for NULL.
If it is NULL then the pointer is dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 6c45e480fe23 ("drm/amd/powerplay: clear the swSMU code layer")
Signed-off-by: Daniil Dulov
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index ee27970cfff9..0fadb6aacd4b 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -2497,7 +2497,7 @@ bool smu_baco_is_support(struct smu_context *smu)
int smu_baco_get_state(struct smu_context *smu, enum smu_baco_state *state)
{
- if (smu->ppt_funcs->baco_get_state)
+ if (!smu->ppt_funcs->baco_get_state)
return -EINVAL;
mutex_lock(>mutex);
--
2.25.1
Re: [PATCH v2 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On 2/10/2024 10:57 PM, Dmitry Baryshkov wrote:
On Sun, 11 Feb 2024 at 06:06, Abhinav Kumar wrote:
On 2/10/2024 1:46 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 20:50, Abhinav Kumar wrote:
On 2/10/2024 10:14 AM, Abhinav Kumar wrote:
On 2/10/2024 2:09 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano
wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog struct since this data is
being allocated at the point used
- Create a new function in dp_utils to pack the VSC SDP data
into a buffer
- Create a new function that packs the SDP header bytes into a
buffer. This function is made generic so that it can be
utilized by dp_audio
header bytes into a buffer
- Create a new function in dp_utils that takes the packed
buffer
and writes to the DP_GENERIC0_* registers
- Split the dp_catalog_panel_config_vsc_sdp() function into two
to disable/enable sending VSC SDP packets
- Check the DP HW version using the original useage of
dp_catalog_hw_revision() and correct the version checking
logic
- Rename dp_panel_setup_vsc_sdp() to
dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
currently VSC SDP is only being set up to support YUV420
modes
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 105
drivers/gpu/drm/msm/dp/dp_catalog.h | 6 ++
drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 ++
drivers/gpu/drm/msm/dp/dp_panel.c | 59
drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
drivers/gpu/drm/msm/dp/dp_utils.c | 80 +
drivers/gpu/drm/msm/dp/dp_utils.h | 3 +
7 files changed, 260 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..0f28a4897b7b7 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -901,6 +901,111 @@ int dp_catalog_panel_timing_cfg(struct
dp_catalog *dp_catalog)
return 0;
}
+static int dp_panel_setup_vsc_sdp_yuv_420(struct dp_panel *dp_panel)
+{
+ struct dp_catalog *catalog;
+ struct dp_panel_private *panel;
+ struct dp_display_mode *dp_mode;
+ struct dp_sdp_header sdp_header;
+ struct drm_dp_vsc_sdp vsc_sdp_data;
+ size_t buff_size;
+ u32 gen_buffer[10];
+ int rc = 0;
+
+ if (!dp_panel) {
+ DRM_ERROR("invalid input\n");
+ rc = -EINVAL;
+ return rc;
+ }
+
+ panel = container_of(dp_panel, struct dp_panel_private,
dp_panel);
+ catalog = panel->catalog;
+ dp_mode = _panel->dp_mode;
+ buff_size = sizeof(gen_buffer);
+
+ memset(_header, 0, sizeof(sdp_header));
+ memset(_sdp_data, 0, sizeof(vsc_sdp_data));
+
+ /* VSC SDP header as per table 2-118 of DP 1.4 specification */
+ sdp_header.HB0 = 0x00;
+ sdp_header.HB1 = 0x07;
+ sdp_header.HB2 = 0x05;
+ sdp_header.HB3 = 0x13;
This should go to the packing function.
We can but
the header bytes can change based on the format. These values are
specific to YUV420. Thats why this part was kept outside of the generic
vsc sdp packing. Today we support only YUV420 VSC SDP so we can move it
but this was the reason.
These values can be set from the sdp_type, revision and length fields
of struct drm_dp_vsc_sdp.
The function intel_dp_vsc_sdp_pack() is pretty much close to what I had in mind.
+
+ /* VSC SDP Payload for DB16 */
Comments are useless more or less. The code fills generic information
structure which might or might not be packed to the data buffer.
+ vsc_sdp_data.pixelformat = DP_PIXELFORMAT_YUV420;
+ vsc_sdp_data.colorimetry = DP_COLORIMETRY_DEFAULT;
+
+ /* VSC SDP Payload for DB17 */
+ vsc_sdp_data.dynamic_range = DP_DYNAMIC_RANGE_CTA;
+
+ /* VSC SDP Payload for DB18 */
+ vsc_sdp_data.content_type = DP_CONTENT_TYPE_GRAPHICS;
+
+ vsc_sdp_data.bpc = dp_mode->bpp / 3;
Consider extracting intel_dp_compute_vsc_colorimetry() and using it.
intel_dp_compute_vsc_colorimetry() uses colorspace property to pick
YUV420, we do not.
Intel function also uses output_format, but it's true, it is full of
Intel specifics.
Right now, its a pure driver decision to use YUV420
when the mode is supported only in that format.
Also, many params are to be used within this function cached inside
intel_crtc_state . We will first need to make that API more generic to
be re-usable by others.
Re: [PATCH v2 5/6] drm/panel: st7703: Drive XBD599 panel at higher clock rate
On 2024-02-08 at 20:05:08 +0100, Maxime Ripard wrote: > [[PGP Signed Part:Undecided]] > Hi Frank, > > On Mon, Feb 05, 2024 at 04:22:28PM +0100, Frank Oltmanns wrote: >> This panel is used in the pinephone that runs on a Allwinner A64 SOC. >> The SOC requires pll-mipi to run at more than 500 MHz. >> >> This is the relevant clock tree: >> pll-mipi >> tcon0 >>tcon-data-clock >> >> tcon-data-clock has to run at 1/4 the DSI per-lane bit rate. The XBD599 >> has 24 bpp and 4 lanes. Therefore, the resulting requested >> tcon-data-clock rate is: >> crtc_clock * 1000 * (24 / 4) / 4 >> >> tcon-data-clock runs at tcon0 / 4 (fixed divisor), so it requests a >> parent rate of >> 4 * (crtc_clock * 1000 * (24 / 4) / 4) >> >> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi. >> >> pll-mipi's constraint to run at 500MHz or higher forces us to have a >> crtc_clock >= 8 kHz if we want a 60 Hz vertical refresh rate. >> >> Change [hv]sync_(start|end) so that we reach a clock rate of 83502 kHz >> so that it is high enough to align with pll-pipi limits. >> >> Signed-off-by: Frank Oltmanns > > That commit log is great, but it's kind of off-topic. It's a panel > driver, it can be used on any MIPI-DSI controller, the only relevant > information there should be the panel timings required in the datasheet. > > The PLL setup is something for the MIPI-DSI driver to adjust, not for > the panel to care for. > I absolutely agree. It even was the reason for my submission of a sunxi-ng patch series last year that was accepted, to make pll-mipi more flexible. :) The only remaining option I currently see for adjusting the sunxi-ng driver to further accomodate the panel, is trying to use a higher divisor than 4 for calculating tcon-data-clock from tcon0. I remember reading a discussion about this, but as far as I remember that proposal was rejected (by you, IIRC). While I appreciate other suggestion as well, I'll look into options for using a different divisor than 4. Best regards, Frank > > Maxime > > [[End of PGP Signed Part]]
Re: [PATCH v2 0/6] Pinephone video out fixes (flipping between two frames)
Hi Ondřej,
On 2024-02-05 at 17:02:00 +0100, Ondřej Jirman wrote:
> On Mon, Feb 05, 2024 at 04:54:07PM +0100, Ondřej Jirman wrote:
>> On Mon, Feb 05, 2024 at 04:22:23PM +0100, Frank Oltmanns wrote:
>> > On some pinephones the video output sometimes freezes (flips between two
>> > frames) [1]. It seems to be that the reason for this behaviour is that
>> > PLL-MIPI, PLL-GPU and GPU are operating outside their limits.
>> >
>> > In this patch series I propose the followin changes:
>> > 1. sunxi-ng: Adhere to the following constraints given in the
>> > Allwinner A64 Manual regarding PLL-MIPI:
>> > * M/N <= 3
>> > * (PLL_VIDEO0)/M >= 24MHz
>> > * 500MHz <= clockrate <= 1400MHz
>> >
>> > 2. Choose a higher clock rate for the ST7703 based XDB599 panel, so
>> > that the panel function well with the Allwinner A64 SOC. PLL-MIPI
>> > must run between 500 MHz and 1.4 GHz. As PLL-MIPI runs at 6 times
>> > the panel's clock rate, we need the panel's clock to be at least
>> > 83.333 MHz.
>> >
>> > 3. Increase the minimum frequency in the A64 DTS OPPs from 120 MHz to
>> > 192 MHz. This further reduces the issue.
>> >
>> > Unfortunately, with these patches the issue [1] is not completely gone,
>> > but becomes less likely.
>> >
>> > Note, that when pinning the GPU to 432 MHz the issue completely
>> > disappears for me. I've searched the BSP and could not find any
>> > indication that supports the idea of having the three OPPs. The only
>> > frequency I found in the BPSs for A64 is 432 MHz, that has also proven
>> > stable for me. So, while increasing the minimum frequency to 192 MHz
>> > reduces the issue, should we maybe instead set the GPU to a fixed 432
>> > MHz instead?
>>
>> Per A64 User Manual 1.1 page 81:
>>
>> (9). Clock output of PLL_GPU can be used for GPU;and dynamic frequency
>> scaling is not supported;
>
> You may be able to elegantly work around this by pinning PLL_GPU to a certain
> frequency (assing it in DT and then don't decalre gpu clock as
> CLK_SET_RATE_PARENT). Say 432 MHz for PLL and then do the scaling via
> GPU_CLK_REG
> N divider between 432MHz and 216MHz and maybe 108MHz if that brings any gains.
>
I really like this idea. Unfortunately, it seems that the divisor of the
GPU_CLK_REG must always be set to 1. I tried to convey this info in the
commit message for PATCH 6. If using a different divisor than 1 the bug
I'm trying to fix here occurs within minutes. Nevertheless, I gave your
proposal a quick try - it seems so elegant. Unfortunately, but not
unexpectedly, the bug occured almost immediately.
> Then you can perhaps sidestep all these potential issues with PLL_GPU and
> lack of DVFS support decalred in the manual.
>
> regards,
> o.
>
>> Also sunxi-ng clk driver does apply NM factors at once to PLL_GPU clock,
>> which can cause sudden frequency increase beyond intended output frequency,
>> because division is applied immediately while multiplication is reflected
>> slowly.
>>
>> Eg. if you're changing divider from 7 to 1, you can get a sudden 7x output
>> frequency spike, before PLL VCO manages to lower the frequency through N clk
>> divider feedback loop and lock on again. This can mess up whatever's
>> connected
>> to the output quite badly.
>>
>> You'd have to put logging on kernel writes to PLL_GPU register to see what
>> is written in there and if divider is lowered significantly on some GPU
>> devfreq frequency transitions.
By looking at the clocks in clk_summary in debugfs, the rate of PLL-GPU
always matches the rate of the GPU (at least at 120, 312, and 432 MHz).
This is further underlined by the fact, that none of the rates can be
achieved by integer dividing one of the other rates. sunxi-ng would
only favor a different rate for pll-gpu than the one that is requested
for the gpu, if pll-gpu is already running at a rate such that there
exists an M ∈ {1, 2, 3, 4, 5, 6, 7, 8}, where
rate of pll-gpu / M = requested gpu rate
or if the requested rate could not be reached directly by pll-gpu. Both
is not the case for the rates in question (120, 192, 312, and 432 MHz).
This means that the following divisor/multipliers are used by sunxi-ng's
ccu_nm:
N = 5, M = 1 for 120 MHz (min value without PATCH 6)
N = 8, M = 1 for 192 MHz (min value after applying PATCH 6)
N = 13, M = 1 for 312 MHz
N = 18, M = 1 for 432 MHz
So, with or without PATCH 6, the divider stays constant and it's only
the multiplier that changes. This means, there should be no unexpected
frequency spikes, right?
>> It's also unclear what happens when FRAC_CLK_OUT or PLL_MODE_SEL changes.
Those are not changed once the clock is initialized. The bug however
occurs hours or days after booting. IMO, this makes it unlikely that this
could be the culprit.
>> Maybe not much because M is supposed to be set to 1, but you still need to
>> care when enabling fractional mode, and setting M to 1 because that's exactly
>> the bad scenario if M was previously higher than
[PATCH v5 1/3] drm: Add support to get EDID from ACPI
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by: Mario Limonciello
---
v1->v2:
* Split code from previous amdgpu specific helper to generic drm helper.
v2->v3:
* Add an extra select to fix a variety of randconfig errors found from
LKP robot.
v3->v4:
* Return struct drm_edid
v4->v5:
* Rename to drm_edid_read_acpi
* Drop selects
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/drm_edid.c | 113 +---
include/drm/drm_connector.h | 6 ++
include/drm/drm_edid.h | 1 +
4 files changed, 119 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2520db0b776e..a49740c528b9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -103,6 +103,13 @@ config DRM_KMS_HELPER
help
CRTC helpers for KMS drivers.
+config DRM_ACPI_HELPER
+ tristate "ACPI support in DRM"
+ depends on DRM
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
+ help
+ ACPI helpers for DRM drivers.
+
config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
bool "Enable refcount backtrace history in the DP MST helpers"
depends on STACKTRACE_SUPPORT
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 69c68804023f..096c278b6f66 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -2188,6 +2189,62 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int
block, size_t len)
return ret == xfers ? 0 : -1;
}
+/**
+ * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
+ * @data: struct drm_connector
+ * @buf: EDID data buffer to be filled
+ * @block: 128 byte EDID block to start fetching from
+ * @len: EDID data buffer length to fetch
+ *
+ * Try to fetch EDID information by calling acpi_video_get_edid() function.
+ *
+ * Return: 0 on success or error code on failure.
+ */
+static int
+drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
+{
+ struct drm_connector *connector = data;
+ struct drm_device *ddev = connector->dev;
+ struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
+ unsigned char start = block * EDID_LENGTH;
+ void *edid;
+ int r;
+
+ if (!acpidev)
+ return -ENODEV;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* fetch the entire edid from BIOS */
+ if (IS_REACHABLE(CONFIG_DRM_ACPI_HELPER)) {
+ r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1,
);
+ if (r < 0) {
+ DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+ return -EINVAL;
+ }
+ } else {
+ r = -EOPNOTSUPP;
+ }
+ if (len > r || start > r || start + len > r) {
+ r = -EINVAL;
+ goto cleanup;
+ }
+
+ memcpy(buf, edid + start, len);
+ r = 0;
+
+cleanup:
+ kfree(edid);
+
+ return r;
+}
+
static void connector_bad_edid(struct drm_connector *connector,
const struct edid *edid, int num_blocks)
{
@@ -2621,7 +2678,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
* @connector: connector we're probing
* @adapter: I2C adapter to use for DDC
*
- * Poke the given I2C channel to grab EDID data if possible. If found,
+ * If the connector allows it, try to fetch EDID data using ACPI. If not found
+ * poke the given I2C channel to grab EDID data if possible. If found,
* attach it to the connector.
*
* Return: Pointer to valid EDID or NULL if we couldn't find any.
@@ -2629,20 +2687,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct edid *edid;
+ struct edid *edid = NULL;
if (connector->force == DRM_FORCE_OFF)
return NULL;
- if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
- return NULL;
+ if (connector->acpi_edid_allowed)
+ edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
connector, NULL);
+
+ if (!edid) {
+ if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
+ return NULL;
+ edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
adapter, NULL);
+ }
- edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter,
NULL);
[PATCH v5 2/3] drm/amd: Fetch the EDID from _DDC if available for eDP
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel. If a user prefers to use the EDID from
the panel, offer a module parameter that would disable this.
Signed-off-by: Mario Limonciello
---
v4->v5:
* rebase on v5 changes
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 ++
5 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 543ed9de5a6d..399885251714 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -217,6 +217,7 @@ extern int amdgpu_smartshift_bias;
extern int amdgpu_use_xgmi_p2p;
extern int amdgpu_mtype_local;
extern bool enforce_isolation;
+extern bool acpi_edid;
#ifdef CONFIG_HSA_AMD
extern int sched_policy;
extern bool debug_evictions;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 9caba10315a8..9165a199ac9b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -281,6 +281,9 @@ static void amdgpu_connector_get_edid(struct drm_connector
*connector)
if (amdgpu_connector->edid)
return;
+ /* if the BIOS specifies the EDID via _DDC, prefer this */
+ connector->acpi_edid_allowed = acpi_edid;
+
/* on hw with routers, select right port */
if (amdgpu_connector->router.ddc_valid)
amdgpu_i2c_router_select_ddc_port(amdgpu_connector);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index edc042db4ea8..123f1128d14e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -166,6 +166,7 @@ uint amdgpu_sdma_phase_quantum = 32;
char *amdgpu_disable_cu;
char *amdgpu_virtual_display;
bool enforce_isolation;
+bool acpi_edid = true;
/*
* OverDrive(bit 14) disabled by default
* GFX DCS(bit 19) disabled by default
@@ -991,6 +992,13 @@ MODULE_PARM_DESC(wbrf,
"Enable Wifi RFI interference mitigation (0 = disabled, 1 = enabled, -1
= auto(default)");
module_param_named(wbrf, amdgpu_wbrf, int, 0444);
+/**
+ * DOC: acpi_edid (bool)
+ * Try to fetch EDID for eDP display from BIOS using ACPI _DDC method.
+ */
+module_param(acpi_edid, bool, 0444);
+MODULE_PARM_DESC(acpi_edid, "Fetch EDID for eDP display from BIOS");
+
/* These devices are not supported by amdgpu.
* They are supported by the mach64, r128, radeon drivers
*/
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ed90fc8fee9f..0b3a19d3d43a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6619,8 +6619,10 @@ static void amdgpu_dm_connector_funcs_force(struct
drm_connector *connector)
* Note: drm_get_edid gets edid in the following order:
* 1) override EDID if set via edid_override debugfs,
* 2) firmware EDID if set via edid_firmware module parameter
-* 3) regular DDC read.
+* 3) ACPI EDID if allowed via module parameter
+* 4) regular DDC read.
*/
+ connector->acpi_edid_allowed = acpi_edid;
edid = drm_get_edid(connector, _connector->ddc_bus->aux.ddc);
if (!edid) {
DRM_ERROR("No EDID found on connector: %s.\n", connector->name);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 85b7f58a7f35..d570a1b6141b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -910,6 +910,8 @@ enum dc_edid_status dm_helpers_read_local_edid(
* do check sum and retry to make sure read correct edid.
*/
do {
+ /* prefer ACPI over panel for eDP */
+ connector->acpi_edid_allowed = acpi_edid;
edid = drm_get_edid(>base, ddc);
--
2.34.1
[PATCH v5 0/3] Add support for getting EDID over ACPI to DRM
This series adds the ability to fetch the EDID through ACPI for laptop panels. Drivers need to opt into the behavior. In this series it's enabled by default for all eDP or LVDS panels with AMDGPU and certain panels for Nouveau. Mario Limonciello (3): drm: Add support to get EDID from ACPI drm/amd: Fetch the EDID from _DDC if available for eDP drm/nouveau: Use drm_edid_read_acpi() helper drivers/gpu/drm/Kconfig | 7 ++ drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 + drivers/gpu/drm/drm_edid.c| 113 -- drivers/gpu/drm/nouveau/nouveau_acpi.c| 27 - drivers/gpu/drm/nouveau/nouveau_acpi.h| 2 - drivers/gpu/drm/nouveau/nouveau_connector.c | 35 +++--- include/drm/drm_connector.h | 6 + include/drm/drm_edid.h| 1 + 12 files changed, 149 insertions(+), 58 deletions(-) -- 2.34.1
[PATCH v5 3/3] drm/nouveau: Use drm_edid_read_acpi() helper
Rather than inventing a wrapper to acpi_video_get_edid() use the
one provided by drm. This fixes two problems:
1. A memory leak that the memory provided by the ACPI call was
never freed.
2. Validation of the BIOS provided blob.
Convert the usage in nouveau_connector_detect_lvds() to use
struct drm_edid at the same time.
Signed-off-by: Mario Limonciello
---
v1->v2:
* New patch
v3->v4:
* Rebase on v4 changes
v4->v5:
* Rebase on v5 changes
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 27
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 --
drivers/gpu/drm/nouveau/nouveau_connector.c | 35 +
3 files changed, 14 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 8f0c69aad248..de9daafb3fbb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -360,33 +360,6 @@ void nouveau_unregister_dsm_handler(void) {}
void nouveau_switcheroo_optimus_dsm(void) {}
#endif
-void *
-nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
-{
- struct acpi_device *acpidev;
- int type, ret;
- void *edid;
-
- switch (connector->connector_type) {
- case DRM_MODE_CONNECTOR_LVDS:
- case DRM_MODE_CONNECTOR_eDP:
- type = ACPI_VIDEO_DISPLAY_LCD;
- break;
- default:
- return NULL;
- }
-
- acpidev = ACPI_COMPANION(dev->dev);
- if (!acpidev)
- return NULL;
-
- ret = acpi_video_get_edid(acpidev, type, -1, );
- if (ret < 0)
- return NULL;
-
- return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
-}
-
bool nouveau_acpi_video_backlight_use_native(void)
{
return acpi_video_backlight_use_native();
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index e39dd8b94b8b..6a3def8e6cca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -10,7 +10,6 @@ bool nouveau_is_v1_dsm(void);
void nouveau_register_dsm_handler(void);
void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
-void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
bool nouveau_acpi_video_backlight_use_native(void);
void nouveau_acpi_video_register_backlight(void);
#else
@@ -19,7 +18,6 @@ static inline bool nouveau_is_v1_dsm(void) { return false; };
static inline void nouveau_register_dsm_handler(void) {}
static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
-static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector) { return NULL; }
static inline bool nouveau_acpi_video_backlight_use_native(void) { return
true; }
static inline void nouveau_acpi_video_register_backlight(void) {}
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 856b3ef5edb8..492035dc8453 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -687,22 +687,13 @@ nouveau_connector_detect_lvds(struct drm_connector
*connector, bool force)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = NULL;
- struct edid *edid = NULL;
+ const struct drm_edid *drm_edid = NULL;
enum drm_connector_status status = connector_status_disconnected;
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder)
goto out;
- /* Try retrieving EDID via DDC */
- if (!drm->vbios.fp_no_ddc) {
- status = nouveau_connector_detect(connector, force);
- if (status == connector_status_connected) {
- edid = nv_connector->edid;
- goto out;
- }
- }
-
/* On some laptops (Sony, i'm looking at you) there appears to
* be no direct way of accessing the panel's EDID. The only
* option available to us appears to be to ask ACPI for help..
@@ -712,10 +703,14 @@ nouveau_connector_detect_lvds(struct drm_connector
*connector, bool force)
* the nouveau decides an entry in the VBIOS FP mode table is
* valid - it's not (rh#613284)
*/
- if (nv_encoder->dcb->lvdsconf.use_acpi_for_edid) {
- edid = nouveau_acpi_edid(dev, connector);
- if (edid) {
- status = connector_status_connected;
+ if (nv_encoder->dcb->lvdsconf.use_acpi_for_edid)
+ connector->acpi_edid_allowed = true;
+
+ /* Try retrieving EDID via BIOS or DDC */
+ if (!drm->vbios.fp_no_ddc ||
nv_encoder->dcb->lvdsconf.use_acpi_for_edid) {
+ status =
Re: [PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
On Sun, 11 Feb 2024 11:51:08 +0200, Tony Lindgren wrote: > The tc358765 is similar to tc358775. The tc358765 just an earlier version > of the hardware, and it's pin and register compatible with tc358775 for > most part. > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml:87:8: [error] empty value in block mapping (empty-values) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: allOf:0:if: None is not of type 'object', 'boolean' from schema $id: http://json-schema.org/draft-07/schema# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: allOf:0:then: 'anyOf' conditional failed, one must be fixed: 'stby-gpios' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems'] 'type' was expected from schema $id: http://devicetree.org/meta-schemas/keywords.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml: ignoring, error in schema: allOf: 0: if Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.example.dtb: /example-0/i2c@78b8000/bridge@f: failed to match any schema with compatible: ['toshiba,tc358775'] Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.example.dtb: /example-1/i2c@78b8000/bridge@f: failed to match any schema with compatible: ['toshiba,tc358775'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240211095144.2589-4-t...@atomide.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
[PATCH v2 1/2] dt-bindings: display: simple: Add boe, bp082wx1-100 8.2" panel
This panel is found on Motorola mapphone tablets mz607 to mz609. Acked-by: Conor Dooley Signed-off-by: Tony Lindgren --- No changes since v1 --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -73,6 +73,8 @@ properties: - auo,t215hvn01 # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel - avic,tm070ddh03 +# BOE BP082WX1-100 8.2" WXGA (1280x800) LVDS panel + - boe,bp082wx1-100 # BOE BP101WX1-100 10.1" WXGA (1280x800) LVDS panel - boe,bp101wx1-100 # BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel -- 2.43.1
[PATCH v2 2/2] drm/panel: simple: Add BOE BP082WX1-100 8.2" panel
The BOE BP082WX1-100 is a 8.2" panel similar to the 10.1" panel
BP101WX1-100. Both panels use the same timings.
Acked-by: Conor Dooley
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Tony Lindgren
---
Changes since v1:
- Update viewport dimensions based on panelook values asa suggested
by Dmitry
---
drivers/gpu/drm/panel/panel-simple.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1367,6 +1367,23 @@ static const struct drm_display_mode
boe_bp101wx1_100_mode = {
.vtotal = 800 + 6 + 8 + 2,
};
+static const struct panel_desc boe_bp082wx1_100 = {
+ .modes = _bp101wx1_100_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 177,
+ .height = 110,
+ },
+ .delay = {
+ .enable = 50,
+ .disable = 50,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct panel_desc boe_bp101wx1_100 = {
.modes = _bp101wx1_100_mode,
.num_modes = 1,
@@ -4343,6 +4360,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "bananapi,s070wv20-ct16",
.data = _s070wv20_ct16,
+ }, {
+ .compatible = "boe,bp082wx1-100",
+ .data = _bp082wx1_100,
}, {
.compatible = "boe,bp101wx1-100",
.data = _bp101wx1_100,
--
2.43.1
[PATCH] Fix divide-by-zero on DP unplug with nouveau
The following trace occurs when using nouveau and unplugging a DP MST adaptor: divide error: [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018 RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 RSP: 0018:b2c5c211fa30 EFLAGS: 00010206 RAX: RBX: RCX: 00f59b00 RDX: RSI: RDI: RBP: b2c5c211fa48 R08: 0001 R09: 0020 R10: 0004 R11: R12: 00023b4a R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010 FS: 7f4a1ca3fa80() GS:91d6edbc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0 Call Trace: ? show_regs+0x6d/0x80 ? die+0x37/0xa0 ? do_trap+0xd4/0xf0 ? do_error_trap+0x71/0xb0 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? exc_divide_error+0x3a/0x70 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? asm_exc_divide_error+0x1b/0x20 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper] nv50_msto_atomic_check+0xda/0x120 [nouveau] drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper] drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper] nv50_disp_atomic_check+0x13f/0x2f0 [nouveau] drm_atomic_check_only+0x668/0xb20 [drm] ? drm_connector_list_iter_next+0x86/0xc0 [drm] drm_atomic_commit+0x58/0xd0 [drm] ? __pfx___drm_printfn_info+0x10/0x10 [drm] drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] drm_connector_property_set_ioctl+0x3b/0x60 [drm] drm_ioctl_kernel+0xb9/0x120 [drm] drm_ioctl+0x2d0/0x550 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] nouveau_drm_ioctl+0x61/0xc0 [nouveau] __x64_sys_ioctl+0xa0/0xf0 do_syscall_64+0x76/0x140 ? do_syscall_64+0x85/0x140 ? do_syscall_64+0x85/0x140 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f4a1cd1a94f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0 R10: R11: 0246 R12: 56347938a220 R13: 000f R14: 563479d9f3f0 R15: Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic snd_rawmidi ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek libahci idma64 intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 dm_crypt raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 joydev input_leds hid_generic usbhid hid nouveau i915 drm_ttm_helper gpu_sched drm_gpuvm drm_exec i2c_algo_bit drm_buddy ttm drm_display_helper drm_kms_helper cec rc_core drm nvme nvme_core mxm_wmi xhci_pci xhci_pci_renesas video wmi pinctrl_cannonlake mac_hid ---[ end trace
[PATCH v3 10/10] drm/bridge: tc358775: Configure hs_rate and lp_rate
The hs_rate and lp_rate may be used by the dsi host for timing
calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
tc358765 has maximurate of 800 Mbps per lane.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -637,6 +637,19 @@ static int tc_attach_host(struct tc_data *tc)
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_LPM;
+ /*
+* The hs_rate and lp_rate are data rate values. The HS mode is
+* differential, while the LP mode is single ended. As the HS mode
+* uses DDR, the DSI clock frequency is half the hs_rate. The 10 Mbs
+* data rate for LP mode is not specified in the bridge data sheet,
+* but seems to be part of the MIPI DSI spec.
+*/
+ if (tc->type == TC358765)
+ dsi->hs_rate = 8;
+ else
+ dsi->hs_rate = 10;
+ dsi->lp_rate = 1000;
+
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
dev_err(dev, "failed to attach dsi to host\n");
--
2.43.0
[PATCH v3 09/10] drm/bridge: tc358775: Add support for tc358765
The tc358775 bridge is pin compatible with earlier tc358765 according to
the tc358774xbg_datasheet_en_20190118.pdf documentation. Compared to the
tc358765, the tc358775 supports a STBY GPIO and higher data rates.
The tc358765 has a register bit for video event mode vs video pulse mode.
We must set it to video event mode for the LCD output to work, and on the
tc358775, this bit no longer exists.
Looks like the registers seem to match otherwise based on a quick glance
comparing the defines to the earlier Android kernel tc358765 driver.
Reviewed-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,6 +108,7 @@
#define RDPKTLN 0x0404 /* Command Read Packet Length */
#define VPCTRL 0x0450 /* Video Path Control */
+#define EVTMODEBIT(5) /* Video event mode enable, tc35876x
only */
#define HTIM1 0x0454 /* Horizontal Timing Control 1 */
#define HTIM2 0x0458 /* Horizontal Timing Control 2 */
#define VTIM1 0x045C /* Vertical Timing Control 1 */
@@ -254,6 +256,11 @@ enum tc358775_ports {
TC358775_LVDS_OUT1,
};
+enum tc3587x5_type {
+ TC358765 = 0x65,
+ TC358775 = 0x75,
+};
+
struct tc_data {
struct i2c_client *i2c;
struct device *dev;
@@ -271,6 +278,8 @@ struct tc_data {
struct gpio_desc*stby_gpio;
u8 lvds_link; /* single-link or dual-link */
u8 bpc;
+
+ enum tc3587x5_type type;
};
static inline struct tc_data *bridge_to_tc(struct drm_bridge *b)
@@ -424,10 +433,16 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, PPI_STARTPPI, PPI_START_FUNCTION);
d2l_write(tc->i2c, DSI_STARTDSI, DSI_RX_START);
+ /* Video event mode vs pulse mode bit, does not exist for tc358775 */
+ if (tc->type == TC358765)
+ val = EVTMODE;
+ else
+ val = 0;
+
if (tc->bpc == 8)
- val = TC358775_VPCTRL_OPXLFMT(1);
+ val |= TC358775_VPCTRL_OPXLFMT(1);
else /* bpc = 6; */
- val = TC358775_VPCTRL_MSF(1);
+ val |= TC358775_VPCTRL_MSF(1);
dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000;
clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 :
DIVIDE_BY_3);
@@ -643,6 +658,7 @@ static int tc_probe(struct i2c_client *client)
tc->dev = dev;
tc->i2c = client;
+ tc->type = (enum tc3587x5_type)(unsigned
long)of_device_get_match_data(dev);
tc->panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
TC358775_LVDS_OUT0, 0);
@@ -704,13 +720,15 @@ static void tc_remove(struct i2c_client *client)
}
static const struct i2c_device_id tc358775_i2c_ids[] = {
- { "tc358775", 0 },
+ { "tc358765", TC358765, },
+ { "tc358775", TC358775, },
{ }
};
MODULE_DEVICE_TABLE(i2c, tc358775_i2c_ids);
static const struct of_device_id tc358775_of_ids[] = {
- { .compatible = "toshiba,tc358775", },
+ { .compatible = "toshiba,tc358765", .data = (void *)TC358765, },
+ { .compatible = "toshiba,tc358775", .data = (void *)TC358775, },
{ }
};
MODULE_DEVICE_TABLE(of, tc358775_of_ids);
--
2.43.0
[PATCH v3 08/10] drm/bridge: tc358775: Enable pre_enable_prev_first flag
Set pre_enable_prev_first to ensure the previous bridge is enabled first. Reviewed-by: Dmitry Baryshkov Reviewed-by: Michael Walle Tested-by: Michael Walle Signed-off-by: Tony Lindgren --- drivers/gpu/drm/bridge/tc358775.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/tc358775.c b/drivers/gpu/drm/bridge/tc358775.c --- a/drivers/gpu/drm/bridge/tc358775.c +++ b/drivers/gpu/drm/bridge/tc358775.c @@ -680,6 +680,7 @@ static int tc_probe(struct i2c_client *client) tc->bridge.funcs = _bridge_funcs; tc->bridge.of_node = dev->of_node; + tc->bridge.pre_enable_prev_first = true; drm_bridge_add(>bridge); i2c_set_clientdata(client, tc); -- 2.43.0
[PATCH v3 07/10] drm/bridge: tc358775: Add burst and low-power modes
Burst and low-power modes are supported both for tc358765 and tc358775.
Reviewed-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -619,7 +619,8 @@ static int tc_attach_host(struct tc_data *tc)
dsi->lanes = tc->num_dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM;
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
--
2.43.0
[PATCH v3 06/10] drm/bridge: tc358775: Get bridge data lanes instead of the DSI host lanes
The current code assumes the data-lanes property is configured on the
DSI host side instead of the bridge side, and assumes DSI host endpoint 1.
Let's standardize on what the other bridge drivers are doing and parse the
data-lanes property for the bridge. Only if data-lanes property is not found,
let's be nice and also check the DSI host for old dtb in use and warn.
And as Dmitry pointed out, the lanes for the host and the bridge may be
different because the lanes may be swapped on the host side.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -525,27 +525,24 @@ tc_mode_valid(struct drm_bridge *bridge,
static int tc358775_parse_dt(struct device_node *np, struct tc_data *tc)
{
struct device_node *endpoint;
- struct device_node *parent;
struct device_node *remote;
int dsi_lanes = -1;
- /*
-* To get the data-lanes of dsi, we need to access the dsi0_out of port1
-* of dsi0 endpoint from bridge port0 of d2l_in
-*/
endpoint = of_graph_get_endpoint_by_regs(tc->dev->of_node,
TC358775_DSI_IN, -1);
- if (endpoint) {
- /* dsi0_out node */
- parent = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
- if (parent) {
- /* dsi0 port 1 */
- dsi_lanes = drm_of_get_data_lanes_count_ep(parent, 1,
-1, 1, 4);
- of_node_put(parent);
- }
+ dsi_lanes = drm_of_get_data_lanes_count(endpoint, 1, 4);
+
+ /* Quirk old dtb: Use data lanes from the DSI host side instead of
bridge */
+ if (dsi_lanes == -EINVAL || dsi_lanes == -ENODEV) {
+ remote = of_graph_get_remote_endpoint(endpoint);
+ dsi_lanes = drm_of_get_data_lanes_count(remote, 1, 4);
+ of_node_put(remote);
+ if (dsi_lanes >= 1)
+ dev_warn(tc->dev, "no dsi-lanes for the bridge, using
host lanes\n");
}
+ of_node_put(endpoint);
+
if (dsi_lanes < 0)
return dsi_lanes;
--
2.43.0
[PATCH v3 05/10] drm/bridge: tc358775: make standby GPIO optional
From: Michael Walle
The stby pin is optional. It is only needed for power-up and down
sequencing. It is not needed, if the power rails cannot by dynamically
enabled.
Because the GPIO is now optional, remove the error message.
Signed-off-by: Michael Walle
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -669,12 +669,9 @@ static int tc_probe(struct i2c_client *client)
return ret;
}
- tc->stby_gpio = devm_gpiod_get(dev, "stby", GPIOD_OUT_HIGH);
- if (IS_ERR(tc->stby_gpio)) {
- ret = PTR_ERR(tc->stby_gpio);
- dev_err(dev, "cannot get stby-gpio %d\n", ret);
- return ret;
- }
+ tc->stby_gpio = devm_gpiod_get_optional(dev, "stby", GPIOD_OUT_HIGH);
+ if (IS_ERR(tc->stby_gpio))
+ return PTR_ERR(tc->stby_gpio);
tc->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(tc->reset_gpio)) {
--
2.43.0
[PATCH v3 04/10] drm/bridge: tc358775: fix support for jeida-18 and jeida-24
From: Michael Walle
The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each channel and thus
starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
lanes instead of three, with the forth pair transmitting the lowest two
bits of each channel. Thus, the mapping between jeida-18 and jeida-24
is actually the same, except that one channel is turned off (by
selecting the RGB666 format in VPCTRL).
While at it, remove the bogus comment about the hardware default because
the default is overwritten in any case.
Tested with a jeida-18 display (Evervision VGG644804).
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -454,10 +454,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
connector->display_info.bus_formats[0],
tc->bpc);
- /*
-* Default hardware register settings of tc358775 configured
-* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
-*/
if (connector->display_info.bus_formats[0] ==
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
/* VESA-24 */
@@ -468,14 +464,15 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1,
LVI_B2));
d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R6));
- } else { /* MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - JEIDA-18 */
- d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
LVI_R3));
- d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_L0, LVI_R5,
LVI_G0));
- d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_L0,
LVI_L0));
- d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5,
LVI_B0));
- d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_L0, LVI_L0, LVI_B1,
LVI_B2));
- d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
- d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_L0));
+ } else {
+ /* JEIDA-18 and JEIDA-24 */
+ d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R2, LVI_R3, LVI_R4,
LVI_R5));
+ d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R6, LVI_R1, LVI_R7,
LVI_G2));
+ d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G3, LVI_G4, LVI_G0,
LVI_G1));
+ d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G5, LVI_G6, LVI_G7,
LVI_B2));
+ d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B0, LVI_B1, LVI_B3,
LVI_B4));
+ d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B5, LVI_B6, LVI_B7,
LVI_L0));
+ d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R0));
}
d2l_write(tc->i2c, VFUEN, VFUEN_EN);
--
2.43.0
[PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
The tc358765 is similar to tc358775. The tc358765 just an earlier version of the hardware, and it's pin and register compatible with tc358775 for most part. >From the binding point of view the only difference is that the tc358765 does not have stdby-gpios. Signed-off-by: Tony Lindgren --- .../bindings/display/bridge/toshiba,tc358775.yaml | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml @@ -10,7 +10,7 @@ maintainers: - Vinay Simha BN description: | - This binding supports DSI to LVDS bridge TC358775 + This binding supports DSI to LVDS bridges TC358765 and TC358775 MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane. Video frame size: @@ -21,7 +21,9 @@ description: | properties: compatible: -const: toshiba,tc358775 +enum: + - toshiba,tc358765 + - toshiba,tc358775 reg: maxItems: 1 @@ -81,6 +83,15 @@ properties: - port@0 - port@1 +allOf: + - if: +properties: + compatible: +contains: + const: toshiba,tc358765 +then: + stby-gpios: false + required: - compatible - reg -- 2.43.0
[PATCH v3 02/10] dt-bindings: display: bridge: tc358775: Add data-lanes
The device uses a clock lane, and 1 to 4 DSI data lanes. Let's add the
data-lanes property starting at 1 similar to what the other bridge
bindings are doing.
Let's also drop the data-lanes properties in the example for the DSI host
controller to avoid confusion. The configuration of the DSI host depends
on the controller used and is unrelated to the bridge binding.
Signed-off-by: Tony Lindgren
---
.../display/bridge/toshiba,tc358775.yaml | 22 ---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
@@ -46,11 +46,27 @@ properties:
properties:
port@0:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
description: |
DSI Input. The remote endpoint phandle should be a
reference to a valid mipi_dsi_host device node.
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
@@ -107,6 +123,7 @@ examples:
reg = <0>;
d2l_in_test: endpoint {
remote-endpoint = <_out>;
+data-lanes = <1 2 3 4>;
};
};
@@ -131,7 +148,6 @@ examples:
reg = <1>;
dsi0_out: endpoint {
remote-endpoint = <_in_test>;
-data-lanes = <0 1 2 3>;
};
};
};
@@ -166,6 +182,7 @@ examples:
reg = <0>;
d2l_in_dual: endpoint {
remote-endpoint = <_out_dual>;
+data-lanes = <1 2 3 4>;
};
};
@@ -197,7 +214,6 @@ examples:
reg = <1>;
dsi0_out_dual: endpoint {
remote-endpoint = <_in_dual>;
-data-lanes = <0 1 2 3>;
};
};
};
--
2.43.0
[PATCH v3 01/10] dt-bindings: display: bridge: tc358775: make stby gpio optional
From: Michael Walle For a normal operation, the stby GPIO is not needed. The reset pin is required because once the PPI (PHY protocol interface) is started, it can only be stopped by asserting the reset pin. Signed-off-by: Michael Walle [t...@atomide.com: dropped regulator related changes] Signed-off-by: Tony Lindgren --- .../devicetree/bindings/display/bridge/toshiba,tc358775.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml @@ -70,7 +70,6 @@ required: - reg - vdd-supply - vddio-supply - - stby-gpios - reset-gpios - ports -- 2.43.0
[PATCH v3 00/10] Improvments for tc358775 with support for tc358765
Hi all, Here are v3 patches to improve tc358775 driver and add support for tc358765. Regards, Tony Changes since v2: - Only make stby-gpios optional for tc358775, and disallow them for tc358765 as noted by Krzysztof - Added additionalProperties: false for port-base as noted by Krzysztof - Updated patch description for why there can be a data-lanes property for both the DSI host and the bridge as noted by Dmitry - Improved the old dtb data-lanes warning as suggested by Michael - Fix warning on casting of_device_get_match_data() as noted by the kernel test robot Changes since v1: - After a brief offline discussion with Michael, merge series with Michael's patch series to make stby gpio and supplies optional as they may be hardwired - Use Michael's better patch for the jeida timings change - Parse lanes on the bridge side like other bridge devices do, and if not found, also parse on the DSI host side and warn Michael Walle (3): dt-bindings: display: bridge: tc358775: make stby gpio optional drm/bridge: tc358775: fix support for jeida-18 and jeida-24 drm/bridge: tc358775: make standby GPIO optional Tony Lindgren (7): dt-bindings: display: bridge: tc358775: Add data-lanes dt-bindings: display: bridge: tc358775: Add support for tc358765 drm/bridge: tc358775: Get bridge data lanes instead of the DSI host lanes drm/bridge: tc358775: Add burst and low-power modes drm/bridge: tc358775: Enable pre_enable_prev_first flag drm/bridge: tc358775: Add support for tc358765 drm/bridge: tc358775: Configure hs_rate and lp_rate .../display/bridge/toshiba,tc358775.yaml | 38 +-- drivers/gpu/drm/bridge/tc358775.c | 98 --- 2 files changed, 93 insertions(+), 43 deletions(-) -- 2.43.0
