[PATCH] drm: Add reference counting to drm_atomic_state

[Chris Wilson]

drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more beneficial when the lifetime of the state becomes more
convoluted than being passed to a single worker thread for the commit.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
 drivers/gpu/drm/drm_atomic.c | 23 +++
 drivers/gpu/drm/drm_atomic_helper.c  | 98 +++-
 drivers/gpu/drm/drm_fb_helper.c  |  8 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |  3 +-
 drivers/gpu/drm/i915/intel_display.c | 25 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  2 +-
 drivers/gpu/drm/msm/msm_atomic.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|  2 +-
 drivers/gpu/drm/sti/sti_drv.c|  2 +-
 drivers/gpu/drm/tegra/drm.c  |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
 include/drm/drm_atomic.h | 12 +++-
 include/drm/drm_crtc.h   |  2 +
 18 files changed, 73 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index d4a3d61b7b06..00f30fbd2336 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -464,7 +464,7 @@ atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit 
*commit)

drm_atomic_helper_cleanup_planes(dev, old_state);

-   drm_atomic_state_free(old_state);
+   drm_atomic_state_put(old_state);

/* Complete the commit, wake up any waiter. */
spin_lock(>commit.wait.lock);
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5cb2e22d5d55..349c2f0de900 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -74,6 +74,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
 int
 drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
 {
+   kref_init(>ref);
+
/* TODO legacy paths should maybe do a better job about
 * setting this appropriately?
 */
@@ -215,22 +217,16 @@ void drm_atomic_state_clear(struct drm_atomic_state 
*state)
 EXPORT_SYMBOL(drm_atomic_state_clear);

 /**
- * drm_atomic_state_free - free all memory for an atomic state
+ * __drm_atomic_state_free - free all memory for an atomic state
  * @state: atomic state to deallocate
  *
  * This frees all memory associated with an atomic state, including all the
  * per-object state for planes, crtcs and connectors.
  */
-void drm_atomic_state_free(struct drm_atomic_state *state)
+void __drm_atomic_state_free(struct kref *ref)
 {
-   struct drm_device *dev;
-   struct drm_mode_config *config;
-
-   if (!state)
-   return;
-
-   dev = state->dev;
-   config = >mode_config;
+   struct drm_atomic_state *state = container_of(ref, typeof(*state), ref);
+   struct drm_mode_config *config = >dev->mode_config;

drm_atomic_state_clear(state);

@@ -243,7 +239,7 @@ void drm_atomic_state_free(struct drm_atomic_state *state)
kfree(state);
}
 }
-EXPORT_SYMBOL(drm_atomic_state_free);
+EXPORT_SYMBOL(__drm_atomic_state_free);

 /**
  * drm_atomic_get_crtc_state - get crtc state
@@ -1742,7 +1738,7 @@ retry:
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
/*
 * Unlike commit, check_only does not clean up state.
-* Below we call drm_atomic_state_free for it.
+* Below we call drm_atomic_state_put for it.
 */
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
@@ -1775,8 +1771,7 @@ out:
goto retry;
}

-   if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
-   drm_atomic_state_free(state);
+   drm_atomic_state_put(state);

drm_modeset_drop_locks();
drm_modeset_acquire_fini();
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9abe0a242f96..14dbae947a12 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1187,7 +1187,7 @@ static void commit_tail(struct drm_atomic_state *state)

drm_atomic_helper_commit_cleanup_done(state);

-   drm_atomic_state_free(state);
+   drm_atomic_state_put(state);
 }

 static void commit_work(struct work_struct *work)
@@ -1263,6 +1263,7 @@ int drm_atomic_helper_commit(struct 

[v14 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
Acked-by: Mark Yao 

---

Changes in v14:
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1067 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  106 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  959 
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  482 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 9 files changed, 2646 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20aaafe 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+   select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..6a07809 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..f8bdfd1
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,1067 @@
+/*

[v14 PATCH 0/5] Rockchip Type-C and DisplayPort driver

[Chris Zhong]

Hi all

This series patch is for rockchip Type-C phy and DisplayPort controller
driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file[0] rockchip/dptx.bin to
/lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication
and link training, the host use mailbox to communicate with the ucpu.

The DP contoller has register a notification with extcon API, to get the
alt mode from PD, the PD driver need call the devm_extcon_dev_allocate
to create a extcon device and use extcon_set_state to notify DP
controller. And call extcon_set_cable_property to set orientation.

About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF.
We can reference them in simple-card.

This series is based on Mark Yao's branch[1], the extcon API backport
from linux-next[2].

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.

>From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY
will be init, no matter which PHY be power_on. The DP module will
enter A2 mode (standby mode) after phy_init, if DP PHY is powered on,
the DP module will enter to A0 mode(running mode). Then if DP PHY is
powered off, DP module will back to A2 mode. If everything is
un-plugged, phy will be deinit.

[0]
kernel/git/firmware/linux-firmware.git
[1]
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23
[2]
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master


Changes in v14:
- change the name of property from super speed to EXTCON_PROP_USB_SS
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration
- do not return err if nothing connected with Type-C, when usb phy power on,
  since the USB core driver will call phy power without USB3 device connected.
- add dptx and apb reset
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
  and DP is attached
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- make a clearer emarcation between usb phy and dp phy
- make a clearer demarcation between usb phy and dp phy.
- split the dp-phy and usb3-phy to 2 child-node
- refer dp phy
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove rockchip,uphy-dp-sel property
- do not control dp select and hpd config in phy driver
- remove rockchip,uphy-dp-sel property
- add pclk_vio_grf clock
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- change #phy-cells to 1
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP
- change #phy-cells to 1
- modify the reference phy = < 0>, < 0>;
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log
- optimization the err log

Changes in v7:
- support new API of extcon
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add assigned-clocks and assigned-clock-rates
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode
- add assigned-clocks and assigned-clock-rates
- add power-domains
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- add a #phy-cells node
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_
- add a reset node
- support 2 phys
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use compatible: rockchip,rk3399-typec-phy

[drm-intel:topic/drm-misc 3/3] htmldocs: drivers/gpu/drm/drm_fb_helper.c:1069: warning: No description found for parameter 'suspend'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   cfe63423d9be3e7020296c3dfb512768a83cd099
commit: cfe63423d9be3e7020296c3dfb512768a83cd099 [3/3] drm/fb-helper: Add 
drm_fb_helper_set_suspend_unlocked()
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/drm_fb_helper.c:1069: warning: No description found for 
>> parameter 'suspend'
>> drivers/gpu/drm/drm_fb_helper.c:1069: warning: Excess function parameter 
>> 'state' description in 'drm_fb_helper_set_suspend_unlocked'
   drivers/gpu/drm/drm_fb_helper.c:1070: warning: No description found for 
parameter 'suspend'
   drivers/gpu/drm/drm_fb_helper.c:1070: warning: Excess function parameter 
'state' description in 'drm_fb_helper_set_suspend_unlocked'
   Documentation/gpu/drm-kms.rst:13: WARNING: Could not lex literal_block as 
"C". Highlighting skipped.
   Documentation/gpu/drm-kms-helpers.rst:16: WARNING: Could not lex 
literal_block as "C". Highlighting skipped.
   Documentation/gpu/i915.rst:57: WARNING: Could not lex literal_block as "C". 
Highlighting skipped.
   Documentation/gpu/drm-internals.rst:286: WARNING: undefined label: 
vga_switcheroo (if the link has no caption the label must precede a section 
header)

vim +/suspend +1069 drivers/gpu/drm/drm_fb_helper.c

  1053   *  takes the console lock
  1054   * @fb_helper: driver-allocated fbdev helper
  1055   * @state: desired state, zero to resume, non-zero to suspend
  1056   *
  1057   * A wrapper around fb_set_suspend() that takes the console lock. If 
the lock
  1058   * isn't available on resume, a worker is tasked with waiting for the 
lock
  1059   * to become available. The console lock can be pretty contented on 
resume
  1060   * due to all the printk activity.
  1061   *
  1062   * This function can be called multiple times with the same state since
  1063   * _info->state is checked to see if fbdev is running or not before 
locking.
  1064   *
  1065   * Use drm_fb_helper_set_suspend() if you need to take the lock 
yourself.
  1066   */
  1067  void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
  1068  int suspend)
> 1069  {
  1070  if (!fb_helper || !fb_helper->fbdev)
  1071  return;
  1072  
  1073  /* make sure there's no pending/ongoing resume */
  1074  flush_work(_helper->resume_work);
  1075  
  1076  if (suspend) {
  1077  if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6422 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/78f63634/attachment.obj>

[PATCH 1/1] drm/vmwgfx: avoid possible NULL pointer dereference

[kbuild test robot]

Hi Heinrich,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.8-rc3 next-20160823]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Heinrich-Schuchardt/drm-vmwgfx-avoid-possible-NULL-pointer-dereference/20160822-051807
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x016-201634 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_res_reloc_add':
>> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:656:3: warning: 'return' with no 
>> value, in function returning non-void [-Wreturn-type]
  return;
  ^~
   drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:646:12: note: declared here
static int vmw_cmd_res_reloc_add(struct vmw_private *dev_priv,
   ^

vim +/return +656 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c

   640   * @sw_context: Pointer to the software context.
   641   * @id_loc: Pointer to where the id that needs translation is located.
   642   * @res: Valid pointer to a struct vmw_resource.
   643   * @p_val: If non null, a pointer to the struct 
vmw_resource_validate_node
   644   * used for this resource is returned here.
   645   */
   646  static int vmw_cmd_res_reloc_add(struct vmw_private *dev_priv,
   647   struct vmw_sw_context *sw_context,
   648   uint32_t *id_loc,
   649   struct vmw_resource *res,
   650   struct vmw_resource_val_node **p_val)
   651  {
   652  int ret;
   653  struct vmw_resource_val_node *node;
   654  
   655  if (!p_val)
 > 656  return;
   657  
   658  *p_val = NULL;
   659  
   660  ret = vmw_resource_relocation_add(_context->res_relocations,
   661res,
   662id_loc - 
sw_context->buf_start);
   663  if (unlikely(ret != 0))
   664  return ret;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 32267 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/11424178/attachment-0001.obj>

[PATCH 2/2] drm: simple_kms_helper: add support for bridges

[Daniel Vetter]

On Tue, Aug 23, 2016 at 06:44:18PM +0200, Andrea Merello wrote:
> On Tue, Aug 23, 2016 at 5:54 PM, Daniel Vetter  wrote:
> 
> > On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote:
> > > On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter  wrote:
> > >
> > > > On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> > > > > Introduce drm_simple_display_pipe_attach_bridge() in order
> > > > > to make it possible to use drm encoders with the simple display
> > > > > pipes managed by simple_kms_helpers
> > > > >
> > > > > Suggested-by: Daniel Vetter 
> > > > > Signed-off-by: Andrea Merello 
> > > > > Cc: Noralf Trønnes 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: David Airlie 
> > > >
> > > > Threading of your patch series is somehow broken, usually that should
> > all
> > > > work nicely if you've set up git send-email.
> > > >
> > > > One question: Should we ahve a drm_simple_display_pipe_detach_bridge
> > (for
> > > > cleanup) too?
> > > >
> > >
> > > Unsure if it worths. May be nice to have a balanced pair, but it would
> > > probably end up in
> > > a quite redundant one-line func, that only calls drm_bridge_detach with
> > the
> > > very same argument.
> > >
> > > ..But of course if you want I can add it in v2 series.
> >
> > Yes it's just going to be a one-line, but it'll do a typecast and so
> > better encapsulate the internals of the simple pipe helper.
> 
> 
> I'm unsure about what do you mean here. Why a typecast?
> 
> Wouldn't it be simply drm_simple_display_pipe_detach_bridge(struct
> drm_bridge *bridge) calling in turn drm_detach_bridge(struct drm_bridge
> *bridge) with the very same argument?
> 
> Or if you want to stay behind the pipe, then it could be
> drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe *pipe),
> but I would say it just does something like
> drm_bridge_detach(pipe->encoder.bridge), so I don't really get your point
> about the cast, sorry..

Yeah, the latter is what I mean. That way drivers don't have to dig around
in the details of pipe. And it wouldn't be entirely just a wrapper, I
think it'd be good to also clear pipe->encoder.bridge to NULL.

Or do you think this is entirely pointless? Sometimes I do go overboard
with curating pretty little functions ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/4] ARM: dts: exynos: Enable HDMI in Arndale Octa board

[Krzysztof Kozlowski]

On Tue, Aug 23, 2016 at 11:13 AM, Milo Kim  wrote:
> This patch-set enables HDMI in Arndale Octa board and fixes HPD DT property.
> It also includes code refactoring on ddc and phy.
>
> Milo Kim (4):
>   ARM: dts: exynos: Enable HDMI for Arndale Octa board
>   ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
>   gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT
> property
>   gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT
> property

I saw DTS patches on linux-samsung-soc patchwork but still I would
appreciate if you send them to appropriate maintainers pointed by
get_maintainers.pl script. DTS stuff goes through samsung-soc tree.

Best regards,
Krzysztof

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

A few bigger things:
- start of splitting drm_crtc.c into more manageable and better documneted
  chunks
- DRM_DEV_* logging (Sean)

But besides those it's really all one-off misc patches all over this time
around, trying to summarize them further would just end up in copying the
shortlog ;-)

Once you pulled this in can you pls apply

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

on top? I think this patch would benefit from your direct sob, and it has
some trivial conflicts with the doc polish in this pull.

I also have a pile in drm-intel-next, but the io-mapping.h change in there
blew up on some really interesting places because some folks thought this
is the generic iomapping header, without realizing that it's _only_ for
per-page io_mapping (only used by i915, nouveau and some random network
driver, which looks a bit fishy). We need to undo that silliness first
before I can send you that pull (gpiolib and some infiniband files include
linux/io-mapping.h), so probably will take a few days.

Cheers, Daniel


The following changes since commit fc93ff608b15ae32cde3006b7af860b59cac20ec:

  Merge tag 'drm-intel-next-2016-08-08' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-08-15 16:53:57 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-08-23

for you to fetch changes up to 28579f37467cd1a9130a6287cf8322986e0b56f9:

  drm/fb-helper: Make docs for fb_set_suspend wrappers consistent (2016-08-23 
21:12:56 +0200)


Chris Wilson (4):
  dma-buf: Wait on the reservation object when sync'ing before CPU access
  drm: Allow drivers to modify plane_state in prepare_fb/cleanup_fb
  drm: Avoid calling dev_printk(.dev = NULL)
  drm/fb-helper: Fix the dummy remove_conflicting_framebuffers

Clint Taylor (1):
  drm/edid: CEA mode 64 1080p100 vsync pulse width incorrect

Daniel Vetter (23):
  drm/doc: Fix more kerneldoc/sphinx warnings
  drm/doc: Light drm-kms-helper.rst cleanup
  drm/kms-helpers: Extract drm_modeset_helper.[hc]
  drm/doc: Reorg drm-mm.rst
  drm/doc: Reorg for drm-kms.rst
  drm/etnaviv: Don't set drm_device->platformdev
  drm/hisilicon: Don't set drm_device->platformdev
  drm/doc: Remove outdated FIXME for the page_flip callback
  drm/kms: Nuke dirty_info property
  drm/doc: Include drm_atomic.h
  drm: Extract drm_framebuffer.[hc]
  drm/doc: Update drm_framebuffer docs
  drm: Export drm_property_replace_global_blob
  drm: Extract drm_connector.[hc]
  drm/doc: Include new drm_blend.c
  drm: Don't export dp-aux devnode functions
  drm: Update connector documentation
  drm: Remove display_info->min/max_(h|v)max
  drm: document drm_display_info
  vgaarbiter: rst-ifiy and polish kerneldoc
  drm: Fix kerneldoc in drm_plane_helper.c
  Revert "drm/hisilicon: Don't set drm_device->platformdev"
  drm/fb-helper: Make docs for fb_set_suspend wrappers consistent

Eric Engestrom (2):
  drm: make drm_get_format_name thread-safe
  drm: remove `const` attribute to hint at caller that they now own the 
memory

Heinrich Schuchardt (1):
  drm: avoid exposing kernel stack in compat_drm_getstats

Jamie Lentin (1):
  drm/udl: Ensure channel is selected before using the device.

Laurent Pinchart (1):
  drm: Don't implement empty prepare_fb()/cleanup_fb()

Lothar Waßmann (1):
  drm: update kerneldoc for changes introduced by commits "16fadc2568e9" 
and "9671e228fb78"

Markus Elfring (4):
  GPU-DRM-Savage: Use memdup_user() rather than duplicating
  virtio-gpu: Use memdup_user() rather than duplicating its implementation
  drm/bridge: dw-hdmi: Delete unnecessary assignment for the field "owner"
  drm/rockchip: Delete unnecessary assignment for the field "owner"

Noralf Trønnes (1):
  drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()

Randy Dunlap (1):
  dma-buf: fix kernel-doc warning and typos

Rob Clark (1):
  reservation: fix small comment typo

Sean Paul (3):
  drm: Introduce DRM_DEV_* log messages
  drm/rockchip: Use DRM_DEV_ERROR in vop
  drm/rockchip: Don't continue trying to enable crtc on failure

Shawn Guo (1):
  drm: drop DRIVER_HAVE_IRQ flag for some drivers

Wei Yongjun (1):
  drm/mgag200: fix error return code in mgag200fb_create()

 Documentation/gpu/drm-kms-helpers.rst  |  211 +-
 Documentation/gpu/drm-kms.rst  |  270 +--
 Documentation/gpu/drm-mm.rst   |   58 +-
 Documentation/gpu/drm-uapi.rst |3 +
 Documentation/gpu/index.rst|1 +
 Documentation/gpu/vga-switcheroo.rst   |2 -
 .../{vgaarbiter.txt => gpu/vgaarbiter.rst} |  161 +-
 drivers/dma-buf/dma-buf.c  |   23 +
 drivers/dma-buf/fence-array.c  |   

[drm-intel:for-linux-next 14/16] htmldocs: drivers/gpu/drm/i915/intel_dp.c:5063: warning: No description found for parameter 'dev_priv'

[kbuild test robot]

7   
struct intel_crtc_state *old_crtc_state)
c395578e Vandana Kannan  2015-01-22 @5188  {
c395578e Vandana Kannan  2015-01-22  5189   struct drm_device *dev 
= intel_dp_to_dev(intel_dp);
fac5e23e Chris Wilson2016-07-04  5190   struct drm_i915_private 
*dev_priv = to_i915(dev);
c395578e Vandana Kannan  2015-01-22  5191  

:: The code at line 5063 was first introduced by commit
:: 439d7ac0879f9fd4c56f212e03477f358133c56c drm/i915: Add support for DRRS 
to switch RR

:: TO: Pradeep Bhat 
:: CC: Daniel Vetter 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6422 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/8020c425/attachment-0001.obj>

[drm-intel:for-linux-next 1/1] include/linux/io-mapping.h:126:2: error: implicit declaration of function 'pgprot_writecombine'

[Daniel Vetter]

On Tue, Aug 23, 2016 at 9:16 PM, Chris Wilson  
wrote:
> On Wed, Aug 24, 2016 at 02:22:29AM +0800, kbuild test robot wrote:
>> tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
>> head:   ac96b5566926af83463ddcf4655856033c092f26
>> commit: ac96b5566926af83463ddcf4655856033c092f26 [1/1] io-mapping.h: 
>> s/PAGE_KERNEL_IO/PAGE_KERNEL/
>> config: microblaze-nommu_defconfig (attached as .config)
>> compiler: microblaze-linux-gcc (GCC) 4.9.0
>> reproduce:
>> wget 
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>  -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout ac96b5566926af83463ddcf4655856033c092f26
>> # save the attached .config to linux build tree
>> make.cross ARCH=microblaze
>>
>> All errors (new ones prefixed by >>):
>>
>>In file included from drivers/gpio/gpiolib-of.c:19:0:
>>include/linux/io-mapping.h: In function 'io_mapping_init_wc':
>> >> include/linux/io-mapping.h:126:2: error: implicit declaration of function 
>> >> 'pgprot_writecombine' [-Werror=implicit-function-declaration]
>>  iomap->prot = pgprot_writecombine(PAGE_KERNEL);
>>  ^
>> >> include/linux/io-mapping.h:126:14: error: incompatible types when 
>> >> assigning to type 'pgprot_t' from type 'int'
>>  iomap->prot = pgprot_writecombine(PAGE_KERNEL);
>>  ^
>>cc1: some warnings being treated as errors
>>
>> vim +/pgprot_writecombine +126 include/linux/io-mapping.h
>
> Grrr.
>
> diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
> index a87dd7fffc0a..babd4c53a5aa 100644
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -114,6 +114,10 @@ io_mapping_unmap(void __iomem *vaddr)
>  #include 
>  #include 
>
> +#ifdef pgprot_noncached_wc
> +#define pgprot_writecombine pgprot_noncached_wc
> +#endif
> +
>  /* Create the io_mapping object*/
>  static inline struct io_mapping *
>  io_mapping_init_wc(struct io_mapping *iomap,
>
> is what I have in mind. Looks like a divide between x86 and ppc (and
> their followers).

tbh I'm leaning towards reverting, since this is getting a bit
embarrassing ;-) Also the io-mapping.h change wasn't reviewed or acked
by arch maintainers (which is probably should have been in hindsight).
And i915_mm.c probably should be somewhere in arch/core code, too.
I'll discuss this a bit more tomorrow with you , but since it's
holding up the drm-intel-next pull revert it likely is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()

[Noralf Trønnes]

Den 23.08.2016 20:01, skrev Daniel Vetter:
> On Tue, Aug 23, 2016 at 7:52 PM, Noralf Trønnes  
> wrote:
 +static int sdrm_fbdev_event_notify(struct notifier_block *self,
 +  unsigned long action, void *data)
 +{
 +   struct sdrm_device *sdrm;
 +   struct fb_event *event = data;
 +   struct fb_info *info = event->info;
 +   struct drm_fb_helper *fb_helper = info->par;
 +
 +   if (action != FB_EVENT_FB_UNREGISTERED)
 +   return NOTIFY_DONE;
 +
 +   if (!fb_helper || !fb_helper->dev || fb_helper->fbdev != info)
 +   return NOTIFY_DONE;
 +
 +   sdrm = fb_helper->dev->dev_private;
 +
 +   if (sdrm && sdrm->fb_helper == fb_helper)
 +
 platform_device_del(to_platform_device(fb_helper->dev->dev));
 +
 +   return NOTIFY_DONE;
 +}
>>> One problem this leaves behind is that registering of the new fbdev driver
>>> is too late - by that point we've already set up the entire driver,
>>> including modeset. If fbdev meanwhile does a dpms off or something like
>>> that all hell will break loose.
>>
>> I don't understand how fbdev registration comes into play here. Drivers call
>> remove_conflicting_framebuffers very early so simpledrm is gone by the time
>> they register anything.
>>
>> For simpledrm, fbdev doing blank/unblank is a no-op since fb_ops.fb_blank
>> is not implemented. So a fb_blank() just results in fbcon doing a
>> software blank.
> Maybe my scenario wasn't entirely clear:
> - prereq: fbdev emulation in drm is disabled
> 1. simpledrm loads and sets up the firmware fb
> 2. real driver loads, first calls
> drm_fb_helper_remove_conflicting_framebuffer. Nothing happens because
> CONFIG_FB=n.
> 3. real driver start loading, remapping the gart and what not else
> 4. something is drawn using fbcon, simplerdrm writes through the now
> invalid mapping
> -> BOOM

Yes CONFIG_FB=n is not covered, that's the drawback mentioned in the 
Kconfig.
However, who uses simpledrm without fbdev/fbcon when it shall be handed over
to a real hw-driver?
But yes, it's not a good stop gap solution, I like my other idea much 
better.

> You have code to listen to the framebuffer registration notifier, but
> I think even that happens way too late. Or at least I didn't spot any
> code in remove_conflicting_framebuffers which would call down into
> that notifier. Or maybe I entirely misunderstand your code ...

remove_conflicting_framebuffers unregisters the fbdev framebuffer.
sdrm_fbdev_event_notify detects that the framebuffer is being unregistered,
and deletes the platform device.

Some details:

do_remove_conflicting_framebuffers():
 for (i = 0 ; i < FB_MAX; i++) {
[...]
 printk(KERN_INFO "fb: switching to %s from %s\n",
name, registered_fb[i]->fix.id);
 ret = do_unregister_framebuffer(registered_fb[i]);

do_unregister_framebuffer(): short version
{
 console_lock();

 event.info = fb_info;
 ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, );
 unlock_fb_info(fb_info);
 console_unlock();

 pm_vt_switch_unregister(fb_info->dev);

 unlink_framebuffer(fb_info);

 registered_fb[i] = NULL;
 num_registered_fb--;

 event.info = fb_info;
 console_lock();
 fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, );
/* at this point simpledrm has been deleted */
 console_unlock();

 /* this may free fb info */
 put_fb_info(fb_info);
 return 0;
}

> Wrt fixing: Just adding it to the recently added stub is of course
> also a working solution.

I actually like this better, because it's so straightforward and easy
to understand. The notifier solution is very convoluted and easy to
mess up. And it runs with the console lock held...

> -Daniel
>
> PS: Can you pls review the 2 patches I submitted with you on cc? I
> won't merge my own patches without proper review, so without that done
> they're stuck.

Ok.

I'll test the simple-helper plane patch tomorrow.
In simpledrm I first tried to send the vblank event only in pipe.update(),
but I had to do it in enable() and disable() as well to make that vblank
timeout go away.


Noralf.

[PATCH] drm/fb-helper: Make docs for fb_set_suspend wrappers consistent

[Daniel Vetter]

On Tue, Aug 23, 2016 at 08:53:05PM +0200, Noralf Trønnes wrote:
> 
> Den 23.08.2016 17:27, skrev Daniel Vetter:
> > I figured I might as well go ocd and make them booleans and rename the
> > locked version too.
> > 
> > Reported-by: kbuild test robot 
> > Cc: Noralf Trønnes 
> > Fixes: cfe63423d9be ("drm/fb-helper: Add 
> > drm_fb_helper_set_suspend_unlocked()")
> > Signed-off-by: Daniel Vetter 
> > ---
> >   drivers/gpu/drm/drm_fb_helper.c | 8 
> >   include/drm/drm_fb_helper.h | 6 +++---
> >   2 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 10585c462d85..e1af1d08511b 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1035,13 +1035,13 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
> >   /**
> >* drm_fb_helper_set_suspend - wrapper around fb_set_suspend
> >* @fb_helper: driver-allocated fbdev helper
> > - * @state: desired state, zero to resume, non-zero to suspend
> > + * @suspend: whether to suspend or resume
> >*
> >* A wrapper around fb_set_suspend implemented by fbdev core.
> >* Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
> >* the lock yourself
> >*/
> > -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
> > +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool 
> > suspend)
> >   {
> > if (fb_helper && fb_helper->fbdev)
> > fb_set_suspend(fb_helper->fbdev, state);
> 
> Forgot to change state to suspend here.

Argh, silly me forgot to compile-check both variants.
> 
> > @@ -1052,7 +1052,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >* drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend 
> > that also
> >*  takes the console lock
> >* @fb_helper: driver-allocated fbdev helper
> > - * @state: desired state, zero to resume, non-zero to suspend
> > + * @suspend: whether to suspend or resume
> >*
> >* A wrapper around fb_set_suspend() that takes the console lock. If the 
> > lock
> >* isn't available on resume, a worker is tasked with waiting for the lock
> > @@ -1065,7 +1065,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >* Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
> >*/
> >   void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> > -   int suspend)
> > +   bool suspend)
> >   {
> > if (!fb_helper || !fb_helper->fbdev)
> > return;
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index 0c6e53d9ce68..6c812e3c8bfc 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -265,9 +265,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
> >   void drm_fb_helper_cfb_imageblit(struct fb_info *info,
> >  const struct fb_image *image);
> > -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
> > +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool 
> > suspend);
> >   void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> > -   int suspend);
> > +   bool suspend);
> >   int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
> > @@ -421,7 +421,7 @@ static inline void drm_fb_helper_cfb_imageblit(struct 
> > fb_info *info,
> >   }
> >   static inline void drm_fb_helper_set_suspend(struct drm_fb_helper 
> > *fb_helper,
> > -int state)
> > +bool suspend)
> >   {
> >   }
> 
> The _unlocked version also needs the bool change here in the #else section.
> 
> With that:
> Acked-by: Noralf Trønnes 

Both fixed and applied, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 97362] Low performance after suspend on RX 480

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Grigori Goronzy  ---
I can confirm, I also see this. The performance reduction also depends on the
application for me. I think this issue has existed from the very start, so
there's no point in trying to bisect.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/49e3b12f/attachment.html>

[PATCH] drm/fb-helper: Make docs for fb_set_suspend wrappers consistent

[Noralf Trønnes]

Den 23.08.2016 17:27, skrev Daniel Vetter:
> I figured I might as well go ocd and make them booleans and rename the
> locked version too.
>
> Reported-by: kbuild test robot 
> Cc: Noralf Trønnes 
> Fixes: cfe63423d9be ("drm/fb-helper: Add 
> drm_fb_helper_set_suspend_unlocked()")
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_fb_helper.c | 8 
>   include/drm/drm_fb_helper.h | 6 +++---
>   2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 10585c462d85..e1af1d08511b 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1035,13 +1035,13 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
>   /**
>* drm_fb_helper_set_suspend - wrapper around fb_set_suspend
>* @fb_helper: driver-allocated fbdev helper
> - * @state: desired state, zero to resume, non-zero to suspend
> + * @suspend: whether to suspend or resume
>*
>* A wrapper around fb_set_suspend implemented by fbdev core.
>* Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
>* the lock yourself
>*/
> -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
> +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend)
>   {
>   if (fb_helper && fb_helper->fbdev)
>   fb_set_suspend(fb_helper->fbdev, state);

Forgot to change state to suspend here.

> @@ -1052,7 +1052,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>* drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that 
> also
>*  takes the console lock
>* @fb_helper: driver-allocated fbdev helper
> - * @state: desired state, zero to resume, non-zero to suspend
> + * @suspend: whether to suspend or resume
>*
>* A wrapper around fb_set_suspend() that takes the console lock. If the 
> lock
>* isn't available on resume, a worker is tasked with waiting for the lock
> @@ -1065,7 +1065,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>* Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
>*/
>   void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> - int suspend)
> + bool suspend)
>   {
>   if (!fb_helper || !fb_helper->fbdev)
>   return;
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 0c6e53d9ce68..6c812e3c8bfc 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -265,9 +265,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
>   void drm_fb_helper_cfb_imageblit(struct fb_info *info,
>const struct fb_image *image);
>   
> -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
> +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool 
> suspend);
>   void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> - int suspend);
> + bool suspend);
>   
>   int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>   
> @@ -421,7 +421,7 @@ static inline void drm_fb_helper_cfb_imageblit(struct 
> fb_info *info,
>   }
>   
>   static inline void drm_fb_helper_set_suspend(struct drm_fb_helper 
> *fb_helper,
> -  int state)
> +  bool suspend)
>   {
>   }
>   

The _unlocked version also needs the bool change here in the #else section.

With that:
Acked-by: Noralf Trønnes 

Thanks for fixing up my docs omission.

Noralf.

[drm-intel:for-linux-next 1/1] include/linux/io-mapping.h:126:2: error: implicit declaration of function 'pgprot_writecombine'

[Chris Wilson]

On Wed, Aug 24, 2016 at 02:22:29AM +0800, kbuild test robot wrote:
> tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
> head:   ac96b5566926af83463ddcf4655856033c092f26
> commit: ac96b5566926af83463ddcf4655856033c092f26 [1/1] io-mapping.h: 
> s/PAGE_KERNEL_IO/PAGE_KERNEL/
> config: microblaze-nommu_defconfig (attached as .config)
> compiler: microblaze-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout ac96b5566926af83463ddcf4655856033c092f26
> # save the attached .config to linux build tree
> make.cross ARCH=microblaze 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from drivers/gpio/gpiolib-of.c:19:0:
>include/linux/io-mapping.h: In function 'io_mapping_init_wc':
> >> include/linux/io-mapping.h:126:2: error: implicit declaration of function 
> >> 'pgprot_writecombine' [-Werror=implicit-function-declaration]
>  iomap->prot = pgprot_writecombine(PAGE_KERNEL);
>  ^
> >> include/linux/io-mapping.h:126:14: error: incompatible types when 
> >> assigning to type 'pgprot_t' from type 'int'
>  iomap->prot = pgprot_writecombine(PAGE_KERNEL);
>  ^
>cc1: some warnings being treated as errors
> 
> vim +/pgprot_writecombine +126 include/linux/io-mapping.h

Grrr.

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index a87dd7fffc0a..babd4c53a5aa 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -114,6 +114,10 @@ io_mapping_unmap(void __iomem *vaddr)
 #include 
 #include 

+#ifdef pgprot_noncached_wc
+#define pgprot_writecombine pgprot_noncached_wc
+#endif
+
 /* Create the io_mapping object*/
 static inline struct io_mapping *
 io_mapping_init_wc(struct io_mapping *iomap,

is what I have in mind. Looks like a divide between x86 and ppc (and
their followers).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()

[Daniel Vetter]

On Tue, Aug 23, 2016 at 7:52 PM, Noralf Trønnes  wrote:
>>> +static int sdrm_fbdev_event_notify(struct notifier_block *self,
>>> +  unsigned long action, void *data)
>>> +{
>>> +   struct sdrm_device *sdrm;
>>> +   struct fb_event *event = data;
>>> +   struct fb_info *info = event->info;
>>> +   struct drm_fb_helper *fb_helper = info->par;
>>> +
>>> +   if (action != FB_EVENT_FB_UNREGISTERED)
>>> +   return NOTIFY_DONE;
>>> +
>>> +   if (!fb_helper || !fb_helper->dev || fb_helper->fbdev != info)
>>> +   return NOTIFY_DONE;
>>> +
>>> +   sdrm = fb_helper->dev->dev_private;
>>> +
>>> +   if (sdrm && sdrm->fb_helper == fb_helper)
>>> +
>>> platform_device_del(to_platform_device(fb_helper->dev->dev));
>>> +
>>> +   return NOTIFY_DONE;
>>> +}
>>
>> One problem this leaves behind is that registering of the new fbdev driver
>> is too late - by that point we've already set up the entire driver,
>> including modeset. If fbdev meanwhile does a dpms off or something like
>> that all hell will break loose.
>
>
> I don't understand how fbdev registration comes into play here. Drivers call
> remove_conflicting_framebuffers very early so simpledrm is gone by the time
> they register anything.
>
> For simpledrm, fbdev doing blank/unblank is a no-op since fb_ops.fb_blank
> is not implemented. So a fb_blank() just results in fbcon doing a
> software blank.

Maybe my scenario wasn't entirely clear:
- prereq: fbdev emulation in drm is disabled
1. simpledrm loads and sets up the firmware fb
2. real driver loads, first calls
drm_fb_helper_remove_conflicting_framebuffer. Nothing happens because
CONFIG_FB=n.
3. real driver start loading, remapping the gart and what not else
4. something is drawn using fbcon, simplerdrm writes through the now
invalid mapping
-> BOOM

You have code to listen to the framebuffer registration notifier, but
I think even that happens way too late. Or at least I didn't spot any
code in remove_conflicting_framebuffers which would call down into
that notifier. Or maybe I entirely misunderstand your code ...

Wrt fixing: Just adding it to the recently added stub is of course
also a working solution.
-Daniel

PS: Can you pls review the 2 patches I submitted with you on cc? I
won't merge my own patches without proper review, so without that done
they're stuck.
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()

[Noralf Trønnes]

Den 23.08.2016 14:41, skrev Daniel Vetter:
> On Mon, Aug 22, 2016 at 10:25:25PM +0200, Noralf Trønnes wrote:
>> There is currently no non-fbdev mechanism in place to kick out
>> simpledrm when the real hw-driver is probed. As a stop gap until
>> that is in place, honour remove_conflicting_framebuffers() and
>> delete the simple-framebuffer platform device when it's called.
>>
>> Signed-off-by: Noralf Trønnes 
>> ---



>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c 
>> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> index c6596ad..7c6db2c 100644
>> --- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> @@ -44,6 +44,20 @@ static int sdrm_fb_mmap(struct fb_info *info, struct 
>> vm_area_struct *vma)
>>  return -ENODEV;
>>   }
>>
>> +/*
>> + * Releasing has to be done outside the notifier callchain when we're
>> + * kicked out, since do_unregister_framebuffer() calls put_fb_info()
>> + * after the notifier has run.
>> + * Open code drm_fb_helper_release_fbi() since fb_helper is freed at
>> + * this point when kicked out.
>> + */
>> +static void sdrm_fbdev_fb_destroy(struct fb_info *info)
>> +{
>> +if (info->cmap.len)
>> +fb_dealloc_cmap(>cmap);
>> +framebuffer_release(info);
>> +}
>> +
>>   static struct fb_ops sdrm_fbdev_ops = {
>>  .owner  = THIS_MODULE,
>>  .fb_fillrect= drm_fb_helper_sys_fillrect,
>> @@ -53,6 +67,7 @@ static struct fb_ops sdrm_fbdev_ops = {
>>  .fb_set_par = drm_fb_helper_set_par,
>>  .fb_setcmap = drm_fb_helper_setcmap,
>>  .fb_mmap= sdrm_fb_mmap,
>> +.fb_destroy = sdrm_fbdev_fb_destroy,
>>   };
>>
>>   static int sdrm_fbdev_create(struct drm_fb_helper *helper,
>> @@ -110,6 +125,9 @@ static int sdrm_fbdev_create(struct drm_fb_helper 
>> *helper,
>>  fbi->screen_base = obj->vmapping;
>>  fbi->fix.smem_len = sdrm->fb_size;
>>
>> +fbi->apertures->ranges[0].base = sdrm->fb_base;
>> +fbi->apertures->ranges[0].size = sdrm->fb_size;
>> +
>>  return 0;
>>
>>   err_fbi_release:
>> @@ -188,9 +206,13 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
>>  sdrm->fb_helper = NULL;
>>  fbdev = to_sdrm_fbdev(fb_helper);
>>
>> -drm_fb_helper_unregister_fbi(fb_helper);
>> +/* it might have been kicked out */
>> +if (registered_fb[fbdev->fb_helper.fbdev->node])
>> +drm_fb_helper_unregister_fbi(fb_helper);
>> +
>> +/* freeing fb_info is done in fb_ops.fb_destroy() */
>> +
>>  cancel_work_sync(_helper->dirty_work);
>> -drm_fb_helper_release_fbi(fb_helper);
>>
>>  drm_framebuffer_unregister_private(fb_helper->fb);
>>  drm_framebuffer_cleanup(fb_helper->fb);
>> @@ -199,3 +221,39 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
>>  drm_fb_helper_fini(fb_helper);
>>  kfree(fbdev);
>>   }
>> +
>> +static int sdrm_fbdev_event_notify(struct notifier_block *self,
>> +   unsigned long action, void *data)
>> +{
>> +struct sdrm_device *sdrm;
>> +struct fb_event *event = data;
>> +struct fb_info *info = event->info;
>> +struct drm_fb_helper *fb_helper = info->par;
>> +
>> +if (action != FB_EVENT_FB_UNREGISTERED)
>> +return NOTIFY_DONE;
>> +
>> +if (!fb_helper || !fb_helper->dev || fb_helper->fbdev != info)
>> +return NOTIFY_DONE;
>> +
>> +sdrm = fb_helper->dev->dev_private;
>> +
>> +if (sdrm && sdrm->fb_helper == fb_helper)
>> +platform_device_del(to_platform_device(fb_helper->dev->dev));
>> +
>> +return NOTIFY_DONE;
>> +}
> One problem this leaves behind is that registering of the new fbdev driver
> is too late - by that point we've already set up the entire driver,
> including modeset. If fbdev meanwhile does a dpms off or something like
> that all hell will break loose.

I don't understand how fbdev registration comes into play here. Drivers call
remove_conflicting_framebuffers very early so simpledrm is gone by the time
they register anything.

For simpledrm, fbdev doing blank/unblank is a no-op since fb_ops.fb_blank
is not implemented. So a fb_blank() just results in fbcon doing a
software blank.

> I think the only option is to add a new notifier chain for fbdev removal,
> called from remove_conflicting_framebuffers (even for CONFIG_FB=n, so need
> a fallback in core/fb_notify.c like with the other notifier I think). That
> would at least keep things working if fbdev is entirely disabled. Or have
> I entirely misunderstood how this works?

How about extending the new wrapper you just added. Something like this:

static int find_simpledrm_cb(struct device *dev, void *data)
{
 struct platform_device *pdev = to_platform_device(dev);
 char *name = data;

 DRM_INFO("Switching to %s from simpledrm\n", name);
 platform_device_del(pdev);

 return 0;
}

/* not sure where this function should go */
void drm_remove_simpledrm(const char *name)
{
 struct device_driver *drv;

[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1

[Jyri Sarha]

Thanks a lot!
This is very helpful as I do not have LCDC rev1 HW my self, but only
am335x based boards.

On 08/23/16 15:56, Karl Beldan wrote:
> Hi,
> 
> I found some missing bits for rev1 of the LCDC and here are some of the
> changes I am using to use the DRM driver on an LCDCK (which has a rev1).
> 1/3 seems required by rev1 of the IP and without it my the LCDC on my
> LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3
> is less of a requirement.

I'll drop 3/3, because my recent patches should take care of that:
http://www.spinics.net/lists/devicetree/msg138885.html

However, there will be v2 round of those patches. Only the DT binding
and its default value should change.

> Although 1,2/3 would have fitted drm-fixes I based them on drm-next as
> 2/3 would conflict with the recent changes in drm-next.
> 

I'll pick these two up for my next pull request. Thanks!

> Another thing which is also an absolute requirement for the rev1 but 
> with which rev2 seems to cope fine is the palette loading (even if the DRM
> uses >= 16bpp formats), dixit the TRM:
> "12-, 16-, and 24-BPP modes do not need a palette; i.e., the pixel data is
> the desired RGB value. However, the first 32 bytes are still considered a
> palette. The first entry should be 4000h (bit 14 is 1) while the remaining
> entries must be filled with 0.".
> ATM I am using a local crude way of loading the palette to verify the
> missing bits to get the DRM driver properly working on the LCDK (as I
> haven't seen how things work in the DRM subsystem I can't post any proper
> change for that).
> 

I see. Reading from the TRM, that should be done for rev2 too. I'll try
to come up with a patch for that at some point, unless you send me one
first.

> The posted changes and the above mentioned palette loading missing bit 
> are specific to the DRM driver.
> 
> However there are other shortcomings to the proper functioning of the 
> LCDC on some platforms (I am currently focusing on the LCDK but I guess 
> it should be true for all da850 based systems), which are not inherent to
> the DRM driver driver but which strongly relate to it:
> 
> - The pixel clock rate setting (eg. currently the davinci clk can't cope
> properly with the DRM driver way of setting the clock and doesn't use
> the common clock framework)
> - The memory bandwidth/latency requirements for the LCDC are not met 
> with the default priority settings (apparently there is a fix in
> da850_lcd_hw_init of: 
> http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-omapl138-lcdk.c;h=689b4f304011e09e262782cf8c4b96eba00ac28b;hb=HEAD).
> Of course this one affects both the DRM and framebuffer systems.
> 

There is also memory bandwidth issues on am335x and we are still looking
for a proper system level fix.

> Hence to test the LCDK my crude local changes include (ie. on top of the
> posted changes and some dts or sync_lost recovery bits):
> - palette loading
> - tweak of the pixel clock to cope with davinci clk

If you have proper a fixes for these, please send a patch. The palette
loading is something I can probably do myself too, but the clock thing
is something that I at least can not test.

> - adjustment of the memory master priorities
> 

That would be a system level fix and I can not say whether or not to
take such a fix.

> 
> BTW, with the recent changes of tilcdc from drm-next, I see this warning
> when loading the module:
> "drm:drm_helper_disable_unused_functions [drm_kms_helper]] *ERROR* Called for 
> atomic driver, this is not what you want."
> 

That is also fixed in my latest patch series above.

Best regards,
Jyri

> 
> Regards, 
> Karl
> 
> 
> Karl Beldan (3):
>   drm/tilcdc: Adjust the FB_CEILING address
>   drm/tilcdc: Enable EOF interrupts for v1 LCDC
>   drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision
> 
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c  | 4 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 

[PATCH] drm/nouveau/tegra: Modify error handling

[Alexandre Courbot]

On Mon, Aug 15, 2016 at 6:54 AM, Amitoj Kaur Chawla
 wrote:
> iommu_domain_alloc returns NULL on error so replace an incorrect
> IS_ERR check with a NULL check.
>
> The Coccinelle semantic patch used to find this issue is as follows:
> @@
> expression e;
> statement S;
> @@
>
> *e = iommu_domain_alloc(...);
> if (IS_ERR(e)) S
>
> Signed-off-by: Amitoj Kaur Chawla 

Reviewed-by: Alexandre Courbot 

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Sumit Semwal]

Hi Jon,

On 23 August 2016 at 18:38, Jonathan Corbet  wrote:
> On Tue, 23 Aug 2016 08:01:35 +0200
> Daniel Vetter  wrote:
>
>> I'm also not too sure about whether dma-buf really should be it's own
>> subdirectory. It's plucked from the device-drivers.tmpl, I think an
>> overall device-drivers/ for all the misc subsystems and support code would
>> be better. Then one toc there, which fans out to either kernel-doc and
>> overview docs.
>
> I'm quite convinced it shouldn't be.
>
> If you get a chance, could you have a look at the "RFC: The beginning of
> a proper driver-api book" series I posted yesterday (yes, I should have
> copied more of you, sorry)?  It shows the direction I would like to go
> with driver API documentation, and, assuming we go that way, I'd like the
> dma-buf documentation to fit into that.
>

Thanks for your comments, and direction. I'll rework the patches on
top of yours then.
I'll have a look at your patches to think about how do we handle API
guides / detailed documentation as well.

> Thanks,
>
> jon

Best,
Sumit.

[PATCH 2/2] drm: simple_kms_helper: add support for bridges

[Andrea Merello]

On Tue, Aug 23, 2016 at 5:54 PM, Daniel Vetter  wrote:

> On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote:
> > On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter  wrote:
> >
> > > On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> > > > Introduce drm_simple_display_pipe_attach_bridge() in order
> > > > to make it possible to use drm encoders with the simple display
> > > > pipes managed by simple_kms_helpers
> > > >
> > > > Suggested-by: Daniel Vetter 
> > > > Signed-off-by: Andrea Merello 
> > > > Cc: Noralf Trønnes 
> > > > Cc: Daniel Vetter 
> > > > Cc: David Airlie 
> > >
> > > Threading of your patch series is somehow broken, usually that should
> all
> > > work nicely if you've set up git send-email.
> > >
> > > One question: Should we ahve a drm_simple_display_pipe_detach_bridge
> (for
> > > cleanup) too?
> > >
> >
> > Unsure if it worths. May be nice to have a balanced pair, but it would
> > probably end up in
> > a quite redundant one-line func, that only calls drm_bridge_detach with
> the
> > very same argument.
> >
> > ..But of course if you want I can add it in v2 series.
>
> Yes it's just going to be a one-line, but it'll do a typecast and so
> better encapsulate the internals of the simple pipe helper.


I'm unsure about what do you mean here. Why a typecast?

Wouldn't it be simply drm_simple_display_pipe_detach_bridge(struct
drm_bridge *bridge) calling in turn drm_detach_bridge(struct drm_bridge
*bridge) with the very same argument?

Or if you want to stay behind the pipe, then it could be
drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe *pipe),
but I would say it just does something like
drm_bridge_detach(pipe->encoder.bridge), so I don't really get your point
about the cast, sorry..


> I think that's
> worth it - we have piles of functions and #defines just to make
> little one-line bits of code a notch more readable.
>
> And yes the symmetry is nice too ;-)
>

OK, then I'll add it :)

Andrea


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/4b952b0d/attachment.html>

linux-next: build failure after merge of the drm-intel tree

[Daniel Vetter]

On Tue, Aug 23, 2016 at 11:56:14AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-intel tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from drivers/gpio/gpiolib-of.c:19:0:
> include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such 
> file or directory
> In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:16:0,
>  from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
>  from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,   
>  from drivers/gpu/drm/nouveau/include/nvkm/core/client.h:3,   
>  from drivers/gpu/drm/nouveau/nvkm/core/client.c:24:
> include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such 
> file or directory
> 
> and many more.
> 
> Caused by commit
> 
>   cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about 
> the io-mapping")
> 
> I have used the drm-intel tree from next-20160822 for today.

Should be fixed now, thanks for reporting.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/

[Daniel Vetter]

On Tue, Aug 23, 2016 at 04:50:24PM +0100, Chris Wilson wrote:
> PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t
> used for the iomapped region, it itself is just PAGE_KERNEL. On all
> other arches, PAGE_KERNEL_IO is undefined so in a general header we must
> refrain from using it.
> 
> v2: include pgtable for pgprot_combine()
> 
> Reported-by: Stephen Rothwell 
> Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata 
> about the io-mapping")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Joonas Lahtinen 
> Cc: linux-mm at kvack.org

This one seems to have worked out, applied to dinq.

Thanks, Daniel

> ---
>  include/linux/io-mapping.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
> index b4c4b5c4216d..a87dd7fffc0a 100644
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -112,7 +112,7 @@ io_mapping_unmap(void __iomem *vaddr)
>  #else
>  
>  #include 
> -#include 
> +#include 
>  
>  /* Create the io_mapping object*/
>  static inline struct io_mapping *
> @@ -123,7 +123,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
>   iomap->base = base;
>   iomap->size = size;
>   iomap->iomem = ioremap_wc(base, size);
> - iomap->prot = pgprot_writecombine(PAGE_KERNEL_IO);
> + iomap->prot = pgprot_writecombine(PAGE_KERNEL);
>  
>   return iomap;
>  }
> -- 
> 2.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] gpu: ipu-v3: fix a possible NULL dereference

[Corentin LABBE]

On 23/08/2016 17:24, Sean Paul wrote:
> On Tue, Aug 16, 2016 at 9:33 AM, LABBE Corentin
>  wrote:
>> of_match_device could return NULL, and so cause a NULL pointer
>> dereference later.
>>
>> For fixing this problem, we use of_device_get_match_data(), this will
>> simplify the code a little by using a standard function for
>> getting the match data.
>>
>> Signed-off-by: LABBE Corentin 
>> ---
>>  drivers/gpu/ipu-v3/ipu-common.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/ipu-v3/ipu-common.c 
>> b/drivers/gpu/ipu-v3/ipu-common.c
>> index 99dcacf..05a9cc6 100644
>> --- a/drivers/gpu/ipu-v3/ipu-common.c
>> +++ b/drivers/gpu/ipu-v3/ipu-common.c
>> @@ -1207,15 +1207,13 @@ EXPORT_SYMBOL_GPL(ipu_dump);
>>
>>  static int ipu_probe(struct platform_device *pdev)
>>  {
>> -   const struct of_device_id *of_id =
>> -   of_match_device(imx_ipu_dt_ids, >dev);
>> struct ipu_soc *ipu;
>> struct resource *res;
>> unsigned long ipu_base;
>> int i, ret, irq_sync, irq_err;
>> const struct ipu_devtype *devtype;
>>
>> -   devtype = of_id->data;
>> +   devtype = of_device_get_match_data(>dev);
> 
> While you avoid the of_id dereference, it's possible that
> of_device_get_match_data() returns NULL, so you're really just moving
> the oops around.
> 
> Sean
> 

Hello

I apologize for didnt seen that, I will send an updated patch which fix that.

Regards

[PATCH 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property

[Milo Kim]

Handle legacy and raw 'phy' parsing in single function.
And it also removes goto condition.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Rob Herring 
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6a636f2..bb2d6d4 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct 
device *dev)
return np;
 }

-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static struct device_node *hdmi_phy_dt_binding(struct device *dev)
 {
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, compatible_str);
+   if (np)
+   return np;
+
+   np = of_parse_phandle(dev->of_node, "phy", 0);
+   if (!np)
+   return NULL;
+
+   of_node_put(dev->of_node);

-   return of_find_compatible_node(NULL, NULL, compatible_str);
+   return np;
 }

 static int hdmi_probe(struct platform_device *pdev)
@@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}

-   phy_node = hdmi_legacy_phy_dt_binding(dev);
-   if (phy_node)
-   goto out_get_phy_port;
-
-   phy_node = of_parse_phandle(dev->of_node, "phy", 0);
+   phy_node = hdmi_phy_dt_binding(dev);
if (!phy_node) {
DRM_ERROR("Failed to find hdmiphy node in device tree\n");
ret = -ENODEV;
goto err_ddc;
}
-   of_node_put(dev->of_node);

-out_get_phy_port:
if (hdata->drv_data->is_apb_phy) {
hdata->regs_hdmiphy = of_iomap(phy_node, 0);
if (!hdata->regs_hdmiphy) {
-- 
1.9.1

[PATCH 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property

[Milo Kim]

Handle legacy and raw 'ddc' parsing in single function.
And it also removes goto condition.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Rob Herring 
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..6a636f2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
 };

-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
 {
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
@@ -1769,7 +1769,13 @@ static struct device_node 
*hdmi_legacy_ddc_dt_binding(struct device *dev)
if (np)
return of_get_next_parent(np);

-   return NULL;
+   np = of_parse_phandle(dev->of_node, "ddc", 0);
+   if (!np)
+   return NULL;
+
+   of_node_put(dev->of_node);
+
+   return np;
 }

 static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}

-   ddc_node = hdmi_legacy_ddc_dt_binding(dev);
-   if (ddc_node)
-   goto out_get_ddc_adpt;
-
-   ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
+   ddc_node = hdmi_ddc_dt_binding(dev);
if (!ddc_node) {
DRM_ERROR("Failed to find ddc node in device tree\n");
return -ENODEV;
}
-   of_node_put(dev->of_node);

-out_get_ddc_adpt:
hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
if (!hdata->ddc_adpt) {
DRM_ERROR("Failed to get ddc i2c adapter by node\n");
-- 
1.9.1

[PATCH 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

[Milo Kim]

This patch enables getting a HPD GPIO descriptor quickly.
The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.

static int hdmi_resources_init(struct hdmi_context *hdata)
{
...
hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
...
}

This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.

However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
always retries to get a GPIO descriptor because the first GPIO suffix is not
'gpio' but 'gpios'. So you always see the debug message below.

of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node 
'/soc/hdmi at 1453[0]'

Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Rob Herring 
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 4 ++--
 arch/arm/boot/dts/exynos4210-universal_c210.dts  | 2 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi  | 2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts| 2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi| 2 +-
 arch/arm/boot/dts/exynos5250-spring.dts  | 2 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts   | 2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts| 2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi   | 2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts| 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index a2ec4c1..6394ea9 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -9,7 +9,7 @@ Required properties:
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
+- hpd-gpios: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
@@ -56,7 +56,7 @@ Example:
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
-   hpd-gpio = < 7 1>;
+   hpd-gpios = < 7 1>;
ddc = <_ddc_node>;
phy = <_phy_node>;
samsung,syscon-phandle = <_system_controller>;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 9a75e3e..cf95202 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -269,7 +269,7 @@
 };

  {
-   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
hdmi-en-supply = <_en>;
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 58ad48e7..be644fe 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -227,7 +227,7 @@
 };

  {
-   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
vdd-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index ea70603..3d981f3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -152,7 +152,7 @@
 };

  {
-   hpd-gpio = < 7 GPIO_ACTIVE_LOW>;
+   hpd-gpios = < 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <_reg>;
vdd_pll-supply = <_reg>;
vdd-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 381af13..7f27263 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -116,7 +116,7 @@
 };

  {
-   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
 };

 _0 {
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index fadbea7..1055d25 100644
--- 

[PATCH 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board

[Milo Kim]

* Support HDMI display data channel
  I2C #2 is assigned for the HDMI DDC. It enables the EDID access.

* GPIO for HDMI hot plug detect
  GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
  single ended.

* Enable HDMI block in Exynos5420
  HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
  1.8V LDO7 (PVDD_ANAIP_1V8).

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Rob Herring 
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 39a3b81..df362a2 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -70,6 +70,23 @@
status = "disabled";
 };

+_2 {
+   samsung,i2c-slave-addr = <0x50>;
+   status = "okay";
+
+   hdmiddc at 50 {
+   compatible = "samsung,exynos4210-hdmiddc";
+   reg = <0x50>;
+   };
+};
+
+ {
+   hpd-gpios = < 7 GPIO_OPEN_SOURCE>;
+   vdd_osc-supply = <_reg>;
+   vdd_pll-supply = <_reg>;
+   status = "okay";
+};
+
 _4 {
status = "okay";

-- 
1.9.1

[PATCH 0/4] ARM: dts: exynos: Enable HDMI in Arndale Octa board

[Milo Kim]

This patch-set enables HDMI in Arndale Octa board and fixes HPD DT property.
It also includes code refactoring on ddc and phy.

Milo Kim (4):
  ARM: dts: exynos: Enable HDMI for Arndale Octa board
  ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
  gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT
property
  gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT
property

 .../bindings/display/exynos/exynos_hdmi.txt|  4 +--
 arch/arm/boot/dts/exynos4210-universal_c210.dts|  2 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts   |  2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |  2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi  |  2 +-
 arch/arm/boot/dts/exynos5250-spring.dts|  2 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 17 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |  2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |  2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 41 --
 13 files changed, 52 insertions(+), 30 deletions(-)

-- 
1.9.1

[PATCH 2/2] drm: simple_kms_helper: add support for bridges

[Daniel Vetter]

On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote:
> On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter  wrote:
> 
> > On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> > > Introduce drm_simple_display_pipe_attach_bridge() in order
> > > to make it possible to use drm encoders with the simple display
> > > pipes managed by simple_kms_helpers
> > >
> > > Suggested-by: Daniel Vetter 
> > > Signed-off-by: Andrea Merello 
> > > Cc: Noralf Trønnes 
> > > Cc: Daniel Vetter 
> > > Cc: David Airlie 
> >
> > Threading of your patch series is somehow broken, usually that should all
> > work nicely if you've set up git send-email.
> >
> > One question: Should we ahve a drm_simple_display_pipe_detach_bridge (for
> > cleanup) too?
> >
> 
> Unsure if it worths. May be nice to have a balanced pair, but it would
> probably end up in
> a quite redundant one-line func, that only calls drm_bridge_detach with the
> very same argument.
> 
> ..But of course if you want I can add it in v2 series.

Yes it's just going to be a one-line, but it'll do a typecast and so
better encapsulate the internals of the simple pipe helper. I think that's
worth it - we have piles of functions and #defines just to make
little one-line bits of code a notch more readable.

And yes the symmetry is nice too ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm: simple_kms_helper: add support for bridges

[Andrea Merello]

On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter  wrote:

> On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> > Introduce drm_simple_display_pipe_attach_bridge() in order
> > to make it possible to use drm encoders with the simple display
> > pipes managed by simple_kms_helpers
> >
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Andrea Merello 
> > Cc: Noralf Trønnes 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
>
> Threading of your patch series is somehow broken, usually that should all
> work nicely if you've set up git send-email.
>
> One question: Should we ahve a drm_simple_display_pipe_detach_bridge (for
> cleanup) too?
>

Unsure if it worths. May be nice to have a balanced pair, but it would
probably end up in
a quite redundant one-line func, that only calls drm_bridge_detach with the
very same argument.

..But of course if you want I can add it in v2 series.

(ACK for all other things)

Andrea


> -Daniel
>
> >
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 3a48c7c..05ee61d 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -133,6 +133,28 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> >  };
> >
> >  /**
> > + * drm_simple_display_pipe_attach_bridge - Attach a bridge to the
> display pipe
> > + * @pipe: simple display pipe object
> > + * @bridge: bridge to attach
> > + *
> > + * Makes it possible to still use the drm_simple_display_pipe helpers
> when
> > + * a DRM bridge has to be used.
> > + * Note that you probably want to initialize the pipe by passing a NULL
> > + * connector to drm_simple_display_pipe_init()
> > + *
> > + * Returns:
> > + * Zero on success, negative error code on failure.
> > + */
> > +int drm_simple_display_pipe_attach_bridge(struct
> drm_simple_display_pipe *pipe,
> > + struct drm_bridge *bridge)
> > +{
> > + bridge->encoder = >encoder;
> > + pipe->encoder.bridge = bridge;
> > + return drm_bridge_attach(pipe->encoder.dev, bridge);
> > +}
> > +EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
> > +
> > +/**
> >   * drm_simple_display_pipe_init - Initialize a simple display pipeline
> >   * @dev: DRM device
> >   * @pipe: simple display pipe object to initialize
> > diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> > index 2690397..1d73bcf 100644
> > --- a/include/drm/drm_simple_kms_helper.h
> > +++ b/include/drm/drm_simple_kms_helper.h
> > @@ -85,6 +85,9 @@ struct drm_simple_display_pipe {
> >   const struct drm_simple_display_pipe_funcs *funcs;
> >  };
> >
> > +int drm_simple_display_pipe_attach_bridge(struct
> drm_simple_display_pipe *pipe,
> > + struct drm_bridge *bridge);
> > +
> >  int drm_simple_display_pipe_init(struct drm_device *dev,
> >   struct drm_simple_display_pipe *pipe,
> >   const struct drm_simple_display_pipe_funcs *funcs,
> > --
> > 2.7.4
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/2e28e30d/attachment-0001.html>

[PATCH] drm/fb-helper: Make docs for fb_set_suspend wrappers consistent

[Daniel Vetter]

I figured I might as well go ocd and make them booleans and rename the
locked version too.

Reported-by: kbuild test robot 
Cc: Noralf Trønnes 
Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 8 
 include/drm/drm_fb_helper.h | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 10585c462d85..e1af1d08511b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1035,13 +1035,13 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
 /**
  * drm_fb_helper_set_suspend - wrapper around fb_set_suspend
  * @fb_helper: driver-allocated fbdev helper
- * @state: desired state, zero to resume, non-zero to suspend
+ * @suspend: whether to suspend or resume
  *
  * A wrapper around fb_set_suspend implemented by fbdev core.
  * Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
  * the lock yourself
  */
-void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
+void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend)
 {
if (fb_helper && fb_helper->fbdev)
fb_set_suspend(fb_helper->fbdev, state);
@@ -1052,7 +1052,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
  * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that also
  *  takes the console lock
  * @fb_helper: driver-allocated fbdev helper
- * @state: desired state, zero to resume, non-zero to suspend
+ * @suspend: whether to suspend or resume
  *
  * A wrapper around fb_set_suspend() that takes the console lock. If the lock
  * isn't available on resume, a worker is tasked with waiting for the lock
@@ -1065,7 +1065,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
  * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
  */
 void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
-   int suspend)
+   bool suspend)
 {
if (!fb_helper || !fb_helper->fbdev)
return;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 0c6e53d9ce68..6c812e3c8bfc 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -265,9 +265,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
 void drm_fb_helper_cfb_imageblit(struct fb_info *info,
 const struct fb_image *image);

-void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
+void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend);
 void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
-   int suspend);
+   bool suspend);

 int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);

@@ -421,7 +421,7 @@ static inline void drm_fb_helper_cfb_imageblit(struct 
fb_info *info,
 }

 static inline void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper,
-int state)
+bool suspend)
 {
 }

-- 
2.9.3

[PATCH] drm/bridge: introduce bridge detaching mechanism

[Daniel Vetter]

On Tue, Aug 23, 2016 at 04:10:04PM +0200, Andrea Merello wrote:
> Up to now, once a bridge has been attached to a DRM device, it cannot
> be undone.
> 
> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
> because the bridge would remain bound to the first (dead) driver instance.
> 
> This patch fixes this by introducing drm_encoder_detach() and a ->detach
> callback in drm_bridge_funcs for the bridge to be notified about detaches.
> 
> It's DRM/KMS driver responsibility to call drm_encoder_detach().
> 
> Suggested-by: Daniel Vetter 
> Suggested-by: Lucas Stach 
> Signed-off-by: Andrea Merello 
> Cc: Archit Taneja 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lucas Stach 
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 2555430..c4ace90 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -125,6 +125,39 @@ int drm_bridge_attach(struct drm_device *dev, struct 
> drm_bridge *bridge)
>  EXPORT_SYMBOL(drm_bridge_attach);
> 
>  /**
> + * drm_bridge_detach - deassociate given bridge from its DRM device
> + *
> + * @bridge: bridge control structure
> + *
> + * called by a kms driver to unlink one of our encoder/bridge to the given
> + * bridge.
> + *
> + * Note that tearing down links between the bridge and our encoder/bridge
> + * objects needs to be handled by the kms driver itself
> + *
> + * RETURNS:
> + * Zero on success, error code on failure
> + */
> +int drm_bridge_detach(struct drm_bridge *bridge)

Generally detach/cleanup functions have a return type of void - there's no
way (usually) to bail out on errors anyway.

> +{
> + int ret;
> +
> + if (!bridge || !bridge->dev)

Hence WARN_ON here probably.

> + return -EINVAL;
> +
> + if (bridge->funcs->detach) {
> + ret = bridge->funcs->detach(bridge);

Same for the callback to the backend.
> + if (ret)
> + return ret;
> + }
> +
> + bridge->dev = NULL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_bridge_detach);
> +
> +/**
>   * DOC: bridge callbacks
>   *
>   * The _bridge_funcs ops are populated by the bridge driver. The DRM
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b618b50..eef4db8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1766,6 +1766,7 @@ struct drm_plane {
>   */
>  struct drm_bridge_funcs {
>   int (*attach)(struct drm_bridge *bridge);
> + int (*detach)(struct drm_bridge *bridge);

kerneldoc for @detach is missing here. And I think it'd be good to also
make the kerneldoc for @attach a stand-alone comment and flesh it out a
bit.

You might also need to include this into the simple pipe series so that
you can wire up detach support for those helpers too.

Otherwise looks all good I think.

Thanks, Daniel

> 
>   /**
>* @mode_fixup:
> @@ -3196,6 +3197,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
>  extern void drm_bridge_remove(struct drm_bridge *bridge);
>  extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
>  extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge 
> *bridge);
> +extern int drm_bridge_detach(struct drm_bridge *bridge);
> 
>  bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
>   const struct drm_display_mode *mode,
> --
> 2.7.4

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm: simple_kms_helper: add support for bridges

[Daniel Vetter]

On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> Introduce drm_simple_display_pipe_attach_bridge() in order
> to make it possible to use drm encoders with the simple display
> pipes managed by simple_kms_helpers
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Andrea Merello 
> Cc: Noralf Trønnes 
> Cc: Daniel Vetter 
> Cc: David Airlie 

Threading of your patch series is somehow broken, usually that should all
work nicely if you've set up git send-email.

One question: Should we ahve a drm_simple_display_pipe_detach_bridge (for
cleanup) too?
-Daniel

> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 3a48c7c..05ee61d 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -133,6 +133,28 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>  };
> 
>  /**
> + * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display 
> pipe
> + * @pipe: simple display pipe object
> + * @bridge: bridge to attach
> + *
> + * Makes it possible to still use the drm_simple_display_pipe helpers when
> + * a DRM bridge has to be used.
> + * Note that you probably want to initialize the pipe by passing a NULL
> + * connector to drm_simple_display_pipe_init()
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe 
> *pipe,
> + struct drm_bridge *bridge)
> +{
> + bridge->encoder = >encoder;
> + pipe->encoder.bridge = bridge;
> + return drm_bridge_attach(pipe->encoder.dev, bridge);
> +}
> +EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
> +
> +/**
>   * drm_simple_display_pipe_init - Initialize a simple display pipeline
>   * @dev: DRM device
>   * @pipe: simple display pipe object to initialize
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index 2690397..1d73bcf 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -85,6 +85,9 @@ struct drm_simple_display_pipe {
>   const struct drm_simple_display_pipe_funcs *funcs;
>  };
> 
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe 
> *pipe,
> + struct drm_bridge *bridge);
> +
>  int drm_simple_display_pipe_init(struct drm_device *dev,
>   struct drm_simple_display_pipe *pipe,
>   const struct drm_simple_display_pipe_funcs *funcs,
> --
> 2.7.4

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] drm: simple_kms_helper: make connector optional at init time

[Daniel Vetter]

On Tue, Aug 23, 2016 at 04:05:57PM +0200, Andrea Merello wrote:
> drm_simple_display_pipe_init() pretendes to attach a connector
> to the display pipe.
> 
> In case a drm bridge has to be used, then it's the bridge that
> takes care of connectors.
> 
> This patch makes the connector parameter optional for
> drm_simple_display_pipe_init(), so that a drm bridge could
> handle connector by itslef later.
> 
> Signed-off-by: Andrea Merello 
> Cc: David Airlie 
> Cc: Noralf Trønnes 
> Cc: Daniel Vetter 
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0a02efe..3a48c7c 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -139,7 +139,7 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>   * @funcs: callbacks for the display pipe (optional)
>   * @formats: array of supported formats (%DRM_FORMAT_*)
>   * @format_count: number of elements in @formats
> - * @connector: connector to attach and register
> + * @connector: connector to attach and register (optional)
>   *
>   * Sets up a display pipeline which consist of a really simple
>   * plane-crtc-encoder pipe coupled with the provided connector.

I think a few more words when a NULL @connector here would be great,
essentially what you've written already in the changelog. Plus then in
patch 2 add a cross-link here to the new function your adding - that
happens automatically if you append ().

btw pls also check the generated output using

$ make DOCBOOKS="" htmldocs

to make sure the links are all pretty.
-Daniel

> @@ -181,7 +181,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
>   encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
>   ret = drm_encoder_init(dev, encoder, _simple_kms_encoder_funcs,
>  DRM_MODE_ENCODER_NONE, NULL);
> - if (ret)
> + if (ret || !connector)
>   return ret;
> 
>   return drm_mode_connector_attach_encoder(connector, encoder);
> --
> 2.7.4

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Daniel Vetter]

On Tue, Aug 23, 2016 at 08:16:33AM -0600, Jonathan Corbet wrote:
> On Tue, 23 Aug 2016 15:28:55 +0200
> Daniel Vetter  wrote:
> 
> > I think the more interesting story is, what's your plan with all the
> > other driver related subsystem? Especially the ones which already have
> > full directories of their own, like e.g. Documentation/gpio/. I think
> > those should be really part of the infrastructure section (or
> > something equally high-level), together with other awesome servies
> > like pwm, regman, irqchip, ... And then there's also the large-scale
> > subsystems like media or gpu. What's the plan to tie them all
> > together? Personally I'm leaning towards keeping the existing
> > directories (where they exist already), but inserting links into the
> > overall driver-api section.
> 
> To say I have a plan is to overstate things somewhat...
> 
> One objective I do have, though, is to declutter Documentation/.
> Presenting people looking for docs with a 270-file directory is
> unfriendly to say the least.  We don't organize the code that way; the
> average in the kernel is <... find | wc -l ... > about 15
> files/directory, which is rather more manageable.  Someday I'd like
> Documentation/ to look a lot more like the top-level directory.
> 
> It seems to me that we have a few basic types of stuff here:
> 
>  - Driver API documentation, obviously, is a lot of it, and I would like
>to organize it better and to move it out of the top-level directory.
> 
>  - Hardware usage information - module parameters, sysfs files, supported
>hardware information, graphic descriptions of the ancestry of hardware
>engineers, etc.  The readership for this stuff is quite different, and
>I think it should be separate; often it's intertwined with API
>information at the moment.
> 
>  - Other usage information - a lot of what's under filesystems/ for
>example, and more.

Hm yeah, I don't have a plan really for what to do with usage docs for
users (as opposed to api docs for kernel developers). With DRM
comparatively few people end up writing userspace for our apis, hence I
think this is a lower priority issue for us. Definitely something I'd like
to address eventually. I think for drivers a big part here is documenting
the ioctls and all the other uapi bits

>  - Core API documentation.

Personally I'm very much interesting in dragging all the locking
primitives into the rst/sphinx world. We already make heavy use fo
ww_mutex, and we started to make rather heavy use of rcu in drm and
drm/i915. I'd like to be able to directly reference these underlying
primitives. For KS I'll try to convince Paul that this is an awesome idea
;-)

>  - Kernel development tools - the stuff I started pulling together into
>the dev-tools/ subdirectory.
> 
>  - How to deal with this unruly mob - SubmittingPatches, CodingStyle,
>development-process, etc.  There's process stuff, and general
>development documents like volatile-considered-harmful.txt or
>memory-barriers.txt

tbh I think the process stuff is important enough that we should imo leave
it in the top-level Documentation/ directory. Maybe collated together into
a contributing.rst index file (besides the top-level index.rst ofc).

> We can go a long way by organizing this stuff within the formatted
> documentation, but I really think we need to organize the directory
> structure as well.  I see that as a slow-moving process that will take
> years, but I do think it's a direction we should go.

Fully agreed on the larger-scale picture, and I think what I've seen thus
far from you looks great. Was simply wondering whether you have a more
concrete plane for drivers specifically already. I'm wondering whether we
should have Documentation/drivers/(gpu|media|...) too, but otoh nesting
things too deeply isn't great either. Starting out with a proper driver
directory in there is definitely the right step forward though. We can
shuffle the other bits into that later on anytime we like really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/

[Chris Wilson]

PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t
used for the iomapped region, it itself is just PAGE_KERNEL. On all
other arches, PAGE_KERNEL_IO is undefined so in a general header we must
refrain from using it.

v2: include pgtable for pgprot_combine()

Reported-by: Stephen Rothwell 
Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about 
the io-mapping")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: linux-mm at kvack.org
---
 include/linux/io-mapping.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index b4c4b5c4216d..a87dd7fffc0a 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -112,7 +112,7 @@ io_mapping_unmap(void __iomem *vaddr)
 #else

 #include 
-#include 
+#include 

 /* Create the io_mapping object*/
 static inline struct io_mapping *
@@ -123,7 +123,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->base = base;
iomap->size = size;
iomap->iomem = ioremap_wc(base, size);
-   iomap->prot = pgprot_writecombine(PAGE_KERNEL_IO);
+   iomap->prot = pgprot_writecombine(PAGE_KERNEL);

return iomap;
 }
-- 
2.9.3

[PATCH] drm/bridge: introduce bridge detaching mechanism

[Andrea Merello]

Up to now, once a bridge has been attached to a DRM device, it cannot
be undone.

In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
because the bridge would remain bound to the first (dead) driver instance.

This patch fixes this by introducing drm_encoder_detach() and a ->detach
callback in drm_bridge_funcs for the bridge to be notified about detaches.

It's DRM/KMS driver responsibility to call drm_encoder_detach().

Suggested-by: Daniel Vetter 
Suggested-by: Lucas Stach 
Signed-off-by: Andrea Merello 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Lucas Stach 

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 2555430..c4ace90 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -125,6 +125,39 @@ int drm_bridge_attach(struct drm_device *dev, struct 
drm_bridge *bridge)
 EXPORT_SYMBOL(drm_bridge_attach);

 /**
+ * drm_bridge_detach - deassociate given bridge from its DRM device
+ *
+ * @bridge: bridge control structure
+ *
+ * called by a kms driver to unlink one of our encoder/bridge to the given
+ * bridge.
+ *
+ * Note that tearing down links between the bridge and our encoder/bridge
+ * objects needs to be handled by the kms driver itself
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_bridge_detach(struct drm_bridge *bridge)
+{
+   int ret;
+
+   if (!bridge || !bridge->dev)
+   return -EINVAL;
+
+   if (bridge->funcs->detach) {
+   ret = bridge->funcs->detach(bridge);
+   if (ret)
+   return ret;
+   }
+
+   bridge->dev = NULL;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_bridge_detach);
+
+/**
  * DOC: bridge callbacks
  *
  * The _bridge_funcs ops are populated by the bridge driver. The DRM
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b618b50..eef4db8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1766,6 +1766,7 @@ struct drm_plane {
  */
 struct drm_bridge_funcs {
int (*attach)(struct drm_bridge *bridge);
+   int (*detach)(struct drm_bridge *bridge);

/**
 * @mode_fixup:
@@ -3196,6 +3197,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
 extern void drm_bridge_remove(struct drm_bridge *bridge);
 extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
 extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge 
*bridge);
+extern int drm_bridge_detach(struct drm_bridge *bridge);

 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
--
2.7.4

[PATCH 2/2] drm: simple_kms_helper: add support for bridges

[Andrea Merello]

Introduce drm_simple_display_pipe_attach_bridge() in order
to make it possible to use drm encoders with the simple display
pipes managed by simple_kms_helpers

Suggested-by: Daniel Vetter 
Signed-off-by: Andrea Merello 
Cc: Noralf Trønnes 
Cc: Daniel Vetter 
Cc: David Airlie 

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 3a48c7c..05ee61d 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -133,6 +133,28 @@ static const struct drm_plane_funcs 
drm_simple_kms_plane_funcs = {
 };

 /**
+ * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display pipe
+ * @pipe: simple display pipe object
+ * @bridge: bridge to attach
+ *
+ * Makes it possible to still use the drm_simple_display_pipe helpers when
+ * a DRM bridge has to be used.
+ * Note that you probably want to initialize the pipe by passing a NULL
+ * connector to drm_simple_display_pipe_init()
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe *pipe,
+   struct drm_bridge *bridge)
+{
+   bridge->encoder = >encoder;
+   pipe->encoder.bridge = bridge;
+   return drm_bridge_attach(pipe->encoder.dev, bridge);
+}
+EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
+
+/**
  * drm_simple_display_pipe_init - Initialize a simple display pipeline
  * @dev: DRM device
  * @pipe: simple display pipe object to initialize
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index 2690397..1d73bcf 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -85,6 +85,9 @@ struct drm_simple_display_pipe {
const struct drm_simple_display_pipe_funcs *funcs;
 };

+int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe *pipe,
+   struct drm_bridge *bridge);
+
 int drm_simple_display_pipe_init(struct drm_device *dev,
struct drm_simple_display_pipe *pipe,
const struct drm_simple_display_pipe_funcs *funcs,
--
2.7.4

[PATCH 1/2] drm: simple_kms_helper: make connector optional at init time

[Andrea Merello]

drm_simple_display_pipe_init() pretendes to attach a connector
to the display pipe.

In case a drm bridge has to be used, then it's the bridge that
takes care of connectors.

This patch makes the connector parameter optional for
drm_simple_display_pipe_init(), so that a drm bridge could
handle connector by itslef later.

Signed-off-by: Andrea Merello 
Cc: David Airlie 
Cc: Noralf Trønnes 
Cc: Daniel Vetter 

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0a02efe..3a48c7c 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -139,7 +139,7 @@ static const struct drm_plane_funcs 
drm_simple_kms_plane_funcs = {
  * @funcs: callbacks for the display pipe (optional)
  * @formats: array of supported formats (%DRM_FORMAT_*)
  * @format_count: number of elements in @formats
- * @connector: connector to attach and register
+ * @connector: connector to attach and register (optional)
  *
  * Sets up a display pipeline which consist of a really simple
  * plane-crtc-encoder pipe coupled with the provided connector.
@@ -181,7 +181,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
ret = drm_encoder_init(dev, encoder, _simple_kms_encoder_funcs,
   DRM_MODE_ENCODER_NONE, NULL);
-   if (ret)
+   if (ret || !connector)
return ret;

return drm_mode_connector_attach_encoder(connector, encoder);
--
2.7.4

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Daniel Vetter]

On Tue, Aug 23, 2016 at 3:08 PM, Jonathan Corbet  wrote:
> On Tue, 23 Aug 2016 08:01:35 +0200
> Daniel Vetter  wrote:
>
>> I'm also not too sure about whether dma-buf really should be it's own
>> subdirectory. It's plucked from the device-drivers.tmpl, I think an
>> overall device-drivers/ for all the misc subsystems and support code would
>> be better. Then one toc there, which fans out to either kernel-doc and
>> overview docs.
>
> I'm quite convinced it shouldn't be.
>
> If you get a chance, could you have a look at the "RFC: The beginning of
> a proper driver-api book" series I posted yesterday (yes, I should have
> copied more of you, sorry)?  It shows the direction I would like to go
> with driver API documentation, and, assuming we go that way, I'd like the
> dma-buf documentation to fit into that.

Looks real pretty, ack on that. And we can always split up more, e.g.
by extracting dma-buf.rst (and merg the current dma-buffer-sharing.txt
into that one).

I think the more interesting story is, what's your plan with all the
other driver related subsystem? Especially the ones which already have
full directories of their own, like e.g. Documentation/gpio/. I think
those should be really part of the infrastructure section (or
something equally high-level), together with other awesome servies
like pwm, regman, irqchip, ... And then there's also the large-scale
subsystems like media or gpu. What's the plan to tie them all
together? Personally I'm leaning towards keeping the existing
directories (where they exist already), but inserting links into the
overall driver-api section.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

[Rob Herring]

On Tue, Aug 23, 2016 at 06:13:37PM +0900, Milo Kim wrote:
> This patch enables getting a HPD GPIO descriptor quickly.
> The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
> 
>   static int hdmi_resources_init(struct hdmi_context *hdata)
>   {
>   ...
>   hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
>   ...
>   }
> 
> This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
> GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
> 
> However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
> always retries to get a GPIO descriptor because the first GPIO suffix is not
> 'gpio' but 'gpios'. So you always see the debug message below.
> 
>   of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node 
> '/soc/hdmi at 1453[0]'
> 
> Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 4 ++--
>  arch/arm/boot/dts/exynos4210-universal_c210.dts  | 2 +-
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi  | 2 +-
>  arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
>  arch/arm/boot/dts/exynos5250-smdk5250.dts| 2 +-
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi| 2 +-
>  arch/arm/boot/dts/exynos5250-spring.dts  | 2 +-
>  arch/arm/boot/dts/exynos5420-peach-pit.dts   | 2 +-
>  arch/arm/boot/dts/exynos5420-smdk5420.dts| 2 +-
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi   | 2 +-
>  arch/arm/boot/dts/exynos5800-peach-pi.dts| 2 +-
>  11 files changed, 12 insertions(+), 12 deletions(-)

Acked-by: Rob Herring 

[PATCH] drm/doc: Add a few words on validation with IGT

[Daniel Vetter]

On Tue, Aug 23, 2016 at 11:15:31AM +0200, Tomeu Vizoso wrote:
> Also provide some pointers for building IGT as some kernel hackers might
> not be that familiar with building stuff on Linux distros.
> 
> Signed-off-by: Tomeu Vizoso 
> Cc: Daniel Vetter 
> ---
>  Documentation/gpu/drm-uapi.rst | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 94876938aef3..5e425ab83dc1 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -112,3 +112,40 @@ interfaces. Especially since all hardware-acceleration 
> interfaces to
>  userspace are driver specific for efficiency and other reasons these
>  interfaces can be rather substantial. Hence every driver has its own
>  chapter.
> +
> +Validating changes with IGT
> +===

I think it'd be good to move this at least ahead of the vblank section.
The vblank section is pure legacy stuff, so best if we leave it at the
bottom.

> +
> +There's a collection of tests that aims to cover the whole functionality of
> +DRM drivers and that can be used to check that changes to DRM drivers or the
> +core don't regress existing functionality. This test suite is called IGT and
> +its code can be found in 
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools.

Daniel Stone just did a rebranding of igt, it's now in /drm/igt-gpu-tests.
Or at least should be once the updates trickle through. Please confirm
with Daniel before respinning.

Aside on that rebranding: I think we could do a similar rebranding in igt
as IGT Gpu Tests in the igt documentation. If you feel like doing that at
least.
-Daniel

> +
> +To build IGT, start by installing its build dependencies. In Debian-based
> +systems::
> +
> + # apt-get build-dep intel-gpu-tools
> +
> +And in Fedora-based systems::
> +
> + # dnf builddep intel-gpu-tools
> +
> +Then clone the repository::
> +
> + $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> +
> +Configure the build system and start the build::
> +
> + $ cd intel-gpu-tools && ./autogen.sh && make -j6
> +
> +Download the piglit dependency::
> +
> + $ ./scripts/run-tests.sh -d
> +
> +And run the tests::
> +
> + $ ./scripts/run-tests.sh -t kms -t core -s
> +
> +run-tests.sh is a wrapper around piglit that will execute the tests matching
> +the -t options. A report in HTML format will be available in
> +./results/html/index.html. Results can be compared with piglit.
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/doc: Document uapi requirements in DRM

[Daniel Vetter]

Everyone knows them, except all the new folks joining from the ARM
side haven't lived through all the pain of the past years and are
entirely surprised when I raise this. Definitely time to document
this.

Last time this was a big discussion was about 6 years ago, when qcom
tried to land a kernel driver without userspace. Dave Airlie made the
rules really clear:

http://airlied.livejournal.com/73115.html

This write-up here is essentially what I've put into a presentation a
while ago, which was also reviewed by Dave:

http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html

v2: Fix typos Eric spotted.

v3: Nitpick from Jani.

Cc: Dave Airlie 
Cc: Oded Gabbay 
Cc: Russell King 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: Lucas Stach 
Cc: Benjamin Gaignard 
Cc: Mark Yao 
Cc: Laurent Pinchart 
Cc: Ben Skeggs 
Cc: Rob Clark 
Cc: CK Hu 
Cc: Xinliang Liu 
Cc: Philipp Zabel 
Cc: Stefan Agner 
Cc: Inki Dae 
Cc: Maxime Ripard  
Cc: Boris Brezillon 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Thierry Reding 
Cc: Christian König 
Cc: Alex Deucher 
Cc: Gerd Hoffmann 
Cc: Brian Starkey 
Cc: Liviu Dudau 
Cc: Alexey Brodkin 
Acked-by: Dave Airlie 
Reviewed-by: Rob Clark 
Reviewed-by: Christian König 
Reviewed-by: Eric Anholt 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-uapi.rst | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 94876938aef3..12b47c30fe2e 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication
 Open-Source Userspace Requirements
 ==

+The DRM subsystem has stricter requirements than most other kernel subsystems 
on
+what the userspace side for new uAPI needs to look like. This section here
+explains what exactly those requirements are, and why they exist.
+
+The short summary is that any addition of DRM uAPI requires corresponding
+open-sourced userspace patches, and those patches must be reviewed and ready 
for
+merging into a suitable and canonical upstream project.
+
+GFX devices (both display and render/GPU side) are really complex bits of
+hardware, with userspace and kernel by necessity having to work together really
+closely.  The interfaces, for rendering and modesetting, must be extremely wide
+and flexible, and therefore it is almost always impossible to precisely define
+them for every possible corner case. This in turn makes it really practically
+infeasible to differentiate between behaviour that's required by userspace, and
+which must not be changed to avoid regressions, and behaviour which is only an
+accidental artifact of the current implementation.
+
+Without access to the full source code of all userspace users that means it
+becomes impossible to change the implementation details, since userspace could
+depend upon the accidental behaviour of the current implementation in minute
+details. And debugging such regressions without access to source code is pretty
+much impossible. As a consequence this means:
+
+- The Linux kernel's "no regression" policy holds in practice only for
+  open-source userspace of the DRM subsystem. DRM developers are perfectly fine
+  if closed-source blob drivers in userspace use the same uAPI as the open
+  drivers, but they must do so in the exact same way as the open drivers.
+  Creative (ab)use of the interfaces will, and in the past routinely has, lead
+  to breakage.
+
+- Any new userspace interface must have an open-source implementation as
+  demonstration vehicle.
+
+The other reason for requiring open-source userspace is uAPI review. Since the
+kernel and userspace parts of a GFX stack must work together so closely, code
+review can only assess whether a new interface achieves its goals by looking at
+both sides. Making sure that the interface indeed covers the use-case fully
+leads to a few additional requirements:
+
+- The open-source userspace must not be a toy/test application, but the real
+  thing. Specifically it needs to handle all the usual error and corner cases.
+  These are often the places where new uAPI falls apart and hence essential to
+  assess the fitness of a proposed interface.
+
+- The userspace side must be fully reviewed and tested to the standards of that
+  userspace project. For e.g. mesa this means piglit testcases and review on 
the
+  mailing list. This is again to ensure that the new interface actually gets 
the
+  job done.
+
+- The userspace patches must be against the canonical upstream, not some vendor
+  fork. This is to make sure that no one cheats on the review and testing
+  requirements by doing a quick fork.
+
+- The kernel patch can only be merged after all the above requirements are met,
+  but it **must** be merged **before** the userspace patches land. uAPI 

[Bug 91960] [i915] kernel warning hsw_unclaimed_reg_debug intel_uncore.c:619

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Renan Birck  ---
(In reply to Renan Birck from comment #7)
> Ubuntu 16.04 mainline kernel, ASUS Z450LA laptop, has a similar error:

[...]

A correction: it's not the mainline kernel; rather, it's the default kernel
rebuilt with a patch to fix this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=107971

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/f7e40dea/attachment.html>

[Bug 91960] [i915] kernel warning hsw_unclaimed_reg_debug intel_uncore.c:619

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Renan Birck  ---
Ubuntu 16.04 mainline kernel, ASUS Z450LA laptop, has a similar error:

Ago 23 11:33:48 alpha kernel: [ cut here ]
Ago 23 11:33:48 alpha kernel: WARNING: CPU: 2 PID: 3045 at
/mnt/disk2/xenial/drivers/gpu/drm/i915/intel_uncore.c:619
hsw_unclaimed_reg_debug+0x69/0x90 [i915]()
Ago 23 11:33:48 alpha kernel: Unclaimed register detected before reading
register 0x22384
Ago 23 11:33:48 alpha kernel: Modules linked in: rfcomm msr pci_stub
vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bnep binfmt_misc
nls_iso8859_1 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2
videobuf2_core v4l2_common videodev media btusb btrtl btbcm btintel intel_rapl
bluetooth x86_pkg_temp_thermal arc4 intel_powerclamp coretemp
snd_hda_codec_hdmi kvm_intel kvm rtl8723be(OE) btcoexist(OE) irqbypass
rtl_pci(OE) snd_hda_codec_realtek crct10dif_pclmul rtlwifi(OE) crc32_pclmul
mac80211 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core
asus_nb_wmi asus_wmi snd_hwdep snd_pcm sparse_keymap aesni_intel cfg80211
snd_seq_midi snd_seq_midi_event aes_x86_64 lrw snd_rawmidi rtsx_pci_ms snd_seq
gf128mul glue_helper memstick ablk_helper cryptd snd_seq_device input_leds
joydev serio_raw snd_timer
Ago 23 11:33:48 alpha kernel:  dw_dmac snd dw_dmac_core soundcore mac_hid
mei_me int3402_thermal shpchp 8250_dw snd_soc_sst_acpi mei int3400_thermal
processor_thermal_device spi_pxa2xx_platform acpi_thermal_rel
int340x_thermal_zone intel_soc_dts_iosf intel_pch_thermal lpc_ich
i2c_designware_platform tpm_crb i2c_designware_core acpi_pad parport_pc ppdev
lp parport autofs4 hid_generic usbhid hid uas usb_storage rtsx_pci_sdmmc i915
psmouse i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt r8169
ahci fb_sys_fops mii libahci drm rtsx_pci wmi sdhci_acpi video sdhci fjes
Ago 23 11:33:48 alpha kernel: CPU: 2 PID: 3045 Comm: Xorg Tainted: G  
OE   4.4.0-34-generic #53
Ago 23 11:33:48 alpha kernel: Hardware name: ASUSTeK COMPUTER INC.
Z450LA/Z450LA, BIOS Z450LA.204 08/12/2015
Ago 23 11:33:48 alpha kernel:  0086 f47942d3
88024ed03cd8 813f11b3
Ago 23 11:33:48 alpha kernel:  88024ed03d20 c025fde0
88024ed03d10 81081102
Ago 23 11:33:48 alpha kernel:  880035ac 00022384
880035ac4568 00022384
Ago 23 11:33:48 alpha kernel: Call Trace:
Ago 23 11:33:48 alpha kernel:[] dump_stack+0x63/0x90
Ago 23 11:33:48 alpha kernel:  []
warn_slowpath_common+0x82/0xc0
Ago 23 11:33:48 alpha kernel:  [] warn_slowpath_fmt+0x5c/0x80
Ago 23 11:33:48 alpha kernel:  []
hsw_unclaimed_reg_debug+0x69/0x90 [i915]
Ago 23 11:33:48 alpha kernel:  [] gen6_read32+0x59/0x1a0
[i915]
Ago 23 11:33:48 alpha kernel:  []
intel_lrc_irq_handler+0xe5/0x240 [i915]
Ago 23 11:33:48 alpha kernel:  []
gen8_gt_irq_handler+0x217/0x240 [i915]
Ago 23 11:33:48 alpha kernel:  [] gen8_irq_handler+0xa1/0x740
[i915]
Ago 23 11:33:48 alpha kernel:  []
handle_irq_event_percpu+0x8d/0x1d0
Ago 23 11:33:48 alpha kernel:  [] handle_irq_event+0x3e/0x60
Ago 23 11:33:48 alpha kernel:  [] handle_edge_irq+0x7d/0x150
Ago 23 11:33:48 alpha kernel:  [] handle_irq+0x1a/0x30
Ago 23 11:33:48 alpha kernel:  [] do_IRQ+0x4b/0xd0
Ago 23 11:33:48 alpha kernel:  [] common_interrupt+0x82/0x82
Ago 23 11:33:48 alpha kernel:[] ?
gen8_emit_request+0x224/0x320 [i915]
Ago 23 11:33:48 alpha kernel:  []
__i915_add_request+0x147/0x210 [i915]
Ago 23 11:33:48 alpha kernel:  []
i915_gem_execbuffer_retire_commands+0x26/0x30 [i915]
Ago 23 11:33:48 alpha kernel:  []
intel_execlists_submission+0x2eb/0x410 [i915]
Ago 23 11:33:48 alpha kernel:  []
i915_gem_do_execbuffer.isra.25+0xfa0/0x12a0 [i915]
Ago 23 11:33:48 alpha kernel:  []
i915_gem_execbuffer2+0xb2/0x240 [i915]
Ago 23 11:33:48 alpha kernel:  [] ?
i915_gem_busy_ioctl+0x92/0xe0 [i915]
Ago 23 11:33:48 alpha kernel:  [] drm_ioctl+0x152/0x540 [drm]
Ago 23 11:33:48 alpha kernel:  [] ?
i915_gem_execbuffer+0x310/0x310 [i915]
Ago 23 11:33:48 alpha kernel:  [] do_vfs_ioctl+0x29f/0x490
Ago 23 11:33:48 alpha kernel:  [] SyS_ioctl+0x79/0x90
Ago 23 11:33:48 alpha kernel:  []
entry_SYSCALL_64_fastpath+0x16/0x71
Ago 23 11:33:48 alpha kernel: ---[ end trace 62f496b552421664 ]---


PID 3045 is Xorg in this case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/28449294/attachment-0001.html>

i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104

[Meelis Roos]

> > > Looks like an incorrect call to drm_encoder_cleanup() from the error
> > > path. If we hit the error path we have never called drm_encoder_init.
> > > Please try:
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> > > b/drivers/gpu/drm/i915/intel_dvo.c
> > > index 47bdf9dad0d3..b9e5a63a7c9e 100644
> > > --- a/drivers/gpu/drm/i915/intel_dvo.c
> > > +++ b/drivers/gpu/drm/i915/intel_dvo.c
> > > @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev)
> > >   return;
> > >   }
> > >  
> > > - drm_encoder_cleanup(_encoder->base);
> > >   kfree(intel_dvo);
> > >   kfree(intel_connector);
> > >  }
> > 
> > It works - the BUG is gone.
> > 
> > Now I get just 
> > [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
> 
> Other than the annoying underrun, is everything else as expected? i.e.
> no connected outputs? Have we lost dvo detection?

Yes, as expected - there is no monitor connected.

-- 
Meelis Roos (mroos at linux.ee)

[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()

[Daniel Vetter]

On Mon, Aug 22, 2016 at 10:25:25PM +0200, Noralf Trønnes wrote:
> There is currently no non-fbdev mechanism in place to kick out
> simpledrm when the real hw-driver is probed. As a stop gap until
> that is in place, honour remove_conflicting_framebuffers() and
> delete the simple-framebuffer platform device when it's called.
> 
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes from version 3:
> - drm_device.platformdev is deprecated, use to_platform_device(ddev->dev).
> - fb_helper might have been released in sdrm_fbdev_fb_destroy(),
>   so open code drm_fb_helper_release_fbi()
> - Strengthen the test in sdrm_fbdev_event_notify() that we're the one.
> 
> Changes from version 2:
> - Don't forget to free fb_info when kicked out.
> 
>  drivers/gpu/drm/simpledrm/Kconfig   |  5 +++
>  drivers/gpu/drm/simpledrm/simpledrm.h   |  2 +
>  drivers/gpu/drm/simpledrm/simpledrm_drv.c   |  3 ++
>  drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 62 
> -
>  4 files changed, 70 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/simpledrm/Kconfig 
> b/drivers/gpu/drm/simpledrm/Kconfig
> index 3257590..4275d13 100644
> --- a/drivers/gpu/drm/simpledrm/Kconfig
> +++ b/drivers/gpu/drm/simpledrm/Kconfig
> @@ -16,6 +16,11 @@ config DRM_SIMPLEDRM
> If fbdev support is enabled, this driver will also provide an fbdev
> compatibility layer that supports fbcon, mmap is not supported.
> 
> +   WARNING
> +   fbdev must be enabled for simpledrm to disable itself when a real
> +   hw-driver is probed. It relies on remove_conflicting_framebuffers()
> +   to be called by the hw-driver.
> +
> If unsure, say Y.
> 
> To compile this driver as a module, choose M here: the
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h 
> b/drivers/gpu/drm/simpledrm/simpledrm.h
> index d4eb52c..3cca196 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm.h
> +++ b/drivers/gpu/drm/simpledrm/simpledrm.h
> @@ -87,5 +87,7 @@ int sdrm_fb_init(struct drm_device *ddev, struct 
> sdrm_framebuffer *fb,
>struct sdrm_gem_object *obj);
>  void sdrm_fbdev_init(struct sdrm_device *sdrm);
>  void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
> +void sdrm_fbdev_kickout_init(void);
> +void sdrm_fbdev_kickout_exit(void);
> 
>  #endif /* SDRM_DRV_H */
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c 
> b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> index fe752c6..0750652 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> @@ -531,12 +531,15 @@ static int __init sdrm_init(void)
>   }
>   }
> 
> + sdrm_fbdev_kickout_init();
> +
>   return 0;
>  }
>  module_init(sdrm_init);
> 
>  static void __exit sdrm_exit(void)
>  {
> + sdrm_fbdev_kickout_exit();
>   platform_driver_unregister(_simplefb_driver);
>  }
>  module_exit(sdrm_exit);
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c 
> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> index c6596ad..7c6db2c 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> @@ -44,6 +44,20 @@ static int sdrm_fb_mmap(struct fb_info *info, struct 
> vm_area_struct *vma)
>   return -ENODEV;
>  }
> 
> +/*
> + * Releasing has to be done outside the notifier callchain when we're
> + * kicked out, since do_unregister_framebuffer() calls put_fb_info()
> + * after the notifier has run.
> + * Open code drm_fb_helper_release_fbi() since fb_helper is freed at
> + * this point when kicked out.
> + */
> +static void sdrm_fbdev_fb_destroy(struct fb_info *info)
> +{
> + if (info->cmap.len)
> + fb_dealloc_cmap(>cmap);
> + framebuffer_release(info);
> +}
> +
>  static struct fb_ops sdrm_fbdev_ops = {
>   .owner  = THIS_MODULE,
>   .fb_fillrect= drm_fb_helper_sys_fillrect,
> @@ -53,6 +67,7 @@ static struct fb_ops sdrm_fbdev_ops = {
>   .fb_set_par = drm_fb_helper_set_par,
>   .fb_setcmap = drm_fb_helper_setcmap,
>   .fb_mmap= sdrm_fb_mmap,
> + .fb_destroy = sdrm_fbdev_fb_destroy,
>  };
> 
>  static int sdrm_fbdev_create(struct drm_fb_helper *helper,
> @@ -110,6 +125,9 @@ static int sdrm_fbdev_create(struct drm_fb_helper *helper,
>   fbi->screen_base = obj->vmapping;
>   fbi->fix.smem_len = sdrm->fb_size;
> 
> + fbi->apertures->ranges[0].base = sdrm->fb_base;
> + fbi->apertures->ranges[0].size = sdrm->fb_size;
> +
>   return 0;
> 
>  err_fbi_release:
> @@ -188,9 +206,13 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
>   sdrm->fb_helper = NULL;
>   fbdev = to_sdrm_fbdev(fb_helper);
> 
> - drm_fb_helper_unregister_fbi(fb_helper);
> + /* it might have been kicked out */
> + if (registered_fb[fbdev->fb_helper.fbdev->node])
> + drm_fb_helper_unregister_fbi(fb_helper);
> +
> + /* freeing fb_info is done in fb_ops.fb_destroy() */
> +
>   

i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104

[Meelis Roos]

> Looks like an incorrect call to drm_encoder_cleanup() from the error
> path. If we hit the error path we have never called drm_encoder_init.
> Please try:
> 
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 47bdf9dad0d3..b9e5a63a7c9e 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev)
>   return;
>   }
>  
> - drm_encoder_cleanup(_encoder->base);
>   kfree(intel_dvo);
>   kfree(intel_connector);
>  }

It works - the BUG is gone.

Now I get just 
[drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun

[   10.499523] agpgart-intel :00:00.0: Intel 865 Chipset
[   10.499623] agpgart-intel :00:00.0: detected gtt size: 131072K total, 
131072K mappable
[   10.499928] agpgart-intel :00:00.0: detected 16384K stolen memory
[   10.500939] [drm] Memory usable by graphics device = 128M
[   10.501029] [drm] Replacing VGA console driver
[   10.502804] Console: switching to colour dummy device 80x25
[   10.504746] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   10.504760] [drm] Driver supports precise vblank timestamp query.
[   11.210224] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   11.237197] [drm] RC6 disabled, disabling runtime PM support
[   11.237407] [drm] initialized overlay support
[   11.362560] [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* 
pipe A underrun
[   11.418776] i915 :00:02.0: No connectors reported connected with modes
[   11.418792] [drm] Cannot find any crtc or sizes - going 1024x768
[   11.421148] fbcon: inteldrmfb (fb0) is primary device
[   11.448292] Console: switching to colour frame buffer device 128x48
[   11.458643] i915 :00:02.0: fb0: inteldrmfb frame buffer device


-- 
Meelis Roos (mroos at linux.ee)

[PATCH v7 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Chanwoo Choi]

Hi Lin,

I reply the on v6 patch[1].
If you have another opinion, please let me know.
If my suggestion is not reasonable, we need to discuss it.

[1] https://lkml.org/lkml/2016/8/23/28

Best Regards,
Chanwoo Choi

On 2016년 08월 22일 12:36, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v7:
> -None
> 
> Changes in v6:
> -Add more detail in Documentation
> 
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
>  .../devicetree/bindings/devfreq/rk3399_dmc.txt | 85 
> ++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> new file mode 100644
> index 000..b787abb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -0,0 +1,85 @@
> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dmc".
> +- devfreq-events: Node to get DDR loading, Refer to
> +   Documentation/devicetree/bindings/devfreq/rockchip-dfi.txt
> +- interrupts: The interrupt number to the CPU. The interrupt specifier format
> +   depends on the interrupt controller. It should be DCF interrupts,
> +   when DDR dvfs finish, it will happen.
> +- clocks: Phandles for clock specified in "clock-names" property
> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
> +- operating-points-v2: Refer to 
> Documentation/devicetree/bindings/power/opp.txt
> +for details.
> +- center-supply: DMC supply node.
> +- status: Marks the node enabled/disabled.
> +
> +Optional properties:
> +- ddr_timing:  DDR timing need to pass to arm trust firmware
> +- upthreshold: The upthreshold to simpleondeamnd policy
> +- downdifferential: The downdifferential to simpleondeamnd policy
> +
> +Example:
> +
> + ddr_timing: ddr_timing {
> + compatible = "rockchip,ddr-timing";
> + ddr3_speed_bin = <21>;
> + pd_idle = <0>;
> + sr_idle = <0>;
> + sr_mc_gate_idle = <0>;
> + srpd_lite_idle  = <0>;
> + standby_idle = <0>;
> + dram_dll_dis_freq = <300>;
> + phy_dll_dis_freq = <125>;
> +
> + ddr3_odt_dis_freq = <333>;
> + ddr3_drv = ;
> + ddr3_odt = ;
> + phy_ddr3_ca_drv = ;
> + phy_ddr3_dq_drv = ;
> + phy_ddr3_odt = ;
> +
> + lpddr3_odt_dis_freq = <333>;
> + lpddr3_drv = ;
> + lpddr3_odt = ;
> + phy_lpddr3_ca_drv = ;
> + phy_lpddr3_dq_drv = ;
> + phy_lpddr3_odt = ;
> +
> + lpddr4_odt_dis_freq = <333>;
> + lpddr4_drv = ;
> + lpddr4_dq_odt = ;
> + lpddr4_ca_odt = ;
> + phy_lpddr4_ca_drv = ;
> + phy_lpddr4_ck_cs_drv = ;
> + phy_lpddr4_dq_drv = ;
> + phy_lpddr4_odt = ;
> + };
> +
> + dmc_opp_table: dmc_opp_table {
> + compatible = "operating-points-v2";
> +
> + opp00 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <66600>;
> + opp-microvolt = <90>;
> + };
> + };
> +
> + dmc: dmc {
> + compatible = "rockchip,rk3399-dmc";
> + devfreq-events = <>;
> + interrupts = ;
> + clocks = < SCLK_DDRCLK>;
> + clock-names = "dmc_clk";
> + ddr_timing = <_timing>;
> + operating-points-v2 = <_opp_table>;
> + center-supply = <_centerlogic>;
> + upthreshold = <15>;
> + downdifferential = <10>;
> + status = "disabled";
> + };
> +
> 

[PATCH v7 4/8] Documentation: bindings: add dt documentation for dfi controller

[Chanwoo Choi]

Hi Lin,

On 2016년 08월 22일 12:36, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v7:
> -None
> 
> Changes in v6:
> -None
> 
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
>  .../bindings/devfreq/event/rockchip-dfi.txt  | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
> b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> new file mode 100644
> index 000..bf42255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> @@ -0,0 +1,20 @@
> +
> +* Rockchip rk3399 DFI device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dfi".
> +- reg: physical base address of each DFI and length of memory mapped region
> +- rockchip,pmu: phandle to the syscon managing the "pmu general register 
> files"
> +- clocks: phandles for clock specified in "clock-names" property
> +- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
> +
> +Example:
> + dfi: dfi at 0xff63 {
> + reg = <0x00 0xff63 0x00 0x4000>;
> + compatible = "rockchip,rk3399-dfi";
> + rockchip,pmu = <>;
> + clocks = < PCLK_DDR_MON>;
> + clock-names = "pclk_ddr_mon";
> + status = "disabled";
> + };
> +
> 

I reviewed this patch on previous version[1] already.
[1] https://lkml.org/lkml/2016/8/16/913

There are minor requirement. If you modify it,
I'll finish the review of this patch.

-- 
Best Regards,
Chanwoo Choi

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Tom  ---
Created attachment 125978
  --> https://bugs.freedesktop.org/attachment.cgi?id=125978=edit
Xorg.log: Screen blanked during boot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/9c265afe/attachment.html>

[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Alex Deucher  ---
The patch will go upstream in the -fixes pull this week.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/4f55d11d/attachment.html>

[PATCH v2] drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()

[Daniel Vetter]

On Tue, Aug 23, 2016 at 01:54:06PM +0200, Noralf Trønnes wrote:
> This adds a function that also takes the console lock before calling
> fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
> a plain wrapper around fb_set_suspend().
> Resume is run asynchronously using a worker if the console lock is
> already taken. This is modelled after the i915 driver.
> 
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Daniel,
> 
> I haven't got time to convert drivers to use this and now that simpledrm
> won't be using it we can wait with this if you prefer, and I'll bundle it
> with tinydrm when the time comes.

Well it's ready, and maybe someone else has a need for it already. Applied
it already, thanks a lot for the quick respin.
-Daniel

> 
> Noralf.
> 
> 
> Changes from version 1:
> - Change function name to drm_fb_helper_set_suspend_unlocked()
> - Use suspend as argument name to increase readability
> 
>  drivers/gpu/drm/drm_fb_helper.c | 62 
> -
>  include/drm/drm_fb_helper.h |  9 ++
>  2 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e98..2886df5 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -29,6 +29,7 @@
>   */
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -618,6 +619,16 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper 
> *helper)
>   kfree(helper->crtc_info);
>  }
> 
> +static void drm_fb_helper_resume_worker(struct work_struct *work)
> +{
> + struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> + resume_work);
> +
> + console_lock();
> + fb_set_suspend(helper->fbdev, 0);
> + console_unlock();
> +}
> +
>  static void drm_fb_helper_dirty_work(struct work_struct *work)
>  {
>   struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> @@ -649,6 +660,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
> drm_fb_helper *helper,
>  {
>   INIT_LIST_HEAD(>kernel_fb_list);
>   spin_lock_init(>dirty_lock);
> + INIT_WORK(>resume_work, drm_fb_helper_resume_worker);
>   INIT_WORK(>dirty_work, drm_fb_helper_dirty_work);
>   helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
>   helper->funcs = funcs;
> @@ -1026,7 +1038,9 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
>   * @fb_helper: driver-allocated fbdev helper
>   * @state: desired state, zero to resume, non-zero to suspend
>   *
> - * A wrapper around fb_set_suspend implemented by fbdev core
> + * A wrapper around fb_set_suspend implemented by fbdev core.
> + * Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
> + * the lock yourself
>   */
>  void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
>  {
> @@ -1035,6 +1049,52 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> *fb_helper, int state)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> 
> +/**
> + * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that 
> also
> + *  takes the console lock
> + * @fb_helper: driver-allocated fbdev helper
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * A wrapper around fb_set_suspend() that takes the console lock. If the lock
> + * isn't available on resume, a worker is tasked with waiting for the lock
> + * to become available. The console lock can be pretty contented on resume
> + * due to all the printk activity.
> + *
> + * This function can be called multiple times with the same state since
> + * _info->state is checked to see if fbdev is running or not before 
> locking.
> + *
> + * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
> + */
> +void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> + int suspend)
> +{
> + if (!fb_helper || !fb_helper->fbdev)
> + return;
> +
> + /* make sure there's no pending/ongoing resume */
> + flush_work(_helper->resume_work);
> +
> + if (suspend) {
> + if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
> + return;
> +
> + console_lock();
> +
> + } else {
> + if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
> + return;
> +
> + if (!console_trylock()) {
> + schedule_work(_helper->resume_work);
> + return;
> + }
> + }
> +
> + fb_set_suspend(fb_helper->fbdev, suspend);
> + console_unlock();
> +}
> +EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
> +
>  static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>u16 blue, u16 regno, struct fb_info *info)
>  {
> diff --git a/include/drm/drm_fb_helper.h 

[PATCH v6 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Chanwoo Choi]

Hi Lin,

On 2016년 08월 22일 07:16, hl wrote:
> Hi Chanwoo Choi,
> 
> On 2016年08月17日 12:50, Chanwoo Choi wrote:
>> Hi Lin,
>>
>> On 2016년 08월 17일 07:36, Lin Huang wrote:
>>> This patch adds the documentation for rockchip rk3399 dmc driver.
>>>
>>> Signed-off-by: Lin Huang 
>>> ---
>>> Changes in v6:
>>> -Add more detail in Documentation
>>>
>>> Changes in v5:
>>> -None
>>>
>>> Changes in v4:
>>> -None
>>>
>>> Changes in v3:
>>> -None
>>>
>>> Changes in v2:
>>> -None
>>>
>>> Changes in v1:
>>> -None
>>>   .../devicetree/bindings/devfreq/rk3399_dmc.txt | 84 
>>> ++
>>>   1 file changed, 84 insertions(+)
>>>   create mode 100644 
>>> Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
>>> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>> new file mode 100644
>>> index 000..e73067c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>> @@ -0,0 +1,84 @@
>>> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
>>> +
>>> +Required properties:
>>> +- compatible: Must be "rockchip,rk3399-dmc".
>>> +- devfreq-events: Node to get ddr loading, Refer to
>>> +  Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
>>> +- interrupts: The interrupt number to the cpu. The interrupt specifier 
>>> format
>>> +  depends on the interrupt controller. it should be dcf interrupts,
>>> +  when ddr dvfs finish, it will happen.
>> If possible, you better to keep the indentation with other properties.
>> s/it->It, dcf->DCF, ddr->DDR
>>
>>
>>> +- clocks: Phandles for clock specified in "clock-names" property
>>> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
>>> +- operating-points-v2: Refer to 
>>> Documentation/devicetree/bindings/power/opp.txt
>>> +   for details.
>> ditto.
>>
>>> +- center-supply: Dmc supply node.
>> s/Dmc/DMC becaue DMC an abbreviation.
>>
>>> +- status: Marks the node enabled/disabled.
>>> +
>>> +Optional properties:
>>> +- ddr_timing: ddr timing need to pass to arm trust firmware
>>> +- upthreshold: the upthreshold to simpleondeamnd policy
>>> +- downdifferential: The downdifferential to simpleondeamnd policy
>>> +
>>> +Example:
>>> +ddr_timing: ddr_timing {
>>> +compatible = "rockchip,ddr-timing";
>> I can't find the 'rockchip,ddr-timing' driver on linux-next git repo 
>> (20160816).
>> If ddr_timing includes the only properties for ddr_timing,
>> I recommend you make the separate a .dtsi file including
>> the ddr timing configuration. I add the reference and an example on below.
>>
>>> +ddr3_speed_bin = <21>;
>>> +pd_idle = <0>;
>>> +sr_idle = <0>;
>>> +sr_mc_gate_idle = <0>;
>>> +srpd_lite_idle= <0>;
>>> +standby_idle = <0>;
>>> +dram_dll_dis_freq = <300>;
>>> +phy_dll_dis_freq = <125>;
>>> +
>>> +ddr3_odt_dis_freq = <333>;
>>> +ddr3_drv = ;
>>> +ddr3_odt = ;
>>> +phy_ddr3_ca_drv = ;
>>> +phy_ddr3_dq_drv = ;
>>> +phy_ddr3_odt = ;
>>> +
>>> +lpddr3_odt_dis_freq = <333>;
>>> +lpddr3_drv = ;
>>> +lpddr3_odt = ;
>>> +phy_lpddr3_ca_drv = ;
>>> +phy_lpddr3_dq_drv = ;
>>> +phy_lpddr3_odt = ;
>>> +
>>> +lpddr4_odt_dis_freq = <333>;
>>> +lpddr4_drv = ;
>>> +lpddr4_dq_odt = ;
>>> +lpddr4_ca_odt = ;
>>> +phy_lpddr4_ca_drv = ;
>>> +phy_lpddr4_ck_cs_drv = ;
>>> +phy_lpddr4_dq_drv = ;
>>> +phy_lpddr4_odt = ;
>>> +};
>>> +
>>> +dmc_opp_table: dmc_opp_table {
>>> +compatible = "operating-points-v2";
>>> +
>>> +opp00 {
>>> +opp-hz = /bits/ 64 <3>;
>>> +opp-microvolt = <90>;
>>> +};
>>> +opp01 {
>>> +opp-hz = /bits/ 64 <66600>;
>>> +opp-microvolt = <90>;
>>> +};
>>> +};
>>> +
>>> +dmc: dmc {
>>> +compatible = "rockchip,rk3399-dmc";
>>> +devfreq-events = <>;
>>> +interrupts = ;
>>> +clocks = < SCLK_DDRCLK>;
>>> +clock-names = "dmc_clk";
>>> +ddr_timing = <_timing>;
>> You can use the following '#include' instead of 'ddr_timing'
>> because the ddr_timing is not a device driver. Instead,
>> the rk3399-dmc must need the ddr timing configuration.
>>
>> #include "rk3399-dmc-timing-conf.dtsi"
>>
>> You can refer the similar usage case[1].
>> The *.conf.dtsi is used on exynos3250 tmu dt node[2].
>>
>> [1] arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
>> [2] arch/arm/boot/dts/exynos3250.dtsi, 224 line.
>>
>>> +operating-points-v2 = <_opp_table>;
>>> +center-supply = <_centerlogic>;
>>> +upthreshold = <15>;
>>> +downdifferential = <10>;
>>> +status = "disabled";
>>> +};
>>> +
>>>
>> For example,
>> I think that you can add the 

[PATCH v2] drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()

[Noralf Trønnes]

This adds a function that also takes the console lock before calling
fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
a plain wrapper around fb_set_suspend().
Resume is run asynchronously using a worker if the console lock is
already taken. This is modelled after the i915 driver.

Signed-off-by: Noralf Trønnes 
---

Daniel,

I haven't got time to convert drivers to use this and now that simpledrm
won't be using it we can wait with this if you prefer, and I'll bundle it
with tinydrm when the time comes.

Noralf.


Changes from version 1:
- Change function name to drm_fb_helper_set_suspend_unlocked()
- Use suspend as argument name to increase readability

 drivers/gpu/drm/drm_fb_helper.c | 62 -
 include/drm/drm_fb_helper.h |  9 ++
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ce54e98..2886df5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -29,6 +29,7 @@
  */
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

+#include 
 #include 
 #include 
 #include 
@@ -618,6 +619,16 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper 
*helper)
kfree(helper->crtc_info);
 }

+static void drm_fb_helper_resume_worker(struct work_struct *work)
+{
+   struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
+   resume_work);
+
+   console_lock();
+   fb_set_suspend(helper->fbdev, 0);
+   console_unlock();
+}
+
 static void drm_fb_helper_dirty_work(struct work_struct *work)
 {
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
@@ -649,6 +660,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
drm_fb_helper *helper,
 {
INIT_LIST_HEAD(>kernel_fb_list);
spin_lock_init(>dirty_lock);
+   INIT_WORK(>resume_work, drm_fb_helper_resume_worker);
INIT_WORK(>dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
helper->funcs = funcs;
@@ -1026,7 +1038,9 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
  * @fb_helper: driver-allocated fbdev helper
  * @state: desired state, zero to resume, non-zero to suspend
  *
- * A wrapper around fb_set_suspend implemented by fbdev core
+ * A wrapper around fb_set_suspend implemented by fbdev core.
+ * Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
+ * the lock yourself
  */
 void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
 {
@@ -1035,6 +1049,52 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
*fb_helper, int state)
 }
 EXPORT_SYMBOL(drm_fb_helper_set_suspend);

+/**
+ * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that also
+ *  takes the console lock
+ * @fb_helper: driver-allocated fbdev helper
+ * @state: desired state, zero to resume, non-zero to suspend
+ *
+ * A wrapper around fb_set_suspend() that takes the console lock. If the lock
+ * isn't available on resume, a worker is tasked with waiting for the lock
+ * to become available. The console lock can be pretty contented on resume
+ * due to all the printk activity.
+ *
+ * This function can be called multiple times with the same state since
+ * _info->state is checked to see if fbdev is running or not before locking.
+ *
+ * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
+ */
+void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
+   int suspend)
+{
+   if (!fb_helper || !fb_helper->fbdev)
+   return;
+
+   /* make sure there's no pending/ongoing resume */
+   flush_work(_helper->resume_work);
+
+   if (suspend) {
+   if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
+   return;
+
+   console_lock();
+
+   } else {
+   if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
+   return;
+
+   if (!console_trylock()) {
+   schedule_work(_helper->resume_work);
+   return;
+   }
+   }
+
+   fb_set_suspend(fb_helper->fbdev, suspend);
+   console_unlock();
+}
+EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
+
 static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
 u16 blue, u16 regno, struct fb_info *info)
 {
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index db8d478..5bde508 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -176,6 +176,7 @@ struct drm_fb_helper_connector {
  *  the screen buffer
  * @dirty_lock: spinlock protecting @dirty_clip
  * @dirty_work: worker used to flush the framebuffer
+ * @resume_work: worker used during resume if the console lock is already taken
  *
  * 

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Mauro Carvalho Chehab]

Em Tue, 23 Aug 2016 08:16:33 -0600
Jonathan Corbet  escreveu:

> On Tue, 23 Aug 2016 15:28:55 +0200
> Daniel Vetter  wrote:
> 
> > I think the more interesting story is, what's your plan with all the
> > other driver related subsystem? Especially the ones which already have
> > full directories of their own, like e.g. Documentation/gpio/. I think
> > those should be really part of the infrastructure section (or
> > something equally high-level), together with other awesome servies
> > like pwm, regman, irqchip, ... And then there's also the large-scale
> > subsystems like media or gpu. What's the plan to tie them all
> > together? Personally I'm leaning towards keeping the existing
> > directories (where they exist already), but inserting links into the
> > overall driver-api section.  
> 
> To say I have a plan is to overstate things somewhat...
> 
> One objective I do have, though, is to declutter Documentation/.
> Presenting people looking for docs with a 270-file directory is
> unfriendly to say the least.  We don't organize the code that way; the
> average in the kernel is <... find | wc -l ... > about 15
> files/directory, which is rather more manageable.  Someday I'd like
> Documentation/ to look a lot more like the top-level directory.

Makes sense, although 15 files/dir doesn't seem feasible...

I actually grouped the media documentation on a more logical arrangement,
grouping things per API type.

Yet, just the V4L userspace docs (Documentation/media/uapi/v4l/)
has ~200 files :) 

And I think that a few of them, like the extended-controls.rst one
are too big and should likely be split in some future.

> 
> It seems to me that we have a few basic types of stuff here:
> 
>  - Driver API documentation, obviously, is a lot of it, and I would like
>to organize it better and to move it out of the top-level directory.
> 
>  - Hardware usage information - module parameters, sysfs files, supported
>hardware information, graphic descriptions of the ancestry of hardware
>engineers, etc.  The readership for this stuff is quite different, and
>I think it should be separate; often it's intertwined with API
>information at the moment.

In the case or media, I ended by merging those into one subdir for V4L2
and another one for DVB (currently, we don't have hardware usage documents
for Remote Controllers or CEC devices).

I wouldn't mind moving them to some other place, although a few rst files
there are actually linked to kAPI documentation.

Btw, we have, at the media subsystem, several drivers using the
kernel-doc syntax to describe functions that are internal to a driver,
and even some alien markups using some Doxygen syntax out there.
Maybe some day we'll end by adding such documentation on some
driver-specific rst file, probably at a hardware section of the
documentation.

> 
>  - Other usage information - a lot of what's under filesystems/ for
>example, and more.
> 
>  - Core API documentation.
> 
>  - Kernel development tools - the stuff I started pulling together into
>the dev-tools/ subdirectory.
> 
>  - How to deal with this unruly mob - SubmittingPatches, CodingStyle,
>development-process, etc.  There's process stuff, and general
>development documents like volatile-considered-harmful.txt or
>memory-barriers.txt

I would actually keep at the top-level directory only the build system 
main conf.py, makefiles & similar stuff), moving everything else to subdirs.

IMHO, there are a few advantages on that:

1) the Sphinx build system is oriented per subdir. We can't ask it to
   build just the stuff at the top dir without building the subdirs;

2) it makes easier to identify what was ported and what wasn't;

3) it makes things more organized, as the subdir will be an
   alias to the group of documents that will be part of the subdir.
> 
> We can go a long way by organizing this stuff within the formatted
> documentation, but I really think we need to organize the directory
> structure as well.  I see that as a slow-moving process that will take
> years, but I do think it's a direction we should go.

My suggestion is to create a directory structure for the
things that are currently under the top /Documentation dir
and at /Documentation/DocBook. Then, create an index.rst file for
each of them, initially with an "empty" content like:

TODO: add stuff here

And then move stuff there as we finish the conversion.

I actually did something like that for the stuff that used to be at
/Documentation/video4linux and Documentation/dvb and worked fine,
IMHO.

Ah, btw, on my experience, converting a .txt file into a .rst one
is a way easier than converting the DocBooks, as there's just one
place to touch, while on DocBooks, you'll also need to touch at
the included files, to fix format issues at the kernel-doc macros
that won't work anymore with ReST.

If you want, I may get some of those non-subsystem specific
documentation (like the documents describing the submission

[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled

[Daniel Vetter]

On Tue, Aug 23, 2016 at 12:26:44PM +0100, Chris Wilson wrote:
> On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote:
> > Legacy cursor updates are entirely asynchronous with respect to all
> > other users of the atomic pipeline. They neither wait for any
> > outstanding flips, nor do they cause subsequent flips to be delayed. The
> > only ordering we do require is given by making the legacy cursor update
> > nonblocking (so the sequence of userspace calls from a process is
> > ordered from the pov of the client).
> 
> Hmm, it is also not entirely true. A modeset (reconfiguration of the
> pipe size) would require all cursor updates to be flushed, or else we
> may make the cursor out-of-bounds which can cause GPU hangs. At the
> moment, I think that is governed by the crtc lock and the blocking
> nature of the modeset + cursor update. But in the future we want far
> more fine grained control over (mostly) asynchronous updates.

Yup, that's why I chickened out of fixing this properly ;-) What we could
do is set a flag that it's a modeset in drm_crtc_commit, and hand a flag
to stall_check to only look for modeset updates. Entirely elliding isn't a
good idea.

The other issue is how to order cursor updates through the legacy update
ioctl against atomic updates on the plane. Not that userspace should mix
those, but it could, and we need to make sure they're ordered properly.
This is especially painful when watermarks have changed, which is entirely
driver-dependent.

At that point it's probably time to ragequit.

Aside: i915 atomic commit is atm stalling way too much, it signals hw_done
too late. Iirc I've sprinkled a fixme into either the commit or code about
what needs to be done for that. Legacy cursor updates with hw_done
signalled early enough (i.e. when we wrote the register, before the hw has
committed the update) should fix this stalling issue too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RESEND PATCH v2 1/3] drm: dw_hdmi: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

Hello Russell,

On 08/18/2016 05:32 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 16, 2016 at 11:26:43PM +0300, Vladimir Zapolskiy wrote:
>> This change is needed to properly lock I2C bus driver, which serves
>> DDC.
>>
>> The change fixes an overflow over zero of I2C bus driver user counter:
>>
>>   root at imx6q:~# lsmod
>>   Not tainted
>>   dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000
>>   dw_hdmi_imx 3498 0 - Live 0xbf00d000
>>   dw_hdmi 16398 2 dw_hdmi_ahb_audio,dw_hdmi_imx, Live 0xbf004000
>>   i2c_imx 16687 0 - Live 0xbf017000
>>
>>   root at imx6q:~# rmmod dw_hdmi_imx
>>   root at imx6q:~# lsmod
>>   Not tainted
>>   dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000
>>   dw_hdmi 16398 1 dw_hdmi_ahb_audio, Live 0xbf004000
>>   i2c_imx 16687 -1 - Live 0xbf017000
>> ^^
>>
>>   root at imx6q:~# rmmod i2c_imx
>>   rmmod: ERROR: Module i2c_imx is in use
>>
>> Note that prior to this change put_device() coupled with
>> of_find_i2c_adapter_by_node() was missing on error path of
>> dw_hdmi_bind(), added i2c_put_adapter() there along with the change.
>
> I *guess* this is the right thing, but it would be nice to see the
> results with the patch applied in the commit description.  Nevertheless:
>
> Acked-by: Russell King 
>

thank you for review.

For information this is a result after applying the fix (+1 to i2c_imx users):

root at imx6q# lsmod
 Not tainted
dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000
i2c_imx 16687 1 - Live 0xbf011000
dw_hdmi_imx 3498 0 - Live 0xbf00d000
dw_hdmi 18925 2 dw_hdmi_ahb_audio,dw_hdmi_imx, Live 0xbf004000

root at imx6q:~# rmmod dw_hdmi_imx

root at imx6q:~# lsmod
 Not tainted
dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000
i2c_imx 16687 0 - Live 0xbf011000
dw_hdmi 18925 1 dw_hdmi_ahb_audio, Live 0xbf004000

No weird negative use count.

I have another pending change against DW HDMI, to avoid git-am conflicts
I'll rebase it on top of this one and resend today later on.

>
> I'd also like to see the DDC bits extracted from the various imx
> drivers, because this is surely common code - I've had this floating
> around for a few years but never got around to finishing it off and
> submitting it.  If folk think this is a good idea, and want to take
> the idea on, that's fine by me.
>
>  drivers/gpu/drm/Makefile|  2 +
>  drivers/gpu/drm/bridge/dw-hdmi.c| 98 
> +
>  drivers/gpu/drm/drm_ddc_connector.c | 91 ++
>  drivers/gpu/drm/imx/imx-tve.c   | 59 ++
>  include/drm/drm_ddc_connector.h | 33 +
>  5 files changed, 163 insertions(+), 120 deletions(-)

I've briefly reviewed the changes and in my opinion this is a good
to have generalization of DDC connector, hopefully DRM people agree.

Moreover I assume that in case of getting modes over I2C/DDC most of
the .get_modes callbacks share almost the same code sequence:

   drm_get_edid()
   drm_detect_hdmi_monitor()
   drm_mode_connector_update_edid_property()
   drm_add_edid_modes()
   drm_edid_to_eld()

I'm not absolutely sure, but probably this can be generalized as well.

--
With best wishes,
Vladimir

i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104

[Meelis Roos]

This on a P4 PC with 82865G chipset and onboard Intel graphics. 4.7.0 
worked fine, current 4.8 git shows NULL pointer dereference as shown 
below at the end of dmesg.

[0.00] Linux version 4.8.0-rc3-00013-gef0e1ea (mroos at vanalynx) (gcc 
version 5.4.0 20160609 (Debian 5.4.0-6) ) #34 Tue Aug 23 10:03:49 EEST 2016
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e6000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7ef2fbff] usable
[0.00] BIOS-e820: [mem 0x7ef2fc00-0x7ef2] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ef3-0x7ef3] ACPI data
[0.00] BIOS-e820: [mem 0x7ef4-0x7efe] ACPI NVS
[0.00] BIOS-e820: [mem 0x7eff-0x7eff] reserved
[0.00] BIOS-e820: [mem 0xfecf-0xfecf0fff] reserved
[0.00] BIOS-e820: [mem 0xfed2-0xfed9] reserved
[0.00] debug: ignoring loglevel setting.
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] SMBIOS 2.3 present.
[0.00] DMI: MicroLink   /D865GLC
, BIOS BF86510A.86A.0077.P25.0508040031 08/04/2005
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x7ef2f max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-E uncachable
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC  
[0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at 
[c00ff780]
[0.00] initial memory mapped: [mem 0x-0x01ff]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] BRK [0x01ad7000, 0x01ad7fff] PGTABLE
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F61E0 14 (v00 ACPIAM)
[0.00] ACPI: RSDT 0x7EF3 38 (v01 INTEL  D865GLC  
20050804 MSFT 0097)
[0.00] ACPI: FACP 0x7EF30200 81 (v02 INTEL  D865GLC  
20050804 MSFT 0097)
[0.00] ACPI: DSDT 0x7EF30370 004305 (v01 INTEL  D865GLC  
0001 MSFT 010D)
[0.00] ACPI: FACS 0x7EF4 40
[0.00] ACPI: APIC 0x7EF30300 68 (v01 INTEL  D865GLC  
20050804 MSFT 0097)
[0.00] ACPI: ASF! 0x7EF34680 99 (v16 LEGEND I865PASF 
0001 MSFT 010D)
[0.00] ACPI: TCPA 0x7EF34719 34 (v01 INTEL  TBLOEMID 
0001 MSFT 0097)
[0.00] ACPI: WDDT 0x7EF3474D 40 (v01 INTEL  OEMWDDT  
0001 MSFT 010D)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] 1143MB HIGHMEM available.
[0.00] 887MB LOWMEM available.
[0.00]   mapped low ram: 0 - 377fe000
[0.00]   low ram: 0 - 377fe000
[0.00] BRK [0x01ad8000, 0x01ad8fff] PGTABLE
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   Normal   [mem 0x0100-0x377fdfff]
[0.00]   HighMem  [mem 0x377fe000-0x7ef2efff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x7ef2efff]
[0.00] Initmem setup node 0 [mem 0x1000-0x7ef2efff]
[0.00] On node 0 totalpages: 519885
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3998 pages, LIFO batch:0
[0.00]   Normal zone: 1744 pages used for memmap
[0.00]   Normal zone: 223230 pages, LIFO batch:31
[0.00]   HighMem zone: 292657 pages, LIFO batch:31
[0.00] Using APIC driver default
[0.00] Reserving Intel graphics memory at 0x7f00-0x7fff
[0.00] ACPI: PM-Timer IO Port: 0x408
[0.00] ACPI: Local APIC address 0xfee0
[0.00] APIC: NR_CPUS/possible_cpus limit of 1 reached.  Processor 1/0x1 
ignored.
[

[PATCH 3/3] drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision

[Karl Beldan]

ATM the driver unconditionally advertises support for some 24bpp and
32bpp formats while version 1 of the IP only supports up to 16bpp.

Signed-off-by: Karl Beldan 
---
 drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c 
b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
index 41911e3..11285f6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
@@ -114,12 +114,17 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 int tilcdc_plane_init(struct drm_device *dev,
  struct drm_plane *plane)
 {
+   struct tilcdc_drm_private *priv = dev->dev_private;
+   unsigned int num_formats = ARRAY_SIZE(tilcdc_formats);
int ret;

+   if (priv->rev == 1)
+   num_formats = 1;
+
ret = drm_plane_init(dev, plane, 1,
 _plane_funcs,
 tilcdc_formats,
-ARRAY_SIZE(tilcdc_formats),
+num_formats,
 true);
if (ret) {
dev_err(dev->dev, "Failed to initialize plane: %d\n", ret);
-- 
2.9.2

[PATCH 2/3] drm/tilcdc: Enable EOF interrupts for v1 LCDC

[Karl Beldan]

This got accidentally dropped in the fixed commit and is required for
the driver to properly work on the rev1 IP, such as found on the LCDK.

Fixes: 2b2080d7e9ae ("drm/tilcdc: Get rid of complex ping-pong mechanism")
Signed-off-by: Karl Beldan 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 89d6916..163f111 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -98,6 +98,8 @@ static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
if (priv->rev == 1) {
tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
LCDC_V1_UNDERFLOW_INT_ENA);
+   tilcdc_set(dev, LCDC_DMA_CTRL_REG,
+   LCDC_V1_END_OF_FRAME_INT_ENA);
} else {
tilcdc_write(dev, LCDC_INT_ENABLE_SET_REG,
LCDC_V2_UNDERFLOW_INT_ENA |
-- 
2.9.2

[PATCH 1/3] drm/tilcdc: Adjust the FB_CEILING address

[Karl Beldan]

The LCDC seems to expect its framebuffer ceiling address pointer to be
an inclusive bound.  The IP rev2 seems to cope with that but rev1 (as
found on the LCDK) don't.
Also note that this is what the framebuffer code does in da8xx-fb.c.

Since, as the TRM puts it, "The 2 LSBs are hardwired to 00b", the
dma_addr_t can be decremented without cast.
I tested it with a v2 (AM335x, rev  0x4F201000) and an LCDK (v1).

Signed-off-by: Karl Beldan 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 25d6b22..89d6916 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -80,7 +80,7 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
end = start + (crtc->mode.vdisplay * fb->pitches[0]);

tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, start);
-   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end - 1);

if (tilcdc_crtc->curr_fb)
drm_flip_work_queue(_crtc->unref_work,
-- 
2.9.2

[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1

[Karl Beldan]

Hi,

I found some missing bits for rev1 of the LCDC and here are some of the
changes I am using to use the DRM driver on an LCDCK (which has a rev1).
1/3 seems required by rev1 of the IP and without it my the LCDC on my
LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3
is less of a requirement.
Although 1,2/3 would have fitted drm-fixes I based them on drm-next as
2/3 would conflict with the recent changes in drm-next.

Another thing which is also an absolute requirement for the rev1 but 
with which rev2 seems to cope fine is the palette loading (even if the DRM
uses >= 16bpp formats), dixit the TRM:
"12-, 16-, and 24-BPP modes do not need a palette; i.e., the pixel data is
the desired RGB value. However, the first 32 bytes are still considered a
palette. The first entry should be 4000h (bit 14 is 1) while the remaining
entries must be filled with 0.".
ATM I am using a local crude way of loading the palette to verify the
missing bits to get the DRM driver properly working on the LCDK (as I
haven't seen how things work in the DRM subsystem I can't post any proper
change for that).

The posted changes and the above mentioned palette loading missing bit 
are specific to the DRM driver.

However there are other shortcomings to the proper functioning of the 
LCDC on some platforms (I am currently focusing on the LCDK but I guess 
it should be true for all da850 based systems), which are not inherent to
the DRM driver driver but which strongly relate to it:

- The pixel clock rate setting (eg. currently the davinci clk can't cope
properly with the DRM driver way of setting the clock and doesn't use
the common clock framework)
- The memory bandwidth/latency requirements for the LCDC are not met 
with the default priority settings (apparently there is a fix in
da850_lcd_hw_init of: 
http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-omapl138-lcdk.c;h=689b4f304011e09e262782cf8c4b96eba00ac28b;hb=HEAD).
Of course this one affects both the DRM and framebuffer systems.

Hence to test the LCDK my crude local changes include (ie. on top of the
posted changes and some dts or sync_lost recovery bits):
- palette loading
- tweak of the pixel clock to cope with davinci clk
- adjustment of the memory master priorities


BTW, with the recent changes of tilcdc from drm-next, I see this warning
when loading the module:
"drm:drm_helper_disable_unused_functions [drm_kms_helper]] *ERROR* Called for 
atomic driver, this is not what you want."


Regards, 
Karl


Karl Beldan (3):
  drm/tilcdc: Adjust the FB_CEILING address
  drm/tilcdc: Enable EOF interrupts for v1 LCDC
  drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c  | 4 +++-
 drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++-
 2 files changed, 9 insertions(+), 2 deletions(-)

-- 
2.9.2

[PATCH] Re: Mullins support in xf86-video-amdgpu

[Michel Dänzer]

On 23/08/16 11:57 AM, Reid Hekman wrote:
> On 08/22/2016 08:27 PM, Michel Dänzer wrote:
>> On 23/08/16 10:18 AM, Reid Hekman wrote:
>>>
>>> I was encouraged by a commit I saw today to add Sea Islands PCI ids to
>>> xf86-video-amdgpu.  However I did not see MULLINS included. Are there
>>> other showstoppers preventing inclusion?
>>
>> I assume the commit you're referring to was the one adding the
>> *Southern* Islands (SI) PCI IDs. Since Mullins is Sea Islands (CIK), it
>> should already be supported by the amdgpu kernel driver; its omission
>> from xf86-video-amdgpu is probably just an oversight. Can you send a
>> patch to the amd-gfx mailing list?
>>
> 
> Michael, oops, yes, sorry, apparently my head was on the wrong AMD
> islands. Admittedly I'm a total newb at this, but David's script makes
> this seem fairly simple.  Does the following look correct?

It looks good, but it fails to apply for me for some reason. How did you
generate the patch?

Ideally, generate a patch (with a proper commit log) with git
format-patch and send it with git send-email.


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

[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled

[Chris Wilson]

On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote:
> Legacy cursor updates are entirely asynchronous with respect to all
> other users of the atomic pipeline. They neither wait for any
> outstanding flips, nor do they cause subsequent flips to be delayed. The
> only ordering we do require is given by making the legacy cursor update
> nonblocking (so the sequence of userspace calls from a process is
> ordered from the pov of the client).

Hmm, it is also not entirely true. A modeset (reconfiguration of the
pipe size) would require all cursor updates to be flushed, or else we
may make the cursor out-of-bounds which can cause GPU hangs. At the
moment, I think that is governed by the crtc lock and the blocking
nature of the modeset + cursor update. But in the future we want far
more fine grained control over (mostly) asynchronous updates.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[GIT PULL] drm/rockchip: Support rk3399/PSR + fixes

[Sean Paul]

Hi Dave,
This pull request contains the following rockchip drm changes:

  - Introduce support for rk3399 vop/crtc
  - Add PSR framework to the rockchip driver
  - Implement PSR in the rockchip analogix edp driver
  - Fix panel on/off in analogix to avoid damaging panels
  - Some miscellaneous fixes to clean up logs and code readability

Sean


The following changes since commit fc93ff608b15ae32cde3006b7af860b59cac20ec:

  Merge tag 'drm-intel-next-2016-08-08' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-08-15 16:53:57 
+1000)

are available in the git repository at:

  ssh://people.freedesktop.org/~seanpaul/dogwood for-next

for you to fetch changes up to 808263393198b9b0f9d53b9983330fb4298851ec:

  drm/rockchip: analogix_dp: drop unnecessary probe deferral "error" print 
(2016-08-23 11:44:37 -0400)


Brian Norris (1):
  drm/rockchip: analogix_dp: drop unnecessary probe deferral "error" print

Mark Yao (5):
  drm/rockchip: sort registers define by chip's number
  drm/rockchip: vop: introduce VOP_REG_MASK
  drm/rockchip: vop: add rk3399 vop support
  dt-bindings: sort Rockchip vop compatible by chip's number
  dt-bindings: add compatible strings for big/little rockchip vops

Sean Paul (7):
  drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared
  drm/rockchip: Convert psr_list_mutex to spinlock and use it
  drm/rockchip: Don't use a delayed worker for psr state changes
  drm/rockchip: Use a spinlock to protect psr state
  drm/rockchip: A couple small fixes to psr
  drm/rockchip: Improve analogix-dp psr handling
  drm/rockchip: Enable vblank without event

Yakir Yang (4):
  drm/rockchip: vop: export line flag function
  drm/rockchip: add an common abstracted PSR driver
  drm/bridge: analogix_dp: add the PSR function support
  drm/rockchip: analogix_dp: implement PSR function

 .../bindings/display/rockchip/rockchip-vop.txt |   4 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 182 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  51 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |  34 +++
 drivers/gpu/drm/rockchip/Makefile  |   2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  70 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   6 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  12 +
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 245 +
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  26 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 198 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   7 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 242 ++--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 193 
 include/drm/bridge/analogix_dp.h   |   3 +
 17 files changed, 1168 insertions(+), 118 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

[PATCH v13 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

[Maarten Lankhorst]

Op 22-08-16 om 18:50 schreef Lyude:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
Applied, thanks.

Can you resend 6/7 and 7/7?

[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler

[Lucas Stach]

Hi Christian,

Am Dienstag, den 23.08.2016, 11:58 +0200 schrieb Christian Gmeiner:
> 2016-08-22 13:01 GMT+02:00 Lucas Stach :
> > Bit 30 of the interrupt status signals an MMU exception. Handle this
> > condition properly and dump some useful registers.
> >
> > Signed-off-by: Lucas Stach 
> > ---
[...]
> >
> >
> > @@ -78,9 +78,10 @@ Copyright (C) 2015
> >  #define VIVS_HI_AXI_STATUS_DET_RD_ERR  0x0200
> >
> >  #define VIVS_HI_INTR_ACKNOWLEDGE   0x0010
> > -#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> > 0x7fff
> > +#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> > 0x3fff
> >  #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT   0
> >  #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC(x)   (((x) << 
> > VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT) & 
> > VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK)
> > +#define VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION 0x4000
> >  #define VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR 0x8000
> >
> >  #define VIVS_HI_INTR_ENBL  0x0014
> 
> Where can I find the rnndb patch? Just share it and I will take care
> that it gets integrated.
> 
Sorry about that. It's still on my machine at home. Will post it in the
evening.

Regards,
Lucas

[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler

[Christian Gmeiner]

2016-08-22 13:01 GMT+02:00 Lucas Stach :
> Bit 30 of the interrupt status signals an MMU exception. Handle this
> condition properly and dump some useful registers.
>
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 12 
>  drivers/gpu/drm/etnaviv/state_hi.xml.h |  9 +
>  2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 4c706438c7c8..923f6c78e1af 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1402,6 +1402,18 @@ static irqreturn_t irq_handler(int irq, void *data)
> intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR;
> }
>
> +   if (intr & VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION) {
> +   int i;
> +
> +   dev_err(gpu->dev, "MMU fault status 0x%08x\n",
> +   gpu_read(gpu, VIVS_MMUv2_STATUS));
> +   for (i = 0; i < 4; i++)
> +   dev_err(gpu->dev, "MMU %d fault addr 
> 0x%08x\n",
> +   i, gpu_read(gpu,
> +   VIVS_MMUv2_EXCEPTION_ADDR(i)));
> +   intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION;
> +   }
> +
> while ((event = ffs(intr)) != 0) {
> struct fence *fence;
>
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h 
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 807a3d9e0dd5..43c73e2ed34f 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,10 +8,10 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
>  git clone git://0x04.net/rules-ng-ng
>
>  The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml (  24309 bytes, from 2015-12-12 09:02:53)
> -- common.xml   (  18437 bytes, from 2015-12-12 09:02:53)
> +- state_hi.xml (  25620 bytes, from 2016-08-19 22:07:37)
> +- common.xml   (  20583 bytes, from 2016-06-07 05:22:38)
>
> -Copyright (C) 2015
> +Copyright (C) 2016
>  */
>
>
> @@ -78,9 +78,10 @@ Copyright (C) 2015
>  #define VIVS_HI_AXI_STATUS_DET_RD_ERR  0x0200
>
>  #define VIVS_HI_INTR_ACKNOWLEDGE   0x0010
> -#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> 0x7fff
> +#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> 0x3fff
>  #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT   0
>  #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC(x)   (((x) << 
> VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT) & 
> VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK)
> +#define VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION 0x4000
>  #define VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR 0x8000
>
>  #define VIVS_HI_INTR_ENBL  0x0014

Where can I find the rnndb patch? Just share it and I will take care
that it gets integrated.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled

[Chris Wilson]

On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote:
> Legacy cursor updates are entirely asynchronous with respect to all
> other users of the atomic pipeline. They neither wait for any
> outstanding flips, nor do they cause subsequent flips to be delayed. The
> only ordering we do require is given by making the legacy cursor update
> nonblocking (so the sequence of userspace calls from a process is

s/nonblocking/blocking/!

> ordered from the pov of the client).

-- 
Chris Wilson, Intel Open Source Technology Centre

linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

After merging the drm-intel tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from drivers/gpio/gpiolib-of.c:19:0:
include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such 
file or directory
In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:16:0,
 from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,   
 from drivers/gpu/drm/nouveau/include/nvkm/core/client.h:3,   
 from drivers/gpu/drm/nouveau/nvkm/core/client.c:24:
include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such 
file or directory

and many more.

Caused by commit

  cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the 
io-mapping")

I have used the drm-intel tree from next-20160822 for today.

-- 
Cheers,
Stephen Rothwell

[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled

[Chris Wilson]

Legacy cursor updates are entirely asynchronous with respect to all
other users of the atomic pipeline. They neither wait for any
outstanding flips, nor do they cause subsequent flips to be delayed. The
only ordering we do require is given by making the legacy cursor update
nonblocking (so the sequence of userspace calls from a process is
ordered from the pov of the client).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9abe0a242f96..9441fb9d9637 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1422,9 +1422,11 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,

state->crtcs[i].commit = commit;

-   ret = stall_checks(crtc, nonblock);
-   if (ret)
-   return ret;
+   if (!state->legacy_cursor_update) {
+   ret = stall_checks(crtc, nonblock);
+   if (ret)
+   return ret;
+   }

/* Drivers only send out events when at least either current or
 * new CRTC state is active. Complete right away if everything
@@ -1989,7 +1991,7 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
swap(state->crtcs[i].state, crtc->state);
crtc->state->state = NULL;

-   if (state->crtcs[i].commit) {
+   if (state->crtcs[i].commit && !state->legacy_cursor_update) {
spin_lock(>commit_lock);
list_add(>crtcs[i].commit->commit_entry,
 >commit_list);
-- 
2.9.3

[PATCH v2] drm/rockchip: Don't continue trying to enable crtc on failure

[Sean Paul]

On Wed, Aug 17, 2016 at 3:28 AM, Yakir Yang  wrote:
> Sean,
>
> On 08/16/2016 07:12 AM, Sean Paul wrote:
>>
>> If vop_enable fails, don't continue on, it causes system hangs.
>>
>> Signed-off-by: Sean Paul 
>
>
> Also meet this problem on my Rk3399 Kevin board. VOP just failed to get the
> pm_runtime at resume time, but ｄｒｉｖer still just continue without 
> anything
> enable rightly, oops, and then system crashed :(
>
> So this patch looks good to me, and also fix my problem, thanks:
>
> Ｒｅviewed-by: Yakir Yang 
> Tested-by: Yakir Yang 
>

Applied to -misc

Sean

> Thanks,
> - Yakir
>
>> ---
>>
>> This patch uses the new DRM_DEV_ERROR logging, so it should be applied on
>> top of "[PATCH 2/2] drm/rockchip: Use DRM_DEV_ERROR in vop".
>>
>> Changes in v2:
>> - Escalate dev_err to WARN_ON for clk_enable failures (Daniel
>> Vetter)
>>
>> Sean
>>
>>
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31
>> -
>>   1 file changed, 17 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index ec8ad00..a176d03 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -428,7 +428,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
>> *vop)
>> spin_unlock_irqrestore(>irq_lock, flags);
>>   }
>>   -static void vop_enable(struct drm_crtc *crtc)
>> +static int vop_enable(struct drm_crtc *crtc)
>>   {
>> struct vop *vop = to_vop(crtc);
>> int ret;
>> @@ -436,26 +436,20 @@ static void vop_enable(struct drm_crtc *crtc)
>> ret = pm_runtime_get_sync(vop->dev);
>> if (ret < 0) {
>> dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
>> -   return;
>> +   goto err_put_pm_runtime;
>> }
>> ret = clk_enable(vop->hclk);
>> -   if (ret < 0) {
>> -   dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
>> -   return;
>> -   }
>> +   if (WARN_ON(ret < 0))
>> +   goto err_put_pm_runtime;
>> ret = clk_enable(vop->dclk);
>> -   if (ret < 0) {
>> -   dev_err(vop->dev, "failed to enable dclk - %d\n", ret);
>> +   if (WARN_ON(ret < 0))
>> goto err_disable_hclk;
>> -   }
>> ret = clk_enable(vop->aclk);
>> -   if (ret < 0) {
>> -   dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
>> +   if (WARN_ON(ret < 0))
>> goto err_disable_dclk;
>> -   }
>> /*
>>  * Slave iommu shares power, irq and clock with vop.  It was
>> associated
>> @@ -485,7 +479,7 @@ static void vop_enable(struct drm_crtc *crtc)
>> drm_crtc_vblank_on(crtc);
>>   - return;
>> +   return 0;
>> err_disable_aclk:
>> clk_disable(vop->aclk);
>> @@ -493,6 +487,9 @@ err_disable_dclk:
>> clk_disable(vop->dclk);
>>   err_disable_hclk:
>> clk_disable(vop->hclk);
>> +err_put_pm_runtime:
>> +   pm_runtime_put_sync(vop->dev);
>> +   return ret;
>>   }
>> static void vop_crtc_disable(struct drm_crtc *crtc)
>> @@ -912,10 +909,16 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
>> u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
>> u16 vact_end = vact_st + vdisplay;
>> uint32_t val;
>> +   int ret;
>> WARN_ON(vop->event);
>>   - vop_enable(crtc);
>> +   ret = vop_enable(crtc);
>> +   if (ret) {
>> +   DRM_DEV_ERROR(vop->dev, "Failed to enable vop (%d)\n",
>> ret);
>> +   return;
>> +   }
>> +
>> /*
>>  * If dclk rate is zero, mean that scanout is stop,
>>  * we don't need wait any more.
>
>
>

[PATCH] drm/rockchip: Delete unnecessary assignment for the field "owner"

[Sean Paul]

On Tue, Aug 16, 2016 at 8:43 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 16 Aug 2016 14:25:35 +0200
>
> The field "owner" is set by the core.
> Thus delete an unneeded initialisation.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> Signed-off-by: Markus Elfring 


Applied to -misc

Sean


> ---
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 -
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 89aadbf..0e63ee2 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -445,7 +445,6 @@ static struct platform_driver rockchip_dp_driver = {
> .remove = rockchip_dp_remove,
> .driver = {
>.name = "rockchip-dp",
> -  .owner = THIS_MODULE,
>.pm = _dp_pm_ops,
>.of_match_table = of_match_ptr(rockchip_dp_dt_ids),
> },
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 919992c..b7f59c4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -305,7 +305,6 @@ static struct platform_driver vop_platform_driver = {
> .remove = vop_remove,
> .driver = {
> .name = "rockchip-vop",
> -   .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(vop_driver_dt_match),
> },
>  };
> --
> 2.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: dw-hdmi: Delete unnecessary assignment for the field "owner"

[Sean Paul]

On Tue, Aug 16, 2016 at 7:58 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 16 Aug 2016 13:52:19 +0200
>
> The field "owner" is set by the core.
> Thus delete an unneeded initialisation.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> Signed-off-by: Markus Elfring 


Applied to -misc

Sean


> ---
>  drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c 
> b/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> index 122bb01..8f2d137 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> @@ -640,7 +640,6 @@ static struct platform_driver snd_dw_hdmi_driver = {
> .remove = snd_dw_hdmi_remove,
> .driver = {
> .name = DRIVER_NAME,
> -   .owner = THIS_MODULE,
> .pm = PM_OPS,
> },
>  };
> --
> 2.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: ipu-v3: fix a possible NULL dereference

[Sean Paul]

On Tue, Aug 16, 2016 at 9:33 AM, LABBE Corentin
 wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later.
>
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
>
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/gpu/ipu-v3/ipu-common.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 99dcacf..05a9cc6 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -1207,15 +1207,13 @@ EXPORT_SYMBOL_GPL(ipu_dump);
>
>  static int ipu_probe(struct platform_device *pdev)
>  {
> -   const struct of_device_id *of_id =
> -   of_match_device(imx_ipu_dt_ids, >dev);
> struct ipu_soc *ipu;
> struct resource *res;
> unsigned long ipu_base;
> int i, ret, irq_sync, irq_err;
> const struct ipu_devtype *devtype;
>
> -   devtype = of_id->data;
> +   devtype = of_device_get_match_data(>dev);

While you avoid the of_id dereference, it's possible that
of_device_get_match_data() returns NULL, so you're really just moving
the oops around.

Sean

>
> irq_sync = platform_get_irq(pdev, 0);
> irq_err = platform_get_irq(pdev, 1);
> --
> 2.7.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Markus Heiser]

Am 23.08.2016 um 08:01 schrieb Daniel Vetter :

> On Mon, Aug 22, 2016 at 12:49:30PM -0300, Mauro Carvalho Chehab wrote:
>> Em Mon, 22 Aug 2016 20:41:45 +0530
>> Sumit Semwal  escreveu:
>> 
>>> Include dma-buf sphinx documentation into top level index.
>>> 
>>> Signed-off-by: Sumit Semwal 
>>> ---
>>> Documentation/index.rst | 2 ++
>>> 1 file changed, 2 insertions(+)
>>> 
>>> diff --git a/Documentation/index.rst b/Documentation/index.rst
>>> index e0fc72963e87..8d05070122c2 100644
>>> --- a/Documentation/index.rst
>>> +++ b/Documentation/index.rst
>>> @@ -14,6 +14,8 @@ Contents:
>>>:maxdepth: 2
>>> 
>>>kernel-documentation
>>> +   dma-buf/intro
>>> +   dma-buf/guide
>>>media/media_uapi
>>>media/media_kapi
>>>media/dvb-drivers/index
>> 
>> IMHO, the best would be, instead, to add an index with a toctree
>> with both intro and guide, and add dma-buf/index instead.
>> 
>> We did that for media too (patches not merged upstream yet), together
>> with a patchset that will allow building just a subset of the books.

Since 606b9ac, one more *pro* of a index.rst file in a sub-folder is,
that you can reduce your roundtrips. Add a conf.py to your subfolder
and compile only your sub-folder with e.g.

  make SPHINXDIRS="dma-buf" htmldocs

* 
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=606b9ac81a63ab3adb7e61206b9ae34ee186a89d

One / the example (Mauro mentioned) is media commit b32feba

* 
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=b32febad77068b4a28daf7b7e063438d0cca8a42

> I'm also not too sure about whether dma-buf really should be it's own
> subdirectory. It's plucked from the device-drivers.tmpl, I think an
> overall device-drivers/ for all the misc subsystems and support code would
> be better.

If the sub-folder named 'device-drivers' use:

  make SPHINXDIRS="device-drivers" htmldocs

-- Markus --


> Then one toc there, which fans out to either kernel-doc and
> overview docs.
> -Daniel
> 
>> 
>> Regards,
>> Mauro
>> 
>> PS.: That's the content of our index.rst file, at
>> Documentation/media/index.rst:
>> 
>> Linux Media Subsystem Documentation
>> ===
>> 
>> Contents:
>> 
>> .. toctree::
>>   :maxdepth: 2
>> 
>>   media_uapi
>>   media_kapi
>>   dvb-drivers/index
>>   v4l-drivers/index
>> 
>> .. only::  subproject
>> 
>>   Indices
>>   ===
>> 
>>   * :ref:`genindex`
>> 
>> 
>> Thanks,
>> Mauro
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[PATCH] drm/doc: Add a few words on validation with IGT

[Tomeu Vizoso]

Also provide some pointers for building IGT as some kernel hackers might
not be that familiar with building stuff on Linux distros.

Signed-off-by: Tomeu Vizoso 
Cc: Daniel Vetter 
---
 Documentation/gpu/drm-uapi.rst | 37 +
 1 file changed, 37 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 94876938aef3..5e425ab83dc1 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -112,3 +112,40 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Validating changes with IGT
+===
+
+There's a collection of tests that aims to cover the whole functionality of
+DRM drivers and that can be used to check that changes to DRM drivers or the
+core don't regress existing functionality. This test suite is called IGT and
+its code can be found in https://cgit.freedesktop.org/xorg/app/intel-gpu-tools.
+
+To build IGT, start by installing its build dependencies. In Debian-based
+systems::
+
+   # apt-get build-dep intel-gpu-tools
+
+And in Fedora-based systems::
+
+   # dnf builddep intel-gpu-tools
+
+Then clone the repository::
+
+   $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
+
+Configure the build system and start the build::
+
+   $ cd intel-gpu-tools && ./autogen.sh && make -j6
+
+Download the piglit dependency::
+
+   $ ./scripts/run-tests.sh -d
+
+And run the tests::
+
+   $ ./scripts/run-tests.sh -t kms -t core -s
+
+run-tests.sh is a wrapper around piglit that will execute the tests matching
+the -t options. A report in HTML format will be available in
+./results/html/index.html. Results can be compared with piglit.
-- 
2.7.4

i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104

[Chris Wilson]

On Tue, Aug 23, 2016 at 02:35:03PM +0300, Meelis Roos wrote:
> > Looks like an incorrect call to drm_encoder_cleanup() from the error
> > path. If we hit the error path we have never called drm_encoder_init.
> > Please try:
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> > b/drivers/gpu/drm/i915/intel_dvo.c
> > index 47bdf9dad0d3..b9e5a63a7c9e 100644
> > --- a/drivers/gpu/drm/i915/intel_dvo.c
> > +++ b/drivers/gpu/drm/i915/intel_dvo.c
> > @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev)
> > return;
> > }
> >  
> > -   drm_encoder_cleanup(_encoder->base);
> > kfree(intel_dvo);
> > kfree(intel_connector);
> >  }
> 
> It works - the BUG is gone.
> 
> Now I get just 
> [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun

Other than the annoying underrun, is everything else as expected? i.e.
no connected outputs? Have we lost dvo detection?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[RFC 0/2] New feature: Framebuffer processors

[Daniel Stone]

Hi,

On 22 August 2016 at 16:23, Rob Clark  wrote:
> I guess a lot comes down to 'how long before hw designers bolt a CP to
> the thing'..  at that point, I think you especially don't want a
> per-blit kernel interface.

Regardless of whether or not we want it, we already _have_ it, in the
form of V4L2 M2M. There are already a few IP blocks working on that, I
believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
anyway ...

Cheers,
Daniel

Mullins support in xf86-video-amdgpu

[Michel Dänzer]

On 23/08/16 10:18 AM, Reid Hekman wrote:
> 
> I was encouraged by a commit I saw today to add Sea Islands PCI ids to
> xf86-video-amdgpu.  However I did not see MULLINS included. Are there
> other showstoppers preventing inclusion?

I assume the commit you're referring to was the one adding the
*Southern* Islands (SI) PCI IDs. Since Mullins is Sea Islands (CIK), it
should already be supported by the amdgpu kernel driver; its omission
from xf86-video-amdgpu is probably just an oversight. Can you send a
patch to the amd-gfx mailing list?


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

[PATCH] drm/fsl-dcu: Fix endian issue when using clk_register_divider

[Meng Yi]

> >>fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
> >>pix_clk_in_name, 0, base + DCU_DIV_RATIO,
> >> -  0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> >> +  24, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> >
> > Tested-by: Meng Yi 
> >
> > On LS1021A-TWR board.
> 
> Yeah I wanted to give this a try on Vybrid, but I don't think that works 
> since on
> Vybrid the IP is little endian...
> 
> We need to come up with a solution which takes that into account.
> Alternatively we can put the offset into the SoC specific structure...
> 
Ok, I will do this these days.

Best Regards,
Meng

[PATCH] drm-misc: arm64 now also must be compile-tested before pushing

[Daniel Vetter]

hisilicon unfortunately requires this since it's a warn-fest on 32bit
builds.

Cc: seanpaul at chromium.org
Cc: sumit.semwal at linaro.org
Cc: sumit.semwal at linaro.org
Cc: architt at codeaurora.org
Signed-off-by: Daniel Vetter 
---
 drm-misc.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drm-misc.rst b/drm-misc.rst
index 521be4aceceb..2f30e18d9095 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -26,8 +26,8 @@ Right now the only hard merge criteria are:
   in through separate pull requests. Those topic branches can still be
   maintained with the dim_ tooling, but that's of course entirely optional.

-* All the x86 and arm DRM drivers need to still compile. To simplify this we
-  track defconfigs for both platforms in the `drm-intel-rerere` branch.
+* All the x86, arm and arm64 DRM drivers need to still compile. To simplify 
this
+  we track defconfigs for all three platforms in the `drm-intel-rerere` branch.

 * The goal is to also pre-check everything with CI. Unfortunately neither the
   arm side (using kernelci.org and generic i-g-t tests) nor the Intel side
-- 
2.9.3

[RESEND PATCH v13 7/7] drm/i915/skl: Update DDB values atomically with wms/plane attrs

[Lyude]

Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Changes since v1:
 - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
 - Use the method for updating CRTCs that Ville suggested
 - In skl_update_wm(), only copy the watermarks for the crtc that was
   passed to us
Changes since v3:
 - Small comment fix in skl_ddb_allocation_overlaps()
Changes since v4:
 - Remove the second loop in intel_update_crtcs() and use Ville's
   suggestion for updating the ddb allocations in the right order
 - Get rid of the second loop and just use the ddb state as it updates
   to determine what order to update everything in (thanks for the
   suggestion Ville)
 - Simplify skl_ddb_allocation_overlaps()
 - Split actual overlap checking into it's own helper

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]

Testcase: kms_cursor_legacy
Testcase: plane-all-modeset-transition
Signed-off-by: Lyude 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c |  93 +---
 drivers/gpu/drm/i915/intel_drv.h |   7 ++
 drivers/gpu/drm/i915/intel_pm.c  | 200 ---
 3 files changed, 132 insertions(+), 168 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 330df69..f9273f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13483,16 +13483,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
  hw_entry->start, hw_entry->end);
}

-   /* cursor */
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
-
-   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+   if (intel_crtc->cursor_addr) {
+   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
+   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
+
+   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+   }
}
 }

@@ -14244,6 +14251,65 @@ static void intel_update_crtcs(struct drm_atomic_state 
*state,
}
 }

+static void skl_update_crtcs(struct drm_atomic_state *state,
+

[RESEND PATCH v13 6/7] drm/i915: Move CRTC updating in atomic_commit into it's own hook

[Lyude]

Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.

Based off of Matt Rope's suggestions

Changes since v1:
 - Drop pipe_config->base.active check in intel_update_crtcs() since we
   check that before calling the function

Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/intel_display.c | 74 +---
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff96b7a..04b4fd6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -514,6 +514,8 @@ struct drm_i915_display_funcs {
struct drm_atomic_state *old_state);
void (*crtc_disable)(struct intel_crtc_state *old_crtc_state,
 struct drm_atomic_state *old_state);
+   void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b10bea6..330df69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14198,6 +14198,52 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return false;
 }

+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+   bool modeset = needs_modeset(crtc->state);
+
+   if (modeset) {
+   update_scanline_offset(intel_crtc);
+   dev_priv->display.crtc_enable(pipe_config, state);
+   } else {
+   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+   }
+
+   if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+   intel_fbc_enable(
+   intel_crtc, pipe_config,
+   to_intel_plane_state(crtc->primary->state));
+   }
+
+   drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+   if (needs_vblank_wait(pipe_config))
+   *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+  unsigned int *crtc_vblank_mask)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *old_crtc_state;
+   int i;
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+   if (!crtc->state->active)
+   continue;
+
+   intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+   }
+}
+
 static void intel_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
@@ -14296,17 +14342,9 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}

-   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+   /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->state);
-
-   if (modeset && crtc->state->active) {
-   update_scanline_offset(to_intel_crtc(crtc));
-   dev_priv->display.crtc_enable(pipe_config, state);
-   }

/* Complete events for now disable pipes here. */
if (modeset && !crtc->state->active && crtc->state->event) {
@@ -14316,21 +14354,11 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)

  

i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104

[Chris Wilson]

On Tue, Aug 23, 2016 at 12:58:43PM +0300, Meelis Roos wrote:
> This on a P4 PC with 82865G chipset and onboard Intel graphics. 4.7.0 
> worked fine, current 4.8 git shows NULL pointer dereference as shown 
> below at the end of dmesg.
> 
> [   10.066261] BUG: unable to handle kernel NULL pointer dereference at 
> 0104
> [   10.066273] IP: [] mutex_lock+0xa/0x15
> [   10.066287] *pde =  
> [   10.066295] Oops: 0002 [#1]
> [   10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper 
> syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt 
> iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse 
> snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd 
> serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100 mii 
> floppy parport_pc parport acpi_cpufreq button processor usb_common eeprom 
> lm85 hwmon_vid autofs4
> [   10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted 
> 4.8.0-rc3-00013-gef0e1ea #34
> [   10.066389] Hardware name: MicroLink   
> /D865GLC, BIOS BF86510A.86A.0077.P25.0508040031 
> 08/04/2005
> [   10.066401] task: f62db800 task.stack: f597
> [   10.066409] EIP: 0060:[] EFLAGS: 00010286 CPU: 0
> [   10.066417] EIP is at mutex_lock+0xa/0x15
> [   10.066424] EAX: 0104 EBX: 0104 ECX:  EDX: 8000
> [   10.066432] ESI:  EDI: 0104 EBP: f5be8000 ESP: f5971b58
> [   10.066439]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
> [   10.066446] CR0: 80050033 CR2: 0104 CR3: 35945000 CR4: 06d0
> [   10.066453] Stack:
> [   10.066459]  f503d740 f824dddf  f61170c0 f61170c0 f82371ae 
> f850f40e 0001
> [   10.066476]  f61170c0 f5971bcc f5be8000 f9c2d401 0001 f8236fcc 
> 0001 
> [   10.066491]  f5144014 f5be8104 0008 f9c5267c 0007 f61170c0 
> f5144400 f9c4ff00
> [   10.066507] Call Trace:
> [   10.066526]  [] ? drm_modeset_lock_all+0x27/0xb3 [drm]
> [   10.066545]  [] ? drm_encoder_cleanup+0x1a/0x132 [drm]
> [   10.066559]  [] ? drm_atomic_helper_connector_reset+0x3f/0x5c 
> [drm_kms_helper]
> [   10.066644]  [] ? intel_dvo_init+0x569/0x788 [i915]

Looks like an incorrect call to drm_encoder_cleanup() from the error
path. If we hit the error path we have never called drm_encoder_init.
Please try:

diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 47bdf9dad0d3..b9e5a63a7c9e 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev)
return;
}

-   drm_encoder_cleanup(_encoder->base);
kfree(intel_dvo);
kfree(intel_connector);
 }

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

[Hans Verkuil]

On 08/23/16 09:59, Russell King - ARM Linux wrote:
> On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
>> Hi Russell,
>>
>> On 08/12/2016 04:15 PM, Russell King wrote:
>>> Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
>>> implementation.
>>>
>>> Signed-off-by: Russell King 
>>> ---
>>>  drivers/gpu/drm/bridge/Kconfig|   7 +
>>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>>  drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 344 
>>> ++
>>>  drivers/gpu/drm/bridge/dw-hdmi.c  |  64 +-
>>>  include/linux/platform_data/dw_hdmi-cec.h |  16 ++
>>>  5 files changed, 421 insertions(+), 11 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
>>>  create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
>>>
>>
>> 
>>
>>> +static unsigned int parse_hdmi_addr(const struct edid *edid)
>>> +{
>>> +   if (!edid || edid->extensions == 0)
>>> +   return (u16)~0;
>>> +
>>> +   return cec_get_edid_phys_addr((u8 *)edid,
>>> +   EDID_LENGTH * (edid->extensions + 1), NULL);
>>> +}
>>> +
>>> +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long 
>>> event,
>>> + void *data)
>>> +{
>>> +   struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
>>> +   union hdmi_event *event_block = data;
>>> +   unsigned int phys;
>>> +
>>> +   dev_info(event_block->base.source, "event %lu\n", event);
>>> +
>>> +   if (event_block->base.source != cec->adap->devnode.parent)
>>> +   return NOTIFY_OK;
>>> +
>>> +   switch (event) {
>>> +   case HDMI_CONNECTED:
>>> +   break;
>>> +
>>> +   case HDMI_DISCONNECTED:
>>> +   cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
>>> +   break;
>>> +
>>> +   case HDMI_NEW_EDID:
>>> +   phys = parse_hdmi_addr(event_block->edid.edid);
>>> +   cec_s_phys_addr(cec->adap, phys, false);
>>> +   break;
>>> +   }
>>> +
>>> +   return NOTIFY_OK;
>>> +}
>>
>> Wouldn't it make a lot of sense to integrate this into the cec framework?
>>
>> All you need is to pass an hdmi_notifier_dev as argument to 
>> cec_allocate_adapter()
>> and you can integrate this.
>>
>> If you are OK with that, then I can make patches for that.
> 
> It's not just about CEC.  It's also used for passing information between
> the video and audio parts, so tying this into CEC is wrong.

I'm not saying that the hdmi notifier should be integrated, just that the
CEC core can register itself as a notifier and handle cec_s_phys_addr.

Regards,

Hans

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

[Hans Verkuil]

Hi Russell,

On 08/12/16 16:15, Russell King wrote:
> + ret = devm_request_threaded_irq(>dev, cec->irq,
> + dw_hdmi_cec_hardirq,
> + dw_hdmi_cec_thread, IRQF_SHARED,
> + DEV_NAME, cec->adap);
> + if (ret < 0)
> + return ret;
> +
> + ret = cec_register_adapter(cec->adap);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * CEC documentation says we must not call cec_delete_adapter
> +  * after a successful call to cec_register_adapter().
> +  */
> + devm_remove_action(>dev, dw_hdmi_cec_del, cec);
> +
> + hdmi_register_notifier(>nb);

The notifier is registered here, but who provides CEC with the initial
physical address? As I understand it, it only tells you when things change,
not what the initial state is.

Regards,

Hans

[PATCH] drm-misc: Rename drm-misc defconfigs to end with _defconfig

[Sean Paul]

Instead of -defconfig, to be consistent with in-tree naming
convention

Cc: daniel.vetter at intel.com
Cc: sumit.semwal at linaro.org
Cc: architt at codeaurora.org
Signed-off-by: Sean Paul 
---
 drm-misc-arm64-defconfig => drm-misc-arm64_defconfig | 0
 drm-misc-arm-defconfig => drm-misc-arm_defconfig | 0
 drm-misc-x86-defconfig => drm-misc-x86_defconfig | 0
 3 files changed, 0 insertions(+), 0 deletions(-)
 rename drm-misc-arm64-defconfig => drm-misc-arm64_defconfig (100%)
 rename drm-misc-arm-defconfig => drm-misc-arm_defconfig (100%)
 rename drm-misc-x86-defconfig => drm-misc-x86_defconfig (100%)

diff --git a/drm-misc-arm64-defconfig b/drm-misc-arm64_defconfig
similarity index 100%
rename from drm-misc-arm64-defconfig
rename to drm-misc-arm64_defconfig
diff --git a/drm-misc-arm-defconfig b/drm-misc-arm_defconfig
similarity index 100%
rename from drm-misc-arm-defconfig
rename to drm-misc-arm_defconfig
diff --git a/drm-misc-x86-defconfig b/drm-misc-x86_defconfig
similarity index 100%
rename from drm-misc-x86-defconfig
rename to drm-misc-x86_defconfig
-- 
2.8.0.rc3.226.g39d4020

[urgent] drm/fb-helper: Fix the dummy remove_conflicting_framebuffers

[Daniel Vetter]

On Mon, Aug 22, 2016 at 09:44:52PM +0100, Chris Wilson wrote:
> We always need to remove conflicting framebuffers if any other fb driver
> is enabled, and not just if we are setting up an fbdev ourselves.
> 
> Unfortunately remove_conflicting_framebuffers() was incorrectly stubbed
> out if !fbdev rather than !fb leading to major memory corruption (and
> corrupt filesystems) upon boot.
> 
> Fixes: 44adece57e26 ("drm/fb-helper: Add a dummy 
> remove_conflicting_framebuffers")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Tobias Jakobi 
> Cc: Noralf Trønnes 
> Cc: tomi.valkeinen at ti.com
> Cc: dh.herrmann at gmail.com
> Cc: Alex Deucher 

It's only in -misc, so not super urgent. Applied, thanks.
-Daniel

> ---
>  include/drm/drm_fb_helper.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 97889a90ff23..f811d755c254 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -282,12 +282,6 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector 
> *fb_helper_conn,
>  int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
> drm_connector *connector);
>  int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
>  struct drm_connector *connector);
> -static inline int
> -drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> -   const char *name, bool primary)
> -{
> - return remove_conflicting_framebuffers(a, name, primary);
> -}
>  #else
>  static inline int drm_fb_helper_modinit(void)
>  {
> @@ -482,11 +476,17 @@ drm_fb_helper_remove_one_connector(struct drm_fb_helper 
> *fb_helper,
>   return 0;
>  }
>  
> +#endif
> +
>  static inline int
>  drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary)
>  {
> +#if IS_ENABLED(CONFIG_FB)
> + return remove_conflicting_framebuffers(a, name, primary);
> +#else
>   return 0;
> -}
>  #endif
> +}
> +
>  #endif
> -- 
> 2.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

[Hans Verkuil]

Hi Russell,

On 08/12/2016 04:15 PM, Russell King wrote:
> Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
> implementation.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   7 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 344 
> ++
>  drivers/gpu/drm/bridge/dw-hdmi.c  |  64 +-
>  include/linux/platform_data/dw_hdmi-cec.h |  16 ++
>  5 files changed, 421 insertions(+), 11 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
>  create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
> 



> +static unsigned int parse_hdmi_addr(const struct edid *edid)
> +{
> + if (!edid || edid->extensions == 0)
> + return (u16)~0;
> +
> + return cec_get_edid_phys_addr((u8 *)edid,
> + EDID_LENGTH * (edid->extensions + 1), NULL);
> +}
> +
> +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long event,
> +   void *data)
> +{
> + struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
> + union hdmi_event *event_block = data;
> + unsigned int phys;
> +
> + dev_info(event_block->base.source, "event %lu\n", event);
> +
> + if (event_block->base.source != cec->adap->devnode.parent)
> + return NOTIFY_OK;
> +
> + switch (event) {
> + case HDMI_CONNECTED:
> + break;
> +
> + case HDMI_DISCONNECTED:
> + cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
> + break;
> +
> + case HDMI_NEW_EDID:
> + phys = parse_hdmi_addr(event_block->edid.edid);
> + cec_s_phys_addr(cec->adap, phys, false);
> + break;
> + }
> +
> + return NOTIFY_OK;
> +}

Wouldn't it make a lot of sense to integrate this into the cec framework?

All you need is to pass an hdmi_notifier_dev as argument to 
cec_allocate_adapter()
and you can integrate this.

If you are OK with that, then I can make patches for that.

Regards,

Hans

[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number

[Sean Paul]

On Mon, Aug 22, 2016 at 8:40 PM, Mark yao  wrote:
> On 2016年08月23日 04:30, Sean Paul wrote:
>>
>> On Thu, Aug 18, 2016 at 6:02 AM, Mark yao  wrote:
>>>
>>> On 2016年08月18日 17:11, Daniel Vetter wrote:

 On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
>>
>> Hi Sean
>>
>> Thanks for send v3 patch for rk3399 vop support.
>>
>> But sorry for that, I had changed my mind, those patches are
>> deprecated,
>> I have new rk3399 patch on my downstream kernel, I will upstream soon.

 Wut? Imo merge Sean's patch here, and then rebase your downstream
 patches
 on top of it. That you have a downstream tree which is out of sync with
 upstream shouldn't be a reason to stall upstream development.
 -Daniel

>>> Yeah, Sorry for that.
>>>
>>> In fact, on my downstream kernel, also have those patches, my new rk3399
>>> patches are based on them,
>>> but the new rk3399 patches will cover the those patches,  Sean's patches
>>> is
>>> old version.
>>>
>>> I just want to fast forward, don't want to send two version drivers to
>>> upstream.
>>> but if you and Dave feel ok for that, I have no problem:-) .
>>>
>>> merged Sean's patches and then apply new version patches.
>>>
>> Ok, so can I get a review/ack for these revised patches then?
>> Something is better than nothing, and there's a bunch of stuff that
>> depends on these changes.
>>
>> Sean
>
> Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the lost
> patches use v2 version?
>

Yes, v2 4/5 was reviewed as-is, so I just applied it.

Sean

>
>>
>>
>>> Thanks.
>>>
>>> --
>>> ï¼­ark Yao
>>>
>>>
>>
>>
>
>
> --
> ï¼­ark Yao
>
>

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

[Russell King - ARM Linux]

On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
> Hi Russell,
> 
> On 08/12/2016 04:15 PM, Russell King wrote:
> > Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
> > implementation.
> > 
> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig|   7 +
> >  drivers/gpu/drm/bridge/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 344 
> > ++
> >  drivers/gpu/drm/bridge/dw-hdmi.c  |  64 +-
> >  include/linux/platform_data/dw_hdmi-cec.h |  16 ++
> >  5 files changed, 421 insertions(+), 11 deletions(-)
> >  create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
> >  create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
> > 
> 
> 
> 
> > +static unsigned int parse_hdmi_addr(const struct edid *edid)
> > +{
> > +   if (!edid || edid->extensions == 0)
> > +   return (u16)~0;
> > +
> > +   return cec_get_edid_phys_addr((u8 *)edid,
> > +   EDID_LENGTH * (edid->extensions + 1), NULL);
> > +}
> > +
> > +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long 
> > event,
> > + void *data)
> > +{
> > +   struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
> > +   union hdmi_event *event_block = data;
> > +   unsigned int phys;
> > +
> > +   dev_info(event_block->base.source, "event %lu\n", event);
> > +
> > +   if (event_block->base.source != cec->adap->devnode.parent)
> > +   return NOTIFY_OK;
> > +
> > +   switch (event) {
> > +   case HDMI_CONNECTED:
> > +   break;
> > +
> > +   case HDMI_DISCONNECTED:
> > +   cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
> > +   break;
> > +
> > +   case HDMI_NEW_EDID:
> > +   phys = parse_hdmi_addr(event_block->edid.edid);
> > +   cec_s_phys_addr(cec->adap, phys, false);
> > +   break;
> > +   }
> > +
> > +   return NOTIFY_OK;
> > +}
> 
> Wouldn't it make a lot of sense to integrate this into the cec framework?
> 
> All you need is to pass an hdmi_notifier_dev as argument to 
> cec_allocate_adapter()
> and you can integrate this.
> 
> If you are OK with that, then I can make patches for that.

It's not just about CEC.  It's also used for passing information between
the video and audio parts, so tying this into CEC is wrong.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number

[Mark yao]

On 2016年08月23日 04:30, Sean Paul wrote:
> On Thu, Aug 18, 2016 at 6:02 AM, Mark yao  wrote:
>> On 2016年08月18日 17:11, Daniel Vetter wrote:
>>> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
> Hi Sean
>
> Thanks for send v3 patch for rk3399 vop support.
>
> But sorry for that, I had changed my mind, those patches are deprecated,
> I have new rk3399 patch on my downstream kernel, I will upstream soon.
>>> Wut? Imo merge Sean's patch here, and then rebase your downstream patches
>>> on top of it. That you have a downstream tree which is out of sync with
>>> upstream shouldn't be a reason to stall upstream development.
>>> -Daniel
>>>
>> Yeah, Sorry for that.
>>
>> In fact, on my downstream kernel, also have those patches, my new rk3399
>> patches are based on them,
>> but the new rk3399 patches will cover the those patches,  Sean's patches is
>> old version.
>>
>> I just want to fast forward, don't want to send two version drivers to
>> upstream.
>> but if you and Dave feel ok for that, I have no problem:-) .
>>
>> merged Sean's patches and then apply new version patches.
>>
> Ok, so can I get a review/ack for these revised patches then?
> Something is better than nothing, and there's a bunch of stuff that
> depends on these changes.
>
> Sean
Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the 
lost patches use v2 version?


>
>
>> Thanks.
>>
>> --
>> ï¼­ark Yao
>>
>>
>
>


-- 
ï¼­ark Yao

[PATCH] drm/simple-helpers: Always add planes to the state update

[Daniel Vetter]

Our update function is hooked to the single plane, which might not get
called for crtc-only updates. Which is surprising, so fix this by
always adding the plane.

While at it document how the event should be sent out better in
the kerneldoc.

Cc: Noralf Trønnes 
Cc: andrea.merello at gmail.com
Tested-and-Reported-by: andrea.merello at gmail.com
Signed-off-by: Daniel Vetter 
---
I'm not entirely sure we really want to put the responsibility for
this onto driver. Plan B) would be to remove the kerneldoc I added
here and call the right function from drm_simple_kms_plane_atomic_update.
That way simple drivers don't need to deal with that detail, and in
general those drivers don't care that much about the miniscule
possible race a generic implementation would cause. What do you
suggest as the best approach?
-Daniel
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 7 +++
 include/drm/drm_simple_kms_helper.h | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index bada17166512..447631018426 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -34,6 +34,12 @@ static const struct drm_encoder_funcs 
drm_simple_kms_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };

+static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+   return drm_atomic_add_affected_planes(state->state, crtc);
+}
+
 static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_simple_display_pipe *pipe;
@@ -57,6 +63,7 @@ static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
 }

 static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
+   .atomic_check = drm_simple_kms_crtc_check,
.disable = drm_simple_kms_crtc_disable,
.enable = drm_simple_kms_crtc_enable,
 };
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index 269039722f91..826946ca2b82 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -60,6 +60,12 @@ struct drm_simple_display_pipe_funcs {
 *
 * This function is called when the underlying plane state is updated.
 * This hook is optional.
+*
+* This is the function drivers should submit the
+* _pending_vblank_event from. Using either
+* drm_crtc_arm_vblank_event(), when the driver supports vblank
+* interrupt handling, or drm_crtc_send_vblank_event() directly in case
+* the hardware lacks vblank support entirely.
 */
void (*update)(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *plane_state);
-- 
2.8.1

[PATCH v4 3/5] drm: add SimpleDRM driver

[Daniel Vetter]

On Mon, Aug 22, 2016 at 10:25:23PM +0200, Noralf Trønnes wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
> 
> Userspace can create dumb-buffers which can be blit into the real
> framebuffer similar to UDL. No access to the real framebuffer is allowed
> (compared to earlier version of this driver) to avoid security issues.
> Furthermore, this way we can support arbitrary modes as long as we have a
> conversion-helper.
> 
> The driver was originally written by David Herrmann in 2014.
> My main contribution is to make use of drm_simple_kms_helper and
> rework the probe path to avoid use of the deprecated drm_platform_init()
> and drm_driver.{load,unload}().
> Additions have also been made for later changes to the Device Tree binding
> document, like support for clocks, regulators and having the node under
> /chosen. This code was lifted verbatim from simplefb.c.
> 
> Cc: dh.herrmann at gmail.com
> Cc: libv at skynet.be
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes from version 3:
> - Reworked gem code to match udl
> - Dropped PRIME support
> - Dropped dirty_info_property, it's gone
> - Don't use drm_device.platformdev it's deprecated
> - Remove struct sdrm_device #ifdef's
> - Split out sdrm_fb_init() from sdrm_fb_create(), needed by fbdev code
> - Simplify drm_clip validation by extending the check in
>   sdrm_dirty() and drop the one in sdrm_blit()
> - Removed sdrm_dirty_all_unlocked() which was unused.
> 
> Changes from version 2:
> - Remove superfluos module.h includes
> - Move includes from header to source files
> - Set plane.fb before flushing in pipe update, or else the previous one
>   gets flushed
> - Added check for vblank event in sdrm_display_pipe_update()
> 
> Changes from version 1:
> - Move platform_set_drvdata() before drm_dev_register()
> - Remove drm_legacy_mmap() call.
> - Set mode_config.{min,max}_{width,height} to the actual dimensions
>   of the native framebuffer
> - Remove plane positioning since it won't work with the simple display pipe,
>   meaning sdrm_display_pipe_check() isn't necessary either
> - Support the additions to the Device Tree binding document, including
>   clocks, regulators and having the node under /chosen
> 
> Changes from previous version:
> - Remove FB_SIMPLE=n dependency to avoid kconfig recursive error
> - Changed module name to match kconfig help text: sdrm -> simpledrm
> - Use drm_simple_display_pipe
> - Replace deprecated drm_platform_init()
> - sdrm_dumb_create(): drm_gem_object_unreference() -> *_unlocked()
> - sdrm_dumb_map_offset(): drm_gem_object_lookup() remove drm_device parameter
> - sdrm_drm_mmap() changes:
>   Remove struct_mutex locking
>   Add drm_vma_offset_{lock,unlock}_lookup()
>   drm_mmap() -> drm_legacy_mmap()
> - dma_buf_begin_cpu_access() doesn't require start and length anymore
> - Use drm_cvt_mode() instead of open coding a mode
> - Fix format conversion. In the intermediate step, store the 8/6/5 bit color
>   value in the upper part of the 16-bit color variable, not the lower.
> - Support clips == NULL in sdrm_dirty()
> - Set mode_config.preferred_depth
> - Attach mode_config.dirty_info_property to connector
> 
>  drivers/gpu/drm/Kconfig  |   2 +
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/simpledrm/Kconfig|  19 +
>  drivers/gpu/drm/simpledrm/Makefile   |   4 +
>  drivers/gpu/drm/simpledrm/simpledrm.h|  86 +
>  drivers/gpu/drm/simpledrm/simpledrm_damage.c | 235 
>  drivers/gpu/drm/simpledrm/simpledrm_drv.c| 543 
> +++
>  drivers/gpu/drm/simpledrm/simpledrm_gem.c| 202 ++
>  drivers/gpu/drm/simpledrm/simpledrm_kms.c| 234 
>  9 files changed, 1326 insertions(+)
>  create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
>  create mode 100644 drivers/gpu/drm/simpledrm/Makefile
>  create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
>  create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c
>  create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
>  create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c
>  create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fc35731..a54cc8d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -290,3 +290,5 @@ source "drivers/gpu/drm/arc/Kconfig"
>  source "drivers/gpu/drm/hisilicon/Kconfig"
> 
>  source "drivers/gpu/drm/mediatek/Kconfig"
> +
> +source "drivers/gpu/drm/simpledrm/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index e3dba6f..eba32ad 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -83,3 +83,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>  obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>  obj-$(CONFIG_DRM_ARCPGU)+= arc/
>  obj-y

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Jonathan Corbet]

On Tue, 23 Aug 2016 15:28:55 +0200
Daniel Vetter  wrote:

> I think the more interesting story is, what's your plan with all the
> other driver related subsystem? Especially the ones which already have
> full directories of their own, like e.g. Documentation/gpio/. I think
> those should be really part of the infrastructure section (or
> something equally high-level), together with other awesome servies
> like pwm, regman, irqchip, ... And then there's also the large-scale
> subsystems like media or gpu. What's the plan to tie them all
> together? Personally I'm leaning towards keeping the existing
> directories (where they exist already), but inserting links into the
> overall driver-api section.

To say I have a plan is to overstate things somewhat...

One objective I do have, though, is to declutter Documentation/.
Presenting people looking for docs with a 270-file directory is
unfriendly to say the least.  We don't organize the code that way; the
average in the kernel is <... find | wc -l ... > about 15
files/directory, which is rather more manageable.  Someday I'd like
Documentation/ to look a lot more like the top-level directory.

It seems to me that we have a few basic types of stuff here:

 - Driver API documentation, obviously, is a lot of it, and I would like
   to organize it better and to move it out of the top-level directory.

 - Hardware usage information - module parameters, sysfs files, supported
   hardware information, graphic descriptions of the ancestry of hardware
   engineers, etc.  The readership for this stuff is quite different, and
   I think it should be separate; often it's intertwined with API
   information at the moment.

 - Other usage information - a lot of what's under filesystems/ for
   example, and more.

 - Core API documentation.

 - Kernel development tools - the stuff I started pulling together into
   the dev-tools/ subdirectory.

 - How to deal with this unruly mob - SubmittingPatches, CodingStyle,
   development-process, etc.  There's process stuff, and general
   development documents like volatile-considered-harmful.txt or
   memory-barriers.txt

We can go a long way by organizing this stuff within the formatted
documentation, but I really think we need to organize the directory
structure as well.  I see that as a slow-moving process that will take
years, but I do think it's a direction we should go.

jon

[PATCH v4 4/5] drm: simpledrm: add fbdev fallback support

[Daniel Vetter]

On Mon, Aug 22, 2016 at 10:25:24PM +0200, Noralf Trønnes wrote:
> Create a simple fbdev device during SimpleDRM setup so legacy user-space
> and fbcon can use it.
> 
> Original work by David Herrmann.
> 
> Cc: dh.herrmann at gmail.com
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes from version 3:
> - Remove #ifdef CONFIG_DRM_FBDEV_EMULATION
> - Use drm_fb_helper_set_suspend_lock()
> - Don't access the native framebuffer directly, but do blitting here as well.
> - Use the drm_fb_helper_sys_*() functions instead of the cfb versions.
> - Remove FBINFO_CAN_FORCE_OUTPUT flag which doesn't work now.
> - Pass struct drm_fb_helper around instead of struct sdrm_fbdev.
> 
> Changes from version 2:
> - Switch to using drm_fb_helper in preparation for future panic handling
>   which needs an enabled pipeline.
> 
> Changes from version 1:
>   No changes
> 
> Changes from previous version:
> - Remove the DRM_SIMPLEDRM_FBDEV kconfig option and use DRM_FBDEV_EMULATION
> - Suspend fbcon/fbdev when the pipeline is enabled, resume in lastclose
> - Add FBINFO_CAN_FORCE_OUTPUT flag so we get oops'es on the console
> 
>  drivers/gpu/drm/simpledrm/Kconfig   |   3 +
>  drivers/gpu/drm/simpledrm/Makefile  |   2 +-
>  drivers/gpu/drm/simpledrm/simpledrm.h   |   5 +
>  drivers/gpu/drm/simpledrm/simpledrm_drv.c   |   4 +
>  drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 201 
> 
>  drivers/gpu/drm/simpledrm/simpledrm_kms.c   |  14 ++
>  6 files changed, 228 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> 
> diff --git a/drivers/gpu/drm/simpledrm/Kconfig 
> b/drivers/gpu/drm/simpledrm/Kconfig
> index f45b25d..3257590 100644
> --- a/drivers/gpu/drm/simpledrm/Kconfig
> +++ b/drivers/gpu/drm/simpledrm/Kconfig
> @@ -13,6 +13,9 @@ config DRM_SIMPLEDRM
> SimpleDRM supports "simple-framebuffer" DeviceTree objects and
> compatible platform framebuffers.
> 
> +   If fbdev support is enabled, this driver will also provide an fbdev
> +   compatibility layer that supports fbcon, mmap is not supported.
> +
> If unsure, say Y.
> 
> To compile this driver as a module, choose M here: the
> diff --git a/drivers/gpu/drm/simpledrm/Makefile 
> b/drivers/gpu/drm/simpledrm/Makefile
> index f6a62dc..5474f7f 100644
> --- a/drivers/gpu/drm/simpledrm/Makefile
> +++ b/drivers/gpu/drm/simpledrm/Makefile
> @@ -1,4 +1,4 @@
>  simpledrm-y :=   simpledrm_drv.o simpledrm_kms.o simpledrm_gem.o \
> - simpledrm_damage.o
> + simpledrm_damage.o simpledrm_fbdev.o
> 
>  obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h 
> b/drivers/gpu/drm/simpledrm/simpledrm.h
> index 0739581..d4eb52c 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm.h
> +++ b/drivers/gpu/drm/simpledrm/simpledrm.h
> @@ -16,6 +16,7 @@
>  #include 
> 
>  struct simplefb_format;
> +struct drm_fb_helper;
>  struct regulator;
>  struct clk;
> 
> @@ -23,6 +24,7 @@ struct sdrm_device {
>   struct drm_device *ddev;
>   struct drm_simple_display_pipe pipe;
>   struct drm_connector conn;
> + struct drm_fb_helper *fb_helper;
> 
>   /* framebuffer information */
>   const struct simplefb_format *fb_sformat;
> @@ -42,6 +44,7 @@ struct sdrm_device {
>   struct regulator **regulators;
>  };
> 
> +void sdrm_lastclose(struct drm_device *ddev);
>  int sdrm_drm_modeset_init(struct sdrm_device *sdrm);
> 
>  int sdrm_dirty(struct drm_framebuffer *fb,
> @@ -82,5 +85,7 @@ struct sdrm_framebuffer {
>  int sdrm_fb_init(struct drm_device *ddev, struct sdrm_framebuffer *fb,
>const struct drm_mode_fb_cmd2 *mode_cmd,
>struct sdrm_gem_object *obj);
> +void sdrm_fbdev_init(struct sdrm_device *sdrm);
> +void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
> 
>  #endif /* SDRM_DRV_H */
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c 
> b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> index 17c1b55..fe752c6 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> @@ -47,6 +47,7 @@ static const struct vm_operations_struct sdrm_gem_vm_ops = {
>  static struct drm_driver sdrm_drm_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
>   .fops = _drm_fops,
> + .lastclose = sdrm_lastclose,
> 
>   .gem_free_object = sdrm_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
> @@ -451,6 +452,8 @@ static int sdrm_simplefb_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_regulators;
> 
> + sdrm_fbdev_init(sdrm);
> +
>   DRM_INFO("Initialized %s on minor %d\n", ddev->driver->name,
>ddev->primary->index);
> 
> @@ -476,6 +479,7 @@ static int sdrm_simplefb_remove(struct platform_device 
> *pdev)
>   struct drm_device *ddev = platform_get_drvdata(pdev);
>   struct sdrm_device *sdrm = ddev->dev_private;
> 
> + 

[PATCH v4 2/5] drm/fb-helper: Add drm_fb_helper_set_suspend_lock()

[Daniel Vetter]

On Mon, Aug 22, 2016 at 10:25:22PM +0200, Noralf Trønnes wrote:
> This adds a function that also takes the console lock before calling
> fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
> a plain wrapper around fb_set_suspend().
> Resume is run asynchronously using a worker if the console lock is
> already taken. This is modelled after the i915 driver.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 57 
> +
>  include/drm/drm_fb_helper.h |  9 +++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e98..897e6f4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -29,6 +29,7 @@
>   */
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -618,6 +619,16 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper 
> *helper)
>   kfree(helper->crtc_info);
>  }
>  
> +static void drm_fb_helper_resume_worker(struct work_struct *work)
> +{
> + struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> + resume_work);
> +
> + console_lock();
> + fb_set_suspend(helper->fbdev, 0);
> + console_unlock();
> +}
> +
>  static void drm_fb_helper_dirty_work(struct work_struct *work)
>  {
>   struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> @@ -649,6 +660,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
> drm_fb_helper *helper,
>  {
>   INIT_LIST_HEAD(>kernel_fb_list);
>   spin_lock_init(>dirty_lock);
> + INIT_WORK(>resume_work, drm_fb_helper_resume_worker);
>   INIT_WORK(>dirty_work, drm_fb_helper_dirty_work);
>   helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
>   helper->funcs = funcs;
> @@ -1035,6 +1047,51 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> *fb_helper, int state)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>  
> +/**
> + * drm_fb_helper_set_suspend_lock - wrapper around fb_set_suspend that also
> + *  takes the console lock
> + * @fb_helper: driver-allocated fbdev helper
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * A wrapper around fb_set_suspend() that takes the console lock. If the lock
> + * isn't available on resume, a worker is tasked with waiting for the lock
> + * to become available. The console lock can be pretty contented on resume
> + * due to all the printk activity.
> + *
> + * This function can be called multiple times with the same state since
> + * _info->state is checked to see if fbdev is running or not before 
> locking.
> + *
> + * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
> + */
> +void drm_fb_helper_set_suspend_lock(struct drm_fb_helper *fb_helper, int 
> state)

We generally call the functions which take the locks themselves _unlocked
(or the version that requires locks to be held _locked). Other nit: I
think added a sentence to the kerneldoc of drm_fb_helper_set_suspend to
instead use this one (since it avoids lock contention on resume) would be
good.

Otherwise looks great.

And if you're bored, following up with a bunch of patches to roll this out
to drivers would be awesome ;-)

> +{
> + if (!fb_helper || !fb_helper->fbdev)
> + return;
> +
> + /* make sure there's no pending/ongoing resume */
> + flush_work(_helper->resume_work);
> +
> + if (state) { /* suspend */

Hm, one more nit: rename state to suspend and you both make the
declaration more self-explanatory, and can drop these 2 comments here.

Thanks, Daniel

> + if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
> + return;
> +
> + console_lock();
> +
> + } else { /* resume */
> + if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
> + return;
> +
> + if (!console_trylock()) {
> + schedule_work(_helper->resume_work);
> + return;
> + }
> + }
> +
> + fb_set_suspend(fb_helper->fbdev, state);
> + console_unlock();
> +}
> +EXPORT_SYMBOL(drm_fb_helper_set_suspend_lock);
> +
>  static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>u16 blue, u16 regno, struct fb_info *info)
>  {
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index db8d478..db7e861 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -176,6 +176,7 @@ struct drm_fb_helper_connector {
>   *  the screen buffer
>   * @dirty_lock: spinlock protecting @dirty_clip
>   * @dirty_work: worker used to flush the framebuffer
> + * @resume_work: worker used during resume if the console lock is already 
> taken
>   *
>   * This is the main structure used by the fbdev