| Message ID | 20230321121859.2355-1-nancy.lin@mediatek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add MediaTek SoC DRM (vdosys1) support for mt8195 | expand |
Hi, Nancy: Nancy.Lin <nancy.lin@mediatek.com> 於 2023年3月21日 週二 下午8:19寫道： > > The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. For this series, applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Add DRM and these modules support by the patches below: > > Changes in v30: > - rebase to next-20230321 > - fix ethdr dt_binding_check message > > Changes in v29: > - rebase to next-20221226 > - fix reviewer comment in v28 > - keep original flow if comp node not found in mtk_drm_crtc_create() > > Changes in v28: > - rebase to next-20221107 > - fix reviewer comment in v27 > - extra new line at the end mtk_ethdr.h > > Changes in v27: > - rebase to next-20221102 > - change mmsys compatible for mt8195 vdosys1 > - base on jason's series[ref 1] > - fix reviewer comment > - add error return code if no ovl_adaptor's comp found > > Changes in v26: > - rebase to next-20220819 > - resend for patch corrupted in v25 > > Changes in v25: > - rebase to next-20220803 > > Changes in v24: > - fix ovl_adaptor binding issue (mtk_disp_ovl_adaptor.c) > - Since ovl_adaptor is an aggregated component, it should be bounded after > all its child components are bounded. > - rebase to next-20220708 > > Changes in v23: > - separate[7] mmsys/mutex and drm patches into two series > > Changes in v22: > - rebase to next-20220525 > - rebase to vdosys0 series v22 > - separate dts to a new patch > > Changes in v21: > - fix reviewer comment > - fix rdma and ethdr binding doc and dts > > Changes in v20: > - fix reviewer comment > - update mmsys update bit api name > - add mtk_mmsys_update_bits error message if lose gce property > - list all mt8195 vdosys1 reset bits > > Changes in v19: > - fix reviewer comment > - separate mt8195 mmsys component to a new patch > - separate mt8195 vdo0 and vdo1 routing table > - separate mmsys_write_reg api to a new patch and simplify write reg code > - separate mmsys 64 bit reset to a new patch > - separate mtk-mutex dp_intf1 component to a new patch > > Changes in v18: > - fix reviewer comment > - fix rdma binding doc > - fix ethdr binding doc > - refine mmsys config cmdq support > - refine merge reset control flow, get reset control in probe function > - add ethdr reset control error handling and remove dbg log > - rebase to vdosys0 series v20 (ref [5]) > > Changes in v17: > - fix reviewer comment in v16 > - separate ovl adaptor comp in mtk-mmsys and mtk-mutex > - separate mmsys config API > - move mdp_rdma binding yaml > - fix ovl adaptor pm runtime get sync timing issue > - rebase to vdosys0 series v19 (ref [5]) > - rebase to [7] for modify vblank register change > > Changes in v16: > - fix reviewer comment in v 15 > - fix mtk_drm_ddp_comp.c alignment > - fix vdosys0 mmsys num before adding vdosys1 patch > > Changes in v15: > - fix ethdr uppercase hex number in dts > > Changes in v14: > - remove MTK_MMSYS 64 bit dependency > - add ethdr.yaml back and fix dt_schema check fail > > Resend v13 > - add related maintainer in maillist > > Changes in v13: > - fix reviewer comment in v12 > - fix rdma dt-binding format > - fix dts node naming > - fix 32 bit build error > - modify 64bit dependency for mtk-mmsys > - rebase to vdosys0 series v16. (ref [5]) > > Changes in v12: > - fix reviewer comment in v11 > - modify mbox index > - refine dma dev for ovl_adaptor sub driver > > Changes in v11: > - remove ethdr vblank spin lock > - refine ovl_adaptor print message > > Changes in v10: > - refine ethdr reset control using devm_reset_control_array_get_optional_exclusive > - fix ovl_adaptor mtk_ovl_adaptor_clk_enable error handle issue > > Changes in v9: > - rebase on kernel-5.16-rc1 > - rebase on vdosys0 series v13. (ref [5]) > - fix ovl_adaptor sub driver is brought up unintentionally > - fix clang build test fail- duplicate ethdr/mdp_rdma init_module/cleanup_module symbol issue > > Changes in v8: > - separate merge async reset to new patch. > - separate drm ovl_adaptor sub driver to new patch. > - fix reviewer comment in v7. > > Changes in v7: > - rebase on vdosys0 series v12 (ref[5]) > - add dma description in ethdr binding document. > - refine vdosys1 bit definition of mmsys routing table. > - separate merge modification into 3 pathces. > - separate mutex modification into 2 patches. > - add plane color coding for mdp_rdma csc. > - move mdp_rdma pm control to ovl_adaptor. > - fix reviewer comment in v6. > > Changes in v6: > - rebase on kernel-5.15-rc1. > - change mbox label to gce0 for dts node of vdosys1. > - modify mmsys reset num for mt8195. > - rebase on vdosys0 series v10. (ref [5]) > - use drm to bring up ovl_adaptor driver. > - move drm iommu/mutex check from kms init to drm bind. > - modify rdma binding doc location. (Documentation/devicetree/bindings/arm/) > - modify for reviewer's comment in v5. > > Changes in v5: > - add mmsys reset controller reference. > > Changes in v4: > - use merge common driver for merge1~4. > - refine ovl_adaptor rdma driver. > - use ovl_adaptor ddp_comp function instead of ethdr. > - modify for reviewer's comment in v3. > > Changes in v3: > - modify for reviewer's comment in v2. > - add vdosys1 2 pixels align limit. > - add mixer odd offset support. > > Changes in v2: > - Merge PSEUDO_OVL and ETHDR into one DRM component. > - Add mmsys config API for vdosys1 hardware setting. > - Add mmsys reset control using linux reset framework. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > This series are based on the following patch: > [1] Change mmsys compatible for mt8195 mediatek-drm > 20221126101220.18179-1-jason-jh.lin@mediatek.com > > Nancy.Lin (7): > dt-bindings: mediatek: add ethdr definition for mt8195 > drm/mediatek: add ETHDR support for MT8195 > drm/mediatek: add ovl_adaptor support for MT8195 > drm/mediatek: add dma dev get function > drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support > drm/mediatek: add drm ovl_adaptor sub driver for MT8195 > drm/mediatek: add mediatek-drm of vdosys1 support for MT8195 > > .../display/mediatek/mediatek,ethdr.yaml | 182 ++++++ > drivers/gpu/drm/mediatek/Makefile | 2 + > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 26 + > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 533 ++++++++++++++++++ > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 85 ++- > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 6 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 129 +++-- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 58 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 366 ++++++++---- > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 24 +- > drivers/gpu/drm/mediatek/mtk_ethdr.c | 370 ++++++++++++ > drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 + > 12 files changed, 1618 insertions(+), 188 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h > > -- > 2.18.0 >
Il 21/03/23 13:18, Nancy.Lin ha scritto: > The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > > Add DRM and these modules support by the patches below: > I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. Green light from me. Chun-Kuang, can you please pick it? Thanks! Angelo
On Thu, Mar 23, 2023 at 4:58 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 21/03/23 13:18, Nancy.Lin ha scritto: > > The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > > > > Add DRM and these modules support by the patches below: > > > > I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > Green light from me. > > Chun-Kuang, can you please pick it? It was picked up a few hours ago. ChenYu
Il 23/03/23 10:04, Chen-Yu Tsai ha scritto: > On Thu, Mar 23, 2023 at 4:58 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: >> >> Il 21/03/23 13:18, Nancy.Lin ha scritto: >>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. >>> >>> Add DRM and these modules support by the patches below: >>> >> >> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. >> Green light from me. >> >> Chun-Kuang, can you please pick it? > > It was picked up a few hours ago. > > ChenYu Sorry, I didn't receive that email. Perfect! Thanks! Angelo
Hi, Angelo: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 2023年3月23日 週四 下午4:58寫道： > > Il 21/03/23 13:18, Nancy.Lin ha scritto: > > The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > > > > Add DRM and these modules support by the patches below: > > > > I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > Green light from me. I'm curious about how you build code and test on Chromebooks. Do you build in cros environment or pure linux (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). I've a MT8183 based Chromebook (HP 11a) and I've tried to run a upstream kernel on it. cros is too heavy for me and I doubt I could use it. I've tried the pure linux and could boot up with console, but display does not work. If you use the pure linux environment, could you share how it works? Regards, Chun-Kuang. > > Chun-Kuang, can you please pick it? > > Thanks! > Angelo >
Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: > Hi, Angelo: > > AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > 2023年3月23日 週四 下午4:58寫道： >> >> Il 21/03/23 13:18, Nancy.Lin ha scritto: >>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. >>> >>> Add DRM and these modules support by the patches below: >>> >> >> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. >> Green light from me. > > I'm curious about how you build code and test on Chromebooks. Do you > build in cros environment or pure linux > (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). > I've a MT8183 based Chromebook (HP 11a) and I've tried to run a > upstream kernel on it. cros is too heavy for me and I doubt I could > use it. I've tried the pure linux and could boot up with console, but > display does not work. If you use the pure linux environment, could > you share how it works? > I haven't tested MT8183 (I don't actually have any 8183 machine in my hands)... but yes, I can share my test environment. I have one MicroSD that I use either in the MicroSD slot of the target machine, or in a USB reader; this *single* system is what I boot on *all* Chromebooks that I have: one kernel, multiple devicetrees, same Debian-based userspace. What we have to prepare this bootable media can be found at [1], but beware that it currently uses an outdated kernel, so, what I have locally is a symlink to my kernel tree. You can change/add/remove the devicetree blobs that will get added to the image by modifying `chromebook-setup.sh`; before tampering with kernel tree symlink, please run that script for the first time, as it will download a cross-compiler, a kernel tree (that you will replace for sure) and the (very old) Debian rootfs that you can update with `apt-get dist-upgrade` after booting the Chromebook. If you want to check about possible kernel configuration differences, what I use is at [2], so that you can compare. [1]: https://gitlab.collabora.com/google/chromebooks/-/tree/mtk-av1 [2]: https://gitlab.collabora.com/google/chromeos-kernel/-/blob/mt8195-tracking-master-rolling/arch/arm64/configs/defconfig Regards, Angelo
Hi, Angelo: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 2023年3月24日 週五 下午4:38寫道： > > Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: > > Hi, Angelo: > > > > AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > > 2023年3月23日 週四 下午4:58寫道： > >> > >> Il 21/03/23 13:18, Nancy.Lin ha scritto: > >>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > >>> > >>> Add DRM and these modules support by the patches below: > >>> > >> > >> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > >> Green light from me. > > > > I'm curious about how you build code and test on Chromebooks. Do you > > build in cros environment or pure linux > > (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). > > I've a MT8183 based Chromebook (HP 11a) and I've tried to run a > > upstream kernel on it. cros is too heavy for me and I doubt I could > > use it. I've tried the pure linux and could boot up with console, but > > display does not work. If you use the pure linux environment, could > > you share how it works? > > > > I haven't tested MT8183 (I don't actually have any 8183 machine in my hands)... but > yes, I can share my test environment. > > I have one MicroSD that I use either in the MicroSD slot of the target machine, or > in a USB reader; this *single* system is what I boot on *all* Chromebooks that I > have: one kernel, multiple devicetrees, same Debian-based userspace. > > What we have to prepare this bootable media can be found at [1], but beware that > it currently uses an outdated kernel, so, what I have locally is a symlink to my > kernel tree. > You can change/add/remove the devicetree blobs that will get added to the image > by modifying `chromebook-setup.sh`; before tampering with kernel tree symlink, > please run that script for the first time, as it will download a cross-compiler, > a kernel tree (that you will replace for sure) and the (very old) Debian rootfs > that you can update with `apt-get dist-upgrade` after booting the Chromebook. > > If you want to check about possible kernel configuration differences, what I use > is at [2], so that you can compare. Thanks for the information, I would try to compare the kernel config first. > > [1]: https://gitlab.collabora.com/google/chromebooks/-/tree/mtk-av1 > [2]: > https://gitlab.collabora.com/google/chromeos-kernel/-/blob/mt8195-tracking-master-rolling/arch/arm64/configs/defconfig > > Regards, > Angelo
On Mon, Mar 27, 2023 at 11:17 PM Chun-Kuang Hu <chunkuang.hu@kernel.org> wrote: > > Hi, Angelo: > > AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > 2023年3月24日 週五 下午4:38寫道： > > > > Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: > > > Hi, Angelo: > > > > > > AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > > > 2023年3月23日 週四 下午4:58寫道： > > >> > > >> Il 21/03/23 13:18, Nancy.Lin ha scritto: > > >>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > > >>> > > >>> Add DRM and these modules support by the patches below: > > >>> > > >> > > >> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > > >> Green light from me. > > > > > > I'm curious about how you build code and test on Chromebooks. Do you > > > build in cros environment or pure linux > > > (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). > > > I've a MT8183 based Chromebook (HP 11a) and I've tried to run a > > > upstream kernel on it. cros is too heavy for me and I doubt I could > > > use it. I've tried the pure linux and could boot up with console, but > > > display does not work. If you use the pure linux environment, could > > > you share how it works? > > > > > > > I haven't tested MT8183 (I don't actually have any 8183 machine in my hands)... but > > yes, I can share my test environment. > > > > I have one MicroSD that I use either in the MicroSD slot of the target machine, or > > in a USB reader; this *single* system is what I boot on *all* Chromebooks that I > > have: one kernel, multiple devicetrees, same Debian-based userspace. > > > > What we have to prepare this bootable media can be found at [1], but beware that > > it currently uses an outdated kernel, so, what I have locally is a symlink to my > > kernel tree. > > You can change/add/remove the devicetree blobs that will get added to the image > > by modifying `chromebook-setup.sh`; before tampering with kernel tree symlink, > > please run that script for the first time, as it will download a cross-compiler, > > a kernel tree (that you will replace for sure) and the (very old) Debian rootfs > > that you can update with `apt-get dist-upgrade` after booting the Chromebook. > > > > If you want to check about possible kernel configuration differences, what I use > > is at [2], so that you can compare. > > Thanks for the information, I would try to compare the kernel config first. Hi CK, Would you consider adding your repo to linux-next? That would let everyone do integration testing, especially automated ones, earlier, before you send your PRs to drm maintainers. You can do so by sending an email to Stephen Rothwell to do so. ChenYu > > > > [1]: https://gitlab.collabora.com/google/chromebooks/-/tree/mtk-av1 > > [2]: > > https://gitlab.collabora.com/google/chromeos-kernel/-/blob/mt8195-tracking-master-rolling/arch/arm64/configs/defconfig > > > > Regards, > > Angelo
Hi, Chen-yu: Chen-Yu Tsai <wenst@chromium.org> 於 2023年3月30日 週四 下午7:05寫道： > > On Mon, Mar 27, 2023 at 11:17 PM Chun-Kuang Hu <chunkuang.hu@kernel.org> wrote: > > > > Hi, Angelo: > > > > AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > > 2023年3月24日 週五 下午4:38寫道： > > > > > > Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: > > > > Hi, Angelo: > > > > > > > > AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > > > > 2023年3月23日 週四 下午4:58寫道： > > > >> > > > >> Il 21/03/23 13:18, Nancy.Lin ha scritto: > > > >>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > > > >>> > > > >>> Add DRM and these modules support by the patches below: > > > >>> > > > >> > > > >> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > > > >> Green light from me. > > > > > > > > I'm curious about how you build code and test on Chromebooks. Do you > > > > build in cros environment or pure linux > > > > (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). > > > > I've a MT8183 based Chromebook (HP 11a) and I've tried to run a > > > > upstream kernel on it. cros is too heavy for me and I doubt I could > > > > use it. I've tried the pure linux and could boot up with console, but > > > > display does not work. If you use the pure linux environment, could > > > > you share how it works? > > > > > > > > > > I haven't tested MT8183 (I don't actually have any 8183 machine in my hands)... but > > > yes, I can share my test environment. > > > > > > I have one MicroSD that I use either in the MicroSD slot of the target machine, or > > > in a USB reader; this *single* system is what I boot on *all* Chromebooks that I > > > have: one kernel, multiple devicetrees, same Debian-based userspace. > > > > > > What we have to prepare this bootable media can be found at [1], but beware that > > > it currently uses an outdated kernel, so, what I have locally is a symlink to my > > > kernel tree. > > > You can change/add/remove the devicetree blobs that will get added to the image > > > by modifying `chromebook-setup.sh`; before tampering with kernel tree symlink, > > > please run that script for the first time, as it will download a cross-compiler, > > > a kernel tree (that you will replace for sure) and the (very old) Debian rootfs > > > that you can update with `apt-get dist-upgrade` after booting the Chromebook. > > > > > > If you want to check about possible kernel configuration differences, what I use > > > is at [2], so that you can compare. > > > > Thanks for the information, I would try to compare the kernel config first. > > Hi CK, > > Would you consider adding your repo to linux-next? That would let everyone > do integration testing, especially automated ones, earlier, before you send > your PRs to drm maintainers. > > You can do so by sending an email to Stephen Rothwell to do so. I don't understand what this process is. Does it means that I directly upstream patches into linux-next? I prefer that my patches go through drm maintainers' tree. Does any document introduce this process? Regards, Chun-Kuang. > > > ChenYu > > > > > > > [1]: https://gitlab.collabora.com/google/chromebooks/-/tree/mtk-av1 > > > [2]: > > > https://gitlab.collabora.com/google/chromeos-kernel/-/blob/mt8195-tracking-master-rolling/arch/arm64/configs/defconfig > > > > > > Regards, > > > Angelo
On 03/04/2023 05:30, Chun-Kuang Hu wrote: > Hi, Chen-yu: > > Chen-Yu Tsai <wenst@chromium.org> 於 2023年3月30日 週四 下午7:05寫道： >> >> On Mon, Mar 27, 2023 at 11:17 PM Chun-Kuang Hu <chunkuang.hu@kernel.org> wrote: >>> >>> Hi, Angelo: >>> >>> AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 >>> 2023年3月24日 週五 下午4:38寫道： >>>> >>>> Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: >>>>> Hi, Angelo: >>>>> >>>>> AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 >>>>> 2023年3月23日 週四 下午4:58寫道： >>>>>> >>>>>> Il 21/03/23 13:18, Nancy.Lin ha scritto: >>>>>>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. >>>>>>> >>>>>>> Add DRM and these modules support by the patches below: >>>>>>> >>>>>> >>>>>> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. >>>>>> Green light from me. >>>>> >>>>> I'm curious about how you build code and test on Chromebooks. Do you >>>>> build in cros environment or pure linux >>>>> (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). >>>>> I've a MT8183 based Chromebook (HP 11a) and I've tried to run a >>>>> upstream kernel on it. cros is too heavy for me and I doubt I could >>>>> use it. I've tried the pure linux and could boot up with console, but >>>>> display does not work. If you use the pure linux environment, could >>>>> you share how it works? >>>>> >>>> >>>> I haven't tested MT8183 (I don't actually have any 8183 machine in my hands)... but >>>> yes, I can share my test environment. >>>> >>>> I have one MicroSD that I use either in the MicroSD slot of the target machine, or >>>> in a USB reader; this *single* system is what I boot on *all* Chromebooks that I >>>> have: one kernel, multiple devicetrees, same Debian-based userspace. >>>> >>>> What we have to prepare this bootable media can be found at [1], but beware that >>>> it currently uses an outdated kernel, so, what I have locally is a symlink to my >>>> kernel tree. >>>> You can change/add/remove the devicetree blobs that will get added to the image >>>> by modifying `chromebook-setup.sh`; before tampering with kernel tree symlink, >>>> please run that script for the first time, as it will download a cross-compiler, >>>> a kernel tree (that you will replace for sure) and the (very old) Debian rootfs >>>> that you can update with `apt-get dist-upgrade` after booting the Chromebook. >>>> >>>> If you want to check about possible kernel configuration differences, what I use >>>> is at [2], so that you can compare. >>> >>> Thanks for the information, I would try to compare the kernel config first. >> >> Hi CK, >> >> Would you consider adding your repo to linux-next? That would let everyone >> do integration testing, especially automated ones, earlier, before you send >> your PRs to drm maintainers. >> >> You can do so by sending an email to Stephen Rothwell to do so. > > I don't understand what this process is. Does it means that I directly > upstream patches into linux-next? I prefer that my patches go through > drm maintainers' tree. Does any document introduce this process? All maintainers and sub-maintainers trees are supposed to be fed into linux-next. https://lore.kernel.org/linux-next/20230327124805.3ca4f3cc@canb.auug.org.au/T/#md226a8e714cc731c2ab4ba5ee7eb43fe21a55009 Documentation/process/howto.rst Documentation/process/2.Process.rst Best regards, Krzysztof
On Mon, Apr 3, 2023 at 5:47 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 03/04/2023 05:30, Chun-Kuang Hu wrote: > > Hi, Chen-yu: > > > > Chen-Yu Tsai <wenst@chromium.org> 於 2023年3月30日 週四 下午7:05寫道： > >> > >> On Mon, Mar 27, 2023 at 11:17 PM Chun-Kuang Hu <chunkuang.hu@kernel.org> wrote: > >>> > >>> Hi, Angelo: > >>> > >>> AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > >>> 2023年3月24日 週五 下午4:38寫道： > >>>> > >>>> Il 24/03/23 00:25, Chun-Kuang Hu ha scritto: > >>>>> Hi, Angelo: > >>>>> > >>>>> AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 > >>>>> 2023年3月23日 週四 下午4:58寫道： > >>>>>> > >>>>>> Il 21/03/23 13:18, Nancy.Lin ha scritto: > >>>>>>> The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. > >>>>>>> > >>>>>>> Add DRM and these modules support by the patches below: > >>>>>>> > >>>>>> > >>>>>> I've tested v30 again on MT8173, MT8192 and MT8195 based Chromebooks. > >>>>>> Green light from me. > >>>>> > >>>>> I'm curious about how you build code and test on Chromebooks. Do you > >>>>> build in cros environment or pure linux > >>>>> (https://archlinuxarm.org/platforms/armv8/mediatek/acer-chromebook-r13). > >>>>> I've a MT8183 based Chromebook (HP 11a) and I've tried to run a > >>>>> upstream kernel on it. cros is too heavy for me and I doubt I could > >>>>> use it. I've tried the pure linux and could boot up with console, but > >>>>> display does not work. If you use the pure linux environment, could > >>>>> you share how it works? > >>>>> > >>>> > >>>> I haven't tested MT8183 (I don't actually have any 8183 machine in my hands)... but > >>>> yes, I can share my test environment. > >>>> > >>>> I have one MicroSD that I use either in the MicroSD slot of the target machine, or > >>>> in a USB reader; this *single* system is what I boot on *all* Chromebooks that I > >>>> have: one kernel, multiple devicetrees, same Debian-based userspace. > >>>> > >>>> What we have to prepare this bootable media can be found at [1], but beware that > >>>> it currently uses an outdated kernel, so, what I have locally is a symlink to my > >>>> kernel tree. > >>>> You can change/add/remove the devicetree blobs that will get added to the image > >>>> by modifying `chromebook-setup.sh`; before tampering with kernel tree symlink, > >>>> please run that script for the first time, as it will download a cross-compiler, > >>>> a kernel tree (that you will replace for sure) and the (very old) Debian rootfs > >>>> that you can update with `apt-get dist-upgrade` after booting the Chromebook. > >>>> > >>>> If you want to check about possible kernel configuration differences, what I use > >>>> is at [2], so that you can compare. > >>> > >>> Thanks for the information, I would try to compare the kernel config first. > >> > >> Hi CK, > >> > >> Would you consider adding your repo to linux-next? That would let everyone > >> do integration testing, especially automated ones, earlier, before you send > >> your PRs to drm maintainers. > >> > >> You can do so by sending an email to Stephen Rothwell to do so. > > > > I don't understand what this process is. Does it means that I directly > > upstream patches into linux-next? I prefer that my patches go through > > drm maintainers' tree. Does any document introduce this process? > > All maintainers and sub-maintainers trees are supposed to be fed into > linux-next. > > https://lore.kernel.org/linux-next/20230327124805.3ca4f3cc@canb.auug.org.au/T/#md226a8e714cc731c2ab4ba5ee7eb43fe21a55009 > > Documentation/process/howto.rst > Documentation/process/2.Process.rst As Krzysztof mentioned, the purpose of linux-next is for integration testing. Your queued up patches still go through the DRM tree for eventually merging into Linus's tree. Getting included into linux-next means that your branch gets automatically merged together with other branches, gets build and boot tested by the various CI platforms and bots out there, and provides a common base for other developers. I don't think there is any downside to having your branch integrated into linux-next. ChenYu
The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. Add DRM and these modules support by the patches below: Changes in v30: - rebase to next-20230321 - fix ethdr dt_binding_check message Changes in v29: - rebase to next-20221226 - fix reviewer comment in v28 - keep original flow if comp node not found in mtk_drm_crtc_create() Changes in v28: - rebase to next-20221107 - fix reviewer comment in v27 - extra new line at the end mtk_ethdr.h Changes in v27: - rebase to next-20221102 - change mmsys compatible for mt8195 vdosys1 - base on jason's series[ref 1] - fix reviewer comment - add error return code if no ovl_adaptor's comp found Changes in v26: - rebase to next-20220819 - resend for patch corrupted in v25 Changes in v25: - rebase to next-20220803 Changes in v24: - fix ovl_adaptor binding issue (mtk_disp_ovl_adaptor.c) - Since ovl_adaptor is an aggregated component, it should be bounded after all its child components are bounded. - rebase to next-20220708 Changes in v23: - separate[7] mmsys/mutex and drm patches into two series Changes in v22: - rebase to next-20220525 - rebase to vdosys0 series v22 - separate dts to a new patch Changes in v21: - fix reviewer comment - fix rdma and ethdr binding doc and dts Changes in v20: - fix reviewer comment - update mmsys update bit api name - add mtk_mmsys_update_bits error message if lose gce property - list all mt8195 vdosys1 reset bits Changes in v19: - fix reviewer comment - separate mt8195 mmsys component to a new patch - separate mt8195 vdo0 and vdo1 routing table - separate mmsys_write_reg api to a new patch and simplify write reg code - separate mmsys 64 bit reset to a new patch - separate mtk-mutex dp_intf1 component to a new patch Changes in v18: - fix reviewer comment - fix rdma binding doc - fix ethdr binding doc - refine mmsys config cmdq support - refine merge reset control flow, get reset control in probe function - add ethdr reset control error handling and remove dbg log - rebase to vdosys0 series v20 (ref [5]) Changes in v17: - fix reviewer comment in v16 - separate ovl adaptor comp in mtk-mmsys and mtk-mutex - separate mmsys config API - move mdp_rdma binding yaml - fix ovl adaptor pm runtime get sync timing issue - rebase to vdosys0 series v19 (ref [5]) - rebase to [7] for modify vblank register change Changes in v16: - fix reviewer comment in v 15 - fix mtk_drm_ddp_comp.c alignment - fix vdosys0 mmsys num before adding vdosys1 patch Changes in v15: - fix ethdr uppercase hex number in dts Changes in v14: - remove MTK_MMSYS 64 bit dependency - add ethdr.yaml back and fix dt_schema check fail Resend v13 - add related maintainer in maillist Changes in v13: - fix reviewer comment in v12 - fix rdma dt-binding format - fix dts node naming - fix 32 bit build error - modify 64bit dependency for mtk-mmsys - rebase to vdosys0 series v16. (ref [5]) Changes in v12: - fix reviewer comment in v11 - modify mbox index - refine dma dev for ovl_adaptor sub driver Changes in v11: - remove ethdr vblank spin lock - refine ovl_adaptor print message Changes in v10: - refine ethdr reset control using devm_reset_control_array_get_optional_exclusive - fix ovl_adaptor mtk_ovl_adaptor_clk_enable error handle issue Changes in v9: - rebase on kernel-5.16-rc1 - rebase on vdosys0 series v13. (ref [5]) - fix ovl_adaptor sub driver is brought up unintentionally - fix clang build test fail- duplicate ethdr/mdp_rdma init_module/cleanup_module symbol issue Changes in v8: - separate merge async reset to new patch. - separate drm ovl_adaptor sub driver to new patch. - fix reviewer comment in v7. Changes in v7: - rebase on vdosys0 series v12 (ref[5]) - add dma description in ethdr binding document. - refine vdosys1 bit definition of mmsys routing table. - separate merge modification into 3 pathces. - separate mutex modification into 2 patches. - add plane color coding for mdp_rdma csc. - move mdp_rdma pm control to ovl_adaptor. - fix reviewer comment in v6. Changes in v6: - rebase on kernel-5.15-rc1. - change mbox label to gce0 for dts node of vdosys1. - modify mmsys reset num for mt8195. - rebase on vdosys0 series v10. (ref [5]) - use drm to bring up ovl_adaptor driver. - move drm iommu/mutex check from kms init to drm bind. - modify rdma binding doc location. (Documentation/devicetree/bindings/arm/) - modify for reviewer's comment in v5. Changes in v5: - add mmsys reset controller reference. Changes in v4: - use merge common driver for merge1~4. - refine ovl_adaptor rdma driver. - use ovl_adaptor ddp_comp function instead of ethdr. - modify for reviewer's comment in v3. Changes in v3: - modify for reviewer's comment in v2. - add vdosys1 2 pixels align limit. - add mixer odd offset support. Changes in v2: - Merge PSEUDO_OVL and ETHDR into one DRM component. - Add mmsys config API for vdosys1 hardware setting. - Add mmsys reset control using linux reset framework. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> This series are based on the following patch: [1] Change mmsys compatible for mt8195 mediatek-drm 20221126101220.18179-1-jason-jh.lin@mediatek.com Nancy.Lin (7): dt-bindings: mediatek: add ethdr definition for mt8195 drm/mediatek: add ETHDR support for MT8195 drm/mediatek: add ovl_adaptor support for MT8195 drm/mediatek: add dma dev get function drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support drm/mediatek: add drm ovl_adaptor sub driver for MT8195 drm/mediatek: add mediatek-drm of vdosys1 support for MT8195 .../display/mediatek/mediatek,ethdr.yaml | 182 ++++++ drivers/gpu/drm/mediatek/Makefile | 2 + drivers/gpu/drm/mediatek/mtk_disp_drv.h | 26 + .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 533 ++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 85 ++- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 6 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 129 +++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 58 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 366 ++++++++---- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 24 +- drivers/gpu/drm/mediatek/mtk_ethdr.c | 370 ++++++++++++ drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 + 12 files changed, 1618 insertions(+), 188 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h