- 02 Aug, 2021 40 commits
-
-
Guenter Roeck authored
Commit 3a70dd2d ("spi: mediatek: fix fifo rx mode") claims that fifo RX mode was never handled, and adds the presumably missing code to the FIFO transfer function. However, the claim that receive data was not handled is incorrect. It was handled as part of interrupt handling after the transfer was complete. The code added with the above mentioned commit reads data from the receive FIFO before the transfer is started, which is wrong. This results in an actual transfer error on a Hayato Chromebook. Remove the code trying to handle receive data before the transfer is started to fix the problem. Fixes: 3a70dd2d ("spi: mediatek: fix fifo rx mode") Cc: Peter Hess <peter.hess@ph-home.de> Cc: Frank Wunderlich <frank-w@public-files.de> Cc: Tzung-Bi Shih <tzungbi@google.com> Cc: Hsin-Yi Wang <hsinyi@google.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Tzung-Bi Shih <tzungbi@google.com> Tested-by:
Hsin-Yi Wang <hsinyi@google.com> Change-Id: I69b5bf1fddad574a657ed42d77012e5a6db274f6
-
Moudy Ho authored
This patch adds driver for Media Data Path 3 (MDP3). Each modules' related operation control is sited in mtk-mdp3-comp.c Each modules' register table is defined in file with "mdp_reg_" and "mmsys_" prefix GCE related API, operation control sited in mtk-mdp3-cmdq.c V4L2 m2m device functions are implemented in mtk-mdp3-m2m.c Probe, power, suspend/resume, system level functions are defined in mtk-mdp3-core.c Signed-off-by:
Ping-Hsun Wu <ping-hsun.wu@mediatek.com> Signed-off-by:
daoyuan huang <daoyuan.huang@mediatek.com> Signed-off-by:
Moudy Ho <moudy.ho@mediatek.com> Change-Id: Ibae5b76032c600ac65546c4b30827566ae46dfca
-
Moudy Ho authored
Add device nodes for Media Data Path 3 (MDP3) modules. Signed-off-by:
Ping-Hsun Wu <ping-hsun.wu@mediatek.com> Signed-off-by:
daoyuan huang <daoyuan.huang@mediatek.com> Signed-off-by:
Moudy Ho <moudy.ho@mediatek.com> Change-Id: Id613e52b6e3f32c23f04c0a2c56d72edb7d790dd
-
Moudy Ho authored
This patch adds DT binding document for Media Data Path 3 (MDP3) a unit in multimedia system used for scaling and color format convert. Signed-off-by:
Ping-Hsun Wu <ping-hsun.wu@mediatek.com> Signed-off-by:
daoyuan huang <daoyuan.huang@mediatek.com> Signed-off-by:
Moudy Ho <moudy.ho@mediatek.com> Change-Id: I745c5f1d6a2338a801445e7a3fbf9ddb3d4a8efc
-
Yunfei Dong authored
Add mt8183 support for vdec/venc H264. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: Ib292fae721dbf8bdff02c4e6ff655c3ab383f8f5
-
Yunfei Dong authored
Now that all the supporting blocks are present, enable decoder for MT8183. Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> [acourbot: refactor, cleanup and split] Co-developed-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: Ifc997ff14bbc24c8fe3709df8b2ed09b626c2b15
-
Alexandre Courbot authored
MT8183's decoder is instantiated similarly to MT8173's. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Acked-by:
Rob Herring <robh@kernel.org> Change-Id: I0e7a99f150e789571f0149ffeb7d61ed24b4a3af
-
Yunfei Dong authored
The stateless API requires a media device for issuing requests. Add one if we are being instantiated as a stateless decoder. Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> [acourbot: refactor, cleanup and split] Co-developed-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: I5ec54ac64b0044789f9765f6ed4f255137c93806
-
Yunfei Dong authored
Add support for H.264 decoding using the stateless API, as supported by MT8183. This support takes advantage of the V4L2 H.264 reference list builders. Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> [acourbot: refactor, cleanup and split] Co-developed-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Change-Id: I86c626d9c9aa9c7e82420734514849558bba1310
-
Yunfei Dong authored
Support the stateless codec API that will be used by MT8183. Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> [acourbot: refactor, cleanup and split] Co-developed-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Change-Id: Ieb7b128f55dfd07a25d32d6db919481b2dd7d79d
-
Alexandre Courbot authored
Add Mediatek's non-compressed 8 bit block video mode. This format is produced by the MT8183 codec and can be converted to a non-proprietary format by the MDP3 component. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: Id2945313a91f9c4e1a64db386c836a5a8a71d518
-
Alexandre Courbot authored
Add support for decoder firmware version 2, which makes the kernel responsible for managing the VSI context and is used for stateless codecs. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: If6ad838e692adbc4e0be38c02ea81a1e156fd5d9
-
Alexandre Courbot authored
Firmwares for decoders newer than MT8173 will include an ABI version number in their initialization ack message. Add the capacity to manage it and make initialization fail if the firmware ABI is of a version that we don't support. For MT8173, this ABI version field does not exist ; thus ignore it on this chip. There should only be one firmware version available for it anyway. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: I13b2e031cd262e8df6ea5ea08bc3411fc677c815
-
Yunfei Dong authored
We are planning to add support for stateless decoders to this driver. Part of the driver will be shared between stateful and stateless codecs, but a few ops need to be specialized for both. Extract the stateful part of the driver and move it into its own file, accessible through ops that the common driver parts can call. This patch only moves code around and introduces a set of abstractions ; the behavior of the driver should not be changed in any way. Changes to code styling has been done to accommodate 'checkpatch.pl --strict'. Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> [acourbot: refactor, cleanup and split] Co-developed-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Change-Id: I06188678d93033c7116f119715418f27a4c918ad
-
Hsin-Yi Wang authored
krane, kakadu, and kodama boards have a default panel rotation. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Change-Id: I4fd929cd6bd2c3c8c0798764de4d6cf211228a27
-
Hsin-Yi Wang authored
Init panel orientation property after connector is initialized. Let the panel driver decides the orientation value later. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Acked-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Change-Id: Ie3b55a7ecd12029fff291ecc285055ddf48fd8b4
-
Hsin-Yi Wang authored
drm_dev_register() sets connector->registration_state to DRM_CONNECTOR_REGISTERED and dev->registered to true. If drm_connector_set_panel_orientation() is first called after drm_dev_register(), it will fail several checks and results in following warning. Add a function to create panel orientation property and set default value to UNKNOWN, so drivers can call this function to init the property earlier , and let the panel set the real value later. [ 4.480976] ------------[ cut here ]------------ [ 4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc <snip> [ 4.609772] Call trace: [ 4.612208] __drm_mode_object_add+0xb4/0xbc [ 4.616466] drm_mode_object_add+0x20/0x2c [ 4.620552] drm_property_create+0xdc/0x174 [ 4.624723] drm_property_create_enum+0x34/0x98 [ 4.629241] drm_connector_set_panel_orientation+0x64/0xa0 [ 4.634716] boe_panel_get_modes+0x88/0xd8 [ 4.638802] drm_panel_get_modes+0x2c/0x48 [ 4.642887] panel_bridge_get_modes+0x1c/0x28 [ 4.647233] drm_bridge_connector_get_modes+0xa0/0xd4 [ 4.652273] drm_helper_probe_single_connector_modes+0x218/0x700 [ 4.658266] drm_mode_getconnector+0x1b4/0x45c [ 4.662699] drm_ioctl_kernel+0xac/0x128 [ 4.666611] drm_ioctl+0x268/0x410 [ 4.670002] drm_compat_ioctl+0xdc/0xf0 [ 4.673829] __arm64_compat_sys_ioctl+0xc8/0x100 [ 4.678436] el0_svc_common+0xf4/0x1c0 [ 4.682174] do_el0_svc_compat+0x28/0x3c [ 4.686088] el0_svc_compat+0x10/0x1c [ 4.689738] el0_sync_compat_handler+0xa8/0xcc [ 4.694171] el0_sync_compat+0x178/0x180 [ 4.698082] ---[ end trace b4f2db9d9c88610b ]--- [ 4.702721] ------------[ cut here ]------------ [ 4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8 <snip> [ 4.833830] Call trace: [ 4.836266] drm_object_attach_property+0x48/0xb8 [ 4.840958] drm_connector_set_panel_orientation+0x84/0xa0 [ 4.846432] boe_panel_get_modes+0x88/0xd8 [ 4.850516] drm_panel_get_modes+0x2c/0x48 [ 4.854600] panel_bridge_get_modes+0x1c/0x28 [ 4.858946] drm_bridge_connector_get_modes+0xa0/0xd4 [ 4.863984] drm_helper_probe_single_connector_modes+0x218/0x700 [ 4.869978] drm_mode_getconnector+0x1b4/0x45c [ 4.874410] drm_ioctl_kernel+0xac/0x128 [ 4.878320] drm_ioctl+0x268/0x410 [ 4.881711] drm_compat_ioctl+0xdc/0xf0 [ 4.885536] __arm64_compat_sys_ioctl+0xc8/0x100 [ 4.890142] el0_svc_common+0xf4/0x1c0 [ 4.893879] do_el0_svc_compat+0x28/0x3c [ 4.897791] el0_svc_compat+0x10/0x1c [ 4.901441] el0_sync_compat_handler+0xa8/0xcc [ 4.905873] el0_sync_compat+0x178/0x180 [ 4.909783] ---[ end trace b4f2db9d9c88610c ]--- Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Change-Id: I881c7f896a80ae024ed819c9f1a39f8feea9d21b
-
Alexandre Courbot authored
The V4L2 encoder specification requires encoders to support the V4L2_ENC_CMD_START and V4L2_ENC_CMD_STOP commands. Add support for these to the mtk-vcodec encoder by reusing the same flush buffer as used by the decoder driver. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> [hsinyi: fix double-free issue if flush buffer was not dequeued by the time streamoff is called] Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Change-Id: Ic8fc22edbc1d7e38906842025ea74179bf18d8fa
-
Alexandre Courbot authored
The flush buffer is a special buffer that tells the decoder driver to send an empty CAPTURE frame to the client with V4L2_BUF_FLAG_LAST set. We need similar functionality for the encoder ; however currently the flush buffer depends on decoder-specific structures and thus cannot be reused with the encoder. Fix this by testing for this buffer by its VB2 address, and not through a dedicated flag stored in a higher-level decoder structure. This also allows us to remove said flag and simplify the code a bit. Since the flush buffer should never be used in the stateless decoder, also add safeguards to check against it. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: I7f669e212bdf8edbcec07fb7592b8fd18a784eb9
-
Alexandre Courbot authored
Calling S_FMT or TRY_FMT on the OUTPUT queue should adjust the resolution to the limits supported by the hardware. Until now this was only done on the CAPTURE queue, which could make clients believe that unsupported resolutions can be used when they set the coded size on the OUTPUT queue. In the case of the stateless decoder, the problem was even bigger since subsequently calling G_FMT on the CAPTURE queue would result in the unclamped resolution being returned, further inducing the client into error. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: Iad51eb6a6fbc63453505f6f5e9942dc4a38591c6
-
Alexandre Courbot authored
Let's use the dedicated helpers to make sure we get the expected behavior and remove redundant code. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: Id421b5ecb35c01def85cbbfed6a30cfc9f8ae4af
-
Hirokazu Honda authored
Add H264 profiles supported by the MediaTek 8173 decoder. Signed-off-by:
Hirokazu Honda <hiroh@chromium.org> [acourbot: fix commit log a bit, move to mtk_vcodec_dec.c] Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Change-Id: If36877104d727b98780b034342fa08f212199f44
-
Yong Wu authored
After adding device_link between the IOMMU consumer and smi, the mediatek,larb is unnecessary now. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Change-Id: I7f1d2082b6717a2fa1f31c3ac5c6e3350a6205b5
-
Yong Wu authored
After adding device_link between the IOMMU consumer and smi, the mediatek,larb is unnecessary now. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Change-Id: I9c0822cb84a80d30c81e24d8ffd6165df39d27ae
-
Yong Wu authored
After adding device_link between the iommu consumer and smi-larb, the pm_runtime_get(_sync) of smi-larb and smi-common will be called automatically. we can get rid of mtk_smi_larb_get/put. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Matthias Brugger <matthias.bgg@gmail.com> Change-Id: I68591b4bd70f3b8030ffd54f75d7f8961ea727a8
-
Yong Wu authored
MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the vcodec device call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: Tiffany Lin <tiffany.lin@mediatek.com> CC: Irui Wang <irui.wang@mediatek.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Acked-by:
Tiffany Lin <tiffany.lin@mediatek.com> Change-Id: Ie781af6423b9aab87c721d7fbcd9f26ea7d03e1c
-
Yong Wu authored
MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the drm device call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: CK Hu <ck.hu@mediatek.com> CC: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Acked-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Change-Id: I693a522eb080e2ea84d404d99f06d094b69bbd82
-
Yongqiang Niu authored
Prepare for smi cleaning up "mediatek,larb". Display use the dispsys device to call pm_rumtime_get_sync before. This patch add pm_runtime_xx with ovl and rdma device whose nodes has "iommus" property, then display could help pm_runtime_get for smi via ovl or rdma device. CC: CK Hu <ck.hu@mediatek.com> Signed-off-by:
Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> (Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync) Acked-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Change-Id: Ie0c0336ef6ccc103a309323c4a3830e9f3e6ed86
-
Yong Wu authored
MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the mdp device call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: Minghsiu Tsai <minghsiu.tsai@mediatek.com> CC: Houlong Wei <houlong.wei@mediatek.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Houlong Wei <houlong.wei@mediatek.com> Change-Id: I8b89cac2591517ba2d635fd17108d0c237005fd2
-
Yong Wu authored
MediaTek IOMMU has already added device_link between the consumer and smi-larb device. If the jpg device call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. After removing the larb_get operations, then mtk_jpeg_clk_init is also unnecessary. Remove it too. CC: Rick Chang <rick.chang@mediatek.com> CC: Xia Jiang <xia.jiang@mediatek.com> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Acked-by:
Rick Chang <rick.chang@mediatek.com> Change-Id: Iafbdca503b064f0959ed9325b70b77541cd15e1a
-
Yong Wu authored
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with smi-larb, then connect with smi-common. M4U | smi-common | ------------- | | ... | | larb1 larb2 | | vdec venc When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, First of all, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. This patch adds device_link between the consumer and the larbs. When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling pm_runtime_xx to keep the original status of clocks. It can avoid two issues: 1) Display HW show fastlogo abnormally reported in [1]. At the beggining, all the clocks are enabled before entering kernel, but the clocks for display HW(always in larb0) will be gated after clk_enable and clk_disable called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock operation happened before display driver probe. At that time, the display HW will be abnormal. 2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip pm_runtime_xx to avoid the deadlock. Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then device_link_removed should be added explicitly. [1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/ [2] https://lore.kernel.org/patchwork/patch/1086569/ Suggested-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Change-Id: I94647677ccefaf977d252e3af6c7bf3369cfd585
-
Yong Wu authored
Prepare for adding device_link. The iommu consumer should use device_link to connect with the smi-larb(supplier). then the smi-larb should run before the iommu consumer. Here we delay the iommu driver until the smi driver is ready, then all the iommu consumer always is after the smi driver. When there is no this patch, if some consumer drivers run before smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the device_link_add, then device_links_driver_bound will use WARN_ON to complain that the link_status of supplier is not right. Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Change-Id: I02ad7518f5555cba34b92cad430633054f60b6dd
-
Eizan Miyamoto authored
It is no longer used by the mediatek MDP driver. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: Ib3b1cc9f5cb8602d4c401d8a15bd7f12183b96b1
-
Eizan Miyamoto authored
... Instead of depending on the presence of a mediatek,vpu property in the device node. That property was originally added to link to the vpu node so that the mtk_mdp_core driver could pass the right device to vpu_wdt_reg_handler(). However in a previous patch in this series, the driver has been modified to search the device tree for that node instead. That property was also used to indicate the primary MDP device, so that it can be passed to the V4L2 subsystem as well as register it to be used when setting up queues in the open() callback for the filesystem device node that is created. In this case, assuming that the primary MDP device is the one with a specific alias seems useable because the alternative is to add a property to the device tree which doesn't actually represent any facet of hardware (i.e., this being the primary MDP device is a software decision). In other words, this solution is equally as arbitrary, but at least it doesn't add a property to a device node where said property is unrelated to the hardware present. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: I06e50c0ef5cb3e4f9d36e9491e0bc5f6ccd6e5bc
-
Eizan Miyamoto authored
Up until this change, many errors were logged but ignored when powering on clocks and calling pm_runtime_get/put() inside mtk_mdp_core. This change tries to do a better job at propagating errors back to the power management framework. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: I3922c520d777e1991b6bbc247278c0d7fb5af605
-
Eizan Miyamoto authored
Since there is only one vpu node, it suffices to search for it instead of having a link coded into the primary mdp device node. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: I81df584819887382f2b86999a95e127998d42ce3
-
Eizan Miyamoto authored
Rather than hanging the MDP master component driver off of the rdma0 device, create a "virtual" device by the mmsys driver instead which is probed by the mtk_mdp_core driver. Broadly, four interdependent things are done by this change: - A virtual device that is probed by the mtk_mdp_core driver is instantiated by the mtk_mmsys driver. - Presence of a mediatek,vpu property in a child node to the mmsys device node is used to determine what device to use when dispatching dma ops from the relevant ioctl. - v4l-related setup is moved into from the mtk_mdp_core driver to the mtk_mdp_comp driver. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: I1eecdfa659c6fbf28b5015fccb6e86846f7cbdcd
-
Eizan Miyamoto authored
The original intent of commit 86698b95 ("media: mtk-mdp: convert mtk_mdp_dev.comp array to list") was to create a list to track all the MDP components that needed to have their clocks enabled/disabled when calling mtk_mdp_comp_clock_on/off. However, there was a bug inside mtk_mdp_register_component where the args to a call to list_add were swapped. The result is that only one component was added to mtk_mdp_dev.comp_list because comp_list was instead being repeatedly added to the single element lists headed by each mtk_mdp_comp. The order of the args to list_add in mtk_mdp_register_component was fixed in https://patchwork.kernel.org/patch/11742895/ (Fix Null pointer dereference when calling list_add). Then, as a result of https://patchwork.kernel.org/patch/11530769/ (mtk-mdp: use pm_runtime in MDP component driver) if all the components are added to the component list, the mdp "master" / rdma0 component ends up having pm_runtime_get_sync() called on it twice recursively: rpm_resume+0x694/0x8f8 __pm_runtime_resume+0x7c/0xa0 ***NOTE*** mtk_mdp_comp_clock_on+0x48/0x104 [mtk_mdp] mtk_mdp_pm_resume+0x2c/0x44 [mtk_mdp] pm_generic_runtime_resume+0x34/0x48 __genpd_runtime_resume+0x6c/0x80 genpd_runtime_resume+0x104/0x1ac __rpm_callback+0x120/0x238 rpm_callback+0x34/0x8c rpm_resume+0x7a0/0x8f8 __pm_runtime_resume+0x7c/0xa0 ***NOTE*** mtk_mdp_m2m_start_streaming+0x2c/0x3c [mtk_mdp] (The calls to pm_runtime_get_sync are inlined and correspond to the calls to __pm_runtime_resume). It is not correct to have pm_runtime_get_sync called recursively and the second call will block indefinitely. As a result of all that, this change factors mtk_mdp_comp_clock_on/off into mtk_mdp_comp_power_on/off and moves the calls to pm_runtime_get/put into the power_on/off functions. This change then special-cases the master/rdma0 MDP component and does these things: - the master/rdma0 component is not added to mtk_mdp_dev.comp_list - the master/rdma0 component has its clocks (*but not power*) toggled by mtk_mpd_comp_clock_on/off inside mtk_mdp_clock_on/off. - the other components have their clocks *and* power toggled with mtk_mdp_comp_power_on/off. This change introduces the assumption that mtk_mdp_pm_resume will always be called though a callback from pm_runtime_get_sync made on the master / rdma0 component. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: Id4a2f30053709c8e8d6c1fa011bb54056de7d0a9
-
Eizan Miyamoto authored
Without this change, the MDP components are not fully integrated into the runtime power management subsystem, and the MDP driver does not work. For each of the component device drivers to be able to call pm_runtime_get/put_sync() a pointer to the component's device struct had to be added to struct mtk_mdp_comp, set by mtk_mdp_comp_init(). Note that the dev argument to mtk_mdp_comp_clock_on/off() has been removed. Those functions used to be called from the "master" mdp driver in mtk_mdp_core.c, but the component's device pointer no longer corresponds to the mdp master device pointer, which is not the right device to pass to pm_runtime_put/get_sync() which we had to add to get the driver to work properly. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: I0670ace4fc4d5d99b679324320877377a0cc753d
-
Eizan Miyamoto authored
Broadly, this patch (1) adds a driver for various MTK MDP components to go alongside the main MTK MDP driver, and (2) hooks them all together using the component framework. (1) Up until now, the MTK MDP driver controls 8 devices in the device tree on its own. When running tests for the hardware video decoder, we found that the iommus and LARBs were not being properly configured. To configure them, a driver for each be added to mtk_mdp_comp so that mtk_iommu_add_device() can (eventually) be called from dma_configure() inside really_probe(). (2) The integration into the component framework allows us to defer the registration with the v4l2 subsystem until all the MDP-related devices have been probed, so that the relevant device node does not become available until initialization of all the components is complete. Some notes about how the component framework has been integrated: - The driver for the rdma0 component serves double duty as the "master" (aggregate) driver as well as a component driver. This is a non-ideal compromise until a better solution is developed. This device is differentiated from the rest by checking for a "mediatek,vpu" property in the device node. - The list of mdp components remains hard-coded as mtk_mdp_comp_dt_ids[] in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in mtk_mdp_comp.c. This unfortunate duplication of information is addressed in a following patch in this series. - The component driver calls component_add() for each device that is probed. - In mtk_mdp_probe (the "master" device), we scan the device tree for any matching nodes against mtk_mdp_comp_dt_ids, and add component matches for them. The match criteria is a matching device node pointer. - When the set of components devices that have been probed corresponds with the list that is generated by the "master", the callback to mtk_mdp_master_bind() is made, which then calls the component bind functions. - Inside mtk_mdp_master_bind(), once all the component bind functions have been called, we can then register our device to the v4l2 subsystem. - The call to pm_runtime_enable() in the master device is called after all the components have been registered by their bind() functions called by mtk_mtp_master_bind(). As a result, the list of components will not change while power management callbacks mtk_mdp_suspend()/ resume() are accessing the list of components. Signed-off-by:
Eizan Miyamoto <eizan@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Change-Id: Idee5792786e32ff52a1a15fab8f9d1e7b2446169
-