Re: [PATCH v2 0/6] Support second Image Signal Processor on rk3399
Hey Heiko, I have tested your series and it successfully fixes the problem with the 2nd camera when HDMI is connected at boot. Besides that the patch looks good and my tests have confirmed that both cameras have the same output quality when I exchange the connected ISP instances. Tested-by: Sebastian Fricke Greetings, Sebastian On 10.02.2021 12:10, Heiko Stuebner wrote: The rk3399 has two ISPs and right now only the first one is usable. The second ISP is connected to the TXRX dphy on the soc. The phy of ISP1 is only accessible through the DSI controller's io-memory, so this series adds support for simply using the dsi controller is a phy if needed. That solution is needed at least on rk3399 and rk3288 but no-one has looked at camera support on rk3288 at all, so right now only implement the rk3399 specifics. changes in v2: - enable grf-clock also for init callback to not break if for example hdmi is connected on boot and disabled the grf clock during its probe - add Sebastian's Tested-by - add Rob's Ack for the phy-cells property Heiko Stuebner (6): drm/rockchip: dsi: add own additional pclk handling dt-bindings: display: rockchip-dsi: add optional #phy-cells property drm/rockchip: dsi: add ability to work as a phy instead of full dsi arm64: dts: rockchip: add #phy-cells to mipi-dsi1 arm64: dts: rockchip: add cif clk-control pinctrl for rk3399 arm64: dts: rockchip: add isp1 node on rk3399 .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 ++ drivers/gpu/drm/rockchip/Kconfig | 2 + .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 349 ++ 4 files changed, 391 insertions(+) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hi Sebastian, Am Samstag, 13. Februar 2021, 12:19:57 CET schrieb Sebastian Fricke: > On 11.02.2021 15:42, Heiko Stübner wrote: > >Am Donnerstag, 11. Februar 2021, 06:25:15 CET schrieb Sebastian Fricke: > >> On 10.02.2021 12:15, Heiko Stübner wrote: > >> >Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner: > >> >> I did some tests myself today as well and can confirm your > >> >> hdmi related finding - at least when plugged in on boot. > >> >> > >> >> I tried some combinations of camera vs. hdmi and it seems > >> >> really only when hdmi is plugged in on boot > >> > > >> >as you can see in v2, it should work now even with hdmi > >> >connected on boot. My patch ignored the grf-clock when > >> >doing the grf-based init. > >> > > >> >All clocks are on during boot and I guess the hdmi-driver > >> >did disable it after its probe. The phy_power_on functions > >> >did handle it correctly already, so it was only happening > >> >with hdmi connected on boot. > >> > >> Thank you very much for solving that problem, I've tested the scenarios > >> described below and it works like a charm. (With your V2) > >> > > >> > > >> >Btw. do you plan on submitting your ov13850 driver > >> >soonish? > >> > >> Actually, I have posted the patch already see here: > >> https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/ > > > >very cool to see > > > >> I currently review the requested changes and questions and will soon > >> post a second version, but I expect quite some time until it is actually > >> merged. > > > >could you Cc me on future versions? > > Sure will do :) by the way, you could also answer the v2 series with a Tested-by: Sebastian Fricke so we get some coverage :-) Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 Andreas (icedragon...@web.de) changed: What|Removed |Added Kernel Version|5.10.14 |5.10.16 Regression|No |Yes -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 --- Comment #7 from Andreas (icedragon...@web.de) --- OK, I could successfully bisect the right point. - last good kernel version was 5.8.18 (latest 5.8.) - first bad kernel version was 5.9.0 until latest 5.10.16! On the kernel 5.4 until 5.8.18 I could only get the 'warnings' like: [Sa Feb 13 20:37:08 2021] [drm] Failed to add display topology, DTM TA is not initialized. -> with kernel prior to and with 5.8.18 no real issue with resuming the screen (only the topology message above). Since 5.9.0: Feb 13 20:33:53 localhost kernel: [ 16.924598] [drm] Failed to add display topology, DTM TA is not initialized. Feb 13 20:33:53 localhost kernel: [ 71.826161] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting Feb 13 20:33:53 localhost kernel: [ 71.826168] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB34E Feb 13 20:33:53 localhost kernel: [ 71.826172] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147 Feb 13 20:33:53 localhost kernel: [ 71.826178] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! Feb 13 20:33:54 localhost kernel: [ 73.389814] [drm] amdgpu_dm_irq_schedule_work FAILED src 2 Also the current latest 5.10.16 produces the errors: Feb 13 17:41:21 localhost kernel: [ 92.580071] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting Feb 13 17:41:21 localhost kernel: [ 92.580079] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB34E Feb 13 17:41:21 localhost kernel: [ 92.580083] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147 Feb 13 17:41:21 localhost kernel: [ 92.580089] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! Feb 13 17:41:23 localhost kernel: [ 94.143214] [drm] amdgpu_dm_irq_schedule_work FAILED src 2 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] kernel: Expose SYS_kcmp by default
Hi! > Userspace has discovered the functionality offered by SYS_kcmp and has > started to depend upon it. In particular, Mesa uses SYS_kcmp for > os_same_file_description() in order to identify when two fd (e.g. device > or dmabuf) point to the same struct file. Since they depend on it for > core functionality, lift SYS_kcmp out of the non-default > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. Is it good idea to enable everything because Mesa uses it for file descriptors? This is really interesting syscall... Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm/sprd: add Unisoc's drm display controller driver
Daniel Vetter 于2021年2月3日周三 下午10:23写道： > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote: > > Adds DPU(Display Processor Unit) support for the Unisoc's display > subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and > more. > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > > > v2: > > - Use drm_xxx to replace all DRM_XXX. > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > v3: > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > Ok noticed one more, see below. > thks > > > --- > > drivers/gpu/drm/sprd/Kconfig| 1 + > > drivers/gpu/drm/sprd/Makefile | 4 +- > > drivers/gpu/drm/sprd/sprd_dpu.c | 985 > > > drivers/gpu/drm/sprd/sprd_dpu.h | 120 + > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 6 files changed, insertions(+), 2 deletions(-) > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > index 6e80cc9..9b4ef9a 100644 > > --- a/drivers/gpu/drm/sprd/Kconfig > > +++ b/drivers/gpu/drm/sprd/Kconfig > > @@ -3,6 +3,7 @@ config DRM_SPRD > > depends on ARCH_SPRD || COMPILE_TEST > > depends on DRM && OF > > select DRM_KMS_HELPER > > + select VIDEOMODE_HELPERS > > select DRM_GEM_CMA_HELPER > > select DRM_KMS_CMA_HELPER > > select DRM_MIPI_DSI > > diff --git a/drivers/gpu/drm/sprd/Makefile > b/drivers/gpu/drm/sprd/Makefile > > index 86d95d9..6c25bfa 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -1,5 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -subdir-ccflags-y += -I$(srctree)/$(src) > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > > > -obj-y := sprd_drm.o > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > b/drivers/gpu/drm/sprd/sprd_dpu.c > > new file mode 100644 > > index 000..d562d44 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > @@ -0,0 +1,985 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_drm.h" > > +#include "sprd_dpu.h" > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_PANEL_SIZE 0x20 > > +#define REG_BLEND_SIZE 0x24 > > +#define REG_BG_COLOR 0x2C > > + > > +/* Layer0 control registers */ > > +#define REG_LAY_BASE_ADDR0 0x30 > > +#define REG_LAY_BASE_ADDR1 0x34 > > +#define REG_LAY_BASE_ADDR2 0x38 > > +#define REG_LAY_CTRL 0x40 > > +#define REG_LAY_SIZE 0x44 > > +#define REG_LAY_PITCH0x48 > > +#define REG_LAY_POS 0x4C > > +#define REG_LAY_ALPHA0x50 > > +#define REG_LAY_CROP_START 0x5C > > + > > +/* Interrupt control registers */ > > +#define REG_DPU_INT_EN 0x1E0 > > +#define REG_DPU_INT_CLR 0x1E4 > > +#define REG_DPU_INT_STS 0x1E8 > > + > > +/* DPI control registers */ > > +#define REG_DPI_CTRL 0x1F0 > > +#define REG_DPI_H_TIMING 0x1F4 > > +#define REG_DPI_V_TIMING 0x1F8 > > + > > +/* MMU control registers */ > > +#define REG_MMU_EN 0x800 > > +#define REG_MMU_VPN_RANGE0x80C > > +#define REG_MMU_VAOR_ADDR_RD 0x818 > > +#define REG_MMU_VAOR_ADDR_WR 0x81C > > +#define REG_MMU_INV_ADDR_RD 0x820 > > +#define REG_MMU_INV_ADDR_WR 0x824 > > +#define REG_MMU_PPN1 0x83C > > +#define REG_MMU_RANGE1 0x840 > > +#define REG_MMU_PPN2 0x844 > > +#define REG_MMU_RANGE2 0x848 > > + > > +/* Global control bits */ > > +#define BIT_DPU_RUN BIT(0) > > +#define BIT_DPU_STOP BIT(1) > > +#define BIT_DPU_REG_UPDATE BIT(2) > > +#define BIT_DPU_IF_EDPI BIT(0) > > + > > +/* Layer control bits */ > > +#define BIT_DPU_LAY_EN BIT(0) > > +#define BIT_DPU_LAY_LAYER_ALPHA (0x01 << 2) > > +#define BIT_DPU_LAY_COMBO_ALPHA (0x02 << 2) > > +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4) > > +#define BIT_DPU_LAY_FORMAT_YUV420_2PLANE (0x01 << 4) > > +#define BIT_DPU_LAY_FORMAT_YUV420_3PLANE (0x02 << 4) > > +#define BIT_DPU_LAY_FORMAT_ARGB (0x03 << 4) > > +#define BIT_DPU_LAY_FORMAT_RGB565(0x04 << 4) > > +#define BIT_DPU_LAY_DATA_ENDIAN_B0B1B2B3 (0x00
Re: [PATCH v3 4/6] drm/sprd: add Unisoc's drm display controller driver
Daniel Vetter 于2021年2月3日周三 下午10:15写道： > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote: > > Adds DPU(Display Processor Unit) support for the Unisoc's display > subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and > more. > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > > > v2: > > - Use drm_xxx to replace all DRM_XXX. > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > v3: > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > Scrolling through the code looks very tidy, only thing I spotted is > that you could use the new drmm_ infrastructure we just landed. See > comments below, with that addressed: > Hi Daniel, Thank you for taking the time to review, i will update my patch on the drm-misc-next and replace drm_helpers with drmm_helpers. > > Acked-by: Daniel Vetter > > --- > > drivers/gpu/drm/sprd/Kconfig| 1 + > > drivers/gpu/drm/sprd/Makefile | 4 +- > > drivers/gpu/drm/sprd/sprd_dpu.c | 985 > > > drivers/gpu/drm/sprd/sprd_dpu.h | 120 + > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 6 files changed, insertions(+), 2 deletions(-) > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > index 6e80cc9..9b4ef9a 100644 > > --- a/drivers/gpu/drm/sprd/Kconfig > > +++ b/drivers/gpu/drm/sprd/Kconfig > > @@ -3,6 +3,7 @@ config DRM_SPRD > > depends on ARCH_SPRD || COMPILE_TEST > > depends on DRM && OF > > select DRM_KMS_HELPER > > + select VIDEOMODE_HELPERS > > select DRM_GEM_CMA_HELPER > > select DRM_KMS_CMA_HELPER > > select DRM_MIPI_DSI > > diff --git a/drivers/gpu/drm/sprd/Makefile > b/drivers/gpu/drm/sprd/Makefile > > index 86d95d9..6c25bfa 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -1,5 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -subdir-ccflags-y += -I$(srctree)/$(src) > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > > > -obj-y := sprd_drm.o > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > b/drivers/gpu/drm/sprd/sprd_dpu.c > > new file mode 100644 > > index 000..d562d44 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > @@ -0,0 +1,985 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_drm.h" > > +#include "sprd_dpu.h" > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_PANEL_SIZE 0x20 > > +#define REG_BLEND_SIZE 0x24 > > +#define REG_BG_COLOR 0x2C > > + > > +/* Layer0 control registers */ > > +#define REG_LAY_BASE_ADDR0 0x30 > > +#define REG_LAY_BASE_ADDR1 0x34 > > +#define REG_LAY_BASE_ADDR2 0x38 > > +#define REG_LAY_CTRL 0x40 > > +#define REG_LAY_SIZE 0x44 > > +#define REG_LAY_PITCH0x48 > > +#define REG_LAY_POS 0x4C > > +#define REG_LAY_ALPHA0x50 > > +#define REG_LAY_CROP_START 0x5C > > + > > +/* Interrupt control registers */ > > +#define REG_DPU_INT_EN 0x1E0 > > +#define REG_DPU_INT_CLR 0x1E4 > > +#define REG_DPU_INT_STS 0x1E8 > > + > > +/* DPI control registers */ > > +#define REG_DPI_CTRL 0x1F0 > > +#define REG_DPI_H_TIMING 0x1F4 > > +#define REG_DPI_V_TIMING 0x1F8 > > + > > +/* MMU control registers */ > > +#define REG_MMU_EN 0x800 > > +#define REG_MMU_VPN_RANGE0x80C > > +#define REG_MMU_VAOR_ADDR_RD 0x818 > > +#define REG_MMU_VAOR_ADDR_WR 0x81C > > +#define REG_MMU_INV_ADDR_RD 0x820 > > +#define REG_MMU_INV_ADDR_WR 0x824 > > +#define REG_MMU_PPN1 0x83C > > +#define REG_MMU_RANGE1 0x840 > > +#define REG_MMU_PPN2 0x844 > > +#define REG_MMU_RANGE2 0x848 > > + > > +/* Global control bits */ > > +#define BIT_DPU_RUN BIT(0) > > +#define BIT_DPU_STOP BIT(1) > > +#define BIT_DPU_REG_UPDATE BIT(2) > > +#define BIT_DPU_IF_EDPI BIT(0) > > + > > +/* Layer control bits */ > > +#define BIT_DPU_LAY_EN BIT(0) > > +#define BIT_DPU_LAY_LAYER_ALPHA (0x01 << 2) > > +#define BIT_DPU_LAY_COMBO_ALPHA (0x02 << 2) > > +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4) > > +#define
Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hey Heiko, On 11.02.2021 15:42, Heiko Stübner wrote: Hi Sebastian, Am Donnerstag, 11. Februar 2021, 06:25:15 CET schrieb Sebastian Fricke: Hey Heiko, On 10.02.2021 12:15, Heiko Stübner wrote: >Hi Sebastian, > >Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner: >> Hi Sebastian, >> >> I did some tests myself today as well and can confirm your >> hdmi related finding - at least when plugged in on boot. >> >> I tried some combinations of camera vs. hdmi and it seems >> really only when hdmi is plugged in on boot > >as you can see in v2, it should work now even with hdmi >connected on boot. My patch ignored the grf-clock when >doing the grf-based init. > >All clocks are on during boot and I guess the hdmi-driver >did disable it after its probe. The phy_power_on functions >did handle it correctly already, so it was only happening >with hdmi connected on boot. Thank you very much for solving that problem, I've tested the scenarios described below and it works like a charm. (With your V2) > > >Btw. do you plan on submitting your ov13850 driver >soonish? Actually, I have posted the patch already see here: https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/ very cool to see I currently review the requested changes and questions and will soon post a second version, but I expect quite some time until it is actually merged. could you Cc me on future versions? Sure will do :) Thanks Heiko Sebastian Greetings, Sebastian > > >> >> (1) >> - boot >> - camera >> --> works >> >> (2) >> - boot >> - camera >> - hdmi plugged in >> - hdmi works >> - camera >> --> works >> >> (3) >> - hdmi plugged in >> - boot >> - hdmi works >> - camera >> --> camera doesn't work >> >> (4) >> - boot >> - hdmi plugged in >> - hdmi works >> - camera >> -> camera works >> >> >> With a bit of brute-force [0] it seems the camera also works again even >> with hdmi connected on boot. So conclusion would be that some clock >> is misbehaving. >> >> Now we'll "only" need to find out which one that is. >> >> >> Heiko >> >> >> [0] >> Don't disable any clock gates >> >> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c >> index 070dc47e95a1..8daf1fc3388c 100644 >> --- a/drivers/clk/clk-gate.c >> +++ b/drivers/clk/clk-gate.c >> @@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable) >> >> set ^= enable; >> >> +if (!enable) >> +return; >> + >> if (gate->lock) >> spin_lock_irqsave(gate->lock, flags); >> else >> >> >> >> Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner: >> > Hi Sebastian, >> > >> > Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke: >> > > On 03.02.2021 20:54, Heiko Stübner wrote: >> > > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke: >> > > >> I have tested your patch set on my nanoPC-T4, here is a complete log >> > > >> with: >> > > >> - relevant kernel log entries >> > > >> - system information >> > > >> - media ctl output >> > > >> - sysfs entry information >> > > >> >> > > >> https://paste.debian.net/1183874/ >> > > >> >> > > >> Additionally, to your patchset I have applied the following patches: >> > > >> https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup >> > > >> >> > > >> And just to not cause confusion the `media_dev` entries come from this >> > > >> unmerged series: >> > > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269 >> > > >> >> > > >> I have actually been able to stream with both of my cameras at the same >> > > >> time using the libcamera cam command. >> > > >> I would like to thank you a lot for making this possible. >> > > > >> > > >Thanks for testing a dual camera setup. On my board I could only test >> > > >the second ISP. And really glad it works for you tool :-) . >> > > > >> > > >Out of curiosity, do you also see that green tint in the images the cameras >> > > >produce? >> > > >> > > Yes, I do. Actually, I currently have two forms of a green tint, on my >> > > OV13850 everything is quite dark and greenish, which is caused by the >> > > missing 3A algorithms. On my OV4689, I have big patches of the image >> > > with bright green color and flickering, I investigated if this is >> > > connected to the 2nd ISP instance, but that doesn't seem to be the case >> > > as I have the same results when I switch the CSI ports of the cameras. >> > > >> > > I have found another issue, while testing I discovered following >> > > issue: >> > > When I start the system with an HDMI monitor connected, then the camera >> > > on the 2nd port doesn't work. This is probably because the RX/TX is >> > > reserved as a TX. >> > > But it made me wonder because if the system has an RX, a TX, and >> > > an RX/TX, why isn't the pure TX used by the monitor and the >> > > cameras take RX and RX/TX? >> > > Or do you think that this is maybe a malfunction of this patch? >> > >> > I
Re: [PATCH v3 1/3] drm/mediatek: mtk_dpi: Add check for max clock rate in mode_valid
+Pi-Hsun Shih
On Mon, Feb 8, 2021 at 9:42 AM Jitao Shi wrote:
>
> Add per-platform max clock rate check in mtk_dpi_bridge_mode_valid.
>
> Signed-off-by: Jitao Shi
I believe this patch (and the following) were actually authored by
Pi-Hsun: https://crrev.com/c/2628812 . Would be best to keep the
author information (unless I'm missing something of course).
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 52f11a63a330..ffa4a0f1989f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -118,6 +118,7 @@ struct mtk_dpi_yc_limit {
> struct mtk_dpi_conf {
> unsigned int (*cal_factor)(int clock);
> u32 reg_h_fre_con;
> + u32 max_clock_khz;
> bool edge_sel_en;
> };
>
> @@ -555,9 +556,22 @@ static void mtk_dpi_bridge_enable(struct drm_bridge
> *bridge)
> mtk_dpi_set_display_mode(dpi, >mode);
> }
>
> +static enum drm_mode_status
> +mtk_dpi_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> +
> + if (dpi->conf->max_clock_khz && mode->clock >
> dpi->conf->max_clock_khz)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
> .attach = mtk_dpi_bridge_attach,
> .mode_set = mtk_dpi_bridge_mode_set,
> + .mode_valid = mtk_dpi_bridge_mode_valid,
> .disable = mtk_dpi_bridge_disable,
> .enable = mtk_dpi_bridge_enable,
> };
> @@ -673,17 +687,20 @@ static unsigned int mt8183_calculate_factor(int clock)
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> + .max_clock_khz = 30,
> };
>
> static const struct mtk_dpi_conf mt2701_conf = {
> .cal_factor = mt2701_calculate_factor,
> .reg_h_fre_con = 0xb0,
> .edge_sel_en = true,
> + .max_clock_khz = 15,
> };
>
> static const struct mtk_dpi_conf mt8183_conf = {
> .cal_factor = mt8183_calculate_factor,
> .reg_h_fre_con = 0xe0,
> + .max_clock_khz = 10,
> };
>
> static int mtk_dpi_probe(struct platform_device *pdev)
> --
> 2.25.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Odroid GO Advance display in mainline (Re: [PATCH 1/2] drm/panel: add rotation support for Elida KD35T133 panels)
(Now with Heiko's address fixed)
On Sat, 13 Feb 2021 at 10:53, Ezequiel Garcia
wrote:
>
> Hi Chris,
>
> I'm hijacking this discussion a bit.
>
> I recently tried to boot maline on my Odroid GOA, which I managed to do,
> except the display wasn't displaying anything :-)
>
> Everything looks good on a quick look, the Inno PHY driver is here,
> and there's a DRM card registered with the right mode 320x240 and
> connected status (which I suppose doesn't mean much in this case).
> Also, the backlight is on.
>
> Looks like this is working for you, so I was wondering if maybe
> this would ring a bell, or perhaps you're aware of any patches
> we are missing in v5.11-rc7 (which is what I'm basing on).
> Or maybe I'm missing some config?...
>
> Any ideas would be welcome!
>
> Ezequiel
>
> On Fri, 12 Feb 2021 at 12:51, Chris Morgan wrote:
> >
> > Update the panel to allow setting the rotation value in device tree.
> >
> > Signed-off-by: Chris Morgan
> > ---
> > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > index bc36aa3c1123..d8534406d1ef 100644
> > --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > @@ -42,6 +42,7 @@ struct kd35t133 {
> > struct gpio_desc *reset_gpio;
> > struct regulator *vdd;
> > struct regulator *iovcc;
> > + enum drm_panel_orientation orientation;
> > bool prepared;
> > };
> >
> > @@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
> > connector->display_info.width_mm = mode->width_mm;
> > connector->display_info.height_mm = mode->height_mm;
> > drm_mode_probed_add(connector, mode);
> > + drm_connector_set_panel_orientation(connector, ctx->orientation);
> >
> > return 1;
> > }
> > @@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
> > return ret;
> > }
> >
> > + ret = of_drm_get_panel_orientation(dev->of_node, >orientation);
> > + if (ret < 0) {
> > + dev_err(dev, "%pOF: failed to get orientation %d\n",
> > dev->of_node, ret);
> > + return ret;
> > + }
> > +
> > mipi_dsi_set_drvdata(dsi, ctx);
> >
> > ctx->dev = dev;
> > --
> > 2.25.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Odroid GO Advance display in mainline (Re: [PATCH 1/2] drm/panel: add rotation support for Elida KD35T133 panels)
Hi Chris,
I'm hijacking this discussion a bit.
I recently tried to boot maline on my Odroid GOA, which I managed to do,
except the display wasn't displaying anything :-)
Everything looks good on a quick look, the Inno PHY driver is here,
and there's a DRM card registered with the right mode 320x240 and
connected status (which I suppose doesn't mean much in this case).
Also, the backlight is on.
Looks like this is working for you, so I was wondering if maybe
this would ring a bell, or perhaps you're aware of any patches
we are missing in v5.11-rc7 (which is what I'm basing on).
Or maybe I'm missing some config?...
Any ideas would be welcome!
Ezequiel
On Fri, 12 Feb 2021 at 12:51, Chris Morgan wrote:
>
> Update the panel to allow setting the rotation value in device tree.
>
> Signed-off-by: Chris Morgan
> ---
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> index bc36aa3c1123..d8534406d1ef 100644
> --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> @@ -42,6 +42,7 @@ struct kd35t133 {
> struct gpio_desc *reset_gpio;
> struct regulator *vdd;
> struct regulator *iovcc;
> + enum drm_panel_orientation orientation;
> bool prepared;
> };
>
> @@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
> connector->display_info.width_mm = mode->width_mm;
> connector->display_info.height_mm = mode->height_mm;
> drm_mode_probed_add(connector, mode);
> + drm_connector_set_panel_orientation(connector, ctx->orientation);
>
> return 1;
> }
> @@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
> return ret;
> }
>
> + ret = of_drm_get_panel_orientation(dev->of_node, >orientation);
> + if (ret < 0) {
> + dev_err(dev, "%pOF: failed to get orientation %d\n",
> dev->of_node, ret);
> + return ret;
> + }
> +
> mipi_dsi_set_drvdata(dsi, ctx);
>
> ctx->dev = dev;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/tegra: Add NVDEC driver
Hi Mikko,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra/for-next]
[also build test ERROR on robh/for-next tegra-drm/drm/tegra/for-next v5.11-rc7
next-20210212]
[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]
url:
https://github.com/0day-ci/linux/commits/Mikko-Perttunen/NVIDIA-Tegra-NVDEC-support/20210213-181808
base: https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/5951327b2039bedd20ca3e7837d4cb6021dc9777
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Mikko-Perttunen/NVIDIA-Tegra-NVDEC-support/20210213-181808
git checkout 5951327b2039bedd20ca3e7837d4cb6021dc9777
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/tegra/nvdec.c: In function 'nvdec_init':
>> drivers/gpu/drm/tegra/nvdec.c:131:2: error: implicit declaration of function
>> 'host1x_syncpt_put'; did you mean 'host1x_syncpt_get'?
>> [-Werror=implicit-function-declaration]
131 | host1x_syncpt_put(client->syncpts[0]);
| ^
| host1x_syncpt_get
cc1: some warnings being treated as errors
vim +131 drivers/gpu/drm/tegra/nvdec.c
91
92 static int nvdec_init(struct host1x_client *client)
93 {
94 struct tegra_drm_client *drm = host1x_to_drm_client(client);
95 struct drm_device *dev = dev_get_drvdata(client->host);
96 struct tegra_drm *tegra = dev->dev_private;
97 struct nvdec *nvdec = to_vic(drm);
98 int err;
99
100 err = host1x_client_iommu_attach(client);
101 if (err < 0 && err != -ENODEV) {
102 dev_err(nvdec->dev, "failed to attach to domain: %d\n",
err);
103 return err;
104 }
105
106 nvdec->channel = host1x_channel_request(client);
107 if (!nvdec->channel) {
108 err = -ENOMEM;
109 goto detach;
110 }
111
112 client->syncpts[0] = host1x_syncpt_request(client, 0);
113 if (!client->syncpts[0]) {
114 err = -ENOMEM;
115 goto free_channel;
116 }
117
118 err = tegra_drm_register_client(tegra, drm);
119 if (err < 0)
120 goto free_syncpt;
121
122 /*
123 * Inherit the DMA parameters (such as maximum segment size)
from the
124 * parent host1x device.
125 */
126 client->dev->dma_parms = client->host->dma_parms;
127
128 return 0;
129
130 free_syncpt:
> 131 host1x_syncpt_put(client->syncpts[0]);
132 free_channel:
133 host1x_channel_put(nvdec->channel);
134 detach:
135 host1x_client_iommu_detach(client);
136
137 return err;
138 }
139
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.
On Fri, 2021-02-12 at 21:01 -0500, Lyude Paul wrote: > (adding danvet to here, as I'd imagine they might be interested in > seeing some > of this) > > Thank you for the descriptive write up. I think we can solve some of > the > problems you described here, however the patches that you submitted > definitely > won't work as-is. In patch 2, by reverting Intel back to using only 7 > retries > you technically break whatever monitor originally prompted us to bump > the retry > count up to 32 in the first place. And we have to try our hardest to > avoid > breaking people's displays when they were already working. Got it. Thank you for pointing that out. > > Also, I'll definitely point out though that a few of the issues > you've pointed > out actually exist as workarounds for bad DisplayPort devices (which > is a big > reason we have these helpers), but I think we might be able to fix > some of the > issues you've mentioned by coming up with better workarounds. More > details below > > On Thu, 2021-02-11 at 06:56 +, Almahallawy, Khaled wrote: > > On Wed, 2021-02-10 at 13:03 -0500, Lyude Paul wrote: > > > On Wed, 2021-02-10 at 00:33 -0800, Khaled Almahallawy wrote: > > > > The number of AUX retries specified in the DP specs is 7. > > > > Currently, to make > > > > Dell 4k monitors happier, the number of retries are 32. > > > > i915 also retries 5 times (intel_dp_aux_xfer) which means in > > > > the > > > > case of AUX > > > > timeout we actually retries 32 * 5 = 160 times. > > > > > > Is there any good reason for i915 to actually be doing retries > > > itself? It seems > > > like an easier solution here might just to be to fix i915 so it > > > doesn't retry, > > > and just rely on DRM to do the retries as appropriate. > > > > > > That being said though, I'm open to this if there is a legitimate > > > reason for > > > i915 to be handling retries on its own > > > > i915 or others may benefit from controlling AUX retries to optimize > > and > > minimize timing spent on the aux transactions. > > > > drm_dpcd_access handles multiple aux retries cases the same way > > (retry > > 32 times at worst case). The 4 cases are: > > 1- *AUX receive or IO error*. I believe it is up to specific > > implementation/HW once it detects a receive error to retry based on > > their internal understanding using the timeout appropriate to the > > HW > > capabilities. > > This makes sense so far > > > > > 2- *AUX Timeout* As the driver follows the specs for the > > recommended > > timeout timer as defined in section (2.11.2 AUX Transaction > > Response/Reply Timeouts), the driver has more intelligence to know > > how > > many retries it needs. This is more useful in case of DP-ALT if > > some > > issues happen in Type-C stack that cause AUX timeout (e.g. USB3 > > dock > > detected as high speed (USB2) causing SBU/AUX lines to be > > disabled). > > Also the disconnect of MST hub/docks is dependent how fast a > > userspace > > disconnect all MST connectors. Not all user spaces do it as fast > > like > > Chrome (ubuntu is an example): > > https://chromium-review.googlesource.com/c/chromium/src/+/2512550/ > > > > So - I'm not exactly following how this portion of the specification > is relevant > to the issue that you're bringing up here. If I understand section > 2.11.2 > correctly, a "response" here is defined as a transmission from the > DPRX which > informs us on the current state of the transaction that we've > started. This > would be any one of the aux response statuses you've mentioned in > this email: > AUX_NACK, AUX_ACK, or AUX_DEFER. It doesn't actually have anything to > do with > the number of retries we have to do, because (ignoring the fact we > retry on > AUX_NACKS in DRM for a moment here) that reply could be an AUX_DEFER > which would > indicate that we have to resend the transaction and try again. I > think this is > the correct understanding of section 2.11.2, because I definitely > don't think > real world DP devices are able to actually complete a full AUX > transaction > within a timespan of 300-400µs reliably for the most part. The AUX timeout I am considering is from the point of view of DPTX (Display Source) not DPRX. Quoting DP2.0 Spec- Sec 2.11.2: “If the DPTX does not receive a reply from the DPRX, the DPTX shall wait for an AUX Reply Timeout *timer period* before initiating the next AUX Request transaction. … For all AUX transactions, the AUX Reply Timeout *timer* starts ticking after the DPTX finishes transmitting the AUX STOP condition. The timer is *reset* when the AUX Reply Timeout timer period has *elapsed*” This AUX timeout retries is also defined in DP 1.4a Link Layer CTS r1.0: “4.2.1.1 Source DUT Retry on No-Reply during AUX Read after HPD Plug Event Test Objective: This test confirms that the Source DUT retries AUX requests on HPD plug event if the Sink does not initially reply.” Based on this, when the Aux timeout *timer* configured by hardware/driver is *expired* before
[PATCH 0/3] NVIDIA Tegra NVDEC support
Hi all, with the release of documentation headers for Tegra multimedia engines (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding implementations. Here's the first one, NVDEC. The kernel driver is a simple Falcon boot driver based on the VIC driver. Some code sharing should be considered there in the future. The userspace driver to accompany this is a bit more complicated - I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding. It should be noted that the implementation is still very clunky and has poor performance, but it's a start. This series is based on top of the "Host1x/TegraDRM UAPI" series. For testing, appropriate firmware should be obtained from a Linux for Tegra distribution for now; the GPU should also be enabled in the device tree. Series was tested on Tegra186. Thanks! Mikko [1] https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video [2] https://github.com/cyndis/vaapi-tegra-driver Mikko Perttunen (3): dt-bindings: Add YAML bindings for Host1x and NVDEC arm64: tegra: Add NVDEC to Tegra186 device tree drm/tegra: Add NVDEC driver .../gpu/host1x/nvidia,tegra20-host1x.yaml | 129 + .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 90 MAINTAINERS | 1 + arch/arm64/boot/dts/nvidia/tegra186.dtsi | 15 + drivers/gpu/drm/tegra/Makefile| 3 +- drivers/gpu/drm/tegra/drm.c | 4 + drivers/gpu/drm/tegra/drm.h | 1 + drivers/gpu/drm/tegra/nvdec.c | 497 ++ drivers/gpu/host1x/dev.c | 12 + include/linux/host1x.h| 1 + 10 files changed, 752 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml create mode 100644 drivers/gpu/drm/tegra/nvdec.c -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] arm64: tegra: Add NVDEC to Tegra186 device tree
Add a device tree node for NVDEC on Tegra186.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 58c51965df47..4bb6fbe6b9ce 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1340,6 +1340,21 @@ dsib: dsi@1540 {
power-domains = < TEGRA186_POWER_DOMAIN_DISP>;
};
+ nvdec@1548 {
+ compatible = "nvidia,tegra186-nvdec";
+ reg = <0x1548 0x4>;
+ clocks = < TEGRA186_CLK_NVDEC>;
+ clock-names = "nvdec";
+ resets = < TEGRA186_RESET_NVDEC>;
+ reset-names = "nvdec";
+
+ power-domains = < TEGRA186_POWER_DOMAIN_NVDEC>;
+ interconnects = < TEGRA186_MEMORY_CLIENT_NVDECSRD
>,
+ < TEGRA186_MEMORY_CLIENT_NVDECSWR
>;
+ interconnect-names = "dma-mem", "write";
+ iommus = < TEGRA186_SID_NVDEC>;
+ };
+
sor0: sor@1554 {
compatible = "nvidia,tegra186-sor";
reg = <0x1554 0x1>;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC
Convert the original Host1x bindings to YAML and add new bindings for
NVDEC, now in a more appropriate location. The old text bindings
for Host1x and engines are still kept at display/tegra/ since they
encompass a lot more engines that haven't been converted over yet.
Signed-off-by: Mikko Perttunen
---
.../gpu/host1x/nvidia,tegra20-host1x.yaml | 129 ++
.../gpu/host1x/nvidia,tegra210-nvdec.yaml | 90
MAINTAINERS | 1 +
3 files changed, 220 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
create mode 100644
Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
diff --git
a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
new file mode 100644
index ..613c6601f0f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra20-host1x.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Device tree binding for NVIDIA Host1x
+
+maintainers:
+ - Thierry Reding
+ - Mikko Perttunen
+
+properties:
+ $nodename:
+pattern: "^host1x@[0-9a-f]*$"
+
+ compatible:
+oneOf:
+ - const: nvidia,tegra20-host1x
+ - const: nvidia,tegra30-host1x
+ - const: nvidia,tegra114-host1x
+ - const: nvidia,tegra124-host1x
+ - items:
+ - const: nvidia,tegra132-host1x
+ - const: nvidia,tegra124-host1x
+ - const: nvidia,tegra210-host1x
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description: Syncpoint threshold interrupt
+ - description: General interrupt
+
+ interrupt-names:
+items:
+ - const: syncpt
+ - const: host1x
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: host1x
+
+ resets:
+maxItems: 1
+
+ reset-names:
+items:
+ - const: host1x
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+maxItems: 1
+
+ interconnect-names:
+items:
+ - const: dma-mem
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 1
+
+ ranges: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+
+additionalProperties:
+ type: object
+
+if:
+ properties:
+compatible:
+ contains:
+anyOf:
+ - const: nvidia,tegra186-host1x
+ - const: nvidia,tegra194-host1x
+then:
+ properties:
+reg:
+ items:
+- description: Hypervisor-accessible register area
+- description: VM-accessible register area
+reg-names:
+ items:
+- const: hypervisor
+- const: vm
+ required:
+- reg-names
+
+examples:
+ - |
+#include
+#include
+
+host1x@5000 {
+compatible = "nvidia,tegra20-host1x";
+reg = <0x5000 0x00024000>;
+interrupts = , /* syncpt */
+ ; /* general */
+interrupt-names = "syncpt", "host1x";
+clocks = <_car TEGRA20_CLK_HOST1X>;
+clock-names = "host1x";
+resets = <_car 28>;
+reset-names = "host1x";
+
+#address-cells = <1>;
+#size-cells = <1>;
+
+ranges = <0x5400 0x5400 0x0400>;
+};
diff --git
a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
new file mode 100644
index ..9a6334d930c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Device tree binding for NVIDIA Tegra VIC
+
+maintainers:
+ - Thierry Reding
+ - Mikko Perttunen
+
+properties:
+ $nodename:
+pattern: "^nvdec@[0-9a-f]*$"
+
+ compatible:
+enum:
+ - nvidia,tegra210-nvdec
+ - nvidia,tegra186-nvdec
+ - nvidia,tegra194-nvdec
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: nvdec
+
+ resets:
+maxItems: 1
+
+ reset-names:
+items:
+ - const: nvdec
+
+ power-domains:
+maxItems: 1
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+items:
+ - description: DMA read memory client
+ - description: DMA write memory client
+
+ interconnect-names:
+items:
+ - const: dma-mem
+ - const: write
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+
+additionalProperties: false
+
[PATCH 3/3] drm/tegra: Add NVDEC driver
Add support for booting and using NVDEC on Tegra210, Tegra186
and Tegra194 to the Host1x and TegraDRM drivers. Booting in
secure mode is not currently supported.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/Makefile | 3 +-
drivers/gpu/drm/tegra/drm.c| 4 +
drivers/gpu/drm/tegra/drm.h| 1 +
drivers/gpu/drm/tegra/nvdec.c | 497 +
drivers/gpu/host1x/dev.c | 12 +
include/linux/host1x.h | 1 +
6 files changed, 517 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tegra/nvdec.c
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 4e3295f436f1..a736bb5e5376 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -24,7 +24,8 @@ tegra-drm-y := \
gr2d.o \
gr3d.o \
falcon.o \
- vic.o
+ vic.o \
+ nvdec.o
tegra-drm-y += trace.o
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 60eab403ae9b..accc41bff173 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1338,15 +1338,18 @@ static const struct of_device_id host1x_drm_subdevs[] =
{
{ .compatible = "nvidia,tegra210-sor", },
{ .compatible = "nvidia,tegra210-sor1", },
{ .compatible = "nvidia,tegra210-vic", },
+ { .compatible = "nvidia,tegra210-nvdec", },
{ .compatible = "nvidia,tegra186-display", },
{ .compatible = "nvidia,tegra186-dc", },
{ .compatible = "nvidia,tegra186-sor", },
{ .compatible = "nvidia,tegra186-sor1", },
{ .compatible = "nvidia,tegra186-vic", },
+ { .compatible = "nvidia,tegra186-nvdec", },
{ .compatible = "nvidia,tegra194-display", },
{ .compatible = "nvidia,tegra194-dc", },
{ .compatible = "nvidia,tegra194-sor", },
{ .compatible = "nvidia,tegra194-vic", },
+ { .compatible = "nvidia,tegra194-nvdec", },
{ /* sentinel */ }
};
@@ -1370,6 +1373,7 @@ static struct platform_driver * const drivers[] = {
_gr2d_driver,
_gr3d_driver,
_vic_driver,
+ _nvdec_driver,
};
static int __init host1x_drm_init(void)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 1af57c2016eb..ba52718a48bd 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -194,5 +194,6 @@ extern struct platform_driver tegra_sor_driver;
extern struct platform_driver tegra_gr2d_driver;
extern struct platform_driver tegra_gr3d_driver;
extern struct platform_driver tegra_vic_driver;
+extern struct platform_driver tegra_nvdec_driver;
#endif /* HOST1X_DRM_H */
diff --git a/drivers/gpu/drm/tegra/nvdec.c b/drivers/gpu/drm/tegra/nvdec.c
new file mode 100644
index ..0b78ee81d01f
--- /dev/null
+++ b/drivers/gpu/drm/tegra/nvdec.c
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015-2021, NVIDIA Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "drm.h"
+#include "falcon.h"
+#include "vic.h"
+
+struct nvdec_config {
+ const char *firmware;
+ unsigned int version;
+ bool supports_sid;
+};
+
+struct nvdec {
+ struct falcon falcon;
+
+ void __iomem *regs;
+ struct tegra_drm_client client;
+ struct host1x_channel *channel;
+ struct device *dev;
+ struct clk *clk;
+ struct reset_control *rst;
+
+ /* Platform configuration */
+ const struct nvdec_config *config;
+};
+
+static inline struct nvdec *to_vic(struct tegra_drm_client *client)
+{
+ return container_of(client, struct nvdec, client);
+}
+
+static void nvdec_writel(struct nvdec *nvdec, u32 value, unsigned int offset)
+{
+ writel(value, nvdec->regs + offset);
+}
+
+static int nvdec_boot(struct nvdec *nvdec)
+{
+#ifdef CONFIG_IOMMU_API
+ struct iommu_fwspec *spec = dev_iommu_fwspec_get(nvdec->dev);
+#endif
+ int err = 0;
+
+#ifdef CONFIG_IOMMU_API
+ if (nvdec->config->supports_sid && spec) {
+ u32 value;
+
+ value = TRANSCFG_ATT(1, TRANSCFG_SID_FALCON) |
+ TRANSCFG_ATT(0, TRANSCFG_SID_HW);
+ nvdec_writel(nvdec, value, VIC_TFBIF_TRANSCFG);
+
+ if (spec->num_ids > 0) {
+ value = spec->ids[0] & 0x;
+
+ nvdec_writel(nvdec, value, VIC_THI_STREAMID0);
+ nvdec_writel(nvdec, value, VIC_THI_STREAMID1);
+ }
+ }
+#endif
+
+ err = falcon_boot(>falcon);
+ if (err < 0)
+ return err;
+
+ err = falcon_wait_idle(>falcon);
+ if (err < 0) {
+ dev_err(nvdec->dev,
+ "failed to set application ID and FCE base\n");
+ return err;
+ }
+
+ return 0;
+}
+
+static int nvdec_init(struct host1x_client *client)
