Re: [Intel-gfx] [PATCH 1/2] drm/dp: Bit definition for D3 power state that keeps AUX fully powered

[Jani Nikula]

On Fri, 11 Aug 2017, Dhinakaran Pandiyan  wrote:
> DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state
>
> 101 = Set Main-Link for local Sink device and all downstream Sink
> devices to D3 (power-down mode), keep AUX block fully powered, ready to
> reply within a Response Timeout period of 300us.
>
> This state is useful in a MST dock + MST monitor configuration that
> doesn't wake up from D3 state.
>
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  include/drm/drm_dp_helper.h | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index b17476a..d77e0f5 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -614,10 +614,11 @@
>  #define DP_BRANCH_HW_REV0x509
>  #define DP_BRANCH_SW_REV0x50A
>  
> -#define DP_SET_POWER0x600
> -# define DP_SET_POWER_D00x1
> -# define DP_SET_POWER_D30x2
> -# define DP_SET_POWER_MASK  0x3
> +#define DP_SET_POWER 0x600
> +# define DP_SET_POWER_D0 0x1
> +# define DP_SET_POWER_D3 0x2
> +# define DP_SET_POWER_MASK   0x3

Please keep the above intact. It appears space is the indent character
of choice in this file.

BR,
Jani.

> +# define DP_SET_POWER_D3_AUX_ON  0x5
>  
>  #define DP_EDP_DPCD_REV  0x700/* eDP 1.2 */
>  # define DP_EDP_11   0x00

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

[git pull] drm fixes for v4.13-rc5

[Dave Airlie]

Hi Linus,

Nothing too earth shattering here, it just seems like lots of little
things all over the place, msm has probably the larger amount of
changes, but they all seem fine, otherwise, some rockchip, i915,
etnaviv and exynos fixes, along with one nouveau regression fix for
some older GPUs.

Dave.

The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e:

  Linux 4.13-rc4 (2017-08-06 18:44:49 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc5

for you to fetch changes up to 46828dc77961d9286e55671c4dd3b6c9effadf1a:

  Merge branch 'linux-4.13' of git://github.com/skeggsb/linux into
drm-fixes (2017-08-10 11:45:04 +1000)


i915, msm, nouveau, rockchip, exynos, etnaviv, core fixes


Archit Taneja (4):
  drm/msm/dsi: Calculate link clock rates with updated dsi->lanes
  drm/msm/mdp5: Fix typo in encoder_enable path
  drm/msm/mdp5: Drop clock names with "_clk" suffix
  drm/msm/adreno: Prevent unclocked access when retrieving timestamps

Arnd Bergmann (2):
  drm/msm: gpu: call qcom_mdt interfaces only for ARCH_QCOM
  drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations

Ben Skeggs (1):
  drm/nouveau/disp/nv04: avoid creation of output paths

Chris Wilson (2):
  dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence
  drm/i915/shrinker: Wrap need_resched() inside preempt-disable

Chuanxiao Dong (2):
  drm/i915/gvt: change resetting to resetting_eng
  drm/i915/gvt: clean workload queue if error happened

Dan Carpenter (2):
  drm/msm: fix an integer overflow test
  drm/msm: unlock on error in msm_gem_get_iova()

Dave Airlie (6):
  Merge branch 'msm-fixes-4.13-rc3' of
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.13-rc4' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-08' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-08-09-1' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'etnaviv/fixes' of
https://git.pengutronix.de/git/lst/linux into drm-fixes
  Merge branch 'linux-4.13' of git://github.com/skeggsb/linux into drm-fixes

Hans Verkuil (2):
  drm/msm: fix WARN_ON in add_vma() with no iommu
  drm/msm: NULL pointer dereference in drivers/gpu/drm/msm/msm_gem_vma.c

Jani Nikula (2):
  Merge tag 'gvt-fixes-2017-08-07' of
https://github.com/01org/gvt-linux into drm-intel-fixes
  drm/i915: fix backlight invert for non-zero minimum brightness

Jordan Crouse (5):
  drm/msm: Remove some potentially blocked register ranges
  drm/msm: Allow hardware clock gating to be toggled
  drm/msm: Turn off hardware clock gating before reading A5XX registers
  drm/msm: args->fence should be args->flags
  drm/msm: Remove __user from __u64 data types

Lionel Landwerlin (1):
  drm/i915/perf: fix flex eu registers programming

Lucas Stach (1):
  drm/bridge: tc358767: fix probe without attached output node

Maarten Lankhorst (1):
  drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut

Marek Szyprowski (1):
  drm/exynos: forbid creating framebuffers from too small GEM buffers

Mark yao (4):
  drm/rockchip: vop: fix iommu page fault when resume
  drm/rockchip: vop: fix NV12 video display error
  drm/rockchip: vop: round_up pitches to word align
  drm/rockchip: vop: report error when check resource error

Michał Mirosław (1):
  drm: make DRM_STM default n

Rob Clark (1):
  drm/msm/mdp5: fix unclocked register access in _cursor_set()

Tina Zhang (1):
  drm/i915/gvt: Initialize MMIO Block with HW state

Viresh Kumar (1):
  drm/msm/mdp5: Fix compilation warnings

Wladimir J. van der Laan (1):
  drm/etnaviv: Fix off-by-one error in reloc checking

Xiong Zhang (1):
  drm/i915/gvt: Change the max length of mmio_reg_rw from 4 to 8

 drivers/dma-buf/sync_file.c |   5 +-
 drivers/gpu/drm/bridge/tc358767.c   |   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  14 +-
 drivers/gpu/drm/i915/gvt/execlist.c |  27 +++-
 drivers/gpu/drm/i915/gvt/firmware.c |  11 +-
 drivers/gpu/drm/i915/gvt/gvt.h  |  14 +-
 drivers/gpu/drm/i915/gvt/handlers.c |  38 +++--
 drivers/gpu/drm/i915/gvt/scheduler.c|   3 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |   8 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c|  11 +-
 drivers/gpu/drm/i915/i915_perf.c|   4 +-
 drivers/gpu/drm/i915/intel_color.c  |   1 +
 drivers/gpu/drm/i915/intel_panel.c  |   2 +-
 drivers/gpu/drm/msm/Kconfig  

[Bug 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #5 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
the system works with dpm=0.  I attached some info about the working system. 
Please note that I DO NOT use the amdgpu-pro kernel module, only its libraries

-- 
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 194899] triple fault while loading amdgpu on Cape Verde

[bugzilla-daemon]

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

Janpieter Sollie (janpieter.sol...@dommel.be) changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=196635

-- 
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 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

Janpieter Sollie (janpieter.sol...@dommel.be) changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=194899

-- 
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 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #4 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 257883
  --> https://bugzilla.kernel.org/attachment.cgi?id=257883=edit
working clinfo

clinfo output with amdgpu.dpm=0

-- 
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 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #3 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 257881
  --> https://bugzilla.kernel.org/attachment.cgi?id=257881=edit
working dmesg

dmesg with amdgpu.dpm=0 seems to intitialize the device correctly

-- 
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 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

在 2017/8/11 2:05, Sean Paul 写道:

On Thu, Aug 10, 2017 at 05:35:52PM +0800, Sandy Huang wrote:

Hi Sean Paul,
 Thanks for your review.

在 2017/8/10 3:58, Sean Paul 写道:

On Wed, Aug 09, 2017 at 06:00:59PM +0800, Sandy Huang wrote:

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
   drivers/gpu/drm/rockchip/Kconfig |   9 +
   drivers/gpu/drm/rockchip/Makefile|   1 +
   drivers/gpu/drm/rockchip/rockchip_lvds.c | 734 
+++
   drivers/gpu/drm/rockchip/rockchip_lvds.h | 112 +
   4 files changed, 856 insertions(+)
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h






diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..a4ad3f0
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c





+   lvds->drm_dev = drm_dev;
+   port = of_graph_get_port_by_id(dev->of_node, 1);
+   if (!port) {
+   dev_err(dev, "can't found port point, please init lvds panel 
port!\n");
+   return -EINVAL;
+   }
+
+   for_each_child_of_node(port, endpoint) {
+   remote = of_graph_get_remote_port_parent(endpoint);
+   if (!remote) {
+   dev_err(dev, "can't found panel node, please init!\n");
+   ret = -EINVAL;
+   goto err_put_port;
+   }
+   if (!of_device_is_available(remote)) {
+   of_node_put(remote);
+   remote = NULL;
+   continue;
+   }
+   break;
+   }
+   if (!remote) {
+   dev_err(dev, "can't found remote node, please init!\n");
+   ret = -EINVAL;
+   goto err_put_port;
+   }
+
+   lvds->panel = of_drm_find_panel(remote);
+   if (!lvds->panel)
+   lvds->bridge = of_drm_find_bridge(remote);


drm_of_find_panel_or_bridge()



because the lvds ports maybe connect to lvds-panel or connect to
rk1000(which is convert RGB to CVBS output), so i have to get the remote
port parent and check the status, and final get the active remote point.






lvds_panel: lvds-panel {
status = "disabled";
ports {
panel_in_lvds: endpoint {
remote-endpoint = <_out_panel>;
};
};
};

rk1000: rk1000@0xff00 {
status = "okay";
ports {
rk1000_in_lvds: endpoint {
remote-endpoint = <_out_panel>;
};
};
};

 {
status = "okay";
ports {
lvds_out: port@1 {
reg = <1>;
lvds_out_panel: endpoint@0 {
reg = <0>;
remote-endpoint = <_in_lvds>;
};
lvds_out_rk1000: endpoint@1 {
reg = <1>;
remote-endpoint = <_in_lvds>;
};
};

};
};


Hi Sandy,
Forgive me, this is probably a stupid question. I don't see how this usecase is
unique from the other users of drm_of_find_panel_or_bridge. Couldn't you change
your devicetree bindings to conform to something drm_of_find_panel_or_bridge()
can work with?

Thank you,


Hi sean,
Maybe i can use the following method to use 
drm_of_find_panel_or_bridge() and no need to change my DT, but there is 
another question:

The LVDS output format(rockchip,output、rockchip,data-mapping etc.)
depend on different panel, so it should be put under remote panel point.
If use drm_of_find_panel_or_bridge（), this just return panel or bridge, 
so i have to back to get remote panel point and get the output format.


ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, >panel,
  >bridge);
if (ret)
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 1, >panel,
  >bridge);
if (ret) {
DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n");
ret  = -EPROBE_DEFER;
goto err_put_remote;
}


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

Re: [PATCHv5 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Ong, Hean Loong]

On Thu, 2017-08-10 at 11:59 -0500, Rob Herring wrote:
> On Thu, Aug 03, 2017 at 01:01:34PM +0800, Hean Loong, Ong wrote:
> > 
> > From: Ong Hean Loong 
> I take back my ack...
> 
> Laurent's comments on v4 are not addressed.
> 
Noted.
> > 
> > Device tree binding for Intel FPGA Video and Image
> > Processing Suite. The binding involved would be generated
> > from the Altera (Intel) Qsys system. The bindings would
> > set the max width, max height, buts per pixel and memory
> > port width. The device tree binding only supports the Intel
> > Arria10 devkit and its variants. Vendor name retained as
> > altr.
> > 
> > Signed-off-by: Ong, Hean Loong 
> > ---
> >  .../devicetree/bindings/display/altr,vip-fb2.txt   | 39
> > ++
> >  1 file changed, 39 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/altr,vip-
> > fb2.txt b/Documentation/devicetree/bindings/display/altr,vip-
> > fb2.txt
> > new file mode 100644
> > index 000..c4338d9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> > @@ -0,0 +1,39 @@
> > +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> > +
> > +Supported hardware: Arria 10 and above with display port IP
> > +
> > +The hardware associated with this device tree is a SoC FPGA. Where
> > there is an ARM controller
> > +and a FPGA device. The ARM controller would host the Linux OS
> > while the FPGA device runs on its
> > +individual IP firmware. In the Intel VIP Frame Buffer II the ARM
> > controller would be
> > +driving data from the Linux OS to the FPGA device programmed with
> > the Frame Buffer II IP
> > +to render pixels to be streamed to the Display Port connector.
> Still referring to Linux as both Laurent and I pointed out.
> 
> Wrap your lines at <80 chars. This was fine before...
> 
> > 
> > +
> > +The Frame Buffer II device is a simple frame buffer device. The
> > device contains the display
> > +properties and the bridge or connector register. The output for
> > this device currently
> > +is a dedicated to a single Display Port. Currently the max
> > resolution supported is 1280 x 720 at
> > +60Hz.
> > +
> > +More information the FPGA video IP component can be acquired from
> > +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/li
> > terature/ug/ug_vip.pdf
> > +
> > +
> > +New bindings:
> > +=
> > +Required properties:
> > +
> > +- compatible: "altr,vip-frame-buffer-2.0"
> > +- reg: Physical base address and length of the framebuffer
> > controller's
> > +  registers.
> > +- altr,max-width: The width of the framebuffer in pixels.
> > +- altr,max-height: The height of the framebuffer in pixels.
> > +- altr,mem-port-width = the bus width of the avalon master port on
> > the frame reader
> > +
> > +Example:
> > +
> > +   dp_0_frame_buf: display-controller@10280 {
> > +   compatible = "altr,vip-frame-buffer-2.0";
> > +   reg = <0x0001 0x0280 0x0040>;
> > +   altr,max-width = <1280>;
> > +   altr,max-height = <720>;
> > +   altr,mem-port-width = <128>;
> > +   };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

[Emil Velikov]

On 10 August 2017 at 20:29, Joe Kniss  wrote:
> On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss  wrote:
>> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes  wrote:
>>>
>>> Den 09.08.2017 01.42, skrev Joe Kniss:

 Because all drivers currently use gem objects for framebuffer planes,
 the virtual create_handle() is not required.  This change adds a
 struct drm_gem_object *gems[4] field to drm_framebuffer and removes
 create_handle() function pointer from drm_framebuffer_funcs.  The
 corresponding *_create_handle() function is removed from each driver.

 In many cases this change eliminates a struct *_framebuffer object,
 as the only need for the derived struct is the addition of the gem
 object pointer.

 TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip

 Signed-off-by: Joe Kniss 
 ---
>>>
>>>
>>> Hi Joe,
>>>
>>> I'm also looking into adding gem objs to drm_framebuffer in this patch:
>>> [PATCH v2 01/22] drm: Add GEM backed framebuffer library
>>> https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
>>>
>>
>> Great.  There's only minimal overlap here.  I'll rebase this change on yours
>> once it's in.
>>
>>> [...]
>>>
 diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
 b/drivers/gpu/drm/drm_fb_cma_helper.c
 index ade319d10e70..f5f011b910b1 100644
 --- a/drivers/gpu/drm/drm_fb_cma_helper.c
 +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
 @@ -31,14 +31,9 @@
 #define DEFAULT_FBDEFIO_DELAY_MS 50
   -struct drm_fb_cma {
 -   struct drm_framebuffer  fb;
 -   struct drm_gem_cma_object   *obj[4];
 -};
 -
   struct drm_fbdev_cma {
 struct drm_fb_helperfb_helper;
 -   struct drm_fb_cma   *fb;
 +   struct drm_framebuffer  *fb;
>>>
>>>
>>> This fb pointer isn't necessary, since fb_helper already has one.
>>>
>
> So, looking deeper into this, it seems that the struct
> drm_framebuffer_funcs *fb_funcs is also redundant here?  In which case
> this whole struct can go...
>
I think you're spot on.

Perhaps the goal was to allow drivers to use separate funcs for fb vs fbdev?
Not sure how well that will fair, yet again, all current users use the
same funcs for both.

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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #51 from Alex Perez  ---
This is still happening with kernel 4.13-rc4, with both a polaris 11 based
RX460, as well as a Cape Verde PRO.

In my case, it's on a BE ppc64 machine (e5500-based ppc64 SoC,
Freescale-manufactured)

-- 
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 v4 2/5] dt-bindings: add binding for Sitronix ST7586 display panels

[Rob Herring]

On Mon, Aug 07, 2017 at 12:39:38PM -0500, David Lechner wrote:
> This adds a new binding for Sitronix ST7586 display panels.
> 
> Using lego as the vendor prefix in the compatible string because the display
> panel I am working with is an integral part of the LEGO MINDSTORMS EV3.
> 
> Signed-off-by: David Lechner 
> ---
> 
> v4 changes:
> * Dropped optional properties and only use pins actually used on LEGO EV3.
> * Rename dc to a0 since that is what is on the datasheet/LEGO schematic.
> 
> 
>  .../bindings/display/sitronix,st7586.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sitronix,st7586.txt

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

Re: [PATCH] drm: Support drivers with threaded irqs

[kbuild test robot]

Hi Thomas,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.13-rc4 next-20170810]
[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/Sinclair-Yeh/drm-Support-drivers-with-threaded-irqs/20170811-025749
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:687: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:687: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2080: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2080: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/wait.h:555: warning: No description found for parameter 'wq'
   include/linux/wait.h:555: warning: Excess function parameter 'wq_head' 
description in 'wait_event_interruptible_hrtimeout'
   include/linux/wait.h:759: warning: No description found for parameter 
'wq_head'
   include/linux/wait.h:759: warning: Excess function parameter 'wq' 
description in 'wait_event_killable'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:968: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/sync_file.h:51: warning: No description found for parameter 
'flags'
   include/linux/iio/iio.h:603: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/ata/libata-eh.c:1449: warning: No description found for parameter 
'link'
   drivers/ata/libata-eh.c:1449: warning: Excess function parameter 'ap' 
description in 'ata_eh_done'
   drivers/ata/libata-eh.c:1590: warning: No description found for parameter 
'qc'
   drivers/ata/libata-eh.c:1590: warning: Excess function parameter 'dev' 
description in 'ata_eh_request_sense'
   drivers/mtd/nand/nand_base.c:2751: warning: Excess function parameter 
'cached' description in 'nand_write_page'
   drivers/mtd/nand/nand_base.c:2751: warning: Excess function parameter 
'cached' description in 'nand_write_page'
   arch/s390/include/asm/cmb.h:1: warning: no structured comments found
   drivers/scsi/scsi_lib.c:1116: warning: No description found for parameter 
'rq'
   drivers/scsi/constants.c:1: warning: no structured comments found
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:412: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:412: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:412: warning: No description found for parameter 
'quirk_zlp_not_supp'
   fs/inode.c:1666: warning: No description found for parameter 'rcu'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_transaction'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_next_transaction'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_list'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_vfs_inode'
   include/linux/jbd2.h:443: warning: No description found for parameter 
'i_flags'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_rsv_handle'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_reserved'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_type'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_line_no'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_start_jiffies'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'h_requested_credits'
   include/linux/jbd2.h:497: warning: No description found for parameter 
'saved_alloc_context'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_chkpt_bhs'
   include/linux/jbd2.h:1050: warning: No description found for parameter 
'j_devname'
   include/linux/jbd2.h:1050: warning: No description found for par

Re: [PATCH] drm: Shift wrap bug in create_in_format_blob()

[Dan Carpenter]

On Wed, Aug 09, 2017 at 03:38:33PM +0100, Daniel Stone wrote:
> On 9 August 2017 at 15:36, Sean Paul  wrote:
> > On Wed, Aug 09, 2017 at 02:19:06PM +0300, Dan Carpenter wrote:
> >> "plane->format_count" can go up to 64.  (It's capped in
> >> drm_universal_plane_init().)  So we should be using ULL type instead of
> >> int here to prevent shift wrapping.
> >>
> >> Fixes: db1689aa61bd ("drm: Create a format/modifier blob")
> >> Signed-off-by: Dan Carpenter 
> >
> > Thank you for the fix, Dan.
> >
> > I've applied it to drm-misc-next.
> 
> Yes, thanks Dan!
> 
> Out of interest, how was this found? With sparse?
> 

These are Smatch checks that I haven't totally cleaned up enough to
publish yet.  I have a couple versions of this check.  This one is doing
cross function analysis so it knows that ->format_count can go up to 64
bits.

regards,
dan carpenter

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

Re: [PATCH v2 21/29] drm/rockchip: switch to drm_*_get(), drm_*_put() helpers

[Sean Paul]

On Thu, Aug 10, 2017 at 3:52 PM, Cihangir Akturk  wrote:
> On Thu, Aug 10, 2017 at 02:16:08PM -0400, Sean Paul wrote:
>> On Thu, Aug 10, 2017 at 03:10:04PM +0300, Cihangir Akturk wrote:
>> > Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference()
>> > and drm_*_unreference() helpers.
>> >
>> > drm_*_reference() and drm_*_unreference() functions are just
>> > compatibility alias for drm_*_get() and drm_*_put() and should not be
>> > used by new code. So convert all users of compatibility functions to
>> > use the new APIs.
>> >
>> > Generated by: scripts/coccinelle/api/drm-get-put.cocci
>> >
>> > Signed-off-by: Cihangir Akturk 
>>
>> Hi Cihangir,
>> Thank you for the patch. Unfortunately it does not apply to drm-misc-next. 
>> Could
>> you please resend with conflicts resolved?
>
> OK, I'll send a v3 based on drm-next.

*drm-misc-next

> And should I drop patches from
> v1 already pulled in drm-next?
>

yes please

Sean


> Thanks, Cihangir
>
>>
>> Thanks,
>>
>> Sean
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] drm/amdgpu: add new low overhead command submission API. (v2)

[Dave Airlie]

On 10 August 2017 at 23:56, Emil Velikov  wrote:
> Hi Dave,
>
> On 18 July 2017 at 04:52, Dave Airlie  wrote:
>
>> +int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
>> +amdgpu_context_handle context,
>> +amdgpu_bo_list_handle bo_list_handle,
>> +int num_chunks,
>> +struct drm_amdgpu_cs_chunk *chunks,
>> +uint64_t *seq_no)
>> +{
>> +   union drm_amdgpu_cs cs = {0};
>> +   uint64_t *chunk_array;
>> +   int i, r;
>> +   if (num_chunks == 0)
>> +   return -EINVAL;
>> +
>> +   chunk_array = alloca(sizeof(uint64_t) * num_chunks);
> Out of curiosity:
> Does malloc/free produce noticeable overhead that lead you you alloca?

The preexisting code for these ioctls used alloca so I just followed
the existing pattern.

I doubt we'd notice malloc/free, but we shouldn't also be sending more
than 5-10 chunks
even in the future, so stack alloc should be fine.

> num_chunks is signed - should we bail on negative values, can we make
> it unsigned?

Possibly, I don't see random users of this API appearing though, but yeah could
change the if <= 0.

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

Re: [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

[Joe Kniss]

On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss  wrote:
> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes  wrote:
>>
>> Den 09.08.2017 01.42, skrev Joe Kniss:
>>>
>>> Because all drivers currently use gem objects for framebuffer planes,
>>> the virtual create_handle() is not required.  This change adds a
>>> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
>>> create_handle() function pointer from drm_framebuffer_funcs.  The
>>> corresponding *_create_handle() function is removed from each driver.
>>>
>>> In many cases this change eliminates a struct *_framebuffer object,
>>> as the only need for the derived struct is the addition of the gem
>>> object pointer.
>>>
>>> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
>>>
>>> Signed-off-by: Joe Kniss 
>>> ---
>>
>>
>> Hi Joe,
>>
>> I'm also looking into adding gem objs to drm_framebuffer in this patch:
>> [PATCH v2 01/22] drm: Add GEM backed framebuffer library
>> https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
>>
>
> Great.  There's only minimal overlap here.  I'll rebase this change on yours
> once it's in.
>
>> [...]
>>
>>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>>> b/drivers/gpu/drm/drm_fb_cma_helper.c
>>> index ade319d10e70..f5f011b910b1 100644
>>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>>> @@ -31,14 +31,9 @@
>>> #define DEFAULT_FBDEFIO_DELAY_MS 50
>>>   -struct drm_fb_cma {
>>> -   struct drm_framebuffer  fb;
>>> -   struct drm_gem_cma_object   *obj[4];
>>> -};
>>> -
>>>   struct drm_fbdev_cma {
>>> struct drm_fb_helperfb_helper;
>>> -   struct drm_fb_cma   *fb;
>>> +   struct drm_framebuffer  *fb;
>>
>>
>> This fb pointer isn't necessary, since fb_helper already has one.
>>

So, looking deeper into this, it seems that the struct
drm_framebuffer_funcs *fb_funcs is also redundant here?  In which case
this whole struct can go...

>
> I'll remove it... but I am sure when I look deeper there will be more
> of these in the various drivers too.
>
>> Noralf.
>>
>>
>
> -joe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: RCU syncobj

[Chris Wilson]

The first contention point we hit using syncobjs from concurrent
threads is the spinlock guarding drm_syncobj_find(). We use an RCU-safe
idr to store the syncobj, so if we employ RCU to free drm_syncobj and be
careful in acquiring the reference (as we may now observe zombie
synocbjs in the idr) we can do a lockless drm_syncobj_find().

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_syncobj.c | 10 +-
 include/drm/drm_syncobj.h |  2 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 38eca783a78c..cb5de50174ed 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -69,14 +69,14 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file 
*file_private,
 {
struct drm_syncobj *syncobj;
 
-   spin_lock(_private->syncobj_table_lock);
+   rcu_read_lock();
 
/* Check if we currently have a reference on the object */
syncobj = idr_find(_private->syncobj_idr, handle);
-   if (syncobj)
-   drm_syncobj_get(syncobj);
+   if (syncobj && !kref_get_unless_zero(>refcount))
+   syncobj = NULL;
 
-   spin_unlock(_private->syncobj_table_lock);
+   rcu_read_unlock();
 
return syncobj;
 }
@@ -151,7 +151,7 @@ void drm_syncobj_free(struct kref *kref)
syncobj_notify(syncobj, NULL);
 
dma_fence_put(syncobj->fence);
-   kfree(syncobj);
+   kfree_rcu(syncobj, rcu);
 }
 EXPORT_SYMBOL(drm_syncobj_free);
 
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index b8f60d6793fb..88c949d2cb34 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -56,6 +56,8 @@ struct drm_syncobj {
 * a file backing for this syncobj.
 */
struct file *file;
+
+   struct rcu_head rcu;
 };
 
 void drm_syncobj_free(struct kref *kref);
-- 
2.13.3

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

Re: [PATCH 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Sean Paul]

On Tue, Jul 11, 2017 at 03:30:09PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.

Hi Hans,
Thank you for the patch, it looks great, I just have a few minor nits below. 

> 
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this capability actually hook up the CEC pin, so
> even though a CEC device is created, it may not actually work.

Boo :(

> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/Kconfig  |  10 ++
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_dp_cec.c | 308 
> +++
>  include/drm/drm_dp_helper.h  |  24 
>  4 files changed, 343 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83cb2a88c204..1f2708df5c4e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
> default case is N. Details and instructions how to build your own
> EDID data are given in Documentation/EDID/HOWTO.txt.
>  
> +config DRM_DP_CEC
> + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + select CEC_CORE
> + help
> +   Choose this option if you want to enable HDMI CEC support for
> +   DisplayPort/USB-C to HDMI adapters.
> +
> +   Note: not all adapters support this feature, and even for those
> +   that do support this they often do not hook up the CEC pin.
> +
>  config DRM_TTM
>   tristate
>   depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 24a066e1841c..c6552c62049e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
> drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
>  
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> new file mode 100644
> index ..7f2e298d45c0
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -0,0 +1,308 @@
> +/*
> + * DisplayPort CEC-Tunneling-over-AUX support
> + *
> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * 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 AUTHORS OR COPYRIGHT HOLDERS
> + * 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 
> +
> +/*
> + * Unfortunately it turns out that we have a chicken-and-egg situation
> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC
> + * useless.
> + *
> + * Sadly there is no way for this driver to know this. What happens is
> + * that a /dev/cecX device is created that is isolated and unable to see
> + * any of the other CEC devices. Quite literally the CEC wire is cut
> + * (or in this case, never connected in the first place).
> + *
> + * I suspect that the reason so few adapters support this is that this
> + * tunneling protocol was never supported by any OS. So there was no
> + * easy way of testing it, and no incentive to correctly wire up the
> + * CEC pin.
> + *
> + * Hopefully by creating this driver it will be easier for vendors to
> + * finally fix their adapters and test the CEC functionality.
> + *
> + * I keep a list of known working adapters here:
> + *
> + * https://hverkuil.home.xs4all.nl/cec-status.txt
> + *
> + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> + * and is not yet listed there.

According to the schematics, the Google USB-C -> HDMI adapter[1] has CEC wired
up.

[1]- https://store.google.com/product/usb_type_c_to_hdmi_adapter

> + */
> +
> +/**
> + * DOC: dp cec helpers
> + *
> + * These functions take care of supporting 

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Christian König]

Am 10.08.2017 um 20:50 schrieb Chris Wilson:

Quoting Christian König (2017-08-10 19:19:52)

Am 10.08.2017 um 19:11 schrieb Chris Wilson:

Quoting Alex Deucher (2017-08-10 18:01:49)

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

I'm still puzzling over this one.

Setting an exclusive fence will clear all shared, so we must have added
the shared fences after the exclusive fence. But those shared fences must
follow the exclusive fence, you should not be able to reorder the shared
fences ahead of the exclusive. If you have completed shared fences, but
incomplete exclusive, doesn't that imply you have an ordering issue?

No, that is not an ordering issue.

The problem happens when the shared fences are "aborted" because of a
GPU reset.

See the exclusive fence is often a DMA moving bytes on behalf of the
kernel while the shared fences are the actual command submission from
user space.

What can happen is that the userspace process is killed and/or it's
scheduled command submission aborted for other reasons.

In this case the shared fences get an error code, are set to the
signaled state and the job they represent is never executed.

I didn't allow the GPU reset to cause fences to appear to complete out
of order, just rewrote them so they would be skipped (with the error
status flagged) if the error was terminal but still update the hw
semaphore and breadcrumbs (i.e. the user portion was cancel, but our
bookkeeping was left intact).


Well again, they don't signal out of order. The exclusive fence and the 
shared fence which is aborted belong to completely independent contexts 
(and can even belong to completely independent hardware).


It's just that the job which should trigger the shared fence never gets 
executed.


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

Re: [PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

[Chris Wilson]

Quoting Jason Ekstrand (2017-08-10 01:31:52)
> 
> 
> On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson  wrote:
> 
> Quoting Jason Ekstrand (2017-08-08 23:46:02)
> > The atomic exchange operation we were doing before in replace_fence was
> > sufficient for the case where it raced with itself.  However, if you
> > have a race between a replace_fence and dma_fence_get(syncobj->fence),
> > you may end up with the entire replace_fence happening between the point
> > in time where the one thread gets the syncobj->fence pointer and when it
> > calls dma_fence_get() on it.  If this happens, then the reference may be
> > dropped before we get a chance to get a new one.
> 
> This doesn't require a spinlock, just dma_fence_get_rcu_safe(). The
> argument for keeping this patch lies in the merit of later patches..
> 
> 
> Doesn't that also require that we start using an RCU for syncobj?  That was my
> interpretation of the hieroglyphics above the definition of get_rcu_safe()

Interesting you mention RCUing syncobj... The spinlock in
drm_syncobj_find() is the first contention point we hit. If we do make
syncobj RCU'ed we can avoid that lock.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 02/22] drm/fb-cma-helper: Use drm_gem_framebuffer_helper

[Noralf Trønnes]

Den 09.08.2017 22.07, skrev Daniel Vetter:

On Wed, Aug 09, 2017 at 12:11:05PM +0200, Noralf Trønnes wrote:

Use the new drm_gem_framebuffer_helper who's code was copied
from this helper.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_cma_helper.c | 172 +++-
  1 file changed, 30 insertions(+), 142 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index ade319d..d0c0110 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,27 +18,17 @@
   */
  
  #include 

-#include 
-#include 
  #include 
-#include 
+#include 
  #include 
+#include 
  #include 
-#include 
-#include 
  #include 
-#include 
  
  #define DEFAULT_FBDEFIO_DELAY_MS 50
  
-struct drm_fb_cma {

-   struct drm_framebuffer  fb;
-   struct drm_gem_cma_object   *obj[4];
-};
-
  struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
-   struct drm_fb_cma   *fb;
const struct drm_framebuffer_funcs *fb_funcs;
  };
  
@@ -90,69 +80,19 @@ static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)

return container_of(helper, struct drm_fbdev_cma, fb_helper);
  }
  
-static inline struct drm_fb_cma *to_fb_cma(struct drm_framebuffer *fb)

-{
-   return container_of(fb, struct drm_fb_cma, fb);
-}
-
  void drm_fb_cma_destroy(struct drm_framebuffer *fb)
  {
-   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
-   int i;
-
-   for (i = 0; i < 4; i++) {
-   if (fb_cma->obj[i])
-   drm_gem_object_put_unlocked(_cma->obj[i]->base);
-   }
-
-   drm_framebuffer_cleanup(fb);
-   kfree(fb_cma);
+   drm_gem_fb_destroy(fb);
  }
  EXPORT_SYMBOL(drm_fb_cma_destroy);
  
  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,

struct drm_file *file_priv, unsigned int *handle)
  {
-   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
-
-   return drm_gem_handle_create(file_priv,
-   _cma->obj[0]->base, handle);
+   return drm_gem_fb_create_handle(fb, file_priv, handle);
  }
  EXPORT_SYMBOL(drm_fb_cma_create_handle);
  
-static struct drm_framebuffer_funcs drm_fb_cma_funcs = {

-   .destroy= drm_fb_cma_destroy,
-   .create_handle  = drm_fb_cma_create_handle,
-};
-
-static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
-   const struct drm_mode_fb_cmd2 *mode_cmd,
-   struct drm_gem_cma_object **obj,
-   unsigned int num_planes, const struct drm_framebuffer_funcs *funcs)
-{
-   struct drm_fb_cma *fb_cma;
-   int ret;
-   int i;
-
-   fb_cma = kzalloc(sizeof(*fb_cma), GFP_KERNEL);
-   if (!fb_cma)
-   return ERR_PTR(-ENOMEM);
-
-   drm_helper_mode_fill_fb_struct(dev, _cma->fb, mode_cmd);
-
-   for (i = 0; i < num_planes; i++)
-   fb_cma->obj[i] = obj[i];
-
-   ret = drm_framebuffer_init(dev, _cma->fb, funcs);
-   if (ret) {
-   dev_err(dev->dev, "Failed to initialize framebuffer: %d\n", 
ret);
-   kfree(fb_cma);
-   return ERR_PTR(ret);
-   }
-
-   return fb_cma;
-}
-
  /**
   * drm_fb_cma_create_with_funcs() - helper function for the
   *  _mode_config_funcs.fb_create
@@ -170,53 +110,7 @@ struct drm_framebuffer 
*drm_fb_cma_create_with_funcs(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
const struct drm_framebuffer_funcs *funcs)
  {
-   const struct drm_format_info *info;
-   struct drm_fb_cma *fb_cma;
-   struct drm_gem_cma_object *objs[4];
-   struct drm_gem_object *obj;
-   int ret;
-   int i;
-
-   info = drm_get_format_info(dev, mode_cmd);
-   if (!info)
-   return ERR_PTR(-EINVAL);
-
-   for (i = 0; i < info->num_planes; i++) {
-   unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
-   unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
-   unsigned int min_size;
-
-   obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
-   if (!obj) {
-   dev_err(dev->dev, "Failed to lookup GEM object\n");
-   ret = -ENOENT;
-   goto err_gem_object_put;
-   }
-
-   min_size = (height - 1) * mode_cmd->pitches[i]
-+ width * info->cpp[i]
-+ mode_cmd->offsets[i];
-
-   if (obj->size < min_size) {
-   drm_gem_object_put_unlocked(obj);
-   ret = -EINVAL;
-   goto err_gem_object_put;
-   }
-   objs[i] = to_drm_gem_cma_obj(obj);
-   }
-
-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
-   if (IS_ERR(fb_cma)) {
-   ret = PTR_ERR(fb_cma);
- 

Re: [PATCH v2 01/22] drm: Add GEM backed framebuffer library

[Noralf Trønnes]

Den 09.08.2017 22.04, skrev Daniel Vetter:

On Wed, Aug 09, 2017 at 12:11:04PM +0200, Noralf Trønnes wrote:

This library provides helpers for drivers that don't subclass
drm_framebuffer and are backed by drm_gem_object. The code is
taken from drm_fb_cma_helper.

Signed-off-by: Noralf Trønnes 

lgtm, a few nits below to polish the documentation. With those addressed:

Reviewed-by: Daniel Vetter 


[...]


+/**
+ * drm_gem_fb_alloc - Allocate GEM backed framebuffer
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ * @obj: GEM object(s) backing the framebuffer
+ * @num_planes: Number of planes
+ * @funcs: vtable to be used for the new framebuffer object

This kinda puts all the warnings from drm_framebuffer_init() under the
rug, so not enough text for such a tricky function. Proposal

"This allocates a  drm_framebuffer and publishes it by calling
drm_framebuffer_init().

IMPORTANT:
All checking and validation must be done before calling this function.
Framebuffers are supposed to be invariant over their lifetime, which means
evil userspace could otherwise trick the kernel into using unvalidated
framebuffer objects."

Not sure whether that kills your use-cases for this, in which case we
probably need to open-code this in all callers. Or remove the call to
drm_framebuffer_init() and place the driver's validation code between the
call to _alloc() and _init().

Maybe we should even change _init() to be called _register() to avoid this
bug in the future.


The only reason drm_gem_fb_alloc() is exported is to add framebuffers
for fbdev emulation. So maybe it's better to hide that function and make
an explicit one:

/**
 * drm_gem_fbdev_fb_create - Create a drm_framebuffer for fbdev emulation
 * @dev: DRM device
 * @sizes: fbdev size description
 * @pitch_align: optional pitch alignment
 * @obj: GEM object backing the framebuffer
 * @funcs: vtable to be used for the new framebuffer object
 *
 * This function creates a framebuffer for use with fbdev emulation.
 *
 * Returns:
 * Pointer to a drm_framebuffer on success or an error pointer on failure.
 */
struct drm_framebuffer *
drm_gem_fbdev_fb_create(struct drm_device *dev,
struct drm_fb_helper_surface_size *sizes,
unsigned int pitch_align, struct drm_gem_object *obj,
const struct drm_framebuffer_funcs *funcs)
{
struct drm_mode_fb_cmd2 mode_cmd = { 0 };

mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
mode_cmd.pitches[0] = sizes->surface_width *
  DIV_ROUND_UP(sizes->surface_bpp, 8);
if (pitch_align)
mode_cmd.pitches[0] = roundup(mode_cmd.pitches[0],
  pitch_align);
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
if (obj->size < mode_cmd.pitches[0] * mode_cmd.height)
return ERR_PTR(-EINVAL);

return drm_gem_fb_alloc(dev, _cmd, , 1, funcs);
}
EXPORT_SYMBOL(drm_gem_fbdev_fb_create);


Noralf.


But that's just all aside, from your create_with_funcs example below it
all looks good.


+ *
+ * Returns:
+ * Allocated struct drm_framebuffer * or error encoded pointer.
+ */
+struct drm_framebuffer *
+drm_gem_fb_alloc(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *mode_cmd,
+struct drm_gem_object **obj, unsigned int num_planes,
+const struct drm_framebuffer_funcs *funcs)
+{
+   struct drm_framebuffer *fb;
+   int ret, i;
+
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
+   return ERR_PTR(-ENOMEM);
+
+   drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
+
+   for (i = 0; i < num_planes; i++)
+   fb->obj[i] = obj[i];
+
+   ret = drm_framebuffer_init(dev, fb, funcs);
+   if (ret) {
+   DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
+ ret);
+   kfree(fb);
+   return ERR_PTR(ret);
+   }
+
+   return fb;
+}
+EXPORT_SYMBOL(drm_gem_fb_alloc);
+
+/**
+ * drm_gem_fb_destroy - Free GEM backed framebuffer
+ * @fb: DRM framebuffer
+ *
+ * Frees a GEM backed framebuffer with it's backing buffer(s) and the structure
+ * itself. Drivers can use this as their _framebuffer_funcs->destroy
+ * callback.
+ */
+void drm_gem_fb_destroy(struct drm_framebuffer *fb)
+{
+   int i;
+
+   for (i = 0; i < 4; i++) {
+   if (fb->obj[i])
+   drm_gem_object_put_unlocked(fb->obj[i]);
+   }
+
+   drm_framebuffer_cleanup(fb);
+   kfree(fb);
+}
+EXPORT_SYMBOL(drm_gem_fb_destroy);
+
+/**
+ * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
+ * @fb: DRM framebuffer
+ * @file: drm file
+ * @handle: handle created
+ *
+ * Drivers can use this as their _framebuffer_funcs->create_handle
+ * callback.
+ *
+ * Returns:
+ * 0 on success or a 

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Chris Wilson]

Quoting Christian König (2017-08-10 19:19:52)
> Am 10.08.2017 um 19:11 schrieb Chris Wilson:
> > Quoting Alex Deucher (2017-08-10 18:01:49)
> >> From: Christian König 
> >>
> >> With hardware resets in mind it is possible that all shared fences are
> >> signaled, but the exlusive isn't. Fix waiting for everything in this 
> >> situation.
> > I'm still puzzling over this one.
> >
> > Setting an exclusive fence will clear all shared, so we must have added
> > the shared fences after the exclusive fence. But those shared fences must
> > follow the exclusive fence, you should not be able to reorder the shared
> > fences ahead of the exclusive. If you have completed shared fences, but
> > incomplete exclusive, doesn't that imply you have an ordering issue?
> 
> No, that is not an ordering issue.
> 
> The problem happens when the shared fences are "aborted" because of a 
> GPU reset.
> 
> See the exclusive fence is often a DMA moving bytes on behalf of the 
> kernel while the shared fences are the actual command submission from 
> user space.
> 
> What can happen is that the userspace process is killed and/or it's 
> scheduled command submission aborted for other reasons.
> 
> In this case the shared fences get an error code, are set to the 
> signaled state and the job they represent is never executed.

I didn't allow the GPU reset to cause fences to appear to complete out
of order, just rewrote them so they would be skipped (with the error
status flagged) if the error was terminal but still update the hw
semaphore and breadcrumbs (i.e. the user portion was cancel, but our
bookkeeping was left intact).
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/22] drm: Add GEM backed framebuffer library

[Joe Kniss]

A few nits.

On Wed, Aug 9, 2017 at 3:12 AM,
 wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
>
> Today's Topics:
>
>1. [PATCH v2 06/22] drm/arm/mali: Use drm_gem_fb_create()
>   (Noralf Trønnes)
>2. [PATCH v2 01/22] drm: Add GEM backed framebuffer library
>   (Noralf Trønnes)
>3. [PATCH v2 04/22] drm/arc: Use drm_gem_fb_create()
>   (Noralf Trønnes)
>4. [PATCH v2 09/22] drm/hisilicon/kirin: Use drm_gem_fb_create()
>   (Noralf Trønnes)
>5. [PATCH v2 03/22] drm/tinydrm: Use drm_gem_framebuffer_helper
>   (Noralf Trønnes)
>6. [PATCH v2 05/22] drm/arm/hdlcd: Use drm_gem_fb_create()
>   (Noralf Trønnes)
>
>
> --
>
> Message: 1
> Date: Wed,  9 Aug 2017 12:11:09 +0200
> From: Noralf Trønnes 
> To: dri-devel@lists.freedesktop.org
> Cc: narmstr...@baylibre.com, liviu.du...@arm.com,
> laurent.pinch...@ideasonboard.com, ma...@denx.de,
> boris.brezil...@free-electrons.com, abrod...@synopsys.com,
> z.liuxinli...@hisilicon.com, kong.kongxin...@hisilicon.com,
> tomi.valkei...@ti.com, puck.c...@hisilicon.com, jsa...@ti.com,
> vincent.abr...@st.com, alison.w...@freescale.com,
> philippe.co...@st.com, yannick.fer...@st.com, zourongr...@gmail.com,
> maxime.rip...@free-electrons.com, shawn...@kernel.org
> Subject: [PATCH v2 06/22] drm/arm/mali: Use drm_gem_fb_create()
> Message-ID: <1502273485-62636-7-git-send-email-nor...@tronnes.org>
> Content-Type: text/plain; charset=UTF-8
>
> drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now,
> so use the function directly.
>
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 1a57cc2..b894466 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "malidp_drv.h"
> @@ -249,7 +250,7 @@ static const struct drm_mode_config_helper_funcs 
> malidp_mode_config_helpers = {
>  };
>
>  static const struct drm_mode_config_funcs malidp_mode_config_funcs = {
> -   .fb_create = drm_fb_cma_create,
> +   .fb_create = drm_gem_fb_create,
> .output_poll_changed = malidp_output_poll_changed,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> --
> 2.7.4
>
>
>
> --
>
> Message: 2
> Date: Wed,  9 Aug 2017 12:11:04 +0200
> From: Noralf Trønnes 
> To: dri-devel@lists.freedesktop.org
> Cc: narmstr...@baylibre.com, liviu.du...@arm.com,
> laurent.pinch...@ideasonboard.com, ma...@denx.de,
> boris.brezil...@free-electrons.com, abrod...@synopsys.com,
> z.liuxinli...@hisilicon.com, kong.kongxin...@hisilicon.com,
> tomi.valkei...@ti.com, puck.c...@hisilicon.com, jsa...@ti.com,
> vincent.abr...@st.com, alison.w...@freescale.com,
> philippe.co...@st.com, yannick.fer...@st.com, zourongr...@gmail.com,
> maxime.rip...@free-electrons.com, shawn...@kernel.org
> Subject: [PATCH v2 01/22] drm: Add GEM backed framebuffer library
> Message-ID: <1502273485-62636-2-git-send-email-nor...@tronnes.org>
> Content-Type: text/plain; charset=UTF-8
>
> This library provides helpers for drivers that don't subclass
> drm_framebuffer and are backed by drm_gem_object. The code is
> taken from drm_fb_cma_helper.
>
> Signed-off-by: Noralf Trønnes 
> ---
>  Documentation/gpu/drm-kms-helpers.rst|   9 +
>  drivers/gpu/drm/Makefile |   2 +-
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 252 
> +++
>  include/drm/drm_framebuffer.h|   4 +
>  include/drm/drm_gem_framebuffer_helper.h |  35 
>  5 files changed, 301 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_gem_framebuffer_helper.c
>  create mode 100644 include/drm/drm_gem_framebuffer_helper.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 7c5e254..13dd237 100644
> --- 

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Christian König]

Am 10.08.2017 um 19:11 schrieb Chris Wilson:

Quoting Alex Deucher (2017-08-10 18:01:49)

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

I'm still puzzling over this one.

Setting an exclusive fence will clear all shared, so we must have added
the shared fences after the exclusive fence. But those shared fences must
follow the exclusive fence, you should not be able to reorder the shared
fences ahead of the exclusive. If you have completed shared fences, but
incomplete exclusive, doesn't that imply you have an ordering issue?


No, that is not an ordering issue.

The problem happens when the shared fences are "aborted" because of a 
GPU reset.


See the exclusive fence is often a DMA moving bytes on behalf of the 
kernel while the shared fences are the actual command submission from 
user space.


What can happen is that the userspace process is killed and/or it's 
scheduled command submission aborted for other reasons.


In this case the shared fences get an error code, are set to the 
signaled state and the job they represent is never executed.


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

[PATCH libdrm] tests/amdgpu: add uvd encode unit tests

[boyuan.zhang]

From: Boyuan Zhang 

Signed-off-by: Boyuan Zhang 
---
 tests/amdgpu/Makefile.am |   1 +
 tests/amdgpu/amdgpu_test.c   |   6 +
 tests/amdgpu/amdgpu_test.h   |  15 ++
 tests/amdgpu/frame.h |   2 +-
 tests/amdgpu/uvd_enc_tests.c | 500 
 tests/amdgpu/uve_ib.h| 527 +++
 6 files changed, 1050 insertions(+), 1 deletion(-)
 create mode 100644 tests/amdgpu/uvd_enc_tests.c
 create mode 100644 tests/amdgpu/uve_ib.h

diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 9e08578..13b3dc8 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -27,4 +27,5 @@ amdgpu_test_SOURCES = \
vce_tests.c \
vce_ib.h \
frame.h \
+   uvd_enc_tests.c \
vcn_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 1d44b09..cd6b826 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -91,6 +91,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_vcn_tests_clean,
.pTests = vcn_tests,
},
+   {
+   .pName = "UVD ENC Tests",
+   .pInitFunc = suite_uvd_enc_tests_init,
+   .pCleanupFunc = suite_uvd_enc_tests_clean,
+   .pTests = uvd_enc_tests,
+   },
CU_SUITE_INFO_NULL,
 };
 
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index c75a07a..d0b61ba 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -120,6 +120,21 @@ int suite_vcn_tests_clean();
 extern CU_TestInfo vcn_tests[];
 
 /**
+ * Initialize uvd enc test suite
+ */
+int suite_uvd_enc_tests_init();
+
+/**
+ * Deinitialize uvd enc test suite
+ */
+int suite_uvd_enc_tests_clean();
+
+/**
+ * Tests in uvd enc test suite
+ */
+extern CU_TestInfo uvd_enc_tests[];
+
+/**
  * Helper functions
  */
 static inline amdgpu_bo_handle gpu_mem_alloc(
diff --git a/tests/amdgpu/frame.h b/tests/amdgpu/frame.h
index 4c946c2..335401c 100644
--- a/tests/amdgpu/frame.h
+++ b/tests/amdgpu/frame.h
@@ -24,7 +24,7 @@
 #ifndef _frame_h_
 #define _frame_h_
 
-const uint8_t frame[] = {
+static const uint8_t frame[] = {
0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 
0xeb, 0xeb, 0xeb, 0xeb,
0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xeb, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 
0xd2, 0xd2, 0xd2, 0xd2,
0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 
0xd2, 0xaa, 0xaa, 0xaa,
diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
new file mode 100644
index 000..6c19f7b
--- /dev/null
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -0,0 +1,500 @@
+/*
+ * 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.
+ *
+*/
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+
+#include "CUnit/Basic.h"
+
+#include "util_math.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+#include "frame.h"
+#include "uve_ib.h"
+
+#define IB_SIZE4096
+#define MAX_RESOURCES  16
+
+struct amdgpu_uvd_enc_bo {
+   amdgpu_bo_handle handle;
+   amdgpu_va_handle va_handle;
+   uint64_t addr;
+   uint64_t size;
+   uint8_t *ptr;
+};
+
+struct amdgpu_uvd_enc {
+   unsigned width;
+   unsigned height;
+   struct amdgpu_uvd_enc_bo session;
+   struct amdgpu_uvd_enc_bo vbuf;
+   struct amdgpu_uvd_enc_bo bs;
+   struct amdgpu_uvd_enc_bo fb;
+   struct amdgpu_uvd_enc_bo cpb;
+};
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+static uint32_t family_id;
+
+static amdgpu_context_handle context_handle;
+static amdgpu_bo_handle ib_handle;
+static amdgpu_va_handle ib_va_handle;
+static uint64_t ib_mc_address;
+static uint32_t 

Re: [PATCH v2 21/29] drm/rockchip: switch to drm_*_get(), drm_*_put() helpers

[Sean Paul]

On Thu, Aug 10, 2017 at 03:10:04PM +0300, Cihangir Akturk wrote:
> Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference()
> and drm_*_unreference() helpers.
> 
> drm_*_reference() and drm_*_unreference() functions are just
> compatibility alias for drm_*_get() and drm_*_put() and should not be
> used by new code. So convert all users of compatibility functions to
> use the new APIs.
> 
> Generated by: scripts/coccinelle/api/drm-get-put.cocci
> 
> Signed-off-by: Cihangir Akturk 

Hi Cihangir,
Thank you for the patch. Unfortunately it does not apply to drm-misc-next. Could
you please resend with conflicts resolved?

Thanks,

Sean

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 6 +++---
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c   | 4 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 81f9548..a933b58 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -48,7 +48,7 @@ static void rockchip_drm_fb_destroy(struct drm_framebuffer 
> *fb)
>   int i;
>  
>   for (i = 0; i < ROCKCHIP_MAX_FB_BUFFER; i++)
> - drm_gem_object_unreference_unlocked(rockchip_fb->obj[i]);
> + drm_gem_object_put_unlocked(rockchip_fb->obj[i]);
>  
>   drm_framebuffer_cleanup(fb);
>   kfree(rockchip_fb);
> @@ -144,7 +144,7 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
> drm_file *file_priv,
>   width * drm_format_plane_cpp(mode_cmd->pixel_format, i);
>  
>   if (obj->size < min_size) {
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>   ret = -EINVAL;
>   goto err_gem_object_unreference;
>   }
> @@ -161,7 +161,7 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
> drm_file *file_priv,
>  
>  err_gem_object_unreference:
>   for (i--; i >= 0; i--)
> - drm_gem_object_unreference_unlocked(objs[i]);
> + drm_gem_object_put_unlocked(objs[i]);
>   return ERR_PTR(ret);
>  }
>  
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
> index ce946b9..724579e 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
> @@ -173,7 +173,7 @@ void rockchip_drm_fbdev_fini(struct drm_device *dev)
>   drm_fb_helper_unregister_fbi(helper);
>  
>   if (helper->fb)
> - drm_framebuffer_unreference(helper->fb);
> + drm_framebuffer_put(helper->fb);
>  
>   drm_fb_helper_fini(helper);
>  }
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index b74ac71..9f880d0 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -383,7 +383,7 @@ rockchip_gem_create_with_handle(struct drm_file 
> *file_priv,
>   goto err_handle_create;
>  
>   /* drop reference from allocate - handle holds it now. */
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>  
>   return rk_obj;
>  
> @@ -414,7 +414,7 @@ int rockchip_gem_dumb_map_offset(struct drm_file 
> *file_priv,
>   DRM_DEBUG_KMS("offset = 0x%llx\n", *offset);
>  
>  out:
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 5d45033..12e17e6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1065,7 +1065,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
>   if (old_plane_state->fb == plane->state->fb)
>   continue;
>  
> - drm_framebuffer_reference(old_plane_state->fb);
> + drm_framebuffer_get(old_plane_state->fb);
>   drm_flip_work_queue(>fb_unref_work, old_plane_state->fb);
>   set_bit(VOP_PENDING_FB_UNREF, >pending);
>   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> @@ -1189,7 +1189,7 @@ static void vop_fb_unref_worker(struct drm_flip_work 
> *work, void *val)
>   struct drm_framebuffer *fb = val;
>  
>   drm_crtc_vblank_put(>crtc);
> - drm_framebuffer_unreference(fb);
> + drm_framebuffer_put(fb);
>  }
>  
>  static void vop_handle_vblank(struct vop *vop)
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 

Re: [PATCH 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sean Paul]

On Thu, Aug 10, 2017 at 05:35:52PM +0800, Sandy Huang wrote:
> Hi Sean Paul,
> Thanks for your review.
> 
> 在 2017/8/10 3:58, Sean Paul 写道:
> > On Wed, Aug 09, 2017 at 06:00:59PM +0800, Sandy Huang wrote:
> > > This adds support for Rockchip soc lvds found on rk3288
> > > Based on the patches from Mark yao and Heiko Stuebner
> > > 
> > > Signed-off-by: Sandy Huang 
> > > Signed-off-by: Mark yao 
> > > Signed-off-by: Heiko Stuebner 
> > > ---
> > >   drivers/gpu/drm/rockchip/Kconfig |   9 +
> > >   drivers/gpu/drm/rockchip/Makefile|   1 +
> > >   drivers/gpu/drm/rockchip/rockchip_lvds.c | 734 
> > > +++
> > >   drivers/gpu/drm/rockchip/rockchip_lvds.h | 112 +
> > >   4 files changed, 856 insertions(+)
> > >   create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
> > >   create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h
> > > 



> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
> > > b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> > > new file mode 100644
> > > index 000..a4ad3f0
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c



> > > + lvds->drm_dev = drm_dev;
> > > + port = of_graph_get_port_by_id(dev->of_node, 1);
> > > + if (!port) {
> > > + dev_err(dev, "can't found port point, please init lvds panel 
> > > port!\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + for_each_child_of_node(port, endpoint) {
> > > + remote = of_graph_get_remote_port_parent(endpoint);
> > > + if (!remote) {
> > > + dev_err(dev, "can't found panel node, please init!\n");
> > > + ret = -EINVAL;
> > > + goto err_put_port;
> > > + }
> > > + if (!of_device_is_available(remote)) {
> > > + of_node_put(remote);
> > > + remote = NULL;
> > > + continue;
> > > + }
> > > + break;
> > > + }
> > > + if (!remote) {
> > > + dev_err(dev, "can't found remote node, please init!\n");
> > > + ret = -EINVAL;
> > > + goto err_put_port;
> > > + }
> > > +
> > > + lvds->panel = of_drm_find_panel(remote);
> > > + if (!lvds->panel)
> > > + lvds->bridge = of_drm_find_bridge(remote);
> > 
> > drm_of_find_panel_or_bridge()
> > 
> 
> because the lvds ports maybe connect to lvds-panel or connect to
> rk1000(which is convert RGB to CVBS output), so i have to get the remote
> port parent and check the status, and final get the active remote point.
> 



> lvds_panel: lvds-panel {
>   status = "disabled";
>   ports {
>   panel_in_lvds: endpoint {
>   remote-endpoint = <_out_panel>;
>   };
>   };
> };
> 
> rk1000: rk1000@0xff00 {
>   status = "okay";
>   ports {
>   rk1000_in_lvds: endpoint {
>   remote-endpoint = <_out_panel>;
>   };
>   };
> };
> 
>  {
>   status = "okay";
>   ports {
>   lvds_out: port@1 {
>   reg = <1>;
>   lvds_out_panel: endpoint@0 {
>   reg = <0>;
>   remote-endpoint = <_in_lvds>;
>   };
>   lvds_out_rk1000: endpoint@1 {
>   reg = <1>;
>   remote-endpoint = <_in_lvds>;
>   };
>   };
> 
>   };
> };

Hi Sandy,
Forgive me, this is probably a stupid question. I don't see how this usecase is
unique from the other users of drm_of_find_panel_or_bridge. Couldn't you change
your devicetree bindings to conform to something drm_of_find_panel_or_bridge()
can work with?

Thank you,

Sean



> > > -- 
> > > 2.7.4
> > > 
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 
> -- 
> Best Regard
> 
> 黄家钗
> Sandy Huang
> 福州瑞芯微电子股份有限公司-图形与显示系统部门
> Fuzhou Rockchip Electronics Co.Ltd - Graphics & Display Dept.
> Addr: 福州市鼓楼区铜盘路软件大道89号福州软件园A区21号楼(350003)
>  No. 21 Building, A District, No.89,software Boulevard
> Fuzhou,Fujian,PRC
> Tel：+86 0591-87884919  8690
> E-mail：h...@rock-chips.com
> 

-- 
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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  ---
Not sure if it's an Alsa issue or not.  Just pointing out the relevant code to
aid in debugging.

-- 
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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

[bugzilla-daemon]

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

--- Comment #7 from Direx  ---
Thank you for the feedback. From Alex's comment I take that it actually should
be an ALSA issue (correct me if I am wrong). I also opened an ALSA bug, let's
see what the ALSA developers think about this:

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

-- 
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 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Chris Wilson]

Quoting Alex Deucher (2017-08-10 18:01:49)
> From: Christian König 
> 
> With hardware resets in mind it is possible that all shared fences are
> signaled, but the exlusive isn't. Fix waiting for everything in this 
> situation.

I'm still puzzling over this one.

Setting an exclusive fence will clear all shared, so we must have added
the shared fences after the exclusive fence. But those shared fences must
follow the exclusive fence, you should not be able to reorder the shared
fences ahead of the exclusive. If you have completed shared fences, but
incomplete exclusive, doesn't that imply you have an ordering issue?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] dma-buf changes for ttm and amdgpu

[Alex Deucher]

We have some changes in ttm and amdgpu that depend on these patches.
Sumit, can you pull these in via dma-buf or should I roll them up
through my amdgpu tree?

Christian König (3):
  dma-buf: dma_fence_put is NULL safe
  dma-buf: add reservation_object_copy_fences
  dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

 drivers/dma-buf/reservation.c | 97 +--
 include/linux/reservation.h   |  3 ++
 2 files changed, 78 insertions(+), 22 deletions(-)

-- 
2.5.5

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

[PATCH 1/2] dma-buf: add reservation_object_copy_fences (v2)

[Alex Deucher]

From: Christian König 

Allows us to copy all the fences in a reservation object to another one.

v2: handle NULL src_list

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/dma-buf/reservation.c | 60 +++
 include/linux/reservation.h   |  3 +++
 2 files changed, 63 insertions(+)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 87f8f57..d4881f9 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -262,6 +262,66 @@ void reservation_object_add_excl_fence(struct 
reservation_object *obj,
 EXPORT_SYMBOL(reservation_object_add_excl_fence);
 
 /**
+* reservation_object_copy_fences - Copy all fences from src to dst.
+* @dst: the destination reservation object
+* @src: the source reservation object
+*
+* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
+* held.
+*/
+int reservation_object_copy_fences(struct reservation_object *dst,
+  struct reservation_object *src)
+{
+   struct reservation_object_list *src_list, *dst_list;
+   struct dma_fence *old, *new;
+   size_t size;
+   unsigned i;
+
+   src_list = reservation_object_get_list(src);
+
+   if (src_list) {
+   size = offsetof(typeof(*src_list),
+   shared[src_list->shared_count]);
+   dst_list = kmalloc(size, GFP_KERNEL);
+   if (!dst_list)
+   return -ENOMEM;
+
+   dst_list->shared_count = src_list->shared_count;
+   dst_list->shared_max = src_list->shared_count;
+   for (i = 0; i < src_list->shared_count; ++i)
+   dst_list->shared[i] =
+   dma_fence_get(src_list->shared[i]);
+   } else {
+   dst_list = NULL;
+   }
+
+   kfree(dst->staged);
+   dst->staged = NULL;
+
+   src_list = reservation_object_get_list(dst);
+
+   old = reservation_object_get_excl(dst);
+   new = reservation_object_get_excl(src);
+
+   dma_fence_get(new);
+
+   preempt_disable();
+   write_seqcount_begin(>seq);
+   /* write_seqcount_begin provides the necessary memory barrier */
+   RCU_INIT_POINTER(dst->fence_excl, new);
+   RCU_INIT_POINTER(dst->fence, dst_list);
+   write_seqcount_end(>seq);
+   preempt_enable();
+
+   if (src_list)
+   kfree_rcu(src_list, rcu);
+   dma_fence_put(old);
+
+   return 0;
+}
+EXPORT_SYMBOL(reservation_object_copy_fences);
+
+/**
  * reservation_object_get_fences_rcu - Get an object's shared and exclusive
  * fences without update side lock held
  * @obj: the reservation object
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 156cfd3..21fc84d 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -254,6 +254,9 @@ int reservation_object_get_fences_rcu(struct 
reservation_object *obj,
  unsigned *pshared_count,
  struct dma_fence ***pshared);
 
+int reservation_object_copy_fences(struct reservation_object *dst,
+  struct reservation_object *src);
+
 long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 bool wait_all, bool intr,
 unsigned long timeout);
-- 
2.5.5

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

[PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Alex Deucher]

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

v2: make sure we always wait for the exclusive fence

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/dma-buf/reservation.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index d4881f9..dec3a81 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -431,12 +431,25 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
long ret = timeout ? timeout : 1;
 
 retry:
-   fence = NULL;
shared_count = 0;
seq = read_seqcount_begin(>seq);
rcu_read_lock();
 
-   if (wait_all) {
+   fence = rcu_dereference(obj->fence_excl);
+   if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   if (!dma_fence_get_rcu(fence))
+   goto unlock_retry;
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   fence = NULL;
+   }
+
+   } else {
+   fence = NULL;
+   }
+
+   if (!fence && wait_all) {
struct reservation_object_list *fobj =
rcu_dereference(obj->fence);
 
@@ -463,22 +476,6 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
}
}
 
-   if (!shared_count) {
-   struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
-
-   if (fence_excl &&
-   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- _excl->flags)) {
-   if (!dma_fence_get_rcu(fence_excl))
-   goto unlock_retry;
-
-   if (dma_fence_is_signaled(fence_excl))
-   dma_fence_put(fence_excl);
-   else
-   fence = fence_excl;
-   }
-   }
-
rcu_read_unlock();
if (fence) {
if (read_seqcount_retry(>seq, seq)) {
-- 
2.5.5

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

Re: [PATCHv5 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Rob Herring]

On Thu, Aug 03, 2017 at 01:01:34PM +0800, Hean Loong, Ong wrote:
> From: Ong Hean Loong 

I take back my ack...

Laurent's comments on v4 are not addressed.

> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height, buts per pixel and memory
> port width. The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as
> altr.
> 
> Signed-off-by: Ong, Hean Loong 
> ---
>  .../devicetree/bindings/display/altr,vip-fb2.txt   | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt 
> b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> new file mode 100644
> index 000..c4338d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> @@ -0,0 +1,39 @@
> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> +
> +Supported hardware: Arria 10 and above with display port IP
> +
> +The hardware associated with this device tree is a SoC FPGA. Where there is 
> an ARM controller
> +and a FPGA device. The ARM controller would host the Linux OS while the FPGA 
> device runs on its
> +individual IP firmware. In the Intel VIP Frame Buffer II the ARM controller 
> would be
> +driving data from the Linux OS to the FPGA device programmed with the Frame 
> Buffer II IP
> +to render pixels to be streamed to the Display Port connector.

Still referring to Linux as both Laurent and I pointed out.

Wrap your lines at <80 chars. This was fine before...

> +
> +The Frame Buffer II device is a simple frame buffer device. The device 
> contains the display
> +properties and the bridge or connector register. The output for this device 
> currently
> +is a dedicated to a single Display Port. Currently the max resolution 
> supported is 1280 x 720 at
> +60Hz.
> +
> +More information the FPGA video IP component can be acquired from
> +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_vip.pdf
> +
> +
> +New bindings:
> +=
> +Required properties:
> +
> +- compatible: "altr,vip-frame-buffer-2.0"
> +- reg: Physical base address and length of the framebuffer controller's
> +  registers.
> +- altr,max-width: The width of the framebuffer in pixels.
> +- altr,max-height: The height of the framebuffer in pixels.
> +- altr,mem-port-width = the bus width of the avalon master port on the frame 
> reader
> +
> +Example:
> +
> +   dp_0_frame_buf: display-controller@10280 {
> +   compatible = "altr,vip-frame-buffer-2.0";
> +   reg = <0x0001 0x0280 0x0040>;
> +   altr,max-width = <1280>;
> +   altr,max-height = <720>;
> +   altr,mem-port-width = <128>;
> +   };
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv5 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Rob Herring]

On Thu, Aug 03, 2017 at 01:01:34PM +0800, Hean Loong, Ong wrote:
> From: Ong Hean Loong 

Why did you change the subject? "dt-bindings: display: ..." for the 
subject was correct.

With subject fixed,

Acked-by: Rob Herring 

> 
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height, buts per pixel and memory
> port width. The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as
> altr.
> 
> Signed-off-by: Ong, Hean Loong 
> ---
>  .../devicetree/bindings/display/altr,vip-fb2.txt   | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #2 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 257867
  --> https://bugzilla.kernel.org/attachment.cgi?id=257867=edit
kernel config

-- 
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 libdrm] exynos: change the license to X11/MIT

[Jan Vesely]

On Thu, 2017-08-10 at 13:52 +0900, Inki Dae wrote:
> Chnage GPL license of Exynos relevant code to X11/MIT.
> 
> I'd like to keep license consistency to all Exynos code
> because License checker notices two more licenses exist
> in libdrm.
> 
> For the license change I need to get your agree - all committers.
> So please give me Acked-by if you agree with me.

Don't really know or care why this is necessary, but few cleanup
commits shouldn't block this.
Acked-by: Jan Vesely 

Jan

> 
> Signed-off-by: Inki Dae 
> Acked-by: Hyungwon Hwang 
> Acked-by: SooChan Lim 
> Acked-by: Sangjin LEE 
> Acked-by: Boram Park 
> Acked-by: Seung-Woo Kim 
> Acked-by: Joonyoung Shim 
> Acked-by: Emil Velikov 
> ---
>  exynos/exynos_fimg2d.c | 21 +
>  exynos/exynos_fimg2d.h | 21 +
>  exynos/fimg2d_reg.h| 21 +
>  libkms/exynos.c| 22 ++
>  tests/exynos/exynos_fimg2d_event.c | 27 +--
>  tests/exynos/exynos_fimg2d_perf.c  | 27 +--
>  tests/exynos/exynos_fimg2d_test.c  | 21 +
>  7 files changed, 120 insertions(+), 40 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 61340c3..5658a48 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -3,11 +3,24 @@
>   * Authors:
>   *   Inki Dae 
>   *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
>   *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifdef HAVE_CONFIG_H
> diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
> index a825c68..a4dfbe7 100644
> --- a/exynos/exynos_fimg2d.h
> +++ b/exynos/exynos_fimg2d.h
> @@ -3,11 +3,24 @@
>   * Authors:
>   *   Inki Dae 
>   *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
>   *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifndef _FIMG2D_H_
> diff --git a/exynos/fimg2d_reg.h b/exynos/fimg2d_reg.h
> index 07dd634..d42296d 100644
> --- a/exynos/fimg2d_reg.h
> +++ 

Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

[Rob Herring]

On Tue, Aug 01, 2017 at 05:11:48PM -0500, David Lechner wrote:
> LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
> module for the ST7586 controller with parameters for the EV3 LCD display.
> 
> Signed-off-by: David Lechner 
> ---
>  .../devicetree/bindings/display/st7586.txt |  26 +

Please split bindings to a separate patch.

>  drivers/gpu/drm/tinydrm/Kconfig|  10 +
>  drivers/gpu/drm/tinydrm/Makefile   |   1 +
>  drivers/gpu/drm/tinydrm/st7586.c   | 579 
> +
>  include/drm/tinydrm/st7586.h   |  34 ++
>  5 files changed, 650 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/st7586.txt
>  create mode 100644 drivers/gpu/drm/tinydrm/st7586.c
>  create mode 100644 include/drm/tinydrm/st7586.h
> 
> diff --git a/Documentation/devicetree/bindings/display/st7586.txt 
> b/Documentation/devicetree/bindings/display/st7586.txt
> new file mode 100644
> index 000..acf784aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st7586.txt
> @@ -0,0 +1,26 @@
> +Sitronix ST7586 display panel
> +
> +Required properties:
> +- compatible:"lego,ev3-lcd".
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +
> +Optional properties:
> +- dc-gpios:  D/C pin. The presence/absence of this GPIO determines
> + the panel interface mode (IM[3:0] pins):
> + - present: IM=x110 4-wire 8-bit data serial interface
> + - absent:  IM=x101 3-wire 9-bit data serial interface

This is a Lego specific pin which in turn drives IM (or IF) signals? 
This should have a vendor prefix with either lego or Sitronix depending 
on the answer.

Presence/absence doesn't sense. Doesn't the state of the GPIO line 
matter? You should just say if not present, the interface defaults to 
3-wire mode.

> +- reset-gpios:   Reset pin
> +- power-supply:  A regulator node for the supply voltage.
> +- backlight: phandle of the backlight device attached to the panel
> +- rotation:  panel rotation in degrees counter clockwise (0,90,180,270)
> +
> +Example:
> + display@0{
> + compatible = "lego,ev3-lcd";
> + reg = <0>;
> + spi-max-frequency = <1000>;
> + dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
> + };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

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

--- Comment #28 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #27)
> An apitrace that reproduces the issue would be very useful.

There is one example already from Philipp Überbacher above in the comments:
https://bugs.freedesktop.org/show_bug.cgi?id=101731#c16

I tried to record this with apitrace too, but strangely, the freeze doesn't
happen when it's recording. Somehow it prevents it by the fact of recording
itself.

I'll re-record it anyway, and will post here.

-- 
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 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #1 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 257865
  --> https://bugzilla.kernel.org/attachment.cgi?id=257865=edit
lspci output

-- 
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 196635] New: amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

Bug ID: 196635
   Summary: amdgpu clinfo hangs with SI
   Product: Drivers
   Version: 2.5
Kernel Version: 4.13-rc4
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: janpieter.sol...@dommel.be
Regression: No

Created attachment 257863
  --> https://bugzilla.kernel.org/attachment.cgi?id=257863=edit
dmesg output

the clinfo command does not work anymore since I tested 4.13-rc4 on my pc.
kernel error message in attachment.
I'm using the amdgpu-pro libraries (not the kernel driver, really only the
libraries) on a dual opteron with a R9 nano and a HD 7700 installed.
I must say I was very happy DPM is working now, but the clinfo calls not
working is a bit of a bummer :(

-- 
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] dma-buf: handle NULL src_list in reservation_object_copy_fences

[Deucher, Alexander]

> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Thursday, August 10, 2017 10:44 AM
> To: Deucher, Alexander; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] dma-buf: handle NULL src_list in
> reservation_object_copy_fences
> 
> Am 10.08.2017 um 16:40 schrieb Deucher, Alexander:
> >> -Original Message-
> >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
> Behalf
> >> Of Christian König
> >> Sent: Thursday, August 10, 2017 9:42 AM
> >> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >> Subject: [PATCH] dma-buf: handle NULL src_list in
> >> reservation_object_copy_fences
> >>
> >> From: Christian König 
> >>
> >> The list of shared fences can be NULL and that needs to be handled as
> well.
> >>
> >> Signed-off-by: Christian König 
> > I'll squash this with the original patch for upstream.
> >
> > Reviewed-by: Alex Deucher 
> 
> Please note that I haven't tested this very well. You really need a
> prime setup for testing and that's not on my desk right now.
> 
> So please ping whoever reported that problem to retest.

FWIW, the issue was reported on a single card.

Alex

> 
> Thanks,
> Christian.
> 
> >
> >> ---
> >>   drivers/dma-buf/reservation.c | 28 +++-
> >>   1 file changed, 15 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-
> buf/reservation.c
> >> index 302c137..dec3a81 100644
> >> --- a/drivers/dma-buf/reservation.c
> >> +++ b/drivers/dma-buf/reservation.c
> >> @@ -279,23 +279,25 @@ int reservation_object_copy_fences(struct
> >> reservation_object *dst,
> >>
> >>src_list = reservation_object_get_list(src);
> >>
> >> -  /*
> >> -   * resize dst->fence or allocate if it doesn't exist,
> >> -   * noop if already correct size
> >> -   */
> >> -  size = offsetof(typeof(*src_list), shared[src_list->shared_count]);
> >> -  dst_list = kmalloc(size, GFP_KERNEL);
> >> -  if (!dst_list)
> >> -  return -ENOMEM;
> >> +  if (src_list) {
> >> +  size = offsetof(typeof(*src_list),
> >> +  shared[src_list->shared_count]);
> >> +  dst_list = kmalloc(size, GFP_KERNEL);
> >> +  if (!dst_list)
> >> +  return -ENOMEM;
> >> +
> >> +  dst_list->shared_count = src_list->shared_count;
> >> +  dst_list->shared_max = src_list->shared_count;
> >> +  for (i = 0; i < src_list->shared_count; ++i)
> >> +  dst_list->shared[i] =
> >> +  dma_fence_get(src_list->shared[i]);
> >> +  } else {
> >> +  dst_list = NULL;
> >> +  }
> >>
> >>kfree(dst->staged);
> >>dst->staged = NULL;
> >>
> >> -  dst_list->shared_count = src_list->shared_count;
> >> -  dst_list->shared_max = src_list->shared_count;
> >> -  for (i = 0; i < src_list->shared_count; ++i)
> >> -  dst_list->shared[i] = dma_fence_get(src_list->shared[i]);
> >> -
> >>src_list = reservation_object_get_list(dst);
> >>
> >>old = reservation_object_get_excl(dst);
> >> --
> >> 2.7.4
> >>
> >> ___
> >> amd-gfx mailing list
> >> amd-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 

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

Re: [PATCH 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Laurent Pinchart]

Hi Marek,

On Friday 04 Aug 2017 08:55:55 Marek Szyprowski wrote:
> Hi Laurent,
> 
> Thanks for your detailed comments. Maciej resurrected some orphaned code,
> which is still useful today (Tomasz has left Samsung a few years ago).
> I'm not sure we will be able to answer all your questions without deep
> investigation, especially about the driver operation details, but we
> will try.

Thank you.

> On 2017-08-03 12:24, Laurent Pinchart wrote:
> > On Thursday 03 Aug 2017 09:45:22 Maciej Purski wrote:
> >> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> >> It is controlled via I2C bus. Its interaction with other
> >> devices in video pipeline is performed mainly on HW level.
> >> The only interaction it does on device driver level is
> >> filtering-out unsupported video modes, it exposes drm_bridge
> >> interface to perform this operation.
> >> 
> >> This patch is based on the code refactored by Tomasz Stanislawski
> >> , which was initially developed by:
> >> Adam Hampson 
> >> Erik Gilling 
> >> Shankar Bandal 
> >> Dharam Kumar 
> >> 
> >> Signed-off-by: Maciej Purski 
> >> ---
> >> 
> >>   .../devicetree/bindings/display/bridge/sii9234.txt |   20 +
> >>   drivers/gpu/drm/bridge/Kconfig |8 +
> >>   drivers/gpu/drm/bridge/Makefile|1 +
> >>   drivers/gpu/drm/bridge/sii9234.c   | 1019 +
> >>   4 files changed, 1048 insertions(+)
> >>   create mode 100644
> >> 
> >> Documentation/devicetree/bindings/display/bridge/sii9234.txt create mode
> >> 100644 drivers/gpu/drm/bridge/sii9234.c
> >> 
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> >> b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file
> >> mode 100644
> >> index 000..2cdf286
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> > 
> > DT reviewers might ask you to submit DT bindings as a separate patch.
> > 
> >> @@ -0,0 +1,20 @@
> >> +SiI9234 Mobile HD Link Transmitter
> >> +
> >> +Required properties:
> >> +- compatible : "sil,sii9234".
> >> +- reg : I2C address for TPI interface, use 0x39
> >> +- vcc-supply : regulator that supplies the chip
> > 
> > Is there a single power supply only ? Transceivers usually have at least
> > one digital and one analog power supply.
> 
> Acording to the schematic there are four power supplies used for SII9234
> MHL chip in Trats2 board: VSIL_1.2A, VSIL_1.2C, VCC_3.3V_MHL and
> VCC_1.8V_MHL. First two are derived directly from VSIL_1.2 signal, which is
> modeled as a fixed regulator. The latter two are derived directly from VBAT
> using some level converter, which is controlled by the same GPIO pin as VSIL
> fixed regulator. Any idea how this should be represented better in device
> tree instead of having single vcc-supply?

Without access to the documentation I can only guess, but it looks like 
VSIL_1.2A and VSIL_1.2C are supposed to be powered from the same power supply 
rail, possibly with different filters. I think they can be grouped together 
from a DT binding point of view. The last two supplies seem independent. We 
should thus probably model this as three separate supplies.

It would be useful to check in the SII9234 datasheet what power sequence the 
chip expects. Is there any chance you could find that document ?

> >> +- interrupts, interrupt-parent: interrupt specifier of INT pin
> >> +- reset-gpios: gpio specifier of RESET pin
> > 
> > Is this mandatory to connect the reset pin to the SoC ?
> 
> IMHO yes, the chip has to be reset during the initialization procedure
> and doesn't work properly without reset.

OK, I have no issue making the property mandatory then.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] dma-buf: handle NULL src_list in reservation_object_copy_fences

[Christian König]

Am 10.08.2017 um 16:40 schrieb Deucher, Alexander:

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Christian König
Sent: Thursday, August 10, 2017 9:42 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH] dma-buf: handle NULL src_list in
reservation_object_copy_fences

From: Christian König 

The list of shared fences can be NULL and that needs to be handled as well.

Signed-off-by: Christian König 

I'll squash this with the original patch for upstream.

Reviewed-by: Alex Deucher 


Please note that I haven't tested this very well. You really need a 
prime setup for testing and that's not on my desk right now.


So please ping whoever reported that problem to retest.

Thanks,
Christian.




---
  drivers/dma-buf/reservation.c | 28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 302c137..dec3a81 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -279,23 +279,25 @@ int reservation_object_copy_fences(struct
reservation_object *dst,

src_list = reservation_object_get_list(src);

-   /*
-* resize dst->fence or allocate if it doesn't exist,
-* noop if already correct size
-*/
-   size = offsetof(typeof(*src_list), shared[src_list->shared_count]);
-   dst_list = kmalloc(size, GFP_KERNEL);
-   if (!dst_list)
-   return -ENOMEM;
+   if (src_list) {
+   size = offsetof(typeof(*src_list),
+   shared[src_list->shared_count]);
+   dst_list = kmalloc(size, GFP_KERNEL);
+   if (!dst_list)
+   return -ENOMEM;
+
+   dst_list->shared_count = src_list->shared_count;
+   dst_list->shared_max = src_list->shared_count;
+   for (i = 0; i < src_list->shared_count; ++i)
+   dst_list->shared[i] =
+   dma_fence_get(src_list->shared[i]);
+   } else {
+   dst_list = NULL;
+   }

kfree(dst->staged);
dst->staged = NULL;

-   dst_list->shared_count = src_list->shared_count;
-   dst_list->shared_max = src_list->shared_count;
-   for (i = 0; i < src_list->shared_count; ++i)
-   dst_list->shared[i] = dma_fence_get(src_list->shared[i]);
-
src_list = reservation_object_get_list(dst);

old = reservation_object_get_excl(dst);
--
2.7.4

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

[Jason Ekstrand]

On Thu, Aug 10, 2017 at 4:00 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-08-10 00:53:00)
> > On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson 
> wrote:
> > However, this installs the proxy into syncobj->fence with the result
> > that any concurrent wait also become a WAIT_FOR_SUBMIT. The behaviour
> > of drm_syncobj is then quite inconsistent, sometimes it will wait
> for a
> > future fence, sometimes it will report an error.
> >
> >
> > Yeah, that's not good.  I thought about a variety of solutions to try and
> > re-use more core dma_fence code.  Ultimately I chose the current one
> because it
> > takes a snapshot of the syncobjs and then, from that point forward, it's
> > consistent with its snapshot.  Nothing I was able to come up with based
> on core
> > dma_fence wait routines does that.
>
> So if we choose to keep the proxy local to the fence-array and not replace
> syncobj->fence, we can still reduce this to a plain dma-fence-array +
> wait.
>
> Pertinent details:
>
> +static void syncobj_notify(struct drm_syncobj *syncobj, struct dma_fence
> *fence)
> +{
> +   struct drm_syncobj_cb *cb, *cn;
> +   unsigned long flags;
> +
> +   /* This is just an opencoded waitqueue; FIXME! */
> +   spin_lock_irqsave(>lock, flags);
> +   list_for_each_entry_safe(cb, cn, >cb_list, link)
> +   cb->func(cb, fence);
> +   INIT_LIST_HEAD(>cb_list);
> +   spin_unlock_irqrestore(>lock, flags);
> +}
> +
>  /**
>   * drm_syncobj_replace_fence - replace fence in a sync object.
>   * @syncobj: Sync object to replace fence in
> @@ -89,7 +109,10 @@ void drm_syncobj_replace_fence(struct drm_syncobj
> *syncobj,
>
> if (fence)
> dma_fence_get(fence);
> +
> old_fence = xchg(>fence, fence);
> +   if (!old_fence && fence)
> +   syncobj_notify(syncobj, fence);
>
> dma_fence_put(old_fence);
>  }
> @@ -124,6 +147,9 @@ void drm_syncobj_free(struct kref *kref)
> struct drm_syncobj *syncobj = container_of(kref,
>struct drm_syncobj,
>refcount);
> +
> +   syncobj_notify(syncobj, NULL);
> +
> dma_fence_put(syncobj->fence);
> kfree(syncobj);
>  }
> @@ -140,6 +166,8 @@ static int drm_syncobj_create(struct drm_file
> *file_private,
> return -ENOMEM;
>
> kref_init(>refcount);
> +   spin_lock_init(>lock);
> +   INIT_LIST_HEAD(>cb_list);
>
> idr_preload(GFP_KERNEL);
> spin_lock(_private->syncobj_table_lock);
>
> struct future_fence {
> +   struct drm_syncobj_cb base;
> +   struct dma_fence **slot;
> +};
> +
> +static void future_fence_cb(struct drm_syncobj_cb *cb, struct dma_fence
> *fence)
> +{
> +   struct future_fence *ff = container_of(cb, typeof(*ff), base);
> +
> +   if (fence)
> +   dma_fence_replace_proxy(ff->slot, fence);
>

Where does this come from?  I can't find it on dri-devel and "proxy"
doesn't show up anywhere in the dam-buf sources.  What does it do?


> +   else
> +   dma_fence_signal(*ff->slot);
> +
> +   kfree(ff);
> +}
> +
> +int
> +drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file_private)
> +{
> +   struct drm_syncobj_wait *args = data;
> +   struct dma_fence_array *array;
> +   struct dma_fence **fences;
> +   unsigned int count, i;
> +   long timeout;
> +   u32 *handles;
> +   int ret;
> +
> +   BUILD_BUG_ON(sizeof(*fences) < sizeof(*handles));
> +
> +   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> +   return -ENODEV;
> +
> +   if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
> +   DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
> +   return -EINVAL;
> +
> +   count = args->count_handles;
> +   if (!count)
> +   return -EINVAL;
> +
> +   /* Get the handles from userspace */
> +   fences = kmalloc_array(count,
> +  sizeof(struct dma_fence *),
> +  __GFP_NOWARN | GFP_KERNEL);
> +   if (!fences)
> +   return -ENOMEM;
> +
> +   handles = (void *)fences + count * (sizeof(*fences) -
> sizeof(*handles));
> +   if (copy_from_user(handles,
> +  u64_to_user_ptr(args->handles),
> +  sizeof(u32) * count)) {
> +   ret = -EFAULT;
> +   goto err;
> +   }
> +
> +   for (i = 0; i < count; i++) {
> +   struct drm_syncobj *s;
> +
> +   ret = -ENOENT;
> +   s = drm_syncobj_find(file_private, handles[i]);
> +   if (s) {
> +   ret = 0;
> +   spin_lock_irq(>lock);
> +   if (s->fence) {
> +

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

[Christian König]

Am 10.08.2017 um 16:32 schrieb Jason Ekstrand:
On Thu, Aug 10, 2017 at 5:26 AM, Christian König 
> wrote:


Am 10.08.2017 um 01:53 schrieb Jason Ekstrand:

On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson
> wrote:

Quoting Chris Wilson (2017-08-09 18:57:44)
> So we are taking a snapshot here. It looks like this could have been
> done using a dma_fence_array + dma_fence_proxy for
capturing the future
> fence.

A quick sketch of this idea looks like:

 void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence)
 {
-   struct dma_fence *old_fence;
+   unsigned long flags;

-   if (fence)
-   dma_fence_get(fence);
-   old_fence = xchg(>fence, fence);
-
-   dma_fence_put(old_fence);
+  spin_lock_irqsave(>lock, flags);
+   dma_fence_replace_proxy(>fence, fence);
+   spin_unlock_irqrestore(>lock, flags);
 }

+int
+drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private)
+{
+   struct drm_syncobj_wait *args = data;
+   struct dma_fence **fences;
+   struct dma_fence_array *array;
+   unsigned long timeout;
+   unsigned int count;
+   u32 *handles;
+   int ret = 0;
+   u32 i;
+
+   BUILD_BUG_ON(sizeof(*fences) < sizeof(*handles));
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->flags != 0 && args->flags !=
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)
+   return -EINVAL;
+
+   count = args->count_handles;
+   if (!count)
+   return -EINVAL;
+
+   /* Get the handles from userspace */
+   fences = kmalloc_array(count,
+ sizeof(struct dma_fence *),
+ __GFP_NOWARN | GFP_KERNEL);
+   if (!fences)
+   return -ENOMEM;
+
+   handles = (void *)fences + count * (sizeof(*fences) -
sizeof(*handles));
+   if (copy_from_user(handles,
+ u64_to_user_ptr(args->handles),
+  sizeof(u32) * count)) {
+   ret = -EFAULT;
+   goto err;
+   }
+
+   for (i = 0; i < count; i++) {
+   struct drm_syncobj *s;
+
+   ret = -ENOENT;
+   s = drm_syncobj_find(file_private, handles[i]);
+   if (s) {
+   ret = 0;
+  spin_lock_irq(>lock);
+   if (!s->fence) {
+   if (args->flags &
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)
+  s->fence = dma_fence_create_proxy();
+   else
+ret = -EINVAL;
+   }
+   if (s->fence)
+   fences[i] =
dma_fence_get(s->fence);
+  spin_unlock_irq(>lock);
+   }
+   if (ret) {
+   count = i;
+   goto err_fences;
+   }
+   }
+
+   array = dma_fence_array_create(count, fences, 0, 0,
+ !(args->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL));
+   if (!array) {
+   ret = -ENOMEM;
+   goto err_fences;
+   }
+
+   timeout = drm_timeout_abs_to_jiffies(args->timeout_nsec);
+   timeout = dma_fence_wait_timeout(>base, true,
timeout);
+   args->first_signaled = array->first_signaled;
+  dma_fence_put(>base);
+
+   return timeout < 0 ? timeout : 0;
+
+err_fences:
+   for (i = 0; i < count; i++)
+   dma_fence_put(fences[i]);
+err:
+   kfree(fences);
+   return ret;
+}

The key advantage is that this translate the ioctl into a
dma-fence-array
which already has to deal with the mess, sharing the burden.
(But it
does require a trivial patch to dma-fence-array to record the
first
signaled fence.)

However, this installs the proxy into syncobj->fence with the
result
that any concurrent wait also become a WAIT_FOR_SUBMIT. The
behaviour
of drm_syncobj is then 

RE: [PATCH] dma-buf: handle NULL src_list in reservation_object_copy_fences

[Deucher, Alexander]

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Thursday, August 10, 2017 9:42 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH] dma-buf: handle NULL src_list in
> reservation_object_copy_fences
> 
> From: Christian König 
> 
> The list of shared fences can be NULL and that needs to be handled as well.
> 
> Signed-off-by: Christian König 

I'll squash this with the original patch for upstream.

Reviewed-by: Alex Deucher 

> ---
>  drivers/dma-buf/reservation.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 302c137..dec3a81 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -279,23 +279,25 @@ int reservation_object_copy_fences(struct
> reservation_object *dst,
> 
>   src_list = reservation_object_get_list(src);
> 
> - /*
> -  * resize dst->fence or allocate if it doesn't exist,
> -  * noop if already correct size
> -  */
> - size = offsetof(typeof(*src_list), shared[src_list->shared_count]);
> - dst_list = kmalloc(size, GFP_KERNEL);
> - if (!dst_list)
> - return -ENOMEM;
> + if (src_list) {
> + size = offsetof(typeof(*src_list),
> + shared[src_list->shared_count]);
> + dst_list = kmalloc(size, GFP_KERNEL);
> + if (!dst_list)
> + return -ENOMEM;
> +
> + dst_list->shared_count = src_list->shared_count;
> + dst_list->shared_max = src_list->shared_count;
> + for (i = 0; i < src_list->shared_count; ++i)
> + dst_list->shared[i] =
> + dma_fence_get(src_list->shared[i]);
> + } else {
> + dst_list = NULL;
> + }
> 
>   kfree(dst->staged);
>   dst->staged = NULL;
> 
> - dst_list->shared_count = src_list->shared_count;
> - dst_list->shared_max = src_list->shared_count;
> - for (i = 0; i < src_list->shared_count; ++i)
> - dst_list->shared[i] = dma_fence_get(src_list->shared[i]);
> -
>   src_list = reservation_object_get_list(dst);
> 
>   old = reservation_object_get_excl(dst);
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

[Jason Ekstrand]

On Thu, Aug 10, 2017 at 5:26 AM, Christian König 
wrote:

> Am 10.08.2017 um 01:53 schrieb Jason Ekstrand:
>
> On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson 
> wrote:
>
>> Quoting Chris Wilson (2017-08-09 18:57:44)
>> > So we are taking a snapshot here. It looks like this could have been
>> > done using a dma_fence_array + dma_fence_proxy for capturing the future
>> > fence.
>>
>> A quick sketch of this idea looks like:
>>
>>  void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>>struct dma_fence *fence)
>>  {
>> -   struct dma_fence *old_fence;
>> +   unsigned long flags;
>>
>> -   if (fence)
>> -   dma_fence_get(fence);
>> -   old_fence = xchg(>fence, fence);
>> -
>> -   dma_fence_put(old_fence);
>> +   spin_lock_irqsave(>lock, flags);
>> +   dma_fence_replace_proxy(>fence, fence);
>> +   spin_unlock_irqrestore(>lock, flags);
>>  }
>>
>> +int
>> +drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
>> +  struct drm_file *file_private)
>> +{
>> +   struct drm_syncobj_wait *args = data;
>> +   struct dma_fence **fences;
>> +   struct dma_fence_array *array;
>> +   unsigned long timeout;
>> +   unsigned int count;
>> +   u32 *handles;
>> +   int ret = 0;
>> +   u32 i;
>> +
>> +   BUILD_BUG_ON(sizeof(*fences) < sizeof(*handles));
>> +
>> +   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>> +   return -ENODEV;
>> +
>> +   if (args->flags != 0 && args->flags !=
>> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)
>> +   return -EINVAL;
>> +
>> +   count = args->count_handles;
>> +   if (!count)
>> +   return -EINVAL;
>> +
>> +   /* Get the handles from userspace */
>> +   fences = kmalloc_array(count,
>> +  sizeof(struct dma_fence *),
>> +  __GFP_NOWARN | GFP_KERNEL);
>> +   if (!fences)
>> +   return -ENOMEM;
>> +
>> +   handles = (void *)fences + count * (sizeof(*fences) -
>> sizeof(*handles));
>> +   if (copy_from_user(handles,
>> +  u64_to_user_ptr(args->handles),
>> +  sizeof(u32) * count)) {
>> +   ret = -EFAULT;
>> +   goto err;
>> +   }
>> +
>> +   for (i = 0; i < count; i++) {
>> +   struct drm_syncobj *s;
>> +
>> +   ret = -ENOENT;
>> +   s = drm_syncobj_find(file_private, handles[i]);
>> +   if (s) {
>> +   ret = 0;
>> +   spin_lock_irq(>lock);
>> +   if (!s->fence) {
>> +   if (args->flags &
>> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)
>> +   s->fence =
>> dma_fence_create_proxy();
>> +   else
>> +   ret = -EINVAL;
>> +   }
>> +   if (s->fence)
>> +   fences[i] = dma_fence_get(s->fence);
>> +   spin_unlock_irq(>lock);
>> +   }
>> +   if (ret) {
>> +   count = i;
>> +   goto err_fences;
>> +   }
>> +   }
>> +
>> +   array = dma_fence_array_create(count, fences, 0, 0,
>> +  !(args->flags &
>> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL));
>> +   if (!array) {
>> +   ret = -ENOMEM;
>> +   goto err_fences;
>> +   }
>> +
>> +   timeout = drm_timeout_abs_to_jiffies(args->timeout_nsec);
>> +   timeout = dma_fence_wait_timeout(>base, true, timeout);
>> +   args->first_signaled = array->first_signaled;
>> +   dma_fence_put(>base);
>> +
>> +   return timeout < 0 ? timeout : 0;
>> +
>> +err_fences:
>> +   for (i = 0; i < count; i++)
>> +   dma_fence_put(fences[i]);
>> +err:
>> +   kfree(fences);
>> +   return ret;
>> +}
>>
>> The key advantage is that this translate the ioctl into a dma-fence-array
>> which already has to deal with the mess, sharing the burden. (But it
>> does require a trivial patch to dma-fence-array to record the first
>> signaled fence.)
>>
>> However, this installs the proxy into syncobj->fence with the result
>> that any concurrent wait also become a WAIT_FOR_SUBMIT. The behaviour
>> of drm_syncobj is then quite inconsistent, sometimes it will wait for a
>> future fence, sometimes it will report an error.
>>
>
> Yeah, that's not good.  I thought about a variety of solutions to try and
> re-use more core dma_fence code.  Ultimately I chose the current one
> because it takes a snapshot of the syncobjs and then, from that point
> forward, it's consistent with its snapshot.  Nothing I was able to come up
> with based on core dma_fence wait routines does that.
>
>
> As Chris pointed out, that's 

Re: [PATCH libdrm] drm/amdgpu: add new low overhead command submission API. (v2)

[Emil Velikov]

Hi Dave,

On 18 July 2017 at 04:52, Dave Airlie  wrote:

> +int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
> +amdgpu_context_handle context,
> +amdgpu_bo_list_handle bo_list_handle,
> +int num_chunks,
> +struct drm_amdgpu_cs_chunk *chunks,
> +uint64_t *seq_no)
> +{
> +   union drm_amdgpu_cs cs = {0};
> +   uint64_t *chunk_array;
> +   int i, r;
> +   if (num_chunks == 0)
> +   return -EINVAL;
> +
> +   chunk_array = alloca(sizeof(uint64_t) * num_chunks);
Out of curiosity:
Does malloc/free produce noticeable overhead that lead you you alloca?

num_chunks is signed - should we bail on negative values, can we make
it unsigned?

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

[PATCH] dma-buf: handle NULL src_list in reservation_object_copy_fences

[Christian König]

From: Christian König 

The list of shared fences can be NULL and that needs to be handled as well.

Signed-off-by: Christian König 
---
 drivers/dma-buf/reservation.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 302c137..dec3a81 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -279,23 +279,25 @@ int reservation_object_copy_fences(struct 
reservation_object *dst,
 
src_list = reservation_object_get_list(src);
 
-   /*
-* resize dst->fence or allocate if it doesn't exist,
-* noop if already correct size
-*/
-   size = offsetof(typeof(*src_list), shared[src_list->shared_count]);
-   dst_list = kmalloc(size, GFP_KERNEL);
-   if (!dst_list)
-   return -ENOMEM;
+   if (src_list) {
+   size = offsetof(typeof(*src_list),
+   shared[src_list->shared_count]);
+   dst_list = kmalloc(size, GFP_KERNEL);
+   if (!dst_list)
+   return -ENOMEM;
+
+   dst_list->shared_count = src_list->shared_count;
+   dst_list->shared_max = src_list->shared_count;
+   for (i = 0; i < src_list->shared_count; ++i)
+   dst_list->shared[i] =
+   dma_fence_get(src_list->shared[i]);
+   } else {
+   dst_list = NULL;
+   }
 
kfree(dst->staged);
dst->staged = NULL;
 
-   dst_list->shared_count = src_list->shared_count;
-   dst_list->shared_max = src_list->shared_count;
-   for (i = 0; i < src_list->shared_count; ++i)
-   dst_list->shared[i] = dma_fence_get(src_list->shared[i]);
-
src_list = reservation_object_get_list(dst);
 
old = reservation_object_get_excl(dst);
-- 
2.7.4

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

Re: [PATCH 1/2] drm/bridge/sii8620: add external connector handle

[Laurent Pinchart]

Hi Maciej,

Thank you for the patch.

On Thursday 10 Aug 2017 15:25:29 Maciej Purski wrote:
> The driver should be switched on if an external connector is plugged and
> switched off if it is unplugged. Extcon is optional. If it is not found,
> the driver stays in "always-on" mode.
> 
> Signed-off-by: Maciej Purski 
> ---
>  .../bindings/display/bridge/sil-sii8620.txt|  4 ++
>  drivers/gpu/drm/bridge/sil-sii8620.c   | 83 ++-
>  2 files changed, 85 insertions(+), 2 deletions(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
> b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt index
> 9409d9c..1f230bf 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
> @@ -10,6 +10,9 @@ Required properties:
>   - clocks, clock-names: specification and name of "xtal" clock
>   - video interfaces: Device node can contain video interface port
>   node for HDMI encoder according to [1].
> +Optional properties:
> + - extcon: phandle to external connector for MHL cable changes
> +   detection

The sii8620 DT node should model its connection to the MHL connector using OF 
graph, connecting a port to the MHL connector DT node through endpoints. I 
believe the extcon property should then be added to the MHL connector DT node, 
not the bridge.

>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> 
> @@ -24,6 +27,7 @@ Example:
>   reset-gpio = < 0 0>;
>   clocks = <_system_controller 0>;
>   clock-names = "xtal";
> + extcon = <>;
> 
>   port {
>   mhl_to_hdmi: endpoint {
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c index 2d51a22..5002654 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -17,6 +17,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -78,6 +79,10 @@ struct sii8620 {
>   struct edid *edid;
>   unsigned int gen2_write_burst:1;
>   enum sii8620_mt_state mt_state;
> + struct extcon_dev *extcon;
> + struct notifier_block extcon_nb;
> + struct work_struct extcon_wq;
> + bool extcon_attached;
>   struct list_head mt_queue;
>   struct {
>   int r_size;
> @@ -2102,6 +2107,72 @@ static void sii8620_cable_in(struct sii8620 *ctx)
>   enable_irq(to_i2c_client(ctx->dev)->irq);
>  }
> 
> +static void sii8620_cable_out(struct sii8620 *ctx)
> +{
> + disable_irq(to_i2c_client(ctx->dev)->irq);
> + sii8620_hw_off(ctx);
> +}
> +
> +static void sii8620_extcon_work(struct work_struct *work)
> +{
> + struct sii8620 *ctx =
> + container_of(work, struct sii8620, extcon_wq);
> +
> + if (ctx->extcon_attached)
> + sii8620_cable_in(ctx);
> + else
> + sii8620_cable_out(ctx);
> +}
> +
> +static int sii8620_extcon_notifier(struct notifier_block *self,
> + unsigned long event, void *ptr)
> +{
> + struct sii8620 *ctx =
> + container_of(self, struct sii8620, extcon_nb);
> +
> + ctx->extcon_attached = event;
> + schedule_work(>extcon_wq);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int sii8620_extcon_init(struct sii8620 *ctx)
> +{
> + struct extcon_dev *edev;
> + int ret;
> +
> + INIT_WORK(>extcon_wq, sii8620_extcon_work);
> +
> + if (!of_property_read_bool(ctx->dev->of_node, "extcon")) {
> + dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
> + ctx->extcon_attached = true;
> + return 0;
> + }
> +
> + edev = extcon_get_edev_by_phandle(ctx->dev, 0);
> + if (IS_ERR(edev)) {
> + if (PTR_ERR(edev) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(ctx->dev, "Invalid or missing extcon\n");
> + return PTR_ERR(edev);
> + }
> +
> + ctx->extcon_attached = extcon_get_cable_state_(edev, EXTCON_DISP_MHL);
> + dev_info(ctx->dev, "extcon(MHL) = %d\n", ctx->extcon_attached);
> +
> + ctx->extcon = edev;
> + ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
> + ret = devm_extcon_register_notifier(ctx->dev, edev,
> + EXTCON_DISP_MHL, >extcon_nb);
> +
> + if (ret) {
> + dev_err(ctx->dev, "failed to register notifier for MHL\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
>  {
>   return container_of(bridge, struct sii8620, bridge);
> @@ -2201,13 +2272,20 @@ static int sii8620_probe(struct i2c_client *client,
>   if (ret)
>   return ret;
> 
> + ret = sii8620_extcon_init(ctx);
> +  

[PATCH 0/2] add Silicon Image SiI9234 driver

[Maciej Purski]

Hi everyone,

These patches are a continuation of work by Tomasz Stanislawski on sii9324 
driver, which was described
in th following letter:
https://lists.freedesktop.org/archives/dri-devel/2014-April/057481.html

The main differences from the previous code are:
* driver moved to /gpu/drm/bridge/ and integrated with drm/bridge subsystem
* added filtering-out unsupported display modes
* changed gpio interface to up-to-date
* changed interrupt handling
* improve code style
* add hdmi and sii9324 to exynos4412-trats2 device tree

All comments are welcome.

Regards,
Maciej Purski


Patch summary:

Maciej Purski (2):
  drm/bridge: add Silicon Image SiI9234 driver
  ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

 .../devicetree/bindings/display/bridge/sii9234.txt |   20 +
 arch/arm/boot/dts/exynos4412-trats2.dts|   93 ++
 drivers/gpu/drm/bridge/Kconfig |8 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/sii9234.c   | 1019 
 5 files changed, 1141 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

-- 
2.7.4

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

[PATCH 2/2] arm64: dts: exynos: add extcon phandle

[Maciej Purski]

Sii8620 driver can now use extcon in order to switch on and off
the device.

Signed-off-by: Maciej Purski 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 0943dec..ed991b3 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -784,6 +784,7 @@
reset-gpios = < 0 GPIO_ACTIVE_LOW>;
clocks = <_system_controller 0>;
clock-names = "xtal";
+   extcon = <>;
 
port {
mhl_to_hdmi: endpoint {
-- 
2.7.4

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

[PATCH 1/2] drm/bridge/sii8620: add external connector handle

[Maciej Purski]

The driver should be switched on if an external connector is plugged and
switched off if it is unplugged. Extcon is optional. If it is not found,
the driver stays in "always-on" mode.

Signed-off-by: Maciej Purski 
---
 .../bindings/display/bridge/sil-sii8620.txt|  4 ++
 drivers/gpu/drm/bridge/sil-sii8620.c   | 83 +-
 2 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
index 9409d9c..1f230bf 100644
--- a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
+++ b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
@@ -10,6 +10,9 @@ Required properties:
- clocks, clock-names: specification and name of "xtal" clock
- video interfaces: Device node can contain video interface port
node for HDMI encoder according to [1].
+Optional properties:
+   - extcon: phandle to external connector for MHL cable changes
+ detection
 
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 
@@ -24,6 +27,7 @@ Example:
reset-gpio = < 0 0>;
clocks = <_system_controller 0>;
clock-names = "xtal";
+   extcon = <>;
 
port {
mhl_to_hdmi: endpoint {
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..5002654 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,6 +79,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   bool extcon_attached;
struct list_head mt_queue;
struct {
int r_size;
@@ -2102,6 +2107,72 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+
+   if (ctx->extcon_attached)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   ctx->extcon_attached = event;
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   int ret;
+
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+
+   if (!of_property_read_bool(ctx->dev->of_node, "extcon")) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   ctx->extcon_attached = true;
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_phandle(ctx->dev, 0);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon_attached = extcon_get_cable_state_(edev, EXTCON_DISP_MHL);
+   dev_info(ctx->dev, "extcon(MHL) = %d\n", ctx->extcon_attached);
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   ret = devm_extcon_register_notifier(ctx->dev, edev,
+   EXTCON_DISP_MHL, >extcon_nb);
+
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2201,13 +2272,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (ctx->extcon_attached)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2216,7 +2294,8 @@ static int 

[PATCH 0/2] drm/bridge/sii8620: add external connector handle

[Maciej Purski]

Hi everyone, 

These patches add external connector handling to sii8620 driver.

The first patch documents the extcon binding and add extcon handling 
to the driver. The second adds support for this in exynos5433-tm2-common.dtsi.

All comments are welcome.

Regards,
Maciej Purski

Patch summary:

Maciej Purski (2):
  drm/bridge/sii8620: add external connector handle
  arm64: dts: exynos: add extcon phandle

 .../bindings/display/bridge/sil-sii8620.txt|  4 ++
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi |  1 +
 drivers/gpu/drm/bridge/sil-sii8620.c   | 83 +-
 3 files changed, 86 insertions(+), 2 deletions(-)

-- 
2.7.4

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

Re: [PATCHv3 2/2] drm/omap: add OMAP5 DSIPHY lane-enable support

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 10 Aug 2017 15:29:45 Tomi Valkeinen wrote:
> We are missing OMAP5 DSIPHY lane-enable support, which has prevented
> OMAP5 DSI working in mainline. This patch adds the lane-enable similarly
> to the recently added OMAP4 version.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 47 +---
>  1 file changed, 39 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c index 1855d69b211d..b56a05730314 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2108,9 +2108,6 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi,
> unsigned int lanes) u32 enable_mask, enable_shift;
>   u32 pipd_mask, pipd_shift;
> 
> - if (!dsi->syscon)
> - return 0;
> -
>   if (dsi->module_id == 0) {
>   enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
>   enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
> @@ -2130,14 +2127,45 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi,
> unsigned int lanes) (lanes << enable_shift) | (lanes << pipd_shift));
>  }
> 
> +/* OMAP5 CONTROL_DSIPHY */
> +
> +#define OMAP5_DSIPHY_SYSCON_OFFSET   0x74
> +
> +#define OMAP5_DSI1_LANEENABLE_SHIFT  24
> +#define OMAP5_DSI2_LANEENABLE_SHIFT  19
> +#define OMAP5_DSI_LANEENABLE_MASK0x1f
> +
> +static int dsi_omap5_mux_pads(struct dsi_data *dsi, unsigned int lanes)
> +{
> + u32 enable_shift;
> +
> + if (dsi->module_id == 0)
> + enable_shift = OMAP5_DSI1_LANEENABLE_SHIFT;
> + else if (dsi->module_id == 1)
> + enable_shift = OMAP5_DSI2_LANEENABLE_SHIFT;
> + else
> + return -ENODEV;
> +
> + return regmap_update_bits(dsi->syscon, OMAP5_DSIPHY_SYSCON_OFFSET,
> + OMAP5_DSI_LANEENABLE_MASK << enable_shift,
> + lanes << enable_shift);
> +}
> +
>  static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)
>  {
> - return dsi_omap4_mux_pads(dsi, lane_mask);
> + if (dsi->data->model == DSI_MODEL_OMAP4)
> + return dsi_omap4_mux_pads(dsi, lane_mask);
> + if (dsi->data->model == DSI_MODEL_OMAP5)
> + return dsi_omap5_mux_pads(dsi, lane_mask);
> + return 0;
>  }
> 
>  static void dsi_disable_pads(struct dsi_data *dsi)
>  {
> - dsi_omap4_mux_pads(dsi, 0);
> + if (dsi->data->model == DSI_MODEL_OMAP4)
> + dsi_omap4_mux_pads(dsi, 0);
> + else if (dsi->data->model == DSI_MODEL_OMAP5)
> + dsi_omap5_mux_pads(dsi, 0);
>  }
> 
>  static int dsi_cio_init(struct platform_device *dsidev)
> @@ -5471,14 +5499,17 @@ static int dsi_bind(struct device *dev, struct
> device *master, void *data)
> 
>   dsi->module_id = d->id;
> 
> - if (dsi->data->model == DSI_MODEL_OMAP4) {
> + if (dsi->data->model == DSI_MODEL_OMAP4 ||
> + dsi->data->model == DSI_MODEL_OMAP5) {
>   struct device_node *np;
> 
>   /*
> -  * The OMAP4 display DT bindings don't reference the padconf
> +  * The OMAP4/5 display DT bindings don't reference the padconf
>* syscon. Our only option to retrieve it is to find it by 
name.
>*/
> - np = of_find_node_by_name(NULL, "omap4_padconf_global");
> + np = of_find_node_by_name(NULL,
> + dsi->data->model == DSI_MODEL_OMAP4 ?
> + "omap4_padconf_global" : "omap5_padconf_global");
>   if (!np)
>   return -ENODEV;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/amdgpu: potential shift wrapping bug

[walter harms]

Am 10.08.2017 15:02, schrieb Christian König:
> Am 10.08.2017 um 14:53 schrieb Dan Carpenter:
>> On Thu, Aug 10, 2017 at 02:30:15PM +0200, Christian König wrote:
>>> Am 10.08.2017 um 14:16 schrieb Dan Carpenter:
 "frag_align" is a u64, so presumably we want to use the high bits as
 well instead of shift wrapping.

 Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for
 Vega10 v2")
 Signed-off-by: Dan Carpenter 
>>> The fragment field has only 5bits in hardware and can never be more
>>> than 31,
>>> so the correct fix would actually be using uint32_t here instead.
>>>
>> Changing it to uint32_t introduces a new static checker warning:
>>
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1465 amdgpu_vm_frag_ptes()
>>  warn: was expecting a 64 bit value instead of '~(frag_align - 1)'
>>
>> Unfortunately, I get so many thousands of those I can't normally even
>> review that sort of bug...
>>
>> Let me resend the original patch but with a modified changelog to say
>> that the bug is a false positive.
> 
> Ah, yes of course that's why I made it a 64bit value in the first place.
> 
> Mhm, could we use something like (u32)(1 << pages_per_frag) instead to
> silence the static checker warning?
> 
> It doesn't make much sense to use a 64bit shift here.
> 
> Christian.
> 



Why not keeping Dan 1. patch and add a comment that pages_per_frag is always 
>31 ?

Using 32bit in a 64bit is not forbidden, and changing it causes more problems 
than
it solves. But doing so should be done in a clean way.

just my 2 cents,
re,
 wh

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

Re: [PATCHv3 1/2] drm/omap: use regmap_update_bit() when muxing DSI pads

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 10 Aug 2017 15:29:44 Tomi Valkeinen wrote:
> Use regmap_update_bits instead of regmap_read/write, which simplifies
> the code.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 15 +++
>  1 file changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c index a66d2b1a6c74..1855d69b211d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2107,7 +2107,6 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi,
> unsigned int lanes) {
>   u32 enable_mask, enable_shift;
>   u32 pipd_mask, pipd_shift;
> - u32 reg;
> 
>   if (!dsi->syscon)
>   return 0;
> @@ -2126,17 +2125,9 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi,
> unsigned int lanes) return -ENODEV;
>   }
> 
> - regmap_read(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET, );
> -
> - reg &= ~enable_mask;
> - reg &= ~pipd_mask;
> -
> - reg |= (lanes << enable_shift) & enable_mask;
> - reg |= (lanes << pipd_shift) & pipd_mask;
> -
> - regmap_write(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET, reg);
> -
> - return 0;
> + return regmap_update_bits(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET,
> + enable_mask | pipd_mask,
> + (lanes << enable_shift) | (lanes << pipd_shift));
>  }
> 
>  static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/amdgpu: potential shift wrapping bug

[Christian König]

Am 10.08.2017 um 14:53 schrieb Dan Carpenter:

On Thu, Aug 10, 2017 at 02:30:15PM +0200, Christian König wrote:

Am 10.08.2017 um 14:16 schrieb Dan Carpenter:

"frag_align" is a u64, so presumably we want to use the high bits as
well instead of shift wrapping.

Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for Vega10 v2")
Signed-off-by: Dan Carpenter 

The fragment field has only 5bits in hardware and can never be more than 31,
so the correct fix would actually be using uint32_t here instead.


Changing it to uint32_t introduces a new static checker warning:

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1465 amdgpu_vm_frag_ptes()
 warn: was expecting a 64 bit value instead of '~(frag_align - 1)'

Unfortunately, I get so many thousands of those I can't normally even
review that sort of bug...

Let me resend the original patch but with a modified changelog to say
that the bug is a false positive.


Ah, yes of course that's why I made it a 64bit value in the first place.

Mhm, could we use something like (u32)(1 << pages_per_frag) instead to 
silence the static checker warning?


It doesn't make much sense to use a 64bit shift here.

Christian.



regards,
dan carpenter



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

Re: [PATCH] drm/amdgpu: potential shift wrapping bug

[Dan Carpenter]

On Thu, Aug 10, 2017 at 03:02:53PM +0200, Christian König wrote:
> Am 10.08.2017 um 14:53 schrieb Dan Carpenter:
> > On Thu, Aug 10, 2017 at 02:30:15PM +0200, Christian König wrote:
> > > Am 10.08.2017 um 14:16 schrieb Dan Carpenter:
> > > > "frag_align" is a u64, so presumably we want to use the high bits as
> > > > well instead of shift wrapping.
> > > > 
> > > > Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for 
> > > > Vega10 v2")
> > > > Signed-off-by: Dan Carpenter 
> > > The fragment field has only 5bits in hardware and can never be more than 
> > > 31,
> > > so the correct fix would actually be using uint32_t here instead.
> > > 
> > Changing it to uint32_t introduces a new static checker warning:
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1465 amdgpu_vm_frag_ptes()
> >  warn: was expecting a 64 bit value instead of '~(frag_align - 1)'
> > 
> > Unfortunately, I get so many thousands of those I can't normally even
> > review that sort of bug...
> > 
> > Let me resend the original patch but with a modified changelog to say
> > that the bug is a false positive.
> 
> Ah, yes of course that's why I made it a 64bit value in the first place.
> 
> Mhm, could we use something like (u32)(1 << pages_per_frag) instead to
> silence the static checker warning?

That wouldn't silence it and I think that's not super pretty either.

> 
> It doesn't make much sense to use a 64bit shift here.
> 

I'm just going to ignore the warning.  This driver isn't part of my
.config so I'm not really compiling it the way it was designed which
means I don't have the cross function database enabled.  Probably if I
compiled this normally, I wouldn't even get the warning.

regards,
dan carpenter

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

Re: [PATCH] drm/amdgpu: potential shift wrapping bug

[Dan Carpenter]

On Thu, Aug 10, 2017 at 02:30:15PM +0200, Christian König wrote:
> Am 10.08.2017 um 14:16 schrieb Dan Carpenter:
> > "frag_align" is a u64, so presumably we want to use the high bits as
> > well instead of shift wrapping.
> > 
> > Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for Vega10 
> > v2")
> > Signed-off-by: Dan Carpenter 
> 
> The fragment field has only 5bits in hardware and can never be more than 31,
> so the correct fix would actually be using uint32_t here instead.
> 

Changing it to uint32_t introduces a new static checker warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1465 amdgpu_vm_frag_ptes()
warn: was expecting a 64 bit value instead of '~(frag_align - 1)'

Unfortunately, I get so many thousands of those I can't normally even
review that sort of bug...

Let me resend the original patch but with a modified changelog to say
that the bug is a false positive.

regards,
dan carpenter

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

Re: [PATCH] drm/bridge/sii8620: add remote control support

[Maciej Purski]

Hi Hans,

Thank you for your reply.  All dongles that we used to work with in Samsung
convert CEC protocol to RCP which we get through MHL Sideband Channel.
All we can do in the driver is to report RCP messages to user-space.

On the RC subsystem: your point is right, which was confirmed
by Sean and I'm going to use RC subsystem there.

Regards,

Maciej Purski

On 08/03/2017 10:28 AM, Hans Verkuil wrote:


Hi Maciej,

Unfortunately I do not have the MHL spec, but I was wondering what the
relationship between RCP and CEC is. CEC has remote control support as
well, so is RCP that subset of the CEC specification or is it completely
separate?

I'm CC-ing Sean Young and the linux-media mailinglist as well since Sean
maintains the rc subsystem. Which you probably should use, but I'm not the
expert on that.

Regards,

Hans

On 08/03/17 09:44, Maciej Purski wrote:

MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.

Signed-off-by: Maciej Purski 
---
  drivers/gpu/drm/bridge/sil-sii8620.c | 188 ++-
  include/drm/bridge/mhl.h |   4 +
  2 files changed, 187 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..7e75f2f 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -58,6 +59,7 @@ enum sii8620_mt_state {
  struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+   struct input_dev *rcp_input_dev;
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -106,6 +108,82 @@ struct sii8620_mt_msg {
sii8620_cb continuation;
  };
  
+static struct {

+   u16 key;
+   u16 extra_key;
+   bool autorepeat;
+}  rcp_keymap[] = {
+   [0x00] = { KEY_SELECT },
+   [0x01] = { KEY_UP, 0, true },
+   [0x02] = { KEY_DOWN, 0, true },
+   [0x03] = { KEY_LEFT, 0, true },
+   [0x04] = { KEY_RIGHT, 0, true },
+
+   [0x05] = { KEY_RIGHT, KEY_UP, true },
+   [0x06] = { KEY_RIGHT, KEY_DOWN, true },
+   [0x07] = { KEY_LEFT,  KEY_UP, true },
+   [0x08] = { KEY_LEFT,  KEY_DOWN, true },
+
+   [0x09] = { KEY_MENU },
+   [0x0A] = { KEY_UNKNOWN },
+   [0x0B] = { KEY_UNKNOWN },
+   [0x0C] = { KEY_BOOKMARKS },
+   [0x0D] = { KEY_EXIT },
+
+   [0x20] = { KEY_NUMERIC_0 },
+   [0x21] = { KEY_NUMERIC_1 },
+   [0x22] = { KEY_NUMERIC_2 },
+   [0x23] = { KEY_NUMERIC_3 },
+   [0x24] = { KEY_NUMERIC_4 },
+   [0x25] = { KEY_NUMERIC_5 },
+   [0x26] = { KEY_NUMERIC_6 },
+   [0x27] = { KEY_NUMERIC_7 },
+   [0x28] = { KEY_NUMERIC_8 },
+   [0x29] = { KEY_NUMERIC_9 },
+
+   [0x2A] = { KEY_DOT },
+   [0x2B] = { KEY_ENTER },
+   [0x2C] = { KEY_CLEAR },
+
+   [0x30] = { KEY_CHANNELUP, 0, true },
+   [0x31] = { KEY_CHANNELDOWN, 0, true },
+
+   [0x33] = { KEY_SOUND },
+   [0x35] = { KEY_PROGRAM }, /* Show Information */
+
+   [0x37] = { KEY_PAGEUP, 0, true },
+   [0x38] = { KEY_PAGEDOWN, 0, true },
+
+   [0x41] = { KEY_VOLUMEUP, 0, true },
+   [0x42] = { KEY_VOLUMEDOWN, 0, true },
+   [0x43] = { KEY_MUTE },
+   [0x44] = { KEY_PLAY },
+   [0x45] = { KEY_STOP },
+   [0x46] = { KEY_PLAYPAUSE }, /* Pause */
+   [0x47] = { KEY_RECORD },
+   [0x48] = { KEY_REWIND, 0, true },
+   [0x49] = { KEY_FASTFORWARD, 0, true },
+   [0x4A] = { KEY_EJECTCD },
+   [0x4B] = { KEY_NEXTSONG, 0, true }, /* Forward */
+   [0x4C] = { KEY_PREVIOUSSONG, 0, true }, /* Backward */
+
+   [0x60] = { KEY_PLAYPAUSE }, /* Play */
+   [0x61] = { KEY_PLAYPAUSE }, /* Pause the Play */
+   [0x62] = { KEY_RECORD },
+   [0x63] = { KEY_PAUSE },
+   [0x64] = { KEY_STOP },
+   [0x65] = { KEY_MUTE },
+   [0x66] = { KEY_MUTE }, /* Restore Mute */
+
+   [0x71] = { KEY_F1 },
+   [0x72] = { KEY_F2 },
+   [0x73] = { KEY_F3 },
+   [0x74] = { KEY_F4 },
+   [0x75] = { KEY_F5 },
+
+   [0x7E] = { KEY_VENDOR },
+};
+
  static const u8 sii8620_i2c_page[] = {
0x39, /* Main System */
0x3d, /* TDM and HSIC */
@@ -431,6 +509,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
  }
  
+static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)

+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
+}
+
+static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
+}
+
  static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
   

Re: [PATCH] drm/amdgpu: potential shift wrapping bug

[Dan Carpenter]

On Thu, Aug 10, 2017 at 02:30:15PM +0200, Christian König wrote:
> Am 10.08.2017 um 14:16 schrieb Dan Carpenter:
> > "frag_align" is a u64, so presumably we want to use the high bits as
> > well instead of shift wrapping.
> > 
> > Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for Vega10 
> > v2")
> > Signed-off-by: Dan Carpenter 
> 
> The fragment field has only 5bits in hardware and can never be more than 31,
> so the correct fix would actually be using uint32_t here instead.
> 

Alright.  Thanks.  I'll resend.

regards,
dan carpenter

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

Re: [PATCH] drm/amdgpu: potential shift wrapping bug

[Christian König]

Am 10.08.2017 um 14:16 schrieb Dan Carpenter:

"frag_align" is a u64, so presumably we want to use the high bits as
well instead of shift wrapping.

Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for Vega10 v2")
Signed-off-by: Dan Carpenter 


The fragment field has only 5bits in hardware and can never be more than 
31, so the correct fix would actually be using uint32_t here instead.


Christian.



diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ba0407d12525..d9a8e942ac3b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1459,7 +1459,7 @@ static int amdgpu_vm_frag_ptes(struct 
amdgpu_pte_update_params*params,
/* SI and newer are optimized for 64KB */
unsigned pages_per_frag = AMDGPU_LOG2_PAGES_PER_FRAG(params->adev);
uint64_t frag_flags = AMDGPU_PTE_FRAG(pages_per_frag);
-   uint64_t frag_align = 1 << pages_per_frag;
+   uint64_t frag_align = 1ULL << pages_per_frag;
  
  	uint64_t frag_start = ALIGN(start, frag_align);

uint64_t frag_end = end & ~(frag_align - 1);
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

[PATCHv3 1/2] drm/omap: use regmap_update_bit() when muxing DSI pads

[Tomi Valkeinen]

Use regmap_update_bits instead of regmap_read/write, which simplifies
the code.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index a66d2b1a6c74..1855d69b211d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -2107,7 +2107,6 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi, 
unsigned int lanes)
 {
u32 enable_mask, enable_shift;
u32 pipd_mask, pipd_shift;
-   u32 reg;
 
if (!dsi->syscon)
return 0;
@@ -2126,17 +2125,9 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi, 
unsigned int lanes)
return -ENODEV;
}
 
-   regmap_read(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET, );
-
-   reg &= ~enable_mask;
-   reg &= ~pipd_mask;
-
-   reg |= (lanes << enable_shift) & enable_mask;
-   reg |= (lanes << pipd_shift) & pipd_mask;
-
-   regmap_write(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET, reg);
-
-   return 0;
+   return regmap_update_bits(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET,
+   enable_mask | pipd_mask,
+   (lanes << enable_shift) | (lanes << pipd_shift));
 }
 
 static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)
-- 
2.7.4


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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

[PATCHv3 2/2] drm/omap: add OMAP5 DSIPHY lane-enable support

[Tomi Valkeinen]

We are missing OMAP5 DSIPHY lane-enable support, which has prevented
OMAP5 DSI working in mainline. This patch adds the lane-enable similarly
to the recently added OMAP4 version.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 47 ---
 1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 1855d69b211d..b56a05730314 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -2108,9 +2108,6 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi, 
unsigned int lanes)
u32 enable_mask, enable_shift;
u32 pipd_mask, pipd_shift;
 
-   if (!dsi->syscon)
-   return 0;
-
if (dsi->module_id == 0) {
enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
@@ -2130,14 +2127,45 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi, 
unsigned int lanes)
(lanes << enable_shift) | (lanes << pipd_shift));
 }
 
+/* OMAP5 CONTROL_DSIPHY */
+
+#define OMAP5_DSIPHY_SYSCON_OFFSET 0x74
+
+#define OMAP5_DSI1_LANEENABLE_SHIFT24
+#define OMAP5_DSI2_LANEENABLE_SHIFT19
+#define OMAP5_DSI_LANEENABLE_MASK  0x1f
+
+static int dsi_omap5_mux_pads(struct dsi_data *dsi, unsigned int lanes)
+{
+   u32 enable_shift;
+
+   if (dsi->module_id == 0)
+   enable_shift = OMAP5_DSI1_LANEENABLE_SHIFT;
+   else if (dsi->module_id == 1)
+   enable_shift = OMAP5_DSI2_LANEENABLE_SHIFT;
+   else
+   return -ENODEV;
+
+   return regmap_update_bits(dsi->syscon, OMAP5_DSIPHY_SYSCON_OFFSET,
+   OMAP5_DSI_LANEENABLE_MASK << enable_shift,
+   lanes << enable_shift);
+}
+
 static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)
 {
-   return dsi_omap4_mux_pads(dsi, lane_mask);
+   if (dsi->data->model == DSI_MODEL_OMAP4)
+   return dsi_omap4_mux_pads(dsi, lane_mask);
+   if (dsi->data->model == DSI_MODEL_OMAP5)
+   return dsi_omap5_mux_pads(dsi, lane_mask);
+   return 0;
 }
 
 static void dsi_disable_pads(struct dsi_data *dsi)
 {
-   dsi_omap4_mux_pads(dsi, 0);
+   if (dsi->data->model == DSI_MODEL_OMAP4)
+   dsi_omap4_mux_pads(dsi, 0);
+   else if (dsi->data->model == DSI_MODEL_OMAP5)
+   dsi_omap5_mux_pads(dsi, 0);
 }
 
 static int dsi_cio_init(struct platform_device *dsidev)
@@ -5471,14 +5499,17 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
 
dsi->module_id = d->id;
 
-   if (dsi->data->model == DSI_MODEL_OMAP4) {
+   if (dsi->data->model == DSI_MODEL_OMAP4 ||
+   dsi->data->model == DSI_MODEL_OMAP5) {
struct device_node *np;
 
/*
-* The OMAP4 display DT bindings don't reference the padconf
+* The OMAP4/5 display DT bindings don't reference the padconf
 * syscon. Our only option to retrieve it is to find it by name.
 */
-   np = of_find_node_by_name(NULL, "omap4_padconf_global");
+   np = of_find_node_by_name(NULL,
+   dsi->data->model == DSI_MODEL_OMAP4 ?
+   "omap4_padconf_global" : "omap5_padconf_global");
if (!np)
return -ENODEV;
 
-- 
2.7.4


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

[Christian König]

Am 09.08.2017 um 23:31 schrieb Chris Wilson:

Quoting Jason Ekstrand (2017-08-09 18:00:54)

+static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj 
**syncobjs,
+ uint32_t count,
+ uint32_t flags,
+ signed long timeout,
+ uint32_t *idx)
+{
+   struct syncobj_wait_entry *entries;
+   struct dma_fence *fence;
+   signed long ret;
+   uint32_t signaled_count, i;
+
+   if (timeout == 0) {
+   signaled_count = 0;
+   for (i = 0; i < count; ++i) {
+   ret = drm_syncobj_signaled(syncobjs[i], flags);
+   if (ret < 0)
+   return ret;
+   if (ret == 0)
+   continue;
+   if (signaled_count == 0 && idx)
+   *idx = i;
+   signaled_count++;
+   }
+
+   if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)
+   return signaled_count == count ? 1 : 0;
+   else
+   return signaled_count > 0 ? 1 : 0;

There's a very annoying laxness in the dma_fence API here, in that
backends are not required to automatically report when a fence is
signaled prior to fence->ops->enable_signaling() being called.
So here if we fail to match signaled_count, we need to fallthough and
try a 0 timeout wait!

Christian, dma_fence_wait_any_timeout() has this same bug you told me off
for, e.g. commit 698c0f7ff216 ("dma-buf/fence: revert "don't wait when
specified timeout is zero" (v2)")!


Thanks for pointing this out, going to take care of this issue.

Christian.


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



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

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

[Christian König]

Am 10.08.2017 um 01:53 schrieb Jason Ekstrand:
On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson > wrote:


Quoting Chris Wilson (2017-08-09 18:57:44)
> So we are taking a snapshot here. It looks like this could have been
> done using a dma_fence_array + dma_fence_proxy for capturing the
future
> fence.

A quick sketch of this idea looks like:

 void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence)
 {
-   struct dma_fence *old_fence;
+   unsigned long flags;

-   if (fence)
-   dma_fence_get(fence);
-   old_fence = xchg(>fence, fence);
-
-   dma_fence_put(old_fence);
+   spin_lock_irqsave(>lock, flags);
+   dma_fence_replace_proxy(>fence, fence);
+   spin_unlock_irqrestore(>lock, flags);
 }

+int
+drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private)
+{
+   struct drm_syncobj_wait *args = data;
+   struct dma_fence **fences;
+   struct dma_fence_array *array;
+   unsigned long timeout;
+   unsigned int count;
+   u32 *handles;
+   int ret = 0;
+   u32 i;
+
+   BUILD_BUG_ON(sizeof(*fences) < sizeof(*handles));
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->flags != 0 && args->flags !=
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)
+   return -EINVAL;
+
+   count = args->count_handles;
+   if (!count)
+   return -EINVAL;
+
+   /* Get the handles from userspace */
+   fences = kmalloc_array(count,
+  sizeof(struct dma_fence *),
+  __GFP_NOWARN | GFP_KERNEL);
+   if (!fences)
+   return -ENOMEM;
+
+   handles = (void *)fences + count * (sizeof(*fences) -
sizeof(*handles));
+   if (copy_from_user(handles,
+ u64_to_user_ptr(args->handles),
+  sizeof(u32) * count)) {
+   ret = -EFAULT;
+   goto err;
+   }
+
+   for (i = 0; i < count; i++) {
+   struct drm_syncobj *s;
+
+   ret = -ENOENT;
+   s = drm_syncobj_find(file_private, handles[i]);
+   if (s) {
+   ret = 0;
+   spin_lock_irq(>lock);
+   if (!s->fence) {
+   if (args->flags &
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)
+   s->fence =
dma_fence_create_proxy();
+   else
+   ret = -EINVAL;
+   }
+   if (s->fence)
+   fences[i] = dma_fence_get(s->fence);
+   spin_unlock_irq(>lock);
+   }
+   if (ret) {
+   count = i;
+   goto err_fences;
+   }
+   }
+
+   array = dma_fence_array_create(count, fences, 0, 0,
+  !(args->flags &
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL));
+   if (!array) {
+   ret = -ENOMEM;
+   goto err_fences;
+   }
+
+   timeout = drm_timeout_abs_to_jiffies(args->timeout_nsec);
+   timeout = dma_fence_wait_timeout(>base, true, timeout);
+   args->first_signaled = array->first_signaled;
+   dma_fence_put(>base);
+
+   return timeout < 0 ? timeout : 0;
+
+err_fences:
+   for (i = 0; i < count; i++)
+   dma_fence_put(fences[i]);
+err:
+   kfree(fences);
+   return ret;
+}

The key advantage is that this translate the ioctl into a
dma-fence-array
which already has to deal with the mess, sharing the burden. (But it
does require a trivial patch to dma-fence-array to record the first
signaled fence.)

However, this installs the proxy into syncobj->fence with the result
that any concurrent wait also become a WAIT_FOR_SUBMIT. The behaviour
of drm_syncobj is then quite inconsistent, sometimes it will wait
for a
future fence, sometimes it will report an error.


Yeah, that's not good.  I thought about a variety of solutions to try 
and re-use more core dma_fence code.  Ultimately I chose the current 
one because it takes a snapshot of the syncobjs and then, from that 
point forward, it's consistent with its snapshot.  Nothing I was able 
to come up with based on core dma_fence wait routines does that.


As Chris 

[PATCH] drm/amdgpu: potential shift wrapping bug

[Dan Carpenter]

"frag_align" is a u64, so presumably we want to use the high bits as
well instead of shift wrapping.

Fixes: 6be7adb37d9b ("drm/amdgpu: increase fragmentation size for Vega10 v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ba0407d12525..d9a8e942ac3b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1459,7 +1459,7 @@ static int amdgpu_vm_frag_ptes(struct 
amdgpu_pte_update_params*params,
/* SI and newer are optimized for 64KB */
unsigned pages_per_frag = AMDGPU_LOG2_PAGES_PER_FRAG(params->adev);
uint64_t frag_flags = AMDGPU_PTE_FRAG(pages_per_frag);
-   uint64_t frag_align = 1 << pages_per_frag;
+   uint64_t frag_align = 1ULL << pages_per_frag;
 
uint64_t frag_start = ALIGN(start, frag_align);
uint64_t frag_end = end & ~(frag_align - 1);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] exynos: change the license to X11/MIT

[Tobias Jakobi]

Hello,

some comments first.

- What is this license checker and why should we care about it?
- If multiple licenses are really the problem, we could also change it to GPLv3.
But you want to change it to X11/MIT, so you should clarify this particular
choice. You kinda did this in [1], but it's totally missing here.

More comments inline.

With these changes you have my
Acked-by: Tobias Jakobi 

- Tobias


[1] http://www.spinics.net/lists/linux-samsung-soc/msg59230.html

Inki Dae wrote:
> Chnage GPL license of Exynos relevant code to X11/MIT.
"Chnage" -> "Change"
"relevant" -> "related"


> I'd like to keep license consistency to all Exynos code
...to keep a consistent license across all...


> because License checker notices two more licenses exist
> in libdrm.
> 
> For the license change I need to get your agree - all committers.
> So please give me Acked-by if you agree with me.
> 
> Signed-off-by: Inki Dae 
> Acked-by: Hyungwon Hwang 
> Acked-by: SooChan Lim 
> Acked-by: Sangjin LEE 
> Acked-by: Boram Park 
> Acked-by: Seung-Woo Kim 
> Acked-by: Joonyoung Shim 
> Acked-by: Emil Velikov 
> ---
>  exynos/exynos_fimg2d.c | 21 +
>  exynos/exynos_fimg2d.h | 21 +
>  exynos/fimg2d_reg.h| 21 +
>  libkms/exynos.c| 22 ++
>  tests/exynos/exynos_fimg2d_event.c | 27 +--
>  tests/exynos/exynos_fimg2d_perf.c  | 27 +--
>  tests/exynos/exynos_fimg2d_test.c  | 21 +
>  7 files changed, 120 insertions(+), 40 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 61340c3..5658a48 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -3,11 +3,24 @@
>   * Authors:
>   *   Inki Dae 
>   *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
>   *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifdef HAVE_CONFIG_H
> diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
> index a825c68..a4dfbe7 100644
> --- a/exynos/exynos_fimg2d.h
> +++ b/exynos/exynos_fimg2d.h
> @@ -3,11 +3,24 @@
>   * Authors:
>   *   Inki Dae 
>   *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
>   *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * VA LINUX SYSTEMS 

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

[Chris Wilson]

Quoting Jason Ekstrand (2017-08-10 00:53:00)
> On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson  wrote:
> However, this installs the proxy into syncobj->fence with the result
> that any concurrent wait also become a WAIT_FOR_SUBMIT. The behaviour
> of drm_syncobj is then quite inconsistent, sometimes it will wait for a
> future fence, sometimes it will report an error.
> 
> 
> Yeah, that's not good.  I thought about a variety of solutions to try and
> re-use more core dma_fence code.  Ultimately I chose the current one because 
> it
> takes a snapshot of the syncobjs and then, from that point forward, it's
> consistent with its snapshot.  Nothing I was able to come up with based on 
> core
> dma_fence wait routines does that.

So if we choose to keep the proxy local to the fence-array and not replace
syncobj->fence, we can still reduce this to a plain dma-fence-array +
wait.

Pertinent details:

+static void syncobj_notify(struct drm_syncobj *syncobj, struct dma_fence 
*fence)
+{
+   struct drm_syncobj_cb *cb, *cn;
+   unsigned long flags;
+
+   /* This is just an opencoded waitqueue; FIXME! */
+   spin_lock_irqsave(>lock, flags);
+   list_for_each_entry_safe(cb, cn, >cb_list, link)
+   cb->func(cb, fence);
+   INIT_LIST_HEAD(>cb_list);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 /**
  * drm_syncobj_replace_fence - replace fence in a sync object.
  * @syncobj: Sync object to replace fence in
@@ -89,7 +109,10 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
 
if (fence)
dma_fence_get(fence);
+
old_fence = xchg(>fence, fence);
+   if (!old_fence && fence)
+   syncobj_notify(syncobj, fence);
 
dma_fence_put(old_fence);
 }
@@ -124,6 +147,9 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
   struct drm_syncobj,
   refcount);
+
+   syncobj_notify(syncobj, NULL);
+
dma_fence_put(syncobj->fence);
kfree(syncobj);
 }
@@ -140,6 +166,8 @@ static int drm_syncobj_create(struct drm_file *file_private,
return -ENOMEM;
 
kref_init(>refcount);
+   spin_lock_init(>lock);
+   INIT_LIST_HEAD(>cb_list);
 
idr_preload(GFP_KERNEL);
spin_lock(_private->syncobj_table_lock);

struct future_fence {
+   struct drm_syncobj_cb base;
+   struct dma_fence **slot;
+};
+
+static void future_fence_cb(struct drm_syncobj_cb *cb, struct dma_fence *fence)
+{
+   struct future_fence *ff = container_of(cb, typeof(*ff), base);
+
+   if (fence)
+   dma_fence_replace_proxy(ff->slot, fence);
+   else
+   dma_fence_signal(*ff->slot);
+
+   kfree(ff);
+}
+
+int
+drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private)
+{
+   struct drm_syncobj_wait *args = data;
+   struct dma_fence_array *array;
+   struct dma_fence **fences;
+   unsigned int count, i;
+   long timeout;
+   u32 *handles;
+   int ret;
+
+   BUILD_BUG_ON(sizeof(*fences) < sizeof(*handles));
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL |
+   DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+   return -EINVAL;
+
+   count = args->count_handles;
+   if (!count)
+   return -EINVAL;
+
+   /* Get the handles from userspace */
+   fences = kmalloc_array(count,
+  sizeof(struct dma_fence *),
+  __GFP_NOWARN | GFP_KERNEL);
+   if (!fences)
+   return -ENOMEM;
+
+   handles = (void *)fences + count * (sizeof(*fences) - sizeof(*handles));
+   if (copy_from_user(handles,
+  u64_to_user_ptr(args->handles),
+  sizeof(u32) * count)) {
+   ret = -EFAULT;
+   goto err;
+   }
+
+   for (i = 0; i < count; i++) {
+   struct drm_syncobj *s;
+
+   ret = -ENOENT;
+   s = drm_syncobj_find(file_private, handles[i]);
+   if (s) {
+   ret = 0;
+   spin_lock_irq(>lock);
+   if (s->fence) {
+   fences[i] = dma_fence_get(s->fence);
+   } else if (args->flags & 
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
+   struct future_fence *cb;
+
+   cb = kmalloc(sizeof(*cb), GFP_KERNEL);
+   fences[i] = dma_fence_create_proxy();
+   if (cb && fences[i]) {
+   cb->slot = [i];
+   

Re: [PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

[Chris Wilson]

Quoting Jason Ekstrand (2017-08-10 01:31:52)
> 
> 
> On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson  wrote:
> 
> Quoting Jason Ekstrand (2017-08-08 23:46:02)
> > The atomic exchange operation we were doing before in replace_fence was
> > sufficient for the case where it raced with itself.  However, if you
> > have a race between a replace_fence and dma_fence_get(syncobj->fence),
> > you may end up with the entire replace_fence happening between the point
> > in time where the one thread gets the syncobj->fence pointer and when it
> > calls dma_fence_get() on it.  If this happens, then the reference may be
> > dropped before we get a chance to get a new one.
> 
> This doesn't require a spinlock, just dma_fence_get_rcu_safe(). The
> argument for keeping this patch lies in the merit of later patches..
> 
> 
> Doesn't that also require that we start using an RCU for syncobj?  That was my
> interpretation of the hieroglyphics above the definition of get_rcu_safe()

That we use RCU for the fence, which we do. i.e. so that the fence
pointer remains valid during the atomic_inc_unless_zero. The caller is
responsible for making sure that the syncobj remains valid across the
call (which we do using a ref, but it too could use RCU if that was ever
desired).
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2] drm/omap: add OMAP5 DSIPHY lane-enable support

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 10 Aug 2017 12:44:01 Tomi Valkeinen wrote:
> We are missing OMAP5 DSIPHY lane-enable support, which has prevented
> OMAP5 DSI working in mainline. This patch adds the lane-enable similarly
> to the recently added OMAP4 version.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
> 
> Changes:
> 
> - Fixed the check for DSI model
> - Use else if
> - Drop the unnecessary syscon check
> 
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 50 +---
>  1 file changed, 42 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c index a66d2b1a6c74..889f2d30050b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2109,9 +2109,6 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi,
> unsigned int lanes) u32 pipd_mask, pipd_shift;
>   u32 reg;
> 
> - if (!dsi->syscon)
> - return 0;
> -
>   if (dsi->module_id == 0) {
>   enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
>   enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
> @@ -2139,14 +2136,48 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi,
> unsigned int lanes) return 0;
>  }
> 
> +#define OMAP5_DSIPHY_SYSCON_OFFSET   0x74
> +
> +#define OMAP5_DSI1_LANEENABLE_SHIFT  24
> +#define OMAP5_DSI2_LANEENABLE_SHIFT  19
> +#define OMAP5_DSI_LANEENABLE_MASK0x1f
> +
> +static int dsi_omap5_mux_pads(struct dsi_data *dsi, unsigned int lanes)
> +{
> + u32 enable_mask, enable_shift, reg;
> +
> + if (dsi->module_id == 0)
> + enable_shift = OMAP5_DSI1_LANEENABLE_SHIFT;
> + else if (dsi->module_id == 1)
> + enable_shift = OMAP5_DSI2_LANEENABLE_SHIFT;
> + else
> + return -ENODEV;
> +
> + enable_mask = OMAP5_DSI_LANEENABLE_MASK << enable_shift;
> +
> + regmap_read(dsi->syscon, OMAP5_DSIPHY_SYSCON_OFFSET, );
> + reg &= ~enable_mask;
> + reg |= (lanes << enable_shift) & enable_mask;
> + regmap_write(dsi->syscon, OMAP5_DSIPHY_SYSCON_OFFSET, reg);

I should have spot that during the first review, but I think 
regmap_update_bits() would be more efficient, and would also benefit from 
internal regmap locking.

Apart from that,

Reviewed-by: Laurent Pinchart 

> +
> + return 0;
> +}
> +
>  static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)
>  {
> - return dsi_omap4_mux_pads(dsi, lane_mask);
> + if (dsi->data->model == DSI_MODEL_OMAP4)
> + return dsi_omap4_mux_pads(dsi, lane_mask);
> + if (dsi->data->model == DSI_MODEL_OMAP5)
> + return dsi_omap5_mux_pads(dsi, lane_mask);
> + return 0;
>  }
> 
>  static void dsi_disable_pads(struct dsi_data *dsi)
>  {
> - dsi_omap4_mux_pads(dsi, 0);
> + if (dsi->data->model == DSI_MODEL_OMAP4)
> + dsi_omap4_mux_pads(dsi, 0);
> + else if (dsi->data->model == DSI_MODEL_OMAP5)
> + dsi_omap5_mux_pads(dsi, 0);
>  }
> 
>  static int dsi_cio_init(struct platform_device *dsidev)
> @@ -5480,14 +5511,17 @@ static int dsi_bind(struct device *dev, struct
> device *master, void *data)
> 
>   dsi->module_id = d->id;
> 
> - if (dsi->data->model == DSI_MODEL_OMAP4) {
> + if (dsi->data->model == DSI_MODEL_OMAP4 ||
> + dsi->data->model == DSI_MODEL_OMAP5) {
>   struct device_node *np;
> 
>   /*
> -  * The OMAP4 display DT bindings don't reference the padconf
> +  * The OMAP4/5 display DT bindings don't reference the padconf
>* syscon. Our only option to retrieve it is to find it by 
name.
>*/
> - np = of_find_node_by_name(NULL, "omap4_padconf_global");
> + np = of_find_node_by_name(NULL,
> + dsi->data->model == DSI_MODEL_OMAP4 ?
> + "omap4_padconf_global" : "omap5_padconf_global");
>   if (!np)
>   return -ENODEV;

-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/sun4i: use of_graph_get_remote_endpoint()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
---
- Not tested

 drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index cf48021..ec59436 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -312,7 +312,7 @@ static int sun4i_backend_of_get_id(struct device_node *node)
struct device_node *remote;
u32 reg;
 
-   remote = of_parse_phandle(ep, "remote-endpoint", 0);
+   remote = of_graph_get_remote_endpoint(ep);
if (!remote)
continue;
 
-- 
1.9.1

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

Re: [PATCH 0/3] drm: make drm_connector_funcs structures const

[Bhumika Goyal]

On Wed, Aug 9, 2017 at 10:07 PM, Daniel Vetter  wrote:
> On Wed, Aug 09, 2017 at 04:02:45PM +0530, Archit Taneja wrote:
>>
>>
>> On 08/08/2017 04:58 PM, Bhumika Goyal wrote:
>> > Declare drm_connector_funcs structures as const.
>>
>> Could you rebase this series over the latest drm-misc-next? The
>> recently merged patch "drm: Nuke drm_atomic_helper_connector_dpms"
>> causes conflicts with these.
>
> I got bored and fixed up the conflicts (wiggle pulled it off). All
> applied, no need to resend.
>

Thank you :)

Thanks,
Bhumika

> Thanks, Daniel
>
>>
>> drm-misc-next:
>>
>> https://cgit.freedesktop.org/drm/drm-misc/log/
>>
>> Thanks,
>> Archit
>>
>> >
>> > Bhumika Goyal (3):
>> >drm/bridge: make drm_connector_funcs structures const
>> >drm/sun4i: make drm_connector_funcs structures const
>> >drm/rockchip: make drm_connector_funcs structures const
>> >
>> >   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
>> >   drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
>> >   drivers/gpu/drm/sun4i/sun4i_rgb.c| 2 +-
>> >   drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +-
>> >   4 files changed, 4 insertions(+), 4 deletions(-)
>> >
>>
>> --
>> 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
>
> --
> 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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

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

--- Comment #27 from Samuel Pitoiset  ---
An apitrace that reproduces the issue would be very useful.

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

Re: [PATCH 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

sorry, it's a wrong email, send the v1 patch ,please ignore.

在 2017/8/10 17:49, Sandy Huang 写道:

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
  drivers/gpu/drm/rockchip/Kconfig |   9 +
  drivers/gpu/drm/rockchip/Makefile|   1 +
  drivers/gpu/drm/rockchip/rockchip_lvds.c | 734 +++
  drivers/gpu/drm/rockchip/rockchip_lvds.h | 112 +
  4 files changed, 856 insertions(+)
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  
  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o

diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..a4ad3f0
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,734 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+#define LVDS_CHIP(lvds)((lvds)->soc_data->chip_type)
+
+/*
+ * @grf_offset: offset inside the grf regmap for setting the rockchip lvds
+ */
+struct rockchip_lvds_soc_data {
+   int chip_type;
+   int grf_soc_con6;
+   int grf_soc_con7;
+
+   bool has_vop_sel;
+};
+
+struct rockchip_lvds {
+   void *base;
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *grf;
+   struct clk *pclk;
+   const struct rockchip_lvds_soc_data *soc_data;
+
+   int output;
+   int format;
+
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+
+   struct mutex suspend_lock;
+   int suspend;
+   struct dev_pin_info *pins;
+   struct drm_display_mode mode;
+};
+
+static inline void lvds_writel(struct rockchip_lvds *lvds, u32 offset, u32 val)
+{
+   writel_relaxed(val, lvds->regs + offset);
+   if ((lvds->output != DISPLAY_OUTPUT_LVDS) &&
+(LVDS_CHIP(lvds) == RK3288_LVDS))
+   writel_relaxed(val,
+  lvds->regs + offset + RK3288_LVDS_CH1_OFFSET);
+}
+
+static inline int lvds_name_to_format(const char *s)
+{
+   if (!s)
+   return -EINVAL;
+
+   if (strncmp(s, "jeida", 6) == 0)
+   return LVDS_FORMAT_JEIDA;
+   else if (strncmp(s, "vesa", 5) == 0)
+  

[PATCH v2 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
Changes according to Sean Paul's reviews.

 drivers/gpu/drm/rockchip/Kconfig |   9 +
 drivers/gpu/drm/rockchip/Makefile|   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 667 +++
 drivers/gpu/drm/rockchip/rockchip_lvds.h | 109 +
 4 files changed, 786 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..36b4911
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,667 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../drm_crtc_internal.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+
+/**
+ * rockchip_lvds_soc_data - rockchip lvds Soc private data
+ * @ch1_offset: lvds channel 1 registe offset
+ * grf_soc_con6: general registe offset for LVDS contrl
+ * grf_soc_con7: general registe offset for LVDS contrl
+ * has_vop_sel: to indicate whether need to choose from different VOP.
+ */
+struct rockchip_lvds_soc_data {
+   u32 ch1_offset;
+   int grf_soc_con6;
+   int grf_soc_con7;
+   bool has_vop_sel;
+};
+
+struct rockchip_lvds {
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *grf;
+   struct clk *pclk;
+   const struct rockchip_lvds_soc_data *soc_data;
+   int output; /* rgb lvds or dual lvds output */
+   int format; /* vesa or jeida format */
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+   struct dev_pin_info *pins;
+   struct drm_display_mode mode;
+};
+
+static inline void lvds_writel(struct rockchip_lvds *lvds, u32 offset, u32 val)
+{
+   writel_relaxed(val, lvds->regs + offset);
+   if (lvds->output == DISPLAY_OUTPUT_LVDS)
+   return;
+   writel_relaxed(val, lvds->regs + offset + lvds->soc_data->ch1_offset);
+}
+
+static inline int lvds_name_to_format(const char *s)
+{
+   if (strncmp(s, "jeida", 6) == 0)
+   return LVDS_FORMAT_JEIDA;
+   else if (strncmp(s, "vesa", 5) == 0)
+   return 

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

On 10/08/17 11:08, Archit Taneja wrote:
> 
> 
> On 08/10/2017 02:26 PM, Hans Verkuil wrote:
>> On 10/08/17 10:49, Archit Taneja wrote:
>>> Hi Hans,
>>>
>>> On 07/30/2017 06:37 PM, Hans Verkuil wrote:
 From: Hans Verkuil 

 This patch series adds CEC support to the drm adv7511/adv7533 drivers.

 I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
 and the Renesas R-Car Koelsch board (adv7511 based).

 Note: the Dragonboard needs this patch:

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

 Archit, can you confirm that this patch will go to kernel 4.14?

 And the Koelsch board needs this 4.13 fix:

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

 I only have the Koelsch board to test with, but it looks like other
 R-Car boards use the same adv7511. It would be nice if someone can
 add CEC support to the other R-Car boards as well. The main thing
 to check is if they all use the same 12 MHz fixed CEC clock source.

 Anyone who wants to test this will need the CEC utilities that
 are part of the v4l-utils git repository:

 git clone git://linuxtv.org/v4l-utils.git
 cd v4l-utils
 ./bootstrap.sh
 ./configure
 make
 sudo make install

 Now configure the CEC adapter as a Playback device:

 cec-ctl --playback

 Discover other CEC devices:

 cec-ctl -S
>>>
>>> I tried the instructions, and I get the following output. I don't think I 
>>> have
>>> any CEC device connected, though. Is this the expected behaviour?
>>>
>>> #cec-ctl -S
>>> Driver Info:
>>>  Driver Name: adv7511
>>>  Adapter Name   : 3-0039
>>>  Capabilities   : 0x000e
>>>  Logical Addresses
>>>  Transmit
>>>  Passthrough
>>>  Driver version : 4.13.0
>>>  Available Logical Addresses: 3
>>>  Physical Address   : 1.0.0.0
>>>  Logical Address Mask   : 0x
>>>  CEC Version: 2.0
>>>  Logical Addresses  : 0
>>>
>>> #cec-ctl --playback
>>> [ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!
>>
>> This isn't right. You shouldn't see this. It never receives an interrupt
>> when the transmit has finished, which causes these time outs.
>>
>> What are you testing this on? The Dragonboard c410?
> 
> Yes.

On top of which kernel tree are these patches applied? I can try and reproduce
it.

Regards,

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

[PATCH 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/Kconfig |   9 +
 drivers/gpu/drm/rockchip/Makefile|   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 734 +++
 drivers/gpu/drm/rockchip/rockchip_lvds.h | 112 +
 4 files changed, 856 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..a4ad3f0
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,734 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+#define LVDS_CHIP(lvds)((lvds)->soc_data->chip_type)
+
+/*
+ * @grf_offset: offset inside the grf regmap for setting the rockchip lvds
+ */
+struct rockchip_lvds_soc_data {
+   int chip_type;
+   int grf_soc_con6;
+   int grf_soc_con7;
+
+   bool has_vop_sel;
+};
+
+struct rockchip_lvds {
+   void *base;
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *grf;
+   struct clk *pclk;
+   const struct rockchip_lvds_soc_data *soc_data;
+
+   int output;
+   int format;
+
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+
+   struct mutex suspend_lock;
+   int suspend;
+   struct dev_pin_info *pins;
+   struct drm_display_mode mode;
+};
+
+static inline void lvds_writel(struct rockchip_lvds *lvds, u32 offset, u32 val)
+{
+   writel_relaxed(val, lvds->regs + offset);
+   if ((lvds->output != DISPLAY_OUTPUT_LVDS) &&
+(LVDS_CHIP(lvds) == RK3288_LVDS))
+   writel_relaxed(val,
+  lvds->regs + offset + RK3288_LVDS_CH1_OFFSET);
+}
+
+static inline int lvds_name_to_format(const char *s)
+{
+   if (!s)
+   return -EINVAL;
+
+   if (strncmp(s, "jeida", 6) == 0)
+   return LVDS_FORMAT_JEIDA;
+   else if (strncmp(s, "vesa", 5) == 0)
+   return LVDS_FORMAT_VESA;
+
+   return -EINVAL;
+}
+
+static inline int lvds_name_to_output(const char *s)

[radeon-alex:amd-staging-4.12 1309/1353] drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:78:25: fatal error: asm/fpu/api.h: No such file or directory

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.12
head:   06b85147cc7f49f13e7bceb2ec97c51712c6a3f0
commit: 0cea20904755da7896bdd4ef95b894f0c6c41b6a [1309/1353] drm/amd/display: 
remove DCN1 guard as DCN1 is already open sourced.
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0cea20904755da7896bdd4ef95b894f0c6c41b6a
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/modules/inc/mod_freesync.h:57:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:48,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:52,
from drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:44:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:78:25: fatal error: 
>> asm/fpu/api.h: No such file or directory
#include 
^
   compilation terminated.

vim +78 drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h

052d140d Harry Wentland 2017-06-21  77  
9902d98f Alex Deucher   2017-06-15 @78  #include 
9902d98f Alex Deucher   2017-06-15  79  

:: The code at line 78 was first introduced by commit
:: 9902d98f0a29db2322c06bf5b0b489c77e7a50ba drm/amdgpu/display: Enable DCN 
in DC

:: TO: Alex Deucher 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2] drm/omap: add OMAP5 DSIPHY lane-enable support

[Tomi Valkeinen]

We are missing OMAP5 DSIPHY lane-enable support, which has prevented
OMAP5 DSI working in mainline. This patch adds the lane-enable similarly
to the recently added OMAP4 version.

Signed-off-by: Tomi Valkeinen 
---

Changes:

- Fixed the check for DSI model
- Use else if
- Drop the unnecessary syscon check

 drivers/gpu/drm/omapdrm/dss/dsi.c | 50 ---
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index a66d2b1a6c74..889f2d30050b 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -2109,9 +2109,6 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi, 
unsigned int lanes)
u32 pipd_mask, pipd_shift;
u32 reg;
 
-   if (!dsi->syscon)
-   return 0;
-
if (dsi->module_id == 0) {
enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
@@ -2139,14 +2136,48 @@ static int dsi_omap4_mux_pads(struct dsi_data *dsi, 
unsigned int lanes)
return 0;
 }
 
+#define OMAP5_DSIPHY_SYSCON_OFFSET 0x74
+
+#define OMAP5_DSI1_LANEENABLE_SHIFT24
+#define OMAP5_DSI2_LANEENABLE_SHIFT19
+#define OMAP5_DSI_LANEENABLE_MASK  0x1f
+
+static int dsi_omap5_mux_pads(struct dsi_data *dsi, unsigned int lanes)
+{
+   u32 enable_mask, enable_shift, reg;
+
+   if (dsi->module_id == 0)
+   enable_shift = OMAP5_DSI1_LANEENABLE_SHIFT;
+   else if (dsi->module_id == 1)
+   enable_shift = OMAP5_DSI2_LANEENABLE_SHIFT;
+   else
+   return -ENODEV;
+
+   enable_mask = OMAP5_DSI_LANEENABLE_MASK << enable_shift;
+
+   regmap_read(dsi->syscon, OMAP5_DSIPHY_SYSCON_OFFSET, );
+   reg &= ~enable_mask;
+   reg |= (lanes << enable_shift) & enable_mask;
+   regmap_write(dsi->syscon, OMAP5_DSIPHY_SYSCON_OFFSET, reg);
+
+   return 0;
+}
+
 static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)
 {
-   return dsi_omap4_mux_pads(dsi, lane_mask);
+   if (dsi->data->model == DSI_MODEL_OMAP4)
+   return dsi_omap4_mux_pads(dsi, lane_mask);
+   if (dsi->data->model == DSI_MODEL_OMAP5)
+   return dsi_omap5_mux_pads(dsi, lane_mask);
+   return 0;
 }
 
 static void dsi_disable_pads(struct dsi_data *dsi)
 {
-   dsi_omap4_mux_pads(dsi, 0);
+   if (dsi->data->model == DSI_MODEL_OMAP4)
+   dsi_omap4_mux_pads(dsi, 0);
+   else if (dsi->data->model == DSI_MODEL_OMAP5)
+   dsi_omap5_mux_pads(dsi, 0);
 }
 
 static int dsi_cio_init(struct platform_device *dsidev)
@@ -5480,14 +5511,17 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
 
dsi->module_id = d->id;
 
-   if (dsi->data->model == DSI_MODEL_OMAP4) {
+   if (dsi->data->model == DSI_MODEL_OMAP4 ||
+   dsi->data->model == DSI_MODEL_OMAP5) {
struct device_node *np;
 
/*
-* The OMAP4 display DT bindings don't reference the padconf
+* The OMAP4/5 display DT bindings don't reference the padconf
 * syscon. Our only option to retrieve it is to find it by name.
 */
-   np = of_find_node_by_name(NULL, "omap4_padconf_global");
+   np = of_find_node_by_name(NULL,
+   dsi->data->model == DSI_MODEL_OMAP4 ?
+   "omap4_padconf_global" : "omap5_padconf_global");
if (!np)
return -ENODEV;
 
-- 
2.7.4


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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

Re: [PATCH 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

Hi Sean Paul,
Thanks for your review.

在 2017/8/10 3:58, Sean Paul 写道:

On Wed, Aug 09, 2017 at 06:00:59PM +0800, Sandy Huang wrote:

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
  drivers/gpu/drm/rockchip/Kconfig |   9 +
  drivers/gpu/drm/rockchip/Makefile|   1 +
  drivers/gpu/drm/rockchip/rockchip_lvds.c | 734 +++
  drivers/gpu/drm/rockchip/rockchip_lvds.h | 112 +
  4 files changed, 856 insertions(+)
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  
  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o

diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..a4ad3f0
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,734 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+#define LVDS_CHIP(lvds)((lvds)->soc_data->chip_type)
+
+/*
+ * @grf_offset: offset inside the grf regmap for setting the rockchip lvds


You only document one member and it doesn't exist :(

I forgot to delete it, i will update at next version.



+ */
+struct rockchip_lvds_soc_data {
+   int chip_type;
+   int grf_soc_con6;
+   int grf_soc_con7;
+
+   bool has_vop_sel;
+};
+
+struct rockchip_lvds {
+   void *base;
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *grf;
+   struct clk *pclk;
+   const struct rockchip_lvds_soc_data *soc_data;
+
+   int output;
+   int format;
+
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+
+   struct mutex suspend_lock;
+   int suspend;
+   struct dev_pin_info *pins;
+   struct drm_display_mode mode;
+};
+
+static inline void lvds_writel(struct rockchip_lvds *lvds, u32 offset, u32 val)
+{
+   writel_relaxed(val, lvds->regs + offset);
+   if ((lvds->output != DISPLAY_OUTPUT_LVDS) &&
+(LVDS_CHIP(lvds) == RK3288_LVDS))


Given that you only support one chip right now, it seems premature to worry
about chip version. At any rate, it seems like it'd be more useful to store
RK3288_LVDS_CHI_OFFSET in soc_data and do:

if (lvds->output 

Re: [PATCH] drm/amdgpu: Uninitialized variable in amdgpu_ttm_backend_bind()

[Christian König]

Am 10.08.2017 um 07:34 schrieb Alex Deucher:

On Wed, Aug 9, 2017 at 10:16 PM, Michel Dänzer  wrote:

On 09/08/17 07:30 PM, Dan Carpenter wrote:

My static checker complains that it's possible for "r" to be
uninitialized.  It used to be set to zero so this returns it to the old
behavior.

Fixes: 98a7f88ce9a9 ("drm/amdgpu: bind BOs with GTT space allocated directly 
v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e6f9a54c959d..b5f2a08757d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -753,7 +753,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_tt *ttm,
  struct ttm_mem_reg *bo_mem)
  {
   struct amdgpu_ttm_tt *gtt = (void*)ttm;
- int r;
+ int r = 0;

   if (gtt->userptr) {
   r = amdgpu_ttm_tt_pin_userptr(ttm);

Reviewed-by: Michel Dänzer 

Applied.  thanks!


For what's worth Reviewed-by: Christian König  
as well.


Might as well explain some fallout people reported about this patch, 
going to ping them for testing.


Christian.



Alex
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

On 08/10/2017 02:26 PM, Hans Verkuil wrote:

On 10/08/17 10:49, Archit Taneja wrote:

Hi Hans,

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

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

Archit, can you confirm that this patch will go to kernel 4.14?

And the Koelsch board needs this 4.13 fix:

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

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S


I tried the instructions, and I get the following output. I don't think I have
any CEC device connected, though. Is this the expected behaviour?

#cec-ctl -S
Driver Info:
 Driver Name: adv7511
 Adapter Name   : 3-0039
 Capabilities   : 0x000e
 Logical Addresses
 Transmit
 Passthrough
 Driver version : 4.13.0
 Available Logical Addresses: 3
 Physical Address   : 1.0.0.0
 Logical Address Mask   : 0x
 CEC Version: 2.0
 Logical Addresses  : 0

#cec-ctl --playback
[ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!


This isn't right. You shouldn't see this. It never receives an interrupt
when the transmit has finished, which causes these time outs.

What are you testing this on? The Dragonboard c410?


Yes.



Can you check the cec clock frequency? It should be 19.2 MHz.
Remember to apply this patch: https://patchwork.kernel.org/patch/9824773/
You probably did, but just in case...


clk_summary does show bb_clk2 to be set to 19.2 Mhz.

I applied a newer version of this patch, which got merged in clk-next:

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

I will try to apply the patch you use and check again.

Thanks,
Archit



Regards,

Hans


Driver Info:
 Driver Name: adv7511
 Adapter Name   : 3-0039
 Capabilities   : 0x000e
 Logical Addresses
 Transmit
 Passthrough
 Driver version : 4.13.0
 Available Logical Addresses: 3
 Physical Address   : 1.0.0.0
 Logical Address Mask   : 0x0010
 CEC Version: 2.0
 Vendor ID  : 0x000c03
 Logical Addresses  : 1 (Allow RC Passthrough)

   Logical Address  : 4
 Primary Device Type: Playback
 Logical Address Type   : Playback
 All Device Types   : Playback
 RC TV Profile  : None
 Device Features:
 None


[ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed out!
[ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!

Thanks,
Archit



Regards,

 Hans

Hans Verkuil (4):
dt-bindings: adi,adv7511.txt: document cec clock
arm: dts: qcom: add cec clock for apq8016 board
arm: dts: renesas: add cec clock for Koelsch board
drm: adv7511/33: add HDMI CEC support

   .../bindings/display/bridge/adi,adv7511.txt|   4 +
   arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
   drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
   drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 
+
   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
   9 files changed, 514 insertions(+), 50 deletions(-)
   create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c





--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list

Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

[Daniel Vetter]

On Wed, Aug 09, 2017 at 04:13:05PM -0700, Joe Kniss wrote:
> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes  wrote:
> >
> > Den 09.08.2017 01.42, skrev Joe Kniss:
> >>
> >> Because all drivers currently use gem objects for framebuffer planes,
> >> the virtual create_handle() is not required.  This change adds a
> >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> >> create_handle() function pointer from drm_framebuffer_funcs.  The
> >> corresponding *_create_handle() function is removed from each driver.
> >>
> >> In many cases this change eliminates a struct *_framebuffer object,
> >> as the only need for the derived struct is the addition of the gem
> >> object pointer.
> >>
> >> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
> >>
> >> Signed-off-by: Joe Kniss 
> >> ---
> >
> >
> > Hi Joe,
> >
> > I'm also looking into adding gem objs to drm_framebuffer in this patch:
> > [PATCH v2 01/22] drm: Add GEM backed framebuffer library
> > https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
> >
> 
> Great.  There's only minimal overlap here.  I'll rebase this change on yours
> once it's in.

Even better than waiting: Reviewing each another's patches. Noralf has
commit rights and knows how driver-wide refactoring works, so you're all
covered to get this landed, if you provide a bit of review for the review
market :-)

Cheers, Daniel

> 
> > [...]
> >
> >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> index ade319d10e70..f5f011b910b1 100644
> >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> @@ -31,14 +31,9 @@
> >> #define DEFAULT_FBDEFIO_DELAY_MS 50
> >>   -struct drm_fb_cma {
> >> -   struct drm_framebuffer  fb;
> >> -   struct drm_gem_cma_object   *obj[4];
> >> -};
> >> -
> >>   struct drm_fbdev_cma {
> >> struct drm_fb_helperfb_helper;
> >> -   struct drm_fb_cma   *fb;
> >> +   struct drm_framebuffer  *fb;
> >
> >
> > This fb pointer isn't necessary, since fb_helper already has one.
> >
> 
> I'll remove it... but I am sure when I look deeper there will be more
> of these in the various drivers too.
> 
> > Noralf.
> >
> >
> 
> -joe
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 0/4] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

On 10/08/17 10:49, Archit Taneja wrote:
> Hi Hans,
> 
> On 07/30/2017 06:37 PM, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds CEC support to the drm adv7511/adv7533 drivers.
>>
>> I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
>> and the Renesas R-Car Koelsch board (adv7511 based).
>>
>> Note: the Dragonboard needs this patch:
>>
>> https://patchwork.kernel.org/patch/9824773/
>>
>> Archit, can you confirm that this patch will go to kernel 4.14?
>>
>> And the Koelsch board needs this 4.13 fix:
>>
>> https://patchwork.kernel.org/patch/9836865/
>>
>> I only have the Koelsch board to test with, but it looks like other
>> R-Car boards use the same adv7511. It would be nice if someone can
>> add CEC support to the other R-Car boards as well. The main thing
>> to check is if they all use the same 12 MHz fixed CEC clock source.
>>
>> Anyone who wants to test this will need the CEC utilities that
>> are part of the v4l-utils git repository:
>>
>> git clone git://linuxtv.org/v4l-utils.git
>> cd v4l-utils
>> ./bootstrap.sh
>> ./configure
>> make
>> sudo make install
>>
>> Now configure the CEC adapter as a Playback device:
>>
>> cec-ctl --playback
>>
>> Discover other CEC devices:
>>
>> cec-ctl -S
> 
> I tried the instructions, and I get the following output. I don't think I have
> any CEC device connected, though. Is this the expected behaviour?
> 
> #cec-ctl -S
> Driver Info:
> Driver Name: adv7511
> Adapter Name   : 3-0039
> Capabilities   : 0x000e
> Logical Addresses
> Transmit
> Passthrough
> Driver version : 4.13.0
> Available Logical Addresses: 3
> Physical Address   : 1.0.0.0
> Logical Address Mask   : 0x
> CEC Version: 2.0
> Logical Addresses  : 0
> 
> #cec-ctl --playback
> [ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!

This isn't right. You shouldn't see this. It never receives an interrupt
when the transmit has finished, which causes these time outs.

What are you testing this on? The Dragonboard c410?

Can you check the cec clock frequency? It should be 19.2 MHz.
Remember to apply this patch: https://patchwork.kernel.org/patch/9824773/
You probably did, but just in case...

Regards,

Hans

> Driver Info:
> Driver Name: adv7511
> Adapter Name   : 3-0039
> Capabilities   : 0x000e
> Logical Addresses
> Transmit
> Passthrough
> Driver version : 4.13.0
> Available Logical Addresses: 3
> Physical Address   : 1.0.0.0
> Logical Address Mask   : 0x0010
> CEC Version: 2.0
> Vendor ID  : 0x000c03
> Logical Addresses  : 1 (Allow RC Passthrough)
> 
>   Logical Address  : 4
> Primary Device Type: Playback
> Logical Address Type   : Playback
> All Device Types   : Playback
> RC TV Profile  : None
> Device Features:
> None
> 
> 
> [ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed 
> out!
> [ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!
> 
> Thanks,
> Archit
> 
>>
>> Regards,
>>
>> Hans
>>
>> Hans Verkuil (4):
>>dt-bindings: adi,adv7511.txt: document cec clock
>>arm: dts: qcom: add cec clock for apq8016 board
>>arm: dts: renesas: add cec clock for Koelsch board
>>drm: adv7511/33: add HDMI CEC support
>>
>>   .../bindings/display/bridge/adi,adv7511.txt|   4 +
>>   arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
>>   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
>>   drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
>>   drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
>>   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
>>   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 
>> +
>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
>>   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
>>   9 files changed, 514 insertions(+), 50 deletions(-)
>>   create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>>
> 

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

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

Hi Hans,

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

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

Archit, can you confirm that this patch will go to kernel 4.14?

And the Koelsch board needs this 4.13 fix:

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

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S


I tried the instructions, and I get the following output. I don't think I have
any CEC device connected, though. Is this the expected behaviour?

#cec-ctl -S
Driver Info:
Driver Name: adv7511
Adapter Name   : 3-0039
Capabilities   : 0x000e
Logical Addresses
Transmit
Passthrough
Driver version : 4.13.0
Available Logical Addresses: 3
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x
CEC Version: 2.0
Logical Addresses  : 0

#cec-ctl --playback
[ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!
Driver Info:
Driver Name: adv7511
Adapter Name   : 3-0039
Capabilities   : 0x000e
Logical Addresses
Transmit
Passthrough
Driver version : 4.13.0
Available Logical Addresses: 3
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x0010
CEC Version: 2.0
Vendor ID  : 0x000c03
Logical Addresses  : 1 (Allow RC Passthrough)

  Logical Address  : 4
Primary Device Type: Playback
Logical Address Type   : Playback
All Device Types   : Playback
RC TV Profile  : None
Device Features:
None


[ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed out!
[ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!

Thanks,
Archit



Regards,

Hans

Hans Verkuil (4):
   dt-bindings: adi,adv7511.txt: document cec clock
   arm: dts: qcom: add cec clock for apq8016 board
   arm: dts: renesas: add cec clock for Koelsch board
   drm: adv7511/33: add HDMI CEC support

  .../bindings/display/bridge/adi,adv7511.txt|   4 +
  arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
  drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 +
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
  9 files changed, 514 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c



--
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 4/4] drm: adv7511/33: add HDMI CEC support

[Archit Taneja]

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

Add support for HDMI CEC to the drm adv7511/adv7533 drivers.

The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.


Thanks for the patch. Some minor comments below.



Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/bridge/adv7511/Kconfig   |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile  |   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h |  45 +++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 314 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 152 +++--
  drivers/gpu/drm/bridge/adv7511/adv7533.c |  30 +--
  6 files changed, 500 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
  Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+   bool "ADV7511/33 HDMI CEC driver"
+   depends on DRM_I2C_ADV7511
+   select CEC_CORE
+   default y
+   help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
  adv7511-y := adv7511_drv.o
  adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
  adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..4fd7b14f619b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
  #define ADV7511_PACKET_GM(x)  ADV7511_PACKET(5, x)
  #define ADV7511_PACKET_SPARE(x)   ADV7511_PACKET(6, x)
  
+#define ADV7511_REG_CEC_TX_FRAME_HDR	0x00

+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN   0x10
+#define ADV7511_REG_CEC_TX_ENABLE  0x11
+#define ADV7511_REG_CEC_TX_RETRY   0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR   0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN   0x25
+#define ADV7511_REG_CEC_RX_ENABLE  0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK  0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1   0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
  enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
  };
  
+#define ADV7511_MAX_ADDRS 3

+
  struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,29 @@ struct adv7511 {
  
  	enum adv7511_type type;

struct platform_device *audio_pdev;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+   struct clk *cec_clk;
+   u32 cec_clk_freq;
  };
  
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC

+extern const struct cec_adap_ops adv7511_cec_adap_ops;
+
+void adv7511_cec_init(struct adv7511 *adv7511, unsigned int offset);
+int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
  #ifdef CONFIG_DRM_I2C_ADV7533
  void adv7533_dsi_power_on(struct adv7511 *adv);
  void adv7533_dsi_power_off(struct adv7511 *adv);
  void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
  int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
  int adv7533_attach_dsi(struct adv7511 *adv);
  void adv7533_detach_dsi(struct adv7511 *adv);
  int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +409,7 @@ static inline int adv7533_patch_registers(struct adv7511 
*adv)
return -ENODEV;
  }
  
-static inline void adv7533_uninit_cec(struct adv7511 *adv)

-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
  {
return -ENODEV;
  }
diff --git 

[PATCHv2 0/3] cec-gpio: add HDMI CEC GPIO-based driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for CEC implementations that use a pull-up
GPIO pin. While SoCs exist that do this, the primary use-case is to
turn a single-board computer into a cheap CEC debugger.

Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus
monitoring and do protocol analysis. And error injection is also
planned for the future.

Here is an example using the Raspberry Pi 3:

https://hverkuil.home.xs4all.nl/rpi3-cec.jpg

A patch for the Raspberry Pi 2B/3 is added below for reference.
It uses pin 7 aka BCM4 aka GPCLK0 on the GPIO pin header.

While this example is for the Rpi, this driver will work for any
SoC with a pull-up GPIO pin.

I have one question: is there a generic way to check/force the gpio
to pull-up mode? I have not found that, but I am no gpio-expert.

Regards,

Hans

Changes since v1:

- Updated the bindings doc to not refer to the driver, instead
  refer to the hardware.

Hans Verkuil (3):
  dt-bindings: document the CEC GPIO bindings
  cec-gpio: add HDMI CEC GPIO driver
  MAINTAINERS: add cec-gpio entry

 .../devicetree/bindings/media/cec-gpio.txt |  16 ++
 MAINTAINERS|   9 +
 drivers/media/platform/Kconfig |  10 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 190 +
 6 files changed, 228 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

-- 
2.13.2

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

[PATCHv2 1/3] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

From: Hans Verkuil 

Document the bindings for the cec-gpio module for hardware where the
CEC pin is connected to a GPIO pin.

Signed-off-by: Hans Verkuil 
---
 Documentation/devicetree/bindings/media/cec-gpio.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt

diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..e34a175468e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,16 @@
+* HDMI CEC GPIO-based hardware
+
+Use these bindings for HDMI CEC hardware where the CEC pin is hooked up
+to a pull-up GPIO pin.
+
+Required properties:
+  - compatible: value must be "cec-gpio"
+  - gpio: gpio that the CEC line is connected to
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 7 aka BCM4 aka GPCLK0 on the GPIO pin header:
+
+cec-gpio {
+   compatible = "cec-gpio";
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+};
-- 
2.13.2

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

[PATCHv2 2/3] cec-gpio: add HDMI CEC GPIO driver

[Hans Verkuil]

From: Hans Verkuil 

Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.

While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.

By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.

With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.

But of course it can also be used with any hardware project where the
HDMI CEC pin is hooked up to a pull-up gpio pin.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig |  10 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 190 +
 4 files changed, 203 insertions(+)
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d12dbc9..681507727259 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -537,6 +537,16 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config CEC_GPIO
+   tristate "Generic GPIO-based CEC driver"
+   depends on PREEMPT
+   select CEC_CORE
+   select CEC_PIN
+   ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..d01cc1886ad1 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/
 
 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
 
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile 
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c 
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..43e1d447ad98
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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 AUTHORS OR COPYRIGHT HOLDERS
+ * 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 
+
+struct cec_gpio {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+   int gpio;
+   int irq;
+   boolis_low;
+   boolhave_irq;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->is_low)
+   return false;
+   return gpio_get_value(cec->gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (!cec->is_low)
+   return;
+   cec->is_low = false;
+   gpio_direction_input(cec->gpio);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->is_low)
+   return;
+   if (WARN_ON_ONCE(cec->have_irq))
+   free_irq(cec->irq, cec);
+   cec->have_irq = false;
+   cec->is_low = true;
+   gpio_direction_output(cec->gpio, 0);
+}
+
+static irqreturn_t cec_gpio_irq_handler(int irq, void *priv)
+{
+   struct cec_gpio *cec = priv;
+
+   cec_pin_changed(cec->adap, gpio_get_value(cec->gpio));
+   return IRQ_HANDLED;
+}
+
+static bool cec_gpio_enable_irq(struct 

[PATCHv2 3/3] MAINTAINERS: add cec-gpio entry

[Hans Verkuil]

From: Hans Verkuil 

Add an entry for the CEC GPIO driver.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aeb84877854b..d85959f82a09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3199,6 +3199,15 @@ F:   include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 F: Documentation/devicetree/bindings/media/cec.txt
 
+CEC GPIO DRIVER
+M: Hans Verkuil 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/platform/cec-gpio/
+F: Documentation/devicetree/bindings/media/cec-gpio.txt
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-...@lists.ozlabs.org
-- 
2.13.2

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

[PATCHv3 1/4] dt-bindings: document the tegra CEC bindings

[Hans Verkuil]

From: Hans Verkuil 

This documents the binding for the Tegra CEC module.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/tegra-cec.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt

diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
b/Documentation/devicetree/bindings/media/tegra-cec.txt
new file mode 100644
index ..c503f06f3b84
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
@@ -0,0 +1,27 @@
+* Tegra HDMI CEC hardware
+
+The HDMI CEC module is present in Tegra SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be one of the following:
+   "nvidia,tegra114-cec"
+   "nvidia,tegra124-cec"
+   "nvidia,tegra210-cec"
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "cec",
+ corresponding to the entry in the clocks property.
+  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
+
+Example:
+
+cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+};
-- 
2.13.2

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

[PATCHv3 3/4] tegra-cec: add Tegra HDMI CEC driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for the Tegra CEC IP. It is based on the
NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel.

This has been converted to the CEC framework and cleaned up.

Tested with my Jetson TK1 board. It has also been tested with the
Tegra X1 in an embedded product.

Note of warning for the Tegra X2: this SoC supports two HDMI outputs,
but only one CEC adapter and the CEC bus is shared between the
two outputs. This is a design mistake and the CEC adapter can
control only one HDMI output. Never hook up both HDMI outputs
to the CEC bus in a hardware design: this is illegal as per the
CEC specification.

The CEC bus can be shared between multiple inputs and zero or one
outputs, but not between multiple outputs.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS  |   8 +
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/tegra-cec/Makefile|   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c | 506 +++
 drivers/media/platform/tegra-cec/tegra_cec.h | 127 +++
 6 files changed, 655 insertions(+)
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 84d6a8277cbd..56b47c721704 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1917,6 +1917,14 @@ M:   Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
+ARM/TEGRA HDMI CEC SUBSYSTEM SUPPORT
+M: Hans Verkuil 
+L: linux-te...@vger.kernel.org
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/tegra-cec/
+F: Documentation/devicetree/bindings/media/tegra-cec.txt
+
 ARM/TETON BGA MACHINE SUPPORT
 M: "Mark F. Brown" 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fb1fa0b82077..7a4db3046161 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -570,6 +570,17 @@ config VIDEO_STM32_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_TEGRA_HDMI_CEC
+   tristate "Tegra HDMI CEC driver"
+   depends on ARCH_TEGRA || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for the Tegra HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
 
 menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..9da73532e556 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra-cec/
+
 obj-y  += stm32/
 
 obj-y   += blackfin/
diff --git a/drivers/media/platform/tegra-cec/Makefile 
b/drivers/media/platform/tegra-cec/Makefile
new file mode 100644
index ..f3d81127589f
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra_cec.o
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c 
b/drivers/media/platform/tegra-cec/tegra_cec.c
new file mode 100644
index ..346586c3ad6d
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -0,0 +1,506 @@
+/*
+ * Tegra CEC implementation
+ *
+ * The original 3.10 CEC driver using a custom API:
+ *
+ * Copyright (c) 2012-2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Conversion to the CEC framework and to the mainline kernel:
+ *
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 

[PATCHv3 0/4] tegra-cec: add Tegra HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the Tegra CEC functionality.

It has this prerequisite: https://patchwork.linuxtv.org/patch/42521/

That patch has been merged in 4.13-rc4.

The first patch documents the CEC bindings, the second adds support
for this to tegra124.dtsi and enables it for the Jetson TK1.

The third patch adds the CEC driver itself and the final patch adds
the cec notifier support to the drm/tegra driver in order to notify
the CEC driver whenever the physical address changes.

I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
other Tegra SoCs, but I can only test this with my Jetson TK1 board.

The dt-bindings and the tegra-cec driver would go in through the media
subsystem, the drm/tegra part through the drm subsystem and the dts
changes through (I guess) the linux-tegra developers. Luckily they are
all independent of one another.

To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.

To build this:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh; ./configure
make
sudo make install # optional, you really only need utils/cec*

To test:

cec-ctl --playback # configure as playback device
cec-ctl -Subject # detect all connected CEC devices

See here for the public CEC API:

https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html

Regards,

Hans

Changes since v1:

- Update the bindings doc so it no longer refers to 'driver', instead it
  only refers to the hardware.
- Add 'select CEC_CORE if CEC_NOTIFIER' to Kconfig. If the tegra-cec driver
  is a module and the drm tegra driver is built-in, then the CEC core
  will be a module also, causing the CEC notifier to fail (will be
  compiled as empty functions). This select forces the correct dependency.
  (Note: this was posted separately as a v2 patch)

Hans Verkuil (4):
  dt-bindings: document the tegra CEC bindings
  ARM: tegra: add CEC support to tegra124.dtsi
  tegra-cec: add Tegra HDMI CEC driver
  drm/tegra: add cec-notifier support

 .../devicetree/bindings/media/tegra-cec.txt|  27 ++
 MAINTAINERS|   8 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
 arch/arm/boot/dts/tegra124.dtsi|  12 +-
 drivers/gpu/drm/tegra/Kconfig  |   1 +
 drivers/gpu/drm/tegra/drm.h|   3 +
 drivers/gpu/drm/tegra/hdmi.c   |   9 +
 drivers/gpu/drm/tegra/output.c |   6 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/tegra-cec/Makefile  |   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c   | 506 +
 drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
 13 files changed, 716 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

-- 
2.13.2

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

[PATCHv3 2/4] ARM: tegra: add CEC support to tegra124.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
Jetson TK1.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 
 arch/arm/boot/dts/tegra124.dtsi   | 12 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 7bacb2954f58..7f56de6890c3 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -67,6 +67,10 @@
};
};
 
+   cec@70015000 {
+   status = "okay";
+   };
+
gpu@0,5700 {
/*
 * Node left disabled on purpose - the bootloader will enable
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 1b10b14a6abd..1a21e527fb6e 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -123,7 +123,7 @@
nvidia,head = <1>;
};
 
-   hdmi@5428 {
+   hdmi: hdmi@5428 {
compatible = "nvidia,tegra124-hdmi";
reg = <0x0 0x5428 0x0 0x0004>;
interrupts = ;
@@ -851,6 +851,16 @@
status = "disabled";
};
 
+   cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+   hdmi-phandle = <>;
+   status = "disabled";
+   };
+
soctherm: thermal-sensor@700e2000 {
compatible = "nvidia,tegra124-soctherm";
reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
-- 
2.13.2

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

[PATCHv3 4/4] drm/tegra: add cec-notifier support

[Hans Verkuil]

From: Hans Verkuil 

In order to support CEC the HDMI driver has to inform the CEC driver
whenever the physical address changes. So when the EDID is read the
CEC driver has to be informed and whenever the hotplug detect goes
away.

This is done through the cec-notifier framework.

The link between the HDMI driver and the CEC driver is done through
the hdmi_phandle in the tegra-cec node in the device tree.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/tegra/Kconfig  | 1 +
 drivers/gpu/drm/tegra/drm.h| 3 +++
 drivers/gpu/drm/tegra/hdmi.c   | 9 +
 drivers/gpu/drm/tegra/output.c | 6 ++
 4 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 2db29d67193d..c882918c2024 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -8,6 +8,7 @@ config DRM_TEGRA
select DRM_PANEL
select TEGRA_HOST1X
select IOMMU_IOVA if IOMMU_SUPPORT
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option if you have an NVIDIA Tegra SoC.
 
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6d6da01282f3..c0a18b60caf1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
   struct clk *clk, unsigned long pclk,
   unsigned int div);
 
+struct cec_notifier;
+
 struct tegra_output {
struct device_node *of_node;
struct device *dev;
@@ -219,6 +221,7 @@ struct tegra_output {
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
+   struct cec_notifier *notifier;
unsigned int hpd_irq;
int hpd_gpio;
enum of_gpio_flags hpd_gpio_flags;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index cda0491ed6bf..fbf14e1efd0e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #include "hdmi.h"
 #include "drm.h"
 #include "dc.h"
@@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->vdd);
}
 
+   hdmi->output.notifier = cec_notifier_get(>dev);
+   if (hdmi->output.notifier == NULL)
+   return -ENOMEM;
+
hdmi->output.dev = >dev;
 
err = tegra_output_probe(>output);
@@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device *pdev)
 
tegra_output_remove(>output);
 
+   if (hdmi->output.notifier)
+   cec_notifier_put(hdmi->output.notifier);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 595d1ec3e02e..57c052521a44 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -11,6 +11,8 @@
 #include 
 #include "drm.h"
 
+#include 
+
 int tegra_output_connector_get_modes(struct drm_connector *connector)
 {
struct tegra_output *output = connector_to_output(connector);
@@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
*connector)
edid = drm_get_edid(connector, output->ddc);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
 
if (edid) {
err = drm_add_edid_modes(connector, edid);
@@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
*connector, bool force)
status = connector_status_connected;
}
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(output->notifier);
+
return status;
 }
 
-- 
2.13.2

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