RE: [PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper
Thanks Maarten now I can build the kernel again. /Marta > -Original Message- > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf > Of Maarten Lankhorst > Sent: Tuesday, June 6, 2017 5:32 PM > To: Archit Taneja ; Eric Anholt ; > Andrzej Hajda ; Laurent Pinchart > ; Thierry Reding > > Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org > Subject: [PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper > > This fixes the following depmod error when building drm as a module: > depmod: ERROR: Found 6 modules in dependency cycles! > depmod: ERROR: Cycle detected: drm -> drm_kms_helper -> drm > > Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the > lvds-encoder bridge.") > Signed-off-by: Maarten Lankhorst > --- > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > dc69175255b1..3999dffcd9ef 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -24,7 +24,6 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o > drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o > drm-$(CONFIG_PCI) += ati_pcigart.o > drm-$(CONFIG_DRM_PANEL) += drm_panel.o > -drm-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o > drm-$(CONFIG_OF) += drm_of.o > drm-$(CONFIG_AGP) += drm_agpsupport.o > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o @@ - > 35,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_probe_helper.o \ > drm_simple_kms_helper.o > drm_modeset_helper.o \ > drm_scdc_helper.o > > +drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += > drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += > drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += > drm_fb_cma_helper.o > > ___ > 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 v5 4/5] arm64: dts: exynos: Remove the OF graph from DSI node
On 05/19/2017 03:17 PM, Hoegeun Kwon wrote: On 05/16/2017 01:48 AM, Krzysztof Kozlowski wrote: On Wed, Mar 08, 2017 at 01:54:11PM +0900, Hoegeun Kwon wrote: The OF graph is not needed because the panel is a child of dsi. Remove the ports node in DSI node. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda Reviewed-by: Andi Shyti --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 14 -- 1 file changed, 14 deletions(-) Hi, I wanted to apply this (and 5/5) but it seems that DRM change is not merged. Was it included in v4.12-rc1? Best regards, Krzysztof Hi, Sorry for my belated reply. The DRM patch(3/5) is not merged in v4.12-rc1 (mainline)... I have checked the David's branch, but not merged. However it was merged into Inki's exynos drm branch. Inki, Could you check the patch(3/5). Best regards, Hoegeun Hi Krzysztof, The drm patch(3/5) has been merged into v4.12-rc4. Best regards, Hoegeun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-mainline-hybrid-4.11 103/518] drivers//pci/pci.c:2930:7: error: 'PCI_EXP_DEVCTL2_ATOMICOP_REQ' undeclared
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-hybrid-4.11 head: 7ccf5ab3da7a87288cc0fd11910b212e4ac154a6 commit: 22b340aa7636404cd6e4cb15f18bfb88afdbfb65 [103/518] PCI: Add pci_enable_atomic_request config: i386-defconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 22b340aa7636404cd6e4cb15f18bfb88afdbfb65 # save the attached .config to linux build tree make ARCH=i386 Note: the radeon-alex/amd-mainline-hybrid-4.11 HEAD 7ccf5ab3da7a87288cc0fd11910b212e4ac154a6 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers//pci/pci.c: In function 'pci_enable_atomic_request': >> drivers//pci/pci.c:2930:7: error: 'PCI_EXP_DEVCTL2_ATOMICOP_REQ' undeclared >> (first use in this function) PCI_EXP_DEVCTL2_ATOMICOP_REQ); ^~~~ drivers//pci/pci.c:2930:7: note: each undeclared identifier is reported only once for each function it appears in vim +/PCI_EXP_DEVCTL2_ATOMICOP_REQ +2930 drivers//pci/pci.c 2924 * to implement AtomicOp requester capabilities. */ 2925 case PCI_EXP_TYPE_ENDPOINT: 2926 case PCI_EXP_TYPE_LEG_END: 2927 case PCI_EXP_TYPE_RC_END: 2928 case PCI_EXP_TYPE_ROOT_PORT: 2929 pcie_capability_set_word(dev, PCI_EXP_DEVCTL2, > 2930 PCI_EXP_DEVCTL2_ATOMICOP_REQ); 2931 break; 2932 } 2933 } --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2
> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, June 06, 2017 7:10 PM > To: Christian König > Cc: linux-...@vger.kernel.org; platform-driver-...@vger.kernel.org; > Deucher, Alexander; David Airlie; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org > Subject: Re: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access > v2 > > On Tue, Jun 06, 2017 at 01:51:11PM +0200, Christian König wrote: > > Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas: > > >On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote: > > >>Hi Bjorn, > > >> > > >>sorry for not responding earlier and thanks for picking this thread > > >>up again. > > >> > > >>Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas: > > >>>[+cc ADMGPU, DRM folks] > > >>> > > >>>On Tue, May 09, 2017 at 06:49:07PM +0200, Christian König wrote: > > [SNIP] > > +/** > > + * amdgpu_resize_bar0 - try to resize BAR0 > > + * > > + * @adev: amdgpu_device pointer > > + * > > + * Try to resize BAR0 to make all VRAM CPU accessible. > > + */ > > +void amdgpu_resize_bar0(struct amdgpu_device *adev) > > +{ > > + u64 space_needed = roundup_pow_of_two(adev- > >mc.real_vram_size); > > + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) - > 1; > > + u16 cmd; > > + int r; > > + > > + /* Free the doorbell mapping, it most likely needs to move as > well */ > > + amdgpu_doorbell_fini(adev); > > + pci_release_resource(adev->pdev, 2); > > + > > + /* Disable memory decoding while we change the BAR > addresses and size */ > > + pci_read_config_word(adev->pdev, PCI_COMMAND, > &cmd); > > + pci_write_config_word(adev->pdev, PCI_COMMAND, > > + cmd & ~PCI_COMMAND_MEMORY); > > + > > + r = pci_resize_resource(adev->pdev, 0, rbar_size); > > + if (r == -ENOSPC) > > + DRM_INFO("Not enough PCI address space for a > large BAR."); > > + else if (r && r != -ENOTSUPP) > > + DRM_ERROR("Problem resizing BAR0 (%d).", r); > > + > > + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd); > > + > > + /* When the doorbell BAR isn't available we have no chance > of > > +* using the device. > > +*/ > > + BUG_ON(amdgpu_doorbell_init(adev)); > > > >>> From the PCI core perspective, it would be much cleaner to do the BAR > > >>>resize before the driver calls pci_enable_device(). If that could be > > >>>done, there would be no need for this sort of shutdown/reinit stuff > > >>>and we wouldn't have to worry about issues like these. The amdgpu > > >>>init path is pretty complicated, so I don't know whether this is > > >>>possible. > > >>I completely agree on this and it is actually the approach I tried first. > > >> > > >>There are just two problems with this approach: > > >>1. When the amdgpu driver is loaded there can already be the VGA > > >>console, Vesa or EFI driver active for the device and displaying the > > >>splash screen. > > >> > > >>When we resize and most likely relocate the BAR while those drivers > > >>are active it will certainly cause problems. > > >> > > >>What amdgpu does before trying to resize the BAR is kicking out > > >>other driver and making sure it has exclusive access to the > > >>hardware. > > >I don't understand the problem here yet. If you need to enable the > > >device, then disable it, resize, and re-enable it, that's fine. > > > > The issue is we never enable the device ourself in amdgpu, except > > for some rare cases during resume. > > > > In most of the cases we have to handle this is the primary display > > device which is enabled by either the BIOS, VGA console, VesaFB or > > EFIFB. Amdgpu just kicks out whatever driver was responsible for the > > device previously and takes over. > > > > I could of course do the disable/resize/reenable dance, but I would > > rather want to avoid that. > > > > The hardware is most likely already displaying a boot splash and we > > want to transit to the desktop without any flickering (at least > > that's the long term goal). Completely disabling the device to do > > this doesn't sounds like a good idea if we want that. > > > > >The important thing I'm looking for is that the resize happens before > > >a pci_enable_device(), because pci_enable_device() is the sync point > > >where the PCI core enables resources and makes them available to the > > >driver. Drivers know that they can't look at the resources before > > >that point. There's a little bit of text about this in [1]. > > > > Yeah, I understand that. But wouldn't it be sufficient to just > > disable memory decoding during the resize? > > > > I can easily guarantee that the CPU isn't accessing the BAR during > > the time (we need to do this for changing the memory clocks as > > well), but I have a bad gut fee
Re: [PATCH v2 00/11] Support for H3 Composite Output support
在 2017-06-05 00:01,Icenowy Zheng 写道: Allwinner H3 SoC features a TV Encoder like the one in Allwinner A13, which can only output TV Composite signal. The display pipeline of H3 is also special -- it has two mixers and two TCONs, of which the connection can be swapped. The TCONs do not have channel 0 (as they are all connected to internal bridges, TVE and HDMI TX). Add support for the display pipeline and the TVE in H3, in order to make it possible to display something with mainline kernel with H3. The image quality of TVE is bad, so HDMI is a better output -- this patchset also prepared the mixers and TCONs for HDMI output, and the HDMI controller driver is already done by Jernej Skrabec. So if possible, please apply PATCH 1~5 and 8,9 as soon as possible, so that Jernej can submit his HDMI patches. Currently the jack detection feature of the TVE is still not so clear -- so it's not implemented in this version. Thus the TV output shouldn't be defaultly enabled now. Icenowy Zheng (11): dt-bindings: update the binding for Allwinner H3 TVE support drm: sun4i: add support for H3 mixers drm: sun4i: ignore swapped mixer<->tcon connection for DE2 drm: sun4i: add support for H3's TCON0/1 drm: sun4i: add compatible for H3 display engine drm: sun4i: add color space correction support for DE2 mixer drm: sun4i: add support for the TV encoder in H3 SoC clk: sunxi-ng: allow CLK_DE to set CLK_PLL_DE for H3 clk: sunxi-ng: export CLK_PLL_DE for H3 ARM: sun8i: h3: add display engine pipeline for TVE [DO NOT MERGE] ARM: sun8i: h3: enable TV output on Orange Pi PC Maxime, could you pick some patches that you think appliable in this series? (especially PATCH 1, the binding patch) I think they can be useful. Thanks! .../bindings/display/sunxi/sun4i-drm.txt | 37 +++- arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 12 ++ arch/arm/boot/dts/sun8i-h3.dtsi| 186 + drivers/clk/sunxi-ng/ccu-sun8i-h3.c| 2 +- drivers/clk/sunxi-ng/ccu-sun8i-h3.h| 3 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 46 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 113 ++--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 3 + drivers/gpu/drm/sun4i/sun4i_tv.c | 35 +++- drivers/gpu/drm/sun4i/sun8i_mixer.c| 53 ++ drivers/gpu/drm/sun4i/sun8i_mixer.h| 6 +- include/dt-bindings/clock/sun8i-h3-ccu.h | 2 + 12 files changed, 463 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf > Of Jeff Kirsher > Sent: Tuesday, June 6, 2017 1:46 PM > To: David Miller ; Nikula, Jani > > Cc: Ursulin, Tvrtko ; daniel.vet...@ffwll.ch; intel- > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; > jani.nik...@linux.intel.com; ch...@chris-wilson.co.uk; Ertman, David M > ; intel-wired-...@lists.osuosl.org; dri- > de...@lists.freedesktop.org; net...@vger.kernel.org; airl...@gmail.com > Subject: Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo > e1000e_pm_freeze if __e1000_shutdown fails > > On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote: > > From: Jani Nikula > > Date: Wed, 31 May 2017 18:50:43 +0300 > > > > > From: Chris Wilson > > > > > > An error during suspend (e100e_pm_suspend), > > > > ... > > > lead to complete failure: > > > > ... > > > The unwind failures stems from commit 2800209994f8 ("e1000e: > > > Refactor PM > > > flows"), but it may be a later patch that introduced the non- > > > recoverable > > > behaviour. > > > > > > Fixes: 2800209994f8 ("e1000e: Refactor PM flows") > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847 > > > Cc: Tvrtko Ursulin > > > Cc: Jeff Kirsher > > > Cc: Dave Ertman > > > Cc: Bruce Allan > > > Cc: intel-wired-...@lists.osuosl.org > > > Cc: net...@vger.kernel.org > > > Signed-off-by: Chris Wilson > > > [Jani: bikeshed repainted] > > > Signed-off-by: Jani Nikula > > > > Jeff, please make sure this gets submitted to me soon. > > Expect it later tonight, just finishing up testing. Tested-by: Aaron Brown ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] mediatek drm fixes for 4.12
Hi, Dave: This include two fixes: dsi wait timeout loop and hdmi infoframe mistake. Regards, CK The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git mediatek-drm-fixes-4.12-rc1 for you to fetch changes up to 014580ffab654bb83256783a2b185cf6c06dffaa: drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake (2017-05-22 13:49:17 +0800) Dan Carpenter (1): drm/mediatek: fix a timeout loop YYS (1): drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake drivers/gpu/drm/mediatek/mtk_dsi.c | 15 ++- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- 2 files changed, 7 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #2 from Luke --- Created attachment 131760 --> https://bugs.freedesktop.org/attachment.cgi?id=131760&action=edit dmesg from crash using amdgpu module -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #1 from Luke --- Created attachment 131759 --> https://bugs.freedesktop.org/attachment.cgi?id=131759&action=edit dmesg from crash using radeon module -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 Bug ID: 101325 Summary: UE4Editor crash after pressing "play" with radeon southern island card (7850 HD) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: dodgyville+freedesk...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 131758 --> https://bugs.freedesktop.org/attachment.cgi?id=131758&action=edit ~/ddebug_dumps/ file with environment variables R600_DEBUG=check_vm GALLIUM_DDEBUG="pipelined 1" Hi, thanks for your great work on bringing hardware accelerated graphics to linux. I have a recurring problem with one 3D program (UE4editor) crashing my computer during a particular operation (pressing "play" on any project including blank). I believe the problem is at the mesa layer. Brief details: Radeon 7850HD It crashes using radeon and amdgpu (on ubuntu 17.04, linux 4.11, padoka ppa). It does not crash using the fglrx driver (on ubuntu 14.04). The entire machine hangs and requires a reset. Following a suggestion from Michael I set the following environment variables for running ue4editor: R600_DEBUG=check_vm GALLIUM_DDEBUG="pipelined 1" Now the program dumps without taking out the whole system. It created a file in ~/ddebug_dumps/ with more information about the GPU hang (attached). I have also attached the two dmesg logs for two separate trials involving the radeon and amdgpu modules. I blacklisted them both in grub2 and rebooted. I first manually loaded amdgpu and then after triggering the crash in ue4editor, rebooted and tried again with the manually loaded radeon module. The radeon one seems to give more information and the screen flashed a few times before freezing. When running amdgpu the x session just hangs and does nothing. I made sure I was running the latest (git 17-06-05) padoka builds. I was able to ssh into the machine for a while after the x session had completely frozen (including frozen mouse) until it also disconnected after a few minutes. This is the part of dmesg running radeon where it appears to go off the rails: radeon :07:00.0: ring 4 stalled for more than 10024msec [ +0.04] radeon :07:00.0: GPU lockup (current fence id 0x0fd0 last fence id 0x0fd2 on ring 4) [ +0.485614] radeon :07:00.0: Saved 724 dwords of commands on ring 0. [ +0.000126] radeon :07:00.0: GPU softreset: 0x004D [ +0.01] radeon :07:00.0: GRBM_STATUS = 0xA0403028 [ +0.01] radeon :07:00.0: GRBM_STATUS_SE0 = 0x0806 [ +0.01] radeon :07:00.0: GRBM_STATUS_SE1 = 0x0806 [ +0.01] radeon :07:00.0: SRBM_STATUS = 0x20C0 [ +0.000118] radeon :07:00.0: SRBM_STATUS2 = 0x [ +0.02] radeon :07:00.0: R_008674_CP_STALLED_STAT1 = 0x [ +0.01] radeon :07:00.0: R_008678_CP_STALLED_STAT2 = 0x00018000 [ +0.01] radeon :07:00.0: R_00867C_CP_BUSY_STAT = 0x0046 [ +0.01] radeon :07:00.0: R_008680_CP_STAT = 0x84038647 [ +0.01] radeon :07:00.0: R_00D034_DMA_STATUS_REG = 0x44C83106 [ +0.01] radeon :07:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [ +0.02] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ +0.01] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ +0.465637] radeon :07:00.0: GRBM_SOFT_RESET=0xDDFF [ +0.52] radeon :07:00.0: SRBM_SOFT_RESET=0x00100100 [ +0.001146] radeon :07:00.0: GRBM_STATUS = 0x3028 [ +0.02] radeon :07:00.0: GRBM_STATUS_SE0 = 0x0006 [ +0.01] radeon :07:00.0: GRBM_STATUS_SE1 = 0x0006 [ +0.00] radeon :07:00.0: SRBM_STATUS = 0x20C0 [ +0.000111] radeon :07:00.0: SRBM_STATUS2 = 0x [ +0.01] radeon :07:00.0: R_008674_CP_STALLED_STAT1 = 0x [ +0.01] radeon :07:00.0: R_008678_CP_STALLED_STAT2 = 0x [ +0.01] radeon :07:00.0: R_00867C_CP_BUSY_STAT = 0x [ +0.01] radeon :07:00.0: R_008680_CP_STAT = 0x [ +0.01] radeon :07:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ +0.01] radeon :07:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [ +0.000247] radeon :07:00.0: GPU reset succeeded, trying to resume [ +0.025448] [drm] probing gen 2 caps for device 8086:151 = 261a103/e [ +0.03] [drm] PCIE gen 3 link speeds already enabled [ +0.002586] [drm] PCIE GART of 2048M enabled (table at 0x001D6000). [ +0.000120] radeon :07:00.0: WB enabled [
[PATCH -next] drm: pl111: select DRM_PANEL
From: Randy Dunlap The drm pl111 driver uses drm_panel interfaces so it should select DRM_PANEL to fix build errors. drivers/built-in.o: In function `pl111_connector_destroy': pl111_connector.c:(.text+0xc7285): undefined reference to `drm_panel_detach' Signed-off-by: Randy Dunlap --- drivers/gpu/drm/pl111/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20170606.orig/drivers/gpu/drm/pl111/Kconfig +++ linux-next-20170606/drivers/gpu/drm/pl111/Kconfig @@ -3,6 +3,7 @@ config DRM_PL111 depends on DRM depends on ARM || ARM64 || COMPILE_TEST depends on COMMON_CLK + select DRM_PANEL select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote: > From: Jani Nikula > Date: Wed, 31 May 2017 18:50:43 +0300 > > > From: Chris Wilson > > > > An error during suspend (e100e_pm_suspend), > > ... > > lead to complete failure: > > ... > > The unwind failures stems from commit 2800209994f8 ("e1000e: > > Refactor PM > > flows"), but it may be a later patch that introduced the non- > > recoverable > > behaviour. > > > > Fixes: 2800209994f8 ("e1000e: Refactor PM flows") > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847 > > Cc: Tvrtko Ursulin > > Cc: Jeff Kirsher > > Cc: Dave Ertman > > Cc: Bruce Allan > > Cc: intel-wired-...@lists.osuosl.org > > Cc: net...@vger.kernel.org > > Signed-off-by: Chris Wilson > > [Jani: bikeshed repainted] > > Signed-off-by: Jani Nikula > > Jeff, please make sure this gets submitted to me soon. Expect it later tonight, just finishing up testing. signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Jun 06, 2017 at 01:51:11PM +0200, Christian König wrote: > Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas: > >On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote: > >>Hi Bjorn, > >> > >>sorry for not responding earlier and thanks for picking this thread > >>up again. > >> > >>Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas: > >>>[+cc ADMGPU, DRM folks] > >>> > >>>On Tue, May 09, 2017 at 06:49:07PM +0200, Christian König wrote: > [SNIP] > +/** > + * amdgpu_resize_bar0 - try to resize BAR0 > + * > + * @adev: amdgpu_device pointer > + * > + * Try to resize BAR0 to make all VRAM CPU accessible. > + */ > +void amdgpu_resize_bar0(struct amdgpu_device *adev) > +{ > + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size); > + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1; > + u16 cmd; > + int r; > + > + /* Free the doorbell mapping, it most likely needs to move as well */ > + amdgpu_doorbell_fini(adev); > + pci_release_resource(adev->pdev, 2); > + > + /* Disable memory decoding while we change the BAR addresses and size */ > + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd); > + pci_write_config_word(adev->pdev, PCI_COMMAND, > + cmd & ~PCI_COMMAND_MEMORY); > + > + r = pci_resize_resource(adev->pdev, 0, rbar_size); > + if (r == -ENOSPC) > + DRM_INFO("Not enough PCI address space for a large BAR."); > + else if (r && r != -ENOTSUPP) > + DRM_ERROR("Problem resizing BAR0 (%d).", r); > + > + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd); > + > + /* When the doorbell BAR isn't available we have no chance of > + * using the device. > + */ > + BUG_ON(amdgpu_doorbell_init(adev)); > >>> From the PCI core perspective, it would be much cleaner to do the BAR > >>>resize before the driver calls pci_enable_device(). If that could be > >>>done, there would be no need for this sort of shutdown/reinit stuff > >>>and we wouldn't have to worry about issues like these. The amdgpu > >>>init path is pretty complicated, so I don't know whether this is > >>>possible. > >>I completely agree on this and it is actually the approach I tried first. > >> > >>There are just two problems with this approach: > >>1. When the amdgpu driver is loaded there can already be the VGA > >>console, Vesa or EFI driver active for the device and displaying the > >>splash screen. > >> > >>When we resize and most likely relocate the BAR while those drivers > >>are active it will certainly cause problems. > >> > >>What amdgpu does before trying to resize the BAR is kicking out > >>other driver and making sure it has exclusive access to the > >>hardware. > >I don't understand the problem here yet. If you need to enable the > >device, then disable it, resize, and re-enable it, that's fine. > > The issue is we never enable the device ourself in amdgpu, except > for some rare cases during resume. > > In most of the cases we have to handle this is the primary display > device which is enabled by either the BIOS, VGA console, VesaFB or > EFIFB. Amdgpu just kicks out whatever driver was responsible for the > device previously and takes over. > > I could of course do the disable/resize/reenable dance, but I would > rather want to avoid that. > > The hardware is most likely already displaying a boot splash and we > want to transit to the desktop without any flickering (at least > that's the long term goal). Completely disabling the device to do > this doesn't sounds like a good idea if we want that. > > >The important thing I'm looking for is that the resize happens before > >a pci_enable_device(), because pci_enable_device() is the sync point > >where the PCI core enables resources and makes them available to the > >driver. Drivers know that they can't look at the resources before > >that point. There's a little bit of text about this in [1]. > > Yeah, I understand that. But wouldn't it be sufficient to just > disable memory decoding during the resize? > > I can easily guarantee that the CPU isn't accessing the BAR during > the time (we need to do this for changing the memory clocks as > well), but I have a bad gut feeling completely turning of the device > while we are still displaying stuff. pci_disable_device() doesn't turn off the device; it only disables bus mastering (and some of the arch-specific pcibios_disable_device() implementations do a little more). But it's certainly the wrong direction -- it disables DMA, which has nothing to do with the BAR decoding we're interested in. What if the driver did something like this: pci_disable_decoding(dev, IORESOURCE_MEM); pci_release_resource(dev, 2); pci_resize_bar(dev, bar, size); pci_assign_resources(dev); pci_enable_decoding(dev, IORESOURCE_MEM); That would require adding pci_enable/disable_decoding() to the driver API, along with the requirement that the driver
XDC 2017 : Call for paper
Hello, I have the pleasure to announce that the X.org Developer Conference 2017 will be held in Mountain View, California from September 20th to September 22nd. The venue is located at the Googleplex. The official page for the event is http://www.x.org/wiki/Events/XDC2017 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2017/ As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Given that the conference is located at Google, we would welcome topics related to Android and Chromebooks. We would also like to hear about Virtual Reality and end-to-end buffer format negociation. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and open to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering, so if you are attending please add your name as early as possible. I am looking forward to seeing you there. If you have any inquiries/questions, please send them to Stéphane Marchesin (please also CC: board at foundation.x.org). Martin Peres ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/vc4: Use drm_atomic_helper_wait_for_flip_done()
On Tue, 06 Jun 2017 13:24:33 -0700 Eric Anholt wrote: > Boris Brezillon writes: > > > Replace the drm_atomic_helper_wait_for_vblanks() with a call to > > drm_atomic_helper_wait_for_flip_done(). This allows better detection of > > page flip done events which what we are really waiting for in > > vc4_atomic_complete_commit(). > > > > With this approach, we also addresse the 'missed single vblank event' > > problem that can arise when the CRTC is configured in oneshot mode > > (only a single frame is generated and the CRTC is immediately paused > > after this frame). Note that this oneshot mode will be used for the > > writeback connector feature. > > Should we just use drm_atomic_helper_commit_tail() and make this change > in the core helper, instead? Hm, not sure changing the default behavior is such a good idea. I don't want to break other drivers. > > Actually, I'm confused. drm_atomic_helper_commit_cleanup_done() seems > to be waiting for the flip_done on the crtc, already. What's the > difference? Actually, drm_atomic_helper_wait_for_flip_done() is called just before drm_atomic_helper_cleanup_planes() which in turn is called before drm_atomic_helper_commit_cleanup_done(). My understanding was that it was unsafe to call plane->cleanup_fb() on FBs that are still in use, and the only thing guaranteeing that FBs are not used anymore is the flip_done event. Maybe I'm wrong, and FB refcounting is enough to make sure resources are preserved until page flip is actually done. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/vc4: Mimic drm_atomic_helper_commit() behavior
On Tue, 06 Jun 2017 13:27:09 -0700 Eric Anholt wrote: > Boris Brezillon writes: > > > The VC4 KMS driver is implementing its own ->atomic_commit() but there > > are a few generic helpers we can use instead of open-coding the logic. > > > > Signed-off-by: Boris Brezillon > > --- > > drivers/gpu/drm/vc4/vc4_kms.c | 38 -- > > 1 file changed, 12 insertions(+), 26 deletions(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c > > index ad7925a9e0ea..f229abc0991b 100644 > > --- a/drivers/gpu/drm/vc4/vc4_kms.c > > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > > @@ -42,6 +42,10 @@ vc4_atomic_complete_commit(struct vc4_commit *c) > > struct drm_device *dev = state->dev; > > struct vc4_dev *vc4 = to_vc4_dev(dev); > > > > + drm_atomic_helper_wait_for_fences(dev, state, false); > > + > > + drm_atomic_helper_wait_for_dependencies(state); > > With this wait_for_fences() addition and the reservation stuff that > landed, I think we can rip out the "seqno cb" in vc4, and just use > drm_atomic_helper_commit() and drm_atomic_hepler_commit_tail(). Do you > see anything missing, with that? I can't tell. I haven't dig enough to understand what this seqno cb was used for :-), but Daniel was suggesting the same thing. I'll try to better understand what seqno cb does and if it's all safe to get rid of it and use the standard helpers. > > > + > > drm_atomic_helper_commit_modeset_disables(dev, state); > > > > drm_atomic_helper_commit_planes(dev, state, 0); > > @@ -57,10 +61,14 @@ vc4_atomic_complete_commit(struct vc4_commit *c) > > */ > > state->legacy_cursor_update = false; > > > > + drm_atomic_helper_commit_hw_done(state); > > + > > drm_atomic_helper_wait_for_vblanks(dev, state); > > > > drm_atomic_helper_cleanup_planes(dev, state); > > > > + drm_atomic_helper_commit_cleanup_done(state); > > + > > drm_atomic_state_put(state); > > > > up(&vc4->async_modeset); > > @@ -117,32 +125,10 @@ static int vc4_atomic_commit(struct drm_device *dev, > > if (!c) > > return -ENOMEM; > > > > - /* Make sure that any outstanding modesets have finished. */ > > - if (nonblock) { > > - struct drm_crtc *crtc; > > - struct drm_crtc_state *crtc_state; > > - unsigned long flags; > > - bool busy = false; > > - > > - /* > > -* If there's an undispatched event to send then we're > > -* obviously still busy. If there isn't, then we can > > -* unconditionally wait for the semaphore because it > > -* shouldn't be contended (for long). > > -* > > -* This is to prevent a race where queuing a new flip > > -* from userspace immediately on receipt of an event > > -* beats our clean-up and returns EBUSY. > > -*/ > > - spin_lock_irqsave(&dev->event_lock, flags); > > - for_each_crtc_in_state(state, crtc, crtc_state, i) > > - busy |= vc4_event_pending(crtc); > > - spin_unlock_irqrestore(&dev->event_lock, flags); > > - if (busy) { > > - kfree(c); > > - return -EBUSY; > > - } > > - } > > + ret = drm_atomic_helper_setup_commit(state, nonblock); > > + if (ret) > > + return ret; > > + > > Looks like vc4_event_pending() should be garbage-collected with this > commit. Indeed. Thanks for the review. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] dt-bindings: Document the VC4 TXP module nodes.
Boris Brezillon writes: > These are part of the vc4 display pipeline. > > Signed-off-by: Boris Brezillon Patch 6-7 are: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/vc4: Mimic drm_atomic_helper_commit() behavior
Boris Brezillon writes: > The VC4 KMS driver is implementing its own ->atomic_commit() but there > are a few generic helpers we can use instead of open-coding the logic. > > Signed-off-by: Boris Brezillon > --- > drivers/gpu/drm/vc4/vc4_kms.c | 38 -- > 1 file changed, 12 insertions(+), 26 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c > index ad7925a9e0ea..f229abc0991b 100644 > --- a/drivers/gpu/drm/vc4/vc4_kms.c > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > @@ -42,6 +42,10 @@ vc4_atomic_complete_commit(struct vc4_commit *c) > struct drm_device *dev = state->dev; > struct vc4_dev *vc4 = to_vc4_dev(dev); > > + drm_atomic_helper_wait_for_fences(dev, state, false); > + > + drm_atomic_helper_wait_for_dependencies(state); With this wait_for_fences() addition and the reservation stuff that landed, I think we can rip out the "seqno cb" in vc4, and just use drm_atomic_helper_commit() and drm_atomic_hepler_commit_tail(). Do you see anything missing, with that? > + > drm_atomic_helper_commit_modeset_disables(dev, state); > > drm_atomic_helper_commit_planes(dev, state, 0); > @@ -57,10 +61,14 @@ vc4_atomic_complete_commit(struct vc4_commit *c) >*/ > state->legacy_cursor_update = false; > > + drm_atomic_helper_commit_hw_done(state); > + > drm_atomic_helper_wait_for_vblanks(dev, state); > > drm_atomic_helper_cleanup_planes(dev, state); > > + drm_atomic_helper_commit_cleanup_done(state); > + > drm_atomic_state_put(state); > > up(&vc4->async_modeset); > @@ -117,32 +125,10 @@ static int vc4_atomic_commit(struct drm_device *dev, > if (!c) > return -ENOMEM; > > - /* Make sure that any outstanding modesets have finished. */ > - if (nonblock) { > - struct drm_crtc *crtc; > - struct drm_crtc_state *crtc_state; > - unsigned long flags; > - bool busy = false; > - > - /* > - * If there's an undispatched event to send then we're > - * obviously still busy. If there isn't, then we can > - * unconditionally wait for the semaphore because it > - * shouldn't be contended (for long). > - * > - * This is to prevent a race where queuing a new flip > - * from userspace immediately on receipt of an event > - * beats our clean-up and returns EBUSY. > - */ > - spin_lock_irqsave(&dev->event_lock, flags); > - for_each_crtc_in_state(state, crtc, crtc_state, i) > - busy |= vc4_event_pending(crtc); > - spin_unlock_irqrestore(&dev->event_lock, flags); > - if (busy) { > - kfree(c); > - return -EBUSY; > - } > - } > + ret = drm_atomic_helper_setup_commit(state, nonblock); > + if (ret) > + return ret; > + Looks like vc4_event_pending() should be garbage-collected with this commit. > ret = down_interruptible(&vc4->async_modeset); > if (ret) { > kfree(c); > -- > 2.7.4 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/vc4: Use drm_atomic_helper_wait_for_flip_done()
Boris Brezillon writes: > Replace the drm_atomic_helper_wait_for_vblanks() with a call to > drm_atomic_helper_wait_for_flip_done(). This allows better detection of > page flip done events which what we are really waiting for in > vc4_atomic_complete_commit(). > > With this approach, we also addresse the 'missed single vblank event' > problem that can arise when the CRTC is configured in oneshot mode > (only a single frame is generated and the CRTC is immediately paused > after this frame). Note that this oneshot mode will be used for the > writeback connector feature. Should we just use drm_atomic_helper_commit_tail() and make this change in the core helper, instead? Actually, I'm confused. drm_atomic_helper_commit_cleanup_done() seems to be waiting for the flip_done on the crtc, already. What's the difference? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/19] drm/sun4i: hdmi: Add support for A31's HDMI controller
On Sat, Jun 03, 2017 at 11:19:09PM +0800, Chen-Yu Tsai wrote: > On Sat, Jun 3, 2017 at 3:41 AM, Maxime Ripard > wrote: > > On Fri, Jun 02, 2017 at 06:10:19PM +0800, Chen-Yu Tsai wrote: > >> The HDMI controller found in the A31 SoCs is slightly different > >> from the one already supported, which is found in the A10s: > >> > >> - Need different initial values for the PLL related registers > >> > >> - Different behavior of the DDC and TMDS clocks > >> > >> - Different register layout for the DDC portion > >> > >> - Separate DDC parent clock > >> > >> This patch adds support for it. > >> > >> Signed-off-by: Chen-Yu Tsai > >> --- > >> drivers/gpu/drm/sun4i/sun4i_hdmi.h | 3 + > >> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 141 > >> + > >> 2 files changed, 144 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h > >> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h > >> index c63d0bd95963..2589bc92be59 100644 > >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h > >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h > >> @@ -56,10 +56,13 @@ > >> #define SUN4I_HDMI_PAD_CTRL0_TXENBIT(23) > >> > >> #define SUN4I_HDMI_PAD_CTRL1_REG 0x204 > >> +#define SUN4I_HDMI_PAD_CTRL1_UNKNOWN BIT(24) /* set on A31 */ > >> #define SUN4I_HDMI_PAD_CTRL1_AMP_OPT BIT(23) > >> #define SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT BIT(22) > >> #define SUN4I_HDMI_PAD_CTRL1_EMP_OPT BIT(20) > >> #define SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT BIT(19) > >> +#define SUN4I_HDMI_PAD_CTRL1_PWSCK BIT(18) > >> +#define SUN4I_HDMI_PAD_CTRL1_PWSDT BIT(17) > >> #define SUN4I_HDMI_PAD_CTRL1_REG_DEN BIT(15) > >> #define SUN4I_HDMI_PAD_CTRL1_REG_DENCK BIT(14) > >> #define SUN4I_HDMI_PAD_CTRL1_REG_EMP(n) (((n) & 7) << 10) > >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > >> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > >> index 9ded40aaed32..e9abf93eb41c 100644 > >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > >> @@ -293,6 +293,109 @@ static const struct drm_connector_helper_funcs > >> sun4i_hdmi_connector_helper_funcs > >> .get_modes = sun4i_hdmi_get_modes, > >> }; > >> > >> +static int sun6i_hdmi_read_sub_block(struct sun4i_hdmi *hdmi, > >> + unsigned int blk, unsigned int offset, > >> + u8 *buf, unsigned int count) > >> +{ > >> + unsigned long reg; > >> + int i; > >> + > >> + reg = readl(hdmi->base + SUN6I_HDMI_DDC_FIFO_CTRL_REG); > >> + writel(reg | SUN6I_HDMI_DDC_FIFO_CTRL_CLEAR, > >> +hdmi->base + SUN6I_HDMI_DDC_FIFO_CTRL_REG); > >> + writel(SUN6I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) | > >> +SUN6I_HDMI_DDC_ADDR_EDDC(DDC_SEGMENT_ADDR << 1) | > >> +SUN6I_HDMI_DDC_ADDR_OFFSET(offset) | > >> +SUN6I_HDMI_DDC_ADDR_SLAVE(DDC_ADDR), > >> +hdmi->base + SUN6I_HDMI_DDC_ADDR_REG); > >> + > >> + writel(SUN6I_HDMI_DDC_CMD_EXPLICIT_EDDC_READ | > >> +SUN6I_HDMI_DDC_CMD_BYTE_COUNT(count), > >> +hdmi->base + SUN6I_HDMI_DDC_CMD_REG); > >> + > >> + reg = readl(hdmi->base + SUN6I_HDMI_DDC_CTRL_REG); > >> + writel(reg | SUN6I_HDMI_DDC_CTRL_START_CMD, > >> +hdmi->base + SUN6I_HDMI_DDC_CTRL_REG); > >> + > >> + if (readl_poll_timeout(hdmi->base + SUN6I_HDMI_DDC_CTRL_REG, reg, > >> +!(reg & SUN6I_HDMI_DDC_CTRL_START_CMD), > >> +100, 10)) > >> + return -EIO; > >> + > >> + for (i = 0; i < count; i++) > >> + buf[i] = readb(hdmi->base + SUN6I_HDMI_DDC_FIFO_DATA_REG); > >> + > >> + return 0; > >> +} > >> + > >> +static int sun6i_hdmi_read_edid_block(void *data, u8 *buf, unsigned int > >> blk, > >> + size_t length) > >> +{ > >> + struct sun4i_hdmi *hdmi = data; > >> + int retry = 2, i; > >> + > >> + do { > >> + for (i = 0; i < length; i += SUN4I_HDMI_DDC_FIFO_SIZE) { > >> + unsigned char offset = blk * EDID_LENGTH + i; > >> + unsigned int count = min((unsigned > >> int)SUN4I_HDMI_DDC_FIFO_SIZE, > >> + length - i); > >> + int ret; > >> + > >> + ret = sun6i_hdmi_read_sub_block(hdmi, blk, offset, > >> + buf + i, count); > >> + if (ret) > >> + return ret; > >> + } > >> + } while (!drm_edid_block_valid(buf, blk, true, NULL) && (retry--)); > >> + > >> + return 0; > >> +} > >> + > >> +static int sun6i_hdmi_get_modes(struct drm_connector *connector) > >> +{ > >> + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector); > >> + u32 reg; > >> + struct edid *edid; > >>
Re: [PATCH 5/7] drm/vc4: Add support for the TXP (transposer) block
Hi Brian, Le Mon, 5 Jun 2017 12:25:50 +0100, Brian Starkey a écrit : > Hi Boris, > > I can't speak for the HW-specific details, but the writeback part > looks pretty good (and familiar ;-) to me. There certainly seems to be > some scope for code-sharing there, but I think it's fine not to do it > yet. Agreed. > > I've a further query below about the handling of CRTC events. > [...] > >+ > >+void vc4_txp_atomic_commit(struct drm_device *dev, > >+ struct drm_atomic_state *old_state) > >+{ > >+struct vc4_dev *vc4 = to_vc4_dev(dev); > >+struct vc4_txp *txp = vc4->txp; > >+struct drm_connector_state *conn_state = txp->connector.base.state; > >+struct drm_display_mode *mode; > >+struct drm_gem_cma_object *gem; > >+struct drm_framebuffer *fb; > >+u32 ctrl = TXP_GO | TXP_EI; > >+ > >+/* Writeback connector is disabled, nothing to do. */ > >+if (!conn_state->crtc) > >+return; > >+ > >+/* Writeback connector is enabled, but has no FB assigned to it. Fake a > >+ * vblank event to complete ->flip_done. > >+ */ > >+if (!conn_state->writeback_job || !conn_state->writeback_job->fb) { > >+vc4_crtc_eof_event(conn_state->crtc); > > I'm not sure about hiding away the one-shot thing like this. If the > CRTC remains "active" from the API point of view, I'd expect it to be > able to keep generating VBLANK events. > > I don't know how to do if, but if there were some notion of > "auto-disabling" CRTCs then this quirk would go away, and you'd also > be able to enforce that the CRTC can't be enabled without a writeback > framebuffer. I don't have a strong opinion on "auto-disabling CRTC" vs "fake VBLANK events". Note that I'm already faking a VBLANK event when activating writeback, because there's no such concept at the HVS/TXP level. We do have EOF (End Of Frame) and writeback done events, but these are quite independent from the VBLANK events generated by the pixelvalve block (the block responsible for generating the HSYNC/VSYNC signals). > > I'm also not sure how (if?) this works today with a CRTC driving a DSI > command-mode panel. Does the CRTC keep generating VBLANKs even when > there are no updates? I don't know. Is this mandatory to have VBLANK events? I mean, the core is using VBLANK events to detect when page flips have been done, that is, when old framebuffers are unused and new ones started to be fetched by the CRTC, but on some HW, VBLANK is not the only way to detect such situations. The question is, are there other situations where VBLANK events are required, or is there an implicit rule stating that a CRTC has to generate VBLANK events at a vrefresh rate even when the display is actually not updated when nothing changes? > > >+return; > >+} > >+ > >+fb = conn_state->writeback_job->fb; > >+ > >+switch (fb->format->format) { > >+case DRM_FORMAT_ARGB: > >+ctrl |= TXP_ALPHA_ENABLE; > >+case DRM_FORMAT_XRGB: > >+ctrl |= VC4_SET_FIELD(TXP_FORMAT_ARGB, TXP_FORMAT) | > >+VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE); > >+break; > >+ > >+case DRM_FORMAT_ABGR: > >+ctrl |= TXP_ALPHA_ENABLE; > >+case DRM_FORMAT_XBGR: > >+ctrl |= VC4_SET_FIELD(TXP_FORMAT_ABGR, TXP_FORMAT) | > >+VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE); > >+break; > >+ > >+case DRM_FORMAT_RGBA: > >+ctrl |= TXP_ALPHA_ENABLE; > >+case DRM_FORMAT_RGBX: > >+ctrl |= VC4_SET_FIELD(TXP_FORMAT_RGBA, TXP_FORMAT) | > >+VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE); > >+break; > >+ > >+case DRM_FORMAT_BGRA: > >+ctrl |= TXP_ALPHA_ENABLE; > >+case DRM_FORMAT_BGRX: > >+ctrl |= VC4_SET_FIELD(TXP_FORMAT_BGRA, TXP_FORMAT) | > >+VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE); > >+break; > >+ > >+case DRM_FORMAT_BGR888: > >+ctrl |= VC4_SET_FIELD(TXP_FORMAT_BGR888, TXP_FORMAT) | > >+VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE); > >+break; > >+ > >+case DRM_FORMAT_RGB888: > >+ctrl |= VC4_SET_FIELD(TXP_FORMAT_RGB888, TXP_FORMAT) | > >+VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE); > >+break; > >+default: > >+WARN_ON(1); > >+return; > >+} > >+ > >+if (!(ctrl & TXP_ALPHA_ENABLE)) > >+ctrl |= TXP_ALPHA_INVERT; > >+ > >+mode = &conn_state->crtc->state->adjusted_mode; > >+gem = drm_fb_cma_get_gem_obj(fb, 0); > >+TXP_WRITE(TXP_DST_PTR, gem->paddr + fb->offsets[0]); > >+TXP_WRITE(TXP_DST_PITCH, fb->pitches[0]); > >+TXP_WRITE(TXP_DIM, > >+ VC4_SET_FIELD(mode->hdisplay, TXP_WIDTH) | > >+ VC4_SET_FIELD(mode->vdisplay, TXP_HEIGHT)); > >+ > >+TXP_WRITE(TXP_DST_CTRL, ctrl); > >+ > >+drm_writeback_queue_job(&txp->connec
[Bug 101319] Tonga DC + UVD [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer
https://bugs.freedesktop.org/show_bug.cgi?id=101319 Bug ID: 101319 Summary: Tonga DC + UVD [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: adf.li...@gmail.com R9285 Tonga it seems that on various agd5f DC kernels using mpv -fs --hwdec=vdpau screen is 1920x1080 DVI-D will sometimes produces logging with a few [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer grepping kernel log shows this is not new + only seems to happen with a DC kernel (I spend more time in non DC kernels and have no instances with those). First record April 3rd, but then it doesn't always happen and I don't always run that test so it could have started earlier. With just a few of the errors no bad effects noticed. Today, with current agd5f amd-staging-4.11 I got a display lock with logging below, I can't reproduce the lock, but can get a few of the messages to show. Jun 6 17:48:16 ph4 kernel: [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer Jun 6 17:48:47 ph4 last message repeated 6136 times Jun 6 17:49:33 ph4 last message repeated 9208 times Jun 6 17:49:33 ph4 kernel: sysrq: SysRq : Emergency Sync Jun 6 17:49:33 ph4 kernel: Emergency Sync complete Jun 6 17:49:33 ph4 kernel: [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer Jun 6 17:49:34 ph4 last message repeated 306 times Jun 6 17:49:34 ph4 kernel: sysrq: SysRq : Emergency Remount R/O Jun 6 17:49:34 ph4 kernel: [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper
Maarten Lankhorst writes: > This fixes the following depmod error when building drm as a module: > depmod: ERROR: Found 6 modules in dependency cycles! > depmod: ERROR: Cycle detected: drm -> drm_kms_helper -> drm > > Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the > lvds-encoder bridge.") > Signed-off-by: Maarten Lankhorst Looks plausible to me. Given how much trouble I've had getting the kbuild right, anyone else want to chime in? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atmel-hlcdc: Fix panel registration
Boris Brezillon writes: > Attach the panel-bridge created by drm_panel_bridge_add() to the > parallel RGB encoder. > > Fixes: 96160a8071b2 ("drm/atmel-hlcdc: Replace the panel usage with > drm_panel_bridge.") > Signed-off-by: Boris Brezillon Reviewed-by: Eric Anholt Sorry for the mistake. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101254] VDPAU videos take forever to start in different applications
https://bugs.freedesktop.org/show_bug.cgi?id=101254 --- Comment #7 from joeri.exelm...@gmail.com --- I used this guide (https://pkg-xorg.alioth.debian.org/howto/build-mesa.html) to build the mesa project with git version 84012262ea70435507d3b88ddbc0f621781ec275 (Mar 21 2017), and I can use VDPAU again in Kodi. The configure command that I used: ./configure --enable-vdpau --enable-va --with-gallium-drivers=r600 --with-dri-drivers=radeon --enable-llvm --enable-dri3 --with-llvm-prefix=/usr/lib/llvm-4.0 --enable-gles1 --enable-gles2 --enable-glx-tls The environment variables when running Kodi: export LIBGL_DRIVERS_PATH=lib export LD_LIBRARY_PATH=lib export VDPAU_DRIVER_PATH=lib (lib being in the mesa git project dir) So Kodi works, VLC already worked, but mpv is still broken. The movie starts playing (cause I can hear the audio), which is an improvement, but the player window is entirely blue + a lot of opengl errors in stdout. Maybe because old mesa + new mpv is a bad idea, or maybe I did something wrong building mesa. I'll continue to search for the specific commit that broke VDPAU in Kodi. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 --- Comment #17 from Thomas J. Moore --- Is this the place for AMD-related kernel bugs to die? Is that why I was told to open the bug here, rather than the Linux kernel bugzilla? Who knows? In any case, not one person who could actually address the problem has made a single comment in nearly a year. In fact, the sum total of comments I've read on other bugs have been "are you using the latest" and "try without power management". Whatever. I have solved this problem for myself in the only way I could: I bought a new machine. Whom do I send the bill to? Oh, right, you want me to pay *you* to look at bugs. I'm not sure what possessed me to by another AMD machine, but I did, and it has almost identical graphics (but unlike the HP Pavilion, it only suffers from the kernel panic with power management enabled, not this bug, and given the response I've gotten from this bug, I won't even bother opening a new one). I am tempted to close this bug, or mark it as a duplicate of #97605 (even though the opposite is true, so I went ahead and marked it as such). Instead I'll simply ignore it like everyone else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 Thomas J. Moore changed: What|Removed |Added CC||jamof...@gmail.com --- Comment #16 from Thomas J. Moore --- *** Bug 97605 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97605] AMDGPU Black Screen when Booting
https://bugs.freedesktop.org/show_bug.cgi?id=97605 Thomas J. Moore changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #10 from Thomas J. Moore --- *** This bug has been marked as a duplicate of bug 97055 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mali-dp: Check PM status when sharing interrupt lines
If an instance of Mali DP hardware shares the interrupt line with another hardware (usually another instance of the Mali DP) its interrupt handler can get called when the device is suspended. Check the PM status before making access to the hardware registers to avoid deadlocks. Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_hw.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index 28360b8542f7..17bca99e8ac8 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -766,12 +766,17 @@ static irqreturn_t malidp_de_irq(int irq, void *arg) u32 status, mask, dc_status; irqreturn_t ret = IRQ_NONE; - if (!drm->dev_private) - return IRQ_HANDLED; - hwdev = malidp->dev; de = &hwdev->map.de_irq_map; + /* +* if we are suspended it is likely that we were invoked because +* we share an interrupt line with some other driver, don't try +* to read the hardware registers +*/ + if (hwdev->pm_suspended) + return IRQ_NONE; + /* first handle the config valid IRQ */ dc_status = malidp_hw_read(hwdev, hwdev->map.dc_base + MALIDP_REG_STATUS); if (dc_status & hwdev->map.dc_irq_map.vsync_irq) { @@ -854,6 +859,14 @@ static irqreturn_t malidp_se_irq(int irq, void *arg) struct malidp_hw_device *hwdev = malidp->dev; u32 status, mask; + /* +* if we are suspended it is likely that we were invoked because +* we share an interrupt line with some other driver, don't try +* to read the hardware registers +*/ + if (hwdev->pm_suspended) + return IRQ_NONE; + status = malidp_hw_read(hwdev, hwdev->map.se_base + MALIDP_REG_STATUS); if (!(status & hwdev->map.se_irq_map.irq_mask)) return IRQ_NONE; -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/arm: hdlcd: Set the CRTC's port before binding the encoder.
The component-based encoder(s) used by HDLCD expect the CRTC port to be set before binding in order to find the right endpoint. Without this patch, the TDA19988 encoder driver prints a warning "Falling back to first CRTC". Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/hdlcd_drv.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c index 345c8357b273..d3da87fbd85a 100644 --- a/drivers/gpu/drm/arm/hdlcd_drv.c +++ b/drivers/gpu/drm/arm/hdlcd_drv.c @@ -297,6 +297,9 @@ static int hdlcd_drm_bind(struct device *dev) if (ret) goto err_free; + /* Set the CRTC's port so that the encoder component can find it */ + hdlcd->crtc.port = of_graph_get_port_by_id(dev->of_node, 0); + ret = component_bind_all(dev, drm); if (ret) { DRM_ERROR("Failed to bind all components\n"); @@ -340,11 +343,14 @@ static int hdlcd_drm_bind(struct device *dev) } err_fbdev: drm_kms_helper_poll_fini(drm); + drm_vblank_cleanup(drm); err_vblank: pm_runtime_disable(drm->dev); err_pm_active: component_unbind_all(dev, drm); err_unload: + of_node_put(hdlcd->crtc.port); + hdlcd->crtc.port = NULL; drm_irq_uninstall(drm); of_reserved_mem_device_release(drm->dev); err_free: @@ -367,6 +373,9 @@ static void hdlcd_drm_unbind(struct device *dev) } drm_kms_helper_poll_fini(drm); component_unbind_all(dev, drm); + of_node_put(hdlcd->crtc.port); + hdlcd->crtc.port = NULL; + drm_vblank_cleanup(drm); pm_runtime_get_sync(drm->dev); drm_irq_uninstall(drm); pm_runtime_put_sync(drm->dev); -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
On Fri, Jun 02, 2017 at 01:25:14PM -0700, Eric Anholt wrote: [...] > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index f6968d3b4b41..adf9ae0e0b7c 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -4,6 +4,14 @@ config DRM_BRIDGE > help > Bridge registration and lookup framework. > > +config DRM_PANEL_BRIDGE Nit: perhaps this would be better named DRM_BRIDGE_PANEL because it is part of DRM_BRIDGE (and in fact depends on it). DRM_PANEL_ prefix with the select on DRM_PANEL looks weird. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper
This fixes the following depmod error when building drm as a module: depmod: ERROR: Found 6 modules in dependency cycles! depmod: ERROR: Cycle detected: drm -> drm_kms_helper -> drm Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index dc69175255b1..3999dffcd9ef 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -24,7 +24,6 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o drm-$(CONFIG_PCI) += ati_pcigart.o drm-$(CONFIG_DRM_PANEL) += drm_panel.o -drm-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm-$(CONFIG_OF) += drm_of.o drm-$(CONFIG_AGP) += drm_agpsupport.o drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o @@ -35,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_simple_kms_helper.o drm_modeset_helper.o \ drm_scdc_helper.o +drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: Fix offset calculation for the primary plane.
On Fri, Jun 02, 2017 at 06:57:33PM -0700, Eric Anholt wrote: > If src_x/y were nonzero, we failed to shift them down by 16 to get the > pixel offset. The recent CMA helper function gets it right. > > Signed-off-by: Eric Anholt > Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111") > Reported-by: Mircea Carausu Reviewed-by: Sean Paul > --- > drivers/gpu/drm/pl111/pl111_display.c | 15 ++- > 1 file changed, 2 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/pl111/pl111_display.c > b/drivers/gpu/drm/pl111/pl111_display.c > index 3e0a4fa73ddb..c6ca4f1bbd49 100644 > --- a/drivers/gpu/drm/pl111/pl111_display.c > +++ b/drivers/gpu/drm/pl111/pl111_display.c > @@ -50,17 +50,6 @@ irqreturn_t pl111_irq(int irq, void *data) > return status; > } > > -static u32 pl111_get_fb_offset(struct drm_plane_state *pstate) > -{ > - struct drm_framebuffer *fb = pstate->fb; > - struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, 0); > - > - return (obj->paddr + > - fb->offsets[0] + > - fb->format->cpp[0] * pstate->src_x + > - fb->pitches[0] * pstate->src_y); > -} > - > static int pl111_display_check(struct drm_simple_display_pipe *pipe, > struct drm_plane_state *pstate, > struct drm_crtc_state *cstate) > @@ -73,7 +62,7 @@ static int pl111_display_check(struct > drm_simple_display_pipe *pipe, > return -EINVAL; > > if (fb) { > - u32 offset = pl111_get_fb_offset(pstate); > + u32 offset = drm_fb_cma_get_gem_addr(fb, pstate, 0); > > /* FB base address must be dword aligned. */ > if (offset & 3) > @@ -249,7 +238,7 @@ static void pl111_display_update(struct > drm_simple_display_pipe *pipe, > struct drm_framebuffer *fb = pstate->fb; > > if (fb) { > - u32 addr = pl111_get_fb_offset(pstate); > + u32 addr = drm_fb_cma_get_gem_addr(fb, pstate, 0); > > writel(addr, priv->regs + CLCD_UBAS); > } > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
Op 05-06-17 om 12:08 schreef Archit Taneja: > > > On 06/03/2017 01:55 AM, Eric Anholt wrote: >> Many DRM drivers have common code to make a stub connector >> implementation that wraps a drm_panel. By wrapping the panel in a DRM >> bridge, all of the connector code (including calls during encoder >> enable/disable) goes away. >> >> v2: Fix build with CONFIG_DRM=m, drop "dev" argument that should just >> be the panel's dev, move kerneldoc up a level and document >> _remove(). >> v3: Fix another breakage with CONFIG_DRM=m, fix breakage with >> CONFIG_OF=n, move protos under CONFIG_DRM_PANEL_BRIDGE, wrap a >> line. >> >> Signed-off-by: Eric Anholt >> Acked-by: Daniel Vetter (v1) >> Reviewed-by: Boris Brezillon (v2) >> Acked-by: Archit Taneja (v2) >> --- >> >> New version of the first patch with build fixes. I've re-pushed to >> get another round of kbuild test, but if it comes back clean, I'd like >> to merge this one, the vc4 patches (unchanged), and atmel-hlcdc (acked >> by the maintainer). I'd be dropping my STM patch (replaced by their >> DSI series), and mediatek (I'd like an ack from the maintainer first). > > Thanks, I've locally picked up this patch and the following patches from > the v2 series: > > [PATCH v2 2/7] drm/vc4: Switch DSI to the panel-bridge layer, and support > bridges. > [PATCH v2 3/7] drm/vc4: Switch DPI to using the panel-bridge helper. > [PATCH v2 6/7] drm/atmel-hlcdc: Drop custom encoder cleanup func. > [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with > drm_panel_bridge. This patch breaks support for building drm as module, because it imports some of the drm_kms_helper stuff. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt/bindings: display: fix display-timing reference
On Wed, May 24, 2017 at 05:51:31PM +0200, Daniel Vetter wrote: > On Wed, May 24, 2017 at 03:37:36PM +0300, Baruch Siach wrote: > > Hi Daniel, > > > > On Wed, May 24, 2017 at 02:23:22PM +0200, Daniel Vetter wrote: > > > On Tue, May 23, 2017 at 09:47:56AM -0500, Rob Herring wrote: > > > > On Tue, May 16, 2017 at 11:19:04AM +0300, Baruch Siach wrote: > > > > > Fixes: 14da3ed8dd08 ("devicetree/bindings: display: Document common > > > > > panel properties") > > > > > Cc: Laurent Pinchart > > > > > Cc: Rob Herring > > > > > Signed-off-by: Baruch Siach > > > > > --- > > > > > Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 > > > > > +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > Acked-by: Rob Herring > > > > > > We now have a pile of acks on these patches, but no one to push them. > > > Seems like it's for the panel tree, but Thierry isn't on cc afaics. > > > > > > Someone needs to take care of this (and no it's no going to be me). > > > > Thanks for looking into this. > > > > Just for the record, Thierry has been on To/Cc of all messages in this > > thread, > > accept yours. > > Ah, that might be his dri-devel settings, there's a mailman option to > remove the cc if you're subscribed. And I got the mails through the m-l. > > I think this wasn't the first time this happened either ... Sorry, I've been busy moving house for the past few weeks. And yes, indeed, this seems to have been the mailmain option. I've switched that around now, so hopefully this won't happen again. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver
On Tue, 6 Jun 2017 16:30:15 +0300 Tomi Valkeinen wrote: > On 02/06/17 15:04, Boris Brezillon wrote: > > > +enum cdns_dsi_output_type { > > + CDNS_DSI_PANEL = 0, > > + CDNS_DSI_BRIDGE = 1, > > +}; > > Just my opinion, but I think you should only define values for enums > when those values actually mean something and are needed. In this case, > it doesn't matter which values those enums have. Actually, this will go away in the next version (see Archit's comment). > > > +static int cdns_dsi_init_link(struct cdns_dsi *dsi) > > +{ > > + u32 val; > > + int i; > > + > > + writel(CLK_UNIT_INTERVAL(16), dsi->regs + MCTL_DPHY_STATIC); > > + writel(CLK_DIV(0xb) | HSTX_TIMEOUT(0xed8afff), > > + dsi->regs + MCTL_DPHY_TIMEOUT1); > > + writel(LPRX_TIMEOUT(0xf30f), dsi->regs + MCTL_DPHY_TIMEOUT2); > > + > > + val = WAIT_BURST_TIME(0xf); > > + for (i = 1; i < dsi->output->dev->lanes; i++) > > + val |= DATA_LANE_EN(i); > > + > > + if (!(dsi->output->dev->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) > > + val |= CLK_CONTINUOUS; > > + > > + writel(val, dsi->regs + MCTL_MAIN_PHY_CTL); > > + > > + writel(CLK_LANE_ULPOUT_TIME(0x105) | DATA_LANE_ULPOUT_TIME(0x1d5), > > + dsi->regs + MCTL_ULPOUT_TIME); > > + > > + writel(LINK_EN, dsi->regs + MCTL_MAIN_DATA_CTL); > > + > > + val = CLK_LANE_EN | PLL_START; > > + for (i = 0; i < dsi->output->dev->lanes; i++) > > + val |= DATA_LANE_START(i); > > + > > + writel(val, dsi->regs + MCTL_MAIN_EN); > > + > > + ndelay(100); > > + > > + return 0; > > +} > > There are quite a bit of magic values here (elsewhere too). Looking at > the names of the macros, many of them probably represent spans of time, > in clock ticks? Would it make more sense to have the times defined in, > say, nanoseconds, and a function to convert the ns to clock ticks? > > And a hardcoded CLK_DIV, does that work? Is the clock rate fixed? Okay, it seems I have all the necessary information to dynamically calculate ULPOUT_TIME values (these values are based on sysclk and ULPOUT_TIME should be 1ms). It's a bit more complicated for MCTL_DPHY_TIMEOUT1 and MCTL_DPHY_TIMEOUT2, because counters are based on the dsi_tx_byte clock which is derived from the DPHY PLL, and I don't have the final spec of the DPHY block yet, which means I can't extract the dsi_tx_byte clock rate. A temporary solution would be to hardcore the tx_byte_clk in the driver and do all the calculation based on this hardcoded value. Or maybe we should expose the DPHY PLL in the DT. I also don't know what CLK_UNIT_INTERVAL() is encoding. I'll check with Cadence engineers. Thanks, Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Jun 6, 2017 at 7:51 AM, Christian König wrote: > Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas: >> >> On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote: >>> >>> Hi Bjorn, >>> >>> sorry for not responding earlier and thanks for picking this thread >>> up again. >>> >>> Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas: [+cc ADMGPU, DRM folks] On Tue, May 09, 2017 at 06:49:07PM +0200, Christian König wrote: > > [SNIP] > +/** > + * amdgpu_resize_bar0 - try to resize BAR0 > + * > + * @adev: amdgpu_device pointer > + * > + * Try to resize BAR0 to make all VRAM CPU accessible. > + */ > +void amdgpu_resize_bar0(struct amdgpu_device *adev) > +{ > + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size); > + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1; > + u16 cmd; > + int r; > + > + /* Free the doorbell mapping, it most likely needs to move as > well */ > + amdgpu_doorbell_fini(adev); > + pci_release_resource(adev->pdev, 2); > + > + /* Disable memory decoding while we change the BAR addresses > and size */ > + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd); > + pci_write_config_word(adev->pdev, PCI_COMMAND, > + cmd & ~PCI_COMMAND_MEMORY); > + > + r = pci_resize_resource(adev->pdev, 0, rbar_size); > + if (r == -ENOSPC) > + DRM_INFO("Not enough PCI address space for a large > BAR."); > + else if (r && r != -ENOTSUPP) > + DRM_ERROR("Problem resizing BAR0 (%d).", r); > + > + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd); > + > + /* When the doorbell BAR isn't available we have no chance of > +* using the device. > +*/ > + BUG_ON(amdgpu_doorbell_init(adev)); This amdgpu_doorbell_fini()/amdgpu_doorbell_init() thing doesn't look right. amdgpu_device_init() only calls amdgpu_doorbell_init() for "adev->asic_type >= CHIP_BONAIRE", but we call it unconditionally here. This is the call graph: amdgpu_device_init adev->rmmio_base = pci_resource_start(adev->pdev, 5) # 2 for < BONAIRE adev->rmmio = ioremap(adev->rmmio_base, ...) DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)adev->rmmio_base) if (adev->asic_type >= CHIP_BONAIRE) { amdgpu_doorbell_init adev->doorbell.base = pci_resource_start(adev->pdev, 2) adev->doorbell.ptr = ioremap(adev->doorbell.base, ...) } amdgpu_init gmc_v7_0_sw_init # gmc_v7_0_ip_funcs.sw_init gmc_v7_0_mc_init + amdgpu_resize_bar0 + amdgpu_doorbell_fini + pci_release_resource(adev->pdev, 2) + pci_resize_resource(adev->pdev, 0, size) + amdgpu_doorbell_init adev->mc.aper_base = pci_resource_start(adev->pdev, 0) If "asic_type < CHIP_BONAIRE", we ioremapped BAR 2 in amdgpu_device_init(), then we released the resource here and never updated the ioremap. >>> >>> The first hardware with a resizeable BAR I could find is a Tonga, >>> and that is even a generation later than Bonaire. >>> >>> So we are never going to call this code on earlier hardware generations. >> >> The problem with that is that it's impossible for a code reader to >> verify that. So adding a check is ugly but I think makes it more >> readable. > > > Good point. I will just move the check into the function itself, that should > handle all such cases. > From the PCI core perspective, it would be much cleaner to do the BAR resize before the driver calls pci_enable_device(). If that could be done, there would be no need for this sort of shutdown/reinit stuff and we wouldn't have to worry about issues like these. The amdgpu init path is pretty complicated, so I don't know whether this is possible. >>> >>> I completely agree on this and it is actually the approach I tried first. >>> >>> There are just two problems with this approach: >>> 1. When the amdgpu driver is loaded there can already be the VGA >>> console, Vesa or EFI driver active for the device and displaying the >>> splash screen. >>> >>> When we resize and most likely relocate the BAR while those drivers >>> are active it will certainly cause problems. >>> >>> What amdgpu does before trying to resize the BAR is kicking out >>> other driver and making sure it has exclusive access to the >>> hardware. >> >> I don't understand the problem here yet. If you need to enable the >> device, then disable it, resize, and re-enable it, that's fine. > > > The issue is we never enable the device ourself in amdgpu, except for some > rare cases during resume.
Re: [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver
On 02/06/17 15:04, Boris Brezillon wrote: > +enum cdns_dsi_output_type { > + CDNS_DSI_PANEL = 0, > + CDNS_DSI_BRIDGE = 1, > +}; Just my opinion, but I think you should only define values for enums when those values actually mean something and are needed. In this case, it doesn't matter which values those enums have. > +static int cdns_dsi_init_link(struct cdns_dsi *dsi) > +{ > + u32 val; > + int i; > + > + writel(CLK_UNIT_INTERVAL(16), dsi->regs + MCTL_DPHY_STATIC); > + writel(CLK_DIV(0xb) | HSTX_TIMEOUT(0xed8afff), > +dsi->regs + MCTL_DPHY_TIMEOUT1); > + writel(LPRX_TIMEOUT(0xf30f), dsi->regs + MCTL_DPHY_TIMEOUT2); > + > + val = WAIT_BURST_TIME(0xf); > + for (i = 1; i < dsi->output->dev->lanes; i++) > + val |= DATA_LANE_EN(i); > + > + if (!(dsi->output->dev->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) > + val |= CLK_CONTINUOUS; > + > + writel(val, dsi->regs + MCTL_MAIN_PHY_CTL); > + > + writel(CLK_LANE_ULPOUT_TIME(0x105) | DATA_LANE_ULPOUT_TIME(0x1d5), > +dsi->regs + MCTL_ULPOUT_TIME); > + > + writel(LINK_EN, dsi->regs + MCTL_MAIN_DATA_CTL); > + > + val = CLK_LANE_EN | PLL_START; > + for (i = 0; i < dsi->output->dev->lanes; i++) > + val |= DATA_LANE_START(i); > + > + writel(val, dsi->regs + MCTL_MAIN_EN); > + > + ndelay(100); > + > + return 0; > +} There are quite a bit of magic values here (elsewhere too). Looking at the names of the macros, many of them probably represent spans of time, in clock ticks? Would it make more sense to have the times defined in, say, nanoseconds, and a function to convert the ns to clock ticks? And a hardcoded CLK_DIV, does that work? Is the clock rate fixed? (I don't have the datasheet yet =) Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On Tue, 6 Jun 2017 16:01:45 +0300 Tomi Valkeinen wrote: > On 06/06/17 15:37, Boris Brezillon wrote: > > Hi Tomi, > > > > On Tue, 6 Jun 2017 15:30:26 +0300 > > Tomi Valkeinen wrote: > > > >> On 02/06/17 15:04, Boris Brezillon wrote: > >>> Document the bindings used for the Cadence DSI bridge. > >>> > >>> Signed-off-by: Boris Brezillon > >>> --- > >>> .../bindings/display/bridge/cdns,dsi.txt | 55 > >>> ++ > >>> 1 file changed, 55 insertions(+) > >>> create mode 100644 > >>> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> new file mode 100644 > >>> index ..770c5c5b1e93 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> @@ -0,0 +1,55 @@ > >>> +Cadence DSI bridge > >>> +== > >>> + > >>> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI > >>> lanes. > >>> + > >>> +Required properties: > >>> +- compatible: should be set to "cdns,dsi". > >>> +- reg: physical base address and length of the controller's registers. > >>> +- interrupts: interrupt line connected to the DSI bridge. > >>> +- clocks: DSI bridge clocks. > >>> +- clock-names: must contain "pclk" and "sysclk". > >> > >> clock-names doesn't match the example below. > > > > Indeed. I'll fix the example. > > > >> > >>> +- phys: phandle link to the MIPI D-PHY controller. > >>> +- phy-names: must contain "dphy". > >>> +- #address-cells: must be set to 1. > >>> +- #size-cells: must be set to 0. > >>> + > >>> +Required subnodes: > >>> +- ports: Ports as described in > >>> Documentation/devicetree/bindings/graph.txt. > >>> + Currently contains a single input port at address 0 representing the > >>> DPI > >>> + input. Other ports will be added later to support the SDI inputs. > >> > >> Typo with "SDI". > > > > No, the 2nd and 3rd input ports are really called SDI. Here > > is the datasheet description: > > > > " > > SDI: > > Serial Display Interface - this is the name of the block that is built > > to interface the Display application processor to the DSI link. This is > > a proprietary interface. > > " > > Ok. Well, I think that's a bit pointless comment in the binding doc, > it'll only confuse =). Describe what the current binding is, not what > might be added later (but that can be mentioned in the commit desc if > you want). OK. Will do that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On 06/06/17 15:37, Boris Brezillon wrote: > Hi Tomi, > > On Tue, 6 Jun 2017 15:30:26 +0300 > Tomi Valkeinen wrote: > >> On 02/06/17 15:04, Boris Brezillon wrote: >>> Document the bindings used for the Cadence DSI bridge. >>> >>> Signed-off-by: Boris Brezillon >>> --- >>> .../bindings/display/bridge/cdns,dsi.txt | 55 >>> ++ >>> 1 file changed, 55 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> >>> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> new file mode 100644 >>> index ..770c5c5b1e93 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> @@ -0,0 +1,55 @@ >>> +Cadence DSI bridge >>> +== >>> + >>> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes. >>> + >>> +Required properties: >>> +- compatible: should be set to "cdns,dsi". >>> +- reg: physical base address and length of the controller's registers. >>> +- interrupts: interrupt line connected to the DSI bridge. >>> +- clocks: DSI bridge clocks. >>> +- clock-names: must contain "pclk" and "sysclk". >> >> clock-names doesn't match the example below. > > Indeed. I'll fix the example. > >> >>> +- phys: phandle link to the MIPI D-PHY controller. >>> +- phy-names: must contain "dphy". >>> +- #address-cells: must be set to 1. >>> +- #size-cells: must be set to 0. >>> + >>> +Required subnodes: >>> +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt. >>> + Currently contains a single input port at address 0 representing the DPI >>> + input. Other ports will be added later to support the SDI inputs. >> >> Typo with "SDI". > > No, the 2nd and 3rd input ports are really called SDI. Here > is the datasheet description: > > " > SDI: > Serial Display Interface - this is the name of the block that is built > to interface the Display application processor to the DSI link. This is > a proprietary interface. > " Ok. Well, I think that's a bit pointless comment in the binding doc, it'll only confuse =). Describe what the current binding is, not what might be added later (but that can be mentioned in the commit desc if you want). Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On 06/06/17 15:48, Boris Brezillon wrote: > Okay. Thanks for the clarification. Can you confirm that this version > is correct? > > dsi@xxx { > #address-cells = <1>; > #size-cells = <0>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > dpi_in: port@0 { > reg = <0>; > #address-cells = <1>; > #size-cells = <0>; > > endpoint@0 { > remote-endpoint = <&dpi_out>; > }; > }; > > dsi_out: port@1 { > reg = <1>; > #address-cells = <1>; > #size-cells = <0>; > > dsi_out_vc0: endpoint@0 { > reg = <0>; > remote-endpoint = <&dsi_panel0_in>; > }; > > dsi_out_vc1: endpoint@1 { > reg = <1>; > remote-endpoint = <&dsi_panel1_in>; > }; > }; > }; > > panel@0 { > compatible = "..."; > reg = <0>; > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > #address-cells = <1>; > #size-cells = <0>; > reg = <0>; > > dsi_panel0_in: endpoint@0 { > reg = <0>; > remote-endpoint = <&dsi_out_vc0>; > }; > }; > }; > > panel@1 { > compatible = "..."; > reg = <1>; > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > #address-cells = <1>; > #size-cells = <0>; > reg = <0>; > > dsi_panel1_in: endpoint@0 { > reg = <0>; > remote-endpoint = <&dsi_out_vc1>; > }; > }; > }; > }; > Looks correct to me. I think it can be a bit shorter though: - You don't need #address-cells and #size-cells for all. I think those are inherited from the parent. - If there's just one port and one endpoint, you can leave the 'reg' out, as it's considered to be 0 by default. So for the panel, you can have just: port { dsi_panel1_in: endpoint { remote-endpoint = <&dsi_out_vc1>; }; }; signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On Tue, 6 Jun 2017 15:40:25 +0300 Tomi Valkeinen wrote: > On 06/06/17 12:35, Boris Brezillon wrote: > > On Sat, 3 Jun 2017 23:43:17 +0530 > > Archit Taneja wrote: > > > >> Hi, > >> > >> On 06/02/2017 05:34 PM, Boris Brezillon wrote: > >>> Document the bindings used for the Cadence DSI bridge. > >>> > >>> Signed-off-by: Boris Brezillon > >>> --- > >>> .../bindings/display/bridge/cdns,dsi.txt | 55 > >>> ++ > >>> 1 file changed, 55 insertions(+) > >>> create mode 100644 > >>> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> new file mode 100644 > >>> index ..770c5c5b1e93 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > >>> @@ -0,0 +1,55 @@ > >>> +Cadence DSI bridge > >>> +== > >>> + > >>> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI > >>> lanes. > >> > >> Is this a separate chip, or an IP integrated into SoCs? > > > > It's supposed to be integrated into SoCs. > > > >> If it's the > >> latter, I don't think DPI on the its input side is the right term to > >> use. Maybe RGB would be more appropriate here. > > > > Well, the datasheet explicitly mentions DPI, and you can also send > > pixels in YUV422 and YUV420 format on this bus, so I don't think RGB is > > appropriate, but if you really want me to use RGB I can change that. > > > > BTW, can you detail why DPI is not appropriate for internal parallel > > busses. I don't understand why it makes a difference when the bus is exposed > > through external pins. > > I think MIPI DPI is fine, if it is indeed MIPI DPI. But mot all parallel > video busses are MIPI DPI. > > >>> +Required subnodes: > >>> +- ports: Ports as described in > >>> Documentation/devicetree/bindings/graph.txt. > >>> + Currently contains a single input port at address 0 representing the > >>> DPI > >>> + input. Other ports will be added later to support the SDI inputs. > >>> + Port 0 should be connected to a DPI encoder output. > >> > >> The output of the DSI bridge may be another bridge, which could be i2c > >> controlled. In that case, it won't be a child of the DSI bridge. For > >> such scenarios, we might want to define an output port for the bridge. > > > > Hm, okay. IIRC, this is something you mentioned when I asked how to > > describe input/output ports for a DSI bridge a while ago. > > > > I'm still not sure how the links between input and output endpoint are > > supposed to be described. > > > > For example, if you take the case where you have the DSI device > > directly described under the DSI host controller, should I create > > another node for this output port? Something like the following? > > > > dsi@xxx { > > #address-cells = <1>; > > #size-cells = <0>; > > > > ports { > > #address-cells = <1>; > > #size-cells = <0>; > > dpi_in: port@0 { > > reg = <0>; > > #address-cells = <1>; > > #size-cells = <0>; > > > > endpoint@0 { > > remote-endpoint = <&dpi_out>; > > }; > > }; > > > > dsi_out0: port@1 { > > reg = <1>; > > #address-cells = <1>; > > #size-cells = <0>; > > > > dsi_out0: endpoint@0 { > > remote-endpoint = <&dsi_panel0_in>; > > }; > > }; > > > > dsi_out0: port@2 { > > reg = <2>; > > #address-cells = <1>; > > #size-cells = <0>; > > > > dsi_out1: endpoint@0 { > > remote-endpoint = <&dsi_panel1_in>; > > }; > > }; > > }; > > > > panel@0 { > > compatible = "..."; > > reg = <0>; > > #address-cells = <1>; > > #size-cells = <0>; > > > > port@0 { > > #address-cells = <1>; > > #size-cells = <0>; > > reg = <0>; > > > > dsi_panel0_in: endpoint@0 { > > remote-endpoint = <&dsi_out0>; > > }; > > }; > > }; > > > > panel@1 { > > compatible = "..."; > >
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On 06/06/17 12:35, Boris Brezillon wrote: > On Sat, 3 Jun 2017 23:43:17 +0530 > Archit Taneja wrote: > >> Hi, >> >> On 06/02/2017 05:34 PM, Boris Brezillon wrote: >>> Document the bindings used for the Cadence DSI bridge. >>> >>> Signed-off-by: Boris Brezillon >>> --- >>> .../bindings/display/bridge/cdns,dsi.txt | 55 >>> ++ >>> 1 file changed, 55 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> >>> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> new file mode 100644 >>> index ..770c5c5b1e93 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt >>> @@ -0,0 +1,55 @@ >>> +Cadence DSI bridge >>> +== >>> + >>> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI >>> lanes. >> >> Is this a separate chip, or an IP integrated into SoCs? > > It's supposed to be integrated into SoCs. > >> If it's the >> latter, I don't think DPI on the its input side is the right term to >> use. Maybe RGB would be more appropriate here. > > Well, the datasheet explicitly mentions DPI, and you can also send > pixels in YUV422 and YUV420 format on this bus, so I don't think RGB is > appropriate, but if you really want me to use RGB I can change that. > > BTW, can you detail why DPI is not appropriate for internal parallel > busses. I don't understand why it makes a difference when the bus is exposed > through external pins. I think MIPI DPI is fine, if it is indeed MIPI DPI. But mot all parallel video busses are MIPI DPI. >>> +Required subnodes: >>> +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt. >>> + Currently contains a single input port at address 0 representing the DPI >>> + input. Other ports will be added later to support the SDI inputs. >>> + Port 0 should be connected to a DPI encoder output. >> >> The output of the DSI bridge may be another bridge, which could be i2c >> controlled. In that case, it won't be a child of the DSI bridge. For >> such scenarios, we might want to define an output port for the bridge. > > Hm, okay. IIRC, this is something you mentioned when I asked how to > describe input/output ports for a DSI bridge a while ago. > > I'm still not sure how the links between input and output endpoint are > supposed to be described. > > For example, if you take the case where you have the DSI device > directly described under the DSI host controller, should I create > another node for this output port? Something like the following? > > dsi@xxx { > #address-cells = <1>; > #size-cells = <0>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > dpi_in: port@0 { > reg = <0>; > #address-cells = <1>; > #size-cells = <0>; > > endpoint@0 { > remote-endpoint = <&dpi_out>; > }; > }; > > dsi_out0: port@1 { > reg = <1>; > #address-cells = <1>; > #size-cells = <0>; > > dsi_out0: endpoint@0 { > remote-endpoint = <&dsi_panel0_in>; > }; > }; > > dsi_out0: port@2 { > reg = <2>; > #address-cells = <1>; > #size-cells = <0>; > > dsi_out1: endpoint@0 { > remote-endpoint = <&dsi_panel1_in>; > }; > }; > }; > > panel@0 { > compatible = "..."; > reg = <0>; > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > #address-cells = <1>; > #size-cells = <0>; > reg = <0>; > > dsi_panel0_in: endpoint@0 { > remote-endpoint = <&dsi_out0>; > }; > }; > }; > > panel@1 { > compatible = "..."; > reg = <1>; > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > #address-cells = <1>; > #size-cells = <0>;
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
Hi Tomi, On Tue, 6 Jun 2017 15:30:26 +0300 Tomi Valkeinen wrote: > On 02/06/17 15:04, Boris Brezillon wrote: > > Document the bindings used for the Cadence DSI bridge. > > > > Signed-off-by: Boris Brezillon > > --- > > .../bindings/display/bridge/cdns,dsi.txt | 55 > > ++ > > 1 file changed, 55 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > new file mode 100644 > > index ..770c5c5b1e93 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > @@ -0,0 +1,55 @@ > > +Cadence DSI bridge > > +== > > + > > +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes. > > + > > +Required properties: > > +- compatible: should be set to "cdns,dsi". > > +- reg: physical base address and length of the controller's registers. > > +- interrupts: interrupt line connected to the DSI bridge. > > +- clocks: DSI bridge clocks. > > +- clock-names: must contain "pclk" and "sysclk". > > clock-names doesn't match the example below. Indeed. I'll fix the example. > > > +- phys: phandle link to the MIPI D-PHY controller. > > +- phy-names: must contain "dphy". > > +- #address-cells: must be set to 1. > > +- #size-cells: must be set to 0. > > + > > +Required subnodes: > > +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt. > > + Currently contains a single input port at address 0 representing the DPI > > + input. Other ports will be added later to support the SDI inputs. > > Typo with "SDI". No, the 2nd and 3rd input ports are really called SDI. Here is the datasheet description: " SDI: Serial Display Interface - this is the name of the block that is built to interface the Display application processor to the DSI link. This is a proprietary interface. " Thanks, Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On 02/06/17 15:04, Boris Brezillon wrote: > Document the bindings used for the Cadence DSI bridge. > > Signed-off-by: Boris Brezillon > --- > .../bindings/display/bridge/cdns,dsi.txt | 55 > ++ > 1 file changed, 55 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > new file mode 100644 > index ..770c5c5b1e93 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > @@ -0,0 +1,55 @@ > +Cadence DSI bridge > +== > + > +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes. > + > +Required properties: > +- compatible: should be set to "cdns,dsi". > +- reg: physical base address and length of the controller's registers. > +- interrupts: interrupt line connected to the DSI bridge. > +- clocks: DSI bridge clocks. > +- clock-names: must contain "pclk" and "sysclk". clock-names doesn't match the example below. > +- phys: phandle link to the MIPI D-PHY controller. > +- phy-names: must contain "dphy". > +- #address-cells: must be set to 1. > +- #size-cells: must be set to 0. > + > +Required subnodes: > +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt. > + Currently contains a single input port at address 0 representing the DPI > + input. Other ports will be added later to support the SDI inputs. Typo with "SDI". Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2
Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas: On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian König wrote: Hi Bjorn, sorry for not responding earlier and thanks for picking this thread up again. Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas: [+cc ADMGPU, DRM folks] On Tue, May 09, 2017 at 06:49:07PM +0200, Christian König wrote: [SNIP] +/** + * amdgpu_resize_bar0 - try to resize BAR0 + * + * @adev: amdgpu_device pointer + * + * Try to resize BAR0 to make all VRAM CPU accessible. + */ +void amdgpu_resize_bar0(struct amdgpu_device *adev) +{ + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size); + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1; + u16 cmd; + int r; + + /* Free the doorbell mapping, it most likely needs to move as well */ + amdgpu_doorbell_fini(adev); + pci_release_resource(adev->pdev, 2); + + /* Disable memory decoding while we change the BAR addresses and size */ + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd); + pci_write_config_word(adev->pdev, PCI_COMMAND, + cmd & ~PCI_COMMAND_MEMORY); + + r = pci_resize_resource(adev->pdev, 0, rbar_size); + if (r == -ENOSPC) + DRM_INFO("Not enough PCI address space for a large BAR."); + else if (r && r != -ENOTSUPP) + DRM_ERROR("Problem resizing BAR0 (%d).", r); + + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd); + + /* When the doorbell BAR isn't available we have no chance of +* using the device. +*/ + BUG_ON(amdgpu_doorbell_init(adev)); This amdgpu_doorbell_fini()/amdgpu_doorbell_init() thing doesn't look right. amdgpu_device_init() only calls amdgpu_doorbell_init() for "adev->asic_type >= CHIP_BONAIRE", but we call it unconditionally here. This is the call graph: amdgpu_device_init adev->rmmio_base = pci_resource_start(adev->pdev, 5) # 2 for < BONAIRE adev->rmmio = ioremap(adev->rmmio_base, ...) DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)adev->rmmio_base) if (adev->asic_type >= CHIP_BONAIRE) { amdgpu_doorbell_init adev->doorbell.base = pci_resource_start(adev->pdev, 2) adev->doorbell.ptr = ioremap(adev->doorbell.base, ...) } amdgpu_init gmc_v7_0_sw_init # gmc_v7_0_ip_funcs.sw_init gmc_v7_0_mc_init + amdgpu_resize_bar0 + amdgpu_doorbell_fini + pci_release_resource(adev->pdev, 2) + pci_resize_resource(adev->pdev, 0, size) + amdgpu_doorbell_init adev->mc.aper_base = pci_resource_start(adev->pdev, 0) If "asic_type < CHIP_BONAIRE", we ioremapped BAR 2 in amdgpu_device_init(), then we released the resource here and never updated the ioremap. The first hardware with a resizeable BAR I could find is a Tonga, and that is even a generation later than Bonaire. So we are never going to call this code on earlier hardware generations. The problem with that is that it's impossible for a code reader to verify that. So adding a check is ugly but I think makes it more readable. Good point. I will just move the check into the function itself, that should handle all such cases. From the PCI core perspective, it would be much cleaner to do the BAR resize before the driver calls pci_enable_device(). If that could be done, there would be no need for this sort of shutdown/reinit stuff and we wouldn't have to worry about issues like these. The amdgpu init path is pretty complicated, so I don't know whether this is possible. I completely agree on this and it is actually the approach I tried first. There are just two problems with this approach: 1. When the amdgpu driver is loaded there can already be the VGA console, Vesa or EFI driver active for the device and displaying the splash screen. When we resize and most likely relocate the BAR while those drivers are active it will certainly cause problems. What amdgpu does before trying to resize the BAR is kicking out other driver and making sure it has exclusive access to the hardware. I don't understand the problem here yet. If you need to enable the device, then disable it, resize, and re-enable it, that's fine. The issue is we never enable the device ourself in amdgpu, except for some rare cases during resume. In most of the cases we have to handle this is the primary display device which is enabled by either the BIOS, VGA console, VesaFB or EFIFB. Amdgpu just kicks out whatever driver was responsible for the device previously and takes over. I could of course do the disable/resize/reenable dance, but I would rather want to avoid that. The hardware is most likely already displaying a boot splash and we want to transit to the desktop without any flickering (at least that's the long term goal). Completely disabling the device to do this doesn't sounds like a good idea if we want that. The important thing I'm look
[PATCH] drm/atmel-hlcdc: Fix panel registration
Attach the panel-bridge created by drm_panel_bridge_add() to the parallel RGB encoder. Fixes: 96160a8071b2 ("drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.") Signed-off-by: Boris Brezillon --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c index 340ef962aa81..dfdd18763b0a 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c @@ -59,8 +59,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_Unknown); if (IS_ERR(bridge)) return PTR_ERR(bridge); - - return 0; } if (bridge) { -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver
Hi Archit, On Sun, 4 Jun 2017 00:20:06 +0530 Archit Taneja wrote: > > + > > +#define DPHY_CFG0 0x1b0 > > +#define DPHY_C_RSTBBIT(20) > > +#define DPHY_D_RSTB(x) ((x) << 16) > > +#define DPHY_TIF_FORCE_WRITE BIT(12) > > +#define DPHY_PLL_PDN BIT(10) > > +#define DPHY_CMN_PDN BIT(9) > > +#define DPHY_C_PDN BIT(8) > > +#define DPHY_D_PDN(x) ((x) << 4) > > +#define DPHY_PLL_PSO BIT(1) > > +#define DPHY_CMN_PSO BIT(0) > > + > > +#define DPHY_CFG1 0x1b4 > > +#define PDHY_PLL_OPDIV(x) ((x) << 20) > > +#define PDHY_PLL_IPDIV(x) ((x) << 12) > > +#define PDHY_PLL_FBDIV(x) (x) > > + > > +#define DPHY_PLL_TM_LO 0x1b8 > > +#define DPHY_PLL_TM_MID0x1bc > > +#define DPHY_PLL_TM_HI 0x1c0 > > + > > +#define DPHY_STATUS0x1c4 > > +#define PPI_D_RX_ULPS_ESC(x) ((x) >> 12) > > +#define PPI_C_TX_READY_HS BIT(8) > > +#define PPI_PLL_LOCK BIT(7) > > +#define PPI_PLL_COARSE BIT(6) > > +#define PPI_PLL_COARSE_CODE(x) ((x) & GENMASK(5, 0)) > > + > > +#define DPHY_BIST 0x1c8 > > +#define PSO_BYPASS_CTX_EN BIT(12) > > +#define PSO_BYPASS_TX_EN(l)BIT(8 + (l)) > > +#define BIST_CTX_ENBIT(4) > > +#define BIST_TX_EN(l) BIT(l) > > + > > Do the above DPHY registers actually configure the PHY used with the > controller, or do we need to configure any additional register outside > of this block to get things working? The DPHY has a separate I/O mem range with its own interface. I didn't provide support for this part yet because the interface is not stable yet. > > I ask because they aren't used in the code below, and the DT binding > for this device specifies the PHY as a separate device. What's the > plan in the future for PHY? The short-term plan is to add support for this DPHY in the cdns-dsi driver. The driver will just retrieve the I/O mem range and interrupt attached to the cdns DPHY block by following the phandle and using of helpers to do the conversion, and then use these resources internally. The mid/long-term plan is to add a dphy framework (on top of the PHY framework) to let dphy providers expose their features in a generic manner. There are 2 pros to this generic DPHY framework/layer: - you could possibly use DPHY and DSI blocks provided by 2 different vendors (not sure how feasible this is in practice) - CSI can also use DPHY as its PHY layer, so DPHY drivers could be shared between V4L and DRM drivers Note that I can't promise the mid/long-term goals are achievable, because my knowledge on DPHY is quite limited, but designing the DT bindings to handle this use case is really important, because of the DT stable ABI thing. > > + > > +static int cdns_dsi_bridge_attach(struct drm_bridge *bridge) > > +{ > > + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge); > > + struct cdns_dsi_output *output = input->dsi->output; > > + int ret; > > + > > + if (!drm_core_check_feature(bridge->dev, DRIVER_ATOMIC)) { > > + dev_err(input->dsi->base.dev, > > + "cdns-dsi driver is only compatible with DRM devices > > supporting atomic updates"); > > + return -ENOTSUPP; > > + } > > + > > + switch (output->type) { > > + case CDNS_DSI_PANEL: > > + ret = cdns_dsi_output_attach_panel(output); > > + break; > > + > > + case CDNS_DSI_BRIDGE: > > + ret = drm_bridge_attach(bridge->encoder, output->bridge, > > + bridge); > > + break; > > Could you have a look at Eric's dsi-panel-bridge patch-set? I think it > should simplify things for this driver too. Yep, that was planned. Was just waiting for this feature to reach drm-misc-next (which seems to be the case ;-)). > > > + > > + default: > > + ret = -ENOTSUPP; > > + } > > + > > + return ret; > > +} > > + > > +static bool cdns_dsi_bridge_mode_fixup(struct drm_bridge *bridge, > > + const struct drm_display_mode *mode, > > + struct drm_display_mode *adj) > > +{ > > + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge); > > + int bpp; > > + > > + /* > > +* VFP_DSI should be less than VFP_DPI and VFP_DSI should be at > > +* least 1. > > +*/ > > + if (adj->crtc_vtotal - adj->crtc_vsync_end < 2) > > + return false; > > + > > + /* VSA_DSI = VSA_DPI and must be at least 2. */ > > + if (adj->crtc_vsync_end - adj->crtc_vsync_start < 2) > > + return false; > > + > > + /* HACT must be a 32-bits aligned. */ > > + bpp = mipi_dsi_pixel_form
Re: [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.
On 06/06/2017 02:27 PM, Boris Brezillon wrote: Hi Archit, On Mon, 5 Jun 2017 21:06:20 +0530 Archit Taneja wrote: Hi, When pushing to drm-misc-next, I got a minor merge conflict when dim tried to rebuild drm-tip. The reason for the conflict was because the following commit was present in drm-tip but not in drm-misc: https://cgit.freedesktop.org/drm-tip/commit/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c?id=6bee9b78a7a5ea257b24d93974538938c82b1169 I fixed the conflict such that drm-tip is rebuit successfully. I'd however like if Eric and Boris could have a look at atmel_hlcdc_output.c to check if things are okay. Where can I find the fix you made to fix this problem? +Sean, I missed adding him in the original message. The fix is a part of the commit that merged drm-misc-next into drm-tip: https://cgit.freedesktop.org/drm-tip/commit/?id=62a258c9c517c7c97bc4545f77af21ee03e23e1a The commit "drm/atmel-hlcdc: Fix output initialization" was a part of 4.12-rc2. drm-misc-next is still based off 4.12-rc1, so this commit wasn't present. Sean will observe some minor merge conflicts when he rebases drm-misc-next onto a more recent tag from Linus. Thanks, Archit [...] if (panel) { - output->connector.dpms = DRM_MODE_DPMS_OFF; - output->connector.polled = DRM_CONNECTOR_POLL_CONNECT; - drm_connector_helper_add(&output->connector, - &atmel_hlcdc_panel_connector_helper_funcs); - ret = drm_connector_init(dev, &output->connector, -&atmel_hlcdc_panel_connector_funcs, -DRM_MODE_CONNECTOR_Unknown); - if (ret) - goto err_encoder_cleanup; - - drm_mode_connector_attach_encoder(&output->connector, - &output->encoder); - - ret = drm_panel_attach(panel, &output->connector); - if (ret) { - drm_connector_cleanup(&output->connector); - goto err_encoder_cleanup; - } - - output->panel = panel; + bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_Unknown); + if (IS_ERR(bridge)) + return PTR_ERR(bridge); return 0; Just noticed that this is wrong. We should not return here, otherwise the panel bridge is never attached to the encoder. } if (bridge) { - ret = drm_bridge_attach(&output->encoder, bridge, NULL); + ret = drm_bridge_attach(encoder, bridge, NULL); if (!ret) return 0; + + if (panel) + drm_panel_bridge_remove(bridge); } -err_encoder_cleanup: - drm_encoder_cleanup(&output->encoder); + drm_encoder_cleanup(encoder); return ret; } -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: ipu-v3: remove interrupt busy waiting routine
This is not used anymore since commit eb8c88808c83 ("drm/imx: add deferred plane disabling"), remove it. Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-common.c | 16 drivers/gpu/ipu-v3/ipu-prv.h| 1 - 2 files changed, 17 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c index 61310f8be3099..22e0a3eca7b1d 100644 --- a/drivers/gpu/ipu-v3/ipu-common.c +++ b/drivers/gpu/ipu-v3/ipu-common.c @@ -597,22 +597,6 @@ int ipu_idmac_wait_busy(struct ipuv3_channel *channel, int ms) } EXPORT_SYMBOL_GPL(ipu_idmac_wait_busy); -int ipu_wait_interrupt(struct ipu_soc *ipu, int irq, int ms) -{ - unsigned long timeout; - - timeout = jiffies + msecs_to_jiffies(ms); - ipu_cm_write(ipu, BIT(irq % 32), IPU_INT_STAT(irq / 32)); - while (!(ipu_cm_read(ipu, IPU_INT_STAT(irq / 32) & BIT(irq % 32 { - if (time_after(jiffies, timeout)) - return -ETIMEDOUT; - cpu_relax(); - } - - return 0; -} -EXPORT_SYMBOL_GPL(ipu_wait_interrupt); - int ipu_idmac_disable_channel(struct ipuv3_channel *channel) { struct ipu_soc *ipu = channel->ipu; diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h index b6e22d64159fa..ac4b8d6585008 100644 --- a/drivers/gpu/ipu-v3/ipu-prv.h +++ b/drivers/gpu/ipu-v3/ipu-prv.h @@ -225,7 +225,6 @@ int ipu_module_enable(struct ipu_soc *ipu, u32 mask); int ipu_module_disable(struct ipu_soc *ipu, u32 mask); bool ipu_idmac_channel_busy(struct ipu_soc *ipu, unsigned int chno); -int ipu_wait_interrupt(struct ipu_soc *ipu, int irq, int ms); int ipu_csi_init(struct ipu_soc *ipu, struct device *dev, int id, unsigned long base, u32 module, struct clk *clk_ipu); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On Sat, 3 Jun 2017 23:43:17 +0530 Archit Taneja wrote: > Hi, > > On 06/02/2017 05:34 PM, Boris Brezillon wrote: > > Document the bindings used for the Cadence DSI bridge. > > > > Signed-off-by: Boris Brezillon > > --- > > .../bindings/display/bridge/cdns,dsi.txt | 55 > > ++ > > 1 file changed, 55 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > new file mode 100644 > > index ..770c5c5b1e93 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt > > @@ -0,0 +1,55 @@ > > +Cadence DSI bridge > > +== > > + > > +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI > > lanes. > > Is this a separate chip, or an IP integrated into SoCs? It's supposed to be integrated into SoCs. > If it's the > latter, I don't think DPI on the its input side is the right term to > use. Maybe RGB would be more appropriate here. Well, the datasheet explicitly mentions DPI, and you can also send pixels in YUV422 and YUV420 format on this bus, so I don't think RGB is appropriate, but if you really want me to use RGB I can change that. BTW, can you detail why DPI is not appropriate for internal parallel busses. I don't understand why it makes a difference when the bus is exposed through external pins. > > > + > > +Required properties: > > +- compatible: should be set to "cdns,dsi". > > Would it be better to take a dw-hdmi like approach here? I.e, the > binding should be specific to the SoC that integrates this DSI > bridge? Hm, I was considering something slightly different: adding new compat strings to the DSI bridge driver and keep the interface to the display controller drivers as simple as possible to avoid duplicating the glue used to bind the component in all display controller drivers embedding this bridge. Note that right now we don't have any SoC embedding this IP. It has been tested on an FPGA with a very basic display controller (designed for testing purpose only). By exposing this IP as a simple bridge, we can easily attach it to any kind of display controller, and if we ever need to use the component framework, then it should be pretty easy to add support for this feature as a follow-up patch. > > > +- reg: physical base address and length of the controller's registers. > > +- interrupts: interrupt line connected to the DSI bridge. > > +- clocks: DSI bridge clocks. > > +- clock-names: must contain "pclk" and "sysclk". > > +- phys: phandle link to the MIPI D-PHY controller. > > +- phy-names: must contain "dphy". > > +- #address-cells: must be set to 1. > > +- #size-cells: must be set to 0. > > + > > +Required subnodes: > > +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt. > > + Currently contains a single input port at address 0 representing the DPI > > + input. Other ports will be added later to support the SDI inputs. > > + Port 0 should be connected to a DPI encoder output. > > The output of the DSI bridge may be another bridge, which could be i2c > controlled. In that case, it won't be a child of the DSI bridge. For > such scenarios, we might want to define an output port for the bridge. Hm, okay. IIRC, this is something you mentioned when I asked how to describe input/output ports for a DSI bridge a while ago. I'm still not sure how the links between input and output endpoint are supposed to be described. For example, if you take the case where you have the DSI device directly described under the DSI host controller, should I create another node for this output port? Something like the following? dsi@xxx { #address-cells = <1>; #size-cells = <0>; ports { #address-cells = <1>; #size-cells = <0>; dpi_in: port@0 { reg = <0>; #address-cells = <1>; #size-cells = <0>; endpoint@0 { remote-endpoint = <&dpi_out>; }; }; dsi_out0: port@1 { reg = <1>; #address-cells = <1>; #size-cells = <0>; dsi_out0: endpoint@0 { remote-endpoint = <&dsi_panel0_in>; }; }; dsi_out0: port@2 { reg = <2>; #address-cells = <1>; #size-cells = <0>;
Re: [Intel-gfx] [PATCH] drm: Restore GNOME monitors.xml support
On Sun, 04 Jun 2017, "H.J. Lu" wrote: > Please CC me since I am not on this mailing list. Sorry, should've instructed you to send to dri-devel instead of intel-gfx, because the patch touches drm helpers. Cc'd. BR, Jani. > > H.J. > --- > My ~/.config/monitors.xml swaps primary/secondary displays as well as > their horizontal positions. It works fine until: > > commit 91eefc05f0ac71902906b2058360e61bd25137fe > Author: Daniel Vetter > Date: Wed Dec 14 00:08:10 2016 +0100 > > drm: Tighten locking in drm_mode_getconnector > > which makes ~/.config/monitors.xml not effective. This patch reorders > drm_mode_getconnector and restores monitors.xml support. > > This may also fix: > > https://bugs.freedesktop.org/show_bug.cgi?id=100576 > > Signed-off-by: H.J. Lu > --- > drivers/gpu/drm/drm_connector.c | 74 > - > 1 file changed, 37 insertions(+), 37 deletions(-) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 45464c8..4fe8ff3 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1169,41 +1169,6 @@ int drm_mode_getconnector(struct drm_device *dev, void > *data, > if (!connector) > return -ENOENT; > > - drm_modeset_lock(&dev->mode_config.connection_mutex, NULL); > - encoder = drm_connector_get_encoder(connector); > - if (encoder) > - out_resp->encoder_id = encoder->base.id; > - else > - out_resp->encoder_id = 0; > - > - ret = drm_mode_object_get_properties(&connector->base, > file_priv->atomic, > - (uint32_t __user *)(unsigned long)(out_resp->props_ptr), > - (uint64_t __user *)(unsigned > long)(out_resp->prop_values_ptr), > - &out_resp->count_props); > - drm_modeset_unlock(&dev->mode_config.connection_mutex); > - if (ret) > - goto out_unref; > - > - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) > - if (connector->encoder_ids[i] != 0) > - encoders_count++; > - > - if ((out_resp->count_encoders >= encoders_count) && encoders_count) { > - copied = 0; > - encoder_ptr = (uint32_t __user *)(unsigned > long)(out_resp->encoders_ptr); > - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { > - if (connector->encoder_ids[i] != 0) { > - if (put_user(connector->encoder_ids[i], > - encoder_ptr + copied)) { > - ret = -EFAULT; > - goto out_unref; > - } > - copied++; > - } > - } > - } > - out_resp->count_encoders = encoders_count; > - > out_resp->connector_id = connector->base.id; > out_resp->connector_type = connector->connector_type; > out_resp->connector_type_id = connector->connector_type_id; > @@ -1240,15 +1205,50 @@ int drm_mode_getconnector(struct drm_device *dev, > void *data, > if (copy_to_user(mode_ptr + copied, >&u_mode, sizeof(u_mode))) { > ret = -EFAULT; > + mutex_unlock(&dev->mode_config.mutex); > goto out; > } > copied++; > } > } > out_resp->count_modes = mode_count; > -out: > mutex_unlock(&dev->mode_config.mutex); > -out_unref: > + > + drm_modeset_lock(&dev->mode_config.connection_mutex, NULL); > + encoder = drm_connector_get_encoder(connector); > + if (encoder) > + out_resp->encoder_id = encoder->base.id; > + else > + out_resp->encoder_id = 0; > + > + ret = drm_mode_object_get_properties(&connector->base, > file_priv->atomic, > + (uint32_t __user *)(unsigned long)(out_resp->props_ptr), > + (uint64_t __user *)(unsigned > long)(out_resp->prop_values_ptr), > + &out_resp->count_props); > + drm_modeset_unlock(&dev->mode_config.connection_mutex); > + if (ret) > + goto out; > + > + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) > + if (connector->encoder_ids[i] != 0) > + encoders_count++; > + > + if ((out_resp->count_encoders >= encoders_count) && encoders_count) { > + copied = 0; > + encoder_ptr = (uint32_t __user *)(unsigned > long)(out_resp->encoders_ptr); > + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { > + if (connector->encoder_ids[i] != 0) { > + if (put_user(connector->encoder_ids[i], > + encoder_ptr + copied)) { > + ret = -EFAULT; > +
Re: [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.
Hi Archit, On Mon, 5 Jun 2017 21:06:20 +0530 Archit Taneja wrote: > Hi, > > When pushing to drm-misc-next, I got a minor merge conflict when dim tried > to rebuild drm-tip. > > The reason for the conflict was because the following commit was present > in drm-tip but not in drm-misc: > > https://cgit.freedesktop.org/drm-tip/commit/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c?id=6bee9b78a7a5ea257b24d93974538938c82b1169 > > I fixed the conflict such that drm-tip is rebuit successfully. I'd > however like if Eric and Boris could have a look at atmel_hlcdc_output.c > to check if things are okay. Where can I find the fix you made to fix this problem? [...] > > if (panel) { > > - output->connector.dpms = DRM_MODE_DPMS_OFF; > > - output->connector.polled = DRM_CONNECTOR_POLL_CONNECT; > > - drm_connector_helper_add(&output->connector, > > - &atmel_hlcdc_panel_connector_helper_funcs); > > - ret = drm_connector_init(dev, &output->connector, > > -&atmel_hlcdc_panel_connector_funcs, > > -DRM_MODE_CONNECTOR_Unknown); > > - if (ret) > > - goto err_encoder_cleanup; > > - > > - drm_mode_connector_attach_encoder(&output->connector, > > - &output->encoder); > > - > > - ret = drm_panel_attach(panel, &output->connector); > > - if (ret) { > > - drm_connector_cleanup(&output->connector); > > - goto err_encoder_cleanup; > > - } > > - > > - output->panel = panel; > > + bridge = drm_panel_bridge_add(panel, > > DRM_MODE_CONNECTOR_Unknown); > > + if (IS_ERR(bridge)) > > + return PTR_ERR(bridge); > > > > return 0; Just noticed that this is wrong. We should not return here, otherwise the panel bridge is never attached to the encoder. > > } > > > > if (bridge) { > > - ret = drm_bridge_attach(&output->encoder, bridge, NULL); > > + ret = drm_bridge_attach(encoder, bridge, NULL); > > if (!ret) > > return 0; > > + > > + if (panel) > > + drm_panel_bridge_remove(bridge); > > } > > > > -err_encoder_cleanup: > > - drm_encoder_cleanup(&output->encoder); > > + drm_encoder_cleanup(encoder); > > > > return ret; > > } > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: ipu-v3: Fix CSI selection for VDIC
On Sat, 2017-06-03 at 11:57 -0700, Steve Longerbeam wrote: > From: Marek Vasut > > The description of the CSI_SEL bit in the i.MX6 reference manual is > incorrect. It states "This bit defines which CSI is the input to the > IC. This bit is effective only if IC_INPUT is bit cleared". > > From experiment it was found this is in fact not correct. The CSI_SEL > bit selects which CSI is input to _both_ the VDIC _and_ the IC. If the > IC_INPUT bit is set so that the IC is receiving from the VDIC, the IC > ignores the CSI_SEL bit, but CSI_SEL still selects which CSI the VDIC > receives from in that case. > > Signed-off-by: Marek Vasut > Signed-off-by: Steve Longerbeam > --- > drivers/gpu/ipu-v3/ipu-common.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c > index 16d5568..2fb5f43 100644 > --- a/drivers/gpu/ipu-v3/ipu-common.c > +++ b/drivers/gpu/ipu-v3/ipu-common.c > @@ -725,15 +725,16 @@ void ipu_set_ic_src_mux(struct ipu_soc *ipu, int > csi_id, bool vdi) > spin_lock_irqsave(&ipu->lock, flags); > > val = ipu_cm_read(ipu, IPU_CONF); > - if (vdi) { > + if (vdi) > val |= IPU_CONF_IC_INPUT; > - } else { > + else > val &= ~IPU_CONF_IC_INPUT; > - if (csi_id == 1) > - val |= IPU_CONF_CSI_SEL; > - else > - val &= ~IPU_CONF_CSI_SEL; > - } > + > + if (csi_id == 1) > + val |= IPU_CONF_CSI_SEL; > + else > + val &= ~IPU_CONF_CSI_SEL; > + > ipu_cm_write(ipu, val, IPU_CONF); > > spin_unlock_irqrestore(&ipu->lock, flags); Applied, thanks. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: Fix driver bind when only CVBS is available
On 05/29/2017 04:15 PM, Neil Armstrong wrote: > While introducing HDMI support, component matching on connectors node > were bypassed since no driver would actually bind on the DT node. > But when only a CVBS connector is present, only a single node is found > in the graph, but ignored and a NULL match table is given to the > component code. > > This code permits bypassing the components framework by binding directly > the DRM driver when no components needs to be loaded. > > Fixes: a41e82e6c457 ("drm/meson: Add support for components") > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/meson/meson_drv.c | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/meson/meson_drv.c > b/drivers/gpu/drm/meson/meson_drv.c > index 75382f5..10b227d 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -152,7 +152,7 @@ static bool meson_vpu_has_available_connectors(struct > device *dev) > .max_register = 0x1000, > }; > > -static int meson_drv_bind(struct device *dev) > +static int meson_drv_bind_master(struct device *dev, bool has_components) > { > struct platform_device *pdev = to_platform_device(dev); > struct meson_drm *priv; > @@ -233,10 +233,12 @@ static int meson_drv_bind(struct device *dev) > if (ret) > goto free_drm; > > - ret = component_bind_all(drm->dev, drm); > - if (ret) { > - dev_err(drm->dev, "Couldn't bind all components\n"); > - goto free_drm; > + if (has_components) { > + ret = component_bind_all(drm->dev, drm); > + if (ret) { > + dev_err(drm->dev, "Couldn't bind all components\n"); > + goto free_drm; > + } > } > > ret = meson_plane_create(priv); > @@ -276,6 +278,11 @@ static int meson_drv_bind(struct device *dev) > return ret; > } > > +static int meson_drv_bind(struct device *dev) > +{ > + return meson_drv_bind_master(dev, true); > +} > + > static void meson_drv_unbind(struct device *dev) > { > struct drm_device *drm = dev_get_drvdata(dev); > @@ -357,6 +364,9 @@ static int meson_drv_probe(struct platform_device *pdev) > count += meson_probe_remote(pdev, &match, np, remote); > } > > + if (count && !match) > + return meson_drv_bind_master(&pdev->dev, false); > + > /* If some endpoints were found, initialize the nodes */ > if (count) { > dev_info(&pdev->dev, "Queued %d outputs on vpu\n", count); > Hi, Could this patch go through the next drm-misc-fixes PR ? Thanks, Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/6] drm/stm: Add STM32 DSI host driver
Hi Philippe, On 06/02/2017 04:37 PM, Philippe CORNU wrote: > Add the STM32 DSI host driver that uses the Synopsys DesignWare > MIPI DSI DRM bridge. > > Signed-off-by: Philippe CORNU > --- > drivers/gpu/drm/stm/Kconfig | 8 + > drivers/gpu/drm/stm/Makefile | 2 + > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 353 > ++ > 3 files changed, 363 insertions(+) > create mode 100644 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c > > diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig > index 4b88223..4c0d670 100644 > --- a/drivers/gpu/drm/stm/Kconfig > +++ b/drivers/gpu/drm/stm/Kconfig > @@ -14,3 +14,11 @@ config DRM_STM > STMicroelectronics STM32 MCUs. > To compile this driver as a module, choose M here: the module > will be called stm-drm. > + > +config DRM_STM_DSI > + tristate "STMicroelectronics specific extensions for Synopsys MIPI DSI" > + depends on DRM_STM > + select DRM_MIPI_DSI > + select DRM_DW_MIPI_DSI > + help > + Choose this option for MIPI DSI support on STMicroelectronics SoC. > diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile > index a09ecf4..d883adc 100644 > --- a/drivers/gpu/drm/stm/Makefile > +++ b/drivers/gpu/drm/stm/Makefile > @@ -2,4 +2,6 @@ stm-drm-y := \ > drv.o \ > ltdc.o > > +obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o > + > obj-$(CONFIG_DRM_STM) += stm-drm.o > diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c > b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c > new file mode 100644 > index 000..8dedc5c > --- /dev/null > +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c > @@ -0,0 +1,353 @@ > +/* > + * Copyright (C) STMicroelectronics SA 2017 > + * > + * Authors: Philippe Cornu > + * Yannick Fertre > + * > + * License terms: GNU General Public License (GPL), version 2 > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* DSI wrapper register & bit definitions */ > +/* Note: registers are named as in the Reference Manual */ > +#define DSI_WCFGR0x0400 /* Wrapper ConFiGuration Reg */ > +#define WCFGR_DSIM BIT(0) /* DSI Mode */ > +#define WCFGR_COLMUX GENMASK(3, 1) /* COLor MUltipleXing */ > + > +#define DSI_WCR 0x0404 /* Wrapper Control Reg */ > +#define WCR_DSIENBIT(3) /* DSI ENable */ > + > +#define DSI_WISR 0x040C /* Wrapper Interrupt and Status Reg */ > +#define WISR_PLLLS BIT(8) /* PLL Lock Status */ > +#define WISR_RRS BIT(12) /* Regulator Ready Status */ > + > +#define DSI_WPCR00x0418 /* Wrapper Phy Conf Reg 0 */ > +#define WPCR0_UIX4 GENMASK(5, 0) /* Unit Interval X 4 */ > +#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */ > + > +#define DSI_WRPCR0x0430 /* Wrapper Regulator & Pll Ctrl Reg */ > +#define WRPCR_PLLEN BIT(0) /* PLL ENable */ > +#define WRPCR_NDIV GENMASK(8, 2) /* pll loop DIVision Factor */ > +#define WRPCR_IDFGENMASK(14, 11) /* pll Input Division Factor */ > +#define WRPCR_ODFGENMASK(17, 16) /* pll Output Division Factor */ > +#define WRPCR_REGEN BIT(24) /* REGulator ENable */ > +#define WRPCR_BGREN BIT(28) /* BandGap Reference ENable */ > +#define IDF_MIN 1 > +#define IDF_MAX 7 > +#define NDIV_MIN 10 > +#define NDIV_MAX 125 > +#define ODF_MIN 1 > +#define ODF_MAX 8 > + > +/* dsi color format coding according to the datasheet */ > +enum dsi_color { > + DSI_RGB565_CONF1, > + DSI_RGB565_CONF2, > + DSI_RGB565_CONF3, > + DSI_RGB666_CONF1, > + DSI_RGB666_CONF2, > + DSI_RGB888, > +}; > + > +#define LANE_MIN_KBPS31250 > +#define LANE_MAX_KBPS50 > + > +/* Sleep & timeout for regulator on/off, pll lock/unlock & fifo empty */ > +#define SLEEP_US 1000 > +#define TIMEOUT_US 20 > + > +struct dw_mipi_dsi_stm { > + void __iomem *base; > + struct clk *pllref_clk; > +}; > + > +static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val) > +{ > + writel_relaxed(val, dsi->base + reg); > +} > + > +static inline u32 dsi_read(struct dw_mipi_dsi_stm *dsi, u32 reg) > +{ > + return readl_relaxed(dsi->base + reg); > +} > + > +static inline void dsi_set(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 mask) > +{ > + dsi_write(dsi, reg, dsi_read(dsi, reg) | mask); > +} > + > +static inline void dsi_clear(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 mask) > +{ > + dsi_write(dsi, reg, dsi_read(dsi, reg) & ~mask); > +} > + > +static inline void dsi_update_bits(struct dw_mipi_dsi_stm *dsi, u32 reg, > +u32 mask, u32 val) > +{ > + dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val); > +} > + > +static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt) > +{ > + switch (fmt) { > + case MIPI_DS
Re: [PATCH v3 3/6] drm/bridge/synopsys: Add MIPI DSI host controller bridge
On 06/02/2017 04:37 PM, Philippe CORNU wrote: > Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the > Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. Hi Philippe, Small nit, but please use "DesignWare" everywhere if possible. Thanks, Neil > > Signed-off-by: Philippe CORNU > --- > drivers/gpu/drm/bridge/synopsys/Kconfig |9 + > drivers/gpu/drm/bridge/synopsys/Makefile |2 + > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 1022 > + > include/drm/bridge/dw_mipi_dsi.h | 42 + > 4 files changed, 1075 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > create mode 100644 include/drm/bridge/dw_mipi_dsi.h > > diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig > b/drivers/gpu/drm/bridge/synopsys/Kconfig > index 40d2827..d7fbdff 100644 > --- a/drivers/gpu/drm/bridge/synopsys/Kconfig > +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig > @@ -21,3 +21,12 @@ config DRM_DW_HDMI_I2S_AUDIO > help > Support the I2S Audio interface which is part of the Synopsys > Designware HDMI block. Yes I know this one is bad > + > +config DRM_DW_MIPI_DSI > + tristate "Synopsys DesignWare MIPI DSI host controller bridge" > + select DRM_KMS_HELPER > + select DRM_MIPI_DSI > + select DRM_PANEL > + help > + Choose this if you want to use the Synopsys DesignWare MIPI DSI host > + controller bridge. > diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile > b/drivers/gpu/drm/bridge/synopsys/Makefile > index 17aa7a6..5f57d36 100644 > --- a/drivers/gpu/drm/bridge/synopsys/Makefile > +++ b/drivers/gpu/drm/bridge/synopsys/Makefile > @@ -3,3 +3,5 @@ > obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o > obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o > obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o > + > +obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw-mipi-dsi.o > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > new file mode 100644 > index 000..6b25629 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > @@ -0,0 +1,1022 @@ > +/* > + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * Modified by Philippe Cornu > + * This generic Synopsys Designware MIPI DSI host driver is based on the --/\ Like here > + * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DSI_VERSION 0x00 > +#define DSI_PWR_UP 0x04 > +#define RESET0 > +#define POWERUP BIT(0) > + > +#define DSI_CLKMGR_CFG 0x08 > +#define TO_CLK_DIVIDSION(div)(((div) & 0xff) << 8) > +#define TX_ESC_CLK_DIVIDSION(div)(((div) & 0xff) << 0) > + > +#define DSI_DPI_VCID 0x0c > +#define DPI_VID(vid) (((vid) & 0x3) << 0) > + > +#define DSI_DPI_COLOR_CODING 0x10 > +#define EN18_LOOSELY BIT(8) > +#define DPI_COLOR_CODING_16BIT_1 0x0 > +#define DPI_COLOR_CODING_16BIT_2 0x1 > +#define DPI_COLOR_CODING_16BIT_3 0x2 > +#define DPI_COLOR_CODING_18BIT_1 0x3 > +#define DPI_COLOR_CODING_18BIT_2 0x4 > +#define DPI_COLOR_CODING_24BIT 0x5 > + > +#define DSI_DPI_CFG_POL 0x14 > +#define COLORM_ACTIVE_LOWBIT(4) > +#define SHUTD_ACTIVE_LOW BIT(3) > +#define HSYNC_ACTIVE_LOW BIT(2) > +#define VSYNC_ACTIVE_LOW BIT(1) > +#define DATAEN_ACTIVE_LOWBIT(0) > + > +#define DSI_DPI_LP_CMD_TIM 0x18 > +#define OUTVACT_LPCMD_TIME(p)(((p) & 0xff) << 16) > +#define INVACT_LPCMD_TIME(p) ((p) & 0xff) > + > +#define DSI_DBI_CFG 0x20 > +#define DSI_DBI_CMDSIZE 0x28 > + > +#define DSI_PCKHDL_CFG 0x2c > +#define EN_CRC_RXBIT(4) > +#define EN_ECC_RXBIT(3) > +#define EN_BTA BIT(2) > +#define EN_EOTP_RX BIT(1) > +#define EN_EOTP_TX BIT(0) > + > +#define DSI_MODE_CFG 0x34 > +#define ENABLE_VIDEO_MODE0 > +#define ENABLE_CMD_MODE BIT(0) > + > +#define DSI_VID_MODE_CFG 0x38 > +#define FRAME_BTA_ACKBIT(14) > +#define ENABLE_LO
Re: [PATCH v3 5/6] dt-bindings: display: stm32: Add DSI host driver
Hi Philippe, On 06/02/2017 04:37 PM, Philippe CORNU wrote: > This patch adds documentation of device tree bindings for the STM32 > DSI host driver based on the Synopsys DW MIPI DSI bridge driver. > --- > .../devicetree/bindings/display/st,stm32-ltdc.txt | 83 > +- > 1 file changed, 82 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > index 90a8459..4cd32bd 100644 > --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > @@ -12,8 +12,39 @@ >Required nodes: > - Video port for RGB output. > > -Example: > +* STMicroelectronics STM32 dsi specific extensions to Synopsys DesignWare > MIPI > + DSI host controller Why is "dsi" in low-case only here and below ? > > +The STMicroelectronics STM32 dsi driver uses the Synopsys DesignWare MIPI > +DSI host controller driver (related documentation in [5]). > + > +Required properties: > +- #address-cells: Should be <1>. > +- #size-cells: Should be <0>. > +- compatible: "st,stm32-dsi". > +- reg: Memory mapped base address and length of the DWC MIPI DSI registers. > +- clocks: References to all the clocks specified in the clock-names property > + as specified in [1]. > +- clock-names: > + - peripheral clock string name, must be "pclk". > + - phy pll reference clock string name, must be "ref". > +- resets: References to all the resets specified in the reset-names property > + as specified in [2]. > +- reset-names: string reset name, must be "apb". > + > +Required nodes: > +- dsi input port node: connected to the ltdc rgb output port, see [3] & [4]. > +- panel or bridge node: see [6]. > + > +Note: You can find more documentation > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > +[2] Documentation/devicetree/bindings/reset/reset.txt > +[3] Documentation/devicetree/bindings/media/video-interfaces.txt > +[4] Documentation/devicetree/bindings/graph.txt > +[5] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > +[6] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt > + > +Example 1: RGB panel > / { > ... > soc { > @@ -33,3 +64,53 @@ Example: > }; > }; > }; > + > +Example 2: DSI panel > + > +/ { > + ... > + soc { > + ... > + ltdc: display-controller@40016800 { > + compatible = "st,stm32-ltdc"; > + reg = <0x40016800 0x200>; > + interrupts = <88>, <89>; > + resets = <&rcc STM32F4_APB2_RESET(LTDC)>; > + clocks = <&rcc 1 CLK_LCD>; > + clock-names = "lcd"; > + > + port { > + ltdc_out_dsi: endpoint { > + remote-endpoint = <&dsi_in>; > + }; > + }; > + }; > + > + > + dsi: dsi@40016c00 { > + #address-cells = <1>; > + #size-cells = <0>; > + compatible = "st,stm32-dsi"; > + reg = <0x40016c00 0x800>; > + clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>; > + clock-names = "ref", "pclk"; > + resets = <&rcc STM32F4_APB2_RESET(DSI)>; > + reset-names = "apb"; > + > + port { > + dsi_in: endpoint { > + remote-endpoint = <; > + }; > + }; > + > + panel-dsi@0 { > + reg = <0>; /* dsi virtual channel (0..3) */ > + compatible = ...; > + enable-gpios = ...; > + > + }; > + > + }; > + > + }; > +}; > Apart from that : Reviewed-by: Neil Armstrong ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] dt-bindings: display: stm32: remove st-display-subsystem parent node requirement
Hi Philippe, On 06/02/2017 04:37 PM, Philippe CORNU wrote: > There is no need anymore to have a "st-display-subsystem" parent node > in the device tree for the ltdc. > > Signed-off-by: Philippe CORNU > --- > Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > index 8e14769..90a8459 100644 > --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > @@ -1,7 +1,6 @@ > * STMicroelectronics STM32 lcd-tft display controller > > - ltdc: lcd-tft display controller host > - must be a sub-node of st-display-subsystem Please fix alignment here. >Required properties: >- compatible: "st,stm32-ltdc" >- reg: Physical base address of the IP registers and length of memory > mapped region. > Apart from that : Reviewed-by: Neil Armstrong ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/6] dt-bindings: display: Add Synopsys DW MIPI DSI DRM bridge driver
On 06/02/2017 04:37 PM, Philippe CORNU wrote: > This patch adds documentation of device tree bindings for the > Synopsys DesignWare MIPI DSI host DRM bridge driver. > > Signed-off-by: Philippe CORNU > --- > .../bindings/display/bridge/dw_mipi_dsi.txt| 30 > ++ > 1 file changed, 30 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > > diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > new file mode 100644 > index 000..1d7c438 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > @@ -0,0 +1,30 @@ > +Synopsys DesignWare MIPI DSI host controller > + > + > +This document defines device tree properties for the Synopsys DesignWare MIPI > +DSI host controller. It doesn't constitue a device tree binding specification ---/\ I'm not sure about this one, and it's already here in the dw_hdmi.txt text. > +by itself but is meant to be referenced by platform-specific device tree > +bindings. > + > +When referenced from platform device tree bindings the properties defined in > +this document are defined as follows. The platform device tree bindings are > +responsible for defining whether each property is required or optional. > + > +- reg: Memory mapped base address and length of the DWC MIPI DSI > + registers. (mandatory) ---/\ Why do you specify the mandatory/optional here since it's written it's the responsibility of the platform bindings ? > + > +- clocks: References to all the clocks specified in the clock-names property > + as specified in [1]. (mandatory) > + > +- clock-names: "pclk" is peripheral clock for either AHB and APB. (mandatory) > + > +- resets: References to all the resets specified in the reset-names property > + as specified in [2]. (optional) > + > +- reset-names: string reset name, must be "apb" if used. (optional) > + > +- panel or bridge node: see [3]. (mandatory) > + > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > +[2] Documentation/devicetree/bindings/reset/reset.txt > +[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/etnaviv: populate GEM objects on cpu_prep
CPU prep is the point where we can reasonably return an error to userspace when something goes wrong while populating the object. If we leave the object unpopulated at this point, the allocation will happen in the fault handler when userspace accesses the object through the mmap space, where we don't have any other option than to OOM the system. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c index 98243ba..f6ac3f7 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c @@ -413,6 +413,16 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op, bool write = !!(op & ETNA_PREP_WRITE); int ret; + if (!etnaviv_obj->sgt) { + void *ret; + + mutex_lock(&etnaviv_obj->lock); + ret = etnaviv_gem_get_pages(etnaviv_obj); + mutex_unlock(&etnaviv_obj->lock); + if (IS_ERR(ret)) + return PTR_ERR(ret); + } + if (op & ETNA_PREP_NOSYNC) { if (!reservation_object_test_signaled_rcu(etnaviv_obj->resv, write)) @@ -427,16 +437,6 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op, } if (etnaviv_obj->flags & ETNA_BO_CACHED) { - if (!etnaviv_obj->sgt) { - void *ret; - - mutex_lock(&etnaviv_obj->lock); - ret = etnaviv_gem_get_pages(etnaviv_obj); - mutex_unlock(&etnaviv_obj->lock); - if (IS_ERR(ret)) - return PTR_ERR(ret); - } - dma_sync_sg_for_cpu(dev->dev, etnaviv_obj->sgt->sgl, etnaviv_obj->sgt->nents, etnaviv_op_to_dma_dir(op)); -- 2.9.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails
GPU buffers can be quite large, so userspace is expected to deal with allocation failure. Don't trigger the OOM killer when page allocation for the GEM objects fails, as this opens an easy possiblity for unprivileged applications to DOS the system,a s the shmem pages are not fully accounted to the allocating process. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c index f0efc5d..4c53508 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c @@ -662,7 +662,8 @@ static struct drm_gem_object *__etnaviv_gem_new(struct drm_device *dev, * going to pin these pages. */ mapping = obj->filp->f_mapping; - mapping_set_gfp_mask(mapping, GFP_HIGHUSER); + mapping_set_gfp_mask(mapping, GFP_HIGHUSER | +__GFP_NORETRY | __GFP_NOWARN); } if (ret) -- 2.9.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/etnaviv: reduce allocation failure message severity
The GPU userspace is expected to deal with failure to allocate memory for the GPU buffers, there is no need to spam the log on failure. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c index 4c53508..98243ba 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c @@ -68,7 +68,7 @@ static int etnaviv_gem_shmem_get_pages(struct etnaviv_gem_object *etnaviv_obj) struct page **p = drm_gem_get_pages(&etnaviv_obj->base); if (IS_ERR(p)) { - dev_err(dev->dev, "could not get pages: %ld\n", PTR_ERR(p)); + dev_dbg(dev->dev, "could not get pages: %ld\n", PTR_ERR(p)); return PTR_ERR(p); } -- 2.9.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101229] Global screen tearing (scrolling, Hz miss-match?)
https://bugs.freedesktop.org/show_bug.cgi?id=101229 --- Comment #12 from Michel Dänzer --- (In reply to Paul from comment #11) > Use the system and run OpenGL applications, Fullscreen or windowed? Does enabling any sync-to-vblank functionality in the apps or setting the environment variable vblank_mode=3 for running them help? > is there an option to enable triple-buffering or is it enabled by default? Automatically used with DRI3. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: exynos drm build failure due to cec_* symbols
On 05/06/17 10:59, Russell King - ARM Linux wrote: > On Mon, Jun 05, 2017 at 10:33:50AM +0900, Inki Dae wrote: >> 2017년 06월 02일 22:58에 Andreas Färber 이(가) 쓴 글: >>> Hello, >>> >>> We're observing the following build failure with v4.12-rc3, latest >>> linux.git and linux-next.git: >>> >>> [ 9825s] LD vmlinux.o >>> [ 9904s] MODPOST vmlinux.o >>> [ 9915s] drivers/built-in.o: In function `hdmi_get_modes': >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:866: >>> undefined reference to `cec_notifier_set_phys_addr_from_edid' >>> [ 9915s] drivers/built-in.o: In function `hdmi_remove': >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1923: >>> undefined reference to `cec_notifier_set_phys_addr' >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1927: >>> undefined reference to `cec_notifier_put' >>> [ 9915s] drivers/built-in.o: In function `hdmi_probe': >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1889: >>> undefined reference to `cec_notifier_get' >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1904: >>> undefined reference to `cec_notifier_put' >>> [ 9915s] drivers/built-in.o: In function `hdmi_disable': >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:1509: >>> undefined reference to `cec_notifier_set_phys_addr' >>> [ 9915s] drivers/built-in.o: In function `hdmi_detect': >>> [ 9915s] >>> /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/linux-obj/../drivers/gpu/drm/exynos/exynos_hdmi.c:827: >>> undefined reference to `cec_notifier_set_phys_addr' >>> [ 9931s] make[2]: *** >>> [/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/linux-4.12-rc3-51-ga374846/Makefile:997: >>> vmlinux] Error 1 >>> [ 9931s] make[1]: *** [Makefile:152: sub-make] Error 2 >>> [ 9931s] make: *** [Makefile:24: __sub-make] Error 2 >>> >>> My guess is the symbols used by the exynos drm module are not exported: >>> >>> cec_notifier_set_phys_addr_from_edid >>> cec_notifier_set_phys_addr >>> cec_notifier_put >>> cec_notifier_get >>> >>> Can you please look into fixing this? >> >> Thanks for reporting. >> >> Will check and fix it. > > Please look at Hans' update to the way CEC's dependencies are handled. > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec > > These are apparently scheduled for -rc, but Mauro is busy. They got merged in the media fixes tree, so with luck will appear in 4.12 soon. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel