[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, ) == -22

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |knikk...@gmail.com
   |.org|

-- 
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: [Intel-gfx] [PATCH v1] i915: Re-use DEFINE_SHOW_ATTRIBUTE() macro

[Chris Wilson]

Quoting Andy Shevchenko (2018-02-14 15:41:57)
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
> 
> Signed-off-by: Andy Shevchenko 

Reviewed-by: Chris Wilson 

Note depends on rc1 backmerge.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #22 from arne_woer...@yahoo.com ---
(In reply to Alex Deucher from comment #20)
> Is it the firmware that caused the regression?  Does everything work with
> the old firmware?

i did the following experiments:

1.
via kernel parameters in grub.cfg i changed
amdgpu.dc from -1 to 1
amdgpu.msi from -1 to 0
amdgpu.audio from -1 to 0.
i installed version 20180119.2a713be-2 of linux-firmware.
result:
during the second suspend the screen went black (no signal) and the following
thaw produced the slow box syndrome...

2.
via kernel parameters in grub.cfg i changed
amdgpu.dc from -1 to 1
and left amdgpu.msi and amdgpu.audio untouched.
i installed version 20180119.2a713be-2 of linux-firmware.
and version 20180104.65b1c68-1 of /usr/lib/firmware/amdgpu/polaris12_uvd.bin
(package linux-firmware).
now it works three times in a row...
the 3rd time there even was a running mplayer, that uses HDMI Audio... :)

what is that new polaris12_uvd.bin good for?

-arne

-- 
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 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > On 2018-02-14 03:08 PM, Sean Paul wrote:
> > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> > >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> > >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> >  Fix a deadlock on hybrid graphics laptops that's been present since 
> >  2013:
> > >>> This series has been reviewed, consent has been expressed by the most
> > >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> > >>> has been acked and I've just out a v2 addressing the only objection
> > >>> raised.  My plan is thus to wait another two days for comments and,
> > >>> barring further objections, push to drm-misc this weekend.
> > >>>
> > >>> However I'm struggling with the decision whether to push to next or
> > >>> fixes.  The series is marked for stable, however the number of
> > >>> affected machines is limited and for an issue that's been present
> > >>> for 5 years it probably doesn't matter if it soaks another two months
> > >>> in linux-next befor it gets backported.  Hence I tend to err on the
> > >>> side of caution and push to next, however a case could be made that
> > >>> fixes is more appropriate.
> > >>>
> > >>> I'm lacking experience making such decisions and would be interested
> > >>> to learn how you'd handle this.
> > >>
> > >> I would say fixes, it doesn't look particularly scary. :)
> > > 
> > > Agreed. If it's good enough for stable, it's good enough for -fixes!
> > 
> > It's not that simple, is it? Fast-tracking patches (some of which appear
> > to be untested) to stable without an immediate cause for urgency seems
> > risky to me.
> 
> /me should be more careful what he says
> 
> Given where we are in the release cycle, it's barely a fast track.
> If these go in -fixes, they'll get in -rc2 and will have plenty of
> time to bake. If we were at rc5, it might be a different story.

The patches are marked for stable though, so if they go in through
drm-misc-fixes, they may appear in stable kernels before 4.16-final
is out.  Greg picks up patches once they're in Linus' tree, though
often with a delay of a few days or weeks.  If they go in through
drm-misc-next, they're guaranteed not to appear in *any* release
before 4.16-final is out.

This allows for differentiation between no-brainer stable fixes that
can be sent immediately and scarier, but similarly important stable
fixes that should soak for a while.  I'm not sure which category
this series belongs to, though it's true what Maarten says, it's
not *that* grave a change.

Thanks,

Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Thu, Feb 15, 2018 at 12:17 PM, Tomasz Figa  wrote:
> On Thu, Feb 15, 2018 at 1:03 AM, Robin Murphy  wrote:
>> On 14/02/18 10:33, Vivek Gautam wrote:
>>>
>>> On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa  wrote:
>>>
>>> Adding Jordan to this thread as well.
>>>
 On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
  wrote:
>
> Hi Tomasz,
>
> On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa 
> wrote:
>>
>> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
>>  wrote:
>>>
>>> Hi Tomasz,
>>>
>>> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa 
>>> wrote:

 On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark 
 wrote:
>
> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa 
> wrote:
>>
>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark 
>> wrote:
>>>
>>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa 
>>> wrote:

 Hi Vivek,

 Thanks for the patch. Please see my comments inline.

 On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
  wrote:
>
> While handling the concerned iommu, there should not be a
> need to power control the drm devices from iommu interface.
> If these drm devices need to be powered around this time,
> the respective drivers should take care of this.
>
> Replace the pm_runtime_get/put_sync() with
> pm_runtime_get/put_suppliers() calls, to power-up
> the connected iommu through the device link interface.
> In case the device link is not setup these get/put_suppliers()
> calls will be a no-op, and the iommu driver should take care of
> powering on its devices accordingly.
>
> Signed-off-by: Vivek Gautam 
> ---
>   drivers/gpu/drm/msm/msm_iommu.c | 16 
>   1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c
> b/drivers/gpu/drm/msm/msm_iommu.c
> index b23d33622f37..1ab629bbee69 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu
> *mmu, const char * const *names,
>  struct msm_iommu *iommu = to_msm_iommu(mmu);
>  int ret;
>
> -   pm_runtime_get_sync(mmu->dev);
> +   pm_runtime_get_suppliers(mmu->dev);
>  ret = iommu_attach_device(iommu->domain, mmu->dev);
> -   pm_runtime_put_sync(mmu->dev);
> +   pm_runtime_put_suppliers(mmu->dev);


 For me, it looks like a wrong place to handle runtime PM of IOMMU
 here. iommu_attach_device() calls into IOMMU driver's
 attach_device()
 callback and that's where necessary runtime PM gets should
 happen, if
 any. In other words, driver A (MSM DRM driver) shouldn't be
 dealing
 with power state of device controlled by driver B (ARM SMMU).
>>>
>>>
>>> Note that we end up having to do the same, because of
>>> iommu_unmap()
>>> while DRM driver is powered off..  it might be cleaner if it was
>>> all
>>> self contained in the iommu driver, but that would make it so
>>> other
>>> drivers couldn't call iommu_unmap() from an irq handler, which is
>>> apparently something that some of them want to do..
>>
>>
>> I'd assume that runtime PM status is already guaranteed to be
>> active
>> when the IRQ handler is running, by some other means (e.g.
>> pm_runtime_get_sync() called earlier, when queuing some work to the
>> hardware). Otherwise, I'm not sure how a powered down device could
>> trigger an IRQ.
>>
>> So, if the master device power is already on, suppliers should be
>> powered on as well, thanks to device links.
>>
>
> umm, that is kindof the inverse of the problem..  the problem is
> things like gpu driver (and v4l2 drivers that import dma-buf's,
> afaict).. they will potentially call iommu->unmap() when device is
> not
> active (due to userspace or things beyond the control of the
> driver)..
> so *they* would want iommu to do pm get/put 

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Thu, Feb 15, 2018 at 1:12 AM, Rob Clark  wrote:
> On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse  
> wrote:
>> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
>>>
>>> - When submitting commands to the GPU, the GPU driver will
>>> pm_runtime_get_sync() on the GPU device, which will automatically do
>>> the same on all the linked suppliers, which would also include the
>>> SMMU itself. The role of device links here is exactly that the GPU
>>> driver doesn't have to care which other devices need to be brought up.
>>
>> This is true.  Assuming that the device link works correctly we would not 
>> need
>> to explicitly power the SMMU which makes my point entirely moot.
>
> Just to point out what motivated this patchset, the biggest problem is
> iommu_unmap() because that can happen when GPU is not powered on (or
> in the v4l2 case, because some other device dropped it's reference to
> the dma-buf allowing it to be free'd).  Currently we pm get/put the
> GPU device around unmap, but it is kinda silly to boot up the GPU just
> to unmap a buffer.

Note that in V4L2 both mapping and unmapping can happen completely
without involving the driver. So AFAICT the approach being implemented
by this patchset will not work, because there will be no one to power
up the IOMMU before the operation. Moreover, there are platforms for
which there is no reason to power up the IOMMU just for map/unmap,
because the hardware state is lost anyway and the only real work
needed is updating the page tables in memory. (I feel like this is
actually true for most of the platforms in the wild, but this is based
purely on the not so small number of platforms I worked with, haven't
bothered looking for more general evidence.)

>
> (Semi-related, I would also like to batch map/unmap's, I just haven't
> gotten around to implementing it yet.. but that would be another case
> where a single get_supplier()/put_supplier() outside of the iommu
> would make sense instead of pm_get/put() inside the iommu driver's
> ->unmap().)
>
> If you really dislike the get/put_supplier() approach, then perhaps we
> need iommu_pm_get()/iommu_pm_put() operations that the iommu user
> could use to accomplish the same thing?

I'm afraid this wouldn't work for V4L2 either. And I still haven't
been given any evidence that the approach I'm suggesting, which relies
only on existing pieces of infrastructure and which worked for both
Exynos and Rockchip, including V4L2, wouldn't work for SMMU and/or QC
SoCs.

Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Thu, Feb 15, 2018 at 1:03 AM, Robin Murphy  wrote:
> On 14/02/18 10:33, Vivek Gautam wrote:
>>
>> On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa  wrote:
>>
>> Adding Jordan to this thread as well.
>>
>>> On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
>>>  wrote:

 Hi Tomasz,

 On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa 
 wrote:
>
> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
>  wrote:
>>
>> Hi Tomasz,
>>
>> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa 
>> wrote:
>>>
>>> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark 
>>> wrote:

 On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa 
 wrote:
>
> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark 
> wrote:
>>
>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa 
>> wrote:
>>>
>>> Hi Vivek,
>>>
>>> Thanks for the patch. Please see my comments inline.
>>>
>>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>>>  wrote:

 While handling the concerned iommu, there should not be a
 need to power control the drm devices from iommu interface.
 If these drm devices need to be powered around this time,
 the respective drivers should take care of this.

 Replace the pm_runtime_get/put_sync() with
 pm_runtime_get/put_suppliers() calls, to power-up
 the connected iommu through the device link interface.
 In case the device link is not setup these get/put_suppliers()
 calls will be a no-op, and the iommu driver should take care of
 powering on its devices accordingly.

 Signed-off-by: Vivek Gautam 
 ---
   drivers/gpu/drm/msm/msm_iommu.c | 16 
   1 file changed, 8 insertions(+), 8 deletions(-)

 diff --git a/drivers/gpu/drm/msm/msm_iommu.c
 b/drivers/gpu/drm/msm/msm_iommu.c
 index b23d33622f37..1ab629bbee69 100644
 --- a/drivers/gpu/drm/msm/msm_iommu.c
 +++ b/drivers/gpu/drm/msm/msm_iommu.c
 @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu
 *mmu, const char * const *names,
  struct msm_iommu *iommu = to_msm_iommu(mmu);
  int ret;

 -   pm_runtime_get_sync(mmu->dev);
 +   pm_runtime_get_suppliers(mmu->dev);
  ret = iommu_attach_device(iommu->domain, mmu->dev);
 -   pm_runtime_put_sync(mmu->dev);
 +   pm_runtime_put_suppliers(mmu->dev);
>>>
>>>
>>> For me, it looks like a wrong place to handle runtime PM of IOMMU
>>> here. iommu_attach_device() calls into IOMMU driver's
>>> attach_device()
>>> callback and that's where necessary runtime PM gets should
>>> happen, if
>>> any. In other words, driver A (MSM DRM driver) shouldn't be
>>> dealing
>>> with power state of device controlled by driver B (ARM SMMU).
>>
>>
>> Note that we end up having to do the same, because of
>> iommu_unmap()
>> while DRM driver is powered off..  it might be cleaner if it was
>> all
>> self contained in the iommu driver, but that would make it so
>> other
>> drivers couldn't call iommu_unmap() from an irq handler, which is
>> apparently something that some of them want to do..
>
>
> I'd assume that runtime PM status is already guaranteed to be
> active
> when the IRQ handler is running, by some other means (e.g.
> pm_runtime_get_sync() called earlier, when queuing some work to the
> hardware). Otherwise, I'm not sure how a powered down device could
> trigger an IRQ.
>
> So, if the master device power is already on, suppliers should be
> powered on as well, thanks to device links.
>

 umm, that is kindof the inverse of the problem..  the problem is
 things like gpu driver (and v4l2 drivers that import dma-buf's,
 afaict).. they will potentially call iommu->unmap() when device is
 not
 active (due to userspace or things beyond the control of the
 driver)..
 so *they* would want iommu to do pm get/put calls.
>>>
>>>
>>> Which is fine and which is actually already done by one of the
>>> patches
>>> in this series, not for map/unmap, but probe, add_device,
>>> 

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Here goes drm-intel-fixes-2018-02-14-1:

There are important fixes for VLV with MIPI/DSI panels,
2 clean-up patches needed for this MIPI/DSI fix,
and many fixes for GEM including fixes for Perf OA and PMU,
and fixes on scheduler and preemption.

This also includes GVT fixes: "This has one to fix GTT mmio 8b
access from guest and two simple ones for mmio switch and typo fix"

Thanks,
Rodrigo.

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-02-14-1

for you to fetch changes up to ee622fe757f6de612dad0f01805eea815a5b3025:

  drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence 
v3 (2018-02-14 11:43:31 -0800)


There are important fixes for VLV with MIPI/DSI panels,
2 clean-up patches needed for this MIPI/DSI fix,
and many fixes for GEM including fixes for Perf OA and PMU,
and fixes on scheduler and preemption.

This also includes GVT fixes: "This has one to fix GTT mmio 8b
access from guest and two simple ones for mmio switch and typo fix"


Chris Wilson (7):
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915: Avoid truncation before clamping userspace's priority value
  drm/i915: Don't wake the device up to check if the engine is asleep
  drm/i915/breadcrumbs: Ignore unsubmitted signalers
  drm/i915: Lock out execlist tasklet while peeking inside for busy-stats
  drm/i915/pmu: Fix building without CONFIG_PM

Hans de Goede (4):
  drm/i915/vlv: Add cdclk workaround for DSI
  drm/i915: Add intel_bios_cleanup() function
  drm/i915: Free memdup-ed DSI VBT data structures on driver_unload
  drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT 
sequence v3

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-02-14' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Tina Zhang (1):
  drm/i915/gvt: Support BAR0 8-byte reads/writes

Tvrtko Ursulin (2):
  drm/i915/pmu: Fix PMU enable vs execlists tasklet race
  drm/i915/pmu: Fix sleep under atomic in RC6 readout

Weinan Li (2):
  drm/i915/gvt: add 0xe4f0 into gen9 render list
  drm/i915/gvt: fix one typo of render_mmio trace

 drivers/gpu/drm/i915/gvt/kvmgt.c |  51 ++-
 drivers/gpu/drm/i915/gvt/mmio_context.c  |   1 +
 drivers/gpu/drm/i915/gvt/trace.h |   2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  14 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_gem_context.c  |   2 +-
 drivers/gpu/drm/i915/i915_oa_cflgt3.c|   4 +-
 drivers/gpu/drm/i915/i915_oa_cnl.c   |   4 +-
 drivers/gpu/drm/i915/i915_pmu.c  | 231 +++
 drivers/gpu/drm/i915/i915_pmu.h  |   6 +
 drivers/gpu/drm/i915/intel_bios.c| 105 ++
 drivers/gpu/drm/i915/intel_breadcrumbs.c |  29 ++--
 drivers/gpu/drm/i915/intel_cdclk.c   |   8 ++
 drivers/gpu/drm/i915/intel_engine_cs.c   |  24 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  14 --
 15 files changed, 346 insertions(+), 151 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

[Rodrigo Vivi]

Let's sync CNL ids with Spec and kernel.

Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
Add Cannonlake PCI IDs for another SKU.")' and
commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'

Cc: James Ausmus 
Cc: Lucas De Marchi 
Cc: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
---
 intel/intel_chipset.h | 52 +++
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 3818e71e..01d250e8 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -241,16 +241,20 @@
 #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
 #define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
 
-#define PCI_CHIP_CANNONLAKE_U_GT2_00x5A52
-#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
-#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
-#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
-#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
-#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
-#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
-#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
-#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
-#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
+#define PCI_CHIP_CANNONLAKE_0  0x5A51
+#define PCI_CHIP_CANNONLAKE_1  0x5A59
+#define PCI_CHIP_CANNONLAKE_2  0x5A41
+#define PCI_CHIP_CANNONLAKE_3  0x5A49
+#define PCI_CHIP_CANNONLAKE_4  0x5A52
+#define PCI_CHIP_CANNONLAKE_5  0x5A5A
+#define PCI_CHIP_CANNONLAKE_6  0x5A42
+#define PCI_CHIP_CANNONLAKE_7  0x5A4A
+#define PCI_CHIP_CANNONLAKE_8  0x5A50
+#define PCI_CHIP_CANNONLAKE_9  0x5A40
+#define PCI_CHIP_CANNONLAKE_10 0x5A54
+#define PCI_CHIP_CANNONLAKE_11 0x5A5C
+#define PCI_CHIP_CANNONLAKE_12 0x5A44
+#define PCI_CHIP_CANNONLAKE_13 0x5A4C
 
 #define IS_MOBILE(devid)   ((devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I915_GM || \
@@ -515,20 +519,20 @@
 IS_GEMINILAKE(devid) || \
 IS_COFFEELAKE(devid))
 
-#define IS_CNL_Y(devid)((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 
|| \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
-
-#define IS_CNL_U(devid)((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
|| \
-(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
-(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
-(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
-
-#define IS_CANNONLAKE(devid)   (IS_CNL_U(devid) || \
-IS_CNL_Y(devid))
+#define IS_CANNONLAKE(devid)   ((devid) == PCI_CHIP_CANNONLAKE_0 || \
+(devid) == PCI_CHIP_CANNONLAKE_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_3 || \
+(devid) == PCI_CHIP_CANNONLAKE_4 || \
+(devid) == PCI_CHIP_CANNONLAKE_5 || \
+(devid) == PCI_CHIP_CANNONLAKE_6 || \
+(devid) == PCI_CHIP_CANNONLAKE_7 || \
+(devid) == PCI_CHIP_CANNONLAKE_8 || \
+(devid) == PCI_CHIP_CANNONLAKE_9 || \
+(devid) == PCI_CHIP_CANNONLAKE_10 || \
+(devid) == PCI_CHIP_CANNONLAKE_11 || \
+(devid) == PCI_CHIP_CANNONLAKE_12 || \
+(devid) == PCI_CHIP_CANNONLAKE_13)
 
 #define IS_GEN10(devid)(IS_CANNONLAKE(devid))
 
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Dongwon Kim]

Abandoning this series as a new version was submitted for the review

"[RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver"

On Tue, Dec 19, 2017 at 11:29:17AM -0800, Kim, Dongwon wrote:
> Upload of intial version of hyper_DMABUF driver enabling
> DMA_BUF exchange between two different VMs in virtualized
> platform based on hypervisor such as KVM or XEN.
> 
> Hyper_DMABUF drv's primary role is to import a DMA_BUF
> from originator then re-export it to another Linux VM
> so that it can be mapped and accessed by it.
> 
> The functionality of this driver highly depends on
> Hypervisor's native page sharing mechanism and inter-VM
> communication support.
> 
> This driver has two layers, one is main hyper_DMABUF
> framework for scatter-gather list management that handles
> actual import and export of DMA_BUF. Lower layer is about
> actual memory sharing and communication between two VMs,
> which is hypervisor-specific interface.
> 
> This driver is initially designed to enable DMA_BUF
> sharing across VMs in Xen environment, so currently working
> with Xen only.
> 
> This also adds Kernel configuration for hyper_DMABUF drv
> under Device Drivers->Xen driver support->hyper_dmabuf
> options.
> 
> To give some brief information about each source file,
> 
> hyper_dmabuf/hyper_dmabuf_conf.h
> : configuration info
> 
> hyper_dmabuf/hyper_dmabuf_drv.c
> : driver interface and initialization
> 
> hyper_dmabuf/hyper_dmabuf_imp.c
> : scatter-gather list generation and management. DMA_BUF
> ops for DMA_BUF reconstructed from hyper_DMABUF
> 
> hyper_dmabuf/hyper_dmabuf_ioctl.c
> : IOCTLs calls for export/import and comm channel creation
> unexport.
> 
> hyper_dmabuf/hyper_dmabuf_list.c
> : Database (linked-list) for exported and imported
> hyper_DMABUF
> 
> hyper_dmabuf/hyper_dmabuf_msg.c
> : creation and management of messages between exporter and
> importer
> 
> hyper_dmabuf/xen/hyper_dmabuf_xen_comm.c
> : comm ch management and ISRs for incoming messages.
> 
> hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.c
> : Database (linked-list) for keeping information about
> existing comm channels among VMs
> 
> Signed-off-by: Dongwon Kim 
> Signed-off-by: Mateusz Polrola 
> ---
>  drivers/xen/Kconfig|   2 +
>  drivers/xen/Makefile   |   1 +
>  drivers/xen/hyper_dmabuf/Kconfig   |  14 +
>  drivers/xen/hyper_dmabuf/Makefile  |  34 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_conf.h   |   2 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.c|  54 ++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.h| 101 +++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.c| 852 
> +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.h|  31 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c  | 462 +++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_list.c   | 119 +++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_list.h   |  40 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.c| 212 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.h|  45 ++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_query.h  |  16 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_struct.h |  70 ++
>  .../xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.c   | 328 
>  .../xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.h   |  62 ++
>  .../hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.c  | 106 +++
>  .../hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.h  |  35 +
>  20 files changed, 2586 insertions(+)
>  create mode 100644 drivers/xen/hyper_dmabuf/Kconfig
>  create mode 100644 drivers/xen/hyper_dmabuf/Makefile
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_conf.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_list.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_list.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_query.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_struct.h
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.c
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.h
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.c
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.h
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d8dd546..b59b0e3 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -321,4 +321,6 @@ config XEN_SYMS
>  config 

Re: [PATCH v2 3/3] drm: rcar-du: lvds: Refactor LVDS startup

[Laurent Pinchart]

Hi Sergei,

On Wednesday, 14 February 2018 20:39:59 EET Sergei Shtylyov wrote:
> On 02/14/2018 09:13 PM, Laurent Pinchart wrote:
> > From: Sergei Shtylyov 
> > 
> > After the recent corrections to the R-Car gen2/3 LVDS startup code,
> > already similar enough at their ends rcar_lvds_enable_gen{2|3}() started
> > asking for a merge and it's becoming actually necessary with the addition
> > of the R-Car V3M (R8A77970) support -- this gen3 SoC has gen2-like
> > LVDPLLCR layout.
> > 
> > Signed-off-by: Sergei Shtylyov 
> > Reviewed-by: Laurent Pinchart 
> > Tested-by: Laurent Pinchart 
> 
> Well, your role wasn't limited to reviewning/testing, you'd clearly did
> some editing too... thus I was expecting to see some changelog.

My bad, it was an oversight. I'll add the following.

[Set the LVDS mode and input before turning channels on]
[Rebased, coding style changes]

> > Signed-off-by: Laurent Pinchart
> > 
> 
> Your variant of my patch looks good otherwise. :-)

Thank you :-) I've queued it in my tree.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 10/12] ARM: dts: r8a7794: Convert to new DU DT bindings

[Laurent Pinchart]

The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7794.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 5643976c1356..cccdada9e4a4 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -992,7 +992,6 @@
du: display@feb0 {
compatible = "renesas,du-r8a7794";
reg = <0 0xfeb0 0 0x4>;
-   reg-names = "du";
interrupts = ,
 ;
clocks = < CPG_MOD 724>, < CPG_MOD 723>;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 07/12] ARM: dts: r8a7791: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Fixed LVDS compatible string

Changes since v1:

- Remove the DU reg-names property
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 10 --
 arch/arm/boot/dts/r8a7791-porter.dts  | 16 +---
 arch/arm/boot/dts/r8a7791.dtsi| 34 --
 3 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index e164eda69baf..5a0f87ed7f16 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -332,8 +332,7 @@
 
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -341,6 +340,13 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
port@1 {
lvds_connector: endpoint {
};
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index 9a02d03b23c2..e6d02839d636 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -419,10 +419,9 @@
pinctrl-names = "default";
status = "okay";
 
-   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -433,6 +432,17 @@
};
 };
 
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds_connector: endpoint {
+   };
+   };
+   };
+};
+
 _sound {
pinctrl-0 = <_pins _clk_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 67831d0405f3..aef34c80c584 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1103,15 +1103,12 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7791";
-   reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x4>;
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
-   clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+   clock-names = "du.0", "du.1";
status = "disabled";
 
ports {
@@ -1126,6 +1123,31 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7791-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 09/12] ARM: dts: r8a7793: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Fixed LVDS compatible string

Changes since v1:

- Remove the DU reg-names property
---
 arch/arm/boot/dts/r8a7793-gose.dts | 10 +++---
 arch/arm/boot/dts/r8a7793.dtsi | 34 --
 2 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 51b3ffac8efa..c6121f9b72a8 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -303,10 +303,9 @@
pinctrl-names = "default";
status = "okay";
 
-   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -314,6 +313,11 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   ports {
port@1 {
lvds_connector: endpoint {
};
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 0cd1035de1a4..3a4918dfc1d9 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -976,15 +976,12 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7793";
-   reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x4>;
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
-   clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+   clock-names = "du.0", "du.1";
status = "disabled";
 
ports {
@@ -999,6 +996,31 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7793-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 11/12] arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Fixed LVDS compatible string

Changes since v1:

- Remove the DU reg-names property
---
 .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|  3 +-
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  3 +-
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 34 ++
 5 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
index 9ef9a4e5f376..0dda1c0ed1ce 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 0afe777973de..f0d6528c05eb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -44,11 +44,10 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 < 3>,
 < 4>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 00ad1ab53a7d..e34b986185d4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index 79e8b65622db..31f2abaa90aa 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 15ef292a8d9f..d67ad6d3d67f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2077,9 +2077,7 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -2087,9 +2085,8 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0  0  0  1>;
status = "disabled";
 
@@ -2117,6 +2114,31 @@
port@3 {
reg = <3>;
du_out_lvds0: endpoint {
+  

[PATCH v3 06/12] ARM: dts: r8a7790: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Fixed LVDS compatible string

Changes since v1:

- Remove the DU reg-names property
---
 arch/arm/boot/dts/r8a7790-lager.dts | 22 ++
 arch/arm/boot/dts/r8a7790.dtsi  | 60 -
 2 files changed, 70 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 7d5cd01069a3..f84963cb6785 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -317,10 +317,8 @@
status = "okay";
 
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
-< CPG_MOD 726>, < CPG_MOD 725>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "du.2", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -328,12 +326,26 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
port@1 {
endpoint {
remote-endpoint = <_in>;
};
};
-   port@2 {
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
lvds_connector: endpoint {
};
};
@@ -689,7 +701,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out_lvds0>;
+   remote-endpoint = <_out>;
};
};
 
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 62baabd757b6..450951ff25eb 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1067,17 +1067,13 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7790";
-   reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x1c>,
- <0 0xfeb94000 0 0x1c>;
-   reg-names = "du", "lvds.0", "lvds.1";
+   reg = <0 0xfeb0 0 0x7>;
interrupts = ,
 ,
 ;
clocks = < CPG_MOD 724>, < CPG_MOD 723>,
-< CPG_MOD 722>, < CPG_MOD 726>,
-< CPG_MOD 725>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1";
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
status = "disabled";
 
ports {
@@ -1092,11 +1088,61 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
};
};
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
+
+   lvds1: lvds@feb94000 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb94000 0 0x1c>;
+   clocks = < CPG_MOD 725>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds1_in: endpoint {
+   remote-endpoint = <_out_lvds1>;
+   

[PATCH v3 05/12] ARM: dts: porter: Fix HDMI output routing

[Laurent Pinchart]

The HDMI encoder is connected to the RGB output of the DU, which is
port@0, not port@1. Fix the incorrect DT description.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index eb374956294f..9a02d03b23c2 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -425,7 +425,7 @@
  "dclkin.0", "dclkin.1";
 
ports {
-   port@1 {
+   port@0 {
endpoint {
remote-endpoint = <_in>;
};
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 12/12] arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Fixed LVDS compatible string

Changes since v1:

- Remove the DU reg-names property
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 34 ++
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  7 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  3 --
 drivers/gpu/drm/rcar-du/rcar_du_group.c| 13 -
 6 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index daee1f1a3f68..21bd679062f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -33,10 +33,9 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 727>,
 < 1>,
 < 3>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2",
  "dclkin.0", "dclkin.1", "dclkin.2";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 4088bea8d62c..ecbfbcb65df3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -32,11 +32,10 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2",
  "dclkin.0", "dclkin.1", "dclkin.2";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f2b2e40c655e..86f4bead3c0b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1826,17 +1826,14 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7796";
-   reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x7>;
interrupts = ,
 ,
 ;
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
-< CPG_MOD 722>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0";
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
status = "disabled";
 
vsps = <  >;
@@ -1859,6 +1856,31 @@
port@2 {
reg = <2>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7796-lvds";
+   reg = <0 0xfeb9 0 0x14>;
+   clocks = < CPG_MOD 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index c4420538ec85..c296db68eddb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -321,12 +321,6 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,
struct rcar_du_device *rcdu = rcrtc->group->dev;
 
/*
-* Store the route from the CRTC output to the DU output. The DU will be
-* 

[PATCH v3 08/12] ARM: dts: r8a7792: Convert to new DU DT bindings

[Laurent Pinchart]

The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7792.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 3d080e07374c..d40325466aa8 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -678,7 +678,6 @@
du: display@feb0 {
compatible = "renesas,du-r8a7792";
reg = <0 0xfeb0 0 0x4>;
-   reg-names = "du";
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 02/12] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
Changes since v1:

- Remove the LVDS reg range from the example
- Remove the reg-names property
---
 .../devicetree/bindings/display/renesas,du.txt | 31 --
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index cd48aba3bc8c..e79cf9b0ad38 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -14,12 +14,7 @@ Required Properties:
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
 
-  - reg: A list of base address and length of each memory resource, one for
-each entry in the reg-names property.
-  - reg-names: Name of the memory resources. The DU requires one memory
-resource for the DU core (named "du") and one memory resource for each
-LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
-index).
+  - reg: the memory-mapped I/O registers base address and length
 
   - interrupt-parent: phandle of the parent interrupt controller.
   - interrupts: Interrupt specifiers for the DU interrupts.
@@ -29,14 +24,13 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- All other DU instances use one functional clock per channel and one
-  clock per LVDS encoder (if available). The functional clocks must be
-  named "du.x" with "x" being the channel numerical index. The LVDS clocks
-  must be named "lvds.x" with "x" being the LVDS encoder numerical index.
-- In addition to the functional and encoder clocks, all DU versions also
-  support externally supplied pixel clocks. Those clocks are optional.
-  When supplied they must be named "dclkin.x" with "x" being the input
-  clock numerical index.
+- All other DU instances use one functional clock per channel The
+  functional clocks must be named "du.x" with "x" being the channel
+  numerical index.
+- In addition to the functional clocks, all DU versions also support
+  externally supplied pixel clocks. Those clocks are optional. When
+  supplied they must be named "dclkin.x" with "x" being the input clock
+  numerical index.
 
   - vsps: A list of phandle and channel index tuples to the VSPs that handle
 the memory interfaces for the DU channels. The phandle identifies the VSP
@@ -69,9 +63,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -79,9 +71,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0>, < 0>, < 0>, < 1>;
 
ports {
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 04/12] drm: rcar-du: Convert LVDS encoder code to bridge driver

[Laurent Pinchart]

The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched live to move to the new bindings.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig   |   4 +-
 drivers/gpu/drm/rcar-du/Makefile  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  93 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  64 
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 524 ++
 12 files changed, 561 insertions(+), 616 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 3f83352a7313..edde8d4b87a3 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
  Enable support for R-Car Gen3 internal HDMI encoder.
 
 config DRM_RCAR_LVDS
-   bool "R-Car DU LVDS Encoder Support"
-   depends on DRM_RCAR_DU
+   tristate "R-Car DU LVDS Encoder Support"
+   depends on DRM && DRM_BRIDGE && OF
select DRM_PANEL
select OF_FLATTREE
select OF_OVERLAY
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 86b337b4be5d..3e58ed93d5b1 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
 rcar_du_plane.o
 
-rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
   rcar_du_of_lvds_r8a7790.dtb.o \
   rcar_du_of_lvds_r8a7791.dtb.o \
@@ -18,3 +16,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
+obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..06a3fbdd728a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -29,6 +29,7 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
+#include "rcar_du_of.h"
 #include "rcar_du_regs.h"
 
 /* 
-
@@ -74,7 +75,6 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info 
= {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -95,14 +95,13 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/*
@@ -164,7 +163,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -186,7 +184,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -434,7 +431,19 @@ static struct platform_driver rcar_du_platform_driver = {
},
 };
 
-module_platform_driver(rcar_du_platform_driver);
+static int __init rcar_du_init(void)
+{
+   

[PATCH v3 01/12] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
Changes since v1:

- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- Fixed "renesas,r8a7743-lvds" description
- Document the resets property
- Fixed typo
---
 .../bindings/display/bridge/renesas,lvds.txt   | 56 ++
 MAINTAINERS|  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..2b19ce51ec07
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,56 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
+Gen2, R-Car Gen3 and RZ/G SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+  - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
+  - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
+  - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+  - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS encoders
+  - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
+  - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+- resets: A phandle + reset specifier for the module reset
+
+Required nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel RGB input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   resets = < 726>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 5bc088f27c83..5b0c14f4209b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4723,6 +4723,7 @@ F:drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
 F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 00/12] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hello,

This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.

To fix the, patches 01/12 and 02/12 define new DT bindings for the LVDS
encoders, and deprecate their description inside the DU bindings. To retain
backward compatibility with existing DT, patch 03/12 then patches the device
tree at runtime to convert the legacy bindings to the new ones.

With the DT side addressed, patch 04/12 then converts the LVDS support code to
a separate bridge driver. After a small fix to the Porter board device tree in
patch 05/12, patches 06/12 to 12/12 then update all the device tree sources to
the new DU and LVDS encoders bindings.

I decided to go for live DT patching in patch 03/12 because implementing
support for both the legacy and new bindings in the driver would have been
very intrusive, and prevented further cleanups. This version relies more
heavily on overlays to avoid touching the internals of the OF core compared to
v2, even if manual fixes to the device tree are still needed.

There were a few shortcomings in the OF API that I worked around with local
code in the driver. If anyone is interested in performing similar live DT
patching I think we could move some of the code to the OF core. I'm thinking
in particular about the rcar_du_of_find_node_by_path() function that resembles
of_find_node_by_path() but with a configurable base node, and about the
rcar_du_of_add_property() function that adds a property to an existing DT
node. Rob, Frank, should I submit patches ? Any advice ?

Compared to v2, the biggest change is in patch 03/12. Following Rob's and
Frank's reviews it was clear that modifying the unflattened DT structure of
the overlay before applying it wasn't popular. I have thus decided to use one
overlay source per SoC to move as much of the DT changes to the overlay as
possible, and only perform manual modifications (that are still needed as some
of the information is board-specific) on the system DT after applying the
overlay. As a result the overlay is parsed and applied without being modified.

Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
and incorporate review feedback as described by the changelogs of individual
patches.

Laurent Pinchart (12):
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU
bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver
  ARM: dts: porter: Fix HDMI output routing
  ARM: dts: r8a7790: Convert to new LVDS DT bindings
  ARM: dts: r8a7791: Convert to new LVDS DT bindings
  ARM: dts: r8a7792: Convert to new DU DT bindings
  ARM: dts: r8a7793: Convert to new LVDS DT bindings
  ARM: dts: r8a7794: Convert to new DU DT bindings
  arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
  arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

 .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
 .../devicetree/bindings/display/renesas,du.txt |  31 +-
 MAINTAINERS|   1 +
 arch/arm/boot/dts/r8a7790-lager.dts|  22 +-
 arch/arm/boot/dts/r8a7790.dtsi |  60 ++-
 arch/arm/boot/dts/r8a7791-koelsch.dts  |  10 +-
 arch/arm/boot/dts/r8a7791-porter.dts   |  18 +-
 arch/arm/boot/dts/r8a7791.dtsi |  34 +-
 arch/arm/boot/dts/r8a7792.dtsi |   1 -
 arch/arm/boot/dts/r8a7793-gose.dts |  10 +-
 arch/arm/boot/dts/r8a7793.dtsi |  34 +-
 arch/arm/boot/dts/r8a7794.dtsi |   1 -
 .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   3 +-
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  34 +-
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  34 +-
 drivers/gpu/drm/rcar-du/Kconfig|   6 +-
 drivers/gpu/drm/rcar-du/Makefile   |  10 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   7 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |   3 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 175 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_group.c|  13 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  14 +-
 

[PATCH v3 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Update the SPDX headers to use C-style comments in header files
- Removed the manually created __local_fixups__ node
- Perform manual fixups on live DT instead of overlay

Changes since v1:

- Select OF_FLATTREE
- Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
- Pass void begin and end pointers to rcar_du_of_get_overlay()
- Use of_get_parent() instead of accessing the parent pointer directly
- Find the LVDS endpoints nodes based on the LVDS node instead of the
  root of the overlay
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig|   2 +
 drivers/gpu/drm/rcar-du/Makefile   |   7 +-
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 374 +
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  81 +
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  55 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  55 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  55 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  55 +++
 9 files changed, 703 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 5d0b4b7119af..3f83352a7313 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_FLATTREE
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..86b337b4be5d 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -8,7 +8,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
-
+rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
+  rcar_du_of_lvds_r8a7790.dtb.o \
+  rcar_du_of_lvds_r8a7791.dtb.o \
+  rcar_du_of_lvds_r8a7793.dtb.o \
+  rcar_du_of_lvds_r8a7795.dtb.o \
+  rcar_du_of_lvds_r8a7796.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..141f6eda6e98
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,374 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart 
+ *
+ * Based on work from Jyri Sarha 
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+/* 
-
+ * Generic Overlay Handling
+ */
+
+struct rcar_du_of_overlay {
+   const char *compatible;
+   void *begin;
+   void *end;
+};
+
+#define RCAR_DU_OF_DTB(type, soc)  \
+   extern char __dtb_rcar_du_of_##type##_##soc##_begin[];  \
+   extern char __dtb_rcar_du_of_##type##_##soc##_end[]
+
+#define RCAR_DU_OF_OVERLAY(type, soc)  \
+   {   \
+   .compatible = "renesas,du-" #soc,   \
+   .begin = __dtb_rcar_du_of_##type##_##soc##_begin,   \
+   .end = __dtb_rcar_du_of_##type##_##soc##_end,   \
+   }
+
+static 

[Bug 104762] Various segfaults/problems in qt/plasma

[bugzilla-daemon]

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

--- Comment #19 from Christoph Haag  ---
(In reply to Christoph Haag from comment #18)
> To be fair, the segfaults are fixed, but sddm and plasmashell randomly not
> working/rendering until the shader cache(s) are deleted is still happening.
> Unfortunately that's a bit harder to debug, but there might still be a
> similar issue hiding somewhere.

This may be rather bug 105065, which is really a QT bug:
https://bugreports.qt.io/browse/QTBUG-66420

-- 
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 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #21 from Alex Deucher  ---
(In reply to arne_woerner from comment #13)
> 1. (on Manjaro Linux) it is not enough to downgrade linux-firmware... u also
> need to do a mkinitcpio... :)
> 2. downgrading the directory /usr/lib/firmware/amdgpu from
> linux-firmware-20180119.2a713be-2 to linux-firmware-20180104.65b1c68-1 fixes
> this bug...
> 3. linux-firmware-20180119.2a713be-1 has this bug, too...
> 4. downgrading only the file polaris12_uvd.bin is not enough (but it looks
> slightly better)...

Sorry, I missed this part.

> 5. how does my box use the other new files in /usr/lib/firmware/amdgpu
> (fiji_vce.bin, polaris10_uvd.bin, polaris11_uvd.bin, raven_vcn.bin,
> vega10_uvd.bin, vega10_vce.bin)? i thought my box would not use these...

Your system doesn't use those additional firmwares.  They are for other chips.

-- 
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] video: fbdev: s3c-fb: remove dead platform code for Exynos and S5PV210 platforms

[Jingoo Han]

On Wednesday, February 14, 2018 7:01 AM wrote:
> 
> Exynos5, Exynos4 and S5PV210 platforms have been converted to
> use Device Tree and Exynos DRM driver long time ago.  Remove
> dead platform code for these platforms and update Kconfig
> s3c-fb entry accordingly.
> 
> Cc: Jingoo Han 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/video/fbdev/Kconfig  |3
>  drivers/video/fbdev/s3c-fb.c |  162 -
> --
>  2 files changed, 1 insertion(+), 164 deletions(-)
> 
> Index: b/drivers/video/fbdev/Kconfig
> ===
> --- a/drivers/video/fbdev/Kconfig 2018-02-12 14:28:32.392677896
> +0100
> +++ b/drivers/video/fbdev/Kconfig 2018-02-14 12:54:06.399057592
> +0100
> @@ -2020,8 +2020,7 @@ config FB_TMIO_ACCELL
> 
>  config FB_S3C
>   tristate "Samsung S3C framebuffer support"
> - depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || \
> - ARCH_S5PV210 || ARCH_EXYNOS)
> + depends on FB && (CPU_S3C2416 || ARCH_S3C64XX)
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
>   select FB_CFB_IMAGEBLIT
> Index: b/drivers/video/fbdev/s3c-fb.c
> ===
> --- a/drivers/video/fbdev/s3c-fb.c2017-10-18 14:35:22.063448310
> +0200
> +++ b/drivers/video/fbdev/s3c-fb.c2018-02-14 12:04:00.719262463
> +0100
> @@ -1716,63 +1716,6 @@ static struct s3c_fb_win_variant s3c_fb_
>   },
>  };
> 
> -static struct s3c_fb_win_variant s3c_fb_data_s5p_wins[] = {
> - [0] = {
> - .has_osd_c  = 1,
> - .osd_size_off   = 0x8,
> - .palette_sz = 256,
> - .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [1] = {
> - .has_osd_c  = 1,
> - .has_osd_d  = 1,
> - .osd_size_off   = 0xc,
> - .has_osd_alpha  = 1,
> - .palette_sz = 256,
> - .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [2] = {
> - .has_osd_c  = 1,
> - .has_osd_d  = 1,
> - .osd_size_off   = 0xc,
> - .has_osd_alpha  = 1,
> - .palette_sz = 256,
> - .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [3] = {
> - .has_osd_c  = 1,
> - .has_osd_alpha  = 1,
> - .palette_sz = 256,
> - .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [4] = {
> - .has_osd_c  = 1,
> - .has_osd_alpha  = 1,
> - .palette_sz = 256,
> - .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> -};
> -
>  static struct s3c_fb_driverdata s3c_fb_data_64xx = {
>   .variant = {
>   .nr_windows = 5,
> @@ -1804,102 +1747,6 @@ static struct s3c_fb_driverdata s3c_fb_d
>   .win[4] = _fb_data_64xx_wins[4],
>  };
> 
> -static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
> - .variant = {
> - .nr_windows = 5,
> - .vidtcon= VIDTCON0,
> - .wincon = WINCON(0),
> - .winmap = WINxMAP(0),
> - .keycon = WKEYCON,
> - .osd= VIDOSD_BASE,
> - .osd_stride = 16,
> - .buf_start  = VIDW_BUF_START(0),
> - .buf_size   = VIDW_BUF_SIZE(0),
> - .buf_end= VIDW_BUF_END(0),
> -
> - .palette = {
> - [0] = 0x2400,
> -

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher  ---
(In reply to arne_woerner from comment #19)
> ok...
> 
> but why is it necessary to use that old amdgpu firmware,
> if it was some other part of the kernel?
> 
> i cant find the change log of those firmware files...
> could there be something, that does not like to suspend/resume?

Is it the firmware that caused the regression?  Does everything work with the
old firmware?

-- 
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 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #19 from arne_woer...@yahoo.com ---
ok...

but why is it necessary to use that old amdgpu firmware,
if it was some other part of the kernel?

i cant find the change log of those firmware files...
could there be something, that does not like to suspend/resume?

-arne

-- 
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: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Meelis Roos]

> Actually this was brought up to me already, there's a fix on the mailing list
> for this I reviewed a little while ago from nvidia that we should pull in:
> 
> https://patchwork.freedesktop.org/patch/203205/
> 
> Would you guys mind confirming that this patch fixes your issues?

It works on my amd64, P4 is still compiling.

[1.124987] nouveau :04:05.0: NVIDIA NV05 (20154000)
[1.161464] nouveau :04:05.0: bios: version 03.05.00.10.00
[1.161475] nouveau :04:05.0: bios: DCB table not found
[1.161535] nouveau :04:05.0: bios: DCB table not found
[1.161577] nouveau :04:05.0: bios: DCB table not found
[1.161586] nouveau :04:05.0: bios: DCB table not found
[1.344008] tsc: Refined TSC clocksource calibration: 2200.078 MHz
[1.344024] clocksource: tsc: mask: 0x max_cycles: 
0x1fb67c69f81, max_idle_ns: 440795210317 ns
[1.344037] clocksource: Switched to clocksource tsc
[1.408102] nouveau :04:05.0: tmr: unknown input clock freq
[1.409471] nouveau :04:05.0: fb: 32 MiB SDRAM
[1.414459] nouveau :04:05.0: DRM: VRAM: 31 MiB
[1.414467] nouveau :04:05.0: DRM: GART: 128 MiB
[1.414476] nouveau :04:05.0: DRM: BMP version 5.17
[1.414484] nouveau :04:05.0: DRM: No DCB data found in VBIOS
[1.415629] nouveau :04:05.0: DRM: Adaptor not initialised, running 
VBIOS init tables.
[1.415829] nouveau :04:05.0: bios: DCB table not found
[1.416125] nouveau :04:05.0: DRM: Saving VGA fonts
[1.477526] nouveau :04:05.0: DRM: No DCB data found in VBIOS
[1.478428] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.478438] [drm] Driver supports precise vblank timestamp query.
[1.479618] nouveau :04:05.0: DRM: MM: using M2MF for buffer copies
[1.517930] nouveau :04:05.0: DRM: allocated 1024x768 fb: 0x4000, bo 
a09f4d1f
[1.519294] nouveau :04:05.0: fb1: nouveaufb frame buffer device
[1.519313] [drm] Initialized nouveau 1.3.1 20120801 for :04:05.0 on 
minor 1


-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #7 from Urs Fleisch  ---
Created attachment 137362
  --> https://bugs.freedesktop.org/attachment.cgi?id=137362=edit
Bisect stopping a commit with lockup but not distortion

-- 
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 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #6 from Urs Fleisch  ---
Since Arch Linux switched to kernel 4.14 for linux-lts (and the standard linux
package is at 4.15), I now have the choice between two kernels which do not
work with my Intel graphics Q35, this gives me quite some motivation to help
fixing this issue. Note that I do not know a real workaround, UXA is not an
option, it crashes regularly, the modesetting driver does not work with my
hardware (it needs at least OpenGL 2.1) and switching off the GPU in Chromium
can mitigate the problem, but it still happens.

I made a bisect using the linux-git kernel from AUR and started where the
bisect from Francesco Turco stopped (its first bad commit contained only hwmon
stuff, but I really expect some i915 code in the first bad commit). I will
attach my bisect log (named git_bisect_log_2.txt). My first bad commit is

[170fa29b14fadf2deb361589cefe6a78b21b1b22] drm/i915: Simplify eb_lookup_vmas()

Some remarks about the bisect: To know if a commit is good or bad, I booted the
kernel and started Chromium with maps.google.com. If the graphics was
distorted, I marked it bad. Two commits were not so easy to judge:
"[79364227e6b4923478e99d8480d62482b588ef84] IB/core: Add might_sleep()
annotation to ib_init_ah_from_wc()" did not distort the graphics, but I could
no longer move the mouse pointer (the computer was still controlable via
keyboard), so I marked that commit as good. The second problem commit was near
the end of the bisect procedure "[170fa29b14fadf2deb361589cefe6a78b21b1b22]
drm/i915: Simplify eb_lookup_vmas()" did not show the distortion, but after
browsing maps.google.com, the computer was totally locked up, I had to push the
power button to restart it, so I marked this commit as bad. This is the commit
which is now marked as the first bad, probably the distortion was introduced
later, but the commit before "[c7c6e46f913bb3a6ff19e64940ebb54652033677]
drm/i915: Convert execbuf to use struct-of-array packing for critical fields"
was good. I will probably have a look at some of the later commits to gain more
information.

-- 
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 105083] Random blinking display

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland  ---
How bad is the flicker? Would you be able to take a video showing the flicker
and post it (youtube or anywhere, really)?

-- 
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 105083] Random blinking display

[bugzilla-daemon]

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

--- Comment #3 from denisgolo...@yandex.ru ---
Adding amdgpu.dc=1 amdgpu.dc_log=1 indeed make flickering much less frequent.
However, I can still reproduce them when turning redshift on and off.

No logs in dmesg and messages with amdgpu appear though.
Any hints?

-- 
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 00/13] gpu: drm: amd: remove unused headers

[Alex Deucher]

On Wed, Feb 14, 2018 at 2:35 PM, Tom St Denis  wrote:
> This will break umr since we source the headers from the kernel.  The kernel
> might not use them but the different IP blocks have deltas that umr is aware
> of.
>
> One might argue that we should then publish the headers somewhere else that
> is public but the kernel is our vehicle right now.
>
> Thoughts Alex/Christian?

I also like having them there for debugging so I can use the defines
for accessing registers and bitfields without having to look them up
and add local defines or magic numbers.  The non-register headers can
be removed however since they are mostly leftover from code cleanups.

Alex

>
> Tom
>
>
>
> On 14/02/18 09:46 AM, Corentin Labbe wrote:
>>
>> Hello
>>
>> This patchset remove several headers which are not used by any source
>> file.
>>
>> Regards
>>
>> Change since v1:
>> - splited in multiple patchs
>>
>> Change since v2
>> - Use --irreversible-delete for format-patch
>>
>> Corentin Labbe (13):
>>drm/amd/include: remove unused asic_reg/oss headers
>>drm/amd/include: remove unused asic_reg/bif headers
>>drm/amd/include: remove unused asic_reg/dce headers
>>drm/amd/include: remove unused asic_reg/gca headers
>>drm/amd/include: remove unused asic_reg/gmc headers
>>drm/amd/include: remove unused asic_reg/smu headers
>>drm/amd/include: remove unused asic_reg/umc headers
>>drm/amd/include: remove unused asic_reg/uvd headers
>>drm/amd/include: remove unused asic_reg/vce headers
>>drm/amd/include: remove unused asic_reg/sdma headers
>>drm/amd/include: remove unused asic_reg/nbif headers
>>drm/amd/include: remove unused displayobject.h header
>>drm/amd/powerplay: remove unused headers
>>
>>   .../drm/amd/include/asic_reg/bif/bif_5_0_enum.h|  1198 --
>>   .../drm/amd/include/asic_reg/bif/bif_5_1_enum.h|  1068 -
>>   .../drm/amd/include/asic_reg/dce/dce_11_2_enum.h   |  6813 --
>>   .../drm/amd/include/asic_reg/dce/dce_8_0_enum.h|  1117 -
>>   .../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h   |  2791 ---
>>   .../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h|  6808 --
>>   .../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21368
>> ---
>>   .../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h|  1198 --
>>   .../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h|  1068 -
>>   .../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h   | 10281 -
>>   .../drm/amd/include/asic_reg/oss/oss_2_4_enum.h|  1340 --
>>   .../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h  |  1464 --
>>   .../drm/amd/include/asic_reg/oss/oss_3_0_enum.h|  1497 --
>>   .../amd/include/asic_reg/sdma0/sdma0_4_0_default.h |   286 -
>>   .../amd/include/asic_reg/sdma1/sdma1_4_0_default.h |   282 -
>>   .../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h   |   148 -
>>   .../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h |   715 -
>>   .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h |  1344 --
>>   .../drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h  |  1191 --
>>   .../amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h   |  5648 -
>>   .../drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h  |  1205 --
>>   .../drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h  |  1246 --
>>   .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  |  1282 --
>>   .../drm/amd/include/asic_reg/smu/smu_8_0_enum.h|  1072 -
>>   .../drm/amd/include/asic_reg/umc/umc_6_0_default.h |31 -
>>   .../drm/amd/include/asic_reg/umc/umc_6_0_offset.h  |52 -
>>   .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |   795 -
>>   .../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h|  1211 --
>>   .../drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h|  1081 -
>>   .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h   |64 -
>>   .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h |99 -
>>   drivers/gpu/drm/amd/include/displayobject.h|   249 -
>>   .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h|   412 -
>>   drivers/gpu/drm/amd/powerplay/inc/pp_feature.h |67 -
>>   34 files changed, 76491 deletions(-)
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h
>>   delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h
>>   delete mode 100644
>> drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h
>>   delete mode 100644
>> 

Re: [PATCH v3 00/13] gpu: drm: amd: remove unused headers

[Tom St Denis]

This will break umr since we source the headers from the kernel.  The 
kernel might not use them but the different IP blocks have deltas that 
umr is aware of.


One might argue that we should then publish the headers somewhere else 
that is public but the kernel is our vehicle right now.


Thoughts Alex/Christian?

Tom


On 14/02/18 09:46 AM, Corentin Labbe wrote:

Hello

This patchset remove several headers which are not used by any source
file.

Regards

Change since v1:
- splited in multiple patchs

Change since v2
- Use --irreversible-delete for format-patch

Corentin Labbe (13):
   drm/amd/include: remove unused asic_reg/oss headers
   drm/amd/include: remove unused asic_reg/bif headers
   drm/amd/include: remove unused asic_reg/dce headers
   drm/amd/include: remove unused asic_reg/gca headers
   drm/amd/include: remove unused asic_reg/gmc headers
   drm/amd/include: remove unused asic_reg/smu headers
   drm/amd/include: remove unused asic_reg/umc headers
   drm/amd/include: remove unused asic_reg/uvd headers
   drm/amd/include: remove unused asic_reg/vce headers
   drm/amd/include: remove unused asic_reg/sdma headers
   drm/amd/include: remove unused asic_reg/nbif headers
   drm/amd/include: remove unused displayobject.h header
   drm/amd/powerplay: remove unused headers

  .../drm/amd/include/asic_reg/bif/bif_5_0_enum.h|  1198 --
  .../drm/amd/include/asic_reg/bif/bif_5_1_enum.h|  1068 -
  .../drm/amd/include/asic_reg/dce/dce_11_2_enum.h   |  6813 --
  .../drm/amd/include/asic_reg/dce/dce_8_0_enum.h|  1117 -
  .../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h   |  2791 ---
  .../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h|  6808 --
  .../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21368 ---
  .../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h|  1198 --
  .../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h|  1068 -
  .../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h   | 10281 -
  .../drm/amd/include/asic_reg/oss/oss_2_4_enum.h|  1340 --
  .../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h  |  1464 --
  .../drm/amd/include/asic_reg/oss/oss_3_0_enum.h|  1497 --
  .../amd/include/asic_reg/sdma0/sdma0_4_0_default.h |   286 -
  .../amd/include/asic_reg/sdma1/sdma1_4_0_default.h |   282 -
  .../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h   |   148 -
  .../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h |   715 -
  .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h |  1344 --
  .../drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h  |  1191 --
  .../amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h   |  5648 -
  .../drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h  |  1205 --
  .../drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h  |  1246 --
  .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  |  1282 --
  .../drm/amd/include/asic_reg/smu/smu_8_0_enum.h|  1072 -
  .../drm/amd/include/asic_reg/umc/umc_6_0_default.h |31 -
  .../drm/amd/include/asic_reg/umc/umc_6_0_offset.h  |52 -
  .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |   795 -
  .../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h|  1211 --
  .../drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h|  1081 -
  .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h   |64 -
  .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h |99 -
  drivers/gpu/drm/amd/include/displayobject.h|   249 -
  .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h|   412 -
  drivers/gpu/drm/amd/powerplay/inc/pp_feature.h |67 -
  34 files changed, 76491 deletions(-)
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h
  delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h
  delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
  delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
  delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
  delete mode 100644 

[PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

[Anusha Srivatsa]

Forward Error Correction is supported on DP 1.4.
This patch adds corresponding DPCD register definitions.

v2: Add dri-devel mailing list to the CC list(Jani)

v3: Change names, add missing masks (Manasi)

v4: Add missing shifts to mask (Manasi)

v5: Arrange the definitions in ascending order
of the address (Jani)

v6: remove unnecessary definitions. Add missing masks,
add "/* 1.4 */" to offset definitions. (Jani)

Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 include/drm/drm_dp_helper.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c239e6e..4de97e9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -329,6 +329,13 @@
 # define DP_DS_12BPC   2
 # define DP_DS_16BPC   3
 
+/* DP Forward error Correction Registers */
+#define DP_FEC_CAPABILITY  0x090/* 1.4 */
+# define DP_FEC_CAPABLE(1 << 0)
+# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
+# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
+# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
+
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */
@@ -445,6 +452,19 @@
 #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118   /* 1.2 */
 # define DP_PWR_NOT_NEEDED (1 << 0)
 
+#define DP_FEC_CONFIGURATION   0x120/* 1.4 */
+# define DP_FEC_READY  (1 << 0)
+# define DP_FEC_ERR_COUNT_SEL_MASK (7 << 1)
+# define DP_FEC_ERR_COUNT_DIS  (0 << 1)
+# define DP_FEC_UNCORR_BLK_ERROR_COUNT (1 << 1)
+# define DP_FEC_CORR_BLK_ERROR_COUNT   (2 << 1)
+# define DP_FEC_BIT_ERROR_COUNT(3 << 1)
+# define DP_FEC_LANE_SELECT_MASK   (3 << 4)
+# define DP_FEC_LANE_0_SELECT  (0 << 4)
+# define DP_FEC_LANE_1_SELECT  (1 << 4)
+# define DP_FEC_LANE_2_SELECT  (2 << 4)
+# define DP_FEC_LANE_3_SELECT  (3 << 4)
+
 #define DP_AUX_FRAME_SYNC_VALUE0x15c   /* eDP 1.4 */
 # define DP_AUX_FRAME_SYNC_VALID   (1 << 0)
 
@@ -620,6 +640,16 @@
 #define DP_TEST_SINK   0x270
 # define DP_TEST_SINK_START(1 << 0)
 
+#define DP_FEC_STATUS  0x280/* 1.4 */
+# define DP_FEC_DECODE_EN_DETECTED (1 << 0)
+# define DP_FEC_DECODE_DIS_DETECTED(1 << 1)
+
+#define DP_FEC_ERROR_COUNT_LSB 0x0281/* 1.4 */
+
+#define DP_FEC_ERROR_COUNT_MSB 0x0282/* 1.4 */
+# define DP_FEC_ERROR_COUNT_MASK   0x7F
+# define DP_FEC_ERR_COUNT_VALID(1 << 7)
+
 #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
 # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
 # define DP_PAYLOAD_ACT_HANDLED (1 << 1)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/8] drm/i915: Add support for the YCbCr COLOR_ENCODING property

[Ville Syrjala]

From: Ville Syrjälä 

Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.

CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it doesn't seem all that useful to
expose anything beyond BT.601 and BT.709 at this time.

GLK can supposedly do BT.2020, but let's leave enabling that for
the future as well.

v2: Rename bit defines to match the spec more closely (Shashank)

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Reviewed-by: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  5 ++-
 drivers/gpu/drm/i915/intel_display.c | 19 +--
 drivers/gpu/drm/i915/intel_sprite.c  | 61 +++-
 3 files changed, 67 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6abeaf64c2d2..6061f418c88d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6140,6 +6140,7 @@ enum {
 #define   DVS_PIPE_CSC_ENABLE   (1<<24)
 #define   DVS_SOURCE_KEY   (1<<22)
 #define   DVS_RGB_ORDER_XBGR   (1<<20)
+#define   DVS_YUV_FORMAT_BT709 (1<<18)
 #define   DVS_YUV_BYTE_ORDER_MASK (3<<16)
 #define   DVS_YUV_ORDER_YUYV   (0<<16)
 #define   DVS_YUV_ORDER_UYVY   (1<<16)
@@ -6210,7 +6211,7 @@ enum {
 #define   SPRITE_SOURCE_KEY(1<<22)
 #define   SPRITE_RGB_ORDER_RGBX(1<<20) /* only for 888 and 
161616 */
 #define   SPRITE_YUV_TO_RGB_CSC_DISABLE(1<<19)
-#define   SPRITE_YUV_CSC_FORMAT_BT709  (1<<18) /* 0 is BT601 */
+#define   SPRITE_YUV_TO_RGB_CSC_FORMAT_BT709   (1<<18) /* 0 is BT601 */
 #define   SPRITE_YUV_BYTE_ORDER_MASK   (3<<16)
 #define   SPRITE_YUV_ORDER_YUYV(0<<16)
 #define   SPRITE_YUV_ORDER_UYVY(1<<16)
@@ -6286,6 +6287,7 @@ enum {
 #define   SP_FORMAT_RGBA   (0xf<<26)
 #define   SP_ALPHA_PREMULTIPLY (1<<23) /* CHV pipe B */
 #define   SP_SOURCE_KEY(1<<22)
+#define   SP_YUV_FORMAT_BT709  (1<<18)
 #define   SP_YUV_BYTE_ORDER_MASK   (3<<16)
 #define   SP_YUV_ORDER_YUYV(0<<16)
 #define   SP_YUV_ORDER_UYVY(1<<16)
@@ -6410,6 +6412,7 @@ enum {
 #define   PLANE_CTL_KEY_ENABLE_DESTINATION (  2 << 21)
 #define   PLANE_CTL_ORDER_BGRX (0 << 20)
 #define   PLANE_CTL_ORDER_RGBX (1 << 20)
+#define   PLANE_CTL_YUV_TO_RGB_CSC_FORMAT_BT709(1 << 18)
 #define   PLANE_CTL_YUV422_ORDER_MASK  (0x3 << 16)
 #define   PLANE_CTL_YUV422_YUYV(  0 << 16)
 #define   PLANE_CTL_YUV422_UYVY(  1 << 16)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a22b583838f7..8c11d2a993a8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3544,6 +3544,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE |
PLANE_CTL_PLANE_GAMMA_DISABLE;
+
+   if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
+   plane_ctl |= PLANE_CTL_YUV_TO_RGB_CSC_FORMAT_BT709;
}
 
plane_ctl |= skl_plane_ctl_format(fb->format->format);
@@ -3573,8 +3576,12 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
 
-   if (intel_format_is_yuv(fb->format->format))
-   plane_color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+   if (intel_format_is_yuv(fb->format->format)) {
+   if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
+   plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+   else
+   plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+   }
 
return plane_color_ctl;
 }
@@ -13314,6 +13321,14 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
   DRM_MODE_ROTATE_0,
   supported_rotations);
 
+   if (INTEL_GEN(dev_priv) >= 9)
+   drm_plane_create_color_properties(>base,
+ 

[PATCH 7/8] drm/i915: Change the COLOR_ENCODING prop default value to BT.709

[Ville Syrjala]

From: Ville Syrjälä 

Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Acked-by: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8c11d2a993a8..89c4bda91ecb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13326,7 +13326,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
  BIT(DRM_COLOR_YCBCR_BT601) |
  BIT(DRM_COLOR_YCBCR_BT709),
  
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
- DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_BT709,
  
DRM_COLOR_YCBCR_LIMITED_RANGE);
 
drm_plane_helper_add(>base, _plane_helper_funcs);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 3a79a641a343..49969b2f3494 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1532,7 +1532,7 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
  BIT(DRM_COLOR_YCBCR_BT601) |
  BIT(DRM_COLOR_YCBCR_BT709),
  BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
- DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_BT709,
  DRM_COLOR_YCBCR_LIMITED_RANGE);
 
drm_plane_helper_add(_plane->base, _plane_helper_funcs);
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/8] drm/i915: Add support for the YCbCr COLOR_RANGE property

[Ville Syrjala]

From: Ville Syrjälä 

Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.

On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program the color
correction logic to pass the data through unmodified.

v2: Rebase

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Reviewed-by: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_display.c |  9 -
 drivers/gpu/drm/i915/intel_sprite.c  | 12 ++--
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6061f418c88d..405a651eea11 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6132,6 +6132,7 @@ enum {
 #define _DVSACNTR  0x72180
 #define   DVS_ENABLE   (1<<31)
 #define   DVS_GAMMA_ENABLE (1<<30)
+#define   DVS_YUV_RANGE_CORRECTION_DISABLE (1<<27)
 #define   DVS_PIXFORMAT_MASK   (3<<25)
 #define   DVS_FORMAT_YUV422(0<<25)
 #define   DVS_FORMAT_RGBX101010(1<<25)
@@ -6200,6 +6201,7 @@ enum {
 #define _SPRA_CTL  0x70280
 #define   SPRITE_ENABLE(1<<31)
 #define   SPRITE_GAMMA_ENABLE  (1<<30)
+#define   SPRITE_YUV_RANGE_CORRECTION_DISABLE  (1<<28)
 #define   SPRITE_PIXFORMAT_MASK(7<<25)
 #define   SPRITE_FORMAT_YUV422 (0<<25)
 #define   SPRITE_FORMAT_RGBX101010 (1<<25)
@@ -6391,6 +6393,7 @@ enum {
 #define _PLANE_CTL_3_A 0x70380
 #define   PLANE_CTL_ENABLE (1 << 31)
 #define   PLANE_CTL_PIPE_GAMMA_ENABLE  (1 << 30)   /* Pre-GLK */
+#define   PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE   (1 << 28)
 /*
  * ICL+ uses the same PLANE_CTL_FORMAT bits, but the field definition
  * expanded to include bit 23 as well. However, the shift-24 based values
@@ -6465,6 +6468,7 @@ enum {
 #define _PLANE_COLOR_CTL_2_A   0x702CC /* GLK+ */
 #define _PLANE_COLOR_CTL_3_A   0x703CC /* GLK+ */
 #define   PLANE_COLOR_PIPE_GAMMA_ENABLE(1 << 30)
+#define   PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23)
 #define   PLANE_COLOR_CSC_MODE_BYPASS  (0 << 17)
 #define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709(1 << 17)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 89c4bda91ecb..3d21eca18602 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3547,6 +3547,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
 
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_ctl |= PLANE_CTL_YUV_TO_RGB_CSC_FORMAT_BT709;
+
+   if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+   plane_ctl |= PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
}
 
plane_ctl |= skl_plane_ctl_format(fb->format->format);
@@ -3581,6 +3584,9 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+
+   if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+   plane_color_ctl |= 
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
}
 
return plane_color_ctl;
@@ -13325,7 +13331,8 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
drm_plane_create_color_properties(>base,
  BIT(DRM_COLOR_YCBCR_BT601) |
  BIT(DRM_COLOR_YCBCR_BT709),
- 
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
+ 
BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
+ 
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
  DRM_COLOR_YCBCR_BT709,
  
DRM_COLOR_YCBCR_LIMITED_RANGE);
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 49969b2f3494..dbdcf85032df 100644
--- 

[PATCH 5/8] drm/i915: Fix plane YCbCr->RGB conversion for GLK

[Ville Syrjala]

From: Ville Syrjälä 

On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.

The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's going to use the YCbCr->RGB
matrix as specified in BT.601 and doesn't actually change the gamut.

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  5 +
 drivers/gpu/drm/i915/intel_display.c |  3 +++
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_sprite.c  | 10 +-
 4 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 28b36eac064e..6abeaf64c2d2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6463,6 +6463,11 @@ enum {
 #define _PLANE_COLOR_CTL_3_A   0x703CC /* GLK+ */
 #define   PLANE_COLOR_PIPE_GAMMA_ENABLE(1 << 30)
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23)
+#define   PLANE_COLOR_CSC_MODE_BYPASS  (0 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709(1 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709(2 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020  (3 << 17)
+#define   PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020   (4 << 17)
 #define   PLANE_COLOR_PLANE_GAMMA_DISABLE  (1 << 13)
 #define   PLANE_COLOR_ALPHA_MASK   (0x3 << 4)
 #define   PLANE_COLOR_ALPHA_DISABLE(0 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 286a9591d179..a22b583838f7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3573,6 +3573,9 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
 
+   if (intel_format_is_yuv(fb->format->format))
+   plane_color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+
return plane_color_ctl;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 898064e8bea7..6e43da40c859 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1591,6 +1591,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
const struct intel_plane_state *plane_state);
 u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
  const struct intel_plane_state *plane_state);
+u32 glk_color_ctl(const struct intel_plane_state *plane_state);
 u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
 unsigned int rotation);
 int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
@@ -2016,6 +2017,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
 
 
 /* intel_sprite.c */
+bool intel_format_is_yuv(u32 format);
 int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
 int usecs);
 struct intel_plane *intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index fac9e01b4795..b4acde2058fe 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -41,8 +41,7 @@
 #include 
 #include "i915_drv.h"
 
-static bool
-format_is_yuv(uint32_t format)
+bool intel_format_is_yuv(u32 format)
 {
switch (format) {
case DRM_FORMAT_YUYV:
@@ -266,6 +265,7 @@ skl_update_plane(struct intel_plane *plane,
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
  plane_state->color_ctl);
+
if (key->flags) {
I915_WRITE_FW(PLANE_KEYVAL(pipe, plane_id), key->min_value);
I915_WRITE_FW(PLANE_KEYMAX(pipe, plane_id), key->max_value);
@@ -354,7 +354,7 @@ chv_update_csc(const struct intel_plane_state *plane_state)
enum plane_id plane_id = plane->id;
 
/* Seems RGB data bypasses the CSC always */
-   if (!format_is_yuv(fb->format->format))
+   if (!intel_format_is_yuv(fb->format->format))
return;
 
/*
@@ -399,7 +399,7 @@ vlv_update_clrc(const struct intel_plane_state *plane_state)
enum plane_id plane_id = plane->id;
int 

[PATCH 0/8] drm: Add COLOR_ENCODING and COLOR_RANGE plane properties

[Ville Syrjala]

From: Ville Syrjälä 

Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties,
and the i915 implementation I did on top. I tossed in a few core
updates as well: plane state dump, and the BT.2020 constant luminance
variant.

Apparently nouveau is already exposing a "iturbt_709" bool property
which allows one to choose between BT.601 and BT.709 encodings, but
given that we want at least BT.2020 in addition I don't think that
property is good enough. Trying to implement it, and somehow extend
it beyond BT.601 vs. BT.709 seems like wasted effort. Hence I think
we should just ignore it and move on.

My userspace implementation in the form of intel ddx
XV_COLORSPACE attribute:
https://patchwork.freedesktop.org/patch/204696/

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 

Jyri Sarha (1):
  drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to
drm_plane

Ville Syrjälä (7):
  drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING
property
  drm/atomic: Include color encoding/range in plane state dump
  drm/i915: Correctly handle limited range YCbCr data on VLV/CHV
  drm/i915: Fix plane YCbCr->RGB conversion for GLK
  drm/i915: Add support for the YCbCr COLOR_ENCODING property
  drm/i915: Change the COLOR_ENCODING prop default value to BT.709
  drm/i915: Add support for the YCbCr COLOR_RANGE property

 drivers/gpu/drm/drm_atomic.c |  12 
 drivers/gpu/drm/drm_color_mgmt.c | 108 
 drivers/gpu/drm/drm_crtc_internal.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |  24 ++-
 drivers/gpu/drm/i915/intel_display.c |  25 +++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_sprite.c  | 134 ---
 include/drm/drm_color_mgmt.h |  20 ++
 include/drm/drm_plane.h  |   8 +++
 9 files changed, 309 insertions(+), 26 deletions(-)

-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] drm/atomic: Include color encoding/range in plane state dump

[Ville Syrjala]

From: Ville Syrjälä 

Include color_enconding and color_range in the plane state dump.

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c|  4 
 drivers/gpu/drm/drm_color_mgmt.c| 16 
 drivers/gpu/drm/drm_crtc_internal.h |  2 ++
 3 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 452a0b0bafbc..9552052ed31a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -952,6 +952,10 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG());
drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG());
drm_printf(p, "\trotation=%x\n", state->rotation);
+   drm_printf(p, "\tcolor-encoding=%s\n",
+  drm_get_color_encoding_name(state->color_encoding));
+   drm_printf(p, "\tcolor-range=%s\n",
+  drm_get_color_range_name(state->color_range));
 
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 061d342f9d96..06851d575f14 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -365,6 +365,22 @@ static const char * const color_range_name[] = {
[DRM_COLOR_YCBCR_LIMITED_RANGE] = "YCbCr limited range",
 };
 
+const char *drm_get_color_encoding_name(enum drm_color_encoding encoding)
+{
+   if (WARN_ON(encoding >= ARRAY_SIZE(color_encoding_name)))
+   return "unknown";
+
+   return color_encoding_name[encoding];
+}
+
+const char *drm_get_color_range_name(enum drm_color_range range)
+{
+   if (WARN_ON(range >= ARRAY_SIZE(color_range_name)))
+   return "unknown";
+
+   return color_range_name[range];
+}
+
 /**
  * drm_plane_create_color_properties - color encoding related plane properties
  * @supported_encodings: bitfield indicating supported color encodings
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index af00f42ba269..8ca2ffef6231 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -71,6 +71,8 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 
 /* drm_color_mgmt.c */
+const char *drm_get_color_encoding_name(enum drm_color_encoding encoding);
+const char *drm_get_color_range_name(enum drm_color_range range);
 
 /* IOCTLs */
 int drm_mode_gamma_get_ioctl(struct drm_device *dev,
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/8] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property

[Ville Syrjala]

From: Ville Syrjälä 

BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
traditional non-constant luminance and a more complicate one constant
luminance one. Add an enum value for the constant luminance variant
as well in case someone has hardware supporting it.

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
CC: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_color_mgmt.c | 1 +
 include/drm/drm_color_mgmt.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index a84fc861e406..061d342f9d96 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -357,6 +357,7 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+   [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr constant 
luminance",
 };
 
 static const char * const color_range_name[] = {
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d302ca8c..175943c87d5b 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 enum drm_color_encoding {
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
-   DRM_COLOR_YCBCR_BT2020,
+   DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
+   DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
DRM_COLOR_ENCODING_MAX,
 };
 
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

[Ville Syrjala]

From: Ville Syrjälä 

Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).

On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.

This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.

One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.

v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Shashank Sharma 
Cc: Uma Shankar 
Cc: Jyri Sarha 
Cc: "Tang, Jun" 
Reported-by: "Tang, Jun" 
Cc: sta...@vger.kernel.org
Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4")
Reviewed-by: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h | 10 +
 drivers/gpu/drm/i915/intel_sprite.c | 81 -
 2 files changed, 73 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6afa5e5e7c1..28b36eac064e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6305,6 +6305,12 @@ enum {
 #define _SPATILEOFF(VLV_DISPLAY_BASE + 0x721a4)
 #define _SPACONSTALPHA (VLV_DISPLAY_BASE + 0x721a8)
 #define   SP_CONST_ALPHA_ENABLE(1<<31)
+#define _SPACLRC0  (VLV_DISPLAY_BASE + 0x721d0)
+#define   SP_CONTRAST(x)   ((x) << 18) /* u3.6 */
+#define   SP_BRIGHTNESS(x) ((x) & 0xff) /* s8 */
+#define _SPACLRC1  (VLV_DISPLAY_BASE + 0x721d4)
+#define   SP_SH_SIN(x) (((x) & 0x7ff) << 16) /* s4.7 */
+#define   SP_SH_COS(x) (x) /* u3.7 */
 #define _SPAGAMC   (VLV_DISPLAY_BASE + 0x721f4)
 
 #define _SPBCNTR   (VLV_DISPLAY_BASE + 0x72280)
@@ -6318,6 +6324,8 @@ enum {
 #define _SPBKEYMAXVAL  (VLV_DISPLAY_BASE + 0x722a0)
 #define _SPBTILEOFF(VLV_DISPLAY_BASE + 0x722a4)
 #define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
+#define _SPBCLRC0  (VLV_DISPLAY_BASE + 0x722d0)
+#define _SPBCLRC1  (VLV_DISPLAY_BASE + 0x722d4)
 #define _SPBGAMC   (VLV_DISPLAY_BASE + 0x722f4)
 
 #define _MMIO_VLV_SPR(pipe, plane_id, reg_a, reg_b) \
@@ -6334,6 +6342,8 @@ enum {
 #define SPKEYMAXVAL(pipe, plane_id)_MMIO_VLV_SPR((pipe), (plane_id), 
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
 #define SPTILEOFF(pipe, plane_id)  _MMIO_VLV_SPR((pipe), (plane_id), 
_SPATILEOFF, _SPBTILEOFF)
 #define SPCONSTALPHA(pipe, plane_id)   _MMIO_VLV_SPR((pipe), (plane_id), 
_SPACONSTALPHA, _SPBCONSTALPHA)
+#define SPCLRC0(pipe, plane_id)_MMIO_VLV_SPR((pipe), 
(plane_id), _SPACLRC0, _SPBCLRC0)
+#define SPCLRC1(pipe, plane_id)_MMIO_VLV_SPR((pipe), 
(plane_id), _SPACLRC1, _SPBCLRC1)
 #define SPGAMC(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), 
_SPAGAMC, _SPBGAMC)
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b2c85c..fac9e01b4795 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -346,44 +346,87 @@ skl_plane_get_hw_state(struct intel_plane *plane)
 }
 
 static void
-chv_update_csc(struct intel_plane *plane, uint32_t format)
+chv_update_csc(const struct intel_plane_state *plane_state)
 {
+   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
enum plane_id plane_id = plane->id;
 
/* Seems RGB data bypasses the CSC always */
-   if (!format_is_yuv(format))
+   if 

[PATCH 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Ville Syrjala]

From: Jyri Sarha 

Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are stored to drm_plane object to allow different set of supported
encoding for different planes on the device.

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/drm_atomic.c |  8 
 drivers/gpu/drm/drm_color_mgmt.c | 91 
 include/drm/drm_color_mgmt.h | 19 +
 include/drm/drm_plane.h  |  8 
 4 files changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d534587..452a0b0bafbc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -759,6 +759,10 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+   } else if (property == plane->color_encoding_property) {
+   state->color_encoding = val;
+   } else if (property == plane->color_range_property) {
+   state->color_range = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -818,6 +822,10 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+   } else if (property == plane->color_encoding_property) {
+   *val = state->color_encoding;
+   } else if (property == plane->color_range_property) {
+   *val = state->color_range;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 0d002b045bd2..a84fc861e406 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -88,6 +88,19 @@
  * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
  * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp with the
  * "GAMMA_LUT" property above.
+ *
+ * Support for different non RGB color encodings is controlled through
+ * _plane specific COLOR_ENCODING and COLOR_RANGE properties:
+ *
+ * "COLOR_ENCODING"
+ * Optional plane enum property to support different non RGB
+ * color encodings. The driver can provide a subset of standard
+ * enum values supported by the DRM plane.
+ *
+ * "COLOR_RANGE"
+ * Optional plane enum property to support different non RGB
+ * color parameter ranges. The driver can provide a subset of
+ * standard enum values supported by the DRM plane.
  */
 
 /**
@@ -339,3 +352,81 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
drm_modeset_unlock(>mutex);
return ret;
 }
+
+static const char * const color_encoding_name[] = {
+   [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
+   [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
+   [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+};
+
+static const char * const color_range_name[] = {
+   [DRM_COLOR_YCBCR_FULL_RANGE] = "YCbCr full range",
+   [DRM_COLOR_YCBCR_LIMITED_RANGE] = "YCbCr limited range",
+};
+
+/**
+ * drm_plane_create_color_properties - color encoding related plane properties
+ * @supported_encodings: bitfield indicating supported color encodings
+ * @supported_ranges: bitfileld indicating supported color ranges
+ * @default_encoding: default color encoding
+ * @default_range: default color range
+ *
+ * Create and attach plane specific COLOR_ENCODING and COLOR_RANGE
+ * properties to to the drm_plane object. The supported encodings and
+ * ranges should be provided in supported_encodings and
+ * supported_ranges bitmasks. Each bit set in the bitmask indicates
+ * the its number as enum value being supported.
+ */
+int drm_plane_create_color_properties(struct drm_plane *plane,
+ u32 supported_encodings,
+ u32 supported_ranges,
+ enum drm_color_encoding default_encoding,
+ enum drm_color_range default_range)
+{
+   

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Lyude Paul]

Actually this was brought up to me already, there's a fix on the mailing list
for this I reviewed a little while ago from nvidia that we should pull in:

https://patchwork.freedesktop.org/patch/203205/

Would you guys mind confirming that this patch fixes your issues?

On Wed, 2018-02-14 at 18:41 +0100, Pierre Moreau wrote:
> On 2018-02-14 — 09:36, Ilia Mirkin wrote:
> > On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin  wrote:
> > > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos  wrote:
> > > > > This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in
> > > > > 4.15:
> > > > 
> > > > NV5 in another PC (secondary card in x86-64) made the systrem crash on
> > > > boot, in nvkm_therm_clkgate_fini.
> > > 
> > > Mind booting with nouveau.debug=trace? That should hopefully tell us
> > > more exactly which thing is dying. If you have a cross-compile/distcc
> > > setup handy, a bisect may be even more useful.
> > 
> > Erm, sorry, nevermind. You even said it -- nvkm_therm_clkgate_fini is
> > somehow mis-hooked up for NV5 now. A bisect result would still make
> > the culprit a lot more obvious.
> 
> CC’ing Lyude Paul as she hooked up the clockgating support.
> 
> Looking at the code, only NV40+ do have a therm engine. Therefore, shouldn’t
> nvkm_therm_clkgate_enable(), nvkm_therm_clkgate_fini() and
> nvkm_therm_clkgate_oneinit() all check for therm being not NULL, on top of
> their check for the clkgate_* hooks being there? Or instead, maybe have the
> check in nvkm_device_init() nvkm_device_init()?
> 
> Pierre
-- 
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Allow determining if current task is output poll worker

[Lyude Paul]

I think your idea of having the extra kerneldoc as a seperate patch to make
this easier to backport should work fine :). Thanks for the good work!

Reviewed-by: Lyude Paul 

On Wed, 2018-02-14 at 08:41 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish and the worker in turn calls a ->detect callback which waits
> for runtime suspend to finish.  The ->detect callback is invoked from
> multiple call sites and waiting for runtime suspend to finish is the
> correct thing to do except if it's executing in the context of the
> worker.
> 
> v2: Expand kerneldoc to specifically mention deadlock between
> output poll worker and autosuspend worker as use case. (Lyude)
> 
> Cc: Dave Airlie 
> Cc: Ben Skeggs 
> Cc: Alex Deucher 
> Reviewed-by: Lyude Paul 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 20 
>  include/drm/drm_crtc_helper.h  |  1 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 6dc2dde5b672..7a6b2dc08913 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -654,6 +654,26 @@ static void output_poll_execute(struct work_struct
> *work)
>   schedule_delayed_work(delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
>  }
>  
> +/**
> + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> + *
> + * Determine if %current task is an output poll worker.  This can be used
> + * to select distinct code paths for output polling versus other contexts.
> + *
> + * One use case is to avoid a deadlock between the output poll worker and
> + * the autosuspend worker wherein the latter waits for polling to finish
> + * upon calling drm_kms_helper_poll_disable(), while the former waits for
> + * runtime suspend to finish upon calling pm_runtime_get_sync() in a
> + * connector ->detect hook.
> + */
> +bool drm_kms_helper_is_poll_worker(void)
> +{
> + struct work_struct *work = current_work();
> +
> + return work && work->func == output_poll_execute;
> +}
> +EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> +
>  /**
>   * drm_kms_helper_poll_disable - disable output polling
>   * @dev: drm_device
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>  
>  void drm_kms_helper_poll_disable(struct drm_device *dev);
>  void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
>  
>  #endif
-- 
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105095] piglit arb_vertex_type_2_10_10_10_rev-array_types failed for BARTS

[bugzilla-daemon]

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

--- Comment #1 from Roland Scheidegger  ---
Is that BARTS specific?
My piglit runs with Juniper (HD 5750) show this test passing (and generally
there's no difference in the driver between these two chips).
(Albeit I never ran it with this specific mesa version, you could try mesa
git.)

-- 
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] gpu: ipu-v3: make const arrays int_reg static, shrinks object size

[Colin King]

From: Colin Ian King 

Don't populate the const read-only arrays int_reg on the stack but instead
make them static. Makes the object code smaller by over 80 bytes:

Before:
   textdata bss dec hex filename
  280248936 192   371529120 drivers/gpu/ipu-v3/ipu-common.o

After:
   textdata bss dec hex filename
  277949080 192   3706690ca drivers/gpu/ipu-v3/ipu-common.o

(gcc version 7.2.0 x86_64)

Signed-off-by: Colin Ian King 
---
 drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 658fa2d3e40c..48685cddbad1 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1089,7 +1089,7 @@ static void ipu_irq_handler(struct irq_desc *desc)
 {
struct ipu_soc *ipu = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
-   const int int_reg[] = { 0, 1, 2, 3, 10, 11, 12, 13, 14};
+   static const int int_reg[] = { 0, 1, 2, 3, 10, 11, 12, 13, 14};
 
chained_irq_enter(chip, desc);
 
@@ -1102,7 +1102,7 @@ static void ipu_err_irq_handler(struct irq_desc *desc)
 {
struct ipu_soc *ipu = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
-   const int int_reg[] = { 4, 5, 8, 9};
+   static const int int_reg[] = { 4, 5, 8, 9};
 
chained_irq_enter(chip, desc);
 
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

[Rodrigo Vivi]

Rodrigo Vivi  writes:

> On Wed, Feb 07, 2018 at 09:32:35PM +, Pandiyan, Dhinakaran wrote:
>> 
>> 
>> 
>> On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
>> > On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
>> > > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
>> > > > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
>> > > > return type for drm_crtc_vblank_count() to u64. This could cause
>> > > > potential problems if the return value is used in arithmetic operations
>> > > > with a 32-bit reference HW vblank count. Explicitly typecasting this
>> > > > down to u32 either fixes a potential problem or serves to add clarity 
>> > > > in
>> > > > case the implicit typecasting was already correct.
>> > > > 
>> > > > Cc: Keith Packard 
>> > > > Cc: Thierry Reding 
>> > > 
>> > > 
>> > > Thierry, 
>> > > 
>> > > Can I get an Ack on this please? 
>> > > 
>> > > > Signed-off-by: Dhinakaran Pandiyan 
>> > > > ---
>> > > >  drivers/gpu/drm/tegra/dc.c | 2 +-
>> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > > 
>> > > > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>> > > > index b8403ed48285..49df2db2ad46 100644
>> > > > --- a/drivers/gpu/drm/tegra/dc.c
>> > > > +++ b/drivers/gpu/drm/tegra/dc.c
>> > > > @@ -1359,7 +1359,7 @@ static u32 tegra_dc_get_vblank_counter(struct 
>> > > > drm_crtc *crtc)
>> > > >return host1x_syncpt_read(dc->syncpt);
>> > > >  
>> > > >/* fallback to software emulated VBLANK counter */
>> > > > -  return drm_crtc_vblank_count(>base);
>> > > > +  return (u32)drm_crtc_vblank_count(>base);
>> > 
>> > Isn't this the wrong way around? Shouldn't we instead make the
>> > ->get_vblank_counter() callback return u64 like drm_crtc_vblank_count()?
>> 
>> Here's how I understand this - 
>> 
>> To use the software emulated vblank counter, the driver should set
>> max_vblank_count = 0 and the core takes care of calculating elapsed
>> vblanks.
>> 
>> ->get_vblank_counter() is meant to return the hardware counter if
>> available, which would be a 32-bit value. Hence the explicit typecast to
>> 32-bit for the fallback case too.
>> 
>> Having said that, I believe drm_crtc_accurate_vblank_count() is the
>> appropriate function for fallback.
>
> Hi Thierry,
>
> any further concerns or thoughts here?
>
> I'd like to merge all together on drm-intel since the ones
> around us is kind of blocking us.
>

Hi Thierry,

I was taking a deeper look to the code here and talking to DK.

This patch only aims to bring more clarity to where the crops are happening.

Furthermore making the whole function to return u64 would have
the same effect since it would get cropped one level above.

I believe you are the best one to make the choice for one
way over another, or none, but the result would be the same.

Since this has no functional impact, I'm planing to move with
other patches but leaving this one behind so you can decide later.

If you still have any concerns please let me know.

Thanks,
Rodrigo,

> Thanks,
> Rodrigo.
>
>> 
>> -DK
>> 
>> 
>> 
>> > 
>> > Thierry
>> > ___
>> > Intel-gfx mailing list
>> > intel-...@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] drm: rcar-du: lvds: Refactor LVDS startup

[Sergei Shtylyov]

On 02/14/2018 09:13 PM, Laurent Pinchart wrote:

> From: Sergei Shtylyov 
> 
> After the recent corrections to the R-Car gen2/3 LVDS startup code, already
> similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
> a merge and it's becoming actually necessary with the addition of the R-Car
> V3M (R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.
> 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Laurent Pinchart 
> Tested-by: Laurent Pinchart 

   Well, your role wasn't limited to reviewning/testing, you'd clearly did some 
editing too... thus I was expecting to see some changelog.

> Signed-off-by: Laurent Pinchart 

   Your variant of my patch looks good otherwise. :-)

[...]

MBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[jsanka]

On 2/13/2018 12:00 PM, Rob Clark wrote:

On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:

Hi dri-devel,
Qualcomm has been working for the past few weeks on forward porting their
downstream drm driver from 4.14 to mainline. Please consider this PR as a
request for review, rather than an attempt at mainlining the code as it
currently stands. The goal is get this driver in shape over the next coming
months.

In the meantime, I'll be hosting a tree here [1] to stage the fixes. Patches
will be posted and reviewed on linux-arm-...@vger.kernel.org. Once things look
good, I'll send another pull 4realz.

To get the ball rolling, I've done some review on the new connector code, my
comments are below.

Thanks in advance for your constructive feedback :)

Sean

[1]- git://people.freedesktop.org/~seanpaul/dpu-staging

Review feedback:


just so others aren't confused, s/sde/dpu/g in the list below (we did
our DAL->DC rename before sending first RFC :-P)


- Solve the splash screen handling (or remove it)
- Simplify devicetree binding (remove register offsets)
feedback from reviewing sde_connector.c:
- Rationalize backlight implementation in sde_connector (display_count static)
- Sort out the dsi event passing between dsi/encoder/connector (move to encoder)
- include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)
- connector->state access violations reading/writing mode_info
- s/sde_rect/drm_rect/
- sde_kms_info usage needs to be replaced with formal data structures (not
   stringified keypairs)
- sde_connector_ops needs to be trimmed, duplicates connector helpers, info
   hooks circumvent state, and other hooks should be stored in state or
   prepopulated (get_dst_format)
- sde_connector_get_dpms unused
- esd status check should migrate to encoder from connector
- backlight should be handled in panel drivers, not in the generic connector/dsi
   encoder
- sde_connector_helper_bridge_disable is called from encoder and calls back into
   set_power encoder function. if backlight, and esd status are removed,
   pre_kickoff can probably go away
- sde_connector_clk_ctrl is another example of encoder->connector->encoder call
- RETIRE_FENCE connector property should be removed, opting for the native
   atomic fences
- ROI (regions of interest) should be expressed per-plane instead of connector.
   there is work ongoing to support dirty_rects per-plane by Deepak Singh Rawat
    and Lukasz Spintzyk 
- Uma Shankar  has proposed HDR source metadata
   properties on the list, we should pivot to those instead of hand-rolling them
   in the sde driver
- Convert HDCP implementation to upstream Content Protection property
- Merge dsi and dsi_staging into one driver
- Writeback connector has been proposed by ARM (Liviu Dudau and Brian Starkey),
   we should work with their proposal instead of rolling OUT_FB ourselves
- sde_connector_set_property should be replaced with atomic helper
- dsi hotplug can probably be punted to the panel driver
- dpms should switch to enable/disable (or at least use the atomic helpers)
- dsi mode handling should also defer to the panel driver
- SDE_WB_CONFIG ioctl should be removed in favor of the existing ioctl to add
   user-defined modes
- dp implementation should use the existing dp helpers wherever possible
- lots of duplicated structures in dsi_defs.h that can be replaced with existing
   drm structs
- mode_valid should be split up and implemented directly in connector/encoder as
   appropriate
- sde_connector->aspace seems like it's unused?


To add to that, a few things I've noticed (but I've mostly only gotten
as far as the front-end of the pipeline, ie. dpu_plane):

  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
there are still unequal capabilities for planes (ie. some can do YUV,
scaling, etc).

But drm-hwc (or weston) isn't going to know about that, so I think we'll
need to add support for dynamically assigning dpu_plane::pipe, similar
to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
for drm-hwc ;-))
We are working on plane virtualization focused primarily to support 4K / 
wider displays which cannot
be catered by one hwpipe. The plan is to gang up two *fixed* hwpipes of 
similar capabilities (in terms of formats,
sub hw blocks like scalar, post processing ) and expose them as a single 
plane so that user space
compositor ( drm-hwc or weston) need not worry about max pixel width 
supported by the planes. But mapping
planes <-> hwpipe dynamically may need more than just virtualization. 
Kernel need to keep track of hwpipes
especially when dealing with multiple displays. And it get complicated 
when planes start moving around CRTC's

for different sized buffers.

Given that DRM exposes planes with its own list of format/modifiers, I 
think its not that big of a deal for a

compositor to 

[PATCH v2 0/3] R-Car DU: Fix and refactor LVDS to prepare for V3M support

[Laurent Pinchart]

Hello, 

This patch series fixes the LVDS startup sequence for Gen2 and Gen3
SoCs, and then proceeds to refactoring the code to merge the Gen2 and
Gen3 implementations in preparation for V3M support.

The patches have been previously posted as part of the following series.

[PATCH 0/2] Fix LVDS startup sequences in the R-Car DU driver...
[PATCH 0/3] Add R-Car V3M (R8A77970) support to the R-Car LVDS driver

They have since been rebased on top of the latest DU driver and the
current DRM -next branch.

For convenience the patches can be found at

git://linuxtv.org/pinchartl/media.git drm/next/du

They have been tested on H2 (Lager), H3 ES1.1 (Salvator-X) and H3 ES2.0
(Salvator-XS) without any issue.

The patches that add V3M support have been left out as they depend on
the LVDS encoder move to the DRM bridge API that is not ready for
upstream yet.

Sergei Shtylyov (3):
  drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2
  drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3
  drm: rcar-du: lvds: Refactor LVDS startup

 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 128 --
 1 file changed, 51 insertions(+), 77 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2

[Laurent Pinchart]

From: Sergei Shtylyov 

According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS
and the bias circuit must be enabled after the LVDS I/O pins are
enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.

Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index abbb7b25129a..dcffd3b59b69 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -59,11 +59,8 @@ static void rcar_du_lvdsenc_start_gen2(struct 
rcar_du_lvdsenc *lvds,
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
-   /*
-* Select the input, hardcode mode 0, enable LVDS operation and turn
-* bias circuitry on.
-*/
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
+   /* Select the input and set the LVDS mode. */
+   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
if (rcrtc->index == 2)
lvdcr0 |= LVDCR0_DUSEL;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
@@ -73,6 +70,10 @@ static void rcar_du_lvdsenc_start_gen2(struct 
rcar_du_lvdsenc *lvds,
LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
 
+   /* Enable LVDS operation and turn bias circuitry on. */
+   lvdcr0 |= LVDCR0_BEN | LVDCR0_LVEN;
+   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+
/*
 * Turn the PLL on, wait for the startup delay, and turn the output
 * on.
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/msm: Add generated headers for A6XX

[Jordan Crouse]

From: Sharat Masetty 

Add initial register headers for A6XX targets.

Signed-off-by: Sharat Masetty 
Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1600 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h |  382 +++
 2 files changed, 1982 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
new file mode 100644
index ..17d12414f347
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -0,0 +1,1600 @@
+#ifndef A6XX_XML
+#define A6XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- /local3/projects/drm/envytools/rnndb//adreno.xml   (501 
bytes, from 2017-11-20 17:36:01)
+- /local3/projects/drm/envytools/rnndb//freedreno_copyright.xml  (   1572 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/a2xx.xml  (  32901 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_common.xml (  11792 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_pm4.xml(  17205 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a3xx.xml  (  83693 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a4xx.xml  ( 110372 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a5xx.xml  (  66793 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx.xml  (  44551 
bytes, from 2017-11-20 19:30:19)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx_gmu.xml  (  10431 
bytes, from 2017-11-20 17:59:44)
+- /local3/projects/drm/envytools/rnndb//adreno/ocmem.xml (   1773 
bytes, from 2016-10-24 21:12:27)
+
+Copyright (C) 2013-2017 by the following authors:
+- Rob Clark  (robclark)
+- Ilia Mirkin  (imirkin)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a6xx_cp_perfcounter_select {
+   PERF_CP_ALWAYS_COUNT = 0,
+};
+
+enum a6xx_event_write {
+   PC_CCU_INVALIDATE_DEPTH = 24,
+   PC_CCU_INVALIDATE_COLOR = 25,
+};
+
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPU_IDLE 0x0001
+#define A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR  0x0002
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW   0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPC_ERROR0x0080
+#define A6XX_RBBM_INT_0_MASK_CP_SW 0x0100
+#define A6XX_RBBM_INT_0_MASK_CP_HW_ERROR   0x0200
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_DEPTH_TS 0x0400
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_COLOR_TS 0x0800
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_RESOLVE_TS 0x1000
+#define A6XX_RBBM_INT_0_MASK_CP_IB20x2000
+#define A6XX_RBBM_INT_0_MASK_CP_IB10x4000
+#define A6XX_RBBM_INT_0_MASK_CP_RB 0x8000
+#define A6XX_RBBM_INT_0_MASK_CP_RB_DONE_TS 0x0002
+#define A6XX_RBBM_INT_0_MASK_CP_WT_DONE_TS 0x0004
+#define A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS 0x0010
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_BUS_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT  0x0080
+#define 

[RFC v2 0/2] drm/msm: Add support for Adreno a6xx

[Jordan Crouse]

Brief refresh of the a6xx GPU support for drm/msm
(v1 found here https://patchwork.freedesktop.org/series/37428/)

Thanks to Lucas for his comments, more comments gladly welcomed. I know it is
hard when you are reviewing code that won't be immediately coming to a device
near you but any feedback will make things even better in the end.

Heads up that this code depends on these two stacks to compile:

https://patchwork.freedesktop.org/series/36252/
https://patchwork.codeaurora.org/patch/446409/

Hopefully soon we'll have a git tree somewhere in the world that has everything
built in, but for the meantime some assembly will be required.

[v2: Addressed comments from Lucas Stach, added pm_runtime_get_supplier calls
for accesses to the GMU IOMMU, moved to SPDX headers for the new files]

Jordan Crouse (1):
  drm/msm: Add A6XX device support

Sharat Masetty (1):
  drm/msm: Add generated headers for A6XX

 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx.xml.h  | 1600 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1210 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h  |  382 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  809 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 13 files changed, 4806 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/msm: Add A6XX device support

[Jordan Crouse]

Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself.  Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1210 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  809 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 11 files changed, 2824 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..4affc665c0de 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -10,6 +10,9 @@ msm-y := \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
adreno/a5xx_preempt.o \
+   adreno/a6xx_gpu.o \
+   adreno/a6xx_gmu.o \
+   adreno/a6xx_hfi.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
new file mode 100644
index ..a031c2eaf18c
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -0,0 +1,1210 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "a6xx_gpu.h"
+#include "a6xx_gmu.xml.h"
+
+static irqreturn_t a6xx_gmu_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_STATUS);
+   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, status);
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
+   dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   if (status &  A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
+   dev_err_ratelimited(gmu->dev, "GMU AHB bus error\n");
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
+   dev_err_ratelimited(gmu->dev, "GMU fence error: 0x%x\n",
+   gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS));
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t a6xx_hfi_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO);
+   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, status);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_MSGQ)
+   tasklet_schedule(>hfi_tasklet);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
+   dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   return IRQ_HANDLED;
+}
+
+/* Check to see if the GX rail is still powered */
+static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+{
+   u32 val  = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+   return !(val &
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF |
+   A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
+}
+
+#define GX_OFF_MASK \
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF | \
+A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF)
+
+static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
+{
+   u32 val;
+   int local = gmu->idle_level;
+
+   /* SPTP and IFPC both report as IFPC */
+   if (gmu->idle_level == GMU_IDLE_STATE_SPTP)
+   local = GMU_IDLE_STATE_IFPC;
+
+   val = gmu_read(gmu, REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE);
+
+   if (val == local) {
+   if (gmu->idle_level != GMU_IDLE_STATE_IFPC ||
+   !a6xx_gmu_gx_is_on(gmu))
+   return true;
+   }
+
+   return false;
+}
+
+/* Wait for the GMU to get to its most idle 

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher  ---
(In reply to arne_woerner from comment #17)
> yup:
> i mean: i did not test, which one is necessary...
> so i cannot say, if all three r necessary, or if just one/two of them
> suffice...
> 
> tomorrow i will test "amdgpu.audio=0 amdgpu.msi=0"...
> with the stable linux-firmware package... right?
> 
> or do u mean just "amdgpu.msi=0"?
> maybe hdmi audio works already, if amdgpu.msi is 0?

I doubt the audio parameter would affect anything in this regard, but you said
it was required for the board to work properly?  Is that the case or am I
misinterpreting you?  For audio on your board, you need to enable DC which is
only available on kernel 4.15 and newer.  You can boot with amdgpu.dc=1 to
enable DC.  The msi option may help narrow down the interrupt issue.  If it
helps, it seems MSIs are not working properly on your system after resume. 
This would probably be something outside of the driver if it's a regression.

-- 
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 v2 2/3] drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3

[Laurent Pinchart]

From: Sergei Shtylyov 

According to the latest revisions of the R-Car Gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after -- fix the
Gen3 LVDS startup sequence accordingly.

Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
[Updated comment in rcar_du_lvdsenc_start_gen3()]
[Moved Gen2 startup comment update to separate commit]
[Fixed =| typo]
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index dcffd3b59b69..01ef0f728e94 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -95,7 +95,7 @@ static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc 
*lvds,
u32 lvdcr0;
u32 pllcr;
 
-   /* PLL clock configuration */
+   /* Set the PLL clock configuration and LVDS mode. */
if (freq < 42000)
pllcr = LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
@@ -107,6 +107,9 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
+   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+
/* Turn all the channels on. */
rcar_lvds_write(lvds, LVDCR1,
LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
@@ -116,7 +119,7 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 * Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
+   lvdcr0 |= LVDCR0_PLLON;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
 
lvdcr0 |= LVDCR0_PWD;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/3] drm: rcar-du: lvds: Refactor LVDS startup

[Laurent Pinchart]

From: Sergei Shtylyov 

After the recent corrections to the R-Car gen2/3 LVDS startup code, already
similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
a merge and it's becoming actually necessary with the addition of the R-Car
V3M (R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.

Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 132 --
 1 file changed, 51 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index 01ef0f728e94..4defa8123eb2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -39,102 +39,37 @@ static void rcar_lvds_write(struct rcar_du_lvdsenc *lvds, 
u32 reg, u32 data)
iowrite32(data, lvds->mmio + reg);
 }
 
-static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc *lvds,
-  struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_lvdpllcr_gen2(unsigned int freq)
 {
-   const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int freq = mode->clock;
-   u32 lvdcr0;
-   u32 pllcr;
-
-   /* PLL clock configuration */
if (freq < 39000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
+   return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
else if (freq < 61000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
+   return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
else if (freq < 121000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | 
LVDPLLCR_PLLDLYCNT_121M;
+   return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
else
-   pllcr = LVDPLLCR_PLLDLYCNT_150M;
-
-   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
-   /* Select the input and set the LVDS mode. */
-   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
-   if (rcrtc->index == 2)
-   lvdcr0 |= LVDCR0_DUSEL;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
-   /* Enable LVDS operation and turn bias circuitry on. */
-   lvdcr0 |= LVDCR0_BEN | LVDCR0_LVEN;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /*
-* Turn the PLL on, wait for the startup delay, and turn the output
-* on.
-*/
-   lvdcr0 |= LVDCR0_PLLON;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   usleep_range(100, 150);
-
-   lvdcr0 |= LVDCR0_LVRES;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDLYCNT_150M;
 }
 
-static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
-  struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_lvdpllcr_gen3(unsigned int freq)
 {
-   const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int freq = mode->clock;
-   u32 lvdcr0;
-   u32 pllcr;
-
-   /* Set the PLL clock configuration and LVDS mode. */
if (freq < 42000)
-   pllcr = LVDPLLCR_PLLDIVCNT_42M;
+   return LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
-   pllcr = LVDPLLCR_PLLDIVCNT_85M;
+   return LVDPLLCR_PLLDIVCNT_85M;
else if (freq < 128000)
-   pllcr = LVDPLLCR_PLLDIVCNT_128M;
+   return LVDPLLCR_PLLDIVCNT_128M;
else
-   pllcr = LVDPLLCR_PLLDIVCNT_148M;
-
-   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
-   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
-   /*
-* Turn the PLL on, set it to LVDS normal mode, wait for the startup
-* delay and turn the output on.
-*/
-   lvdcr0 |= LVDCR0_PLLON;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   lvdcr0 |= LVDCR0_PWD;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   usleep_range(100, 150);
-
-   lvdcr0 |= LVDCR0_LVRES;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDIVCNT_148M;
 }
 
 static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
 struct rcar_du_crtc *rcrtc)
 {
+   

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #17 from arne_woer...@yahoo.com ---
(In reply to Alex Deucher from comment #15)
> (In reply to arne_woerner from comment #14)
> > _but_ they both need at least one of these kernel parameters in the 
> > grub.cfg:
> > amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.audio=0
> 
> Can you clarify this last statement?  The first two options are irrelevant
> for your board since it's not SI or CIK.
>
yup:
i mean: i did not test, which one is necessary...
so i cannot say, if all three r necessary, or if just one/two of them
suffice...

tomorrow i will test "amdgpu.audio=0 amdgpu.msi=0"...
with the stable linux-firmware package... right?

or do u mean just "amdgpu.msi=0"?
maybe hdmi audio works already, if amdgpu.msi is 0?

-arne

-- 
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 3/3] drm: rcar-du: lvds: add R8A77970 support

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Friday, 19 January 2018 20:29:21 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the LVDS encoder driver.
> Note that there are some differences with the other R-Car gen3 SoCs, e.g.
> LVDPLLCR has the same layout as in the R-Car gen2 SoCs...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  drivers/gpu/drm/rcar-du/rcar_lvds.c |   21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -32,6 +32,10 @@ enum rcar_lvds_mode {
>  };
> 
>  #define RCAR_LVDS_QUIRK_LANES(1 << 0)/* LVDS lanes 1 and 3 
> inverted */
> +#define RCAR_LVDS_QUIRK_GEN2_PLLCR (1 << 1)  /* LVDPLLCR has gen2-like */
> + /* layout on R8A77970 */
> +#define RCAR_LVDS_QUIRK_PHY  (1 << 2)/* LVDS has PHY on R8A77970 */
> + /* and  R8A7799{0|5} */

I'm not sure if that's the right explanation for this quirk. I assume the LVDS 
encoder to always have a PHY. The difference here is that it needs to be 
explicitly enabled. Note that the LVEN bit also exists in Gen2.

>  struct rcar_lvds_device_info {
>   unsigned int gen;
> @@ -162,6 +166,7 @@ static void rcar_lvds_enable(struct drm_
>*/
>   struct drm_crtc *crtc = lvds->bridge.encoder->crtc;
>   const struct drm_display_mode *mode = >display_mode;
> + unsigned int quirks = lvds->info->quirks;
>   unsigned int gen = lvds->info->gen;
>   u32 lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
>   u32 lvdpllcr;
> @@ -186,7 +191,7 @@ static void rcar_lvds_enable(struct drm_
>   LVDCTRCR_CTR2SEL_DISP | LVDCTRCR_CTR1SEL_VSYNC |
>   LVDCTRCR_CTR0SEL_HSYNC);
> 
> - if (lvds->info->quirks & RCAR_LVDS_QUIRK_LANES)
> + if (quirks & RCAR_LVDS_QUIRK_LANES)
>   lvdhcr = LVDCHCR_CHSEL_CH(0, 0) | LVDCHCR_CHSEL_CH(1, 3)
> 
>  | LVDCHCR_CHSEL_CH(2, 2) | LVDCHCR_CHSEL_CH(3, 1);
> 
>   else
> @@ -195,7 +200,7 @@ static void rcar_lvds_enable(struct drm_
>   rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
> 
>   /* PLL clock configuration */
> - if (gen < 3)
> + if (gen < 3 || quirks & RCAR_LVDS_QUIRK_GEN2_PLLCR)

I'd set the RCAR_LVDS_QUIRK_GEN2_PLLCR flag in all the Gen2 
rcar_lvds_device_info instances, and remove the gen check here.

>   lvdpllcr = rcar_lvds_lvdpllcr_gen2(mode->clock);
>   else
>   lvdpllcr = rcar_lvds_lvdpllcr_gen3(mode->clock);
> @@ -227,6 +232,12 @@ static void rcar_lvds_enable(struct drm_
>   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
>   }
> 
> + if (quirks & RCAR_LVDS_QUIRK_PHY) {
> + /* Turn on the LVDS PHY. */
> + lvdcr0 |= LVDCR0_LVEN;
> + rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + }
> +
>   /* Wait for the startup delay. */
>   usleep_range(100, 150);
> 
> @@ -499,6 +510,11 @@ static const struct rcar_lvds_device_inf
>   .gen = 3,
>  };
> 
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77970_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_PHY,
> +};
> +
>  static const struct of_device_id rcar_lvds_of_table[] = {
>   { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info 
> },
> @@ -506,6 +522,7 @@ static const struct of_device_id rcar_lv
>   { .compatible = "renesas,r8a7793-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info },
>   { .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info },
> + { .compatible = "renesas,r8a77970-lvds", .data = 
> _lvds_r8a77970_info
> }, { }
>  };

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

[Sylwester Nawrocki]

Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0,
not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2
constant and adds missing HDMI_I2S_SEL_DATA0.
The value of bit field selecting SDATA_1 (pin_sel_3) is also changed,
so it is 3 as suggested in the Exynos TRMs.

Signed-off-by: Sylwester Nawrocki 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +--
 drivers/gpu/drm/exynos/regs-hdmi.h   | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a4b75a46f946..abd84cbcf1c2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1068,10 +1068,13 @@ static void hdmi_audio_config(struct hdmi_context 
*hdata)
/* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
| HDMI_I2S_SEL_LRCK(6));
-   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
-   | HDMI_I2S_SEL_SDATA2(4));
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(3)
+   | HDMI_I2S_SEL_SDATA0(4));
+
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_2, HDMI_I2S_SEL_SDATA3(1)
| HDMI_I2S_SEL_SDATA2(2));
+
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_3, HDMI_I2S_SEL_DSD(0));
 
/* I2S_CON_1 & 2 */
diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
b/drivers/gpu/drm/exynos/regs-hdmi.h
index 04be0f7e8193..4420c203ac85 100644
--- a/drivers/gpu/drm/exynos/regs-hdmi.h
+++ b/drivers/gpu/drm/exynos/regs-hdmi.h
@@ -464,7 +464,7 @@
 
 /* I2S_PIN_SEL_1 */
 #define HDMI_I2S_SEL_SDATA1(x) (((x) & 0x7) << 4)
-#define HDMI_I2S_SEL_SDATA2(x) ((x) & 0x7)
+#define HDMI_I2S_SEL_SDATA0(x) ((x) & 0x7)
 
 /* I2S_PIN_SEL_2 */
 #define HDMI_I2S_SEL_SDATA3(x) (((x) & 0x7) << 4)
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

[Sylwester Nawrocki]

Hi Inki,

On 02/14/2018 06:57 AM, Inki Dae wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a4b75a46f946..abd84cbcf1c2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -1068,10 +1068,13 @@ static void hdmi_audio_config(struct hdmi_context 
>> *hdata)
>>  /* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
>>  hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
>>  | HDMI_I2S_SEL_LRCK(6));
>> -hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
>> -| HDMI_I2S_SEL_SDATA2(4));
>> +
>> +hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(3)
>
> Seems you fixed pin_sel_3 field value of I2S_PIN_SEL_1 register. According 
> to datasheet, 0x3 should be set to this field to select SDATA_1 not 0x1.
> So could you update the description of this patch?

Indeed, I finally missed that when I was writing the commit message. 
I've posted v2 already.

-- 
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/msm/adreno: Add A6XX device support

[Jordan Crouse]

On Thu, Feb 01, 2018 at 11:32:25AM +0100, Lucas Stach wrote:
> Hi Jordan,
> 
> just some drive-by comments:

Drive by comments are the best.

> Am Mittwoch, den 31.01.2018, 11:25 -0700 schrieb Jordan Crouse:
> > Add support for the A6XX family of Adreno GPUs. The biggest addition
> > is the GMU (Graphics Management Unit) which takes over most of the
> > power management of the GPU itself but in a ironic twist of fate
> > needs a goodly amount of management itself. Add support for the
> > A6XX core code, the GMU and the HFI (hardware firmware interface)
> > queue that the CPU uses to communicate with the GMU.
> > 
> > > Signed-off-by: Jordan Crouse 
> > ---
> [...]
> > +static int a6xx_hfi_queue_read(struct a6xx_hfi_queue *queue, u32 *data,
> > > + u32 dwords)
> > +{
> > > + struct a6xx_hfi_queue_header *header = queue->header;
> > > + u32 i, hdr, index = header->read_index;
> > +
> > > + if (header->read_index == header->write_index) {
> > > + header->rx_request = 1;
> > > + return 0;
> > > + }
> > +
> > > + hdr = queue->data[index];
> > +
> > > + /*
> > > +  * If we are to assume that the GMU firmware is in fact a rational actor
> > > +  * and is programmed to not send us a larger response than we expect
> > > +  * then we can also assume that if the header size is unexpectedly large
> > > +  * that it is due to memory corruption and/or hardware failure. In this
> > > +  * case the only reasonable course of action is to BUG() to help harden
> > > +  * the failure.
> > > +  */
> > +
> > +   BUG_ON(HFI_HEADER_SIZE(hdr) > dwords);
> 
> Don't ever BUG the kernel due to a peripheral acting up, until you are
> really certain that it has corrupted memory it doesn't own, which would
> be written back to persistent storage. That's the only valid
> justification for a BUG.

Acknowledged. In the final version we'll try to zap the hardware and recover
cleanly but I don't have that coded up yet.  Don't worry, I wouldn't let it
merge with a BUG().

> > +
> > > + for (i = 0; i < HFI_HEADER_SIZE(hdr); i++) {
> > > + data[i] = queue->data[index];
> > > + index = (index + 1) % header->size;
> > > + }
> > +
> > > + header->read_index = index;
> > > + return HFI_HEADER_SIZE(hdr);
> > +}
> > +
> > +static int a6xx_hfi_queue_write(struct a6xx_gmu *gmu,
> > > + struct a6xx_hfi_queue *queue, u32 *data, u32 dwords)
> > +{
> > > + struct a6xx_hfi_queue_header *header = queue->header;
> > > + u32 i, space, index = header->write_index;
> > +
> > > + spin_lock(>lock);
> > +
> > > + space = CIRC_SPACE(header->write_index, header->read_index,
> > > + header->size);
> > > + if (space < dwords) {
> > > + header->dropped++;
> > > + spin_unlock(>lock);
> > > + return -ENOSPC;
> > > + }
> > +
> > > + for (i = 0; i < dwords; i++) {
> > > + queue->data[index] = data[i];
> > > + index = (index + 1) % header->size;
> > > + }
> > +
> > > + header->write_index = index;
> > > + spin_unlock(>lock);
> > +
> > > + /* Make sure the command is written to the queue */
> > > + wmb();
> 
> The above memory barrier is unnecessary. The gmu_write below is a
> wrapper around writel, which already includes the write barrier.

Thanks.  I got this one and a few others I found too.

> > +   gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET, 0x01);
> > > + return 0;
> > +}
> 
> [...]
> > +static int a6xx_hfi_send_msg(struct a6xx_gmu *gmu, int id,
> > > + void *data, u32 size, u32 *payload, u32 payload_size)
> > +{
> > > + struct a6xx_hfi_queue *queue = >queues[HFI_COMMAND_QUEUE];
> > > + struct a6xx_hfi_response resp = { 0 };
> > > + int ret, dwords = size >> 2;
> > > + u32 seqnum;
> > +
> > > + seqnum = atomic_inc_return(>seqnum) % 0xfff;
> > +
> > > + /* First dword of the message is the message header - fill it in */
> > > + *((u32 *) data) = (seqnum << 20) | (HFI_MSG_CMD << 16) |
> > > + (dwords << 8) | id;
> > +
> > > + init_completion();
> > > + resp.id = id;
> > > + resp.seqnum = seqnum;
> > +
> > > + spin_lock_bh(_ack_lock);
> > > + list_add_tail(, _ack_list);
> > > + spin_unlock_bh(_ack_lock);
> 
> What are you protecting against here by using the _bh spinlock
> variants?

We use a tasklet from the interrupt to process responses. The
commands are entirely serialized right now so this is mostly wasted
cycles but we are planning for a brave future where the commands
may be asynchronous.

> Regards,
> Lucas

Thanks,
Jordan
-- 
The 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

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Laurent Pinchart]

Hi Sergei,

On Tuesday, 16 January 2018 17:42:41 EET Laurent Pinchart wrote:
> On Saturday, 13 January 2018 11:25:31 EET Sergei Shtylyov wrote:
> > On 1/13/2018 1:15 AM, Laurent Pinchart wrote:
>  According to the latest revisions of the R-Car gen3 manual, the LVDS
>  mode must be set before the LVDS I/O pins are enabled, not after -- 
>  fix the gen3 LVDS startup sequence accordingly...
>  
>  While  at it,  also fix the comment  preceding the first LVDCR0 write
>  in the R-Car gen2 startup code that still talks about hardcoding the
>  LVDS mode 0...
> >>> 
> >>> How about fixing that in patch 2/2 that touches the Gen2 initialization
> >>> sequence ? I think I'd even go as far as squashing both patches, I
> >>> don't think there's a need to split them.
> >>> 
>  Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode
>  selection")
>  Signed-off-by: Sergei Shtylyov 
> >>> 
> >>> Is this really needed ? Does it fix a problem you've experienced, or is
> >>> it theoretical only ? The mode shouldn't matter before the LVDS
> >>> internal logic is turned on. Unless there's a real issue I'm not sure we
> >>> should make the code more complex.
> >> 
> >> Furthermore the datasheet states
> >> 
> >> "3. This refers to settings other than those that are concerned with
> >> LVDS-IF startup. These items may be set while waiting for the conditions
> >> of step 6 to be met."
> > 
> > Ah, I hadn't paid much attention to this note. Howeve, it seems quite
> > vague to me... and there's no condition in step 6. ;-)
> 
> Lots of bits and pieces are lost in translation yes :-)
> 
> >> Doesn't this mean that the mode and input selector don't have to be set
> >> as the very first step, but can be programmed at any point before
> >> starting the LVDS encoder through the PWD bit (on Gen3) or the PLLON bit
> >> (on Gen2) ?
> > 
> > Frankly speaking, I don't know how to interpret that note...
> 
> My understanding is that the parameters can be programmed at any time before
> step 6. The fact that the current code works seems to confirm that
> interpretation. We could ask Renesas for a confirmation if you want.

I've received feedback, and while it wasn't clear what the not really means, 
Renesas recommends following the documented startup sequence (I'm still not 
sure it's really needed, but that's a different story). I'll thus rebase this 
patch and repost it, and take it in my tree if you're fine with the result.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rcar-du: lvds: Fix LVDS clock frequency range

[Sergei Shtylyov]

On 01/13/2018 12:40 AM, Laurent Pinchart wrote:

> According to the latest versions of both the Gen2 and Gen3 datasheets,
> the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all

   Not quite so with R-Car D3/E3 (which have the low boundary of 5 MHz) But we 
don't
support them yet anyway...

> SoCs. Update the driver accordingly.
> 
> Signed-off-by: Laurent Pinchart 
[...]

Acked-by: Sergei Shtylyov 

MBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFT PATCH] drm/msm: Trigger fence completion from GPU

[Rob Clark]

On Wed, Feb 14, 2018 at 1:46 AM, Bjorn Andersson
 wrote:
> Interrupt commands causes the CP to trigger an interrupt as the command
> is processed, regardless of the GPU being done processing previous
> commands. This is seen by the interrupt being delivered before the
> fence is written on 8974 and is likely the cause of the additional
> CP_WAIT_FOR_IDLE workaround found for a306, which would cause the CP to
> wait for the GPU to go idle before triggering the interrupt.
>
> Instead we can set the (undocumented) BIT(31) of the CACHE_FLUSH_TS
> which will cause a special CACHE_FLUSH_TS interrupt to be triggered from
> the GPU as the write event is processed.
>
> Add CACHE_FLUSH_TS to the IRQ masks of A3xx and A4xx and remove the
> workaround for A306.
>
> Suggested-by: Jordan Crouse 
> Signed-off-by: Bjorn Andersson 
> ---
>
> This is only tested on 8974.

Tested on db410c (8016).. thanks

BR,
-R

>
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 ++
>  3 files changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 4baef2738178..a3a43be920d0 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -35,6 +35,7 @@
>  A3XX_INT0_CP_RB_INT | \
>  A3XX_INT0_CP_REG_PROTECT_FAULT |  \
>  A3XX_INT0_CP_AHB_ERROR_HALT | \
> +A3XX_INT0_CACHE_FLUSH_TS |\
>  A3XX_INT0_UCHE_OOB_ACCESS)
>
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index 8199a4b9f2fa..b44cd0d90621 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -27,6 +27,7 @@
>  A4XX_INT0_CP_RB_INT | \
>  A4XX_INT0_CP_REG_PROTECT_FAULT |  \
>  A4XX_INT0_CP_AHB_ERROR_HALT | \
> +A4XX_INT0_CACHE_FLUSH_TS |\
>  A4XX_INT0_UCHE_OOB_ACCESS)
>
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index de63ff26a062..5806f9942514 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -293,26 +293,12 @@ void adreno_submit(struct msm_gpu *gpu, struct 
> msm_gem_submit *submit,
> OUT_RING(ring, 0x);
> }
>
> +   /* BIT(31) of CACHE_FLUSH_TS triggers CACHE_FLUSH_TS IRQ from GPU */
> OUT_PKT3(ring, CP_EVENT_WRITE, 3);
> -   OUT_RING(ring, CACHE_FLUSH_TS);
> +   OUT_RING(ring, CACHE_FLUSH_TS | BIT(31));
> OUT_RING(ring, rbmemptr(ring, fence));
> OUT_RING(ring, submit->seqno);
>
> -   /* we could maybe be clever and only CP_COND_EXEC the interrupt: */
> -   OUT_PKT3(ring, CP_INTERRUPT, 1);
> -   OUT_RING(ring, 0x8000);
> -
> -   /* Workaround for missing irq issue on 8x16/a306.  Unsure if the
> -* root cause is a platform issue or some a306 quirk, but this
> -* keeps things humming along:
> -*/
> -   if (adreno_is_a306(adreno_gpu)) {
> -   OUT_PKT3(ring, CP_WAIT_FOR_IDLE, 1);
> -   OUT_RING(ring, 0x);
> -   OUT_PKT3(ring, CP_INTERRUPT, 1);
> -   OUT_RING(ring, 0x8000);
> -   }
> -
>  #if 0
> if (adreno_is_a3xx(adreno_gpu)) {
> /* Dummy set-constant to trigger context rollover */
> --
> 2.15.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] DT: display: renesas, lvds: document R8A77970 bindings

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Friday, 19 January 2018 20:29:20 EET Sergei Shtylyov wrote:
> Document the R-Car V3M (R8A77970) SoC in the R-Car LVDS bindings.
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 +
>  1 file changed, 1 insertion(+)
> 
> Index:
> linux/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> === ---
> linux.orig/Documentation/devicetree/bindings/display/bridge/renesas,lvds.tx
> t +++
> linux/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@
> -13,6 +13,7 @@ Required properties:
>- "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS
> encoders - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS
> encoders - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS
> encoders +  - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible
> LVDS encoders
> 
>  - reg: Base address and length for the memory-mapped registers
>  - clocks: A phandle + clock-specifier pair for the functional clock

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFT PATCH] drm/msm: Trigger fence completion from GPU

[Jordan Crouse]

On Tue, Feb 13, 2018 at 10:46:58PM -0800, Bjorn Andersson wrote:
> Interrupt commands causes the CP to trigger an interrupt as the command
> is processed, regardless of the GPU being done processing previous
> commands. This is seen by the interrupt being delivered before the
> fence is written on 8974 and is likely the cause of the additional
> CP_WAIT_FOR_IDLE workaround found for a306, which would cause the CP to
> wait for the GPU to go idle before triggering the interrupt.
> 
> Instead we can set the (undocumented) BIT(31) of the CACHE_FLUSH_TS
> which will cause a special CACHE_FLUSH_TS interrupt to be triggered from
> the GPU as the write event is processed.
> 
> Add CACHE_FLUSH_TS to the IRQ masks of A3xx and A4xx and remove the
> workaround for A306.
> 
> Suggested-by: Jordan Crouse 
> Signed-off-by: Bjorn Andersson 

LGTM. This should help your races.

> ---
> 
> This is only tested on 8974.
> 
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 ++
>  3 files changed, 4 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 4baef2738178..a3a43be920d0 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -35,6 +35,7 @@
>A3XX_INT0_CP_RB_INT | \
>A3XX_INT0_CP_REG_PROTECT_FAULT |  \
>A3XX_INT0_CP_AHB_ERROR_HALT | \
> +  A3XX_INT0_CACHE_FLUSH_TS |\
>A3XX_INT0_UCHE_OOB_ACCESS)
>  
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index 8199a4b9f2fa..b44cd0d90621 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -27,6 +27,7 @@
>A4XX_INT0_CP_RB_INT | \
>A4XX_INT0_CP_REG_PROTECT_FAULT |  \
>A4XX_INT0_CP_AHB_ERROR_HALT | \
> +  A4XX_INT0_CACHE_FLUSH_TS |\
>A4XX_INT0_UCHE_OOB_ACCESS)
>  
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index de63ff26a062..5806f9942514 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -293,26 +293,12 @@ void adreno_submit(struct msm_gpu *gpu, struct 
> msm_gem_submit *submit,
>   OUT_RING(ring, 0x);
>   }
>  
> + /* BIT(31) of CACHE_FLUSH_TS triggers CACHE_FLUSH_TS IRQ from GPU */
>   OUT_PKT3(ring, CP_EVENT_WRITE, 3);
> - OUT_RING(ring, CACHE_FLUSH_TS);
> + OUT_RING(ring, CACHE_FLUSH_TS | BIT(31));
>   OUT_RING(ring, rbmemptr(ring, fence));
>   OUT_RING(ring, submit->seqno);
>  
> - /* we could maybe be clever and only CP_COND_EXEC the interrupt: */
> - OUT_PKT3(ring, CP_INTERRUPT, 1);
> - OUT_RING(ring, 0x8000);
> -
> - /* Workaround for missing irq issue on 8x16/a306.  Unsure if the
> -  * root cause is a platform issue or some a306 quirk, but this
> -  * keeps things humming along:
> -  */
> - if (adreno_is_a306(adreno_gpu)) {
> - OUT_PKT3(ring, CP_WAIT_FOR_IDLE, 1);
> - OUT_RING(ring, 0x);
> - OUT_PKT3(ring, CP_INTERRUPT, 1);
> - OUT_RING(ring, 0x8000);
> - }
> -
>  #if 0
>   if (adreno_is_a3xx(adreno_gpu)) {
>   /* Dummy set-constant to trigger context rollover */
> -- 
> 2.15.0
> 

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

Re: [PATCH] drm: rcar-du: Enable VSP compositor by default on Gen3

[Kieran Bingham]

Hi Laurent,

Thankyou for the patch.

On 12/01/18 03:20, Laurent Pinchart wrote:
> On Gen3 hardware the VSP compositor is required for display. Enable it
> by default in the kernel configuration. The option is kept
> user-configurable for testing purpose on Gen2 platforms.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 


> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 1d6f1b849287..2b104daf56eb 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -27,7 +27,8 @@ config DRM_RCAR_LVDS
> Enable support for the R-Car Display Unit embedded LVDS encoders.
>  
>  config DRM_RCAR_VSP
> - bool "R-Car DU VSP Compositor Support"
> + bool "R-Car DU VSP Compositor Support" if ARM
> + default y if ARM64
>   depends on DRM_RCAR_DU
>   depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
>   help
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[Rob Clark]

On Tue, Feb 13, 2018 at 3:00 PM, Rob Clark  wrote:
> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:
>> Hi dri-devel,
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request for review, rather than an attempt at mainlining the code as it
>> currently stands. The goal is get this driver in shape over the next coming
>> months.
>>
>> In the meantime, I'll be hosting a tree here [1] to stage the fixes. Patches
>> will be posted and reviewed on linux-arm-...@vger.kernel.org. Once things 
>> look
>> good, I'll send another pull 4realz.
>>
>> To get the ball rolling, I've done some review on the new connector code, my
>> comments are below.
>>
>> Thanks in advance for your constructive feedback :)
>>
>> Sean
>>
>> [1]- git://people.freedesktop.org/~seanpaul/dpu-staging
>>
>> Review feedback:
>> 
>
> just so others aren't confused, s/sde/dpu/g in the list below (we did
> our DAL->DC rename before sending first RFC :-P)
>
>> - Solve the splash screen handling (or remove it)
>> - Simplify devicetree binding (remove register offsets)
>> feedback from reviewing sde_connector.c:
>> - Rationalize backlight implementation in sde_connector (display_count 
>> static)
>> - Sort out the dsi event passing between dsi/encoder/connector (move to 
>> encoder)
>> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)
>> - connector->state access violations reading/writing mode_info
>> - s/sde_rect/drm_rect/
>> - sde_kms_info usage needs to be replaced with formal data structures (not
>>   stringified keypairs)
>> - sde_connector_ops needs to be trimmed, duplicates connector helpers, info
>>   hooks circumvent state, and other hooks should be stored in state or
>>   prepopulated (get_dst_format)
>> - sde_connector_get_dpms unused
>> - esd status check should migrate to encoder from connector
>> - backlight should be handled in panel drivers, not in the generic 
>> connector/dsi
>>   encoder
>> - sde_connector_helper_bridge_disable is called from encoder and calls back 
>> into
>>   set_power encoder function. if backlight, and esd status are removed,
>>   pre_kickoff can probably go away
>> - sde_connector_clk_ctrl is another example of encoder->connector->encoder 
>> call
>> - RETIRE_FENCE connector property should be removed, opting for the native
>>   atomic fences
>> - ROI (regions of interest) should be expressed per-plane instead of 
>> connector.
>>   there is work ongoing to support dirty_rects per-plane by Deepak Singh 
>> Rawat
>>    and Lukasz Spintzyk 
>> - Uma Shankar  has proposed HDR source metadata
>>   properties on the list, we should pivot to those instead of hand-rolling 
>> them
>>   in the sde driver
>> - Convert HDCP implementation to upstream Content Protection property
>> - Merge dsi and dsi_staging into one driver
>> - Writeback connector has been proposed by ARM (Liviu Dudau and Brian 
>> Starkey),
>>   we should work with their proposal instead of rolling OUT_FB ourselves
>> - sde_connector_set_property should be replaced with atomic helper
>> - dsi hotplug can probably be punted to the panel driver
>> - dpms should switch to enable/disable (or at least use the atomic helpers)
>> - dsi mode handling should also defer to the panel driver
>> - SDE_WB_CONFIG ioctl should be removed in favor of the existing ioctl to add
>>   user-defined modes
>> - dp implementation should use the existing dp helpers wherever possible
>> - lots of duplicated structures in dsi_defs.h that can be replaced with 
>> existing
>>   drm structs
>> - mode_valid should be split up and implemented directly in 
>> connector/encoder as
>>   appropriate
>> - sde_connector->aspace seems like it's unused?
>>
>
> To add to that, a few things I've noticed (but I've mostly only gotten
> as far as the front-end of the pipeline, ie. dpu_plane):
>
>  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
>there are still unequal capabilities for planes (ie. some can do YUV,
>scaling, etc).
>
>But drm-hwc (or weston) isn't going to know about that, so I think we'll
>need to add support for dynamically assigning dpu_plane::pipe, similar
>to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
>for drm-hwc ;-))
>
>  - I *think* we also need the same trick for combining mixers under one CRTC
>for 4k modes too?
>
>  - in dpu_plane, and perhaps elsewhere, userspace pointers for things like CSC
>and scaling coefficients need to be annotated w/ __user.  (Except the 
> should
>probably be blob properties instead.. and we probably need to strip out the
>custom properties and re-introduce them separately with some userspace +
>review.)
>
>  - dpu_formats.c looks mostly like a superset of mdp_format.c, ie there is 

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

--- Comment #18 from Ainola  ---
I applied the patch to 4.15.3 on archlinux and have tested with xset dpms force
{standby,suspend} with success.

-- 
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: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Rob Clark]

On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse  wrote:
> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
>>
>> - When submitting commands to the GPU, the GPU driver will
>> pm_runtime_get_sync() on the GPU device, which will automatically do
>> the same on all the linked suppliers, which would also include the
>> SMMU itself. The role of device links here is exactly that the GPU
>> driver doesn't have to care which other devices need to be brought up.
>
> This is true.  Assuming that the device link works correctly we would not need
> to explicitly power the SMMU which makes my point entirely moot.

Just to point out what motivated this patchset, the biggest problem is
iommu_unmap() because that can happen when GPU is not powered on (or
in the v4l2 case, because some other device dropped it's reference to
the dma-buf allowing it to be free'd).  Currently we pm get/put the
GPU device around unmap, but it is kinda silly to boot up the GPU just
to unmap a buffer.

(Semi-related, I would also like to batch map/unmap's, I just haven't
gotten around to implementing it yet.. but that would be another case
where a single get_supplier()/put_supplier() outside of the iommu
would make sense instead of pm_get/put() inside the iommu driver's
->unmap().)

If you really dislike the get/put_supplier() approach, then perhaps we
need iommu_pm_get()/iommu_pm_put() operations that the iommu user
could use to accomplish the same thing?

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Robin Murphy]

On 14/02/18 10:33, Vivek Gautam wrote:

On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa  wrote:

Adding Jordan to this thread as well.


On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
 wrote:

Hi Tomasz,

On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa  wrote:

On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
 wrote:

Hi Tomasz,

On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa  wrote:

On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark  wrote:

On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa  wrote:

On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark  wrote:

On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa  wrote:

Hi Vivek,

Thanks for the patch. Please see my comments inline.

On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
 wrote:

While handling the concerned iommu, there should not be a
need to power control the drm devices from iommu interface.
If these drm devices need to be powered around this time,
the respective drivers should take care of this.

Replace the pm_runtime_get/put_sync() with
pm_runtime_get/put_suppliers() calls, to power-up
the connected iommu through the device link interface.
In case the device link is not setup these get/put_suppliers()
calls will be a no-op, and the iommu driver should take care of
powering on its devices accordingly.

Signed-off-by: Vivek Gautam 
---
  drivers/gpu/drm/msm/msm_iommu.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..1ab629bbee69 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char * 
const *names,
 struct msm_iommu *iommu = to_msm_iommu(mmu);
 int ret;

-   pm_runtime_get_sync(mmu->dev);
+   pm_runtime_get_suppliers(mmu->dev);
 ret = iommu_attach_device(iommu->domain, mmu->dev);
-   pm_runtime_put_sync(mmu->dev);
+   pm_runtime_put_suppliers(mmu->dev);


For me, it looks like a wrong place to handle runtime PM of IOMMU
here. iommu_attach_device() calls into IOMMU driver's attach_device()
callback and that's where necessary runtime PM gets should happen, if
any. In other words, driver A (MSM DRM driver) shouldn't be dealing
with power state of device controlled by driver B (ARM SMMU).


Note that we end up having to do the same, because of iommu_unmap()
while DRM driver is powered off..  it might be cleaner if it was all
self contained in the iommu driver, but that would make it so other
drivers couldn't call iommu_unmap() from an irq handler, which is
apparently something that some of them want to do..


I'd assume that runtime PM status is already guaranteed to be active
when the IRQ handler is running, by some other means (e.g.
pm_runtime_get_sync() called earlier, when queuing some work to the
hardware). Otherwise, I'm not sure how a powered down device could
trigger an IRQ.

So, if the master device power is already on, suppliers should be
powered on as well, thanks to device links.



umm, that is kindof the inverse of the problem..  the problem is
things like gpu driver (and v4l2 drivers that import dma-buf's,
afaict).. they will potentially call iommu->unmap() when device is not
active (due to userspace or things beyond the control of the driver)..
so *they* would want iommu to do pm get/put calls.


Which is fine and which is actually already done by one of the patches
in this series, not for map/unmap, but probe, add_device,
remove_device. Having parts of the API doing it inside the callback
and other parts outside sounds at least inconsistent.


But other drivers
trying to unmap from irq ctx would not.  Which is the contradictory
requirement that lead to the idea of iommu user powering up iommu for
unmap.


Sorry, maybe I wasn't clear. My last message was supposed to show that
it's not contradictory at all, because "other drivers trying to unmap
from irq ctx" would already have called pm_runtime_get_*() earlier
from a non-irq ctx, which would have also done the same on all the
linked suppliers, including the IOMMU. The ultimate result would be
that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync()
would do nothing besides incrementing the reference count.


The entire point was to avoid the slowpath that pm_runtime_get/put_sync()
would add in map/unmap. It would not be correct to add a slowpath in irq_ctx
for taking care of non-irq_ctx and for the situations where master is already
powered-off.


Correct me if I'm wrong, but I believe that with what I'm proposing
there wouldn't be any slow path.


Yea, but only when the power domain is irq-safe? And not all platforms
enable irq-safe power domains. For instance, msm doesn't enable its

Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically

[Tomi Valkeinen]

On 14/02/18 17:39, Laurent Pinchart wrote:

>> I have to admit I didn't go through every line of the patches, but
>> overall I think this looks good. The only problem is the support for
>> DSS6, which I mentioned in the other mail.
>>
>> We don't have DSS6 support in mainline, but it's a critical thing for TI
>> to support. If it helps, we can upstream the current DSS6 driver (which
>> is not very big), so that these can be reworked with DSS6 included. Or
>> we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6
>> driver working on top of these (which, afaics, is not possible at the
>> moment).
> 
> Following up our discussion in reply to another e-mail in this thread, would 
> switching to struct device pointers for DSS and DISPC objects in the public 
> API help ? Is there anything else preventing DSS6 from working on top of this 

I think using struct device pointers should be enough to get DSS6
working, but we need to try it out. And, as you pointed out, the structs
are opaque to omapdrm, so if we're sure they don't leak to omapdrm and
don't mix up between dss2-5 and dss6 drivers, we could even use the same
struct. But I think that's rather messy, so if we do that it should be
just a temporary measure.

> series ? I would personally prefer getting the cleanups and reworks 
> (including 
> the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in 
> mainline, as the problem is already complex enough.

I agree, but then, I've been pushing the upstreaming of DSS6 driver
forward for a very long time already. And, it does create these kind of
issue, making it very laborious to carry in TI's tree. So, I'm fine with
waiting still a bit longer, but if the bridge/panel work gets delayed,
I'd rather push DSS6.

I made a quick branch on top of drm-next which contains the DSS6:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
4.17/omapdrm-dss6-test

The first three patches have already been posted for review, and the
last three and not that relevant here.

It's essentially a simplified version of the old DSS, with slightly
different registers.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Jordan Crouse]

On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
> Hi Jordan,
> 
> On Wed, Feb 14, 2018 at 1:42 AM, Jordan Crouse  wrote:
> > On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
> >> Hi Vivek,
> >>
> >> Thanks for the patch. Please see my comments inline.
> >>
> >> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> >>  wrote:
> >> > While handling the concerned iommu, there should not be a
> >> > need to power control the drm devices from iommu interface.
> >> > If these drm devices need to be powered around this time,
> >> > the respective drivers should take care of this.
> >> >
> >> > Replace the pm_runtime_get/put_sync() with
> >> > pm_runtime_get/put_suppliers() calls, to power-up
> >> > the connected iommu through the device link interface.
> >> > In case the device link is not setup these get/put_suppliers()
> >> > calls will be a no-op, and the iommu driver should take care of
> >> > powering on its devices accordingly.
> >> >
> >> > Signed-off-by: Vivek Gautam 
> >> > ---
> >> >  drivers/gpu/drm/msm/msm_iommu.c | 16 
> >> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
> >> > b/drivers/gpu/drm/msm/msm_iommu.c
> >> > index b23d33622f37..1ab629bbee69 100644
> >> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> >> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> >> > @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const 
> >> > char * const *names,
> >> > struct msm_iommu *iommu = to_msm_iommu(mmu);
> >> > int ret;
> >> >
> >> > -   pm_runtime_get_sync(mmu->dev);
> >> > +   pm_runtime_get_suppliers(mmu->dev);
> >> > ret = iommu_attach_device(iommu->domain, mmu->dev);
> >> > -   pm_runtime_put_sync(mmu->dev);
> >> > +   pm_runtime_put_suppliers(mmu->dev);
> >>
> >> For me, it looks like a wrong place to handle runtime PM of IOMMU
> >> here. iommu_attach_device() calls into IOMMU driver's attach_device()
> >> callback and that's where necessary runtime PM gets should happen, if
> >> any. In other words, driver A (MSM DRM driver) shouldn't be dealing
> >> with power state of device controlled by driver B (ARM SMMU).
> >
> > This whole thing is confused by the fact that on MSM the GPU and the GPU 
> > IOMMU
> > share some of the same clocks and power rail so turning on the GPU also
> > turned on the IOMMU register banks by extension.
> 
> This is surprisingly not a very surprising case. Exactly the same can
> be seen on Rockchip SoCs and we're solving the problem using the
> solution I suggested. In fact, my suggestions to this thread are based
> on the design we chose for Rockchip, due to the high level of
> similarity (+/- the GPU directly programming IOMMU registers, which is
> not present there, but AFAICT it doesn't pose a problem here).
> 
> >
> > But if we put that aside the question is who should be responsible for
> > controlling the power in this relationship and there are several good 
> > reasons to
> > leave it up to the client device. The most important reason is when we move 
> > to
> > the per-instance model where the GPU self-programmings the SMMU registers. 
> > In
> > that case, the driver will need to make sure that the SMMU is powered up 
> > before
> > submitting the command and then removing the power vote when the commands
> > are done to save energy.
> 
> I might need more insight on what's going on in your hardware, but
> with my current understanding I'd argue that that is not right,
> because:
> 
> - When submitting commands to the GPU, the GPU driver will
> pm_runtime_get_sync() on the GPU device, which will automatically do
> the same on all the linked suppliers, which would also include the
> SMMU itself. The role of device links here is exactly that the GPU
> driver doesn't have to care which other devices need to be brought up.

This is true.  Assuming that the device link works correctly we would not need
to explicitly power the SMMU which makes my point entirely moot.

> - When the GPU is operating, the SMMU power must be supplied anyway,
> because it needs to be doing the translations, right? Note that by
> "power" I really mean the physical power supply in the SoC, e.g. as
> for a power domain. The runtime PM API in its current form (e.g.
> binary off or on operation) is unsuitable for managing other things,
> such as clocks (and there is ongoing work on improving it, e.g. by
> adding support for multiple power states).

As others have pointed out, the register banks and the translation unit are
powered separately (or at least, clocked separately).

>^^ The above would be actually guaranteed by your hardware design,
> where SMMU and GPU share the power domain and clocks. (We used to rely
> on this in old downstream implementation of Rockchip IOMMU and master
> drivers in Chromium OS kernel, before we moved to handling the clocks
> explicitly in 

Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 14 February 2018 15:24:53 EET Tomi Valkeinen wrote:
> Hi,
> 
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > Hello,
> > 
> > Most of this series has previously been posted as part of "[PATCH 00/48]
> > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm:
> > Miscellaneous fixes and cleanups" posted and merged a few days ago, it
> > completes the rework of the omapdrm and omapdss drivers to replace most
> > global variables with dynamically-allocated objects. The actual merge of
> > the omapdrm and omapdss drivers has been left out for now as it still
> > suffers from unresolved issues.
> > 
> > As with the previous series I have other pending patches based on top of
> > this, as passing driver objects around explicitly helps not relying on
> > more global variables that would hinder the effort to move to the DRM
> > bridge and DRM panel APIs.
> > 
> > Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen
> > significant changes and I have thus dropped the Reviewed-by tag from
> > Sebastian. All other patches have been rebased and reordered, thus
> > sometimes modified to resolve conflicts, but have otherwise seen only
> > minor changes.
> > 
> > The series is based on top of the omapdrm-next branch from
> > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git.
> > 
> > Tomi, as the series has been stripped of its controversial patches, I
> > think it's now ready to be merged (pending review of the patches mentioned
> > above of course). I have tested it on both a Panda board and an AM57xx EVM
> > without any issues (and this time I made sure to try with the drivers
> > compiled as modules).
> 
> I have to admit I didn't go through every line of the patches, but
> overall I think this looks good. The only problem is the support for
> DSS6, which I mentioned in the other mail.
> 
> We don't have DSS6 support in mainline, but it's a critical thing for TI
> to support. If it helps, we can upstream the current DSS6 driver (which
> is not very big), so that these can be reworked with DSS6 included. Or
> we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6
> driver working on top of these (which, afaics, is not possible at the
> moment).

Following up our discussion in reply to another e-mail in this thread, would 
switching to struct device pointers for DSS and DISPC objects in the public 
API help ? Is there anything else preventing DSS6 from working on top of this 
series ? I would personally prefer getting the cleanups and reworks (including 
the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in 
mainline, as the problem is already complex enough.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105095] piglit arb_vertex_type_2_10_10_10_rev-array_types failed for BARTS

[bugzilla-daemon]

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

Bug ID: 105095
   Summary: piglit arb_vertex_type_2_10_10_10_rev-array_types
failed for BARTS
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: benau2...@yahoo.com.hk
QA Contact: dri-devel@lists.freedesktop.org

Output of arb_vertex_type_2_10_10_10_rev-array_types from piglit tests:

testing: RGBA SINT
testing: RGBA SNORM
Probe color at (25,5)
  Expected: 0.50 0.25 0.00 1.00
  Observed: 0.501961 0.250980 0.00 0.33
testing: RGBA UINT
testing: RGBA UNORM
testing: BGRA SNORM
Probe color at (85,5)
  Expected: 0.00 0.25 0.50 1.00
  Observed: 0.00 0.250980 0.501961 0.33
testing: BGRA UNORM
Mesa version 17.3.3
AMD/ATI Barts PRO Radeon HD 6850

Detail in https://github.com/supertuxkart/stk-code/issues/3097, this bug cause
wrong animation in stk.

And i think 2.2 / 2.3 equation isn't causing this bug, because from what i see
zero is represented correctly in stk, also some amd devs told me barts switched
to use the new formula long time ago.

Any idea?

-- 
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 v2 22/30] drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 14 February 2018 10:31:17 EET Tomi Valkeinen wrote:
> Hi,
> 
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > The dss_device is the top-level component in the omapdss driver. Give
> > the omapdrm driver access to the dss_device pointer in order to obtain
> > pointers to all other components from it. This requires a new global
> > variable in the omapdss driver that will be removed when merging the
> > omapdrm and omapdss drivers, but will already allow removal of several
> > other global variables.
> 
> How can we support different DSS versions with this change? So far the
> DSS functions used from omapdrm have been designed to be free of DSS
> specific parameters, and in the TI kernel we have a separate DSS driver
> for the DSS6, and omapdrm "just works" with either DSS2-5 and DSS6.
> 
> We could have the "struct dss_device *dss" and "struct dispc_device
> *dispc" in omap_drv.h as "struct device" pointers instead.

From an omapdrm point of view the dss_device and dispc_device structures are 
opaque. We're free to do anything we want with them, from switching to struct 
device pointers to allow completely separate implementations of the DSS and 
DISPC on DSS2-5 and DSS6, or storing common data in struct dss_device and 
struct dispc_device, that we can then subclass with version-specific 
structures internally. I don't have a strong opinion at the moment as I 
haven't seen the DSS6 code and thus can't judge whether there's a need to 
share data and code. At this point what matters to me is making sure we always 
pass objects around explicitly to avoid global variables. We could go for 
struct device now and switch to something else later, or the other way around, 
or anything else that works for you.

> Alternatively, we could just create a totally new DRM driver for DSS6,
> having nothing in common with the current omapdrm. From naming
> perspective that would not be so bad, as OMAP is dead =). But if we ever
> get DSS7, perhaps that's again different enough that we don't want a
> single DSS driver for DSS6 and DSS7.

Again I haven't stupid the differences between DSS2-5 and DSS6 so I can't 
really comment, but being able to start from scratch without carrying device 
mistakes over is tempting. Of course that means we would just make different 
design mistakes :-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Sean Paul]

On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> On 2018-02-14 03:08 PM, Sean Paul wrote:
> > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> >>> Dear drm-misc maintainers,
> >>>
> >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>  Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> >>> This series has been reviewed, consent has been expressed by the most
> >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> >>> has been acked and I've just out a v2 addressing the only objection
> >>> raised.  My plan is thus to wait another two days for comments and,
> >>> barring further objections, push to drm-misc this weekend.
> >>>
> >>> However I'm struggling with the decision whether to push to next or
> >>> fixes.  The series is marked for stable, however the number of
> >>> affected machines is limited and for an issue that's been present
> >>> for 5 years it probably doesn't matter if it soaks another two months
> >>> in linux-next befor it gets backported.  Hence I tend to err on the
> >>> side of caution and push to next, however a case could be made that
> >>> fixes is more appropriate.
> >>>
> >>> I'm lacking experience making such decisions and would be interested
> >>> to learn how you'd handle this.
> >>>
> >>> Thanks,
> >>>
> >>> Lukas
> >>
> >> I would say fixes, it doesn't look particularly scary. :)
> > 
> > Agreed. If it's good enough for stable, it's good enough for -fixes!
> 
> It's not that simple, is it? Fast-tracking patches (some of which appear
> to be untested) to stable without an immediate cause for urgency seems
> risky to me.
> 

/me should be more careful what he says

Given where we are in the release cycle, it's barely a fast track. If these go
in -fixes, they'll get in -rc2 and will have plenty of time to bake. If we were
at rc5, it might be a different story.

Sean

> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 08/13] drm/amd/include: remove unused asic_reg/uvd headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |  795 -
 .../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h| 1211 
 .../drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h| 1081 -
 3 files changed, 3087 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
deleted file mode 100644
index 8ee3149df5b7..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h
deleted file mode 100644
index 981086f8ee4e..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h
deleted file mode 100644
index ecf47ba55c2d..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 05/13] drm/amd/include: remove unused asic_reg/gmc headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h| 1198 
 .../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h| 1068 -
 2 files changed, 2266 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
deleted file mode 100644
index 05b80f2bb147..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h
deleted file mode 100644
index bc18e4d1f20e..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 00/13] gpu: drm: amd: remove unused headers

[Corentin Labbe]

Hello

This patchset remove several headers which are not used by any source
file.

Regards

Change since v1:
- splited in multiple patchs

Change since v2
- Use --irreversible-delete for format-patch

Corentin Labbe (13):
  drm/amd/include: remove unused asic_reg/oss headers
  drm/amd/include: remove unused asic_reg/bif headers
  drm/amd/include: remove unused asic_reg/dce headers
  drm/amd/include: remove unused asic_reg/gca headers
  drm/amd/include: remove unused asic_reg/gmc headers
  drm/amd/include: remove unused asic_reg/smu headers
  drm/amd/include: remove unused asic_reg/umc headers
  drm/amd/include: remove unused asic_reg/uvd headers
  drm/amd/include: remove unused asic_reg/vce headers
  drm/amd/include: remove unused asic_reg/sdma headers
  drm/amd/include: remove unused asic_reg/nbif headers
  drm/amd/include: remove unused displayobject.h header
  drm/amd/powerplay: remove unused headers

 .../drm/amd/include/asic_reg/bif/bif_5_0_enum.h|  1198 --
 .../drm/amd/include/asic_reg/bif/bif_5_1_enum.h|  1068 -
 .../drm/amd/include/asic_reg/dce/dce_11_2_enum.h   |  6813 --
 .../drm/amd/include/asic_reg/dce/dce_8_0_enum.h|  1117 -
 .../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h   |  2791 ---
 .../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h|  6808 --
 .../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21368 ---
 .../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h|  1198 --
 .../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h|  1068 -
 .../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h   | 10281 -
 .../drm/amd/include/asic_reg/oss/oss_2_4_enum.h|  1340 --
 .../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h  |  1464 --
 .../drm/amd/include/asic_reg/oss/oss_3_0_enum.h|  1497 --
 .../amd/include/asic_reg/sdma0/sdma0_4_0_default.h |   286 -
 .../amd/include/asic_reg/sdma1/sdma1_4_0_default.h |   282 -
 .../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h   |   148 -
 .../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h |   715 -
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h |  1344 --
 .../drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h  |  1191 --
 .../amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h   |  5648 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h  |  1205 --
 .../drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h  |  1246 --
 .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  |  1282 --
 .../drm/amd/include/asic_reg/smu/smu_8_0_enum.h|  1072 -
 .../drm/amd/include/asic_reg/umc/umc_6_0_default.h |31 -
 .../drm/amd/include/asic_reg/umc/umc_6_0_offset.h  |52 -
 .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |   795 -
 .../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h|  1211 --
 .../drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h|  1081 -
 .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h   |64 -
 .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h |99 -
 drivers/gpu/drm/amd/include/displayobject.h|   249 -
 .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h|   412 -
 drivers/gpu/drm/amd/powerplay/inc/pp_feature.h |67 -
 34 files changed, 76491 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h
 delete mode 100644 

[PATCH v3 03/13] drm/amd/include: remove unused asic_reg/dce headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/dce/dce_11_2_enum.h   | 6813 
 .../drm/amd/include/asic_reg/dce/dce_8_0_enum.h| 1117 
 2 files changed, 7930 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
deleted file mode 100644
index b2ea4202d7bd..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h
deleted file mode 100644
index 6bea30ef3df5..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 06/13] drm/amd/include: remove unused asic_reg/smu headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h   |  148 -
 .../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h |  715 ---
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h | 1344 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h  | 1191 -
 .../amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h   | 5648 
 .../drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h  | 1205 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h  | 1246 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  | 1282 -
 .../drm/amd/include/asic_reg/smu/smu_8_0_enum.h| 1072 
 9 files changed, 13851 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
deleted file mode 100644
index 6b10be61efc3..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
deleted file mode 100644
index 7d3925b7266e..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
deleted file mode 100644
index 57588b11ff1a..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h
deleted file mode 100644
index 61face1d0d8d..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h
deleted file mode 100644
index cd7893065a4b..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h
deleted file mode 100644
index c1a7aba19223..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h
deleted file mode 100644
index 73bbf506b1c9..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
deleted file mode 100644
index f19c4208d963..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h
deleted file mode 100644
index e1540c181bf8..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 10/13] drm/amd/include: remove unused asic_reg/sdma headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../amd/include/asic_reg/sdma0/sdma0_4_0_default.h | 286 -
 .../amd/include/asic_reg/sdma1/sdma1_4_0_default.h | 282 
 2 files changed, 568 deletions(-)
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h 
b/drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
deleted file mode 100644
index 4be3cb5c4556..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h 
b/drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h
deleted file mode 100644
index 934733762ddf..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 07/13] drm/amd/include: remove unused asic_reg/umc headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/umc/umc_6_0_default.h | 31 -
 .../drm/amd/include/asic_reg/umc/umc_6_0_offset.h  | 52 --
 2 files changed, 83 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_default.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_offset.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_default.h 
b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_default.h
deleted file mode 100644
index 128a18f1e362..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_offset.h 
b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_offset.h
deleted file mode 100644
index 6985dbba39f5..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 12/13] drm/amd/include: remove unused displayobject.h header

[Corentin Labbe]

displayobject.h is not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 drivers/gpu/drm/amd/include/displayobject.h | 249 
 1 file changed, 249 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/displayobject.h

diff --git a/drivers/gpu/drm/amd/include/displayobject.h 
b/drivers/gpu/drm/amd/include/displayobject.h
deleted file mode 100644
index 67e23ff9cbd4..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 13/13] drm/amd/powerplay: remove unused headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h| 412 -
 drivers/gpu/drm/amd/powerplay/inc/pp_feature.h |  67 
 2 files changed, 479 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h
 delete mode 100644 drivers/gpu/drm/amd/powerplay/inc/pp_feature.h

diff --git a/drivers/gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h 
b/drivers/gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h
deleted file mode 100644
index b8f4b73c322e..
diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_feature.h 
b/drivers/gpu/drm/amd/powerplay/inc/pp_feature.h
deleted file mode 100644
index 0faf6a25c18b..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 09/13] drm/amd/include: remove unused asic_reg/vce headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h   | 64 --
 .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 99 --
 2 files changed, 163 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h
deleted file mode 100644
index 2176548e9203..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h
deleted file mode 100644
index ea5b26b11cb1..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 04/13] drm/amd/include: remove unused asic_reg/gca headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h   |  2791 ---
 .../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h|  6808 --
 .../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21368 ---
 3 files changed, 30967 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
deleted file mode 100644
index 2d672b3d2fed..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
deleted file mode 100644
index f9022097fbe9..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h
deleted file mode 100644
index 397705a6b3a2..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 02/13] drm/amd/include: remove unused asic_reg/bif headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/bif/bif_5_0_enum.h| 1198 
 .../drm/amd/include/asic_reg/bif/bif_5_1_enum.h| 1068 -
 2 files changed, 2266 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
deleted file mode 100644
index 46b75f4bbc36..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h
deleted file mode 100644
index d8d5ae0b341f..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 11/13] drm/amd/include: remove unused asic_reg/nbif headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h   | 10281 ---
 1 file changed, 10281 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h
deleted file mode 100644
index c7518b84f559..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 01/13] drm/amd/include: remove unused asic_reg/oss headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/oss/oss_2_4_enum.h| 1340 --
 .../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h  | 1464 ---
 .../drm/amd/include/asic_reg/oss/oss_3_0_enum.h| 1497 
 3 files changed, 4301 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
deleted file mode 100644
index 37adf0df0fd3..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
deleted file mode 100644
index 627cff10fcce..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h
deleted file mode 100644
index 09338d82afba..
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Michel Dänzer]

On 2018-02-14 03:08 PM, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
>> Op 14-02-18 om 09:46 schreef Lukas Wunner:
>>> Dear drm-misc maintainers,
>>>
>>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
 Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>>> This series has been reviewed, consent has been expressed by the most
>>> interested parties, patch [1/5] which touches files outside drivers/gpu
>>> has been acked and I've just out a v2 addressing the only objection
>>> raised.  My plan is thus to wait another two days for comments and,
>>> barring further objections, push to drm-misc this weekend.
>>>
>>> However I'm struggling with the decision whether to push to next or
>>> fixes.  The series is marked for stable, however the number of
>>> affected machines is limited and for an issue that's been present
>>> for 5 years it probably doesn't matter if it soaks another two months
>>> in linux-next befor it gets backported.  Hence I tend to err on the
>>> side of caution and push to next, however a case could be made that
>>> fixes is more appropriate.
>>>
>>> I'm lacking experience making such decisions and would be interested
>>> to learn how you'd handle this.
>>>
>>> Thanks,
>>>
>>> Lukas
>>
>> I would say fixes, it doesn't look particularly scary. :)
> 
> Agreed. If it's good enough for stable, it's good enough for -fixes!

It's not that simple, is it? Fast-tracking patches (some of which appear
to be untested) to stable without an immediate cause for urgency seems
risky to me.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm/i915: Add HDCP support to i915

[Jani Nikula]

On Wed, 14 Feb 2018, Sean Paul  wrote:
> On Wed, Feb 14, 2018 at 02:48:29PM +0100, Hans Verkuil wrote:
>> Yes, your patches I've seen, but the 12 from Ramalingam I haven't seen.
>> At least not on dri-devel. It's a bit weird.
>
> Ahh, I'm sorry I misunderstood. I think Ram may have sent those to intel-gfx
> exclusively.

We rarely post i915 specific patches to dri-devel, just intel-gfx, but
in cases where they warrant changes in drm core it may be warranted to
add a wider audience. Sorry about failing to do that here.

All the commits have Link: tags back to the patches posted publicly,
with message-ids.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[Daniel Stone]

Hi,

On 14 February 2018 at 13:50, Sean Paul  wrote:
> On Wed, Feb 14, 2018 at 07:22:53AM -0500, Rob Clark wrote:
>> On Wed, Feb 14, 2018 at 3:30 AM, Daniel Stone  wrote:
>> > This one I guess you can't get around though. Can they still run from
>> > the one plane, or do you secretly consume two planes?
>>
>> I think it is still the case, like mdp5, that you need two hw pipes..
>> but actually it gets more crazy, since there are some cases where two
>> planes could share a hw pipe.
>
> Right. Large fbs might require 2 pipes, and multiple overlapping or adjacent 
> small fbs
> can be serviced with 1 pipe.

I didn't know about using a single pipe for multiple framebuffers.
That's quite special indeed.

I think virtualising probably makes sense in that case: rather than
just getting around limitations, it's seeming like more of a VC4
situation where they just really aren't actually planes in the first
place.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Ilia Mirkin]

On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin  wrote:
> On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos  wrote:
>>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>>
>> NV5 in another PC (secondary card in x86-64) made the systrem crash on
>> boot, in nvkm_therm_clkgate_fini.
>
> Mind booting with nouveau.debug=trace? That should hopefully tell us
> more exactly which thing is dying. If you have a cross-compile/distcc
> setup handy, a bisect may be even more useful.

Erm, sorry, nevermind. You even said it -- nvkm_therm_clkgate_fini is
somehow mis-hooked up for NV5 now. A bisect result would still make
the culprit a lot more obvious.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel