date:20180114

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

2018-01-14 Thread Laurent Pinchart

Hi Simon,

On Monday, 15 January 2018 08:57:48 EET Simon Horman wrote:
> On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote:
> > On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote:
> >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> >>> This patch series addresses a design mistake that dates back from the
> >>> initial DU support. Support for the LVDS encoders, which are IP cores
> >>> separate from the DU, was bundled in the DU driver. Worse, both the DU
> >>> and LVDS were described through a single DT node.
> >>> 
> >>> To fix the, patches 01/10 and 02/10 define new DT bindings for the
> >>> LVDS encoders, and deprecate their description inside the DU bindings.
> >>> To retain backward compatibility with existing DT, patch 03/10 then
> >>> patches the device tree at runtime to convert the legacy bindings to the
> >>> new ones.
> >> 
> >> Looks like we will have to postpone the R-Car Gen2 Modern DT flag day
> >> again by a few kernel releases?
> > 
> > Why so ? We don't have to drop support for all legacy DT bindings at the
> > same time, do we ? We can switch to the new-style clock bindings on Gen2
> > already, and drop the legacy LVDS bindings later.
> 
> To clarify, after this patchset.
> * Old DTs work with old and new kernels.
> * New DTs require new kernels.

That's correct. I've tested old DTs with new kernels successfully on Lager, 
Salvator-X (both H3 ES1.x and M3-W) and Salvator-XS.

-- 
Regards,

Laurent Pinchart

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

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

2018-01-14 Thread Laurent Pinchart

Hi Simon,

On Monday, 15 January 2018 08:55:29 EET Simon Horman wrote:
> On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote:
> > On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote:
> >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> >>> The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> >>> corresponding device tree bindings.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> 
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> >>> @@ -0,0 +1,54 @@
> >>> +Renesas R-Car LVDS Encoder
> >>> +==
> >>> +
> >>> +These DT bindings describe the LVDS encoder embedded in the Renesas
> >>> R-Car Gen2 +and Gen3 SoCs.
> >>> +
> >>> +Required properties:
> >>> +
> >>> +- compatible : Shall contain one of
> >>> +  - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> >>> encoders
> >> 
> >> As this is a new binding, please use "renesas,-lvds".
> > 
> > I've recently been thinking that we made the wrong choice, -
> > would be better in my opinion as it aligns with -, but it's
> > too late to change that, so I'll change the order here.
> 
> My recollection is that in the beginning we had a bit of a mixture but
> leaned towards -, which made sense in my opinion. However, after
> some discussion it was agreed that the best-practice for upstream was to
> use -. Unless that situation has changed lets stock with using
> - for new bindings.

Sure, that was my plan, and it seems I failed to explain it clearly. I too 
believe that - would be better, but as we have standardized on -
 and as there's no strong reason to reconsider that decision at the 
moment, the next version of this patch will use -. It was a mistake 
in v1, not an attempt to change what we had agreed on.

> >> BTW, would it make sense to use "renesas,-du" for the new DU
> >> binding, too? Or have you reserved that for the future version that will
> >> have a one-to-one mapping between device nodes and DU channels? ;-)
> > 
> > It's a good idea, let's reserve it for that evolution. If it ever happens
> > ;-)

-- 
Regards,

Laurent Pinchart

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

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

2018-01-14 Thread bugzilla-daemon

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

Amy  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
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 104599] corrupted desktop graphics with latest git intel driver

2018-01-14 Thread bugzilla-daemon

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

--- Comment #4 from Tapani Pälli  ---
(In reply to Mario Kleiner from comment #3)
> This is running the new GNOME based Ubuntu GUI with Gnome-Shell Wayland,
> right?
> 
> With "Windows control did not work" you mean it doesn't respond to
> mouse-clicks?
> 
> In that case it is known bugs/limitations in gnome-shell for depth 30/10bpc
> mode. GNOME Shells picking code can't handle 10 bit per color channel.
> 
> Additionally Gnome-Shells Wayland compositor doesn't handle anything but
> bgrx or bgra framebuffers in its drm/kms backend. It takes whatever
> framebuffer format it gets, e.g., bgrx1010102 and hands it to the kernel as
> bgrx, so the gpu misinterprets a 10 bit image as a 8 bit image during
> scanout, which ends badly.

Right, so this is NOTOURBUG. Zebulon, your issue should disappear when you do
apt-get update again since allow_rgb10_configs defaults to 'false'.

Mario, do you know if there us existing Gnome bug about this? (did not find
such) Maybe easiest workaround for them would be to ignore 10bpc until picking
and kms backend is fixed.

-- 
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/arm/malidp: Disable pixel alpha blending for colors that do not have alpha

2018-01-14 Thread kbuild test robot

Hi Ayan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15-rc8 next-20180112]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ayan-Halder/drm-arm-malidp-Disable-pixel-alpha-blending-for-colors-that-do-not-have-alpha/20180115-080603
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/arm/malidp_planes.c: In function 'malidp_de_plane_update':
>> drivers/gpu/drm/arm/malidp_planes.c:275:42: error: 'const struct 
>> drm_format_info' has no member named 'alpha'
 u8 alpha_bits = plane->state->fb->format->alpha;
 ^~

vim +275 drivers/gpu/drm/arm/malidp_planes.c

   267  
   268  static void malidp_de_plane_update(struct drm_plane *plane,
   269 struct drm_plane_state *old_state)
   270  {
   271  struct malidp_plane *mp;
   272  struct malidp_plane_state *ms = 
to_malidp_plane_state(plane->state);
   273  u32 src_w, src_h, dest_w, dest_h, val;
   274  int i;
 > 275  u8 alpha_bits = plane->state->fb->format->alpha;
   276  
   277  mp = to_malidp_plane(plane);
   278  
   279  /* convert src values from Q16 fixed point to integer */
   280  src_w = plane->state->src_w >> 16;
   281  src_h = plane->state->src_h >> 16;
   282  dest_w = plane->state->crtc_w;
   283  dest_h = plane->state->crtc_h;
   284  
   285  malidp_hw_write(mp->hwdev, ms->format, mp->layer->base);
   286  
   287  for (i = 0; i < ms->n_planes; i++) {
   288  /* calculate the offset for the layer's plane registers 
*/
   289  u16 ptr = mp->layer->ptr + (i << 4);
   290  dma_addr_t fb_addr = 
drm_fb_cma_get_gem_addr(plane->state->fb,
   291   
plane->state, i);
   292  
   293  malidp_hw_write(mp->hwdev, lower_32_bits(fb_addr), ptr);
   294  malidp_hw_write(mp->hwdev, upper_32_bits(fb_addr), ptr 
+ 4);
   295  }
   296  malidp_de_set_plane_pitches(mp, ms->n_planes,
   297  plane->state->fb->pitches);
   298  
   299  malidp_hw_write(mp->hwdev, LAYER_H_VAL(src_w) | 
LAYER_V_VAL(src_h),
   300  mp->layer->base + MALIDP_LAYER_SIZE);
   301  
   302  malidp_hw_write(mp->hwdev, LAYER_H_VAL(dest_w) | 
LAYER_V_VAL(dest_h),
   303  mp->layer->base + MALIDP_LAYER_COMP_SIZE);
   304  
   305  malidp_hw_write(mp->hwdev, LAYER_H_VAL(plane->state->crtc_x) |
   306  LAYER_V_VAL(plane->state->crtc_y),
   307  mp->layer->base + MALIDP_LAYER_OFFSET);
   308  
   309  if (mp->layer->id == DE_SMART)
   310  malidp_hw_write(mp->hwdev,
   311  LAYER_H_VAL(src_w) | LAYER_V_VAL(src_h),
   312  mp->layer->base + 
MALIDP550_LS_R1_IN_SIZE);
   313  
   314  /* first clear the rotation bits */
   315  val = malidp_hw_read(mp->hwdev, mp->layer->base + 
MALIDP_LAYER_CONTROL);
   316  val &= ~LAYER_ROT_MASK;
   317  
   318  /* setup the rotation and axis flip bits */
   319  if (plane->state->rotation & DRM_MODE_ROTATE_MASK)
   320  val |= ilog2(plane->state->rotation & 
DRM_MODE_ROTATE_MASK) <<
   321 LAYER_ROT_OFFSET;
   322  if (plane->state->rotation & DRM_MODE_REFLECT_X)
   323  val |= LAYER_H_FLIP;
   324  if (plane->state->rotation & DRM_MODE_REFLECT_Y)
   325  val |= LAYER_V_FLIP;
   326  
   327  val &= ~LAYER_COMP_MASK;
   328  if (alpha_bits > 0) {
   329  
   330  /*
   331   * always enable pixel alpha blending until we have a 
way to change
   332   * blend modes
   333   */
   334  val |= LAYER_COMP_PIXEL;
   335  } else {
   336  
   337  /*
   338   * do not enable pixel alpha blending as the color 
channel does not
   339   * have any alpha information
   340   */
   341  val |= LAYER_COMP_PLANE;
   342  
   343  /* Set layer alpha coefficient to 0xff ie fully opaque 
*/
   344

[PATCH] dma-buf/sw_sync: fix document of sw_sync_create_fence_data

2018-01-14 Thread Shawn Guo

The structure should really be sw_sync_create_fence_data rather than
sw_sync_ioctl_create_fence which is the function name.

Signed-off-by: Shawn Guo 
---
 drivers/dma-buf/sw_sync.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 24f83f9eeaed..7779bdbd18d1 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -43,14 +43,14 @@
  * timelines.
  *
  * Fences can be created with SW_SYNC_IOC_CREATE_FENCE ioctl with struct
- * sw_sync_ioctl_create_fence as parameter.
+ * sw_sync_create_fence_data as parameter.
  *
  * To increment the timeline counter, SW_SYNC_IOC_INC ioctl should be used
  * with the increment as u32. This will update the last signaled value
  * from the timeline and signal any fence that has a seqno smaller or equal
  * to it.
  *
- * struct sw_sync_ioctl_create_fence
+ * struct sw_sync_create_fence_data
  * @value: the seqno to initialise the fence with
  * @name:  the name of the new sync point
  * @fence: return the fd of the new sync_file with the created fence
-- 
1.9.1

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

[Bug 104627] Regression: Unable to start "Saints Row: The Third" (Steam for Linux)

2018-01-14 Thread bugzilla-daemon

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

Christian Inci  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Christian Inci  ---
Whoops, thank you very much. I overlooked that bug.

*** This bug has been marked as a duplicate of bug 104490 ***

-- 
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 104627] Regression: Unable to start "Saints Row: The Third" (Steam for Linux)

2018-01-14 Thread bugzilla-daemon

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #1 from Mike Lothian  ---
This is a duplicate of Bug 104490

-- 
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 104631] Requesting a New Account for libdrm

2018-01-14 Thread bugzilla-daemon

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

Bug ID: 104631
   Summary: Requesting a New Account for libdrm
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: david1.z...@amd.com

Created attachment 136720
  --> https://bugs.freedesktop.org/attachment.cgi?id=136720=edit
GPG and SSH public key

Hi,

I'm David from AMD and I'd like to apply for a freedesktop account for my
contributions to libdrm.

my real name: Chunming Zhou
my email address: david1.z...@amd.com
my preferred account name: Chunming-Zhou

my SSH public key and GPG public key are attached.

Please tell me if you need additional info or if you have questions.

Thank you,

David Zhou

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

linux-next: manual merge of the drm tree with Linus' tree

2018-01-14 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/tegra/sor.c

between commit:

  d780537f9b49 ("drm/tegra: sor: Fix hang on Tegra124 eDP")

from Linus' tree and commit:

  1087fac18b8e ("drm/tegra: dc: Use direct offset to plane registers")

from the drm tree.

I fixed it up (I just included the comment from the former) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

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

[Bug 104627] Regression: Unable to start "Saints Row: The Third" (Steam for Linux)

2018-01-14 Thread bugzilla-daemon

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

Bug ID: 104627
   Summary: Regression: Unable to start "Saints Row: The Third"
(Steam for Linux)
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: trivial
  Priority: lowest
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: chris.bug...@broke-the-inter.net
QA Contact: dri-devel@lists.freedesktop.org

A dialog window shows up before the game exits:
Title: "Graphics Requirements Not Met"
Message: "Unfortunately, the game requires OpenGL 4.1 to run, and your OpenGL
driver does not provide support for it. The game will now exit."

The Mesa commit "gallium/dri2: Enable {GLX_ARB,EGL_KHR}_context_flush_control"
(0d044351b7043cd0bc94c1cb9b7a2213f8054414) is the cause of the regression.

System info: Gentoo AMD64 Unstable; llvm, clang, ...: 6.0.; libdrm, mesa,
...: ; Graphics card: RX 470 (Polaris 10); Kernel: 4.15_rc7 (Using a
"newer" kernel from the ~agd5f repository isn't possible anymore due to another
regression)

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

2018-01-14 Thread bugzilla-daemon

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

--- Comment #17 from Daniel Vetter (dan...@ffwll.ch) ---
Created attachment 273609
  --> https://bugzilla.kernel.org/attachment.cgi?id=273609=edit
ast patch to load the lut on modesets

This only patches ast, since I'm still not clear what exactly is going on on
the radeon driver. The code looks the same, but the reported test results are
different.

Bill Fraser, can you pls test 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

[Bug 99316] Radeon crash when laptop on AC power

2018-01-14 Thread bugzilla-daemon

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

--- Comment #13 from l.hartm...@gmail.com ---
Hi!
As an owner of the same GPU, I can confirm this bug still appears under linux
4.15.0-rc7.
The card card crashes or hangs when used with DRI_PRIME=1. After seeing this
report, I tried with the laptop plugged out and it surprisingly did work.

It would be nice to have a solution as the w5130m isn't currently supported by
amdgpu either leaving it unusable under linux.

-- 
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 198123] Console is the wrong color at boot with radeon 6670

2018-01-14 Thread bugzilla-daemon

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

--- Comment #16 from Daniel Vetter (dan...@ffwll.ch) ---
Deposte Pirate, the latest patch I attached (attachment 273575) doesn't even
apply on latest kernels, so I' not sure what exactly you tested. That latest
patch should be tested on top of b8e2b0199cc377617dc238f5106352c06dcd3fa2. Can
you pls link to the exact patch you tested and the git sha1 you applied it to?
Or if possible, upload your entire resulting git tree, with the patch
committed, to github or some place.

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

[Bug 104624] [regression, vega] Running DOOM causes ERROR amdgpu_dm_commit_planes: acrtc 2, already busy WARNING amdgpu_dm_atomic_commit_tail and prepare_flip_isr

2018-01-14 Thread bugzilla-daemon

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

Bug ID: 104624
   Summary: [regression, vega] Running DOOM causes *ERROR*
amdgpu_dm_commit_planes: acrtc 2, already busy WARNING
amdgpu_dm_atomic_commit_tail and prepare_flip_isr
   Product: DRI
   Version: DRI git
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net

Created attachment 136717
  --> https://bugs.freedesktop.org/attachment.cgi?id=136717=edit
dmesg

I'm using

43:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Vega 10 XT [Radeon RX Vega 64] [1002:687f] (rev c1)

and running DOOM (2016) over Wine 2.20, Mesa 17.3.0-rc3, LLVM 5.0.1, kernel
4.15.0-0.rc7.git2.1.fc28.x86_64. When the modeset from the game happens, I get:

[  176.242980] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]]
*ERROR* [PLANE:38:plane-2] flip_done timed out
[  176.243071] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR*
amdgpu_dm_commit_planes: acrtc 2, already busy

and two WARNINGs. The machine can be rebooted normally over SSH. Full dmesg is
attached.

This is a regression, DOOM used to work.

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

Re: [PATCH v2 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

2018-01-14 Thread Jernej Škrabec

Hi all,

Dne sreda, 10. januar 2018 ob 20:25:04 CET je Jernej Skrabec napisal(a):
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of the Synopsys PHY
> related code could be reused.
> 
> Functions exported here are actually not specific to Synopsys PHYs but
> to DWC HDMI controller PHY interface. This means that even if the PHY is
> completely custom, i.e. not designed by Synopsys, exported functions can
> be useful.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44
> +-- include/drm/bridge/dw_hdmi.h  |
> 11 
>  2 files changed, 41 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 7ca14d7325b5..7d80f4b56683 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
> *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
>  }
> 
> -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
>HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> 
> -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
>HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> 
>  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
>  {
> @@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct
> dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
> 
> +void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
> +{
> + /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> + hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> + hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);

I just noticed that meson dw hdmi driver uses function with the same name, 
which break compilation. Is it ok if I rename meson specific reset to 
meson_dw_hdmi_phy_reset()?

Best regards,
Jernej

> +
> +void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
> +{
> + hdmi_phy_test_clear(hdmi, 1);
> + hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
> + hdmi_phy_test_clear(hdmi, 0);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
> +
>  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  {
>   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> @@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   if (phy->has_svsret)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
> 
> - /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> + dw_hdmi_phy_reset(hdmi);
> 
>   hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> 
> - hdmi_phy_test_clear(hdmi, 1);
> - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> - HDMI_PHY_I2CM_SLAVE_ADDR);
> - hdmi_phy_test_clear(hdmi, 0);
> + dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
> 
>   /* Write to the PHY as configured by the platform */
>   if (pdata->configure_phy)
> @@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
>  }
> 
> -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> -   void *data)
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data)
>  {
>   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
>   connector_status_connected : connector_status_disconnected;
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> 
> -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> -bool force, bool disabled, bool rxsense)
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense)
>  {
>   u8 old_mask = hdmi->phy_mask;
> 
> @@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> *hdmi, void *data, if (old_mask != hdmi->phy_mask)
>   hdmi_writeb(hdmi, hdmi->phy_mask,

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

2018-01-14 Thread Yisheng Xie

Hi Christophe ，

On 2018/1/4 16:05, Christophe LEROY wrote:
> 
> 
> Le 25/12/2017 à 02:34, Yisheng Xie a écrit :
>>
>>
>> On 2017/12/24 17:05, christophe leroy wrote:
>>>
>>>
>>> Le 23/12/2017 à 14:48, Greg KH a écrit :
 On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
> Hi all,
>
> When I tried to use devm_ioremap function and review related code, I found
> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
> except one use ioremap while the other use ioremap_nocache.

 For all arches?  Really?  Look at MIPS, and x86, they have different
 functions.

> While ioremap's
> default function is ioremap_nocache, so devm_ioremap_nocache also have the
> same function with devm_ioremap, which can just be killed to reduce the 
> size
> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
>
> I have posted two versions, which use macro instead of function for
> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
> devm_ioremap_nocache for no need to keep a macro around for the duplicate
> thing. So here comes v3 and please help to review.

 I don't think this can be done, what am I missing?  These functions are
 not identical, sorry for missing that before.
>>>
>>> devm_ioremap() and devm_ioremap_nocache() are quite similar, both use 
>>> devm_ioremap_release() for the release, why not just defining:
>>>
>>> static void __iomem *__devm_ioremap(struct device *dev, resource_size_t 
>>> offset,
>>> resource_size_t size, bool nocache)
>>> {
>>> [...]
>>>  if (nocache)
>>>  addr = ioremap_nocache(offset, size);
>>>  else
>>>  addr = ioremap(offset, size);
>>> [...]
>>> }
>>>
>>> then in include/linux/io.h
>>>
>>> static inline void __iomem *devm_ioremap(struct device *dev, 
>>> resource_size_t offset,
>>> resource_size_t size)
>>> {return __devm_ioremap(dev, offset, size, false);}
>>>
>>> static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
>>> resource_size_t offset,
>>> resource_size_t size);
>>> {return __devm_ioremap(dev, offset, size, true);}
>>
>> Yeah, this seems good to me, right now we have devm_ioremap, 
>> devm_ioremap_wc, devm_ioremap_nocache
>> May be we can use an enum like:
>> typedef enum {
>> DEVM_IOREMAP = 0,
>> DEVM_IOREMAP_NOCACHE,
>> DEVM_IOREMAP_WC,
>> } devm_ioremap_type;
>>
>> static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
>> offset,
>>  resource_size_t size)
>>   {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}
>>
>>   static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
>> resource_size_t offset,
>>  resource_size_t size);
>>   {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}
>>
>>   static inline void __iomem *devm_ioremap_wc(struct device *dev, 
>> resource_size_t offset,
>>  resource_size_t size);
>>   {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}
>>
>>   static void __iomem *__devm_ioremap(struct device *dev, resource_size_t 
>> offset,
>>  resource_size_t size, devm_ioremap_type type)
>>   {
>>   void __iomem **ptr, *addr = NULL;
>>   [...]
>>   switch (type){
>>   case DEVM_IOREMAP:
>>   addr = ioremap(offset, size);
>>   break;
>>   case DEVM_IOREMAP_NOCACHE:
>>   addr = ioremap_nocache(offset, size);
>>   break;
>>   case DEVM_IOREMAP_WC:
>>   addr = ioremap_wc(offset, size);
>>   break;
>>   }
>>   [...]
>>   }
> 
> 
> That looks good to me, will you submit a v4 ?

Sorry for late response. And I will submit the v4 as your suggestion.

Thanks
Yisheng

> 
> Christophe
> 
>>

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

[PATCH] drm/nouveau/core/client: use strlcpy() instead of strncpy()

2018-01-14 Thread Xiongfeng Wang

From: Xiongfeng Wang 

gcc-8 reports

drivers/gpu/drm/nouveau/nvif/client.c: In function 'nvif_client_init':
./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified
bound 32 equals destination size [-Wstringop-truncation]

We need to use strlcpy() to make sure the dest string is nul-terminated.

Signed-off-by: Xiongfeng Wang 
---
 drivers/gpu/drm/nouveau/nvif/client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvif/client.c 
b/drivers/gpu/drm/nouveau/nvif/client.c
index 12db549..f294d99 100644
--- a/drivers/gpu/drm/nouveau/nvif/client.c
+++ b/drivers/gpu/drm/nouveau/nvif/client.c
@@ -69,7 +69,7 @@
} nop = {};
int ret;
 
-   strncpy(args.name, name, sizeof(args.name));
+   strlcpy(args.name, name, sizeof(args.name));
ret = nvif_object_init(parent != client ? >object : NULL,
   0, NVIF_CLASS_CLIENT, , sizeof(args),
   >object);
-- 
1.8.3.1

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

[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

2018-01-14 Thread bugzilla-daemon

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

--- Comment #5 from megaphant...@bol.com.br ---
Confirmed:

Radeon HD 7850
kernel 4.14.13
mesa 17.3.2
LLVM 4.0.1

-- 
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/10] R-Car DU: Convert LVDS code to bridge driver

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

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

[Bug 104599] corrupted desktop graphics with latest git intel driver

Re: [PATCH] drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha

[PATCH] dma-buf/sw_sync: fix document of sw_sync_create_fence_data

[Bug 104627] Regression: Unable to start "Saints Row: The Third" (Steam for Linux)

[Bug 104627] Regression: Unable to start "Saints Row: The Third" (Steam for Linux)

[Bug 104631] Requesting a New Account for libdrm

linux-next: manual merge of the drm tree with Linus' tree

[Bug 104627] Regression: Unable to start "Saints Row: The Third" (Steam for Linux)

[Bug 198123] Console is the wrong color at boot with radeon 6670

[Bug 99316] Radeon crash when laptop on AC power

[Bug 198123] Console is the wrong color at boot with radeon 6670

[Bug 104624] [regression, vega] Running DOOM causes ERROR amdgpu_dm_commit_planes: acrtc 2, already busy WARNING amdgpu_dm_atomic_commit_tail and prepare_flip_isr

Re: [PATCH v2 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

[PATCH] drm/nouveau/core/client: use strlcpy() instead of strncpy()

[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

19 matches

Site Navigation

Mail list logo

Footer information