[radeon-alex:amd-mainline-hybrid-4.11 103/518] drivers//pci/pci.c:2930:7: error: 'PCI_EXP_DEVCTL2_ATOMICOP_REQ' undeclared

[kbuild test robot]

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

[Deucher, Alexander]

> -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,
> );
> > +   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 

Re: [PATCH v2 00/11] Support for H3 Composite Output support

[icenowy]

在 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

[Brown, Aaron F]

> 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

[CK Hu]

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)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101325

--- Comment #2 from Luke  ---
Created attachment 131760
  --> https://bugs.freedesktop.org/attachment.cgi?id=131760=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)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101325

--- Comment #1 from Luke  ---
Created attachment 131759
  --> https://bugs.freedesktop.org/attachment.cgi?id=131759=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)

[bugzilla-daemon]

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=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

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

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 <rdun...@infradead.org>
---
 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

[Jeff Kirsher]

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

[Bjorn Helgaas]

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, );
> + 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

[Martin Peres]

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()

[Boris Brezillon]

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

[Boris Brezillon]

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(>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(>event_lock, flags);
> > -   for_each_crtc_in_state(state, crtc, crtc_state, i)
> > -   busy |= vc4_event_pending(crtc);
> > -   spin_unlock_irqrestore(>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.

[Eric Anholt]

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

[Eric Anholt]

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(>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(>event_lock, flags);
> - for_each_crtc_in_state(state, crtc, crtc_state, i)
> - busy |= vc4_event_pending(crtc);
> - spin_unlock_irqrestore(>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(>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()

[Eric Anholt]

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

[Maxime Ripard]

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);
> >> 

Re: [PATCH 5/7] drm/vc4: Add support for the TXP (transposer) block

[Boris Brezillon]

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 = _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);
> >+
> >+

[Bug 101319] Tonga DC + UVD [drm:fill_plane_attributes [amdgpu]] *ERROR* Unable to reserve buffer

[bugzilla-daemon]

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

[Eric Anholt]

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

[Eric Anholt]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[Liviu Dudau]

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 = >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.

[Liviu Dudau]

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.

[Thierry Reding]

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

[Maarten Lankhorst]

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.

[Sean Paul]

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.

[Maarten Lankhorst]

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

[Thierry Reding]

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

[Boris Brezillon]

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

[Alex Deucher]

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, );
> +   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 

Re: [PATCH v2 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]

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

[Boris Brezillon]

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

[Tomi Valkeinen]

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

[Tomi Valkeinen]

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 = <_out>;
>   };
>   };
>  
>   dsi_out: port@1 {
>   reg = <1>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
>   dsi_out_vc0: endpoint@0 {
>   reg = <0>;
>   remote-endpoint = <_panel0_in>;
>   };
> 
>   dsi_out_vc1: endpoint@1 {
>   reg = <1>;
>   remote-endpoint = <_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 = <_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 = <_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 = <_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

[Boris Brezillon]

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 = <_out>;
> > };
> > };
> > 
> > dsi_out0: port@1 {
> > reg = <1>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > dsi_out0: endpoint@0 {
> > remote-endpoint = <_panel0_in>;
> > };
> > };
> > 
> > dsi_out0: port@2 {
> > reg = <2>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > dsi_out1: endpoint@0 {
> > remote-endpoint = <_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 = <_out0>;
> > };
> > };
> > };
> > 
> > 

Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Tomi Valkeinen]

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 = <_out>;
>   };
>   };
> 
>   dsi_out0: port@1 {
>   reg = <1>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   dsi_out0: endpoint@0 {
>   remote-endpoint = <_panel0_in>;
>   };
>   };
> 
>   dsi_out0: port@2 {
>   reg = <2>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   dsi_out1: endpoint@0 {
>   remote-endpoint = <_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 = <_out0>;
>   };
>   };
>   };
> 
>   panel@1 {
>   compatible = "...";
>   reg = <1>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   port@0 {
>   #address-cells = <1>;
> 

Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

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

[Tomi Valkeinen]

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

[Christian König]

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, );
+   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 looking 

[PATCH] drm/atmel-hlcdc: Fix panel registration

[Boris Brezillon]

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

[Boris Brezillon]

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. */
> > +   

Re: [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.

[Archit Taneja]

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(>connector,
-   _hlcdc_panel_connector_helper_funcs);
-   ret = drm_connector_init(dev, >connector,
-_hlcdc_panel_connector_funcs,
-DRM_MODE_CONNECTOR_Unknown);
-   if (ret)
-   goto err_encoder_cleanup;
-
-   drm_mode_connector_attach_encoder(>connector,
- >encoder);
-
-   ret = drm_panel_attach(panel, >connector);
-   if (ret) {
-   drm_connector_cleanup(>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(>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(>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

[Philipp Zabel]

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

[Boris Brezillon]

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 = <_out>;
};
};

dsi_out0: port@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;

dsi_out0: endpoint@0 {
remote-endpoint = <_panel0_in>;
};
};

dsi_out0: port@2 {
reg = <2>;
#address-cells = <1>;
   

Re: [Intel-gfx] [PATCH] drm: Restore GNOME monitors.xml support

[Jani Nikula]

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(>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(>base, 
> file_priv->atomic,
> - (uint32_t __user *)(unsigned long)(out_resp->props_ptr),
> - (uint64_t __user *)(unsigned 
> long)(out_resp->prop_values_ptr),
> - _resp->count_props);
> - drm_modeset_unlock(>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,
>_mode, sizeof(u_mode))) {
>   ret = -EFAULT;
> + mutex_unlock(>mode_config.mutex);
>   goto out;
>   }
>   copied++;
>   }
>   }
>   out_resp->count_modes = mode_count;
> -out:
>   mutex_unlock(>mode_config.mutex);
> -out_unref:
> +
> + drm_modeset_lock(>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(>base, 
> file_priv->atomic,
> + (uint32_t __user *)(unsigned long)(out_resp->props_ptr),
> + (uint64_t __user *)(unsigned 
> long)(out_resp->prop_values_ptr),
> + _resp->count_props);
> + drm_modeset_unlock(>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.

[Boris Brezillon]

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(>connector,
> > -   _hlcdc_panel_connector_helper_funcs);
> > -   ret = drm_connector_init(dev, >connector,
> > -_hlcdc_panel_connector_funcs,
> > -DRM_MODE_CONNECTOR_Unknown);
> > -   if (ret)
> > -   goto err_encoder_cleanup;
> > -
> > -   drm_mode_connector_attach_encoder(>connector,
> > - >encoder);
> > -
> > -   ret = drm_panel_attach(panel, >connector);
> > -   if (ret) {
> > -   drm_connector_cleanup(>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(>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(>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

[Philipp Zabel]

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(>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(>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

[Neil Armstrong]

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, , np, remote);
>   }
>  
> + if (count && !match)
> + return meson_drv_bind_master(>dev, false);
> +
>   /* If some endpoints were found, initialize the nodes */
>   if (count) {
>   dev_info(>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

[Neil Armstrong]

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 

Re: [PATCH v3 3/6] drm/bridge/synopsys: Add MIPI DSI host controller bridge

[Neil Armstrong]

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_ACK  

Re: [PATCH v3 5/6] dt-bindings: display: stm32: Add DSI host driver

[Neil Armstrong]

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 = < STM32F4_APB2_RESET(LTDC)>;
> + clocks = < 1 CLK_LCD>;
> + clock-names = "lcd";
> +
> + port {
> + ltdc_out_dsi: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
> +
> + dsi: dsi@40016c00 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-dsi";
> + reg = <0x40016c00 0x800>;
> + clocks = < 1 CLK_F469_DSI>, <_hse>;
> + clock-names = "ref", "pclk";
> + resets = < STM32F4_APB2_RESET(DSI)>;
> + reset-names = "apb";
> +
> + port {
> + dsi_in: endpoint {
> + remote-endpoint = <_out_dsi>;
> + };
> + };
> +
> + 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

[Neil Armstrong]

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

[Neil Armstrong]

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

[Lucas Stach]

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(_obj->lock);
+   ret = etnaviv_gem_get_pages(etnaviv_obj);
+   mutex_unlock(_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(_obj->lock);
-   ret = etnaviv_gem_get_pages(etnaviv_obj);
-   mutex_unlock(_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

[Lucas Stach]

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

[Lucas Stach]

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(_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?)

[bugzilla-daemon]

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

[Hans Verkuil]

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