Re: [RFC PATCH v4 6/8] drm/bridge/analogix: Do not use device's drvdata

[Archit Taneja]

Hi,

On 10/18/2017 05:13 AM, Jingoo Han wrote:

On Tuesday, October 17, 2017 6:16 AM, Jeffy Chen wrote:


From: Tomasz Figa 

The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is barely
a good practice and in fact has led to many bugs in this driver.

Let's clean up this mess and change Analogix entry points to simply
accept some opaque struct pointer, adjusting their users at the same
time to avoid breaking the compilation.

Signed-off-by: Tomasz Figa 
Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 




This depends on previous patches of the series. I guess it would be easier
to queue this to drm-misc as a part of the eDP support series. For that:

Acked-by: Archit Taneja 


Acked-by: Jingoo Han 

Best regards,
Jingoo Han


---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +
-
  drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 47

+++---

--
  include/drm/bridge/analogix_dp.h   | 19 
  4 files changed, 73 insertions(+), 69 deletions(-)




___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
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/bridge: adv7511: Fix a use after free

[Archit Taneja]

On 10/18/2017 02:13 AM, Dan Carpenter wrote:

We free "edid", then use it again on the next line.

Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Dan Carpenter 


Thanks for the fix. I've queued this to drm-misc-next.

Archit



diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 31ca883bda83..0e14f1572d05 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -607,10 +607,10 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
adv7511_set_config_csc(adv7511, connector, adv7511->rgb,
   drm_detect_hdmi_monitor(edid));
  
-	kfree(edid);

-
cec_s_phys_addr_from_edid(adv7511->cec_adap, edid);
  
+	kfree(edid);

+
return count;
  }
  



--
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: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

[Ville Syrjälä]

On Tue, Oct 17, 2017 at 09:00:56PM +0200, Nicolai Hähnle wrote:
> On 17.10.2017 16:09, Ville Syrjälä wrote:
> > On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 02:22 PM, Daniel Vetter wrote:
> >>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
>  On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> >>>
> > Common sense suggests that there need to be two side to FreeSync / VESA
> > Adaptive Sync support:
> >
> > 1. Query the display capabilities. This means querying minimum / maximum
> > refresh duration, plus possibly a query for when the earliest/latest
> > timing of the *next* refresh.
> >
> > 2. Signal desired present time. This means passing a target timer value
> > instead of a target vblank count, e.g. something like this for the KMS
> > interface:
> >
> >    int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id,
> >    uint32_t flags, void *user_data,
> >    uint64_t target);
> >
> >    + a flag to indicate whether target is the vblank count or the
> > CLOCK_MONOTONIC (?) time in ns.
> 
>  drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative
>  sync should probably only be supported via the atomic API, presumably
>  via output properties.
> >>>
> >>> +1
> >>>
> >>> At least now that DC is on track to land properly, and you want to do this
> >>> for DC-only anyway there's no reason to pimp the legacy interfaces
> >>> further. And atomic is soo much easier to extend.
> >>>
> >>> The big question imo is where we need to put the flag on the kms side,
> >>> since freesync is not just about presenting earlier, but also about
> >>> presenting later. But for backwards compat we can't stretch the refresh
> >>> rate by default for everyone, or clients that rely on high precision
> >>> timestamps and regular refresh will get a bad surprise.
> >>
> >> The idea described above is that adaptive sync would be used for flips
> >> with a target timestamp. Apps which don't want to use adaptive sync
> >> wouldn't set a target timestamp.
> >>
> >>
> >>> I think a boolean enable_freesync property is probably what we want, which
> >>> enables freesync for as long as it's set.
> >>
> >> The question then becomes under what circumstances the property is (not)
> >> set. Not sure offhand this will actually solve any problem, or just push
> >> it somewhere else.
> >>
> >>
> >>> Finally I'm not sure we want to insist on a target time for freesync. At
> >>> least as far as I understand things you just want "as soon as possible".
> >>> This might change with some of the VK/EGL/GLX extensions where you
> >>> specify a precise timing (media playback). But that needs a bit more work
> >>> to make it happen I think, so perhaps better to postpone.
> >>
> >> I don't see why. There's an obvious use case for this now, for video
> >> playback. At least VDPAU already has target timestamps for this.
> >>
> >>
> >>> Also note that right now no driver expect amdgpu has support for a target
> >>> vblank on a flip. That's imo another reason for not requiring target
> >>> support for at least basic freesync support.
> >>
> >> I think that's a bad reason. :) Adding it for atomic drivers shouldn't
> >> be that hard.
> > 
> > Apart from the actual implementation hurdles it does open up some new 
> > questions:
> 
> All good questions, thanks! Let me try to take a crack at them:
> 
> 
> > - Is it going to be per-plane or per-crtc?
> 
> My understanding is that planes are combined to form a single signal 
> that goes out to the monitor(s). The planes are scanned out together by 
> a crtc, so it should be per-crtc.

I guess one might imagine a compositor with one video player type of
client, and another game/benchmark type of client. If both clients queue
their next frames around the same time, the compositor might think to
combine them to a single atomic ioctl call. But it's possible the
video player client would want its frame presented much later than
the other client, which would require a per-plane timestamp.
But I guess it's not totally unreasonable to ask the compositor to
do two ioctls in this case since we aren't actually looking for a
single atomic update of two planes.

> 
> 
> > - What happens if the target timestamp is already stale?
> > - What happens if the target timestamp is good when it gets scheduled,
> >but can't be met once the fences and whatnot have signalled?
> 
> Treat it as "flip as soon as possible" in both cases.
> 
> 
> > - What happens if another operation is already queued with a more
> >recent timestamp?
> 
> This is a problem already today, isn't it? You could have two page flips 
> being queued before the next vblank. What happens in that case?

I think currently we get -EBUSY. But there's has been talk about
replacing queued flips, async flips, etc. so it seems like people
are starting 

Re: [PATCH v2 09/11] drm/exynos/hdmi: quirk for support mode timings conversion

[Inki Dae]

2017년 10월 17일 17:04에 Andrzej Hajda 이(가) 쓴 글:
> On 17.10.2017 09:38, Inki Dae wrote:
>>
>> 2017년 09월 29일 19:05에 Andrzej Hajda 이(가) 쓴 글:
>>> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
>>> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes
>>> can be enabled by manipulating timings of HDMI. To do it
>>> adjusted_mode should contain actual mode set on crtc.
>>> With this patch it is possible to enable 1024x768 and 1280x1024
>>> modes in MIXER.
>>>
>>> Suggested-by: Daniel Drake 
>>> Signed-off-by: Andrzej Hajda 
>>> Reviewed-by: Tobias Jakobi 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
>>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index 7225b6521148..4b081f6cfdcb 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -1239,6 +1239,17 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
>>> *hdata)
>>>  static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
>>>  {
>>> struct drm_display_mode *m = >encoder.crtc->state->mode;
>>> +   struct drm_display_mode *am = 
>>> >encoder.crtc->state->adjusted_mode;
>>> +   int hquirk = 0;
>>> +
>>> +   /*
>>> +* In case video mode coming from CRTC differs from requested one HDMI
>>> +* sometimes is able to almost properly perform conversion - only
>>> +* first line is distorted.
>>> +*/
>>> +   if ((m->vdisplay != am->vdisplay) &&
>>> +   (m->hdisplay == 1280 || m->hdisplay == 1024))
>>> +   hquirk = 258;
>> Andrzej,
>>
>> The distorted value couldn't be described logically? Just I wonder why the 
>> difference happens.
> 
> Without low level documentation of the IP one could only guess what
> happens there.
> In case of 1024x768 one can reason as follows:
> - mixer sends image in format 1280x720, so it sends 1280 - 1024 = 256
> pixels too much, so if we trim it in HDMI by 256 it should display it
> correctly,
> - but another quirk few lines later suppress 2 pixels from
> hsync_(start,end), so to balance it we should add these pixels here, so
> finally we have 256 + 2 = 258.
> 
> This explanation seems quite reasonable, except it does not work for
> 1280x1024 mode.

We aren't sure 100% but above comment would be helpful to other developers. So 
could you leave the comment?

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>
>> Thanks,
>> Inki Dae
>>
>>>  
>>> hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
>>> hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
>>> @@ -1332,8 +1343,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
>>> *hdata)
>>> hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_6_0, 2, 0x);
>>>  
>>> hdmi_reg_writev(hdata, HDMI_TG_H_FSZ_L, 2, m->htotal);
>>> -   hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay);
>>> -   hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay);
>>> +   hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay - 
>>> hquirk);
>>> +   hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay + hquirk);
>>> hdmi_reg_writev(hdata, HDMI_TG_V_FSZ_L, 2, m->vtotal);
>>> if (hdata->drv_data == _hdmi_driver_data)
>>> hdmi_reg_writeb(hdata, HDMI_TG_DECON_EN, 1);
>>>
>>
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/12] of: overlay: clean up device tree overlay code

[Rob Herring]

On Tue, Oct 17, 2017 at 6:36 PM,   wrote:
> From: Frank Rowand 
>
> I have found the device tree overlay code to be difficult to read and
> maintain.  This patch series attempts to improve that situation.
>
> The cleanup includes some changes visible to users of overlays.  The
> only in kernel user of overlays is fixed up for those changes.  The
> in kernel user is:
>
>drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>
> Following the cleanup patches are a set of patches to fix various
> issues.
>
> The first five patches are intended to not make any functional
> changes, and are segrated to ease review.
>
> Version 3 applies on top of ac0f3e30d87e "of: overlay: fix memory
> leak related to duplicated property"
>
>
>
> Changes from version 2:
>- rebase on Rob's dt/next branch
>- 3/12: do missing renames in of_fill_overlay_info() so that 3/12
>  and 4/12 build.  This function is removed in 5/12.
>
> Changes from version 1:
>
>   - squash "[PATCH] of: overlay: move resolve phandles into
> of_overlay_apply()" into "[PATCH 09/12] of: overlay: avoid race
> condition between applying multiple overlays"
>
>
> Frank Rowand (12):
>   of: overlay.c: Remove comments that state the obvious, to reduce
> clutter
>   of: overlay.c: Convert comparisons to zero or NULL to logical
> expressions
>   of: overlay: rename identifiers to more reflect what they do
>   of: overlay: rename identifiers in dup_and_fixup_symbol_prop()
>   of: overlay: minor restructuring
>   of: overlay: detect cases where device tree may become corrupt
>   of: overlay: expand check of whether overlay changeset can be removed
>   of: overlay: loosen overly strict phandle clash check
>   of: overlay: avoid race condition between applying multiple overlays
>   of: overlay: simplify applying symbols from an overlay
>   of: overlay: remove a dependency on device node full_name
>   of: overlay: remove unneeded check for NULL kbasename()
>
>  Documentation/devicetree/overlay-notes.txt   |   12 +-
>  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c |   14 +-
>  drivers/of/base.c|2 +-
>  drivers/of/dynamic.c |  137 +++-
>  drivers/of/of_private.h  |   22 +-
>  drivers/of/overlay.c | 1042 
> --
>  drivers/of/resolver.c|7 +
>  drivers/of/unittest.c|   81 +-
>  include/linux/of.h   |   17 +-
>  9 files changed, 874 insertions(+), 460 deletions(-)

Series applied.

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

[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #54 from Alex Deucher  ---
Please see comment 37.  We support both snooped and unsnooped access to system
memory.  When we use unsnooped, we always use uncached memory.  Does i915
always assume dma_bufs are cached?

-- 
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] drm: panel: simple: add Toshiba LT089AC19000

[Rob Herring]

On Fri, Oct 13, 2017 at 07:01:27PM +0200, Lucas Stach wrote:
> Only exposes a single mode and not a complete display timing, as
> the datasheet is rather vague about the minimum/maximum values.
> 
> Signed-off-by: Lucas Stach 
> ---
>  .../display/panel/toshiba,lt089ac29000.txt |  8 +++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt

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

Re: [linux-sunxi] [PATCH 08/10] ARM: dts: sun4i: Enable HDMI support on some A10 devices

[Chen-Yu Tsai]

On Wed, Oct 18, 2017 at 2:10 AM, Maxime Ripard
 wrote:
> On Tue, Oct 17, 2017 at 10:38:45PM +0800, Chen-Yu Tsai wrote:
>> > diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts 
>> > b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> > index 2d1b4329f54a..e39ec9beef75 100644
>> > --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> > +++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> > @@ -58,6 +58,17 @@
>> > stdout-path = "serial0:115200n8";
>> > };
>> >
>> > +   hdmi-connector {
>> > +   compatible = "hdmi-connector";
>> > +   type = "a";
>> > +
>> > +   port {
>> > +   hdmi_con_in: endpoint {
>> > +   remote-endpoint = <_out_con>;
>> > +   };
>> > +   };
>> > +   };
>> > +
>> > leds {
>> > compatible = "gpio-leds";
>> > pinctrl-names = "default";
>> > @@ -106,6 +117,16 @@
>> > status = "okay";
>> >  };
>>
>> The LIME's dts change is missing the  part. :(
>> I can fix this when applying.
>
> I've applied all of rest, I'll leave that one up to you, with my
> Acked-by: Maxime Ripard 

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

Applied "ASoC: AMD: DMA driver changes for Stoney Platform" to the asoc tree

[Mark Brown]

The patch

   ASoC: AMD: DMA driver changes for Stoney Platform

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From e89cff5ed047d8108d1f0b093e5313647aecb2db Mon Sep 17 00:00:00 2001
From: Vijendar Mukunda 
Date: Wed, 13 Sep 2017 13:57:53 -0400
Subject: [PATCH] ASoC: AMD: DMA driver changes for Stoney Platform

Added DMA driver changes for Stoney platform.
Below are the key differences between Stoney and CZ

In Stoney, Memory Gating is disabled.SRAM Banks won't
be turned off.No Of SRAM Banks reduced to 6.
DAGB Garlic Interface used and 16 bit resolution is supported.
SRAM bank 1 & SRAM bank 2 will be used for playback scenario.
SRAM Bank 3 & SRAM Bank 4 will be used for Capture scenario.

Acked-by: Mark Brown 
Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/acp-pcm-dma.c | 87 +
 sound/soc/amd/acp.h |  2 ++
 2 files changed, 67 insertions(+), 22 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f00b6b92e076..f16e0b8e2ed7 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -137,8 +137,8 @@ static void config_dma_descriptor_in_sram(void __iomem 
*acp_mmio,
  * system memory <-> ACP SRAM
  */
 static void set_acp_sysmem_dma_descriptors(void __iomem *acp_mmio,
-  u32 size, int direction,
-  u32 pte_offset)
+   u32 size, int direction,
+   u32 pte_offset, u32 asic_type)
 {
u16 i;
u16 dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
@@ -152,20 +152,42 @@ static void set_acp_sysmem_dma_descriptors(void __iomem 
*acp_mmio,
(size / 2) - (i * (size/2));
dmadscr[i].src = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS
+ (pte_offset * SZ_4K) + (i * (size/2));
-   dmadscr[i].xfer_val |=
-   (ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM << 16) |
-   (size / 2);
+   switch (asic_type) {
+   case CHIP_STONEY:
+   dmadscr[i].xfer_val |=
+   (ACP_DMA_ATTRIBUTES_DAGB_GARLIC_TO_SHAREDMEM  
<< 16) |
+   (size / 2);
+   break;
+   default:
+   dmadscr[i].xfer_val |=
+   (ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM  << 
16) |
+   (size / 2);
+   }
} else {
dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14 + i;
-   dmadscr[i].src = ACP_SHARED_RAM_BANK_5_ADDRESS +
-   (i * (size/2));
-   dmadscr[i].dest = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS
-   + (pte_offset * SZ_4K) +
-   (i * (size/2));
-   dmadscr[i].xfer_val |=
-   BIT(22) |
-   (ACP_DMA_ATTRIBUTES_SHAREDMEM_TO_DAGB_ONION << 16) |
-   (size / 2);
+   switch (asic_type) {
+   case CHIP_STONEY:
+   dmadscr[i].src = ACP_SHARED_RAM_BANK_3_ADDRESS +
+   (i * (size/2));
+   dmadscr[i].dest =
+   ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
+   (pte_offset * SZ_4K) + (i * (size/2));
+   dmadscr[i].xfer_val |=
+   BIT(22) |
+   (ACP_DMA_ATTRIBUTES_SHARED_MEM_TO_DAGB_GARLIC 
<< 16) |
+   (size / 2);

Applied "ASoC: AMD: disabling memory gating in stoney platform" to the asoc tree

[Mark Brown]

The patch

   ASoC: AMD: disabling memory gating in stoney platform

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 4fe4d93c8eb8a823f295f80ff28c7d0bd2f4458e Mon Sep 17 00:00:00 2001
From: Vijendar Mukunda 
Date: Wed, 13 Sep 2017 13:57:52 -0400
Subject: [PATCH] ASoC: AMD: disabling memory gating in stoney platform

For Stoney platform, Memory gating is disabled.i.e SRAM Banks
won't be turned off. By Default, SRAM Bank state set to ON.
Added condition checks to skip SRAM Bank state set logic for
Stoney platform.

Acked-by: Mark Brown 
Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/acp-pcm-dma.c | 79 +++--
 1 file changed, 55 insertions(+), 24 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index dcbf9973884d..f00b6b92e076 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -20,7 +20,7 @@
 #include 
 
 #include 
-
+#include 
 #include "acp.h"
 
 #define PLAYBACK_MIN_NUM_PERIODS2
@@ -419,7 +419,7 @@ static void acp_set_sram_bank_state(void __iomem *acp_mmio, 
u16 bank,
 }
 
 /* Initialize and bring ACP hardware to default state. */
-static int acp_init(void __iomem *acp_mmio)
+static int acp_init(void __iomem *acp_mmio, u32 asic_type)
 {
u16 bank;
u32 val, count, sram_pte_offset;
@@ -493,9 +493,14 @@ static int acp_init(void __iomem *acp_mmio)
/* When ACP_TILE_P1 is turned on, all SRAM banks get turned on.
* Now, turn off all of them. This can't be done in 'poweron' of
* ACP pm domain, as this requires ACP to be initialized.
+   * For Stoney, Memory gating is disabled,i.e SRAM Banks
+   * won't be turned off. The default state for SRAM banks is ON.
+   * Setting SRAM bank state code skipped for STONEY platform.
*/
-   for (bank = 1; bank < 48; bank++)
-   acp_set_sram_bank_state(acp_mmio, bank, false);
+   if (asic_type != CHIP_STONEY) {
+   for (bank = 1; bank < 48; bank++)
+   acp_set_sram_bank_state(acp_mmio, bank, false);
+   }
 
return 0;
 }
@@ -646,14 +651,22 @@ static int acp_dma_open(struct snd_pcm_substream 
*substream)
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
intr_data->play_stream = substream;
-   for (bank = 1; bank <= 4; bank++)
-   acp_set_sram_bank_state(intr_data->acp_mmio, bank,
-   true);
+   /* For Stoney, Memory gating is disabled,i.e SRAM Banks
+* won't be turned off. The default state for SRAM banks is ON.
+* Setting SRAM bank state code skipped for STONEY platform.
+*/
+   if (intr_data->asic_type != CHIP_STONEY) {
+   for (bank = 1; bank <= 4; bank++)
+   acp_set_sram_bank_state(intr_data->acp_mmio,
+   bank, true);
+   }
} else {
intr_data->capture_stream = substream;
-   for (bank = 5; bank <= 8; bank++)
-   acp_set_sram_bank_state(intr_data->acp_mmio, bank,
-   true);
+   if (intr_data->asic_type != CHIP_STONEY) {
+   for (bank = 5; bank <= 8; bank++)
+   acp_set_sram_bank_state(intr_data->acp_mmio,
+   bank, true);
+   }
}
 
return 0;
@@ -869,14 +882,23 @@ static int acp_dma_close(struct snd_pcm_substream 
*substream)
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
adata->play_stream = NULL;
-   for (bank = 1; bank <= 4; bank++)
-   acp_set_sram_bank_state(adata->acp_mmio, bank,
- 

Applied "drm/amdgpu Moving amdgpu asic types to a separate file" to the asoc tree

[Mark Brown]

The patch

   drm/amdgpu Moving amdgpu asic types to a separate file

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 1e4448648333a8fb7830a7a4b76c86e160a79b1e Mon Sep 17 00:00:00 2001
From: Akshu Agrawal 
Date: Wed, 28 Jun 2017 14:08:09 +0530
Subject: [PATCH] drm/amdgpu Moving amdgpu asic types to a separate file

Amdgpu asic types will be required for other drivers too.
Hence, its better to keep it in a separate include file.

Reviewed-by: Alex Deucher 
Signed-off-by: Akshu Agrawal 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/include/amd_shared.h | 29 ++
 include/drm/amd_asic_type.h  | 52 
 2 files changed, 54 insertions(+), 27 deletions(-)
 create mode 100644 include/drm/amd_asic_type.h

diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 70e8c20acb2f..3a49fbd8baf8 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -23,34 +23,9 @@
 #ifndef __AMD_SHARED_H__
 #define __AMD_SHARED_H__
 
-#define AMD_MAX_USEC_TIMEOUT   20  /* 200 ms */
+#include 
 
-/*
- * Supported ASIC types
- */
-enum amd_asic_type {
-   CHIP_TAHITI = 0,
-   CHIP_PITCAIRN,
-   CHIP_VERDE,
-   CHIP_OLAND,
-   CHIP_HAINAN,
-   CHIP_BONAIRE,
-   CHIP_KAVERI,
-   CHIP_KABINI,
-   CHIP_HAWAII,
-   CHIP_MULLINS,
-   CHIP_TOPAZ,
-   CHIP_TONGA,
-   CHIP_FIJI,
-   CHIP_CARRIZO,
-   CHIP_STONEY,
-   CHIP_POLARIS10,
-   CHIP_POLARIS11,
-   CHIP_POLARIS12,
-   CHIP_VEGA10,
-   CHIP_RAVEN,
-   CHIP_LAST,
-};
+#define AMD_MAX_USEC_TIMEOUT   20  /* 200 ms */
 
 /*
  * Chip flags
diff --git a/include/drm/amd_asic_type.h b/include/drm/amd_asic_type.h
new file mode 100644
index ..599028f66585
--- /dev/null
+++ b/include/drm/amd_asic_type.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * 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 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 HOLDER(S) OR AUTHOR(S) 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.
+ */
+
+#ifndef __AMD_ASIC_TYPE_H__
+#define __AMD_ASIC_TYPE_H__
+/*
+ * Supported ASIC types
+ */
+enum amd_asic_type {
+   CHIP_TAHITI = 0,
+   CHIP_PITCAIRN,
+   CHIP_VERDE,
+   CHIP_OLAND,
+   CHIP_HAINAN,
+   CHIP_BONAIRE,
+   CHIP_KAVERI,
+   CHIP_KABINI,
+   CHIP_HAWAII,
+   CHIP_MULLINS,
+   CHIP_TOPAZ,
+   CHIP_TONGA,
+   CHIP_FIJI,
+   CHIP_CARRIZO,
+   CHIP_STONEY,
+   CHIP_POLARIS10,
+   CHIP_POLARIS11,
+   CHIP_POLARIS12,
+   CHIP_VEGA10,
+   CHIP_RAVEN,
+   CHIP_LAST,
+};
+
+#endif /*__AMD_ASIC_TYPE_H__ */
-- 
2.14.1

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

Applied "ASoC: AMD: Add machine driver for cz rt5650" to the asoc tree

[Mark Brown]

The patch

   ASoC: AMD: Add machine driver for cz rt5650

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 91d790b83bf44c356e57149d440e7f8e36f03c4f Mon Sep 17 00:00:00 2001
From: Akshu Agrawal 
Date: Wed, 13 Sep 2017 13:57:55 -0400
Subject: [PATCH] ASoC: AMD: Add machine driver for cz rt5650

The driver is used for AMD board using rt5650 codec.

Reviewed-by: Alex Deucher 
Signed-off-by: Akshu Agrawal 
Signed-off-by: Alex Deucher 
Signed-off-by: Dylan Reid 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/Kconfig  |   7 ++
 sound/soc/amd/Makefile |   2 +
 sound/soc/amd/acp-rt5645.c | 199 +
 3 files changed, 208 insertions(+)
 create mode 100644 sound/soc/amd/acp-rt5645.c

diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
index 78187eb24f56..d5838402f667 100644
--- a/sound/soc/amd/Kconfig
+++ b/sound/soc/amd/Kconfig
@@ -2,3 +2,10 @@ config SND_SOC_AMD_ACP
tristate "AMD Audio Coprocessor support"
help
 This option enables ACP DMA support on AMD platform.
+
+config SND_SOC_AMD_CZ_RT5645_MACH
+   tristate "AMD CZ support for RT5645"
+   select SND_SOC_RT5645
+   depends on SND_SOC_AMD_ACP && I2C
+   help
+This option enables machine driver for rt5645.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index 1a66ec0366b2..eed64ff6c73e 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,3 +1,5 @@
 snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
 obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-rt5645.c b/sound/soc/amd/acp-rt5645.c
new file mode 100644
index ..941aed6bb364
--- /dev/null
+++ b/sound/soc/amd/acp-rt5645.c
@@ -0,0 +1,199 @@
+/*
+ * Machine driver for AMD ACP Audio engine using Realtek RT5645 codec
+ *
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * This file is modified from rt288 machine driver
+ *
+ * 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 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 HOLDER(S) OR AUTHOR(S) 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.
+ *
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../codecs/rt5645.h"
+
+#define CZ_PLAT_CLK 2400
+
+static struct snd_soc_jack cz_jack;
+
+static int cz_aif1_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   int ret = 0;
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+
+   ret = snd_soc_dai_set_pll(codec_dai, 0, RT5645_PLL1_S_MCLK,
+ CZ_PLAT_CLK, params_rate(params) * 512);
+   if (ret < 0) {
+   dev_err(rtd->dev, "can't set codec pll: %d\n", ret);
+   return ret;
+   }
+
+   ret = snd_soc_dai_set_sysclk(codec_dai, RT5645_SCLK_S_PLL1,
+   

Applied "ASoC: AMD: Audio buffer related changes for Stoney" to the asoc tree

[Mark Brown]

The patch

   ASoC: AMD: Audio buffer related changes for Stoney

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From f672fc6de01de8ae3feb3fc59669a40dc8808434 Mon Sep 17 00:00:00 2001
From: Vijendar Mukunda 
Date: Wed, 13 Sep 2017 13:57:54 -0400
Subject: [PATCH] ASoC: AMD: Audio buffer related changes for Stoney

Stoney uses 16kb SRAM memory for playback and 16Kb
for capture.Modified Max buffer size to have the
correct mapping between System Memory and SRAM.

Added snd_pcm_hardware structures for playback
and capture for Stoney.

Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/acp-pcm-dma.c | 83 ++---
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f16e0b8e2ed7..73b58ee00383 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -35,6 +35,11 @@
 #define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define MIN_BUFFER MAX_BUFFER
 
+#define ST_PLAYBACK_MAX_PERIOD_SIZE 8192
+#define ST_CAPTURE_MAX_PERIOD_SIZE  ST_PLAYBACK_MAX_PERIOD_SIZE
+#define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define ST_MIN_BUFFER ST_MAX_BUFFER
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -73,6 +78,44 @@ static const struct snd_pcm_hardware 
acp_pcm_hardware_capture = {
.periods_max = CAPTURE_MAX_NUM_PERIODS,
 };
 
+static const struct snd_pcm_hardware acp_st_pcm_hardware_playback = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+   .channels_max = 8,
+   .rates = SNDRV_PCM_RATE_8000_96000,
+   .rate_min = 8000,
+   .rate_max = 96000,
+   .buffer_bytes_max = ST_MAX_BUFFER,
+   .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
+   .period_bytes_max = ST_PLAYBACK_MAX_PERIOD_SIZE,
+   .periods_min = PLAYBACK_MIN_NUM_PERIODS,
+   .periods_max = PLAYBACK_MAX_NUM_PERIODS,
+};
+
+static const struct snd_pcm_hardware acp_st_pcm_hardware_capture = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+   .channels_max = 2,
+   .rates = SNDRV_PCM_RATE_8000_48000,
+   .rate_min = 8000,
+   .rate_max = 48000,
+   .buffer_bytes_max = ST_MAX_BUFFER,
+   .period_bytes_min = CAPTURE_MIN_PERIOD_SIZE,
+   .period_bytes_max = ST_CAPTURE_MAX_PERIOD_SIZE,
+   .periods_min = CAPTURE_MIN_NUM_PERIODS,
+   .periods_max = CAPTURE_MAX_NUM_PERIODS,
+};
+
 static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
 {
return readl(acp_mmio + (reg * 4));
@@ -664,10 +707,23 @@ static int acp_dma_open(struct snd_pcm_substream 
*substream)
if (adata == NULL)
return -ENOMEM;
 
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
-   runtime->hw = acp_pcm_hardware_playback;
-   else
-   runtime->hw = acp_pcm_hardware_capture;
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   switch (intr_data->asic_type) {
+   case CHIP_STONEY:
+   runtime->hw = acp_st_pcm_hardware_playback;
+   break;
+   default:
+   

Re: [PATCH v2 2/2] vgaarb: Factor out EFI and fallback default device selection

[Daniel Axtens]

Hi Daniel,

>> Initially I wondered if this info printk could be moved into
>> vga_arbiter_check_bridge_sharing(), but it's been separated out since
>> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
>> possible."), and upon closer examination, it seems you can't be sure a
>> device doesn't share a bridge until the end of the process, so this is
>> indeed correct.
>> 
>> Everything else also looks good to me.
>> 
>> Reviewed-by: Daniel Axtens 
>
> R-b for both patches? And ok with everyone if I pull this into drm-misc
> for 4.15 (deadline is end of this week for feature-y stuff)?

I had only intended it for patch 2, but I've now read over patch 1 to my
satisfaction, so it too is:

Reviewed-by: Daniel Axtens 

Thanks!

Regards,
Daniel

>
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl

[Eric Anholt]

Boris Brezillon  writes:

> This ioctl will allow us to purge inactive userspace buffers when the
> system is running out of contiguous memory.
>
> For now, the purge logic is rather dumb in that it does not try to
> release only the amount of BO needed to meet the last CMA alloc request
> but instead purges all objects placed in the purgeable pool as soon as
> we experience a CMA allocation failure.
>
> Note that the in-kernel BO cache is always purged before the purgeable
> cache because those objects are known to be unused while objects marked
> as purgeable by a userspace application/library might have to be
> restored when they are marked back as unpurgeable, which can be
> expensive.
>
> Signed-off-by: Boris Brezillon 

Looking good!  Just a couple things I'd like to sort out before we
merge.

> ---
> Hello,
>
> Updates to libdrm, mesa and igt making use of this kernel feature can
> be found on my github repos [1][2][3].
>
> There's currently no debugfs hook to manually force a purge, but this
> is being discussed and might be added later on.
>
> Regards,
>
> Boris
>
> [1]https://github.com/bbrezillon/drm/tree/vc4/purgeable
> [2]https://github.com/bbrezillon/mesa/tree/vc4/purgeable
> [3]https://github.com/bbrezillon/igt/tree/vc4/purgeable
>
> Changes in v3:
> - Use %zd formatters when printing size_t values
> - rework detection of BOs that do not support the MADV ioctl
> - replace DRM_ERROR by DRM_DEBUG in the ioctl path
> - do not explicitly memzero purged BO mem
> - check that pad is set to zero in the madv ioctl function
>
> Changes in v2:
> - Do not re-allocate BO's memory after when WILLNEED is asked after a purge
> - Add purgeable/purged stats to debugfs and dumpstats
> - Pad the drm_vc4_gem_madvise to make it 64-bit aligned
> - Forbid madvise calls on internal BO objects (everything that is not
>   meant to be exposed to userspace)
> - Do not increment/decrement usecnt on internal BOs (they cannot be marked
>   purgeable, so doing that is useless and error prone)
> - Fix a few bugs related to usecnt refcounting
> ---
>  drivers/gpu/drm/vc4/vc4_bo.c| 292 
> ++--
>  drivers/gpu/drm/vc4/vc4_drv.c   |  10 +-
>  drivers/gpu/drm/vc4/vc4_drv.h   |  30 +
>  drivers/gpu/drm/vc4/vc4_gem.c   | 156 -
>  drivers/gpu/drm/vc4/vc4_plane.c |  20 +++
>  include/uapi/drm/vc4_drm.h  |  19 +++
>  6 files changed, 512 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 3afdbf4bc10b..e4d13bbef54f 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -42,6 +42,8 @@ static bool is_user_label(int label)
>  
>  static void vc4_bo_stats_dump(struct vc4_dev *vc4)
>  {
> + size_t purgeable_size, purged_size;
> + unsigned int npurgeable, npurged;
>   int i;
>  
>   for (i = 0; i < vc4->num_labels; i++) {
> @@ -53,6 +55,21 @@ static void vc4_bo_stats_dump(struct vc4_dev *vc4)
>vc4->bo_labels[i].size_allocated / 1024,
>vc4->bo_labels[i].num_allocated);
>   }
> +
> + mutex_lock(>purgeable.lock);
> + npurgeable = vc4->purgeable.num;
> + purgeable_size = vc4->purgeable.size;
> + purged_size = vc4->purgeable.purged_size;
> + npurged = vc4->purgeable.purged_num;
> + mutex_unlock(>purgeable.lock);
> +
> + if (npurgeable)
> + DRM_INFO("%30s: %6zdkb BOs (%d)\n", "userspace BO cache",
> +  purgeable_size / 1024, npurgeable);
> +
> + if (npurged)
> + DRM_INFO("%30s: %6zdkb BOs (%d)\n", "total purged BO",
> +  purged_size / 1024, npurged);
>  }
>  
>  #ifdef CONFIG_DEBUG_FS
> @@ -61,6 +78,8 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
>   struct drm_info_node *node = (struct drm_info_node *)m->private;
>   struct drm_device *dev = node->minor->dev;
>   struct vc4_dev *vc4 = to_vc4_dev(dev);
> + size_t purgeable_size, purged_size;
> + unsigned int npurgeable, npurged;
>   int i;
>  
>   mutex_lock(>bo_lock);
> @@ -75,6 +94,21 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
>   }
>   mutex_unlock(>bo_lock);
>  
> + mutex_lock(>purgeable.lock);
> + npurgeable = vc4->purgeable.num;
> + purgeable_size = vc4->purgeable.size;
> + purged_size = vc4->purgeable.purged_size;
> + npurged = vc4->purgeable.purged_num;
> + mutex_unlock(>purgeable.lock);
> +
> + if (npurgeable)
> + seq_printf(m, "%30s: %6dkb BOs (%d)\n", "userspace BO cache",
> +purgeable_size / 1024, npurgeable);
> +
> + if (npurged)
> + seq_printf(m, "%30s: %6dkb BOs (%d)\n", "total purged BO",
> +purged_size / 1024, npurged);

I think you could just do these seq_printfs under the lock, instead of
taking a snapshot ahead 

Re: [RFC PATCH v4 6/8] drm/bridge/analogix: Do not use device's drvdata

[Jingoo Han]

On Tuesday, October 17, 2017 6:16 AM, Jeffy Chen wrote:
> 
> From: Tomasz Figa 
> 
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
> owned by its driver struct. Moreover, storing two different pointer
> types in driver data depending on driver initialization status is barely
> a good practice and in fact has led to many bugs in this driver.
> 
> Let's clean up this mess and change Analogix entry points to simply
> accept some opaque struct pointer, adjusting their users at the same
> time to avoid breaking the compilation.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Andrzej Hajda 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +
> -
>  drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 47
+++---
> --
>  include/drm/bridge/analogix_dp.h   | 19 
>  4 files changed, 73 insertions(+), 69 deletions(-)
> 

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

Re: [RFC PATCH v3 3/5] drm/bridge/analogix: Do not use device's drvdata

[Jingoo Han]

On Tuesday, October 17, 2017 4:09 AM, Jeffy Chen wrote:
> 
> From: Tomasz Figa 
> 
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
> owned by its driver struct. Moreover, storing two different pointer
> types in driver data depending on driver initialization status is barely
> a good practice and in fact has led to many bugs in this driver.
> 
> Let's clean up this mess and change Analogix entry points to simply
> accept some opaque struct pointer, adjusting their users at the same
> time to avoid breaking the compilation.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Andrzej Hajda 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +
> -
>  drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 47
+++---
> --
>  include/drm/bridge/analogix_dp.h   | 19 
>  4 files changed, 73 insertions(+), 69 deletions(-)
> 

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

[Bug 102820] [bisected][DC] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting

[bugzilla-daemon]

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

--- Comment #16 from Harry Wentland  ---
That's interesting. No picture needed anymore. I get it now.

This is really weird behavior. Do you have the actual TV model by any chance?
If I get a chance I'd love to see if I can find something similar in the office
and repro it.

As for 4k60 support, you're right that that's usually entailed by HDMI 2.0 but
like Alex said HDMI 2.0 doesn't necessarily imply 4k60. In your case it looks
like our Video BIOS doesn't report that 4k60 (i.e. 6GB) is validated. I'll try
to find out more.

-- 
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 103320] Build error with 1.20 release

[bugzilla-daemon]

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

Bug ID: 103320
   Summary: Build error with 1.20 release
   Product: DRI
   Version: XOrg git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: re...@rezso.net

If I try to compile 1.20 release, I get this error:

igt_x86.c:96:10: error: redefinition of ‘igt_x86_features’
 unsigned igt_x86_features(void)
  ^~~~
In file included from igt_x86.c:38:0:
igt_x86.h:47:24: note: previous definition of ‘igt_x86_features’ was here
 static inline unsigned igt_x86_features(void)
^~~~
igt_x86.c:148:7: error: redefinition of ‘igt_x86_features_to_string’
 char *igt_x86_features_to_string(unsigned features, char *line)
   ^~
In file included from igt_x86.c:38:0:
igt_x86.h:51:21: note: previous definition of ‘igt_x86_features_to_string’ was
here
 static inline char *igt_x86_features_to_string(unsigned features, char *line)
 ^~

How to fix this?

-- 
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 102820] [bisected][DC] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting

[bugzilla-daemon]

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

--- Comment #15 from dwagner  ---
(In reply to Harry Wentland from comment #10)
> As for the behavior you're seeing with the modelines removed, I don't fully
> understand what you're seeing. Mind posting a picture? It sounds like we
> should be driving the monitor in 4k30 at that point but seems like something
> goes wrong there, from your description.

The display is driven in 3840x2160 @ 30Hz with modelines removed and commit
present - but the picture fills only ~80% in the middle of the screen
horizontally (100% vertically).  

If I use "xrandr --output HDMI-A-0 --mode 3840x2160 --rate 24" to switch to
24Hz, then the picture fills the whole screen.

Without the commit (still without Modelines), when I use "xrandr --output
HDMI-A-0 --mode 3840x2160 --rate 30" to voluntarily only use 30Hz, then the
picture fills the whole screen. So with and without the commit, different
parameters seem to be used to output 3840x2160 @ 30Hz.

(If really required, I can shoot a photo later, but it doesn't really show
anything remarkable except for the two black bars to the left and the right of
the screen.)

-- 
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 00/48] omapdrm: Merge omapdrm and omapdss

[Laurent Pinchart]

Hi Sebastian,

On Wednesday, 18 October 2017 01:29:56 EEST Sebastian Reichel wrote:
> On Fri, Oct 13, 2017 at 05:58:56PM +0300, Laurent Pinchart wrote:
> > This patch series merges the omapdrm and omapdss drivers into a single
> > driver called omapdrm. The split in two drivers was historical, in order
> > to support the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports
> > DRM/KMS only there's no need to keep two seperate drivers.
> > 
> > The series starts with a few cleanups (01/48 to 03/48) and quickly
> > proceeds to merging the omapdss and omapdss-base modules (04/48). It then
> > prepares the omapdss code (05/48 to 08/48), perform a few more cleanups
> > (09/48 to 11/48) and prepares the omapdrm code (12/48).
> > 
> > Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers.
> > All those drivers defer probing when their video source can't be found at
> > probe time. This would cause endless probe deferral when merging omapdrm
> > and omapdss as the drivers need omapdss to be fully initialized to probe
> > successfully, but cause omapdrm to defer probing when they're not
> > available.
> > 
> > Patch 20/48 merges the omapdrm and omapdss drivers.
> > 
> > The next patches are added bonuses that start removal of global variables
> > from the driver. The code relies heavily on global variables for objects
> > that are instance-specific, and should thus be dynamically allocated.
> > Most of the patches change internal APIs to pass objects to driver
> > functions (21/48 to 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a
> > few miscellaneous cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches
> > 30/48 to 34/48 and 46/48 then allocate instance objects dynamically to
> > replace global variables, and patches 47/48 and 48/48 move global
> > variables to existing instance objects.
> > 
> > The series has been tested on a Pandaboard with the DVI and HDMI output.
> 
> Nice cleanup! :)

And great review ! :-) Thank you.

There will be more coming, probably another cleanup round before I start 
moving the encoder, connector and panel drivers to drm_bridge and drm_panel.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 47/48] drm: omapdrm: dss: Store the debugfs root directory in struct dss_device

[Laurent Pinchart]

Hi Sebastian,

On Wednesday, 18 October 2017 01:16:53 EEST Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Oct 13, 2017 at 05:59:43PM +0300, Laurent Pinchart wrote:
> > As part of an effort to remove the usage of global variables in the
> > driver, store the debugfs root directory in the dss_device structure
> > instead of a global variable.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/dispc.c |  2 +-
> >  drivers/gpu/drm/omapdrm/dss/dsi.c   |  8 
> >  drivers/gpu/drm/omapdrm/dss/dss.c   | 39 +---
> >  drivers/gpu/drm/omapdrm/dss/dss.h   |  9 ++---
> >  drivers/gpu/drm/omapdrm/dss/hdmi4.c |  3 ++-
> >  drivers/gpu/drm/omapdrm/dss/hdmi5.c |  3 ++-
> >  drivers/gpu/drm/omapdrm/dss/venc.c  |  3 ++-
> >  7 files changed, 37 insertions(+), 30 deletions(-)

[snip]

> > diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
> > b/drivers/gpu/drm/omapdrm/dss/dss.c index 5d927dfe0a7f..f4e15850cc9d
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> > @@ -906,25 +906,23 @@ static int dss_debug_dump_clocks(struct seq_file *s,
> > void *p)
> > return 0;
> >  }
> > 
> > -static struct dentry *dss_debugfs_dir;
> > -
> >  static int dss_initialize_debugfs(struct dss_device *dss)
> >  {
> > -   dss_debugfs_dir = debugfs_create_dir("omapdss", NULL);
> > -   if (IS_ERR(dss_debugfs_dir)) {
> > -   int err = PTR_ERR(dss_debugfs_dir);
> > +   static struct dentry *dir;
> 
> static?

Oops. Will fix in v2. Thanks for catching it.

> Otherwise:
> 
> Reviewed-by: Sebastian Reichel 
> 
> -- Sebastian
> 
> > -   dss_debugfs_dir = NULL;
> > -   return err;
> > -   }
> > +   dir = debugfs_create_dir("omapdss", NULL);
> > +   if (IS_ERR(dir))
> > +   return PTR_ERR(dir);
> > +
> > +   dss->debugfs.root = dir;
> > return 0;
> >  }

[snip]

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss

[Sebastian Reichel]

Hi Laurent,

On Fri, Oct 13, 2017 at 05:58:56PM +0300, Laurent Pinchart wrote:
> This patch series merges the omapdrm and omapdss drivers into a single driver
> called omapdrm. The split in two drivers was historical, in order to support
> the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only
> there's no need to keep two seperate drivers.
> 
> The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds to
> merging the omapdss and omapdss-base modules (04/48). It then prepares the
> omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48)
> and prepares the omapdrm code (12/48).
> 
> Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All
> those drivers defer probing when their video source can't be found at probe
> time. This would cause endless probe deferral when merging omapdrm and omapdss
> as the drivers need omapdss to be fully initialized to probe successfully, but
> cause omapdrm to defer probing when they're not available.
> 
> Patch 20/48 merges the omapdrm and omapdss drivers.
> 
> The next patches are added bonuses that start removal of global variables from
> the driver. The code relies heavily on global variables for objects that are
> instance-specific, and should thus be dynamically allocated. Most of the
> patches change internal APIs to pass objects to driver functions (21/48 to
> 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous
> cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and 46/48
> then allocate instance objects dynamically to replace global variables, and
> patches 47/48 and 48/48 move global variables to existing instance objects.
> 
> The series has been tested on a Pandaboard with the DVI and HDMI output.

Nice cleanup! :)

-- Sebastian


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

[Bug 102820] [bisected][DC] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting

[bugzilla-daemon]

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

--- Comment #14 from dwagner  ---
(In reply to Alex Deucher from comment #13)
> It's pretty vague unfortunately regarding HDMI:
> It does not explicitly say 4K@60 on HDMI.  The high refresh rates may only
> be available on DP.

Well then, if you suspect XFX to be sneaky bitches, I should refer you to the
page of the actual reseller that I bought my XFX RX 460 from:
https://www.caseking.de/en/xfx-radeon-rx-460-passive-heatsink-edition-2048-mb-gddr5-gcxf-148.html
which clearly states: "The 2.0b HDMI port carries a 4K/UHD resolution signal at
60 Hz and permits the sending and receiving of encrypted signals using the HDCP
2.2 protocol (4K streaming, 4K Blu-Rays)."

And that corresponds well to the many reports of Windows users you find on the
Internet that confirm XFX RX460 cards do in fact drive HDMI displays at 4k 60Hz
also under Windows - or should we assume the Windows drivers to be broken and
all those users just being "lucky"?

> HDMI 2.0b does not imply 4K@60.

Support of 4k @ 60Hz was the first and foremost feature advertised by the HDMI
licensors as being the main reason for introducing HDMI 2.0! - Here's their
press release from back then: 
https://www.hdmi.org/press/press_release.aspx?prid=133
and a clear statement on HDMI 2.0b supporting 4k@60Hz:
https://www.hdmi.org/manufacturer/hdmi_2_0/index.aspx

> Your board may work, but others might not depending on the board, cable,
> monitor, etc.

Yes, the GPU board cannot guarantee anything with regards to cabling or
monitors - but how is that a reason for a driver software to keep users from
even trying to use this fundamentally important, reseller-promised,
broadly-reported-to-be-working-under-Windows feature?

Should audio drivers discard LFE channels because some sound card vendor cannot
validate that the user connected a capable sub-woofer to his amplifier...?

-- 
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 09/48] drm: omapdrm: Deconstruct the omap_drv.h header.

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:05PM +0300, Laurent Pinchart wrote:
> The number of function declarations in the omap_drv.h degrades
> readability. To fix it, create new header files for each part of the
> driver and move the related functions.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/omap_connector.h |  37 +
>  drivers/gpu/drm/omapdrm/omap_crtc.h  |  43 ++
>  drivers/gpu/drm/omapdrm/omap_drv.h   | 133 
> +++
>  drivers/gpu/drm/omapdrm/omap_encoder.h   |  33 
>  drivers/gpu/drm/omapdrm/omap_fb.h|  46 +++
>  drivers/gpu/drm/omapdrm/omap_fbdev.h |  39 +
>  drivers/gpu/drm/omapdrm/omap_gem.h   |  99 +++
>  drivers/gpu/drm/omapdrm/omap_irq.h   |  39 +
>  drivers/gpu/drm/omapdrm/omap_plane.h |  37 +
>  9 files changed, 386 insertions(+), 120 deletions(-)
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_connector.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_crtc.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_encoder.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_fb.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_fbdev.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_gem.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_irq.h
>  create mode 100644 drivers/gpu/drm/omapdrm/omap_plane.h
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.h 
> b/drivers/gpu/drm/omapdrm/omap_connector.h
> new file mode 100644
> index ..98bbc779b302
> --- /dev/null
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.h
> @@ -0,0 +1,37 @@
> +/*
> + * omap_connector.h -- OMAP DRM Connector
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __OMAPDRM_CONNECTOR_H__
> +#define __OMAPDRM_CONNECTOR_H__
> +
> +#include 
> +
> +struct drm_connector;
> +struct drm_device;
> +struct drm_encoder;
> +struct omap_dss_device;
> +
> +struct drm_connector *omap_connector_init(struct drm_device *dev,
> + int connector_type, struct omap_dss_device *dssdev,
> + struct drm_encoder *encoder);
> +struct drm_encoder *omap_connector_attached_encoder(
> + struct drm_connector *connector);
> +bool omap_connector_get_hdmi_mode(struct drm_connector *connector);
> +
> +#endif /* __OMAPDRM_CONNECTOR_H__ */
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h 
> b/drivers/gpu/drm/omapdrm/omap_crtc.h
> new file mode 100644
> index ..ad7b007c6174
> --- /dev/null
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
> @@ -0,0 +1,43 @@
> +/*
> + * omap_crtc.h -- OMAP DRM CRTC
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __OMAPDRM_CRTC_H__
> +#define __OMAPDRM_CRTC_H__
> +
> +#include 
> +
> +enum omap_channel;
> +
> +struct drm_crtc;
> +struct drm_device;
> +struct drm_plane;
> +struct omap_dss_device;
> +struct videomode;
> +
> +struct videomode *omap_crtc_timings(struct drm_crtc *crtc);
> +enum omap_channel omap_crtc_channel(struct drm_crtc *crtc);
> +void omap_crtc_pre_init(void);
> +void omap_crtc_pre_uninit(void);
> +struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> + struct drm_plane *plane, struct omap_dss_device *dssdev);
> +int omap_crtc_wait_pending(struct drm_crtc *crtc);
> +void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus);
> +void omap_crtc_vblank_irq(struct drm_crtc *crtc);
> +
> +#endif /* __OMAPDRM_CRTC_H__ */
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> 

Re: [PATCH 48/48] drm: omapdrm: dss: Store the registered plls array in struct dss_device

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:44PM +0300, Laurent Pinchart wrote:
> As part of an effort to remove the usage of global variables in the
> driver, store the registered plls array in the dss_device structure
> instead of a global variable.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dispc.c |  4 ++--
>  drivers/gpu/drm/omapdrm/dss/dpi.c   | 17 +++---
>  drivers/gpu/drm/omapdrm/dss/dsi.c   |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h   | 12 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi_pll.c  |  3 +--
>  drivers/gpu/drm/omapdrm/dss/pll.c   | 40 
> +
>  drivers/gpu/drm/omapdrm/dss/video-pll.c |  3 +--
>  7 files changed, 42 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 5eacf4cdac54..181a8ea072b1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -3252,7 +3252,7 @@ static unsigned long dispc_fclk_rate(struct 
> dispc_device *dispc)
>   struct dss_pll *pll;
>   unsigned int clkout_idx;
>  
> - pll = dss_pll_find_by_src(src);
> + pll = dss_pll_find_by_src(dispc->dss, src);
>   clkout_idx = dss_pll_get_clkout_idx_for_src(src);
>  
>   r = pll->cinfo.clkout[clkout_idx];
> @@ -3280,7 +3280,7 @@ static unsigned long dispc_mgr_lclk_rate(struct 
> dispc_device *dispc,
>   struct dss_pll *pll;
>   unsigned int clkout_idx;
>  
> - pll = dss_pll_find_by_src(src);
> + pll = dss_pll_find_by_src(dispc->dss, src);
>   clkout_idx = dss_pll_get_clkout_idx_for_src(src);
>  
>   r = pll->cinfo.clkout[clkout_idx];
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 66183fc77bb2..2fb9406d2059 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -60,7 +60,8 @@ static struct dpi_data *dpi_get_data_from_dssdev(struct 
> omap_dss_device *dssdev)
>   return container_of(dssdev, struct dpi_data, output);
>  }
>  
> -static enum dss_clk_source dpi_get_clk_src_dra7xx(enum omap_channel channel)
> +static enum dss_clk_source dpi_get_clk_src_dra7xx(struct dpi_data *dpi,
> +   enum omap_channel channel)
>  {
>   /*
>* Possible clock sources:
> @@ -72,23 +73,23 @@ static enum dss_clk_source dpi_get_clk_src_dra7xx(enum 
> omap_channel channel)
>   switch (channel) {
>   case OMAP_DSS_CHANNEL_LCD:
>   {
> - if (dss_pll_find_by_src(DSS_CLK_SRC_PLL1_1))
> + if (dss_pll_find_by_src(dpi->dss, DSS_CLK_SRC_PLL1_1))
>   return DSS_CLK_SRC_PLL1_1;
>   break;
>   }
>   case OMAP_DSS_CHANNEL_LCD2:
>   {
> - if (dss_pll_find_by_src(DSS_CLK_SRC_PLL1_3))
> + if (dss_pll_find_by_src(dpi->dss, DSS_CLK_SRC_PLL1_3))
>   return DSS_CLK_SRC_PLL1_3;
> - if (dss_pll_find_by_src(DSS_CLK_SRC_PLL2_3))
> + if (dss_pll_find_by_src(dpi->dss, DSS_CLK_SRC_PLL2_3))
>   return DSS_CLK_SRC_PLL2_3;
>   break;
>   }
>   case OMAP_DSS_CHANNEL_LCD3:
>   {
> - if (dss_pll_find_by_src(DSS_CLK_SRC_PLL2_1))
> + if (dss_pll_find_by_src(dpi->dss, DSS_CLK_SRC_PLL2_1))
>   return DSS_CLK_SRC_PLL2_1;
> - if (dss_pll_find_by_src(DSS_CLK_SRC_PLL1_3))
> + if (dss_pll_find_by_src(dpi->dss, DSS_CLK_SRC_PLL1_3))
>   return DSS_CLK_SRC_PLL1_3;
>   break;
>   }
> @@ -135,7 +136,7 @@ static enum dss_clk_source dpi_get_clk_src(struct 
> dpi_data *dpi)
>   }
>  
>   case DSS_MODEL_DRA7:
> - return dpi_get_clk_src_dra7xx(channel);
> + return dpi_get_clk_src_dra7xx(dpi, channel);
>  
>   default:
>   return DSS_CLK_SRC_FCK;
> @@ -603,7 +604,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
>  
>   dpi->clk_src = dpi_get_clk_src(dpi);
>  
> - pll = dss_pll_find_by_src(dpi->clk_src);
> + pll = dss_pll_find_by_src(dpi->dss, dpi->clk_src);
>   if (!pll)
>   return;
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 48ea5285cf20..bc9d6b7ce6a9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5226,9 +5226,8 @@ static int dsi_init_pll_data(struct dss_device *dss, 
> struct dsi_data *dsi)
>   pll->base = dsi->pll_base;
>   pll->hw = dsi->data->pll_hw;
>   pll->ops = _pll_ops;
> - pll->dss = dss;
>  
> - r = dss_pll_register(pll);
> + r = dss_pll_register(dss, pll);
>   if (r)
>  

Re: [PATCH 47/48] drm: omapdrm: dss: Store the debugfs root directory in struct dss_device

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:43PM +0300, Laurent Pinchart wrote:
> As part of an effort to remove the usage of global variables in the
> driver, store the debugfs root directory in the dss_device structure
> instead of a global variable.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c |  2 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c   |  8 
>  drivers/gpu/drm/omapdrm/dss/dss.c   | 39 
> +++--
>  drivers/gpu/drm/omapdrm/dss/dss.h   |  9 ++---
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c |  3 ++-
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c |  3 ++-
>  drivers/gpu/drm/omapdrm/dss/venc.c  |  3 ++-
>  7 files changed, 37 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index aaf7396f0273..5eacf4cdac54 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -4772,7 +4772,7 @@ static int dispc_bind(struct device *dev, struct device 
> *master, void *data)
>   dispc_set_ops(_ops);
>   dss->dispc = dispc;
>  
> - dispc->debugfs = dss_debugfs_create_file("dispc", dispc_dump_regs,
> + dispc->debugfs = dss_debugfs_create_file(dss, "dispc", dispc_dump_regs,
>dispc);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c7700dfccc08..48ea5285cf20 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5453,20 +5453,20 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>   dsi_runtime_put(dsi);
>  
>   if (dsi->module_id == 0)
> - dsi->debugfs.regs = dss_debugfs_create_file("dsi1_regs",
> + dsi->debugfs.regs = dss_debugfs_create_file(dss, "dsi1_regs",
>   dsi1_dump_regs,
>   );
>   else
> - dsi->debugfs.regs = dss_debugfs_create_file("dsi2_regs",
> + dsi->debugfs.regs = dss_debugfs_create_file(dss, "dsi2_regs",
>   dsi2_dump_regs,
>   );
>  #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
>   if (dsi->module_id == 0)
> - dsi->debugfs.irqs = dss_debugfs_create_file("dsi1_irqs",
> + dsi->debugfs.irqs = dss_debugfs_create_file(dss, "dsi1_irqs",
>   dsi1_dump_irqs,
>   );
>   else
> - dsi->debugfs.irqs = dss_debugfs_create_file("dsi2_irqs",
> + dsi->debugfs.irqs = dss_debugfs_create_file(dss, "dsi2_irqs",
>   dsi2_dump_irqs,
>   );
>  #endif
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
> b/drivers/gpu/drm/omapdrm/dss/dss.c
> index 5d927dfe0a7f..f4e15850cc9d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> @@ -906,25 +906,23 @@ static int dss_debug_dump_clocks(struct seq_file *s, 
> void *p)
>   return 0;
>  }
>  
> -static struct dentry *dss_debugfs_dir;
> -
>  static int dss_initialize_debugfs(struct dss_device *dss)
>  {
> - dss_debugfs_dir = debugfs_create_dir("omapdss", NULL);
> - if (IS_ERR(dss_debugfs_dir)) {
> - int err = PTR_ERR(dss_debugfs_dir);
> + static struct dentry *dir;

static?

Otherwise:

Reviewed-by: Sebastian Reichel 

-- Sebastian

> - dss_debugfs_dir = NULL;
> - return err;
> - }
> + dir = debugfs_create_dir("omapdss", NULL);
> + if (IS_ERR(dir))
> + return PTR_ERR(dir);
> +
> + dss->debugfs.root = dir;
>  
>   return 0;
>  }
>  
> -static void dss_uninitialize_debugfs(void)
> +static void dss_uninitialize_debugfs(struct dss_device *dss)
>  {
> - if (dss_debugfs_dir)
> - debugfs_remove_recursive(dss_debugfs_dir);
> + if (dss->debugfs.root)
> + debugfs_remove_recursive(dss->debugfs.root);
>  }
>  
>  struct dss_debugfs_entry {
> @@ -947,8 +945,10 @@ static const struct file_operations dss_debug_fops = {
>   .release= single_release,
>  };
>  
> -struct dss_debugfs_entry *dss_debugfs_create_file(const char *name,
> - int (*show_fn)(struct seq_file *s, void *data), void *data)
> +struct dss_debugfs_entry *
> +dss_debugfs_create_file(struct dss_device *dss, const char *name,
> + int (*show_fn)(struct seq_file *s, void *data),
> + void *data)
>  {
>   struct dss_debugfs_entry *entry;
>   struct dentry *d;
> @@ -960,7 +960,7 @@ struct dss_debugfs_entry 

Re: [PATCH 46/48] drm: omapdrm: dispc: Allocate the dispc private data structure dynamically

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:42PM +0300, Laurent Pinchart wrote:
> The dispc private data structure is currently stored as a global
> variable. While no platform with multiple DISPC currently exists
> nor is planned, this doesn't comply with the kernel device model and
> should thus be fixed.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dispc.c | 1924 
> +++
>  1 file changed, 1032 insertions(+), 892 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 180ad55bbdec..aaf7396f0273 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -49,6 +49,8 @@
>  #include "dss.h"
>  #include "dispc.h"
>  
> +struct dispc_device;
> +
>  /* DISPC */
>  #define DISPC_SZ_REGSSZ_4K
>  
> @@ -58,11 +60,12 @@ enum omap_burst_size {
>   BURST_SIZE_X8 = 2,
>  };
>  
> -#define REG_GET(idx, start, end) \
> - FLD_GET(dispc_read_reg(idx), start, end)
> +#define REG_GET(dispc, idx, start, end) \
> + FLD_GET(dispc_read_reg(dispc, idx), start, end)
>  
> -#define REG_FLD_MOD(idx, val, start, end)\
> - dispc_write_reg(idx, FLD_MOD(dispc_read_reg(idx), val, start, end))
> +#define REG_FLD_MOD(dispc, idx, val, start, end) \
> + dispc_write_reg(dispc, idx, \
> + FLD_MOD(dispc_read_reg(dispc, idx), val, start, end))
>  
>  /* DISPC has feature id */
>  enum dispc_feature_id {
> @@ -107,7 +110,8 @@ struct dispc_features {
>   unsigned int max_downscale;
>   unsigned int max_line_width;
>   unsigned int min_pcd;
> - int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
> + int (*calc_scaling)(struct dispc_device *dispc,
> + unsigned long pclk, unsigned long lclk,
>   const struct videomode *vm,
>   u16 width, u16 height, u16 out_width, u16 out_height,
>   u32 fourcc, bool *five_taps,
> @@ -198,8 +202,6 @@ struct dispc_device {
>   spinlock_t control_lock;
>  };
>  
> -static struct dispc_device dispc;
> -
>  enum omap_color_component {
>   /* used for all color formats for OMAP3 and earlier
>* and for RGB and Y color component on OMAP4
> @@ -357,45 +359,52 @@ struct color_conv_coef {
>   int full_range;
>  };
>  
> -static unsigned long dispc_fclk_rate(void);
> -static unsigned long dispc_core_clk_rate(void);
> -static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
> -static unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
> +static unsigned long dispc_fclk_rate(struct dispc_device *dispc);
> +static unsigned long dispc_core_clk_rate(struct dispc_device *dispc);
> +static unsigned long dispc_mgr_lclk_rate(struct dispc_device *dispc,
> +  enum omap_channel channel);
> +static unsigned long dispc_mgr_pclk_rate(struct dispc_device *dispc,
> +  enum omap_channel channel);
>  
> -static unsigned long dispc_plane_pclk_rate(enum omap_plane_id plane);
> -static unsigned long dispc_plane_lclk_rate(enum omap_plane_id plane);
> +static unsigned long dispc_plane_pclk_rate(struct dispc_device *dispc,
> +enum omap_plane_id plane);
> +static unsigned long dispc_plane_lclk_rate(struct dispc_device *dispc,
> +enum omap_plane_id plane);
>  
>  static void dispc_clear_irqstatus(struct dispc_device *dispc, u32 mask);
>  
> -static inline void dispc_write_reg(const u16 idx, u32 val)
> +static inline void dispc_write_reg(struct dispc_device *dispc, u16 idx, u32 
> val)
>  {
> - __raw_writel(val, dispc.base + idx);
> + __raw_writel(val, dispc->base + idx);
>  }
>  
> -static inline u32 dispc_read_reg(const u16 idx)
> +static inline u32 dispc_read_reg(struct dispc_device *dispc, u16 idx)
>  {
> - return __raw_readl(dispc.base + idx);
> + return __raw_readl(dispc->base + idx);
>  }
>  
> -static u32 mgr_fld_read(enum omap_channel channel, enum mgr_reg_fields 
> regfld)
> +static u32 mgr_fld_read(struct dispc_device *dispc, enum omap_channel 
> channel,
> + enum mgr_reg_fields regfld)
>  {
>   const struct dispc_reg_field rfld = mgr_desc[channel].reg_desc[regfld];
> - return REG_GET(rfld.reg, rfld.high, rfld.low);
> +
> + return REG_GET(dispc, rfld.reg, rfld.high, rfld.low);
>  }
>  
> -static void mgr_fld_write(enum omap_channel channel,
> - enum mgr_reg_fields regfld, int val) {
> +static void mgr_fld_write(struct dispc_device *dispc, enum omap_channel 
> channel,
> +   enum mgr_reg_fields regfld, int val)
> +{
>   const struct dispc_reg_field rfld = mgr_desc[channel].reg_desc[regfld];
>   

Re: [Intel-gfx] [PATCH i-g-t 3/7] lib: Fix compilation on non-x86

[Chris Wilson]

Quoting Thierry Reding (2017-10-12 14:29:39)
> diff --git a/lib/igt_x86.h b/lib/igt_x86.h
> index d6dcfa108331..27b7f0fd5837 100644
> --- a/lib/igt_x86.h
> +++ b/lib/igt_x86.h
> @@ -40,7 +40,7 @@
>  #define AVX0x80
>  #define AVX2   0x100
>  
> -#if defined(__x86_64__)
> +#if defined(__x86_64__) || defined(__i386__)
>  unsigned igt_x86_features(void);
>  char *igt_x86_features_to_string(unsigned features, char *line);

This by itself is a build regression from 2a74ae550842. Would be nice to
get this fixed irrespective of the meson fixes.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 45/48] drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions

[Laurent Pinchart]

Hi Sebastian,

On Wednesday, 18 October 2017 00:24:54 EEST Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Oct 13, 2017 at 05:59:41PM +0300, Laurent Pinchart wrote:
> > This removes the need to access the global DISPC private data in those
> > functions (both for the current accesses and the future ones that will
> > be introduced when allocating the DISPC private data dynamically).
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> 
> Reviewed-by: Sebastian Reichel 
> 
> IMHO this patch can be squashed into the previous patch.

I've split the changes in two patches to try and keep them reviewable, given 
the amount of lines changed, but I'm fine merging them together too.

> >  drivers/gpu/drm/omapdrm/dss/dispc.c | 101 +--
> >  drivers/gpu/drm/omapdrm/dss/dpi.c   |  12 +++--
> >  drivers/gpu/drm/omapdrm/dss/dsi.c   |  22 
> >  drivers/gpu/drm/omapdrm/dss/dss.c   |  14 ++---
> >  drivers/gpu/drm/omapdrm/dss/dss.h   |  74 ++
> >  drivers/gpu/drm/omapdrm/dss/hdmi4.c |   6 ++-
> >  drivers/gpu/drm/omapdrm/dss/hdmi5.c |   6 ++-
> >  drivers/gpu/drm/omapdrm/dss/sdi.c   |  13 +++--
> >  drivers/gpu/drm/omapdrm/dss/venc.c  |   2 +-
> >  9 files changed, 139 insertions(+), 111 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #53 from Chris Wilson  ---
Created attachment 134897
  --> https://bugs.freedesktop.org/attachment.cgi?id=134897=edit
Shotgun attempt to stop pulling external images into the L3 (mesa/i965)

-- 
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 45/48] drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:41PM +0300, Laurent Pinchart wrote:
> This removes the need to access the global DISPC private data in those
> functions (both for the current accesses and the future ones that will
> be introduced when allocating the DISPC private data dynamically).
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

IMHO this patch can be squashed into the previous patch.

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dispc.c | 101 
> 
>  drivers/gpu/drm/omapdrm/dss/dpi.c   |  12 +++--
>  drivers/gpu/drm/omapdrm/dss/dsi.c   |  22 
>  drivers/gpu/drm/omapdrm/dss/dss.c   |  14 ++---
>  drivers/gpu/drm/omapdrm/dss/dss.h   |  74 ++
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c |   6 ++-
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c |   6 ++-
>  drivers/gpu/drm/omapdrm/dss/sdi.c   |  13 +++--
>  drivers/gpu/drm/omapdrm/dss/venc.c  |   2 +-
>  9 files changed, 139 insertions(+), 111 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 1bca5785b8a8..180ad55bbdec 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -706,7 +706,7 @@ static u32 dispc_mgr_get_sync_lost_irq(struct 
> dispc_device *dispc,
>   return mgr_desc[channel].sync_lost_irq;
>  }
>  
> -u32 dispc_wb_get_framedone_irq(void)
> +u32 dispc_wb_get_framedone_irq(struct dispc_device *dispc)
>  {
>   return DISPC_IRQ_FRAMEDONEWB;
>  }
> @@ -741,12 +741,12 @@ static void dispc_mgr_go(struct dispc_device *dispc, 
> enum omap_channel channel)
>   mgr_fld_write(channel, DISPC_MGR_FLD_GO, 1);
>  }
>  
> -bool dispc_wb_go_busy(void)
> +bool dispc_wb_go_busy(struct dispc_device *dispc)
>  {
>   return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
>  }
>  
> -void dispc_wb_go(void)
> +void dispc_wb_go(struct dispc_device *dispc)
>  {
>   enum omap_plane_id plane = OMAP_DSS_WB;
>   bool enable, go;
> @@ -1198,7 +1198,8 @@ static enum omap_channel dispc_ovl_get_channel_out(enum 
> omap_plane_id plane)
>   }
>  }
>  
> -void dispc_wb_set_channel_in(enum dss_writeback_channel channel)
> +void dispc_wb_set_channel_in(struct dispc_device *dispc,
> +  enum dss_writeback_channel channel)
>  {
>   enum omap_plane_id plane = OMAP_DSS_WB;
>  
> @@ -1373,10 +1374,10 @@ static void dispc_init_fifos(void)
>   const bool use_fifomerge = false;
>   const bool manual_update = false;
>  
> - dispc_ovl_compute_fifo_thresholds(i, , ,
> + dispc_ovl_compute_fifo_thresholds(, i, , ,
>   use_fifomerge, manual_update);
>  
> - dispc_ovl_set_fifo_threshold(i, low, high);
> + dispc_ovl_set_fifo_threshold(, i, low, high);
>   }
>  
>   if (dispc.feat->has_writeback) {
> @@ -1384,10 +1385,11 @@ static void dispc_init_fifos(void)
>   const bool use_fifomerge = false;
>   const bool manual_update = false;
>  
> - dispc_ovl_compute_fifo_thresholds(OMAP_DSS_WB, , ,
> - use_fifomerge, manual_update);
> + dispc_ovl_compute_fifo_thresholds(, OMAP_DSS_WB,
> +   , ,
> +   use_fifomerge, manual_update);
>  
> - dispc_ovl_set_fifo_threshold(OMAP_DSS_WB, low, high);
> + dispc_ovl_set_fifo_threshold(, OMAP_DSS_WB, low, high);
>   }
>  }
>  
> @@ -1404,13 +1406,14 @@ static u32 dispc_ovl_get_fifo_size(enum omap_plane_id 
> plane)
>   return size;
>  }
>  
> -void dispc_ovl_set_fifo_threshold(enum omap_plane_id plane, u32 low,
> -   u32 high)
> +void dispc_ovl_set_fifo_threshold(struct dispc_device *dispc,
> +   enum omap_plane_id plane,
> +   u32 low, u32 high)
>  {
>   u8 hi_start, hi_end, lo_start, lo_end;
>   u32 unit;
>  
> - unit = dispc.feat->buffer_size_unit;
> + unit = dispc->feat->buffer_size_unit;
>  
>   WARN_ON(low % unit != 0);
>   WARN_ON(high % unit != 0);
> @@ -1438,12 +1441,12 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane_id 
> plane, u32 low,
>* large for the preload field, set the threshold to the maximum value
>* that can be held by the preload register
>*/
> - if (dispc_has_feature(FEAT_PRELOAD) && dispc.feat->set_max_preload &&
> + if (dispc_has_feature(FEAT_PRELOAD) && dispc->feat->set_max_preload &&
>   plane != OMAP_DSS_WB)
>   dispc_write_reg(DISPC_OVL_PRELOAD(plane), min(high, 0xfffu));
>  }
>  
> -void dispc_enable_fifomerge(bool enable)
> +void dispc_enable_fifomerge(struct dispc_device *dispc, bool enable)
>  {
>   if (!dispc_has_feature(FEAT_FIFO_MERGE)) {
>   WARN_ON(enable);
> 

Re: [PATCH 44/48] drm: omapdrm: dispc: Pass DISPC pointer to dispc_ops operations

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:40PM +0300, Laurent Pinchart wrote:
> This removes the need to access the global DISPC private data in those
> functions (both for the current accesses and the future ones that will
> be introduced when allocating the DISPC private data dynamically).
> 
> In order to allow the omapdrm side to call the dispc_ops with a DISPC
> pointer, we also introduce a new function dss_get_dispc() to retrieve
> the DISPC corresponding to the DSS.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 221 
> +++---
>  drivers/gpu/drm/omapdrm/dss/dpi.c |   6 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c |   4 +-
>  drivers/gpu/drm/omapdrm/dss/dss.c |   7 +-
>  drivers/gpu/drm/omapdrm/dss/dss.h |   7 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c   |   7 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c   |   7 +-
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  91 --
>  drivers/gpu/drm/omapdrm/dss/sdi.c |   6 +-
>  drivers/gpu/drm/omapdrm/dss/venc.c|   4 +-
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  31 +++--
>  drivers/gpu/drm/omapdrm/omap_drv.c|  18 +--
>  drivers/gpu/drm/omapdrm/omap_drv.h|   5 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c|  32 ++---
>  drivers/gpu/drm/omapdrm/omap_plane.c  |  12 +-
>  15 files changed, 261 insertions(+), 197 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 912957c471ce..1bca5785b8a8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -164,7 +164,7 @@ struct dispc_features {
>  #define DISPC_MAX_NR_FIFOS 5
>  #define DISPC_MAX_CHANNEL_GAMMA 4
>  
> -static struct {
> +struct dispc_device {
>   struct platform_device *pdev;
>   void __iomem*base;
>   struct dss_device *dss;
> @@ -196,7 +196,9 @@ static struct {
>  
>   /* DISPC_CONTROL & DISPC_CONFIG lock*/
>   spinlock_t control_lock;
> -} dispc;
> +};
> +
> +static struct dispc_device dispc;
>  
>  enum omap_color_component {
>   /* used for all color formats for OMAP3 and earlier
> @@ -363,9 +365,7 @@ static unsigned long dispc_mgr_pclk_rate(enum 
> omap_channel channel);
>  static unsigned long dispc_plane_pclk_rate(enum omap_plane_id plane);
>  static unsigned long dispc_plane_lclk_rate(enum omap_plane_id plane);
>  
> -static void dispc_clear_irqstatus(u32 mask);
> -static bool dispc_mgr_is_enabled(enum omap_channel channel);
> -static void dispc_clear_irqstatus(u32 mask);
> +static void dispc_clear_irqstatus(struct dispc_device *dispc, u32 mask);
>  
>  static inline void dispc_write_reg(const u16 idx, u32 val)
>  {
> @@ -398,14 +398,14 @@ static void mgr_fld_write(enum omap_channel channel,
>   spin_unlock_irqrestore(_lock, flags);
>  }
>  
> -static int dispc_get_num_ovls(void)
> +static int dispc_get_num_ovls(struct dispc_device *dispc)
>  {
> - return dispc.feat->num_ovls;
> + return dispc->feat->num_ovls;
>  }
>  
> -static int dispc_get_num_mgrs(void)
> +static int dispc_get_num_mgrs(struct dispc_device *dispc)
>  {
> - return dispc.feat->num_mgrs;
> + return dispc->feat->num_mgrs;
>  }
>  
>  static void dispc_get_reg_field(enum dispc_feat_reg_field id,
> @@ -457,7 +457,7 @@ static void dispc_save_context(void)
>   SR(CONFIG3);
>   }
>  
> - for (i = 0; i < dispc_get_num_mgrs(); i++) {
> + for (i = 0; i < dispc_get_num_mgrs(); i++) {
>   SR(DEFAULT_COLOR(i));
>   SR(TRANS_COLOR(i));
>   SR(SIZE_MGR(i));
> @@ -479,7 +479,7 @@ static void dispc_save_context(void)
>   }
>   }
>  
> - for (i = 0; i < dispc_get_num_ovls(); i++) {
> + for (i = 0; i < dispc_get_num_ovls(); i++) {
>   SR(OVL_BA0(i));
>   SR(OVL_BA1(i));
>   SR(OVL_POSITION(i));
> @@ -563,7 +563,7 @@ static void dispc_restore_context(void)
>   if (dispc_has_feature(FEAT_MGR_LCD3))
>   RR(CONFIG3);
>  
> - for (i = 0; i < dispc_get_num_mgrs(); i++) {
> + for (i = 0; i < dispc_get_num_mgrs(); i++) {
>   RR(DEFAULT_COLOR(i));
>   RR(TRANS_COLOR(i));
>   RR(SIZE_MGR(i));
> @@ -585,7 +585,7 @@ static void dispc_restore_context(void)
>   }
>   }
>  
> - for (i = 0; i < dispc_get_num_ovls(); i++) {
> + for (i = 0; i < dispc_get_num_ovls(); i++) {
>   RR(OVL_BA0(i));
>   RR(OVL_BA1(i));
>   RR(OVL_POSITION(i));
> @@ -650,7 +650,7 @@ static void dispc_restore_context(void)
>   if (dispc_has_feature(FEAT_MGR_LCD3))
>   RR(CONTROL3);
>   /* clear spurious SYNC_LOST_DIGIT interrupts */
> - dispc_clear_irqstatus(DISPC_IRQ_SYNC_LOST_DIGIT);
> + dispc_clear_irqstatus(, DISPC_IRQ_SYNC_LOST_DIGIT);
>  
>   /*
>* 

Re: [PATCH 43/48] drm: omapdrm: dss: Pass omap_drm_private pointer to dss_mgr_ops

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:39PM +0300, Laurent Pinchart wrote:
> The dss_mgr_ops operations implemented by the omapdrm side have to look
> up the omap_crtc objects from global variables as they are only passed a
> channel number. In order to remove global variables pass the
> omap_drm_private pointer to the dss_mgr_ops. This requires storing a
> pointer to the dss_device in the omap_dss_device structure to allow
> looking up the omap_drm_private in the dss_mgr_*() functions.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dpi.c |  1 +
>  drivers/gpu/drm/omapdrm/dss/dsi.c |  1 +
>  drivers/gpu/drm/omapdrm/dss/dss.c | 37 -
>  drivers/gpu/drm/omapdrm/dss/dss.h | 37 +
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c   |  1 +
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c   |  1 +
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 39 
> ++-
>  drivers/gpu/drm/omapdrm/dss/output.c  | 23 +
>  drivers/gpu/drm/omapdrm/dss/sdi.c |  1 +
>  drivers/gpu/drm/omapdrm/dss/venc.c|  1 +
>  drivers/gpu/drm/omapdrm/omap_crtc.c   | 27 ++--
>  11 files changed, 98 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 3894e53ff58d..ae43ba81eb96 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -727,6 +727,7 @@ static void dpi_init_output_port(struct dpi_data *dpi, 
> struct device_node *port)
>   }
>  
>   out->dev = >pdev->dev;
> + out->dss = dpi->dss;
>   out->id = OMAP_DSS_OUTPUT_DPI;
>   out->output_type = OMAP_DISPLAY_TYPE_DPI;
>   out->dispc_channel = dpi_get_channel(dpi, port_num);
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 512625ed03e2..eafea72998dd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5044,6 +5044,7 @@ static void dsi_init_output(struct dsi_data *dsi)
>   struct omap_dss_device *out = >output;
>  
>   out->dev = dsi->dev;
> + out->dss = dsi->dss;
>   out->id = dsi->module_id == 0 ?
>   OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2;
>  
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
> b/drivers/gpu/drm/omapdrm/dss/dss.c
> index 8fec9bf6f06f..0e8c70591308 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> @@ -49,9 +49,6 @@
>  
>  #include "omapdss.h"
>  #include "dss.h"
> -#include "../omap_drv.h"
> -
> -#define DSS_SZ_REGS  SZ_512
>  
>  struct dss_reg {
>   u16 idx;
> @@ -96,40 +93,6 @@ struct dss_features {
>   bool has_lcd_clk_src;
>  };
>  
> -struct dss_device {
> - struct platform_device *pdev;
> - struct omap_drm_private drm;
> -
> - void __iomem*base;
> - struct regmap   *syscon_pll_ctrl;
> - u32 syscon_pll_ctrl_offset;
> -
> - struct clk  *parent_clk;
> - struct clk  *dss_clk;
> - unsigned long   dss_clk_rate;
> -
> - unsigned long   cache_req_pck;
> - unsigned long   cache_prate;
> - struct dispc_clock_info cache_dispc_cinfo;
> -
> - enum dss_clk_source dsi_clk_source[MAX_NUM_DSI];
> - enum dss_clk_source dispc_clk_source;
> - enum dss_clk_source lcd_clk_source[MAX_DSS_LCD_MANAGERS];
> -
> - boolctx_valid;
> - u32 ctx[DSS_SZ_REGS / sizeof(u32)];
> -
> - const struct dss_features *feat;
> -
> - struct {
> - struct dss_debugfs_entry *clk;
> - struct dss_debugfs_entry *dss;
> - } debugfs;
> -
> - struct dss_pll  *video1_pll;
> - struct dss_pll  *video2_pll;
> -};
> -
>  static const char * const dss_generic_clk_source_names[] = {
>   [DSS_CLK_SRC_FCK]   = "FCK",
>   [DSS_CLK_SRC_PLL1_1]= "PLL1:1",
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
> b/drivers/gpu/drm/omapdrm/dss/dss.h
> index 5d6f8afca49d..cda2cbd888f0 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -26,6 +26,7 @@
>  #include 
>  
>  #include "omapdss.h"
> +#include "../omap_drv.h"
>  
>  struct dentry;
>  struct dss_debugfs_entry;
> @@ -241,6 +242,42 @@ struct dss_lcd_mgr_config {
>   int lcden_sig_polarity;
>  };
>  
> +#define DSS_SZ_REGS  SZ_512
> +
> +struct dss_device {
> + struct platform_device *pdev;
> + struct omap_drm_private drm;
> +
> + void __iomem*base;
> + struct regmap   *syscon_pll_ctrl;
> + u32 syscon_pll_ctrl_offset;
> +
> + struct clk  *parent_clk;
> + struct clk  *dss_clk;
> + unsigned long   dss_clk_rate;
> +
> + unsigned long   cache_req_pck;
> + unsigned long   cache_prate;
> + struct 

[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer

[bugzilla-daemon]

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

--- Comment #2 from Nicolai Hähnle  ---
Oh wow, now that I've actually looked at the issue in more detail, I'm pretty
amazed that you actually managed to hit this issue! Congratulations! :)

The true analysis is a bit different, I would say. The flush ends up accessing
the texture because it does an automatic re-add of all resources when starting
a new CS. This should not affect the ability of the other thread to do a
texture invalidation (you'd just kill performance by introducing an unnecessary
stall).

The real solution is certainly different. I'm currently looking at other
texture-related races as well, this is just one additional one to take care of.
Thank you for the report!

-- 
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 v3 09/12] drm/panel: 43wvf1g: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c 
b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
index 71c09ed436ae..51785774efd1 100644
--- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
+++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
@@ -44,8 +44,6 @@ struct seiko_panel_desc {
 
 struct seiko_panel {
struct drm_panel base;
-   bool prepared;
-   bool enabled;
const struct seiko_panel_desc *desc;
struct backlight_device *backlight;
struct regulator *dvdd;
@@ -126,17 +124,12 @@ static int seiko_panel_disable(struct drm_panel *panel)
 {
struct seiko_panel *p = to_seiko_panel(panel);
 
-   if (!p->enabled)
-   return 0;
-
if (p->backlight) {
p->backlight->props.power = FB_BLANK_POWERDOWN;
p->backlight->props.state |= BL_CORE_FBBLANK;
backlight_update_status(p->backlight);
}
 
-   p->enabled = false;
-
return 0;
 }
 
@@ -144,9 +137,6 @@ static int seiko_panel_unprepare(struct drm_panel *panel)
 {
struct seiko_panel *p = to_seiko_panel(panel);
 
-   if (!p->prepared)
-   return 0;
-
regulator_disable(p->avdd);
 
/* Add a 100ms delay as per the panel datasheet */
@@ -154,8 +144,6 @@ static int seiko_panel_unprepare(struct drm_panel *panel)
 
regulator_disable(p->dvdd);
 
-   p->prepared = false;
-
return 0;
 }
 
@@ -164,9 +152,6 @@ static int seiko_panel_prepare(struct drm_panel *panel)
struct seiko_panel *p = to_seiko_panel(panel);
int err;
 
-   if (p->prepared)
-   return 0;
-
err = regulator_enable(p->dvdd);
if (err < 0) {
dev_err(panel->dev, "failed to enable dvdd: %d\n", err);
@@ -182,8 +167,6 @@ static int seiko_panel_prepare(struct drm_panel *panel)
goto disable_dvdd;
}
 
-   p->prepared = true;
-
return 0;
 
 disable_dvdd:
@@ -195,17 +178,12 @@ static int seiko_panel_enable(struct drm_panel *panel)
 {
struct seiko_panel *p = to_seiko_panel(panel);
 
-   if (p->enabled)
-   return 0;
-
if (p->backlight) {
p->backlight->props.state &= ~BL_CORE_FBBLANK;
p->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(p->backlight);
}
 
-   p->enabled = true;
-
return 0;
 }
 
@@ -254,8 +232,6 @@ static int seiko_panel_probe(struct device *dev,
if (!panel)
return -ENOMEM;
 
-   panel->enabled = false;
-   panel->prepared = false;
panel->desc = desc;
 
panel->dvdd = devm_regulator_get(dev, "dvdd");
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 10/12] drm/panel: simple: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-simple.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index a3c96d2ea41c..0e1fbca811a0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -77,8 +77,6 @@ struct panel_desc {
 
 struct panel_simple {
struct drm_panel base;
-   bool prepared;
-   bool enabled;
 
const struct panel_desc *desc;
 
@@ -163,9 +161,6 @@ static int panel_simple_disable(struct drm_panel *panel)
 {
struct panel_simple *p = to_panel_simple(panel);
 
-   if (!p->enabled)
-   return 0;
-
if (p->backlight) {
p->backlight->props.power = FB_BLANK_POWERDOWN;
p->backlight->props.state |= BL_CORE_FBBLANK;
@@ -175,8 +170,6 @@ static int panel_simple_disable(struct drm_panel *panel)
if (p->desc->delay.disable)
msleep(p->desc->delay.disable);
 
-   p->enabled = false;
-
return 0;
 }
 
@@ -184,9 +177,6 @@ static int panel_simple_unprepare(struct drm_panel *panel)
 {
struct panel_simple *p = to_panel_simple(panel);
 
-   if (!p->prepared)
-   return 0;
-
gpiod_set_value_cansleep(p->enable_gpio, 0);
 
regulator_disable(p->supply);
@@ -194,8 +184,6 @@ static int panel_simple_unprepare(struct drm_panel *panel)
if (p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
 
-   p->prepared = false;
-
return 0;
 }
 
@@ -204,9 +192,6 @@ static int panel_simple_prepare(struct drm_panel *panel)
struct panel_simple *p = to_panel_simple(panel);
int err;
 
-   if (p->prepared)
-   return 0;
-
err = regulator_enable(p->supply);
if (err < 0) {
dev_err(panel->dev, "failed to enable supply: %d\n", err);
@@ -218,8 +203,6 @@ static int panel_simple_prepare(struct drm_panel *panel)
if (p->desc->delay.prepare)
msleep(p->desc->delay.prepare);
 
-   p->prepared = true;
-
return 0;
 }
 
@@ -227,9 +210,6 @@ static int panel_simple_enable(struct drm_panel *panel)
 {
struct panel_simple *p = to_panel_simple(panel);
 
-   if (p->enabled)
-   return 0;
-
if (p->desc->delay.enable)
msleep(p->desc->delay.enable);
 
@@ -239,8 +219,6 @@ static int panel_simple_enable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
 
-   p->enabled = true;
-
return 0;
 }
 
@@ -301,8 +279,6 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
if (!panel)
return -ENOMEM;
 
-   panel->enabled = false;
-   panel->prepared = false;
panel->desc = desc;
 
panel->supply = devm_regulator_get(dev, "power");
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 11/12] drm/panel: p079zca: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba93449fcfb..38b19c8de9e1 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -27,9 +27,6 @@ struct innolux_panel {
struct backlight_device *backlight;
struct regulator *supply;
struct gpio_desc *enable_gpio;
-
-   bool prepared;
-   bool enabled;
 };
 
 static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
@@ -42,9 +39,6 @@ static int innolux_panel_disable(struct drm_panel *panel)
struct innolux_panel *innolux = to_innolux_panel(panel);
int err;
 
-   if (!innolux->enabled)
-   return 0;
-
innolux->backlight->props.power = FB_BLANK_POWERDOWN;
backlight_update_status(innolux->backlight);
 
@@ -53,8 +47,6 @@ static int innolux_panel_disable(struct drm_panel *panel)
DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
  err);
 
-   innolux->enabled = false;
-
return 0;
 }
 
@@ -63,9 +55,6 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
struct innolux_panel *innolux = to_innolux_panel(panel);
int err;
 
-   if (!innolux->prepared)
-   return 0;
-
err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
if (err < 0) {
DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
@@ -82,8 +71,6 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
if (err < 0)
return err;
 
-   innolux->prepared = false;
-
return 0;
 }
 
@@ -92,9 +79,6 @@ static int innolux_panel_prepare(struct drm_panel *panel)
struct innolux_panel *innolux = to_innolux_panel(panel);
int err, regulator_err;
 
-   if (innolux->prepared)
-   return 0;
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
err = regulator_enable(innolux->supply);
@@ -129,8 +113,6 @@ static int innolux_panel_prepare(struct drm_panel *panel)
/* T7: 5ms */
usleep_range(5000, 6000);
 
-   innolux->prepared = true;
-
return 0;
 
 poweroff:
@@ -148,9 +130,6 @@ static int innolux_panel_enable(struct drm_panel *panel)
struct innolux_panel *innolux = to_innolux_panel(panel);
int ret;
 
-   if (innolux->enabled)
-   return 0;
-
innolux->backlight->props.power = FB_BLANK_UNBLANK;
ret = backlight_update_status(innolux->backlight);
if (ret) {
@@ -159,8 +138,6 @@ static int innolux_panel_enable(struct drm_panel *panel)
return ret;
}
 
-   innolux->enabled = true;
-
return 0;
 }
 
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 12/12] drm/panel: ls043t1le01: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 3aeb0bda4947..8d7843248556 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -39,9 +39,6 @@ struct sharp_nt_panel {
struct regulator *supply;
struct gpio_desc *reset_gpio;
 
-   bool prepared;
-   bool enabled;
-
const struct drm_display_mode *mode;
 };
 
@@ -114,16 +111,11 @@ static int sharp_nt_panel_disable(struct drm_panel *panel)
 {
struct sharp_nt_panel *sharp_nt = to_sharp_nt_panel(panel);
 
-   if (!sharp_nt->enabled)
-   return 0;
-
if (sharp_nt->backlight) {
sharp_nt->backlight->props.power = FB_BLANK_POWERDOWN;
backlight_update_status(sharp_nt->backlight);
}
 
-   sharp_nt->enabled = false;
-
return 0;
 }
 
@@ -132,9 +124,6 @@ static int sharp_nt_panel_unprepare(struct drm_panel *panel)
struct sharp_nt_panel *sharp_nt = to_sharp_nt_panel(panel);
int ret;
 
-   if (!sharp_nt->prepared)
-   return 0;
-
ret = sharp_nt_panel_off(sharp_nt);
if (ret < 0) {
dev_err(panel->dev, "failed to set panel off: %d\n", ret);
@@ -145,8 +134,6 @@ static int sharp_nt_panel_unprepare(struct drm_panel *panel)
if (sharp_nt->reset_gpio)
gpiod_set_value(sharp_nt->reset_gpio, 0);
 
-   sharp_nt->prepared = false;
-
return 0;
 }
 
@@ -155,9 +142,6 @@ static int sharp_nt_panel_prepare(struct drm_panel *panel)
struct sharp_nt_panel *sharp_nt = to_sharp_nt_panel(panel);
int ret;
 
-   if (sharp_nt->prepared)
-   return 0;
-
ret = regulator_enable(sharp_nt->supply);
if (ret < 0)
return ret;
@@ -185,8 +169,6 @@ static int sharp_nt_panel_prepare(struct drm_panel *panel)
goto poweroff;
}
 
-   sharp_nt->prepared = true;
-
return 0;
 
 poweroff:
@@ -200,16 +182,11 @@ static int sharp_nt_panel_enable(struct drm_panel *panel)
 {
struct sharp_nt_panel *sharp_nt = to_sharp_nt_panel(panel);
 
-   if (sharp_nt->enabled)
-   return 0;
-
if (sharp_nt->backlight) {
sharp_nt->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(sharp_nt->backlight);
}
 
-   sharp_nt->enabled = true;
-
return 0;
 }
 
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 04/12] drm/panel: vvx10f034n00: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will WARN if
the calls are unbalanced.

Signed-off-by: Sean Paul 
---
No changes since v1

 .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 7f915f706fa6..e7efa097151c 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -44,9 +44,6 @@ struct wuxga_nt_panel {
struct backlight_device *backlight;
struct regulator *supply;
 
-   bool prepared;
-   bool enabled;
-
ktime_t earliest_wake;
 
const struct drm_display_mode *mode;
@@ -73,9 +70,6 @@ static int wuxga_nt_panel_disable(struct drm_panel *panel)
 {
struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
 
-   if (!wuxga_nt->enabled)
-   return 0;
-
mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
 
if (wuxga_nt->backlight) {
@@ -84,8 +78,6 @@ static int wuxga_nt_panel_disable(struct drm_panel *panel)
backlight_update_status(wuxga_nt->backlight);
}
 
-   wuxga_nt->enabled = false;
-
return 0;
 }
 
@@ -93,12 +85,8 @@ static int wuxga_nt_panel_unprepare(struct drm_panel *panel)
 {
struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
 
-   if (!wuxga_nt->prepared)
-   return 0;
-
regulator_disable(wuxga_nt->supply);
wuxga_nt->earliest_wake = ktime_add_ms(ktime_get_real(), MIN_POFF_MS);
-   wuxga_nt->prepared = false;
 
return 0;
 }
@@ -109,9 +97,6 @@ static int wuxga_nt_panel_prepare(struct drm_panel *panel)
int ret;
s64 enablewait;
 
-   if (wuxga_nt->prepared)
-   return 0;
-
/*
 * If the user re-enabled the panel before the required off-time then
 * we need to wait the remaining period before re-enabling regulator
@@ -141,8 +126,6 @@ static int wuxga_nt_panel_prepare(struct drm_panel *panel)
goto poweroff;
}
 
-   wuxga_nt->prepared = true;
-
return 0;
 
 poweroff:
@@ -155,17 +138,12 @@ static int wuxga_nt_panel_enable(struct drm_panel *panel)
 {
struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
 
-   if (wuxga_nt->enabled)
-   return 0;
-
if (wuxga_nt->backlight) {
wuxga_nt->backlight->props.power = FB_BLANK_UNBLANK;
wuxga_nt->backlight->props.state &= ~BL_CORE_FBBLANK;
backlight_update_status(wuxga_nt->backlight);
}
 
-   wuxga_nt->enabled = true;
-
return 0;
 }
 
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 05/12] drm/panel: lt070me05000: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced.

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340ef74ed..2f2455650258 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -50,9 +50,6 @@ struct jdi_panel {
struct gpio_desc *dcdc_en_gpio;
struct backlight_device *backlight;
 
-   bool prepared;
-   bool enabled;
-
const struct drm_display_mode *mode;
 };
 
@@ -189,14 +186,9 @@ static int jdi_panel_disable(struct drm_panel *panel)
 {
struct jdi_panel *jdi = to_jdi_panel(panel);
 
-   if (!jdi->enabled)
-   return 0;
-
jdi->backlight->props.power = FB_BLANK_POWERDOWN;
backlight_update_status(jdi->backlight);
 
-   jdi->enabled = false;
-
return 0;
 }
 
@@ -206,9 +198,6 @@ static int jdi_panel_unprepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
 
-   if (!jdi->prepared)
-   return 0;
-
jdi_panel_off(jdi);
 
ret = regulator_bulk_disable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
@@ -221,8 +210,6 @@ static int jdi_panel_unprepare(struct drm_panel *panel)
 
gpiod_set_value(jdi->dcdc_en_gpio, 0);
 
-   jdi->prepared = false;
-
return 0;
 }
 
@@ -232,9 +219,6 @@ static int jdi_panel_prepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
 
-   if (jdi->prepared)
-   return 0;
-
ret = regulator_bulk_enable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
if (ret < 0) {
dev_err(dev, "regulator enable failed, %d\n", ret);
@@ -264,8 +248,6 @@ static int jdi_panel_prepare(struct drm_panel *panel)
goto poweroff;
}
 
-   jdi->prepared = true;
-
return 0;
 
 poweroff:
@@ -286,14 +268,9 @@ static int jdi_panel_enable(struct drm_panel *panel)
 {
struct jdi_panel *jdi = to_jdi_panel(panel);
 
-   if (jdi->enabled)
-   return 0;
-
jdi->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(jdi->backlight);
 
-   jdi->enabled = true;
-
return 0;
 }
 
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 08/12] drm/panel: otm8009a: Properly sequence [un]prepare with backlight

[Sean Paul]

I noticed while removing the enabled flag that backlight update checks
prepared in such a way that could race with hardware turning on/off.
This patch adds a mutex to ensure these races don't happen.

In addition to the lock, this patch also renames prepared to initialized
to better reflect what it means when used in the backlight hook.

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 43 
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 0a5898fd4502..d099af3c91df 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define DRV_NAME "orisetech_otm8009a"
@@ -62,7 +63,9 @@ struct otm8009a {
struct drm_panel panel;
struct backlight_device *bl_dev;
struct gpio_desc *reset_gpio;
-   bool prepared;
+
+   struct mutex lock;
+   bool initialized;
 };
 
 static const struct drm_display_mode default_mode = {
@@ -265,26 +268,30 @@ static int otm8009a_unprepare(struct drm_panel *panel)
 {
struct otm8009a *ctx = panel_to_otm8009a(panel);
 
-   if (!ctx->prepared)
-   return 0;
+   mutex_lock(>lock);
+   if (!ctx->initialized)
+   goto out;
 
if (ctx->reset_gpio) {
gpiod_set_value_cansleep(ctx->reset_gpio, 1);
msleep(20);
}
 
-   ctx->prepared = false;
+   ctx->initialized = false;
 
+out:
+   mutex_unlock(>lock);
return 0;
 }
 
 static int otm8009a_prepare(struct drm_panel *panel)
 {
struct otm8009a *ctx = panel_to_otm8009a(panel);
-   int ret;
+   int ret = 0;
 
-   if (ctx->prepared)
-   return 0;
+   mutex_lock(>lock);
+   if (ctx->initialized)
+   goto out;
 
if (ctx->reset_gpio) {
gpiod_set_value_cansleep(ctx->reset_gpio, 0);
@@ -296,18 +303,20 @@ static int otm8009a_prepare(struct drm_panel *panel)
 
ret = otm8009a_init_sequence(ctx);
if (ret)
-   return ret;
+   goto out;
 
-   ctx->prepared = true;
+   ctx->initialized = true;
 
/*
 * Power on the backlight. Note: end-user still controls brightness
-* Note: ctx->prepared must be true before updating the backlight.
+* Note: ctx->initialized must be true before updating the backlight.
 */
ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
backlight_update_status(ctx->bl_dev);
 
-   return 0;
+out:
+   mutex_unlock(>lock);
+   return ret;
 }
 
 static int otm8009a_get_modes(struct drm_panel *panel)
@@ -348,10 +357,13 @@ static int otm8009a_backlight_update_status(struct 
backlight_device *bd)
 {
struct otm8009a *ctx = bl_get_data(bd);
u8 data[2];
+   int ret = 0;
 
-   if (!ctx->prepared) {
+   mutex_lock(>lock);
+   if (!ctx->initialized) {
DRM_DEBUG("lcd not ready yet for setting its backlight!\n");
-   return -ENXIO;
+   ret = -ENXIO;
+   goto out;
}
 
if (bd->props.power <= FB_BLANK_NORMAL) {
@@ -375,7 +387,9 @@ static int otm8009a_backlight_update_status(struct 
backlight_device *bd)
data[0] = MIPI_DCS_WRITE_CONTROL_DISPLAY;
otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data));
 
-   return 0;
+out:
+   mutex_unlock(>lock);
+   return ret;
 }
 
 static const struct backlight_ops otm8009a_backlight_ops = {
@@ -401,6 +415,7 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
 
ctx->dev = dev;
+   mutex_init(>lock);
 
dsi->lanes = 2;
dsi->format = MIPI_DSI_FMT_RGB888;
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 00/12] drm/panel: Remove unnecessary enabled/prepared state

[Sean Paul]

A number of panel drivers track enabled/prepared state (I suspect to protect
regulator refcounts). However, the atomic framework already ensures that
prepare/unprepare and enable/disable calls are balanced. This series removes all
independent tracking from the drivers and adds a WARNING to the core in case
someone uses a panel with a legacy driver.

Changes in v2:
- Addressed review comments in first patch
- Since the initial set didn't get much action, this is a partial RESEND

Changes in v3:
- Fixed typo in docs
- Moved static inlines out of header
- Used helper function to make the state transition
- All panel driver patches are the same as v1

Sean Paul (12):
  drm/panel: Fix typo in drm_panel_unprepare docs
  drm/panel: Move [un]prepare and [dis|en]able functions
  drm/panel: Keep track of enabled/prepared
  drm/panel: vvx10f034n00: Remove enabled/prepared state
  drm/panel: lt070me05000: Remove enabled/prepared state
  drm/panel: lq101r1sx01: Remove enabled/prepared state
  drm/panel: otm8009a: Remove enabled state
  drm/panel: otm8009a: Properly sequence [un]prepare with backlight
  drm/panel: 43wvf1g: Remove enabled/prepared state
  drm/panel: simple: Remove enabled/prepared state
  drm/panel: p079zca: Remove enabled/prepared state
  drm/panel: ls043t1le01: Remove enabled/prepared state

 drivers/gpu/drm/drm_panel.c| 116 +
 drivers/gpu/drm/panel/panel-innolux-p079zca.c  |  23 
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c |  23 
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c   |  59 ++-
 .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   |  22 
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|  24 -
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c|  23 
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c|  23 
 drivers/gpu/drm/panel/panel-simple.c   |  24 -
 include/drm/drm_panel.h|  93 -
 10 files changed, 165 insertions(+), 265 deletions(-)

-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 07/12] drm/panel: otm8009a: Remove enabled state

[Sean Paul]

It's not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced.

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index c189cd6329c8..0a5898fd4502 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -63,7 +63,6 @@ struct otm8009a {
struct backlight_device *bl_dev;
struct gpio_desc *reset_gpio;
bool prepared;
-   bool enabled;
 };
 
 static const struct drm_display_mode default_mode = {
@@ -243,9 +242,6 @@ static int otm8009a_disable(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
 
-   if (!ctx->enabled)
-   return 0; /* This is not an issue so we return 0 here */
-
/* Power off the backlight. Note: end-user still controls brightness */
ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
ret = backlight_update_status(ctx->bl_dev);
@@ -262,8 +258,6 @@ static int otm8009a_disable(struct drm_panel *panel)
 
msleep(120);
 
-   ctx->enabled = false;
-
return 0;
 }
 
@@ -316,15 +310,6 @@ static int otm8009a_prepare(struct drm_panel *panel)
return 0;
 }
 
-static int otm8009a_enable(struct drm_panel *panel)
-{
-   struct otm8009a *ctx = panel_to_otm8009a(panel);
-
-   ctx->enabled = true;
-
-   return 0;
-}
-
 static int otm8009a_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
@@ -352,7 +337,6 @@ static const struct drm_panel_funcs otm8009a_drm_funcs = {
.disable   = otm8009a_disable,
.unprepare = otm8009a_unprepare,
.prepare   = otm8009a_prepare,
-   .enable= otm8009a_enable,
.get_modes = otm8009a_get_modes,
 };
 
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 02/12] drm/panel: Move [un]prepare and [dis|en]able functions

[Sean Paul]

In preparation for state tracking in drm_panel, move the panel functions
into drm_panel.c so we beef them up in later patches.

Signed-off-by: Sean Paul 
---
New in v3

 drivers/gpu/drm/drm_panel.c | 77 
 include/drm/drm_panel.h | 78 +++--
 2 files changed, 82 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 308d442a531b..6f28598a5d0e 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -126,6 +126,83 @@ int drm_panel_detach(struct drm_panel *panel)
 }
 EXPORT_SYMBOL(drm_panel_detach);
 
+/**
+ * drm_panel_unprepare - power off a panel
+ * @panel: DRM panel
+ *
+ * Calling this function will completely power off a panel (assert the panel's
+ * reset, turn off power supplies, ...). After this function has completed, it
+ * is usually no longer possible to communicate with the panel until another
+ * call to drm_panel_prepare().
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_unprepare(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->unprepare)
+   return panel->funcs->unprepare(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_unprepare);
+
+/**
+ * drm_panel_disable - disable a panel
+ * @panel: DRM panel
+ *
+ * This will typically turn off the panel's backlight or disable the display
+ * drivers. For smart panels it should still be possible to communicate with
+ * the integrated circuitry via any command bus after this call.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_disable(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->disable)
+   return panel->funcs->disable(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_disable);
+
+/**
+ * drm_panel_prepare - power on a panel
+ * @panel: DRM panel
+ *
+ * Calling this function will enable power and deassert any reset signals to
+ * the panel. After this has completed it is possible to communicate with any
+ * integrated circuitry via a command bus.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_prepare(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->prepare)
+   return panel->funcs->prepare(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_prepare);
+
+/**
+ * drm_panel_enable - enable a panel
+ * @panel: DRM panel
+ *
+ * Calling this function will cause the panel display drivers to be turned on
+ * and the backlight to be enabled. Content will be visible on screen after
+ * this call completes.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_enable(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->enable)
+   return panel->funcs->enable(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_enable);
+
 #ifdef CONFIG_OF
 /**
  * of_drm_find_panel - look up a panel using a device tree node
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index ab59d71a24c3..0a9442069d3c 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -95,79 +95,6 @@ struct drm_panel {
struct list_head list;
 };
 
-/**
- * drm_panel_unprepare - power off a panel
- * @panel: DRM panel
- *
- * Calling this function will completely power off a panel (assert the panel's
- * reset, turn off power supplies, ...). After this function has completed, it
- * is usually no longer possible to communicate with the panel until another
- * call to drm_panel_prepare().
- *
- * Return: 0 on success or a negative error code on failure.
- */
-static inline int drm_panel_unprepare(struct drm_panel *panel)
-{
-   if (panel && panel->funcs && panel->funcs->unprepare)
-   return panel->funcs->unprepare(panel);
-
-   return panel ? -ENOSYS : -EINVAL;
-}
-
-/**
- * drm_panel_disable - disable a panel
- * @panel: DRM panel
- *
- * This will typically turn off the panel's backlight or disable the display
- * drivers. For smart panels it should still be possible to communicate with
- * the integrated circuitry via any command bus after this call.
- *
- * Return: 0 on success or a negative error code on failure.
- */
-static inline int drm_panel_disable(struct drm_panel *panel)
-{
-   if (panel && panel->funcs && panel->funcs->disable)
-   return panel->funcs->disable(panel);
-
-   return panel ? -ENOSYS : -EINVAL;
-}
-
-/**
- * drm_panel_prepare - power on a panel
- * @panel: DRM panel
- *
- * Calling this function will enable power and deassert any reset signals to
- * the panel. After this has completed it is possible to communicate with any
- * integrated circuitry via a command bus.
- *
- * Return: 0 on 

[PATCH v3 03/12] drm/panel: Keep track of enabled/prepared

[Sean Paul]

This patch adds state tracking to the drm_panel functions which keep
track of enabled and prepared. If the calls are unbalanced, a WARNING is
issued.

The motivation for this change is that a number of panel drivers
(including panel-simple) all do this to protect their regulator
refcounts. The atomic framework ensures the calls are balanced, and
there  aren't any panel drivers being used by legacy drivers. As such,
these checks are useless, but let's add a WARNING just in case something
crazy happens (like a legacy driver using a panel).

Less code == better.

Changes in v2:
 - Reduced enabled/prepared bools to one enum (Andrzej)
 - Don't update state if the operation fails (Andrzej)
 - Issue warning even if operation is not implemented

Changes in v3:
 - Functions no longer static inline (Daniel)
 - Added a helper function to share state change code (Andrzej)
 - Only warn when a panel is present (Daniel)
 - Update state if function is not implemented (Andrzej)

Cc: Andrzej Hajda 
Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_panel.c | 63 -
 include/drm/drm_panel.h | 15 +++
 2 files changed, 66 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 6f28598a5d0e..6547850b5e80 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -21,6 +21,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 
@@ -48,6 +49,7 @@ static LIST_HEAD(panel_list);
 void drm_panel_init(struct drm_panel *panel)
 {
INIT_LIST_HEAD(>list);
+   panel->state = DRM_PANEL_POWER_OFF;
 }
 EXPORT_SYMBOL(drm_panel_init);
 
@@ -126,6 +128,23 @@ int drm_panel_detach(struct drm_panel *panel)
 }
 EXPORT_SYMBOL(drm_panel_detach);
 
+static int drm_panel_change_state(struct drm_panel *panel,
+ enum drm_panel_state cur_state,
+ enum drm_panel_state new_state,
+ int (*hook)(struct drm_panel *panel))
+{
+   int ret;
+
+   WARN_ON(panel->state != cur_state);
+   if (hook)
+   ret = hook(panel);
+   else
+   ret = -ENOSYS;
+
+   panel->state = new_state;
+   return ret;
+}
+
 /**
  * drm_panel_unprepare - power off a panel
  * @panel: DRM panel
@@ -135,14 +154,19 @@ EXPORT_SYMBOL(drm_panel_detach);
  * is usually no longer possible to communicate with the panel until another
  * call to drm_panel_prepare().
  *
+ * Atomic framework will ensure that prepare/unprepare are properly balanced.
+ * If this is not the case, a WARNING will be issued.
+ *
  * Return: 0 on success or a negative error code on failure.
  */
 int drm_panel_unprepare(struct drm_panel *panel)
 {
-   if (panel && panel->funcs && panel->funcs->unprepare)
-   return panel->funcs->unprepare(panel);
+   if (!panel)
+   return -EINVAL;
 
-   return panel ? -ENOSYS : -EINVAL;
+   return drm_panel_change_state(panel, DRM_PANEL_POWER_PREPARED,
+ DRM_PANEL_POWER_OFF,
+ panel->funcs ? panel->funcs->unprepare : NULL);
 }
 EXPORT_SYMBOL(drm_panel_unprepare);
 
@@ -154,14 +178,19 @@ EXPORT_SYMBOL(drm_panel_unprepare);
  * drivers. For smart panels it should still be possible to communicate with
  * the integrated circuitry via any command bus after this call.
  *
+ * Atomic framework will ensure that enable/disable are properly balanced.
+ * If this is not the case, a WARNING will be issued.
+ *
  * Return: 0 on success or a negative error code on failure.
  */
 int drm_panel_disable(struct drm_panel *panel)
 {
-   if (panel && panel->funcs && panel->funcs->disable)
-   return panel->funcs->disable(panel);
+   if (!panel)
+   return -EINVAL;
 
-   return panel ? -ENOSYS : -EINVAL;
+   return drm_panel_change_state(panel, DRM_PANEL_POWER_ENABLED,
+ DRM_PANEL_POWER_PREPARED,
+ panel->funcs ? panel->funcs->disable : NULL);
 }
 EXPORT_SYMBOL(drm_panel_disable);
 
@@ -173,14 +202,19 @@ EXPORT_SYMBOL(drm_panel_disable);
  * the panel. After this has completed it is possible to communicate with any
  * integrated circuitry via a command bus.
  *
+ * Atomic framework will ensure that prepare/unprepare are properly balanced.
+ * If this is not the case, a WARNING will be issued.
+ *
  * Return: 0 on success or a negative error code on failure.
  */
 int drm_panel_prepare(struct drm_panel *panel)
 {
-   if (panel && panel->funcs && panel->funcs->prepare)
-   return panel->funcs->prepare(panel);
+   if (!panel)
+   return -EINVAL;
 
-   return panel ? -ENOSYS : -EINVAL;
+   return drm_panel_change_state(panel, DRM_PANEL_POWER_OFF,
+ DRM_PANEL_POWER_PREPARED,
+ panel->funcs ? 

[PATCH v3 06/12] drm/panel: lq101r1sx01: Remove enabled/prepared state

[Sean Paul]

They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced.

Signed-off-by: Sean Paul 
---
No changes since v1

 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 3cce3ca19601..9b447b0bfcd0 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -28,9 +28,6 @@ struct sharp_panel {
struct backlight_device *backlight;
struct regulator *supply;
 
-   bool prepared;
-   bool enabled;
-
const struct drm_display_mode *mode;
 };
 
@@ -93,16 +90,11 @@ static int sharp_panel_disable(struct drm_panel *panel)
 {
struct sharp_panel *sharp = to_sharp_panel(panel);
 
-   if (!sharp->enabled)
-   return 0;
-
if (sharp->backlight) {
sharp->backlight->props.power = FB_BLANK_POWERDOWN;
backlight_update_status(sharp->backlight);
}
 
-   sharp->enabled = false;
-
return 0;
 }
 
@@ -111,9 +103,6 @@ static int sharp_panel_unprepare(struct drm_panel *panel)
struct sharp_panel *sharp = to_sharp_panel(panel);
int err;
 
-   if (!sharp->prepared)
-   return 0;
-
sharp_wait_frames(sharp, 4);
 
err = mipi_dsi_dcs_set_display_off(sharp->link1);
@@ -128,8 +117,6 @@ static int sharp_panel_unprepare(struct drm_panel *panel)
 
regulator_disable(sharp->supply);
 
-   sharp->prepared = false;
-
return 0;
 }
 
@@ -173,9 +160,6 @@ static int sharp_panel_prepare(struct drm_panel *panel)
u8 format = MIPI_DCS_PIXEL_FMT_24BIT;
int err;
 
-   if (sharp->prepared)
-   return 0;
-
err = regulator_enable(sharp->supply);
if (err < 0)
return err;
@@ -244,8 +228,6 @@ static int sharp_panel_prepare(struct drm_panel *panel)
goto poweroff;
}
 
-   sharp->prepared = true;
-
/* wait for 6 frames before continuing */
sharp_wait_frames(sharp, 6);
 
@@ -260,16 +242,11 @@ static int sharp_panel_enable(struct drm_panel *panel)
 {
struct sharp_panel *sharp = to_sharp_panel(panel);
 
-   if (sharp->enabled)
-   return 0;
-
if (sharp->backlight) {
sharp->backlight->props.power = FB_BLANK_UNBLANK;
backlight_update_status(sharp->backlight);
}
 
-   sharp->enabled = true;
-
return 0;
 }
 
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[PATCH v3 01/12] drm/panel: Fix typo in drm_panel_unprepare docs

[Sean Paul]

Signed-off-by: Sean Paul 
---
New in v3

 include/drm/drm_panel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 14ac240a1f64..ab59d71a24c3 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -96,7 +96,7 @@ struct drm_panel {
 };
 
 /**
- * drm_disable_unprepare - power off a panel
+ * drm_panel_unprepare - power off a panel
  * @panel: DRM panel
  *
  * Calling this function will completely power off a panel (assert the panel's
-- 
2.15.0.rc1.287.g2b38de12cc-goog

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

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #5 from Nicolai Hähnle  ---
Thank you for the report!

Can you try with Mesa from git master?

The issue is that in Mesa 17.2.2 (which you have according to glxinfo),
si_state_draw.c:1305 corresponds to

   1304 index_offset -= start_offset;
   1305 } else if (sctx->b.chip_class <= CIK &&
   1306r600_resource(indexbuf)->TC_L2_dirty) {

and it's basically impossible to get a crash there, so I suspect the Gentoo
build actually applies some other patches.

Something random you could try is starting KWin with GALLIUM_THREAD=0.

-- 
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 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #52 from Daniel Vetter  ---
Reassigning to amdgpu.

-- 
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 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

Daniel Vetter  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |DRM/AMDgpu

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: adv7511: Fix a use after free

[Dan Carpenter]

We free "edid", then use it again on the next line.

Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 31ca883bda83..0e14f1572d05 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -607,10 +607,10 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
adv7511_set_config_csc(adv7511, connector, adv7511->rgb,
   drm_detect_hdmi_monitor(edid));
 
-   kfree(edid);
-
cec_s_phys_addr_from_edid(adv7511->cec_adap, edid);
 
+   kfree(edid);
+
return count;
 }
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 42/48] drm: omapdrm: dss: Remove unused functions prototypes

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:38PM +0300, Laurent Pinchart wrote:
> The omap_dss_register_driver(), omap_dss_unregister_driver() and
> dispc_enable_gamma_table() functions don't exist anymore, remove their
> prototypes.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Yeah, I also found the ones from omapdss.h:

https://patchwork.kernel.org/patch/9859893/

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dss.h | 1 -
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
> b/drivers/gpu/drm/omapdrm/dss/dss.h
> index 6950f5d61b6c..5d6f8afca49d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -388,7 +388,6 @@ void dispc_disable_sidle(void);
>  void dispc_lcd_enable_signal(bool enable);
>  void dispc_pck_free_enable(bool enable);
>  void dispc_enable_fifomerge(bool enable);
> -void dispc_enable_gamma_table(bool enable);
>  
>  typedef bool (*dispc_div_calc_func)(int lckd, int pckd, unsigned long lck,
>   unsigned long pck, void *data);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index 8024680e8d57..32c5944b0bea 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -583,9 +583,6 @@ struct omap_dss_driver {
>   const struct hdmi_avi_infoframe *avi);
>  };
>  
> -int omap_dss_register_driver(struct omap_dss_driver *);
> -void omap_dss_unregister_driver(struct omap_dss_driver *);
> -
>  int omapdss_register_display(struct omap_dss_device *dssdev);
>  void omapdss_unregister_display(struct omap_dss_device *dssdev);
>  
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Bug 103130] Mesa from git causes games to crash mid-play

[bugzilla-daemon]

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

--- Comment #7 from Nicolai Hähnle  ---
Thanks for the report!

The error message is benign. The only possible way in which it cause issues is
if the application itself is also trying to use LLVM.

If you could provide a backtrace with debug symbols, that would be helpful.

-- 
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 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer

[bugzilla-daemon]

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

--- Comment #1 from Nicolai Hähnle  ---
Do you have a simple test application you can share that reproduces this
reliably?

-- 
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] drm/msm/dsi: workaround for display enabled by bootloader

[Rob Clark]

On Tue, Oct 17, 2017 at 4:16 PM, Eric Anholt  wrote:
> Rob Clark  writes:
>
>> Bootloader enabled display, when the driver is built-in (rather than a
>> module loaded after CCF/genpd disable "unused" clocks/powerdomains)
>> causes problems since the driver thinks the clocks are off, but in fact
>> they are on.  This causes (for example) clk_set_rate() to fail.
>>
>> A better solution would be to support display handover from bootloader,
>> but that will require some CCF+genpd changes before that is possible.
>> So until then, we need this workaround.
>
> Hmm.  Couldn't the clk_set_rate() just turn off the clock and then make
> the rate change when there are no refs on the clk currently?

+sboyd

I *assume* the reasoning is something about parent clocks?

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

Re: [PATCH 41/48] drm: omapdrm: dss: Pass omap_dss_device pointer to dss_mgr_*() functions

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:37PM +0300, Laurent Pinchart wrote:
> The dss_mgr_*() functions take a channel argument to identify the
> channel they operate on. This prevents the functions from accessing
> driver data structures without resorting to global variables. In an
> effort to remove global variables, pass the omap_dss_device pointer
> associated with the channel instead. This will be used to look up the
> omap_drm_private data structure to pass to the dss_mgr_ops.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dpi.c | 32 ++
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 30 +++--
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c   | 20 +++--
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c   | 20 +++--
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 22 +-
>  drivers/gpu/drm/omapdrm/dss/output.c  | 42 
> ++-
>  drivers/gpu/drm/omapdrm/dss/sdi.c | 27 +-
>  drivers/gpu/drm/omapdrm/dss/venc.c| 18 ++-
>  8 files changed, 92 insertions(+), 119 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index b0f890a3c8db..3894e53ff58d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -344,8 +344,6 @@ static int dpi_set_dispc_clk(struct dpi_data *dpi, 
> unsigned long pck_req,
>  
>  static int dpi_set_mode(struct dpi_data *dpi)
>  {
> - struct omap_dss_device *out = >output;
> - enum omap_channel channel = out->dispc_channel;
>   struct videomode *vm = >vm;
>   int lck_div = 0, pck_div = 0;
>   unsigned long fck = 0;
> @@ -353,8 +351,8 @@ static int dpi_set_mode(struct dpi_data *dpi)
>   int r = 0;
>  
>   if (dpi->pll)
> - r = dpi_set_pll_clk(dpi, channel, vm->pixelclock, ,
> - _div, _div);
> + r = dpi_set_pll_clk(dpi, dpi->output.dispc_channel,
> + vm->pixelclock, , _div, _div);
>   else
>   r = dpi_set_dispc_clk(dpi, vm->pixelclock, ,
>   _div, _div);
> @@ -370,16 +368,13 @@ static int dpi_set_mode(struct dpi_data *dpi)
>   vm->pixelclock = pck;
>   }
>  
> - dss_mgr_set_timings(channel, vm);
> + dss_mgr_set_timings(>output, vm);
>  
>   return 0;
>  }
>  
>  static void dpi_config_lcd_manager(struct dpi_data *dpi)
>  {
> - struct omap_dss_device *out = >output;
> - enum omap_channel channel = out->dispc_channel;
> -
>   dpi->mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
>  
>   dpi->mgr_config.stallmode = false;
> @@ -389,14 +384,13 @@ static void dpi_config_lcd_manager(struct dpi_data *dpi)
>  
>   dpi->mgr_config.lcden_sig_polarity = 0;
>  
> - dss_mgr_set_lcd_config(channel, >mgr_config);
> + dss_mgr_set_lcd_config(>output, >mgr_config);
>  }
>  
>  static int dpi_display_enable(struct omap_dss_device *dssdev)
>  {
>   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
>   struct omap_dss_device *out = >output;
> - enum omap_channel channel = out->dispc_channel;
>   int r;
>  
>   mutex_lock(>lock);
> @@ -417,7 +411,7 @@ static int dpi_display_enable(struct omap_dss_device 
> *dssdev)
>   if (r)
>   goto err_get_dispc;
>  
> - r = dss_dpi_select_source(dpi->dss, out->port_num, channel);
> + r = dss_dpi_select_source(dpi->dss, out->port_num, out->dispc_channel);
>   if (r)
>   goto err_src_sel;
>  
> @@ -435,7 +429,7 @@ static int dpi_display_enable(struct omap_dss_device 
> *dssdev)
>  
>   mdelay(2);
>  
> - r = dss_mgr_enable(channel);
> + r = dss_mgr_enable(>output);
>   if (r)
>   goto err_mgr_enable;
>  
> @@ -462,14 +456,14 @@ static int dpi_display_enable(struct omap_dss_device 
> *dssdev)
>  static void dpi_display_disable(struct omap_dss_device *dssdev)
>  {
>   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
> - enum omap_channel channel = dpi->output.dispc_channel;
>  
>   mutex_lock(>lock);
>  
> - dss_mgr_disable(channel);
> + dss_mgr_disable(>output);
>  
>   if (dpi->pll) {
> - dss_select_lcd_clk_source(dpi->dss, channel, DSS_CLK_SRC_FCK);
> + dss_select_lcd_clk_source(dpi->dss, dpi->output.dispc_channel,
> +   DSS_CLK_SRC_FCK);
>   dss_pll_disable(dpi->pll);
>   }
>  
> @@ -659,7 +653,6 @@ static int dpi_connect(struct omap_dss_device *dssdev,
>   struct omap_dss_device *dst)
>  {
>   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
> - enum omap_channel channel = dpi->output.dispc_channel;
>   int r;
>  
>   r = dpi_init_regulator(dpi);
> @@ -668,7 +661,7 @@ static int 

Re: [PATCH] drm/msm/dsi: workaround for display enabled by bootloader

[Eric Anholt]

Rob Clark  writes:

> Bootloader enabled display, when the driver is built-in (rather than a
> module loaded after CCF/genpd disable "unused" clocks/powerdomains)
> causes problems since the driver thinks the clocks are off, but in fact
> they are on.  This causes (for example) clk_set_rate() to fail.
>
> A better solution would be to support display handover from bootloader,
> but that will require some CCF+genpd changes before that is possible.
> So until then, we need this workaround.

Hmm.  Couldn't the clk_set_rate() just turn off the clock and then make
the rate change when there are no refs on the clk currently?


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

Re: [PATCH 40/48] drm: omapdrm: dsi: Don't pass channel to dispc init/uninit functions

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:36PM +0300, Laurent Pinchart wrote:
> The dsi_display_init_dispc() and dsi_display_uninit_dispc() functions
> take a channel argument that is reduntant as it is always identical to
> the dsi->output.dispc_channel. Remove the argument and use the field
> directly in the functions to avoid misuse.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 9be26eb262f3..d1cc036ed280 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -217,10 +217,8 @@ struct dsi_reg { u16 module; u16 idx; };
>  typedef void (*omap_dsi_isr_t) (void *arg, u32 mask);
>  struct dsi_data;
>  
> -static int dsi_display_init_dispc(struct dsi_data *dsi,
> - enum omap_channel channel);
> -static void dsi_display_uninit_dispc(struct dsi_data *dsi,
> - enum omap_channel channel);
> +static int dsi_display_init_dispc(struct dsi_data *dsi);
> +static void dsi_display_uninit_dispc(struct dsi_data *dsi);
>  
>  static int dsi_vc_send_null(struct dsi_data *dsi, int channel);
>  
> @@ -3847,7 +3845,7 @@ static int dsi_enable_video_output(struct 
> omap_dss_device *dssdev, int channel)
>   return -ENODEV;
>   }
>  
> - r = dsi_display_init_dispc(dsi, dispc_channel);
> + r = dsi_display_init_dispc(dsi);
>   if (r)
>   goto err_init_dispc;
>  
> @@ -3897,7 +3895,7 @@ static int dsi_enable_video_output(struct 
> omap_dss_device *dssdev, int channel)
>   dsi_vc_enable(dsi, channel, false);
>   }
>  err_pix_fmt:
> - dsi_display_uninit_dispc(dsi, dispc_channel);
> + dsi_display_uninit_dispc(dsi);
>  err_init_dispc:
>   return r;
>  }
> @@ -3920,7 +3918,7 @@ static void dsi_disable_video_output(struct 
> omap_dss_device *dssdev, int channel
>  
>   dss_mgr_disable(dispc_channel);
>  
> - dsi_display_uninit_dispc(dsi, dispc_channel);
> + dsi_display_uninit_dispc(dsi);
>  }
>  
>  static void dsi_update_screen_dispc(struct dsi_data *dsi)
> @@ -4106,9 +4104,9 @@ static int dsi_configure_dispc_clocks(struct dsi_data 
> *dsi)
>   return 0;
>  }
>  
> -static int dsi_display_init_dispc(struct dsi_data *dsi,
> -   enum omap_channel channel)
> +static int dsi_display_init_dispc(struct dsi_data *dsi)
>  {
> + enum omap_channel channel = dsi->output.dispc_channel;
>   int r;
>  
>   dss_select_lcd_clk_source(dsi->dss, channel, dsi->module_id == 0 ?
> @@ -4169,9 +4167,10 @@ static int dsi_display_init_dispc(struct dsi_data *dsi,
>   return r;
>  }
>  
> -static void dsi_display_uninit_dispc(struct dsi_data *dsi,
> -  enum omap_channel channel)
> +static void dsi_display_uninit_dispc(struct dsi_data *dsi)
>  {
> + enum omap_channel channel = dsi->output.dispc_channel;
> +
>   if (dsi->mode == OMAP_DSS_DSI_CMD_MODE)
>   dss_mgr_unregister_framedone_handler(channel,
>   dsi_framedone_irq_callback, dsi);
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [PATCH 39/48] drm: omapdrm: dsi: Store the struct device pointer in struct dsi_data

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:35PM +0300, Laurent Pinchart wrote:
> The dsi_data structure stores a pointer to a struct platform_device. The
> driver only uses the dev member of the platform device structure. Store
> the struct device pointer instead and use it directly.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 4f67dd70f279..9be26eb262f3 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -332,7 +332,7 @@ struct dsi_of_data {
>  };
>  
>  struct dsi_data {
> - struct platform_device *pdev;
> + struct device *dev;
>   void __iomem *proto_base;
>   void __iomem *phy_base;
>   void __iomem *pll_base;
> @@ -1146,7 +1146,7 @@ static int dsi_runtime_get(struct dsi_data *dsi)
>  
>   DSSDBG("dsi_runtime_get\n");
>  
> - r = pm_runtime_get_sync(>pdev->dev);
> + r = pm_runtime_get_sync(dsi->dev);
>   WARN_ON(r < 0);
>   return r < 0 ? r : 0;
>  }
> @@ -1157,7 +1157,7 @@ static void dsi_runtime_put(struct dsi_data *dsi)
>  
>   DSSDBG("dsi_runtime_put\n");
>  
> - r = pm_runtime_put_sync(>pdev->dev);
> + r = pm_runtime_put_sync(dsi->dev);
>   WARN_ON(r < 0 && r != -ENOSYS);
>  }
>  
> @@ -1168,7 +1168,7 @@ static int dsi_regulator_init(struct dsi_data *dsi)
>   if (dsi->vdds_dsi_reg != NULL)
>   return 0;
>  
> - vdds_dsi = devm_regulator_get(>pdev->dev, "vdd");
> + vdds_dsi = devm_regulator_get(dsi->dev, "vdd");
>  
>   if (IS_ERR(vdds_dsi)) {
>   if (PTR_ERR(vdds_dsi) != -EPROBE_DEFER)
> @@ -4953,7 +4953,7 @@ static int dsi_get_clocks(struct dsi_data *dsi)
>  {
>   struct clk *clk;
>  
> - clk = devm_clk_get(>pdev->dev, "fck");
> + clk = devm_clk_get(dsi->dev, "fck");
>   if (IS_ERR(clk)) {
>   DSSERR("can't get fck\n");
>   return PTR_ERR(clk);
> @@ -5048,7 +5048,7 @@ static void dsi_init_output(struct dsi_data *dsi)
>  {
>   struct omap_dss_device *out = >output;
>  
> - out->dev = >pdev->dev;
> + out->dev = dsi->dev;
>   out->id = dsi->module_id == 0 ?
>   OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2;
>  
> @@ -5070,7 +5070,7 @@ static void dsi_uninit_output(struct dsi_data *dsi)
>  
>  static int dsi_probe_of(struct dsi_data *dsi)
>  {
> - struct device_node *node = dsi->pdev->dev.of_node;
> + struct device_node *node = dsi->dev->of_node;
>   struct property *prop;
>   u32 lane_arr[10];
>   int len, num_pins;
> @@ -5084,7 +5084,7 @@ static int dsi_probe_of(struct dsi_data *dsi)
>  
>   prop = of_find_property(ep, "lanes", );
>   if (prop == NULL) {
> - dev_err(>pdev->dev, "failed to find lane data\n");
> + dev_err(dsi->dev, "failed to find lane data\n");
>   r = -EINVAL;
>   goto err;
>   }
> @@ -5093,14 +5093,14 @@ static int dsi_probe_of(struct dsi_data *dsi)
>  
>   if (num_pins < 4 || num_pins % 2 != 0 ||
>   num_pins > dsi->num_lanes_supported * 2) {
> - dev_err(>pdev->dev, "bad number of lanes\n");
> + dev_err(dsi->dev, "bad number of lanes\n");
>   r = -EINVAL;
>   goto err;
>   }
>  
>   r = of_property_read_u32_array(ep, "lanes", lane_arr, num_pins);
>   if (r) {
> - dev_err(>pdev->dev, "failed to read lane data\n");
> + dev_err(dsi->dev, "failed to read lane data\n");
>   goto err;
>   }
>  
> @@ -5110,7 +5110,7 @@ static int dsi_probe_of(struct dsi_data *dsi)
>  
>   r = dsi_configure_pins(>output, _cfg);
>   if (r) {
> - dev_err(>pdev->dev, "failed to configure pins");
> + dev_err(dsi->dev, "failed to configure pins");
>   goto err;
>   }
>  
> @@ -5216,7 +5216,7 @@ static int dsi_init_pll_data(struct dss_device *dss, 
> struct dsi_data *dsi)
>   struct clk *clk;
>   int r;
>  
> - clk = devm_clk_get(>pdev->dev, "sys_clk");
> + clk = devm_clk_get(dsi->dev, "sys_clk");
>   if (IS_ERR(clk)) {
>   DSSERR("can't get sys_clk\n");
>   return PTR_ERR(clk);
> @@ -5320,7 +5320,7 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>   return -ENOMEM;
>  
>   dsi->dss = dss;
> - dsi->pdev = pdev;
> + dsi->dev = dev;
>   dev_set_drvdata(dev, dsi);
>  
>   spin_lock_init(>irq_lock);
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: 

Re: [PATCH 38/48] drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:34PM +0300, Laurent Pinchart wrote:
> The dsi_bind() function receives a pointer to a struct device that it
> casts to a struct platform_device, only to use the platform device's dev
> field through the code. Use the dev pointer directly.
> 
> While at it rename the struct platform_device pointer dsidev to pdev to
> make it more explicit.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index a763ab7ed657..4f67dd70f279 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5302,9 +5302,10 @@ static const struct soc_device_attribute 
> dsi_soc_devices[] = {
>   { .machine = "AM35*",   .data = _of_data_omap34xx },
>   { /* sentinel */ }
>  };
> +
>  static int dsi_bind(struct device *dev, struct device *master, void *data)
>  {
> - struct platform_device *dsidev = to_platform_device(dev);
> + struct platform_device *pdev = to_platform_device(dev);
>   struct dss_device *dss = dss_get_device(master);
>   const struct soc_device_attribute *soc;
>   const struct dsi_module_id_data *d;
> @@ -5314,13 +5315,13 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>   struct resource *dsi_mem;
>   struct resource *res;
>  
> - dsi = devm_kzalloc(>dev, sizeof(*dsi), GFP_KERNEL);
> + dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
>   if (!dsi)
>   return -ENOMEM;
>  
>   dsi->dss = dss;
> - dsi->pdev = dsidev;
> - dev_set_drvdata(>dev, dsi);
> + dsi->pdev = pdev;
> + dev_set_drvdata(dev, dsi);
>  
>   spin_lock_init(>irq_lock);
>   spin_lock_init(>errors_lock);
> @@ -5343,29 +5344,29 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>   dsi->te_timer.data = 0;
>  #endif
>  
> - dsi_mem = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "proto");
> - dsi->proto_base = devm_ioremap_resource(>dev, dsi_mem);
> + dsi_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, "proto");
> + dsi->proto_base = devm_ioremap_resource(dev, dsi_mem);
>   if (IS_ERR(dsi->proto_base))
>   return PTR_ERR(dsi->proto_base);
>  
> - res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "phy");
> - dsi->phy_base = devm_ioremap_resource(>dev, res);
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy");
> + dsi->phy_base = devm_ioremap_resource(dev, res);
>   if (IS_ERR(dsi->phy_base))
>   return PTR_ERR(dsi->phy_base);
>  
> - res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "pll");
> - dsi->pll_base = devm_ioremap_resource(>dev, res);
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pll");
> + dsi->pll_base = devm_ioremap_resource(dev, res);
>   if (IS_ERR(dsi->pll_base))
>   return PTR_ERR(dsi->pll_base);
>  
> - dsi->irq = platform_get_irq(dsi->pdev, 0);
> + dsi->irq = platform_get_irq(pdev, 0);
>   if (dsi->irq < 0) {
>   DSSERR("platform_get_irq failed\n");
>   return -ENODEV;
>   }
>  
> - r = devm_request_irq(>dev, dsi->irq, omap_dsi_irq_handler,
> -  IRQF_SHARED, dev_name(>dev), dsi);
> + r = devm_request_irq(dev, dsi->irq, omap_dsi_irq_handler,
> +  IRQF_SHARED, dev_name(dev), dsi);
>   if (r < 0) {
>   DSSERR("request_irq failed\n");
>   return r;
> @@ -5419,14 +5420,14 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>  
>   dsi_init_pll_data(dss, dsi);
>  
> - pm_runtime_enable(>dev);
> + pm_runtime_enable(dev);
>  
>   r = dsi_runtime_get(dsi);
>   if (r)
>   goto err_runtime_get;
>  
>   rev = dsi_read_reg(dsi, DSI_REVISION);
> - dev_dbg(>dev, "OMAP DSI rev %d.%d\n",
> + dev_dbg(dev, "OMAP DSI rev %d.%d\n",
>  FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
>  
>   /* DSI on OMAP3 doesn't have register DSI_GNQ, set number
> @@ -5447,7 +5448,7 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>   goto err_probe_of;
>   }
>  
> - r = of_platform_populate(dsidev->dev.of_node, NULL, NULL, >dev);
> + r = of_platform_populate(dev->of_node, NULL, NULL, dev);
>   if (r)
>   DSSERR("Failed to populate DSI child devices: %d\n", r);
>  
> @@ -5479,7 +5480,7 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>   dsi_runtime_put(dsi);
>  
>  err_runtime_get:
> - pm_runtime_disable(>dev);
> + pm_runtime_disable(dev);
> 

Re: [PATCH 37/48] drm: omapdrm: dsi: Combine two commonly used inline functions

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:33PM +0300, Laurent Pinchart wrote:
> The dsi_get_dsidrv_data() and dsi_get_dsidev_from_dssdev() inline
> functions convert a struct omap_dss_device pointer to the corresponding
> struct platform_device, and a struct platform_device pointer to the
> corresponding struct dsi_data. They are nearly always called together
> without any use of the intermediate platform_device, so combine them
> into a single function.
> 
> In the three locations where only dsi_get_dsidrv_data() is used, call
> dev_get_drvdata() directly.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 90 
> +--
>  1 file changed, 30 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 312804104ad3..a763ab7ed657 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -441,14 +441,9 @@ static bool dsi_perf;
>  module_param(dsi_perf, bool, 0644);
>  #endif
>  
> -static inline struct dsi_data *dsi_get_dsidrv_data(struct platform_device 
> *dsidev)
> +static inline struct dsi_data *to_dsi_data(struct omap_dss_device *dssdev)
>  {
> - return dev_get_drvdata(>dev);
> -}
> -
> -static inline struct platform_device *dsi_get_dsidev_from_dssdev(struct 
> omap_dss_device *dssdev)
> -{
> - return to_platform_device(dssdev->dev);
> + return dev_get_drvdata(dssdev->dev);
>  }
>  
>  static struct dsi_data *dsi_get_dsi_from_id(int module)
> @@ -469,7 +464,7 @@ static struct dsi_data *dsi_get_dsi_from_id(int module)
>  
>   out = omap_dss_get_output(id);
>  
> - return out ? dsi_get_dsidrv_data(to_platform_device(out->dev)) : NULL;
> + return out ? to_dsi_data(out) : NULL;
>  }
>  
>  static inline void dsi_write_reg(struct dsi_data *dsi,
> @@ -503,16 +498,14 @@ static inline u32 dsi_read_reg(struct dsi_data *dsi, 
> const struct dsi_reg idx)
>  
>  static void dsi_bus_lock(struct omap_dss_device *dssdev)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>  
>   down(>bus_lock);
>  }
>  
>  static void dsi_bus_unlock(struct omap_dss_device *dssdev)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>  
>   up(>bus_lock);
>  }
> @@ -2536,8 +2529,7 @@ static int dsi_vc_config_source(struct dsi_data *dsi, 
> int channel,
>  static void dsi_vc_enable_hs(struct omap_dss_device *dssdev, int channel,
>   bool enable)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>  
>   DSSDBG("dsi_vc_enable_hs(%d, %d)\n", channel, enable);
>  
> @@ -2660,8 +2652,7 @@ static int dsi_vc_send_bta(struct dsi_data *dsi, int 
> channel)
>  
>  static int dsi_vc_send_bta_sync(struct omap_dss_device *dssdev, int channel)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>   DECLARE_COMPLETION_ONSTACK(completion);
>   int r = 0;
>   u32 err;
> @@ -2863,8 +2854,7 @@ static int dsi_vc_write_nosync_common(struct dsi_data 
> *dsi, int channel,
>  static int dsi_vc_dcs_write_nosync(struct omap_dss_device *dssdev, int 
> channel,
>   u8 *data, int len)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>  
>   return dsi_vc_write_nosync_common(dsi, channel, data, len,
>   DSS_DSI_CONTENT_DCS);
> @@ -2873,8 +2863,7 @@ static int dsi_vc_dcs_write_nosync(struct 
> omap_dss_device *dssdev, int channel,
>  static int dsi_vc_generic_write_nosync(struct omap_dss_device *dssdev, int 
> channel,
>   u8 *data, int len)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct dsi_data *dsi = to_dsi_data(dssdev);
>  
>   return dsi_vc_write_nosync_common(dsi, channel, data, len,
>   DSS_DSI_CONTENT_GENERIC);
> @@ -2884,8 +2873,7 @@ static int dsi_vc_write_common(struct omap_dss_device 
> *dssdev,
>  int channel, u8 *data, int len,
>  enum dss_dsi_content_type type)
>  {
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = 

Re: [PATCH 36/48] drm: omapdrm: dsi: Pass the dsi_data pointer to internal functions

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:32PM +0300, Laurent Pinchart wrote:
> Internal dsi functions take a pointer to the DSI platform_device and
> then cast it to a dsi_data pointer. That's pointless as the caller
> already has the dsi_data pointer. Pass it directly instead of the
> platform_device pointer.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 1228 
> +
>  1 file changed, 564 insertions(+), 664 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c94bb6404a69..312804104ad3 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -121,11 +121,11 @@ struct dsi_reg { u16 module; u16 idx; };
>  #define DSI_PLL_CONFIGURATION1   DSI_REG(DSI_PLL, 0x000C)
>  #define DSI_PLL_CONFIGURATION2   DSI_REG(DSI_PLL, 0x0010)
>  
> -#define REG_GET(dsidev, idx, start, end) \
> - FLD_GET(dsi_read_reg(dsidev, idx), start, end)
> +#define REG_GET(dsi, idx, start, end) \
> + FLD_GET(dsi_read_reg(dsi, idx), start, end)
>  
> -#define REG_FLD_MOD(dsidev, idx, val, start, end) \
> - dsi_write_reg(dsidev, idx, FLD_MOD(dsi_read_reg(dsidev, idx), val, 
> start, end))
> +#define REG_FLD_MOD(dsi, idx, val, start, end) \
> + dsi_write_reg(dsi, idx, FLD_MOD(dsi_read_reg(dsi, idx), val, start, 
> end))
>  
>  /* Global interrupts */
>  #define DSI_IRQ_VC0  (1 << 0)
> @@ -215,13 +215,14 @@ struct dsi_reg { u16 module; u16 idx; };
>DSI_CIO_IRQ_ERRCONTENTIONLP0_5 | DSI_CIO_IRQ_ERRCONTENTIONLP1_5)
>  
>  typedef void (*omap_dsi_isr_t) (void *arg, u32 mask);
> +struct dsi_data;
>  
> -static int dsi_display_init_dispc(struct platform_device *dsidev,
> +static int dsi_display_init_dispc(struct dsi_data *dsi,
>   enum omap_channel channel);
> -static void dsi_display_uninit_dispc(struct platform_device *dsidev,
> +static void dsi_display_uninit_dispc(struct dsi_data *dsi,
>   enum omap_channel channel);
>  
> -static int dsi_vc_send_null(struct omap_dss_device *dssdev, int channel);
> +static int dsi_vc_send_null(struct dsi_data *dsi, int channel);
>  
>  /* DSI PLL HSDIV indices */
>  #define HSDIV_DISPC  0
> @@ -284,7 +285,7 @@ struct dsi_isr_tables {
>  };
>  
>  struct dsi_clk_calc_ctx {
> - struct platform_device *dsidev;
> + struct dsi_data *dsi;
>   struct dss_pll *pll;
>  
>   /* inputs */
> @@ -431,7 +432,7 @@ struct dsi_data {
>  };
>  
>  struct dsi_packet_sent_handler_data {
> - struct platform_device *dsidev;
> + struct dsi_data *dsi;
>   struct completion *completion;
>  };
>  
> @@ -450,7 +451,7 @@ static inline struct platform_device 
> *dsi_get_dsidev_from_dssdev(struct omap_dss
>   return to_platform_device(dssdev->dev);
>  }
>  
> -static struct platform_device *dsi_get_dsidev_from_id(int module)
> +static struct dsi_data *dsi_get_dsi_from_id(int module)
>  {
>   struct omap_dss_device *out;
>   enum omap_dss_output_id id;
> @@ -468,13 +469,12 @@ static struct platform_device 
> *dsi_get_dsidev_from_id(int module)
>  
>   out = omap_dss_get_output(id);
>  
> - return out ? to_platform_device(out->dev) : NULL;
> + return out ? dsi_get_dsidrv_data(to_platform_device(out->dev)) : NULL;
>  }
>  
> -static inline void dsi_write_reg(struct platform_device *dsidev,
> - const struct dsi_reg idx, u32 val)
> +static inline void dsi_write_reg(struct dsi_data *dsi,
> +  const struct dsi_reg idx, u32 val)
>  {
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>   void __iomem *base;
>  
>   switch(idx.module) {
> @@ -487,10 +487,8 @@ static inline void dsi_write_reg(struct platform_device 
> *dsidev,
>   __raw_writel(val, base + idx.idx);
>  }
>  
> -static inline u32 dsi_read_reg(struct platform_device *dsidev,
> - const struct dsi_reg idx)
> +static inline u32 dsi_read_reg(struct dsi_data *dsi, const struct dsi_reg 
> idx)
>  {
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>   void __iomem *base;
>  
>   switch(idx.module) {
> @@ -519,10 +517,8 @@ static void dsi_bus_unlock(struct omap_dss_device 
> *dssdev)
>   up(>bus_lock);
>  }
>  
> -static bool dsi_bus_is_locked(struct platform_device *dsidev)
> +static bool dsi_bus_is_locked(struct dsi_data *dsi)
>  {
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> -
>   return dsi->bus_lock.count == 0;
>  }
>  
> @@ -531,8 +527,9 @@ static void dsi_completion_handler(void *data, u32 mask)
>   complete((struct completion *)data);
>  }
>  
> -static inline bool wait_for_bit_change(struct platform_device *dsidev,
> - const struct dsi_reg idx, int bitnum, int value)
> +static inline bool wait_for_bit_change(struct dsi_data *dsi,
> +   

Re: [PATCH v3 1/2] drm: Move debug macros out of drmP.h

[Sean Paul]

On Tue, Oct 17, 2017 at 02:43:38AM -0600, Haneen Mohammed wrote:
> This patch extract DRM_* debug macros from drmP.h to drm_print.h and
> move printing related functions used by these macros from drm_drv.[hc]
> to drm_print.[hc].
> 
> Signed-off-by: Haneen Mohammed 
> ---
> Changes in v3:
> - Move debug macros and print functions into drm_print.[hc] instead of
> introducing drm_debug.[hc].
> 
>  drivers/gpu/drm/drm_drv.c   |  47 -
>  drivers/gpu/drm/drm_print.c |  47 +
>  include/drm/drmP.h  | 150 +-
>  include/drm/drm_drv.h   |   7 --
>  include/drm/drm_print.h | 156 
> 
>  5 files changed, 204 insertions(+), 203 deletions(-)
> 



> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 7277783a..2ba73ff4 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -75,6 +75,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -142,160 +143,11 @@ struct pci_controller;
>  /*@{*/
>  

Any reason why you didn't move the DRM_UT_* defines as well? They're sprinkled
through a couple drivers, but it's all related to debug messaging.

Sean

>  /***/
> -/** \name Macros to make printk easier */
> -/*@{*/
> -
> -#define _DRM_PRINTK(once, level, fmt, ...)   \
> - do {\
> - printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
> -  ##__VA_ARGS__);\
> - } while (0)
> -
> -#define DRM_INFO(fmt, ...)   \
> - _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
> -#define DRM_NOTE(fmt, ...)   \
> - _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
> -#define DRM_WARN(fmt, ...)   \
> - _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
> -
> -#define DRM_INFO_ONCE(fmt, ...)  
> \
> - _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
> -#define DRM_NOTE_ONCE(fmt, ...)  
> \
> - _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
> -#define DRM_WARN_ONCE(fmt, ...)  
> \
> - _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
> -
> -/**
> - * Error output.
> - *
> - * \param fmt printf() like format string.
> - * \param arg arguments
> - */
> -#define DRM_DEV_ERROR(dev, fmt, ...) \
> - drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
> -fmt, ##__VA_ARGS__)
> -#define DRM_ERROR(fmt, ...)  \
> - drm_printk(KERN_ERR, DRM_UT_NONE, fmt,  ##__VA_ARGS__)
> -
> -/**
> - * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
> - *
> - * \param fmt printf() like format string.
> - * \param arg arguments
> - */
> -#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
> -({   \
> - static DEFINE_RATELIMIT_STATE(_rs,  \
> -   DEFAULT_RATELIMIT_INTERVAL,   \
> -   DEFAULT_RATELIMIT_BURST); \
> - \
> - if (__ratelimit(&_rs))  \
> - DRM_DEV_ERROR(dev, fmt, ##__VA_ARGS__); \
> -})
> -#define DRM_ERROR_RATELIMITED(fmt, ...)  
> \
> - DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> -
> -#define DRM_DEV_INFO(dev, fmt, ...)  \
> - drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt,  \
> -##__VA_ARGS__)
> -
> -#define DRM_DEV_INFO_ONCE(dev, fmt, ...) \
> -({   \
> - static bool __print_once __read_mostly; \
> - if (!__print_once) {\
> - __print_once = true;\
> - DRM_DEV_INFO(dev, fmt, ##__VA_ARGS__);  \
> - }   \
> -})
> -
> -/**
> - * Debug output.
> - *
> - * \param fmt printf() like format string.
> - * \param arg arguments
> - */
> -#define DRM_DEV_DEBUG(dev, fmt, args...) \
> - drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
> -##args)
> -#define DRM_DEBUG(fmt, ...)  \
> - drm_printk(KERN_DEBUG, 

Re: [PATCH 5/9] drm/panel: simple: add support for EDT ET0350 3.5" QVGA panel

[Rob Herring]

On Wed, Oct 11, 2017 at 01:23:37PM +0200, Lothar Waßmann wrote:
> Signed-off-by: Lothar Waßmann 
> ---
>  .../bindings/display/panel/edt,et0350g0dh6.txt|  7 +++

Please split bindings to separate patch.

>  drivers/gpu/drm/panel/panel-simple.c  | 19 
> +++
>  2 files changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/edt,et0350g0dh6.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/edt,et0350g0dh6.txt 
> b/Documentation/devicetree/bindings/display/panel/edt,et0350g0dh6.txt
> new file mode 100644
> index 000..5546221
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/edt,et0350g0dh6.txt
> @@ -0,0 +1,7 @@
> +Emerging Display Technology Corp. 3.5" QVGA (320x240) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "edt,et0350g0dh6"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

No reset lines, power supplies, etc.? Yes, simple-panel.txt defines 
properties, but you still need to specify which ones you use. Otherwise, 
I don't know if this panel has a single supply or you just forgot to 
define the supplies.

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

Re: [PATCH] drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels

[Maxime Ripard]

Hi,

On Tue, Oct 17, 2017 at 10:09:46PM +1100, Jonathan Liu wrote:
> Dithering is supported on TCON channel 0 which is used for LCD panels.

Expanding a bit the commit log would be great. What is dithering, why
is this needed in the first place, what is it trying to fix, etc.

> Signed-off-by: Jonathan Liu 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 37 +
>  drivers/gpu/drm/sun4i/sun4i_tcon.h | 18 +-
>  2 files changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 68751b999877..cf313ca858b3 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -12,11 +12,13 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -168,7 +170,9 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> struct drm_display_mode *mode)
>  {
>   unsigned int bp, hsync, vsync;
> + u32 bus_format = 0;
>   u8 clk_delay;
> + struct drm_connector *connector = tcon->panel->connector;

You shouldn't access the connector directly, but instead use the
current state associated to the encoder.

>   u32 val = 0;
>  
>   /* Configure the dot clock */
> @@ -230,6 +234,39 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
>  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
> SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
>  val);
>  
> + if (connector->display_info.num_bus_formats)
> + bus_format = connector->display_info.bus_formats[0];
> +
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + case MEDIA_BUS_FMT_RGB666_1X18:

I guess that has more to do with the bit width than the actual media
bus.

I've created helper for both these two in my LVDS patch set, you might
want to rebase on top of it.

> + /* Enable dithering */
> + /* FIXME: Undocumented bits */
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED0_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED1_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED2_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED3_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED4_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED5_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB0_REG, 0x0101);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB1_REG, 0x1515);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB2_REG, 0x5757);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB3_REG, 0x7f7f);
> + val = SUN4I_TCON0_FRM_CTL_ENABLE;
> +
> + if (bus_format == MEDIA_BUS_FMT_RGB565_1X16) {
> + val |= SUN4I_TCON0_FRM_CTL_MODE_R;
> + val |= SUN4I_TCON0_FRM_CTL_MODE_B;
> + }

This can be moved to the first case in your switch, and just let it
fall through. You won't have to do a comparison twice then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 103317] Tearing in WQHD, but not in FHD

[bugzilla-daemon]

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

--- Comment #1 from Torsten Kessler  ---
Created attachment 134889
  --> https://bugs.freedesktop.org/attachment.cgi?id=134889=edit
Dmesg output

-- 
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 103317] Tearing in WQHD, but not in FHD

[bugzilla-daemon]

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

Bug ID: 103317
   Summary: Tearing in WQHD, but not in FHD
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: torke...@gmail.com

Created attachment 134888
  --> https://bugs.freedesktop.org/attachment.cgi?id=134888=edit
X server log

Hi all,

I'm using Arch Linux with kernel 4.13.5-1-ARCH, Xorg 1.19.5 and the amdgpu
driver, version 1.4. My GPU is a R9 390. I attached the X server log.
My window manager is i3.

Entries in xorg.conf.d:

20-amdgpu.conf

Section "Device"
Identifier "AMD R9 390"
Driver "amdgpu"
Option "DRI" "3"
Option "TearFree" "true"
EndSection

With this setup I experience screen tearing and flickering on a WQHD monitor.
Enabling a compositor like compton makes these effects worse.
I can reproduce this issue on the same machine with KDE instead of i3.
To give you an idea of my problem, I captured a scene from the RTS 0ad:

https://youtu.be/ZhjPpB7djyk

The same kind of flickering and tearing also happens in desktop mode. It seems
to appear randomly.
However, the problem disappears when I'm using the radeonsi driver or changing
the resolution to FHD. In both cases everything is fine.

-- 
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 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #4 from Dennis Schridde  ---
I now also have this card plugged into the system:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Baffin [Radeon RX 560] (rev cf) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Baffin [Radeon RX 560]
Flags: bus master, fast devsel, latency 0, IRQ 51
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f000 (64-bit, prefetchable) [size=2M]
I/O ports at e000 [size=256]
Memory at fea0 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at fea4 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Capabilities: [150] Advanced Error Reporting
Capabilities: [200] #15
Capabilities: [270] #19
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] Page Request Interface (PRI)
Capabilities: [2d0] Process Address Space ID (PASID)
Capabilities: [320] Latency Tolerance Reporting
Capabilities: [328] Alternative Routing-ID Interpretation (ARI)
Capabilities: [370] L1 PM Substates
Kernel driver in use: amdgpu
Kernel modules: amdgpu

The monitor is still connected to the other card (comment #1), though.

-- 
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 35/48] drm: omapdrm: dsi: Make wait_for_bit_change() return a status

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:31PM +0300, Laurent Pinchart wrote:
> The wait_for_bit_change() function returns the value of the bit it
> polls. This requires the caller to compare the return value to the
> expected bit value. As all the existing callers need is to check whether
> the bit has reached the expected value, it's easier to return a boolean
> status from the function.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dsi.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 7fb048023fd0..c94bb6404a69 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -531,7 +531,7 @@ static void dsi_completion_handler(void *data, u32 mask)
>   complete((struct completion *)data);
>  }
>  
> -static inline int wait_for_bit_change(struct platform_device *dsidev,
> +static inline bool wait_for_bit_change(struct platform_device *dsidev,
>   const struct dsi_reg idx, int bitnum, int value)
>  {
>   unsigned long timeout;
> @@ -542,21 +542,21 @@ static inline int wait_for_bit_change(struct 
> platform_device *dsidev,
>   t = 100;
>   while (t-- > 0) {
>   if (REG_GET(dsidev, idx, bitnum, bitnum) == value)
> - return value;
> + return true;
>   }
>  
>   /* then loop for 500ms, sleeping for 1ms in between */
>   timeout = jiffies + msecs_to_jiffies(500);
>   while (time_before(jiffies, timeout)) {
>   if (REG_GET(dsidev, idx, bitnum, bitnum) == value)
> - return value;
> + return true;
>  
>   wait = ns_to_ktime(1000 * 1000);
>   set_current_state(TASK_UNINTERRUPTIBLE);
>   schedule_hrtimeout(, HRTIMER_MODE_REL);
>   }
>  
> - return !value;
> + return false;
>  }
>  
>  static u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
> @@ -1259,9 +1259,9 @@ static inline int dsi_if_enable(struct platform_device 
> *dsidev, bool enable)
>   enable = enable ? 1 : 0;
>   REG_FLD_MOD(dsidev, DSI_CTRL, enable, 0, 0); /* IF_EN */
>  
> - if (wait_for_bit_change(dsidev, DSI_CTRL, 0, enable) != enable) {
> - DSSERR("Failed to set dsi_if_enable to %d\n", enable);
> - return -EIO;
> + if (!wait_for_bit_change(dsidev, DSI_CTRL, 0, enable)) {
> + DSSERR("Failed to set dsi_if_enable to %d\n", enable);
> + return -EIO;
>   }
>  
>   return 0;
> @@ -1450,7 +1450,7 @@ static int dsi_pll_enable(struct dss_pll *pll)
>   /* XXX PLL does not come out of reset without this... */
>   dispc_pck_free_enable(1);
>  
> - if (wait_for_bit_change(dsidev, DSI_PLL_STATUS, 0, 1) != 1) {
> + if (!wait_for_bit_change(dsidev, DSI_PLL_STATUS, 0, 1)) {
>   DSSERR("PLL not coming out of reset.\n");
>   r = -ENODEV;
>   dispc_pck_free_enable(0);
> @@ -2200,7 +2200,7 @@ static int dsi_cio_init(struct platform_device *dsidev)
>* I/O. */
>   dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
>  
> - if (wait_for_bit_change(dsidev, DSI_DSIPHY_CFG5, 30, 1) != 1) {
> + if (!wait_for_bit_change(dsidev, DSI_DSIPHY_CFG5, 30, 1)) {
>   DSSERR("CIO SCP Clock domain not coming out of reset.\n");
>   r = -EIO;
>   goto err_scp_clk_dom;
> @@ -2248,7 +2248,7 @@ static int dsi_cio_init(struct platform_device *dsidev)
>   if (r)
>   goto err_cio_pwr;
>  
> - if (wait_for_bit_change(dsidev, DSI_COMPLEXIO_CFG1, 29, 1) != 1) {
> + if (!wait_for_bit_change(dsidev, DSI_COMPLEXIO_CFG1, 29, 1)) {
>   DSSERR("CIO PWR clock domain not coming out of reset.\n");
>   r = -ENODEV;
>   goto err_cio_pwr_dom;
> @@ -2389,7 +2389,7 @@ static int dsi_force_tx_stop_mode_io(struct 
> platform_device *dsidev)
>   r = FLD_MOD(r, 1, 15, 15);  /* FORCE_TX_STOP_MODE_IO */
>   dsi_write_reg(dsidev, DSI_TIMING1, r);
>  
> - if (wait_for_bit_change(dsidev, DSI_TIMING1, 15, 0) != 0) {
> + if (!wait_for_bit_change(dsidev, DSI_TIMING1, 15, 0)) {
>   DSSERR("TX_STOP bit not going down\n");
>   return -EIO;
>   }
> @@ -2531,10 +2531,9 @@ static int dsi_vc_enable(struct platform_device 
> *dsidev, int channel,
>  
>   REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), enable, 0, 0);
>  
> - if (wait_for_bit_change(dsidev, DSI_VC_CTRL(channel),
> - 0, enable) != enable) {
> - DSSERR("Failed to set dsi_vc_enable to %d\n", enable);
> - return -EIO;
> + if (!wait_for_bit_change(dsidev, DSI_VC_CTRL(channel), 0, enable)) {
> + DSSERR("Failed to 

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #3 from Dennis Schridde  ---
It just happened again:

Application: KWin (kwin_x11), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fc355251d00 (LWP 3241))]

Thread 13 (Thread 0x7fc31350c700 (LWP 30580)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0x144db48, cond=0x144db70) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0x13e9bf0) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/src/util/u_queue.c:158
#3  0x7fc32df9b717 in impl_thrd_routine (p=) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:87
#4  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#5  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 12 (Thread 0x7fc312d0b700 (LWP 3408)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc351dbe634 in ?? () from /usr/lib64/libQt5Script.so.5
#2  0x7fc351dbe679 in ?? () from /usr/lib64/libQt5Script.so.5
#3  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#4  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 11 (Thread 0x7fc313d0d700 (LWP 3380)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0xf50528, cond=0xf50550) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0xe39db0) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/src/util/u_queue.c:158
#3  0x7fc32df9b717 in impl_thrd_routine (p=) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:87
#4  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#5  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 10 (Thread 0x7fc31450e700 (LWP 3377)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0xdf6b80, cond=0xdf6ba8) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0xe45f40) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/src/util/u_queue.c:158
#3  0x7fc32df9b717 in impl_thrd_routine (p=) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:87
#4  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#5  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 9 (Thread 0x7fc314d0f700 (LWP 3376)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0xdf6b80, cond=0xdf6ba8) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0xe45f00) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/src/util/u_queue.c:158
#3  0x7fc32df9b717 in impl_thrd_routine (p=) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:87
#4  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#5  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 8 (Thread 0x7fc315510700 (LWP 3375)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0xdf6a98, cond=0xdf6ac0) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0xe52840) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/src/util/u_queue.c:158
#3  0x7fc32df9b717 in impl_thrd_routine (p=) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:87
#4  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#5  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7fc315d11700 (LWP 3374)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0xdf6a98, cond=0xdf6ac0) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0xe0a120) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/src/util/u_queue.c:158
#3  0x7fc32df9b717 in impl_thrd_routine (p=) at
/var/tmp/portage/media-libs/mesa-17.2.2/work/mesa-17.2.2/include/c11/threads_posix.h:87
#4  0x7fc34e822617 in start_thread () from /lib64/libpthread.so.0
#5  0x7fc354d5960f in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7fc316512700 (LWP 3373)):
#0  0x7fc34e829466 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7fc32df9b7f3 in cnd_wait (mtx=0xdf6a98, cond=0xdf6ac0) at

Re: [PATCH 34/48] drm: omapdrm: sdi: Allocate the sdi private data structure dynamically

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:30PM +0300, Laurent Pinchart wrote:
> The sdi private data structure is currently stored as a global
> variable. While no platform with multiple SDI encoders currently exists
> nor is planned, this doesn't comply with the kernel device model and
> should thus be fixed.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/sdi.c | 122 
> +-
>  1 file changed, 69 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c 
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index ac436826914a..a35dc51c5a6a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -31,7 +31,7 @@
>  #include "omapdss.h"
>  #include "dss.h"
>  
> -static struct {
> +struct sdi_device {
>   struct platform_device *pdev;
>   struct dss_device *dss;
>  
> @@ -43,9 +43,9 @@ static struct {
>   int datapairs;
>  
>   struct omap_dss_device output;
> +};
>  
> - bool port_initialized;
> -} sdi;
> +#define dssdev_to_sdi(dssdev) container_of(dssdev, struct sdi_device, output)
>  
>  struct sdi_clk_calc_ctx {
>   unsigned long pck_min, pck_max;
> @@ -77,9 +77,9 @@ static bool dpi_calc_dss_cb(unsigned long fck, void *data)
>   dpi_calc_dispc_cb, ctx);
>  }
>  
> -static int sdi_calc_clock_div(unsigned long pclk,
> - unsigned long *fck,
> - struct dispc_clock_info *dispc_cinfo)
> +static int sdi_calc_clock_div(struct sdi_device *sdi, unsigned long pclk,
> +   unsigned long *fck,
> +   struct dispc_clock_info *dispc_cinfo)
>  {
>   int i;
>   struct sdi_clk_calc_ctx ctx;
> @@ -101,7 +101,7 @@ static int sdi_calc_clock_div(unsigned long pclk,
>   ctx.pck_min = 0;
>   ctx.pck_max = pclk + 1000 * i * i * i;
>  
> - ok = dss_div_calc(sdi.dss, pclk, ctx.pck_min,
> + ok = dss_div_calc(sdi->dss, pclk, ctx.pck_min,
> dpi_calc_dss_cb, );
>   if (ok) {
>   *fck = ctx.fck;
> @@ -113,26 +113,27 @@ static int sdi_calc_clock_div(unsigned long pclk,
>   return -EINVAL;
>  }
>  
> -static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
> +static void sdi_config_lcd_manager(struct sdi_device *sdi)
>  {
> - enum omap_channel channel = dssdev->dispc_channel;
> + enum omap_channel channel = sdi->output.dispc_channel;
>  
> - sdi.mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
> + sdi->mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
>  
> - sdi.mgr_config.stallmode = false;
> - sdi.mgr_config.fifohandcheck = false;
> + sdi->mgr_config.stallmode = false;
> + sdi->mgr_config.fifohandcheck = false;
>  
> - sdi.mgr_config.video_port_width = 24;
> - sdi.mgr_config.lcden_sig_polarity = 1;
> + sdi->mgr_config.video_port_width = 24;
> + sdi->mgr_config.lcden_sig_polarity = 1;
>  
> - dss_mgr_set_lcd_config(channel, _config);
> + dss_mgr_set_lcd_config(channel, >mgr_config);
>  }
>  
>  static int sdi_display_enable(struct omap_dss_device *dssdev)
>  {
> - struct omap_dss_device *out = 
> + struct sdi_device *sdi = dssdev_to_sdi(dssdev);
> + struct omap_dss_device *out = >output;
>   enum omap_channel channel = dssdev->dispc_channel;
> - struct videomode *vm = 
> + struct videomode *vm = >vm;
>   unsigned long fck;
>   struct dispc_clock_info dispc_cinfo;
>   unsigned long pck;
> @@ -143,7 +144,7 @@ static int sdi_display_enable(struct omap_dss_device 
> *dssdev)
>   return -ENODEV;
>   }
>  
> - r = regulator_enable(sdi.vdds_sdi_reg);
> + r = regulator_enable(sdi->vdds_sdi_reg);
>   if (r)
>   goto err_reg_enable;
>  
> @@ -154,11 +155,11 @@ static int sdi_display_enable(struct omap_dss_device 
> *dssdev)
>   /* 15.5.9.1.2 */
>   vm->flags |= DISPLAY_FLAGS_PIXDATA_POSEDGE | DISPLAY_FLAGS_SYNC_POSEDGE;
>  
> - r = sdi_calc_clock_div(vm->pixelclock, , _cinfo);
> + r = sdi_calc_clock_div(sdi, vm->pixelclock, , _cinfo);
>   if (r)
>   goto err_calc_clock_div;
>  
> - sdi.mgr_config.clock_info = dispc_cinfo;
> + sdi->mgr_config.clock_info = dispc_cinfo;
>  
>   pck = fck / dispc_cinfo.lck_div / dispc_cinfo.pck_div;
>  
> @@ -172,11 +173,11 @@ static int sdi_display_enable(struct omap_dss_device 
> *dssdev)
>  
>   dss_mgr_set_timings(channel, vm);
>  
> - r = dss_set_fck_rate(sdi.dss, fck);
> + r = dss_set_fck_rate(sdi->dss, fck);
>   if (r)
>   goto err_set_dss_clock_div;
>  
> - sdi_config_lcd_manager(dssdev);
> + sdi_config_lcd_manager(sdi);
>  
>   /*
>* LCLK and PCLK divisors are located in shadow registers, and we
> @@ -189,10 +190,10 

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

[Nicolai Hähnle]

On 17.10.2017 19:16, Daniel Vetter wrote:

On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer  wrote:

On 17/10/17 05:04 PM, Daniel Vetter wrote:

On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:

On 17/10/17 02:22 PM, Daniel Vetter wrote:

On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:

On 17/10/17 11:34 AM, Nicolai Hähnle wrote:



Common sense suggests that there need to be two side to FreeSync / VESA
Adaptive Sync support:

1. Query the display capabilities. This means querying minimum / maximum
refresh duration, plus possibly a query for when the earliest/latest
timing of the *next* refresh.

2. Signal desired present time. This means passing a target timer value
instead of a target vblank count, e.g. something like this for the KMS
interface:

   int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id,
   uint32_t flags, void *user_data,
   uint64_t target);

   + a flag to indicate whether target is the vblank count or the
CLOCK_MONOTONIC (?) time in ns.


drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative
sync should probably only be supported via the atomic API, presumably
via output properties.


+1

At least now that DC is on track to land properly, and you want to do this
for DC-only anyway there's no reason to pimp the legacy interfaces
further. And atomic is soo much easier to extend.

The big question imo is where we need to put the flag on the kms side,
since freesync is not just about presenting earlier, but also about
presenting later. But for backwards compat we can't stretch the refresh
rate by default for everyone, or clients that rely on high precision
timestamps and regular refresh will get a bad surprise.


The idea described above is that adaptive sync would be used for flips
with a target timestamp. Apps which don't want to use adaptive sync
wouldn't set a target timestamp.



I think a boolean enable_freesync property is probably what we want, which
enables freesync for as long as it's set.


The question then becomes under what circumstances the property is (not)
set. Not sure offhand this will actually solve any problem, or just push
it somewhere else.


I thought that's what the driconf switch is for, with a policy of "please
schedule asap" instead of a specific timestamp.


The driconf switch is just for the user's intention to use adaptive sync
when possible. A property as you suggest cannot be set by the client
directly, because it can't know when adaptive sync can actually be used
(only when its window is fullscreen and using page flipping). So the
property would have to be set by the X server/driver / Wayland
compositor / ... instead. The question is whether such a property is
actually needed, or whether the kernel could just enable adaptive sync
when there's a flip with a target timestamp, and disable it when there's
a flip without a target timestamp, or something like that.


If your adaptive sync also supports extending the vblank beyond the
nominal limit, then you can't do that with a per-flip flag. Because
absent of a userspace requesting adaptive sync you must flip at the
nominal vrefresh rate. So if your userspace is a tad bit late with the
frame and would like to extend the frame to avoid missing a frame
entirely it'll be too late by the time the vblank actually gets
submitted. That's a bit a variation of what Ville brought up about
what we're going to do when the timestamp was missed by the time all
the depending fences signalled.


These are very good points. It does sound like we'd need both an 
"AdaptiveSync" boolean property and an (optional) "DesiredPresentTime" 
property.


The DesiredPresentTime property applies only to a single commit and 
could perhaps be left out in a first version. The AdaptiveSync property 
is persistent. When enabled, it means:


- handle page flip requests as soon as possible
- while no page flip is requested, delay vblank as long as possible

How does that sound?



Given all that I'm not sure whether requiring that userspace submits a
timestamp to get adaptive sync is a good idea (if we don't have an "as
soon as ready" flag at least), and the timestamp/flag at flip time
isn't enough either.


Finally I'm not sure we want to insist on a target time for freesync. At
least as far as I understand things you just want "as soon as possible".
This might change with some of the VK/EGL/GLX extensions where you
specify a precise timing (media playback). But that needs a bit more work
to make it happen I think, so perhaps better to postpone.


I don't see why. There's an obvious use case for this now, for video
playback. At least VDPAU already has target timestamps for this.



Also note that right now no driver expect amdgpu has support for a target
vblank on a flip. That's imo another reason for not requiring target
support for at least basic freesync support.


I think that's a bad reason. :) 

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

[Nicolai Hähnle]

On 17.10.2017 16:09, Ville Syrjälä wrote:

On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:

On 17/10/17 02:22 PM, Daniel Vetter wrote:

On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:

On 17/10/17 11:34 AM, Nicolai Hähnle wrote:



Common sense suggests that there need to be two side to FreeSync / VESA
Adaptive Sync support:

1. Query the display capabilities. This means querying minimum / maximum
refresh duration, plus possibly a query for when the earliest/latest
timing of the *next* refresh.

2. Signal desired present time. This means passing a target timer value
instead of a target vblank count, e.g. something like this for the KMS
interface:

   int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id,
   uint32_t flags, void *user_data,
   uint64_t target);

   + a flag to indicate whether target is the vblank count or the
CLOCK_MONOTONIC (?) time in ns.


drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative
sync should probably only be supported via the atomic API, presumably
via output properties.


+1

At least now that DC is on track to land properly, and you want to do this
for DC-only anyway there's no reason to pimp the legacy interfaces
further. And atomic is soo much easier to extend.

The big question imo is where we need to put the flag on the kms side,
since freesync is not just about presenting earlier, but also about
presenting later. But for backwards compat we can't stretch the refresh
rate by default for everyone, or clients that rely on high precision
timestamps and regular refresh will get a bad surprise.


The idea described above is that adaptive sync would be used for flips
with a target timestamp. Apps which don't want to use adaptive sync
wouldn't set a target timestamp.



I think a boolean enable_freesync property is probably what we want, which
enables freesync for as long as it's set.


The question then becomes under what circumstances the property is (not)
set. Not sure offhand this will actually solve any problem, or just push
it somewhere else.



Finally I'm not sure we want to insist on a target time for freesync. At
least as far as I understand things you just want "as soon as possible".
This might change with some of the VK/EGL/GLX extensions where you
specify a precise timing (media playback). But that needs a bit more work
to make it happen I think, so perhaps better to postpone.


I don't see why. There's an obvious use case for this now, for video
playback. At least VDPAU already has target timestamps for this.



Also note that right now no driver expect amdgpu has support for a target
vblank on a flip. That's imo another reason for not requiring target
support for at least basic freesync support.


I think that's a bad reason. :) Adding it for atomic drivers shouldn't
be that hard.


Apart from the actual implementation hurdles it does open up some new questions:


All good questions, thanks! Let me try to take a crack at them:



- Is it going to be per-plane or per-crtc?


My understanding is that planes are combined to form a single signal 
that goes out to the monitor(s). The planes are scanned out together by 
a crtc, so it should be per-crtc.




- What happens if the target timestamp is already stale?
- What happens if the target timestamp is good when it gets scheduled,
   but can't be met once the fences and whatnot have signalled?


Treat it as "flip as soon as possible" in both cases.



- What happens if another operation is already queued with a more
   recent timestamp?


This is a problem already today, isn't it? You could have two page flips 
being queued before the next vblank. What happens in that case?




- Apart from a pure timestamp do we want to move the OML_sync/swap_whatever
   msc remainder etc. semantics into the kernel as well? It's just
   another way to specify the target flip time after all.


A related question:

- What happens if the target timestamp is too late for the next vblank?

There's an argument to be made that late timestamps should just be 
treated as "delay the next vblank as late as possible". Such an option 
could be used by compositors for a power-saving mode.




I do like the idea, but clearly there's a bit of thought require to
make sure the semantics are good.


Agreed!

Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/48] drm: omapdrm: venc: Allocate the venc private data structure dynamically

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:29PM +0300, Laurent Pinchart wrote:
> The venc private data structure is currently stored as a global
> variable. While no platform with multiple VENC encoders currently exists
> nor is planned, this doesn't comply with the kernel device model and
> should thus be fixed.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/venc.c | 425 
> -
>  1 file changed, 228 insertions(+), 197 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c 
> b/drivers/gpu/drm/omapdrm/dss/venc.c
> index 179ef73a5564..7acdbfefe397 100644
> --- a/drivers/gpu/drm/omapdrm/dss/venc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/venc.c
> @@ -321,7 +321,7 @@ static enum venc_videomode venc_get_videomode(const 
> struct videomode *vm)
>   return VENC_MODE_UNKNOWN;
>  }
>  
> -static struct {
> +struct venc_device {
>   struct platform_device *pdev;
>   void __iomem *base;
>   struct mutex venc_lock;
> @@ -339,81 +339,87 @@ static struct {
>   bool requires_tv_dac_clk;
>  
>   struct omap_dss_device output;
> -} venc;
> +};
> +
> +#define dssdev_to_venc(dssdev) container_of(dssdev, struct venc_device, 
> output)
>  
> -static inline void venc_write_reg(int idx, u32 val)
> +static inline void venc_write_reg(struct venc_device *venc, int idx, u32 val)
>  {
> - __raw_writel(val, venc.base + idx);
> + __raw_writel(val, venc->base + idx);
>  }
>  
> -static inline u32 venc_read_reg(int idx)
> +static inline u32 venc_read_reg(struct venc_device *venc, int idx)
>  {
> - u32 l = __raw_readl(venc.base + idx);
> + u32 l = __raw_readl(venc->base + idx);
>   return l;
>  }
>  
> -static void venc_write_config(const struct venc_config *config)
> +static void venc_write_config(struct venc_device *venc,
> +   const struct venc_config *config)
>  {
>   DSSDBG("write venc conf\n");
>  
> - venc_write_reg(VENC_LLEN, config->llen);
> - venc_write_reg(VENC_FLENS, config->flens);
> - venc_write_reg(VENC_CC_CARR_WSS_CARR, config->cc_carr_wss_carr);
> - venc_write_reg(VENC_C_PHASE, config->c_phase);
> - venc_write_reg(VENC_GAIN_U, config->gain_u);
> - venc_write_reg(VENC_GAIN_V, config->gain_v);
> - venc_write_reg(VENC_GAIN_Y, config->gain_y);
> - venc_write_reg(VENC_BLACK_LEVEL, config->black_level);
> - venc_write_reg(VENC_BLANK_LEVEL, config->blank_level);
> - venc_write_reg(VENC_M_CONTROL, config->m_control);
> - venc_write_reg(VENC_BSTAMP_WSS_DATA, config->bstamp_wss_data |
> - venc.wss_data);
> - venc_write_reg(VENC_S_CARR, config->s_carr);
> - venc_write_reg(VENC_L21__WC_CTL, config->l21__wc_ctl);
> - venc_write_reg(VENC_SAVID__EAVID, config->savid__eavid);
> - venc_write_reg(VENC_FLEN__FAL, config->flen__fal);
> - venc_write_reg(VENC_LAL__PHASE_RESET, config->lal__phase_reset);
> - venc_write_reg(VENC_HS_INT_START_STOP_X, config->hs_int_start_stop_x);
> - venc_write_reg(VENC_HS_EXT_START_STOP_X, config->hs_ext_start_stop_x);
> - venc_write_reg(VENC_VS_INT_START_X, config->vs_int_start_x);
> - venc_write_reg(VENC_VS_INT_STOP_X__VS_INT_START_Y,
> + venc_write_reg(venc, VENC_LLEN, config->llen);
> + venc_write_reg(venc, VENC_FLENS, config->flens);
> + venc_write_reg(venc, VENC_CC_CARR_WSS_CARR, config->cc_carr_wss_carr);
> + venc_write_reg(venc, VENC_C_PHASE, config->c_phase);
> + venc_write_reg(venc, VENC_GAIN_U, config->gain_u);
> + venc_write_reg(venc, VENC_GAIN_V, config->gain_v);
> + venc_write_reg(venc, VENC_GAIN_Y, config->gain_y);
> + venc_write_reg(venc, VENC_BLACK_LEVEL, config->black_level);
> + venc_write_reg(venc, VENC_BLANK_LEVEL, config->blank_level);
> + venc_write_reg(venc, VENC_M_CONTROL, config->m_control);
> + venc_write_reg(venc, VENC_BSTAMP_WSS_DATA, config->bstamp_wss_data |
> +venc->wss_data);
> + venc_write_reg(venc, VENC_S_CARR, config->s_carr);
> + venc_write_reg(venc, VENC_L21__WC_CTL, config->l21__wc_ctl);
> + venc_write_reg(venc, VENC_SAVID__EAVID, config->savid__eavid);
> + venc_write_reg(venc, VENC_FLEN__FAL, config->flen__fal);
> + venc_write_reg(venc, VENC_LAL__PHASE_RESET, config->lal__phase_reset);
> + venc_write_reg(venc, VENC_HS_INT_START_STOP_X,
> +config->hs_int_start_stop_x);
> + venc_write_reg(venc, VENC_HS_EXT_START_STOP_X,
> +config->hs_ext_start_stop_x);
> + venc_write_reg(venc, VENC_VS_INT_START_X, config->vs_int_start_x);
> + venc_write_reg(venc, VENC_VS_INT_STOP_X__VS_INT_START_Y,
>  config->vs_int_stop_x__vs_int_start_y);
> - venc_write_reg(VENC_VS_INT_STOP_Y__VS_EXT_START_X,
> + venc_write_reg(venc, VENC_VS_INT_STOP_Y__VS_EXT_START_X,
>  

Re: [PATCH 32/48] drm: omapdrm: hdmi5: Allocate the omap_hdmi data structure dynamically

[Sebastian Reichel]

Hi,

On Fri, Oct 13, 2017 at 05:59:28PM +0300, Laurent Pinchart wrote:
> The omap_hdmi private data structure is currently stored as a global
> variable. While no platform with multiple HDMI5 encoders currently
> exists nor is planned, this doesn't comply with the kernel device model
> and should thus be fixed.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/hdmi5.c | 345 
> +++-
>  1 file changed, 184 insertions(+), 161 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> index c28fe184a7ad..ed8a2bd2a035 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -46,15 +46,13 @@
>  #include "hdmi5_core.h"
>  #include "dss.h"
>  
> -static struct omap_hdmi hdmi;
> -
> -static int hdmi_runtime_get(void)
> +static int hdmi_runtime_get(struct omap_hdmi *hdmi)
>  {
>   int r;
>  
>   DSSDBG("hdmi_runtime_get\n");
>  
> - r = pm_runtime_get_sync(>dev);
> + r = pm_runtime_get_sync(>pdev->dev);
>   WARN_ON(r < 0);
>   if (r < 0)
>   return r;
> @@ -62,19 +60,20 @@ static int hdmi_runtime_get(void)
>   return 0;
>  }
>  
> -static void hdmi_runtime_put(void)
> +static void hdmi_runtime_put(struct omap_hdmi *hdmi)
>  {
>   int r;
>  
>   DSSDBG("hdmi_runtime_put\n");
>  
> - r = pm_runtime_put_sync(>dev);
> + r = pm_runtime_put_sync(>pdev->dev);
>   WARN_ON(r < 0 && r != -ENOSYS);
>  }
>  
>  static irqreturn_t hdmi_irq_handler(int irq, void *data)
>  {
> - struct hdmi_wp_data *wp = data;
> + struct omap_hdmi *hdmi = data;
> + struct hdmi_wp_data *wp = >wp;
>   u32 irqstatus;
>  
>   irqstatus = hdmi_wp_get_irqstatus(wp);
> @@ -97,17 +96,17 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
>* setting the PHY to LDOON. To ignore those, we force the RXDET
>* line to 0 until the PHY power state has been changed.
>*/
> - v = hdmi_read_reg(hdmi.phy.base, HDMI_TXPHY_PAD_CFG_CTRL);
> + v = hdmi_read_reg(hdmi->phy.base, HDMI_TXPHY_PAD_CFG_CTRL);
>   v = FLD_MOD(v, 1, 15, 15); /* FORCE_RXDET_HIGH */
>   v = FLD_MOD(v, 0, 14, 7); /* RXDET_LINE */
> - hdmi_write_reg(hdmi.phy.base, HDMI_TXPHY_PAD_CFG_CTRL, v);
> + hdmi_write_reg(hdmi->phy.base, HDMI_TXPHY_PAD_CFG_CTRL, v);
>  
>   hdmi_wp_set_irqstatus(wp, HDMI_IRQ_LINK_CONNECT |
>   HDMI_IRQ_LINK_DISCONNECT);
>  
>   hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
>  
> - REG_FLD_MOD(hdmi.phy.base, HDMI_TXPHY_PAD_CFG_CTRL, 0, 15, 15);
> + REG_FLD_MOD(hdmi->phy.base, HDMI_TXPHY_PAD_CFG_CTRL, 0, 15, 15);
>  
>   } else if (irqstatus & HDMI_IRQ_LINK_CONNECT) {
>   hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_TXON);
> @@ -118,70 +117,70 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
>   return IRQ_HANDLED;
>  }
>  
> -static int hdmi_init_regulator(void)
> +static int hdmi_init_regulator(struct omap_hdmi *hdmi)
>  {
>   struct regulator *reg;
>  
> - if (hdmi.vdda_reg != NULL)
> + if (hdmi->vdda_reg != NULL)
>   return 0;
>  
> - reg = devm_regulator_get(>dev, "vdda");
> + reg = devm_regulator_get(>pdev->dev, "vdda");
>   if (IS_ERR(reg)) {
>   DSSERR("can't get VDDA regulator\n");
>   return PTR_ERR(reg);
>   }
>  
> - hdmi.vdda_reg = reg;
> + hdmi->vdda_reg = reg;
>  
>   return 0;
>  }
>  
> -static int hdmi_power_on_core(struct omap_dss_device *dssdev)
> +static int hdmi_power_on_core(struct omap_hdmi *hdmi)
>  {
>   int r;
>  
> - r = regulator_enable(hdmi.vdda_reg);
> + r = regulator_enable(hdmi->vdda_reg);
>   if (r)
>   return r;
>  
> - r = hdmi_runtime_get();
> + r = hdmi_runtime_get(hdmi);
>   if (r)
>   goto err_runtime_get;
>  
>   /* Make selection of HDMI in DSS */
> - dss_select_hdmi_venc_clk_source(hdmi.dss, DSS_HDMI_M_PCLK);
> + dss_select_hdmi_venc_clk_source(hdmi->dss, DSS_HDMI_M_PCLK);
>  
> - hdmi.core_enabled = true;
> + hdmi->core_enabled = true;
>  
>   return 0;
>  
>  err_runtime_get:
> - regulator_disable(hdmi.vdda_reg);
> + regulator_disable(hdmi->vdda_reg);
>  
>   return r;
>  }
>  
> -static void hdmi_power_off_core(struct omap_dss_device *dssdev)
> +static void hdmi_power_off_core(struct omap_hdmi *hdmi)
>  {
> - hdmi.core_enabled = false;
> + hdmi->core_enabled = false;
>  
> - hdmi_runtime_put();
> - regulator_disable(hdmi.vdda_reg);
> + hdmi_runtime_put(hdmi);
> + regulator_disable(hdmi->vdda_reg);
>  }
>  
> -static int hdmi_power_on_full(struct omap_dss_device *dssdev)
> +static 

[Bug 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]

[bugzilla-daemon]

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

Bug ID: 103316
   Summary: [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632
at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548
ttm_dma_free_pool.part.8+0x128/0x130 [ttm]
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net
QA Contact: dri-devel@lists.freedesktop.org

On kernel 4.13.6-300.fc27.x86_64, with 01:00.0 VGA compatible controller:
Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT GL [FirePro W9100] upon
modprobe -r radeon I get:

[83523.596239] [drm] radeon: finishing device.
[83523.615907] [TTM] Finalizing pool allocator
[83523.615910] [TTM] Finalizing DMA pool allocator
[83523.615942] [ cut here ]
[83523.615948] WARNING: CPU: 1 PID: 18632 at
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548
ttm_dma_free_pool.part.8+0x128/0x130 [ttm]
[83523.615949] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security
ebtable_filter ebtables ip6table_filter ip6_tables sunrpc intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
snd_hda_codec_realtek snd_hda_codec_generic irqbypass snd_hda_codec_hdmi
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel snd_seq_device intel_cstate intel_uncore
eeepc_wmi intel_rapl_perf asus_wmi snd_pcm sparse_keymap rfkill iTCO_wdt
mxm_wmi iTCO_vendor_support
[83523.615968]  snd_timer wmi_bmof snd mei_me mei soundcore shpchp i2c_i801
lpc_ich tpm_infineon tpm_tis tpm_tis_core tpm wmi xfs libcrc32c amdgpu amdkfd
i915 amd_iommu_v2 radeon(-) i2c_algo_bit drm_kms_helper ttm crc32c_intel drm
r8169 mii video
[83523.615978] CPU: 1 PID: 18632 Comm: modprobe Not tainted
4.13.6-300.fc27.x86_64 #1
[83523.615978] Hardware name: ASUS All Series/Z87-A, BIOS 1602 10/29/2013
[83523.615979] task: 948aebd84c80 task.stack: a04ea4cf8000
[83523.615982] RIP: 0010:ttm_dma_free_pool.part.8+0x128/0x130 [ttm]
[83523.615982] RSP: 0018:a04ea4cfbc40 EFLAGS: 00010202
[83523.615983] RAX: 0202 RBX: 948ed5b6d540 RCX:

[83523.615984] RDX: 00010042 RSI: dab5d0562e40 RDI:
a04ea4cfbbf0
[83523.615984] RBP: a04ea4cfbc58 R08: 948ed58b9080 R09:
00010041
[83523.615985] R10: a04ea4cfbb40 R11:  R12:
948edce2e2e0
[83523.615985] R13: 0008 R14: c043e1e8 R15:
948edd148100
[83523.615986] FS:  7efc655aa740() GS:948eefa4()
knlGS:
[83523.615987] CS:  0010 DS:  ES:  CR0: 80050033
[83523.615987] CR2: 55e3e6293030 CR3: 0003f194c000 CR4:
001406e0
[83523.615988] Call Trace:
[83523.615992]  ttm_dma_page_alloc_fini+0x84/0xf0 [ttm]
[83523.615994]  ttm_mem_global_release+0x19/0x90 [ttm]
[83523.616017]  radeon_ttm_mem_global_release+0x12/0x20 [radeon]
[83523.616026]  drm_global_item_unref+0x4c/0x70 [drm]
[83523.616035]  radeon_ttm_fini+0x133/0x1a0 [radeon]
[83523.616044]  radeon_bo_fini+0x12/0x40 [radeon]
[83523.616057]  cik_fini+0xca/0xf0 [radeon]
[83523.616065]  radeon_device_fini+0x35/0x110 [radeon]
[83523.616072]  radeon_driver_unload_kms+0x4b/0x80 [radeon]
[83523.616077]  drm_dev_unregister+0x3c/0xe0 [drm]
[83523.616083]  drm_put_dev+0x32/0x60 [drm]
[83523.616089]  radeon_pci_remove+0x15/0x20 [radeon]
[83523.616092]  pci_device_remove+0x39/0xb0
[83523.616094]  device_release_driver_internal+0x158/0x210
[83523.616095]  driver_detach+0x38/0x70
[83523.616096]  bus_remove_driver+0x59/0xd0
[83523.616097]  driver_unregister+0x2c/0x40
[83523.616098]  pci_unregister_driver+0x22/0xb0
[83523.616103]  drm_pci_exit+0xbb/0xc0 [drm]
[83523.616115]  radeon_exit+0x1c/0x43 [radeon]
[83523.616116]  SyS_delete_module+0x1a8/0x2b0
[83523.616118]  ? exit_to_usermode_loop+0x91/0xb0
[83523.616120]  entry_SYSCALL_64_fastpath+0x1a/0xa5
[83523.616121] RIP: 0033:0x7efc64a93917
[83523.616122] RSP: 002b:7ffdd5e175f8 EFLAGS: 0206 ORIG_RAX:
00b0
[83523.616123] RAX: ffda RBX: 0003 RCX:
7efc64a93917
[83523.616123] RDX:  RSI: 0800 RDI:
564a18d45ea8
[83523.616123] RBP:  R08: 7ffdd5e165a1 R09:

[83523.616124] R10: 7efc64b0cbc0 R11: 0206 R12:
564a18d45e40
[83523.616124] R13: 7ffdd5e16610 R14: 564a18d45ea8 R15:
7ffdd5e189e0
[83523.616125] Code: 00 ad de 48 89 df 48 89 03 

Re: [RFC PATCH v4 8/8] drm/rockchip: Add device links for master and components

[Sean Paul]

On Tue, Oct 17, 2017 at 06:16:24PM +0800, Jeffy Chen wrote:
> Since we are trying to access components' resources in the master's
> suspend/resume PM callbacks(e.g. panel), add device links to correct
> the suspend/resume and shutdown ordering.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> Use device link to correct the suspend/resume and shutdown ordering,
> instead of converting rockchip spi's suspend/resume PM callbacks to
> late suspend/resume PM callbacks.
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 76d63de5921d..af18967f699b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -337,6 +337,8 @@ static struct component_match 
> *rockchip_drm_match_add(struct device *dev)
>  
>   if (!d)
>   break;
> +
> + device_link_add(dev, d, DL_FLAG_STATELESS);
>   component_match_add(dev, , compare_dev, d);
>   } while (true);
>   }
> @@ -406,6 +408,7 @@ static int rockchip_drm_platform_of_probe(struct device 
> *dev)
>  static int rockchip_drm_platform_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> + struct device_link *link;
>   struct component_match *match = NULL;
>   int ret;
>  
> @@ -414,16 +417,31 @@ static int rockchip_drm_platform_probe(struct 
> platform_device *pdev)
>   return ret;
>  
>   match = rockchip_drm_match_add(dev);
> - if (IS_ERR(match))
> - return PTR_ERR(match);
> + if (IS_ERR(match)) {
> + ret = PTR_ERR(match);
> + goto err_cleanup_dev_links;

This cleanup should take place in rockchip_drm_match_add(). The review theme for
this entire series is that, when possible, we should cleanup things where they
are initialized.

Since you'll also need to clean up the links elsewhere, consider adding a helper
function to do the cleanup (rockchip_drm_match_remove or similar) and calling it
where needed.

Sean

> + }
>  
> - return component_master_add_with_match(dev, _drm_ops, match);
> + ret = component_master_add_with_match(dev, _drm_ops, match);
> + if (ret < 0)
> + goto err_cleanup_dev_links;
> +
> + return 0;
> +err_cleanup_dev_links:
> + list_for_each_entry(link, >links.consumers, s_node)
> + device_link_del(link);
> + return ret;
>  }
>  
>  static int rockchip_drm_platform_remove(struct platform_device *pdev)
>  {
> + struct device_link *link;
> +
>   component_master_del(>dev, _drm_ops);
>  
> + list_for_each_entry(link, >dev.links.consumers, s_node)
> + device_link_del(link);
> +
>   return 0;
>  }
>  
> -- 
> 2.11.0
> 
> 

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

Re: [PATCH] drm/nouveau/fbcon: fix oops without fbdev emulation

[Ben Skeggs]

On 10/18/2017 04:06 AM, Pavel Roskin wrote:
> Ben, David,
> 
> I would hate if Linux 4.14 is released without this fix, as it would
> be a regression for my machine. As I mentioned, Linux 4.13 registers
> nouveaufb even without the dock, but Linux 4.14 doesn't. And that
> would cause an oops even if CONFIG_DRM_FBDEV_EMULATION is enabled.
> 
> Please let me know if any assistance is needed on my part to get the
> patch merged.
None necessary, I will pick it up.

Thank you!
Ben.

> 
> Pavel
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v4 6/8] drm/bridge/analogix: Do not use device's drvdata

[Sean Paul]

On Tue, Oct 17, 2017 at 06:16:22PM +0800, Jeffy Chen wrote:
> From: Tomasz Figa 
> 
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
> owned by its driver struct. Moreover, storing two different pointer
> types in driver data depending on driver initialization status is barely
> a good practice and in fact has led to many bugs in this driver.
> 
> Let's clean up this mess and change Analogix entry points to simply
> accept some opaque struct pointer, adjusting their users at the same
> time to avoid breaking the compilation.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Sean Paul 

> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 
> +-
>  drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 47 +++-
>  include/drm/bridge/analogix_dp.h   | 19 
>  4 files changed, 73 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 5dd3f1cd074a..74d274b6d31d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -98,17 +98,15 @@ static int analogix_dp_detect_hpd(struct 
> analogix_dp_device *dp)
>   return 0;
>  }
>  
> -int analogix_dp_psr_supported(struct device *dev)
> +int analogix_dp_psr_supported(struct analogix_dp_device *dp)
>  {
> - struct analogix_dp_device *dp = dev_get_drvdata(dev);
>  
>   return dp->psr_support;
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
>  
> -int analogix_dp_enable_psr(struct device *dev)
> +int analogix_dp_enable_psr(struct analogix_dp_device *dp)
>  {
> - struct analogix_dp_device *dp = dev_get_drvdata(dev);
>   struct edp_vsc_psr psr_vsc;
>  
>   if (!dp->psr_support)
> @@ -129,9 +127,8 @@ int analogix_dp_enable_psr(struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
>  
> -int analogix_dp_disable_psr(struct device *dev)
> +int analogix_dp_disable_psr(struct analogix_dp_device *dp)
>  {
> - struct analogix_dp_device *dp = dev_get_drvdata(dev);
>   struct edp_vsc_psr psr_vsc;
>   int ret;
>  
> @@ -1281,8 +1278,9 @@ static ssize_t analogix_dpaux_transfer(struct 
> drm_dp_aux *aux,
>   return analogix_dp_transfer(dp, msg);
>  }
>  
> -int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
> -  struct analogix_dp_plat_data *plat_data)
> +struct analogix_dp_device *
> +analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
> +  struct analogix_dp_plat_data *plat_data)
>  {
>   struct platform_device *pdev = to_platform_device(dev);
>   struct analogix_dp_device *dp;
> @@ -1292,14 +1290,12 @@ int analogix_dp_bind(struct device *dev, struct 
> drm_device *drm_dev,
>  
>   if (!plat_data) {
>   dev_err(dev, "Invalided input plat_data\n");
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
>   }
>  
>   dp = devm_kzalloc(dev, sizeof(struct analogix_dp_device), GFP_KERNEL);
>   if (!dp)
> - return -ENOMEM;
> -
> - dev_set_drvdata(dev, dp);
> + return ERR_PTR(-ENOMEM);
>  
>   dp->dev = >dev;
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
> @@ -1316,7 +1312,7 @@ int analogix_dp_bind(struct device *dev, struct 
> drm_device *drm_dev,
>  
>   ret = analogix_dp_dt_parse_pdata(dp);
>   if (ret)
> - return ret;
> + return ERR_PTR(ret);
>  
>   dp->phy = devm_phy_get(dp->dev, "dp");
>   if (IS_ERR(dp->phy)) {
> @@ -1330,14 +1326,14 @@ int analogix_dp_bind(struct device *dev, struct 
> drm_device *drm_dev,
>   if (ret == -ENOSYS || ret == -ENODEV)
>   dp->phy = NULL;
>   else
> - return ret;
> + return ERR_PTR(ret);
>   }
>   }
>  
>   dp->clock = devm_clk_get(>dev, "dp");
>   if (IS_ERR(dp->clock)) {
>   dev_err(>dev, "failed to get clock\n");
> - return PTR_ERR(dp->clock);
> + return ERR_CAST(dp->clock);
>   }
>  
>   clk_prepare_enable(dp->clock);
> @@ -1346,7 +1342,7 @@ int analogix_dp_bind(struct device *dev, struct 
> drm_device *drm_dev,
>  
>   dp->reg_base = devm_ioremap_resource(>dev, res);
>   if (IS_ERR(dp->reg_base))
> - return PTR_ERR(dp->reg_base);
> + return ERR_CAST(dp->reg_base);
>  
>   dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
>  

Re: [RFC PATCH v4 5/8] drm/rockchip: inno_hdmi: Fix error handling path

[Sean Paul]

On Tue, Oct 17, 2017 at 06:16:21PM +0800, Jeffy Chen wrote:
> Add missing error handling in bind().
> 
> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/inno_hdmi.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index ee584d87111f..9c258b05dfa5 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -851,8 +851,10 @@ static int inno_hdmi_bind(struct device *dev, struct 
> device *master,
>   }
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> - return irq;
> + if (irq < 0) {
> + ret = irq;
> + goto err_disable_clk;
> + }
>  
>   inno_hdmi_reset(hdmi);
>  
> @@ -860,7 +862,7 @@ static int inno_hdmi_bind(struct device *dev, struct 
> device *master,
>   if (IS_ERR(hdmi->ddc)) {
>   ret = PTR_ERR(hdmi->ddc);
>   hdmi->ddc = NULL;
> - return ret;
> + goto err_disable_clk;
>   }
>  
>   /*
> @@ -874,7 +876,7 @@ static int inno_hdmi_bind(struct device *dev, struct 
> device *master,
>  
>   ret = inno_hdmi_register(drm, hdmi);
>   if (ret)
> - return ret;
> + goto err_put_adapter;
>  
>   dev_set_drvdata(dev, hdmi);
>  
> @@ -884,7 +886,17 @@ static int inno_hdmi_bind(struct device *dev, struct 
> device *master,
>   ret = devm_request_threaded_irq(dev, irq, inno_hdmi_hardirq,
>   inno_hdmi_irq, IRQF_SHARED,
>   dev_name(dev), hdmi);
> + if (ret < 0)
> + goto err_cleanup_hdmi;
>  
> + return 0;
> +err_cleanup_hdmi:
> + drm_connector_cleanup(>connector);
> + drm_encoder_cleanup(>encoder);

Same question regarding cleanup vs destroy.

> +err_put_adapter:
> + i2c_put_adapter(hdmi->ddc);
> +err_disable_clk:
> + clk_disable_unprepare(hdmi->pclk);

I also noticed the order of these two functions is reversed in unbind(). Can you
please update the order to match?

Sean

>   return ret;
>  }
>  
> -- 
> 2.11.0
> 
> 

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

Re: [RFC PATCH v4 4/8] drm/rockchip: dw_hdmi: Fix error handling path

[Sean Paul]

On Tue, Oct 17, 2017 at 06:16:20PM +0800, Jeffy Chen wrote:
> Add missing clk_disable_unprepare() in bind()'s error handling path.

This also isn't disabled in unbind(), is that intentional?

> 
> Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 1eb02a82fd91..582283da7861 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -383,8 +383,10 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
> struct device *master,
>* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
>* which would have called the encoder cleanup.  Do it manually.
>*/
> - if (ret)
> + if (ret) {
>   drm_encoder_cleanup(encoder);
> + clk_disable_unprepare(hdmi->vpll_clk);

Same comment with respect to rockchip_hdmi_parse_dt(). This bug would have
probably been avoided if the contents of rockchip_hdmi_parse_dt() were inline
with dw_hdmi_rockchip_bind(), since then it's obvious what needs to be cleaned
up.

Sean

> + }
>  
>   return ret;
>  }
> -- 
> 2.11.0
> 
> 

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

Re: [linux-sunxi] [PATCH 08/10] ARM: dts: sun4i: Enable HDMI support on some A10 devices

[Maxime Ripard]

On Tue, Oct 17, 2017 at 10:38:45PM +0800, Chen-Yu Tsai wrote:
> > diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts 
> > b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> > index 2d1b4329f54a..e39ec9beef75 100644
> > --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> > +++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> > @@ -58,6 +58,17 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > +   hdmi-connector {
> > +   compatible = "hdmi-connector";
> > +   type = "a";
> > +
> > +   port {
> > +   hdmi_con_in: endpoint {
> > +   remote-endpoint = <_out_con>;
> > +   };
> > +   };
> > +   };
> > +
> > leds {
> > compatible = "gpio-leds";
> > pinctrl-names = "default";
> > @@ -106,6 +117,16 @@
> > status = "okay";
> >  };
> 
> The LIME's dts change is missing the  part. :(
> I can fix this when applying.

I've applied all of rest, I'll leave that one up to you, with my
Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [RFC PATCH v4 3/8] drm/rockchip: dw-mipi-dsi: Fix error handling path

[Sean Paul]

On Tue, Oct 17, 2017 at 06:16:19PM +0800, Jeffy Chen wrote:
> Add missing pm_runtime_disable() in bind()'s error handling path.
> 
> Also cleanup encoder & connector in unbind().
> 
> Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index b15755b6129c..a17ff0f6f489 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
> device *master,
>   ret = dw_mipi_dsi_register(drm, dsi);
>   if (ret) {
>   DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
> - goto err_pllref;
> + goto err_disable_pllref;
>   }
>  
>   pm_runtime_enable(dev);
> @@ -1292,23 +1292,24 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> struct device *master,
>   ret = mipi_dsi_host_register(>dsi_host);
>   if (ret) {
>   DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
> - goto err_cleanup;
> + goto err_disable_pm_runtime;
>   }
>  
>   if (!dsi->panel) {
>   ret = -EPROBE_DEFER;
> - goto err_mipi_dsi_host;
> + goto err_unreg_mipi_dsi_host;
>   }
>  
>   dev_set_drvdata(dev, dsi);
>   return 0;
>  
> -err_mipi_dsi_host:
> +err_unreg_mipi_dsi_host:
>   mipi_dsi_host_unregister(>dsi_host);
> -err_cleanup:
> +err_disable_pm_runtime:
> + pm_runtime_disable(dev);
>   drm_encoder_cleanup(>encoder);
>   drm_connector_cleanup(>connector);

Should you update these to call the destroy hook like in unbind()?

Sean

> -err_pllref:
> +err_disable_pllref:
>   clk_disable_unprepare(dsi->pllref_clk);
>   return ret;
>  }
> @@ -1320,6 +1321,10 @@ static void dw_mipi_dsi_unbind(struct device *dev, 
> struct device *master,
>  
>   mipi_dsi_host_unregister(>dsi_host);
>   pm_runtime_disable(dev);
> +
> + dsi->connector.funcs->destroy(>connector);
> + dsi->encoder.funcs->destroy(>encoder);
> +
>   clk_disable_unprepare(dsi->pllref_clk);
>  }
>  
> -- 
> 2.11.0
> 
> 

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

Re: [RFC PATCH v4 2/8] drm/rockchip: analogix_dp: Fix error handling path

[Sean Paul]

On Tue, Oct 17, 2017 at 06:16:18PM +0800, Jeffy Chen wrote:
> Add missing error handling in rockchip_dp_bind().
> 
> Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip platform dp driver")
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 4d3f6ad0abdd..4b689c0f3fc1 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -371,7 +371,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
> device *master,
>   ret = rockchip_dp_drm_create_encoder(dp);
>   if (ret) {
>   DRM_ERROR("failed to create drm encoder\n");
> - return ret;
> + goto err_disable_pclk;
>   }
>  
>   dp->plat_data.encoder = >encoder;
> @@ -387,7 +387,17 @@ static int rockchip_dp_bind(struct device *dev, struct 
> device *master,
>  
>   rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
>  
> - return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
> + ret = analogix_dp_bind(dev, dp->drm_dev, >plat_data);
> + if (ret < 0)
> + goto err_unreg_psr;
> + return 0;
> +
> +err_unreg_psr:
> + rockchip_drm_psr_unregister(>encoder);
> + rockchip_dp_drm_encoder_destroy(>encoder);
> +err_disable_pclk:
> + clk_disable_unprepare(dp->pclk);

Hi Jeffy,
This part of the cleanup is handling things setup by rockchip_dp_init().
However if someone adds something to rockchip_dp_init(), it's not obvious that
it should be cleaned up here and in unbind(). I'd suggest rebasing this on
a new patch which folds everything rockchip_dp_init() does into
rockchip_dp_bind(), then it will be obvious what needs to be cleaned up.

Sean


> + return ret;
>  }
>  
>  static void rockchip_dp_unbind(struct device *dev, struct device *master,
> -- 
> 2.11.0
> 
> 

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

Re: [PATCH] drm/atomic-helper: check that drivers call drm_crtc_vblank_off

[Sean Paul]

On Tue, Oct 17, 2017 at 01:47:36PM -0400, Sean Paul wrote:
> On Tue, Oct 17, 2017 at 04:59:39PM +0200, Daniel Vetter wrote:
> > At least when they have vblank support they need to call this, or the
> > vblank core will happily call into their crtc->enable_vblank callback
> > even when the crtc is off. Which leads to a boom when the clocks are
> > off on most hardware (besides the inevitable confusion in the
> > book-keeping).
> > 
> > The consistency checks in drm_vblank.c will then make sure that
> > vblank_off/on calls are balanced, and if drivers forget to re-enable
> > it all the commits will stall, so I think we're covered.
> > 
> > It'd be nice to be able to place this check outside of commit helpers,
> > but tha's not really possible (due to nonblocking commits and all
> > that). Placing it into atomic helpers should at least cover most
> > drivers.
> > 
> > Also note that vblank support is still optional (for virtual drivers,
> > which tend to not have this), check for that.
> > 
> > Cc: Rob Clark 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index ae56d91433ff..cc9c0173e075 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -860,6 +860,7 @@ disable_outputs(struct drm_device *dev, struct 
> > drm_atomic_state *old_state)
> >  
> > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
> > new_crtc_state, i) {
> > const struct drm_crtc_helper_funcs *funcs;
> > +   int ret;
> >  
> > /* Shut down everything that needs a full modeset. */
> > if (!drm_atomic_crtc_needs_modeset(new_crtc_state))
> > @@ -883,6 +884,14 @@ disable_outputs(struct drm_device *dev, struct 
> > drm_atomic_state *old_state)
> > funcs->disable(crtc);
> > else
> > funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > +
> > +   if (!(dev->irq_enabled && dev->num_crtcs))
> > +   continue;
> > +
> > +   ret = drm_crtc_vblank_get(crtc);
> > +   WARN_ONCE(ret != -EINVAL, "driver forgot to call 
> > drm_crtc_vblank_off()\n");
> > +   if (ret)
> 
> Shouldn't this be !ret

Annnd I should check my email before sending. Sorry, v2 is 

Reviewed-by: Sean Paul 

> 
> Sean
> 
> > +   drm_crtc_vblank_put(crtc);
> > }
> >  }
> >  
> > -- 
> > 2.14.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH] drm/atomic-helper: check that drivers call drm_crtc_vblank_off

[Sean Paul]

On Tue, Oct 17, 2017 at 04:59:39PM +0200, Daniel Vetter wrote:
> At least when they have vblank support they need to call this, or the
> vblank core will happily call into their crtc->enable_vblank callback
> even when the crtc is off. Which leads to a boom when the clocks are
> off on most hardware (besides the inevitable confusion in the
> book-keeping).
> 
> The consistency checks in drm_vblank.c will then make sure that
> vblank_off/on calls are balanced, and if drivers forget to re-enable
> it all the commits will stall, so I think we're covered.
> 
> It'd be nice to be able to place this check outside of commit helpers,
> but tha's not really possible (due to nonblocking commits and all
> that). Placing it into atomic helpers should at least cover most
> drivers.
> 
> Also note that vblank support is still optional (for virtual drivers,
> which tend to not have this), check for that.
> 
> Cc: Rob Clark 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ae56d91433ff..cc9c0173e075 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -860,6 +860,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>  
>   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
> new_crtc_state, i) {
>   const struct drm_crtc_helper_funcs *funcs;
> + int ret;
>  
>   /* Shut down everything that needs a full modeset. */
>   if (!drm_atomic_crtc_needs_modeset(new_crtc_state))
> @@ -883,6 +884,14 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   funcs->disable(crtc);
>   else
>   funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> +
> + if (!(dev->irq_enabled && dev->num_crtcs))
> + continue;
> +
> + ret = drm_crtc_vblank_get(crtc);
> + WARN_ONCE(ret != -EINVAL, "driver forgot to call 
> drm_crtc_vblank_off()\n");
> + if (ret)

Shouldn't this be !ret

Sean

> + drm_crtc_vblank_put(crtc);
>   }
>  }
>  
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=60857

mirh (m...@protonmail.ch) changed:

   What|Removed |Added

 CC||m...@protonmail.ch

--- Comment #18 from mirh (m...@protonmail.ch) ---
Github says e40210cca98068835acd5a4fe760bf96b3a1aa48 landed in 3.12-rc2. 
Is this fixed now?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc] drm_hwcomposer: make sure primary plane is allocated for squash

[Robert Foss]

Hey Adrian,

This looks good to me. Pushed!

Sorry about the late reply, I was under the weather for a bit.
Would you be interested in commit rights to this project?


Rob.

On Mon, 2017-10-02 at 11:31 -0700, Adrian Salido wrote:
> There are instances where the primary plane may have been disabled,
> look
> through disabled planes as well to find primary plane to use for
> squash.
> 
> Signed-off-by: Adrian Salido 
> ---
>  drmdisplaycompositor.cpp | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index a07d3588d1f5..80e3eba60ccf 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -933,10 +933,13 @@ int
> DrmDisplayCompositor::SquashFrame(DrmDisplayComposition *src,
>    goto move_layers_back;
>  }
>  
> -if (comp_plane.type() == DrmCompositionPlane::Type::kDisable) {
> +if (comp_plane.plane()->type() == DRM_PLANE_TYPE_PRIMARY)
> +  squashed_comp.set_plane(comp_plane.plane());
> +else
>    dst->AddPlaneDisable(comp_plane.plane());
> +
> +if (comp_plane.type() == DrmCompositionPlane::Type::kDisable)
>    continue;
> -}
>  
>  for (auto i : comp_plane.source_layers()) {
>    DrmHwcLayer  = src_layers[i];
> @@ -955,11 +958,12 @@ int
> DrmDisplayCompositor::SquashFrame(DrmDisplayComposition *src,
>    squashed_comp.source_layers().push_back(
>    squashed_comp.source_layers().size());
>  }
> +  }
>  
> -if (comp_plane.plane()->type() == DRM_PLANE_TYPE_PRIMARY)
> -  squashed_comp.set_plane(comp_plane.plane());
> -else
> -  dst->AddPlaneDisable(comp_plane.plane());
> +  if (squashed_comp.plane() == NULL) {
> +ALOGE("Primary plane not found for squash");
> +ret = -ENOTSUP;
> +goto move_layers_back;
>    }
>  
>    ret = dst->SetLayers(dst_layers.data(), dst_layers.size(), false);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37696] [RADEON:KMS:PLL] frequent colored lines appear on screen

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from mirh  ---
Fixed in 411678288d61ba17afe1f8afed92200be6bbc65d then I guess.

-- 
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: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

[Daniel Vetter]

On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer  wrote:
> On 17/10/17 05:04 PM, Daniel Vetter wrote:
>> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>>> On 17/10/17 02:22 PM, Daniel Vetter wrote:
 On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:

>> Common sense suggests that there need to be two side to FreeSync / VESA
>> Adaptive Sync support:
>>
>> 1. Query the display capabilities. This means querying minimum / maximum
>> refresh duration, plus possibly a query for when the earliest/latest
>> timing of the *next* refresh.
>>
>> 2. Signal desired present time. This means passing a target timer value
>> instead of a target vblank count, e.g. something like this for the KMS
>> interface:
>>
>>   int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id,
>>   uint32_t flags, void *user_data,
>>   uint64_t target);
>>
>>   + a flag to indicate whether target is the vblank count or the
>> CLOCK_MONOTONIC (?) time in ns.
>
> drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative
> sync should probably only be supported via the atomic API, presumably
> via output properties.

 +1

 At least now that DC is on track to land properly, and you want to do this
 for DC-only anyway there's no reason to pimp the legacy interfaces
 further. And atomic is soo much easier to extend.

 The big question imo is where we need to put the flag on the kms side,
 since freesync is not just about presenting earlier, but also about
 presenting later. But for backwards compat we can't stretch the refresh
 rate by default for everyone, or clients that rely on high precision
 timestamps and regular refresh will get a bad surprise.
>>>
>>> The idea described above is that adaptive sync would be used for flips
>>> with a target timestamp. Apps which don't want to use adaptive sync
>>> wouldn't set a target timestamp.
>>>
>>>
 I think a boolean enable_freesync property is probably what we want, which
 enables freesync for as long as it's set.
>>>
>>> The question then becomes under what circumstances the property is (not)
>>> set. Not sure offhand this will actually solve any problem, or just push
>>> it somewhere else.
>>
>> I thought that's what the driconf switch is for, with a policy of "please
>> schedule asap" instead of a specific timestamp.
>
> The driconf switch is just for the user's intention to use adaptive sync
> when possible. A property as you suggest cannot be set by the client
> directly, because it can't know when adaptive sync can actually be used
> (only when its window is fullscreen and using page flipping). So the
> property would have to be set by the X server/driver / Wayland
> compositor / ... instead. The question is whether such a property is
> actually needed, or whether the kernel could just enable adaptive sync
> when there's a flip with a target timestamp, and disable it when there's
> a flip without a target timestamp, or something like that.

If your adaptive sync also supports extending the vblank beyond the
nominal limit, then you can't do that with a per-flip flag. Because
absent of a userspace requesting adaptive sync you must flip at the
nominal vrefresh rate. So if your userspace is a tad bit late with the
frame and would like to extend the frame to avoid missing a frame
entirely it'll be too late by the time the vblank actually gets
submitted. That's a bit a variation of what Ville brought up about
what we're going to do when the timestamp was missed by the time all
the depending fences signalled.

Given all that I'm not sure whether requiring that userspace submits a
timestamp to get adaptive sync is a good idea (if we don't have an "as
soon as ready" flag at least), and the timestamp/flag at flip time
isn't enough either.

 Finally I'm not sure we want to insist on a target time for freesync. At
 least as far as I understand things you just want "as soon as possible".
 This might change with some of the VK/EGL/GLX extensions where you
 specify a precise timing (media playback). But that needs a bit more work
 to make it happen I think, so perhaps better to postpone.
>>>
>>> I don't see why. There's an obvious use case for this now, for video
>>> playback. At least VDPAU already has target timestamps for this.
>>>
>>>
 Also note that right now no driver expect amdgpu has support for a target
 vblank on a flip. That's imo another reason for not requiring target
 support for at least basic freesync support.
>>>
>>> I think that's a bad reason. :) Adding it for atomic drivers shouldn't
>>> be that hard.
>>
>> I thought the primary reason for adaptive sync is the adaptive frame rate
>> to cope with the occasional stall in games. If the 

Re: [PATCH] drm: some KMS todo ideas

[Sean Paul]

On Tue, Oct 17, 2017 at 06:29:18PM +0200, Daniel Vetter wrote:
> Inspired by discussions with Keith and Ville.
> 
> Cc: Ville Syrjälä 
> Cc: Keith Packard 
> Signed-off-by: Daniel Vetter 

Acked-by: Sean Paul 

> ---
>  Documentation/gpu/todo.rst | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 92ee2f982572..96f8ec7dbe4e 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -304,6 +304,18 @@ There's a bunch of issues with it:
>  
>  Contact: Daniel Vetter
>  
> +KMS cleanups
> +
> +
> +Some of these date from the very introduction of KMS in 2008 ...
> +
> +- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. 
> Should
> +  be renamed to drm_mode_config.object_idr.
> +
> +- drm_display_mode doesn't need to be derived from drm_mode_object. That's
> +  leftovers from older (never merged into upstream) KMS designs where modes
> +  where set using their ID, including support to add/remove modes.
> +
>  Better Testing
>  ==
>  
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 3/9] drm/panel: simple: make it possible to override LCD bus format

[Rob Herring]

On Tue, Oct 17, 2017 at 7:56 AM, Thierry Reding
 wrote:
> On Tue, Oct 17, 2017 at 02:44:23PM +0200, Lothar Waßmann wrote:
>> Hi,
>>
>> On Tue, 17 Oct 2017 14:12:40 +0200 Thierry Reding wrote:
>> > On Wed, Oct 11, 2017 at 01:23:35PM +0200, Lothar Waßmann wrote:
>> > > The baseboards for the Ka-Ro electronics series of i.MX modules
>> > > use a 24bit LCD interface, no matter what LCD bus width the SoC on the
>> > > module provides and what the LCD panel expects. LCDs with 6bit per color
>> > > will ignore the 2 LSBs of each color lane, and modules using a SoC
>> > > that provides only 6bit per color, drive the display information on the
>> > > 6 MSBs of each color lane and tie the 2 LSBs of each color lane to GND.
>> > >
>> > > Thus, no matter what combination of LCD and SoC is used, the LCD port
>> > > can be used without shuffling bit lanes by always configuring the LCD
>> > > output to 24bit mode.
>> > >
>> > > Add a function to handle certain quirks of the LCD interface to the
>> > > panel driver to be able to override the bus format specified in a
>> > > panel's display_mode.
>> >
>> > I think the above paragraph clearly indicates that this is the wrong
>> > place to workaround this. You say yourself that the LCD interface has
>> > quirks that need to be handled, so why do you want to force this
>> > handling into the panel driver?
>> >
>> The quirk is in the interfacing of the SoM's LCD output to the LCD
>> panel. Thus it can be handled in either place.
>
> Yes. What I'm saying is that the panel is, in my opinion, the wrong
> place to handle an LCD interface (originating from the SoM) quirk.

There's 2 possible things we could need to describe here. First, is
any restrictions the SoM has. For example, the SoM has an 18-bit
interface while the SoC has a 24-bit interface. Second, is how a panel
with fewer bits than the interface (whether a SoM or direct to SoC) is
wired up. If we think about this in terms of a base DT plus overlays,
then the former case belongs in the base and the latter belongs in the
overlay. If the SoM interface needs to be SoC independent, then it
gets more complicated as we don't want to have the SoC's LCD
controller node in the overlay adding properties to it and therefore
need to have some sort of translation (i.e. a connector binding). But
we have no definition of how we would describe OF graph thru a
connector.

In the end, these are board level properties, so you can make the same
argument that this property doesn't belong in the SoC's LCD controller
node as you can it doesn't belong in the panel node. Generally, we
just default to the node bound to the driver we want to handle the
property.

In any case, I think this should be properties of the endpoints rather
than the endpoint parent nodes as it is a property of the interface,
not the controller nor the panel. This is also how camera interfaces
were done. An LCD controller node could have 2 interfaces for example.

>> > The panel remains the same, no matter what interface you connect it to.
>> >
>> Because that's just ONE place to change, no matter what LCD driver is
>> being used.
>
> That's a Linux specific implementation detail. If you ever want to use
> a panel that is not driven by simple-panel you'd have to change it in
> that driver, too.

I do agree the implementation belongs in the LCD controller side, but
just because the property is in the panel node that doesn't mean it's
the panel driver that has to handle the property. As long as the
property is parse-able in a standard way, the "parent" can do it.
There are cases where the driver tied to the parent node handles
properties in the child nodes. SPI timing modes is one example. In
this case, I think we'll need to handle this property being in the
local endpoint and the remote endpoint and resolving the format needed
based on that (as well as what the panel driver says). That's going to
be needed with overlays and connectors anyways and then you don't
really have to care where the restriction comes from.

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

Re: [RESEND PATCH v2 2/5] backlight: pwm_bl: Add device link for pwm_bl and pwm

[Brian Norris]

Hi,

On Tue, Oct 17, 2017 at 04:13:55PM +0800, Jeffy Chen wrote:
> On 10/17/2017 07:57 AM, Brian Norris wrote:
> >This is going to be a*lot*  of churn throughout the tree, if we expect
> >all resource consumers to do this. I think we'd want some kind of
> >agreement from the PM maintainers and (larger) subsystem owners before
> >going down this route...
> >
> >And in the PWM case, pwm_get() already has the device pointer. Why can't
> >we just instrument it instead?
> 
> according to pwm_bl driver, we may need to take care of pwm_request() too:

That's a legacy API. I wouldn't spend any time on improving it. In fact,
the only other 2 users are:
(a) drivers/input/misc/max8997_haptic.c: abandoned; nobody provides
pdata for that driver, so pwm_request() can never be called...
(b) arch/arm/mach-s3c24xx/mach-rx1950.c: can be easily converted to
the lookup table approach (pwm_add_table() + pwm_get()) if needed

> pb->pwm = devm_pwm_get(>dev, NULL);
> if (IS_ERR(pb->pwm) && PTR_ERR(pb->pwm) != -EPROBE_DEFER &&
> !node) {
> dev_err(>dev, "unable to request PWM, trying
> legacy API\n");
> pb->legacy = true;
> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
> }
> 
> and maybe also *of_pwm_get...
> 
> maybe we can add a dummy pwm chip for those orphan pwms?

What? That seems like a very silly idea. And judging by Thierry's
response to your v4, he doesn't understand it either.

All I was suggesting was that you should try to add the device links in
the fewest places possible. Because if you require all consumers to add
extra boilerplate to resolve some strange corner cases, those corner
cases will likely go unsolved in many cases.

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

Re: [RFC v2 0/8] Acer Chromebook R13 support

[Laurent Pinchart]

Hi Ulrich,

(CC'ing Matthias Brugger and Daniel Kurtz)

On Monday, 16 October 2017 18:31:32 EEST Ulrich Hecht wrote:
> Hi!
> 
> This is a new revision of the Acer Chromebook R13 support series. It does
> not offer anything new in terms of functionality, but eliminates three out
> of four ugly hacks and adds a few minor cleanups; see below for details.
> Thanks to Robin Murphy and CK Hu for their comments and suggestions!
> 
> I'm still looking for advice on how to implement the dual-role mmsys device
> correctly; see "hack: mediatek: get mmsys to register as both DRM and clock
> device" for details on this.

What I'd really like to find out is what the mmsys device is. Its DT binding 
documents it as "The Mediatek mmsys controller provides various clocks to the 
system". Even if it provides clocks to the display engine, it shouldn't be 
used as the root device in the display complex. There could of course be 
information I'm lacking as the datasheet isn't public. Hopefully someone from 
Mediatek and/or Google will be able to comment on this.

> Like the previous revision, you can find this series at
> https://github.com/uli/kernel/tree/elm-working, which also contains a config
> file and several ancillary bits that are required to build a kernel
> partition for the Chromebook. Instructions on how to do so (and various
> other things that have to be done to get it running on your device) are
> available at
> https://www.elinux.org/User:Uli/Acer_Chromebook_R13_GPU_test_system (These
> instructions have been written for the vendor kernel, but apply to mainline
> as well, except that you won't need any extra patches.)
> 
> CU
> Uli
> 
> Changes since RFC v1:
> - cmdq: remove obsolete driver; not currently used anyway
> - dt: remove CD GPIO from mmc1, does not seem to be correct
> - mmc: remove mtk-sd.c revert hack (works fine without the CD pin)
> - dsi: fix port number for drm_of_find_panel_or_bridge(), remove hack
> - fbdev: add missing Signed-off-bys
> - iommu: remove io-pgtable sanity check hack, has been properly fixed
> - minor style fixes
> 
> 
> Ulrich Hecht (8):
>   drm/bridge: GPIO-controlled display multiplexer driver
>   platform/chrome: ChromeOS firmware interface driver
>   drm/bridge: Parade PS8640 MIPI DSI -> eDP converter driver
>   drm/bridge: Analogix ANX7688 HDMI -> DP bridge driver
>   arm64: dts: mediatek: Add Elm Rev. 3 device tree
>   hack: mediatek: get mmsys to register as both DRM and clock device
>   drm/mediatek: Add DRM-based framebuffer device
>   drm: mediatek: Fix drm_of_find_panel_or_bridge conversion
> 
>  arch/arm64/boot/dts/mediatek/Makefile|1 +
>  arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts |   21 +
>  arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi |  210 
>  arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi | 1013 +++
>  drivers/clk/mediatek/clk-mt8173.c|4 +-
>  drivers/gpu/drm/bridge/Kconfig   |   32 +
>  drivers/gpu/drm/bridge/Makefile  |5 +
>  drivers/gpu/drm/bridge/analogix-anx7688.c|  233 +
>  drivers/gpu/drm/bridge/generic-gpio-mux.c|  316 +++
>  drivers/gpu/drm/bridge/parade-ps8640.c   | 1104 +++
>  drivers/gpu/drm/mediatek/Makefile|2 +
>  drivers/gpu/drm/mediatek/mtk_dpi.c   |5 +-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c   |5 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |   15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h   |4 +-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c|   13 +
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h|3 +
>  drivers/gpu/drm/mediatek/mtk_drm_fbdev.c |  181 
>  drivers/gpu/drm/mediatek/mtk_drm_fbdev.h |   32 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c   |2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c  |5 +-
>  drivers/platform/chrome/Kconfig  |   18 +
>  drivers/platform/chrome/Makefile |2 +
>  drivers/platform/chrome/chromeos.c   |  120 +++
>  drivers/platform/chrome/chromeos.h   |   61 ++
>  drivers/platform/chrome/chromeos_arm.c   |  264 ++
>  drivers/platform/chrome/elog.h   |  186 
>  include/linux/chromeos_platform.h|   27 +
>  28 files changed, 3874 insertions(+), 10 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi
>  create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
>  create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fbdev.h
>  create mode 100644 drivers/platform/chrome/chromeos.c
>  

[PATCH] drm: some KMS todo ideas

[Daniel Vetter]

Inspired by discussions with Keith and Ville.

Cc: Ville Syrjälä 
Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 92ee2f982572..96f8ec7dbe4e 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -304,6 +304,18 @@ There's a bunch of issues with it:
 
 Contact: Daniel Vetter
 
+KMS cleanups
+
+
+Some of these date from the very introduction of KMS in 2008 ...
+
+- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. 
Should
+  be renamed to drm_mode_config.object_idr.
+
+- drm_display_mode doesn't need to be derived from drm_mode_object. That's
+  leftovers from older (never merged into upstream) KMS designs where modes
+  where set using their ID, including support to add/remove modes.
+
 Better Testing
 ==
 
-- 
2.14.1

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

Re: [PATCH v2 1/4] video: fb: Make fbcon dmi quirks usuable for drm drivers too

[Hans de Goede]

Hi,

Sorry for being slow to reply, I've been a bit overwhelmed with
other stuff lately.

On 10/02/2017 10:01 AM, Daniel Vetter wrote:

On Sun, Oct 01, 2017 at 05:33:14PM +0200, Hans de Goede wrote:

Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot (transparently) rotate in hardware, so we
need to rotate things in software / let user space deal with this.

The fbcon code has a set of DMI based quirks to automatically detect
such tablet LCD panels and rotate the fbcon to compensate.

The plan was for userspace (e.g. a Wayland compositor) to simply read
/sys/class/graphics/fbcon/rotate and apply the rotation from there to
the LCD panel to compensate.

However this will not work when an external monitor gets plugged in,
since with fbcon rotation is not per output, so the fbcon quirk code
disables the rotation when an external monitor is present.

Using /sys/class/graphics/fbcon/rotate will not help in that case
since it will indicate no rotation is in use. So instead we are going
to need a drm connecter property for this.

This commit is a preparation patch for adding the drm-connecter
property, by making the fbcon quirk code generally usable so that
the drm code can use it to check for rotation quirks.

Note this commit re-uses the FB_CMDLINE Kconfig option for selecting
if the quirk code should be build, since that is already selected by
both the drm and fbcon code.

Signed-off-by: Hans de Goede 


Can we pls just outright move this out of fbdev? fbdev is dead, I don't
want to add/maintain new stuff in there (except fbcon, but that should not
deal with stuff like this).


Sure we can do that, but fbcon also needs access to the quirks, so then
we need to have some part of the drm code which always gets builtin into
the kernel and make the drm code export a function for this which the
fbcon code uses.

The reason why fbcon uses this is because there are cases where the BIOS
does not setup the EFIFB with the correct rotation, typically because
the hardware does not support 90 / 270 degrees rotation and the
screen has been mounted rotated 90 / 270 degrees rotation.

Regards,

Hans



This probably means some serious patch series acrobatics, or just breaking
the current fbcon-only hack and rebuilding it in drm (in the same series).

>

-Daniel


---
Changes in v2:
-Rebased on 4.14-rc1
---
  drivers/video/fbdev/core/Makefile  |  6 +++---
  .../core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c}   | 15 +--
  drivers/video/fbdev/core/fbcon.c   | 22 ++
  drivers/video/fbdev/core/fbcon.h   |  6 --
  include/linux/fb.h |  6 ++
  5 files changed, 32 insertions(+), 23 deletions(-)
  rename drivers/video/fbdev/core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c} (91%)

diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 73493bbd7a15..06caf037a822 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,7 @@
  obj-$(CONFIG_FB_CMDLINE)  += fb_cmdline.o
+ifeq ($(CONFIG_DMI),y)
+obj-$(CONFIG_FB_CMDLINE)  += fb_dmi_quirks.o
+endif
  obj-$(CONFIG_FB_NOTIFY)   += fb_notify.o
  obj-$(CONFIG_FB)  += fb.o
  fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
@@ -14,9 +17,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
  fb-y+= fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
 fbcon_ccw.o
  endif
-ifeq ($(CONFIG_DMI),y)
-fb-y += fbcon_dmi_quirks.o
-endif
  endif
  fb-objs   := $(fb-y)
  
diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c b/drivers/video/fbdev/core/fb_dmi_quirks.c

similarity index 91%
rename from drivers/video/fbdev/core/fbcon_dmi_quirks.c
rename to drivers/video/fbdev/core/fb_dmi_quirks.c
index 6904e47d1e51..d5fdf3245f83 100644
--- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
+++ b/drivers/video/fbdev/core/fb_dmi_quirks.c
@@ -1,5 +1,5 @@
  /*
- *  fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
+ *  fb_dmi_quirks.c -- DMI based LCD panel rotation quirk detection
   *
   *Copyright (C) 2017 Hans de Goede 
   *
@@ -11,7 +11,6 @@
  #include 
  #include 
  #include 
-#include "fbcon.h"
  
  /*

   * Some x86 clamshell design devices use portrait tablet screens and a display
@@ -112,7 +111,11 @@ static const struct dmi_system_id rotate_data[] = {
{}
  };
  
-int fbcon_platform_get_rotate(struct fb_info *info)

+/*
+ * Note this function returns the rotation necessary to put the display
+ * the right way up, or -1 if there is no quirk.
+ */
+int fb_get_panel_rotate_quirk(int width, int height)
  {
const struct dmi_system_id *match;
const struct fbcon_dmi_rotate_data *data;
@@ -124,8 +127,7 @@ int fbcon_platform_get_rotate(struct 

[Bug 197103] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 / IP: nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau]

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197103

--- Comment #4 from Igor Gnatenko (i.gnatenko.br...@gmail.com) ---
(In reply to Thorsten Leemhuis from comment #2)
> Did you try to bring this to the nouveau developer list? Not sure if the
> drivers developers look here. Did you consider to bisect this? 
Not really, I am kinda busy with $dayjob so I just tried to report to upstream
something useful.

If I will get time, I will try to do this.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/8] Acer Chromebook R13 support

[Sean Paul]

On Tue, Oct 17, 2017 at 12:33:09PM +0200, Matthias Brugger wrote:
> Hi Ulrich,
> 
> On 10/16/2017 05:31 PM, Ulrich Hecht wrote:
> > Hi!
> > 
> > This is a new revision of the Acer Chromebook R13 support series. It does
> > not offer anything new in terms of functionality, but eliminates three out
> > of four ugly hacks and adds a few minor cleanups; see below for details.
> > Thanks to Robin Murphy and CK Hu for their comments and suggestions!
> > 
> > I'm still looking for advice on how to implement the dual-role mmsys device
> > correctly; see "hack: mediatek: get mmsys to register as both DRM and clock
> > device" for details on this.
> > 
> > Like the previous revision, you can find this series at
> > https://github.com/uli/kernel/tree/elm-working, which also contains a config
> > file and several ancillary bits that are required to build a kernel
> > partition for the Chromebook. Instructions on how to do so (and various
> > other things that have to be done to get it running on your device) are
> > available at
> > https://www.elinux.org/User:Uli/Acer_Chromebook_R13_GPU_test_system (These
> > instructions have been written for the vendor kernel, but apply to mainline
> > as well, except that you won't need any extra patches.)
> > 
> 
> I appreciate your efforts to get this done. 

Agreed, thanks for doing this work and posting it! 

> From what I understand you
> rebased the patches from the chromium kernel to mainline. So you should keep
> the signed-off-by from the original author and just add you signed-off-by
> below that.
> Also it would be nice to CC these persons so that they are aware of your 
> effort.
> 

Additionally, make sure the author and commit messages are preserved when you 
send
patches. You can add your own message in addition to your SoB, but please try to
preserve history.

Sean


> > CU
> > Uli
> > 
> > Changes since RFC v1:
> > - cmdq: remove obsolete driver; not currently used anyway
> 
> Are you sure about this? I remember that Dan (CC'ed) told me that this is
> one of the requirements to get upstream working.
> 
> Dan, can you clarify please?
> 
> Regards,
> Matthias
> 
> > - dt: remove CD GPIO from mmc1, does not seem to be correct
> > - mmc: remove mtk-sd.c revert hack (works fine without the CD pin)
> > - dsi: fix port number for drm_of_find_panel_or_bridge(), remove hack
> > - fbdev: add missing Signed-off-bys
> > - iommu: remove io-pgtable sanity check hack, has been properly fixed
> > - minor style fixes
> > 
> > 
> > Ulrich Hecht (8):
> >drm/bridge: GPIO-controlled display multiplexer driver
> >platform/chrome: ChromeOS firmware interface driver
> >drm/bridge: Parade PS8640 MIPI DSI -> eDP converter driver
> >drm/bridge: Analogix ANX7688 HDMI -> DP bridge driver
> >arm64: dts: mediatek: Add Elm Rev. 3 device tree
> >hack: mediatek: get mmsys to register as both DRM and clock device
> >drm/mediatek: Add DRM-based framebuffer device
> >drm: mediatek: Fix drm_of_find_panel_or_bridge conversion
> > 
> >   arch/arm64/boot/dts/mediatek/Makefile|1 +
> >   arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts |   21 +
> >   arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi |  210 
> >   arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi | 1013 
> > 
> >   drivers/clk/mediatek/clk-mt8173.c|4 +-
> >   drivers/gpu/drm/bridge/Kconfig   |   32 +
> >   drivers/gpu/drm/bridge/Makefile  |5 +
> >   drivers/gpu/drm/bridge/analogix-anx7688.c|  233 +
> >   drivers/gpu/drm/bridge/generic-gpio-mux.c|  316 +++
> >   drivers/gpu/drm/bridge/parade-ps8640.c   | 1104 
> > ++
> >   drivers/gpu/drm/mediatek/Makefile|2 +
> >   drivers/gpu/drm/mediatek/mtk_dpi.c   |5 +-
> >   drivers/gpu/drm/mediatek/mtk_drm_ddp.c   |5 +-
> >   drivers/gpu/drm/mediatek/mtk_drm_drv.c   |   15 +
> >   drivers/gpu/drm/mediatek/mtk_drm_drv.h   |4 +-
> >   drivers/gpu/drm/mediatek/mtk_drm_fb.c|   13 +
> >   drivers/gpu/drm/mediatek/mtk_drm_fb.h|3 +
> >   drivers/gpu/drm/mediatek/mtk_drm_fbdev.c |  181 
> >   drivers/gpu/drm/mediatek/mtk_drm_fbdev.h |   32 +
> >   drivers/gpu/drm/mediatek/mtk_dsi.c   |2 +-
> >   drivers/gpu/drm/mediatek/mtk_hdmi.c  |5 +-
> >   drivers/platform/chrome/Kconfig  |   18 +
> >   drivers/platform/chrome/Makefile |2 +
> >   drivers/platform/chrome/chromeos.c   |  120 +++
> >   drivers/platform/chrome/chromeos.h   |   61 ++
> >   drivers/platform/chrome/chromeos_arm.c   |  264 ++
> >   drivers/platform/chrome/elog.h   |  186 
> >   include/linux/chromeos_platform.h|   27 +
> >   28 files changed, 3874 insertions(+), 10 deletions(-)
> >   create mode 100644 

Re: [PATCH v3 4/4] drm/rockchip: vop: Add more RGB output interface type

[Sean Paul]

On Mon, Oct 09, 2017 at 04:07:04PM +0800, Sandy Huang wrote:
> This patch add serial RGB output interface for rockchip vop, the
> more info about serial RGB output interface described at the
> following file:
> 
> Documentation/devicetree/bindings/display/panel/panel-rgb.txt
> 
> Signed-off-by: Sandy Huang 
Reviewed-by: Sean Paul 
> ---
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 56bbd2e..59a01c3 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -209,6 +209,8 @@ struct vop_data {
>  #define ROCKCHIP_OUT_MODE_P888   0
>  #define ROCKCHIP_OUT_MODE_P666   1
>  #define ROCKCHIP_OUT_MODE_P565   2
> +#define ROCKCHIP_OUT_MODE_S888   8
> +#define ROCKCHIP_OUT_MODE_S888_DUMMY 12
>  /* for use special outface */
>  #define ROCKCHIP_OUT_MODE_   15
>  
> -- 
> 2.7.4
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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