Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Daniel Vetter]

On Fri, May 05, 2017 at 08:40:43PM +0300, Ville Syrjälä wrote:
> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> > 
> > > In several instances the driver passes an 'enum pipe' value to a
> > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> > > TRANSCODER_x have the same values this doesn't cause functional
> > > problems. Still it is incorrect and causes clang to generate warnings
> > > like this:
> > > 
> > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> > >   conversion from enumeration type 'enum transcoder' to different
> > >   enumeration type 'enum pipe' [-Wenum-conversion]
> > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> > > 
> > > Change the code to pass values of the type expected by the callee.
> > > 
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> > >  4 files changed, 14 insertions(+), 8 deletions(-)
> > 
> > Ping, any comments on this patch?
> 
> I'm not convinced the patch is making things any better really. To
> fix this really properly, I think we'd need to introduce a new enum 
> pch_transcoder and thus avoid the confusion of which type of
> transcoder we're talking about. Currently most places expect an 
> enum pipe when dealing with PCH transcoders, and enum transcoder
> when dealing with CPU transcoders. But there are some exceptions
> of course.

enum transcoder is wrong for the pch, that enum is only for cpu
transcoders introduced in hsw+. PCH should always use enum pipe.

So a patch to switch the enum to enum pipe for all the pch functions
sounds like the right thing to do here. Plus maybe rename enum transcoder
to enum cpu_transcoder, but that'd be tons of work. A comment instead
might be easier ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Make vblank evade warnings optional

[Daniel Vetter]

On Sun, May 07, 2017 at 07:52:14PM -0600, Jens Axboe wrote:
> On 05/07/2017 11:56 AM, Daniel Vetter wrote:
> > On Sun, May 7, 2017 at 7:46 PM, Jens Axboe  wrote:
> >> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> Add a new Kconfig option to enable/disable the extra warnings
> >>> from the vblank evade code. For now we'll keep the warning
> >>> about an actually missed vblank always enabled as that can have
> >>> an actual user visible impact. But if we miss the deadline
> >>> othrwise there's no real need to bother the user with that.
> >>> We'll want these warnings enabled during development however
> >>> so that we can catch regressions.
> >>>
> >>> Based on the reports it looks like this is still very easy
> >>> to hit on SKL, so we have more work ahead of us to optimize
> >>> the crtiical section further.
> >>
> >> Shouldn't it just be a debug printk or something instead, so that normal
> >> people don't see it, but the folks that turn on debugging can get the
> >> info they need? Seems silly to add a kconfig option for this.
> > 
> > I guess we could keep it as debug for users, but we want to make this
> > a hard failure on our CI machines. Kconfig knob is the easiest to roll
> > out to all machines.
> 
> Wouldn't a module parameter be more useful then, as an opt-in
> to catch these violations.
> 
> Nobody is going to know wtf to set this kconfig option to.

They're all hidden behind an overall i915 debugging option which tells you
not to enable it. You won't see this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Make vblank evade warnings optional

[Daniel Vetter]

On Sun, May 07, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Add a new Kconfig option to enable/disable the extra warnings
> from the vblank evade code. For now we'll keep the warning
> about an actually missed vblank always enabled as that can have
> an actual user visible impact. But if we miss the deadline
> othrwise there's no real need to bother the user with that.
> We'll want these warnings enabled during development however
> so that we can catch regressions.
> 
> Based on the reports it looks like this is still very easy
> to hit on SKL, so we have more work ahead of us to optimize
> the crtiical section further.
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Dave Airlie 
> Cc: Jens Axboe 
> Cc: Linus Torvalds 
> Cc: Maarten Lankhorst 
> Reported-by: Jens Axboe 
> Reported-by: Linus Torvalds 
> Fixes: e1edbd44e23b ("drm/i915: Complain if we take too long under vblank 
> evasion.")
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/Kconfig.debug  | 13 +
>  drivers/gpu/drm/i915/intel_sprite.c |  7 +--
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
> b/drivers/gpu/drm/i915/Kconfig.debug
> index e091809a9a9e..49db32fa6524 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -87,3 +87,16 @@ config DRM_I915_LOW_LEVEL_TRACEPOINTS
>and also analyze the request dependency resolving timeline.
>  
>If in doubt, say "N".
> +
> +config DRM_I915_DEBUG_VBLANK_EVADE
> + bool "Enable extra debug warnings for vblank evasion"
> + depends on DRM_I915
> + default n
> + help
> +   Choose this option to turn on extra debug warnings for the
> +   vblank evade mechanism. This gives a warning every time the
> +   the deadline allotted for the vblank evade critical section
> +   is exceeded, even if there isn't an actual risk of missing
> +   the vblank.
> +
> +   If in doubt, say "N".
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index f7d431427115..8c87c717c7cd 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -198,12 +198,15 @@ void intel_pipe_update_end(struct intel_crtc *crtc, 
> struct intel_flip_work *work
> ktime_us_delta(end_vbl_time, 
> crtc->debug.start_vbl_time),
> crtc->debug.min_vbl, crtc->debug.max_vbl,
> crtc->debug.scanline_start, scanline_end);
> - } else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
> -VBLANK_EVASION_TIME_US)
> + }
> +#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
> + else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
> +  VBLANK_EVASION_TIME_US)
>   DRM_WARN("Atomic update on pipe (%c) took %lld us, max time 
> under evasion is %u us\n",
>pipe_name(pipe),
>ktime_us_delta(end_vbl_time, 
> crtc->debug.start_vbl_time),
>VBLANK_EVASION_TIME_US);
> +#endif
>  }
>  
>  static void
> -- 
> 2.10.2
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: use memdup_user_nul

[Daniel Vetter]

On Sat, May 06, 2017 at 11:40:17PM +0800, Geliang Tang wrote:
> Use memdup_user_nul() helper instead of open-coding to simplify the
> code.
> 
> Signed-off-by: Geliang Tang 

Thx for the patch, applied to drm-intel.git.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   | 13 +++--
>  drivers/gpu/drm/i915/intel_pipe_crc.c | 13 +++--
>  2 files changed, 6 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d689e51..e56b636 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3704,16 +3704,10 @@ static ssize_t 
> i915_displayport_test_active_write(struct file *file,
>   if (len == 0)
>   return 0;
>  
> - input_buffer = kmalloc(len + 1, GFP_KERNEL);
> - if (!input_buffer)
> - return -ENOMEM;
> + input_buffer = memdup_user_nul(ubuf, len);
> + if (IS_ERR(input_buffer))
> + return PTR_ERR(input_buffer);
>  
> - if (copy_from_user(input_buffer, ubuf, len)) {
> - status = -EFAULT;
> - goto out;
> - }
> -
> - input_buffer[len] = '\0';
>   DRM_DEBUG_DRIVER("Copied %d bytes from user\n", (unsigned int)len);
>  
>   drm_connector_list_iter_begin(dev, &conn_iter);
> @@ -3739,7 +3733,6 @@ static ssize_t 
> i915_displayport_test_active_write(struct file *file,
>   }
>   }
>   drm_connector_list_iter_end(&conn_iter);
> -out:
>   kfree(input_buffer);
>   if (status < 0)
>   return status;
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 206ee4f..813dd3c 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -842,19 +842,12 @@ static ssize_t display_crc_ctl_write(struct file *file, 
> const char __user *ubuf,
>   return -E2BIG;
>   }
>  
> - tmpbuf = kmalloc(len + 1, GFP_KERNEL);
> - if (!tmpbuf)
> - return -ENOMEM;
> -
> - if (copy_from_user(tmpbuf, ubuf, len)) {
> - ret = -EFAULT;
> - goto out;
> - }
> - tmpbuf[len] = '\0';
> + tmpbuf = memdup_user_nul(ubuf, len);
> + if (IS_ERR(tmpbuf))
> + return PTR_ERR(tmpbuf);
>  
>   ret = display_crc_ctl_parse(dev_priv, tmpbuf, len);
>  
> -out:
>   kfree(tmpbuf);
>   if (ret < 0)
>   return ret;
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Pekka Paalanen]

On Sat, 6 May 2017 13:34:44 +0200
Mario Kleiner  wrote:

> Just please make sure that one (user configurable/opt-in if necessary) 
> policy from the beginning is to allow leasing out any output to 
> applications, not just HMDs. My type of scientific/medical applications 
> would benefit as soon as it has the option to get a drm lease for a 
> given output on both X and Wayland based systems. That's not a 
> theoretical future use case, but one i'd try to offer to my users as 
> soon as a stable protocol/implementation is available in a regular Linux 
> distribution. It wouldn't be fun for inexperienced users if they had to 
> hack the database for every model of display they want to use, or if 
> every untrusted user would have to have a root password to do so.

Hi Mario,

as Keith said, the DRM leasing API is ok for that. Such policy must not
be part of the database, IMO, so it's not an issue for the database.
This is another reason why I think the database should only describe
the hardware, not set usage patterns nor be an extension of display
server configuration.

For Wayland, we would need to experiment. I would not start with the
assumption that the Wayland extension used for grabbing HMD outputs
could also be used to grab an arbitrary output that the compositor is
already using for the desktop. Since an output is a part of the
desktop, it is possible it needs more strict or slightly different
grabbing semantics. I believe one should design both cases separately
and then see how much they have overlap.


Thanks,
pq

PS. Keith, I started writing a reply to you, but didn't finish yet.


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

Re: [PATCH 2/5] drm: Use new mode_valid() helpers in connector probe helper

[Daniel Vetter]

On Thu, May 04, 2017 at 03:11:39PM +0100, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid() and crtc->mode_valid() helper callbacks to
> validate the modes.
> 
> The new callbacks are optional so the behaviour remains the same
> if they are not implemented. If they are, then the code loops
> through all the connector's encodersXcrtcs and calls the
> callback.
> 
> If at least a valid encoderXcrtc combination is found which
> accepts the mode then the function returns MODE_OK.
> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Andrzej Hajda 
> Cc: Archit Taneja 

A few comments below.
-Daniel

> ---
>  drivers/gpu/drm/drm_probe_helper.c | 71 
> +++---
>  1 file changed, 67 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 1b0c14a..bf19f82 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -80,6 +80,67 @@
>   return MODE_OK;
>  }
>  
> +static enum drm_mode_status
> +drm_mode_validate_connector(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + const struct drm_connector_helper_funcs *connector_funcs =
> + connector->helper_private;
> + struct drm_device *dev = connector->dev;
> + uint32_t *ids = connector->encoder_ids;
> + enum drm_mode_status ret = MODE_OK;
> + unsigned int i;
> +
> + /* Step 1: Validate against connector */
> + if (connector_funcs && connector_funcs->mode_valid)
> + ret = connector_funcs->mode_valid(connector, mode);
> +
> + if (ret != MODE_OK)
> + return ret;
> +
> + /* Step 2: Validate against encoders and crtcs */
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> + const struct drm_encoder_helper_funcs *encoder_funcs;
> + struct drm_crtc *crtc;
> +
> + if (!encoder)
> + continue;
> +
> + encoder_funcs = encoder->helper_private;
> + if (encoder_funcs && encoder_funcs->mode_valid)
> + ret = encoder_funcs->mode_valid(encoder, mode);
> + else
> + ret = MODE_OK; /* encoder accepts everything */
> +
> + /* No point in continuing for crtc check as this encoder will
> +  * not accept the mode anyway. If all encoders reject the mode
> +  * then, at exit, ret will not be MODE_OK. */
> + if (ret != MODE_OK)
> + continue;

I think we should validate encoders against connector->possible_ids here.
Might be that not many drivers fill this out correctly, and in case fixing
that is much work, perhaps as a follow-up. But would be good to at least
help look down that part of uapi a bit more.

This isn't checked within atomic and legacy helpers since we assume that
->best_encoder respectively ->atomic_best_encoder gives us a valid encoder
...

> +
> + drm_for_each_crtc(crtc, dev) {
> + const struct drm_crtc_helper_funcs *crtc_funcs;
> +
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;

We check this one here already in both atomic and legacy helpers, so all
drivers should get this right.

> +
> + crtc_funcs = crtc->helper_private;
> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> + return MODE_OK; /* crtc accepts everything */
> +
> + ret = crtc_funcs->mode_valid(crtc, mode);
> + if (ret == MODE_OK)
> + /* If we get to this point there is at least
> +  * one combination of encoder+crtc that works
> +  * for this mode. Lets return now. */
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +
>  static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
>  {
>   struct drm_cmdline_mode *cmdline_mode;
> @@ -283,8 +344,10 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
>   *  (if specified)
>   *- drm_mode_validate_flag() checks the modes against basic connector
>   *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
> - *- the optional &drm_connector_helper_funcs.mode_valid helper can 
> perform
> - *  driver and/or hardware specific checks
> + *- the optional &drm_connector_helper_funcs.mode_valid,
> + *   &drm_crtc_helper_funcs.mode_valid and
> + *   &drm_encoder_helper_funcs.mode_valid helpers can perform driver 
> and/or
> + *   hardware specific checks

I'd leave 2 bul

Re: [PATCH 1/5] drm: Add crtc/encoder/bridge->mode_valid() callbacks

[Daniel Vetter]

On Thu, May 04, 2017 at 03:11:38PM +0100, Jose Abreu wrote:
> This adds a new callback to crtc, encoder and bridge helper functions
> called mode_valid(). This callback shall be implemented if the
> corresponding component has some sort of restriction in the modes
> that can be displayed. A NULL callback implicates that the component
> can display all the modes.
> 
> Only the callbacks were implemented to simplify review process,
> following patches will make use of them.
> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Andrzej Hajda 
> Cc: Archit Taneja 
> ---
>  include/drm/drm_bridge.h | 20 
>  include/drm/drm_modeset_helper_vtables.h | 40 
> 
>  2 files changed, 60 insertions(+)

I think we should also update the kernel-doc for connector->mode_valid,
explaining why it is not called in the atomic check phase, but only at
mode probe time: To allow userspace to override the kernel's sink
checks, in case of broken EDID with wrong limits from the sink.

Otherwise lgtm.
-Daniel

> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index fdd82fc..00c6c36 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -59,6 +59,26 @@ struct drm_bridge_funcs {
>   void (*detach)(struct drm_bridge *bridge);
>  
>   /**
> +  * @mode_valid:
> +  *
> +  * This callback is used to check if a specific mode is valid in this
> +  * bridge. This should be implemented if the bridge has some sort of
> +  * restriction in the modes it can display. For example, a given bridge
> +  * may be responsible to set a clock value. If the clock can not
> +  * produce all the values for the available modes then this callback
> +  * can be used to restrict the number of modes to only the ones that
> +  * can be displayed.
> +  *
> +  * This is called at mode probe and at atomic check phase.
> +  *
> +  * RETURNS:
> +  *
> +  * drm_mode_status Enum
> +  */
> + enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc,
> +const struct drm_display_mode *mode);
> +
> + /**
>* @mode_fixup:
>*
>* This callback is used to validate and adjust a mode. The paramater
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index c01c328..bb04688 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -106,6 +106,26 @@ struct drm_crtc_helper_funcs {
>   void (*commit)(struct drm_crtc *crtc);
>  
>   /**
> +  * @mode_valid:
> +  *
> +  * This callback is used to check if a specific mode is valid in this
> +  * crtc. This should be implemented if the crtc has some sort of
> +  * restriction in the modes it can display. For example, a given crtc
> +  * may be responsible to set a clock value. If the clock can not
> +  * produce all the values for the available modes then this callback
> +  * can be used to restrict the number of modes to only the ones that
> +  * can be displayed.
> +  *
> +  * This is called at mode probe and at atomic check phase.
> +  *
> +  * RETURNS:
> +  *
> +  * drm_mode_status Enum
> +  */
> + enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
> +const struct drm_display_mode *mode);
> +
> + /**
>* @mode_fixup:
>*
>* This callback is used to validate a mode. The parameter mode is the
> @@ -457,6 +477,26 @@ struct drm_encoder_helper_funcs {
>   void (*dpms)(struct drm_encoder *encoder, int mode);
>  
>   /**
> +  * @mode_valid:
> +  *
> +  * This callback is used to check if a specific mode is valid in this
> +  * encoder. This should be implemented if the encoder has some sort
> +  * of restriction in the modes it can display. For example, a given
> +  * encoder may be responsible to set a clock value. If the clock can
> +  * not produce all the values for the available modes then this callback
> +  * can be used to restrict the number of modes to only the ones that
> +  * can be displayed.
> +  *
> +  * This is called at mode probe and at atomic check phase.
> +  *
> +  * RETURNS:
> +  *
> +  * drm_mode_status Enum
> +  */
> + enum drm_mode_status (*mode_valid)(struct drm_encoder *crtc,
> +const struct drm_display_mode *mode);
> +
> + /**
>* @mode_fixup:
>*
>* This callback is used to validate and adjust a mode. The parameter
> -- 
> 1.9.1
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@list

[Bug 100949] Power management problem on CIK/SI hybrid laptop

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
Can you bisect?

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

Re: [PATCH 4/5] drm: Use mode_valid() in atomic modeset

[Daniel Vetter]

On Thu, May 04, 2017 at 04:13:51PM +0100, Jose Abreu wrote:
> On 04-05-2017 15:40, Ville Syrjälä wrote:
> > On Thu, May 04, 2017 at 03:11:41PM +0100, Jose Abreu wrote:
> >> +  struct drm_encoder *encoder,
> >> +  struct drm_crtc *crtc,
> >> +  struct drm_display_mode *mode)
> >> +{
> >> +  const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> >> +  const struct drm_connector_helper_funcs *connector_funcs =
> >> +  connector->helper_private;
> >> +  const struct drm_encoder_helper_funcs *encoder_funcs =
> >> +  encoder->helper_private;
> >> +  enum drm_mode_status ret = MODE_OK;
> >> +
> >> +  if (connector_funcs && connector_funcs->mode_valid)
> >> +  ret = connector_funcs->mode_valid(connector, mode);
> > As I mentioned earlier, this would break i915. We either can't call the 
> > connector hook at all here, or we have to make it somehow opt-in if some
> > drivers really want to do it.
> 
> Ok. You said you let users exceed the limits, but why doesn't it
> fail in atomic_check and will fail in mode_valid? I guess I can
> remove it, but this can lead to lots of confusion, i.e. with this
> series the mode_valid callbacks for all components are called, if
> I remove just one call the whole point will fall apart.
> 
> Can we think about something else ? I think making it opt-in is
> not ideal, if the helper is there then it should be used, but if
> thats the best solution then shall we add a flag which will call
> or not *all* the mode_valid callbacks in this stage
> (drm_device.allow_modevalid_call, ...) ?

This is a general issue, not a driver opt-in. With your new callbacks
ideally we'll have:
- all the source checks (clock limits, size limits) are in the
  crtc/encoder/bridge callbacks
- only the sink limit checks (derived from edid or DP aux) are in the
  connector callback

Letting userspace overwrite these seems like a reasonable idea that we
should support in general I think. See also my comment on patch 1 for the
connector's mode_valid kerneldoc.

For arcpgu that might mean that you need to move part of the connector's
mode_valid checks into the encoder, but since all the encoder modeset is
in there already, that seems like a good cleanup of the drm modeset
framework.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Introduce new mode validation callbacks

[Daniel Vetter]

On Thu, May 04, 2017 at 03:11:37PM +0100, Jose Abreu wrote:
> This series is a follow up from the discussion at [1]. We start by
> introducing crtc->mode_valid(), encoder->mode_valid() and
> bridge->mode_valid() callbacks which will be used in followup
> patches.
> 
> Next, at 2/5 we modify the connector probe helper so that only modes
> which are supported by a given encoder+crtc combination are probbed.
> 
> At 3/5 a helper function is introduced that calls all mode_valid()
> from a set of bridges.
> 
> At 4/5 we call all the mode_valid() callbacks for a given pipeline
> so that the mode is validated. This is done before calling mode_fixup().
> 
> Finally, at 5/5 we use the new crtc->mode_valid() callback in arcpgu
> and remove the atomic_check() callback.
> 
> [1] https://patchwork.kernel.org/patch/9702233/
> 
> Jose Abreu (5):
>   drm: Add crtc/encoder/bridge->mode_valid() callbacks
>   drm: Use new mode_valid() helpers in connector probe helper
>   drm: Introduce drm_bridge_mode_valid()
>   drm: Use mode_valid() in atomic modeset
>   drm: arc: Use crtc->mode_valid() callback
> 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Andrzej Hajda 
> Cc: Archit Taneja 

Looks nice. A few small things from Ville and me, but with those addressed
this looks all ready for merging and seems like a good improvement to the
modeset framework.

Ok, one more patch at the end is needed: We need to review and upate the
kernel-doc for all the existing hooks, and add cross-links between
mode_valid and atomic_check respectively mode_fixup.

Some more drivers using this would be sweet too, but not a blocker.

Thanks, Daniel
> 
>  drivers/gpu/drm/arc/arcpgu_crtc.c| 39 --
>  drivers/gpu/drm/drm_atomic_helper.c  | 92 
> ++--
>  drivers/gpu/drm/drm_bridge.c | 33 
>  drivers/gpu/drm/drm_probe_helper.c   | 71 ++--
>  include/drm/drm_bridge.h | 22 
>  include/drm/drm_modeset_helper_vtables.h | 40 ++
>  6 files changed, 275 insertions(+), 22 deletions(-)
> 
> -- 
> 1.9.1
> 
> 

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

[Bug 100949] Power management problem on CIK/SI hybrid laptop

[bugzilla-daemon]

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

Luya Tshimbalanga  changed:

   What|Removed |Added

 Attachment #131232|0   |1
is obsolete||

--- Comment #2 from Luya Tshimbalanga  ---
Created attachment 131255
  --> https://bugs.freedesktop.org/attachment.cgi?id=131255&action=edit
dmesg sorted by drm

dmesg sorted by drm attached, Noticeable problems are

[   28.135157] [drm] Internal thermal controller without fan control

[ 9815.904855] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport
link status failed
[ 9815.904891] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock
recovery failed


Narrowing down to amdgpu which detailed the hardware
$ dmesg | grep amdgpu
[   23.120326] [drm] amdgpu kernel modesetting enabled.
[   23.618949] fb: switching to amdgpudrmfb from EFI VGA
[   23.619716] amdgpu :00:01.0: VM size (-1) must be a power of 2
[   23.619975] amdgpu :00:01.0: VRAM: 1024M 0x -
0x3FFF (1024M used)
[   23.619977] amdgpu :00:01.0: GTT: 3072M 0x4000 -
0x
[   23.620094] [drm] amdgpu: 1024M of VRAM memory ready
[   23.620095] [drm] amdgpu: 3072M of GTT memory ready.
[   23.721480] amdgpu :00:01.0: amdgpu: using MSI.
[   23.721510] [drm] amdgpu: irq initialized.
[   23.721519] [drm] amdgpu: dpm initialized
[   23.724341] [drm] amdgpu atom DIG backlight initialized
[   24.430744] amdgpu :00:01.0: fence driver on ring 0 use gpu addr
0x4010, cpu addr 0xa02179c2d010
[   24.430790] amdgpu :00:01.0: fence driver on ring 1 use gpu addr
0x4020, cpu addr 0xa02179c2d020
[   24.430843] amdgpu :00:01.0: fence driver on ring 2 use gpu addr
0x4030, cpu addr 0xa02179c2d030
[   24.430921] amdgpu :00:01.0: fence driver on ring 3 use gpu addr
0x4040, cpu addr 0xa02179c2d040
[   24.430971] amdgpu :00:01.0: fence driver on ring 4 use gpu addr
0x4050, cpu addr 0xa02179c2d050
[   24.431066] amdgpu :00:01.0: fence driver on ring 5 use gpu addr
0x4060, cpu addr 0xa02179c2d060
[   24.431123] amdgpu :00:01.0: fence driver on ring 6 use gpu addr
0x4070, cpu addr 0xa02179c2d070
[   24.431170] amdgpu :00:01.0: fence driver on ring 7 use gpu addr
0x4080, cpu addr 0xa02179c2d080
[   24.431221] amdgpu :00:01.0: fence driver on ring 8 use gpu addr
0x4090, cpu addr 0xa02179c2d090
[   24.761420] amdgpu :00:01.0: fence driver on ring 9 use gpu addr
0x40a0, cpu addr 0xa02179c2d0a0
[   24.761749] amdgpu :00:01.0: fence driver on ring 10 use gpu addr
0x40b0, cpu addr 0xa02179c2d0b0
[   24.900778] amdgpu :00:01.0: fence driver on ring 11 use gpu addr
0x0068cd30, cpu addr 0xb70d02238d30
[   24.993027] amdgpu :00:01.0: fence driver on ring 12 use gpu addr
0x40d0, cpu addr 0xa02179c2d0d0
[   24.993099] amdgpu :00:01.0: fence driver on ring 13 use gpu addr
0x40e0, cpu addr 0xa02179c2d0e0
[   26.092550] fbcon: amdgpudrmfb (fb0) is primary device
[   27.935642] amdgpu :00:01.0: fb0: amdgpudrmfb frame buffer device
[   27.956506] [drm] Initialized amdgpu 3.16.0 20150101 for :00:01.0 on
minor 0
[   27.956682] amdgpu :01:00.0: enabling device ( -> 0003)
[   27.957234] amdgpu :01:00.0: VM size (-1) must be a power of 2
[   28.041269] amdgpu :01:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[   28.041274] amdgpu :01:00.0: GTT: 3072M 0x8000 -
0x00013FFF
[   28.041370] [drm] amdgpu: 2048M of VRAM memory ready
[   28.041372] [drm] amdgpu: 3072M of GTT memory ready.
[   28.042108] amdgpu :01:00.0: PCIE GART of 3072M enabled (table at
0x0004).
[   28.042308] amdgpu :01:00.0: amdgpu: using MSI.
[   28.042355] [drm] amdgpu: irq initialized.
[   28.135174] [drm] amdgpu: dpm initialized
[   28.265927] amdgpu :01:00.0: fence driver on ring 0 use gpu addr
0x8010, cpu addr 0xa0217c2eb010
[   28.266183] amdgpu :01:00.0: fence driver on ring 1 use gpu addr
0x8020, cpu addr 0xa0217c2eb020
[   28.266262] amdgpu :01:00.0: fence driver on ring 2 use gpu addr
0x8030, cpu addr 0xa0217c2eb030
[   28.266352] amdgpu :01:00.0: fence driver on ring 3 use gpu addr
0x8040, cpu addr 0xa0217c2eb040
[   28.266546] amdgpu :01:00.0: fence driver on ring 4 use gpu addr
0x8050, cpu addr 0xa0217c2eb050
[   28.266982] [drm] enabling PCIE gen 3 link speeds, disable with
amdgpu.pcie_gen2=0
[   30.289599] [drm] Initialized amdgpu 3.16.0 20150101 for :01:00.0 on
minor 1
[   30.485628] audit: type=1130 audit(1494213691.999:65): pid=1 uid=0
auid=4294967295 ses=429496

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Jani Nikula]

On Mon, 08 May 2017, Daniel Vetter  wrote:
> On Fri, May 05, 2017 at 08:40:43PM +0300, Ville Syrjälä wrote:
>> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> > 
>> > > In several instances the driver passes an 'enum pipe' value to a
>> > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
>> > > TRANSCODER_x have the same values this doesn't cause functional
>> > > problems. Still it is incorrect and causes clang to generate warnings
>> > > like this:
>> > > 
>> > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> > >   conversion from enumeration type 'enum transcoder' to different
>> > >   enumeration type 'enum pipe' [-Wenum-conversion]
>> > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> > > 
>> > > Change the code to pass values of the type expected by the callee.
>> > > 
>> > > Signed-off-by: Matthias Kaehlcke 
>> > > ---
>> > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> > >  4 files changed, 14 insertions(+), 8 deletions(-)
>> > 
>> > Ping, any comments on this patch?
>> 
>> I'm not convinced the patch is making things any better really. To
>> fix this really properly, I think we'd need to introduce a new enum 
>> pch_transcoder and thus avoid the confusion of which type of
>> transcoder we're talking about. Currently most places expect an 
>> enum pipe when dealing with PCH transcoders, and enum transcoder
>> when dealing with CPU transcoders. But there are some exceptions
>> of course.
>
> enum transcoder is wrong for the pch, that enum is only for cpu
> transcoders introduced in hsw+. PCH should always use enum pipe.

For background, below is the commit message for introduction of enum
transcoder.

> So a patch to switch the enum to enum pipe for all the pch functions
> sounds like the right thing to do here. Plus maybe rename enum transcoder
> to enum cpu_transcoder, but that'd be tons of work. A comment instead
> might be easier ...

The enum pipe conversion might be the right thing to do *if* you must do
something. But I'm not convinced you must. It's a bunch of churn that's
not just purely mechanical conversion.

BR,
Jani.


commit a5c961d1f3a9ab5ba0e5706e866192f8108143fe
Author: Paulo Zanoni 
Date:   Wed Oct 24 15:59:34 2012 -0200

drm/i915: add TRANSCODER_EDP

Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
(only used for VGA).

For all the outputs except for EDP we have an 1:1 mapping on the CPU
pipes and CPU transcoders, so if you're using CPU pipe A you have to
use CPU transcoder A. When have an eDP output you have to use
transcoder EDP and you can attach this CPU transcoder to any of the 3
CPU pipes. When using VGA you need to select a pair of matching CPU
pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
PCH transcoder.

For now we're just creating the cpu_transcoder definitions and setting
cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
registers was ported to use transcoder instead of pipe. The goal is to
keep the code backwards-compatible since on all cases except when
using eDP we must have pipe == cpu_transcoder.

V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
and Daniel Vetter.

We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
can be used by any CRTC, so when you stop using it you have to stop
saying you're using it, otherwise you may have at some point 2 CRTCs
claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
one), then the HW state readout code will get completely confused.

In other words:

Imagine the following case:
  xrandr --output eDP1 --auto --crtc 0
  xrandr --output eDP1 --off
  xrandr --output eDP1 --auto --crtc 2

After the last command you could get a "pipe A assertion failure
(expected off, current on)" because CRTC 0 still claims it's using
TRANSCODER_EDP, so the HW state readout function will read it
(through PIPECONF) and expect it to be off, when it's actually on
because it's being used by CRTC 2.

So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
make sure we're pointing to our own original CRTC which is certainly
not used by any other CRTC.

Signed-off-by: Paulo Zanoni 
Reviewed-by: Damien Lespiau 
Signed-off-by: Daniel Vetter 




-- 
J

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Summary|"Out of range" on a display |[DC] "Out of range" on a
   |connected to a DVI-D output |display connected to a
   |of RX460 card via   |DVI-D output of RX460 card
   |DVI-D<=>HDMI-A cable|via DVI-D<=>HDMI-A cable

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

Re: [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Jani Nikula]

On Sun, 07 May 2017, Hans de Goede  wrote:
> @@ -1403,6 +1410,31 @@ static inline u32 intel_plane_ggtt_offset(const struct 
> intel_plane_state *state)
>   return i915_ggtt_offset(state->vma);
>  }
>  
> +static inline unsigned int
> +intel_plane_get_rotation(const struct intel_plane_state *plane_state)
> +{

Random drive-by bikeshed, is this really worth the inline?

BR,
Jani.

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

[PATCH RESEND 3/4] drm/exynos: Merge pre/postclose hooks

[Daniel Vetter]

Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Reviewed-by: Sean Paul 
Reviewed-by: Liviu Dudau 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d3c4c3c858..50294a7bd29d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -82,14 +82,9 @@ static int exynos_drm_open(struct drm_device *dev, struct 
drm_file *file)
return ret;
 }
 
-static void exynos_drm_preclose(struct drm_device *dev,
-   struct drm_file *file)
-{
-   exynos_drm_subdrv_close(dev, file);
-}
-
 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
 {
+   exynos_drm_subdrv_close(dev, file);
kfree(file->driver_priv);
file->driver_priv = NULL;
 }
@@ -145,7 +140,6 @@ static struct drm_driver exynos_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
  | DRIVER_ATOMIC | DRIVER_RENDER,
.open   = exynos_drm_open,
-   .preclose   = exynos_drm_preclose,
.lastclose  = exynos_drm_lastclose,
.postclose  = exynos_drm_postclose,
.gem_free_object_unlocked = exynos_drm_gem_free_object,
-- 
2.11.0

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

[PATCH RESEND 4/4] drm: Nerf the preclose callback for modern drivers

[Daniel Vetter]

With all drivers converted there's only legacy dri1 drivers using it.
Not going to touch those, instead just hide it like we've done with
other dri1 driver hooks like firstopen.

In all this I didn't find any real reason why we'd needed 2 hooks, and
having symmetry between open and close just appeases my OCD better.
Yeah, someone else could do an s/postclose/close/, but that's for
someone who understands cocci. And maybe after this series is reviewed
and landed, to avoid patch-regen churn.

v2: s/last/post/close in the kernel-doc (Sean).

Reviewed-by: Sean Paul 
Reviewed-by: Liviu Dudau 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_file.c |  8 
 include/drm/drm_drv.h  | 23 ++-
 2 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 3783b659cd38..caad93dab54b 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -351,9 +351,8 @@ void drm_lastclose(struct drm_device * dev)
  *
  * This function must be used by drivers as their &file_operations.release
  * method. It frees any resources associated with the open file, and calls the
- * &drm_driver.preclose and &drm_driver.lastclose driver callbacks. If this is
- * the last open file for the DRM device also proceeds to call the
- * &drm_driver.lastclose driver callback.
+ * &drm_driver.postclose driver callback. If this is the last open file for the
+ * DRM device also proceeds to call the &drm_driver.lastclose driver callback.
  *
  * RETURNS:
  *
@@ -373,7 +372,8 @@ int drm_release(struct inode *inode, struct file *filp)
list_del(&file_priv->lhead);
mutex_unlock(&dev->filelist_mutex);
 
-   if (dev->driver->preclose)
+   if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
+   dev->driver->preclose)
dev->driver->preclose(dev, file_priv);
 
/* 
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 53b98321df9b..d0b5f363bfa1 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -104,23 +104,6 @@ struct drm_driver {
int (*open) (struct drm_device *, struct drm_file *);
 
/**
-* @preclose:
-*
-* One of the driver callbacks when a new &struct drm_file is closed.
-* Useful for tearing down driver-private data structures allocated in
-* @open like buffer allocators, execution contexts or similar things.
-*
-* Since the display/modeset side of DRM can only be owned by exactly
-* one &struct drm_file (see &drm_file.is_master and &drm_device.master)
-* there should never be a need to tear down any modeset related
-* resources in this callback. Doing so would be a driver design bug.
-*
-* FIXME: It is not really clear why there's both @preclose and
-* @postclose. Without a really good reason, use @postclose only.
-*/
-   void (*preclose) (struct drm_device *, struct drm_file *file_priv);
-
-   /**
 * @postclose:
 *
 * One of the driver callbacks when a new &struct drm_file is closed.
@@ -131,9 +114,6 @@ struct drm_driver {
 * one &struct drm_file (see &drm_file.is_master and &drm_device.master)
 * there should never be a need to tear down any modeset related
 * resources in this callback. Doing so would be a driver design bug.
-*
-* FIXME: It is not really clear why there's both @preclose and
-* @postclose. Without a really good reason, use @postclose only.
 */
void (*postclose) (struct drm_device *, struct drm_file *);
 
@@ -150,7 +130,7 @@ struct drm_driver {
 * state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
 * infrastructure.
 *
-* This is called after @preclose and @postclose have been called.
+* This is called after @postclose hook has been called.
 *
 * NOTE:
 *
@@ -516,6 +496,7 @@ struct drm_driver {
/* List of devices hanging off this driver with stealth attach. */
struct list_head legacy_dev_list;
int (*firstopen) (struct drm_device *);
+   void (*preclose) (struct drm_device *, struct drm_file *file_priv);
int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file 
*file_priv);
int (*dma_quiescent) (struct drm_device *);
int (*context_dtor) (struct drm_device *dev, int context);
-- 
2.11.0

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

[PATCH RESEND 2/4] drm/tegra: switch to postclose

[Daniel Vetter]

I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.

Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
Reviewed-by: Sean Paul 
Reviewed-by: Liviu Dudau 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9a1e34e48f64..51c48a8e00ec 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -892,7 +892,7 @@ static int tegra_drm_context_cleanup(int id, void *p, void 
*data)
return 0;
 }
 
-static void tegra_drm_preclose(struct drm_device *drm, struct drm_file *file)
+static void tegra_drm_postclose(struct drm_device *drm, struct drm_file *file)
 {
struct tegra_drm_file *fpriv = file->driver_priv;
 
@@ -960,7 +960,7 @@ static struct drm_driver tegra_drm_driver = {
.load = tegra_drm_load,
.unload = tegra_drm_unload,
.open = tegra_drm_open,
-   .preclose = tegra_drm_preclose,
+   .postclose = tegra_drm_postclose,
.lastclose = tegra_drm_lastclose,
 
 #if defined(CONFIG_DEBUG_FS)
-- 
2.11.0

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

[PATCH RESEND 1/4] drm/nouveau: Merge pre/postclose hooks

[Daniel Vetter]

Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.

Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Reviewed-by: Sean Paul 
Reviewed-by: Liviu Dudau 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2b6ac24ce690..ec719df619a6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -881,7 +881,7 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file 
*fpriv)
 }
 
 static void
-nouveau_drm_preclose(struct drm_device *dev, struct drm_file *fpriv)
+nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
 {
struct nouveau_cli *cli = nouveau_cli(fpriv);
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -897,12 +897,6 @@ nouveau_drm_preclose(struct drm_device *dev, struct 
drm_file *fpriv)
list_del(&cli->head);
mutex_unlock(&drm->client.mutex);
 
-}
-
-static void
-nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
-{
-   struct nouveau_cli *cli = nouveau_cli(fpriv);
nouveau_cli_fini(cli);
kfree(cli);
pm_runtime_mark_last_busy(dev->dev);
@@ -974,7 +968,6 @@ driver_stub = {
.load = nouveau_drm_load,
.unload = nouveau_drm_unload,
.open = nouveau_drm_open,
-   .preclose = nouveau_drm_preclose,
.postclose = nouveau_drm_postclose,
.lastclose = nouveau_vga_lastclose,
 
-- 
2.11.0

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

Re: [PATCH RESEND 1/4] drm/nouveau: Merge pre/postclose hooks

[Daniel Vetter]

On Mon, May 08, 2017 at 10:26:30AM +0200, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.
> 
> Cc: Ben Skeggs 
> Cc: nouv...@lists.freedesktop.org
> Reviewed-by: Sean Paul 
> Reviewed-by: Liviu Dudau 
> Signed-off-by: Daniel Vetter 

Forgot the cover letter: I'm resending the patches that didn't find an
owner last time around. I'll smash them all into drm-misc later so I can
apply the final patch.

Thanks, Daniel
> ---
>  drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 2b6ac24ce690..ec719df619a6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -881,7 +881,7 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file 
> *fpriv)
>  }
>  
>  static void
> -nouveau_drm_preclose(struct drm_device *dev, struct drm_file *fpriv)
> +nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
>  {
>   struct nouveau_cli *cli = nouveau_cli(fpriv);
>   struct nouveau_drm *drm = nouveau_drm(dev);
> @@ -897,12 +897,6 @@ nouveau_drm_preclose(struct drm_device *dev, struct 
> drm_file *fpriv)
>   list_del(&cli->head);
>   mutex_unlock(&drm->client.mutex);
>  
> -}
> -
> -static void
> -nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
> -{
> - struct nouveau_cli *cli = nouveau_cli(fpriv);
>   nouveau_cli_fini(cli);
>   kfree(cli);
>   pm_runtime_mark_last_busy(dev->dev);
> @@ -974,7 +968,6 @@ driver_stub = {
>   .load = nouveau_drm_load,
>   .unload = nouveau_drm_unload,
>   .open = nouveau_drm_open,
> - .preclose = nouveau_drm_preclose,
>   .postclose = nouveau_drm_postclose,
>   .lastclose = nouveau_vga_lastclose,
>  
> -- 
> 2.11.0
> 

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

[PATCH 0/2] drm/omap: OMAP_BO flags

[Tomi Valkeinen]

Hi,

This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently run out
of TILER space.

This needs to be rebased on Laurent's "GEM object fixes" series, but I don't
expect any major conflicts.

 Tomi

Tomi Valkeinen (2):
  drm/omap: add omap_gem_put_paddr_locked()
  drm/omap: add OMAP_BO flags to affect buffer allocation

 drivers/gpu/drm/omapdrm/omap_gem.c | 32 +---
 include/uapi/drm/omap_drm.h|  3 +++
 2 files changed, 32 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[PATCH 2/2] drm/omap: add OMAP_BO flags to affect buffer allocation

[Tomi Valkeinen]

On SoCs with TILER, we have to ways to allocate buffers: normal
dma_alloc or via TILER (which basically functions as an IOMMU). TILER
can map 128MB at a time, and we only map the TILER buffers when they are
used (i.e. not at alloc time). If TILER is present, omapdrm always
uses TILER.

There are use cases that require lots of big buffers that are being used
at the same time by different IPs. At the moment the userspace has a
hard maximum of 128MB.

This patch adds three new flags that can be used by the userspace to
solve the situation:

OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
This can be used to avoid TILER if the userspace knows it needs more
than 128M of memory at the same time.

OMAP_BO_MEM_TILER: The driver will use TILER to get the memory. There's
nto much use for this flag at the moment, but it's here for
completeness.

OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep
it pinned. This can be used to 1) get an error at alloc time if TILER
space is full, and 2) get rid of the constant pin/unpin operations which
may have some effect on performance.

If none of the flags are given, the behavior is the same as currently.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 23 ++-
 include/uapi/drm/omap_drm.h|  3 +++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 5d73dccc1383..90ae8615f6c6 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1292,6 +1292,9 @@ void omap_gem_free_object(struct drm_gem_object *obj)
list_del(&omap_obj->mm_list);
spin_unlock(&priv->list_lock);
 
+   if (omap_obj->flags & OMAP_BO_MEM_PIN)
+   omap_gem_put_paddr_locked(obj);
+
/* this means the object is still pinned.. which really should
 * not happen.  I think..
 */
@@ -1338,6 +1341,11 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
return NULL;
}
 
+   if (flags & OMAP_BO_MEM_CONTIG) {
+   dev_err(dev->dev, "Tiled buffers require TILER 
memory\n");
+   return NULL;
+   }
+
/*
 * Tiled buffers are always shmem paged backed. When they are
 * scanned out, they are remapped into DMM/TILER.
@@ -1351,7 +1359,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
 */
flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
flags |= tiler_get_cpu_cache_flags();
-   } else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
+   } else if ((flags & OMAP_BO_MEM_CONTIG) ||
+   ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm)) {
/*
 * OMAP_BO_SCANOUT hints that the buffer doesn't need to be
 * tiled. However, to lower the pressure on memory allocation,
@@ -1411,12 +1420,24 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
goto err_release;
}
 
+   if (flags & OMAP_BO_MEM_PIN) {
+   dma_addr_t dummy;
+
+   ret = omap_gem_get_paddr(obj, &dummy, true);
+   if (ret)
+   goto err_free_dma;
+   }
+
spin_lock(&priv->list_lock);
list_add(&omap_obj->mm_list, &priv->obj_list);
spin_unlock(&priv->list_lock);
 
return obj;
 
+err_free_dma:
+   if (flags & OMAP_BO_MEM_DMA_API)
+   dma_free_writecombine(dev->dev, size,
+   omap_obj->vaddr, omap_obj->paddr);
 err_release:
drm_gem_object_release(obj);
 err_free:
diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
index 7fb97863c945..a976e8682c5f 100644
--- a/include/uapi/drm/omap_drm.h
+++ b/include/uapi/drm/omap_drm.h
@@ -40,6 +40,9 @@ struct drm_omap_param {
 #define OMAP_BO_SCANOUT0x0001  /* scanout capable 
(phys contiguous) */
 #define OMAP_BO_CACHE_MASK 0x0006  /* cache type mask, see cache 
modes */
 #define OMAP_BO_TILED_MASK 0x0f00  /* tiled mapping mask, see 
tiled modes */
+#define OMAP_BO_MEM_CONTIG 0x0008  /* only use contiguous dma mem 
*/
+#define OMAP_BO_MEM_TILER  0x0010  /* only use TILER mem */
+#define OMAP_BO_MEM_PIN0x0020  /* pin the buffer when 
allocating */
 
 /* cache modes */
 #define OMAP_BO_CACHED 0x  /* default */
-- 
2.7.4

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

[PATCH 1/2] drm/omap: add omap_gem_put_paddr_locked()

[Tomi Valkeinen]

Add omap_gem_put_paddr_locked() which is a version of
omap_gem_put_paddr() that expects the caller to hold the struct_mutex.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 68a75b829b71..5d73dccc1383 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -873,12 +873,12 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
 /* Release physical address, when DMA is no longer being performed.. this
  * could potentially unpin and unmap buffers from TILER
  */
-void omap_gem_put_paddr(struct drm_gem_object *obj)
+
+static void omap_gem_put_paddr_locked(struct drm_gem_object *obj)
 {
struct omap_gem_object *omap_obj = to_omap_bo(obj);
int ret;
 
-   mutex_lock(&obj->dev->struct_mutex);
if (omap_obj->paddr_cnt > 0) {
omap_obj->paddr_cnt--;
if (omap_obj->paddr_cnt == 0) {
@@ -896,7 +896,12 @@ void omap_gem_put_paddr(struct drm_gem_object *obj)
omap_obj->block = NULL;
}
}
+}
 
+void omap_gem_put_paddr(struct drm_gem_object *obj)
+{
+   mutex_lock(&obj->dev->struct_mutex);
+   omap_gem_put_paddr_locked(obj);
mutex_unlock(&obj->dev->struct_mutex);
 }
 
-- 
2.7.4

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

Re: [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

Hi,

On 08-05-17 10:25, Jani Nikula wrote:

On Sun, 07 May 2017, Hans de Goede  wrote:

@@ -1403,6 +1410,31 @@ static inline u32 intel_plane_ggtt_offset(const struct 
intel_plane_state *state)
return i915_ggtt_offset(state->vma);
  }
  
+static inline unsigned int

+intel_plane_get_rotation(const struct intel_plane_state *plane_state)
+{


Random drive-by bikeshed, is this really worth the inline?


It is small and this seemed a convenient way to answer the
"where to put this" question, but I'm fine with having it as
a regular function instead.

I guess it should go to intel_atomic_plane.c then?

Regards,

Hans

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

[PATCH 0/4] DMA-buf: Fine-tuning for four function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 11:05:05 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Combine two function calls into one in dma_buf_debug_show()
  Improve a size determination in dma_buf_attach()
  Adjust a null pointer check in dma_buf_attach()
  Use seq_putc() in two functions

 drivers/dma-buf/dma-buf.c| 8 +++-
 drivers/dma-buf/sync_debug.c | 6 +++---
 2 files changed, 6 insertions(+), 8 deletions(-)

-- 
2.12.2

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

[PATCH 1/4] dma-buf: Combine two function calls into one in dma_buf_debug_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 10:32:44 +0200

A bit of data was put into a sequence by two separate function calls.
Print the same data by a single function call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/dma-buf/dma-buf.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 512bdbc23bbb..53257c166f4d 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1122,9 +1122,7 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
attach_count = 0;
 
list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
-   seq_puts(s, "\t");
-
-   seq_printf(s, "%s\n", dev_name(attach_obj->dev));
+   seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
attach_count++;
}
 
-- 
2.12.2

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

[RFC v2 0/2] Exynos DRM: add Picture Processor extension

[Marek Szyprowski]

Dear all,

This is an updated proposal for extending EXYNOS DRM API with generic support
for hardware modules, which can be used for processing image data from the
one memory buffer to another. Typical memory-to-memory operations are:
rotation, scaling, colour space conversion or mix of them. This is
a follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
processors", which has been rejected as "not really needed in the DRM core":
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html

In this proposal I moved all the code to Exynos DRM driver, so now this
will be specific only to Exynos DRM. I've also changed the name from
framebuffer processor (fbproc) to picture processor (pp) to avoid confusion
with fbdev API.

Here is a bit more information what picture processors are:

Embedded SoCs are known to have a number of hardware blocks, which perform
such operations. They can be used in paralel to the main GPU module to
offload CPU from processing grapics or video data. One of example use of
such modules is implementing video overlay, which usually requires color
space conversion from NV12 (or similar) to RGB32 color space and scaling to
target window size.

The proposed API is ispired a bit by atomic KMS approach. Each picture
processor has a number of parameters, which describe operation to be
performed by respective hardware module. The list is open and can be
extended in the future. In typical case those parameters are a source fb
id and rectangle (x, y, width, height) and destination fb id and
rectangle as well as a rotation property. Parameters are provided by
their predefined IDs. To perform an operation on image data, userspace
provides a set of parameters and their values for given picture processor.

The proposed API consists of the 3 new ioctls:
- DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
  processors,
- DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
  processor,
- DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
  property set.

The proposed userspace API is extensible. Drivers can add their own,
custom parameters to add support for more advanced picture processing (for
example blending).

This proposal aims to replace Exynos DRM IPP (Image Post Processing)
subsystem. IPP API is over-engineered in general, but not really extensible
on the other side. It is also buggy, with significant design flaws - the
biggest issue is the fact that the API covers memory-2-memory picture
operations together with CRTC writeback and duplicating features, which
belongs to video plane. Comparing with IPP subsystem, the PP framework is
smaller (1807 vs 646 lines) and allows driver simplification (Exynos
rotator driver smaller by over 200 lines).

Open questions:
- How to expose supported pixel formats/modifiers? Currently this is done
  by the arrays of supported fourcc codes in the drm_exynos_pp_get structure
  and DRM_IOCTL_EXYNOS_PP_GET ioctl.
  I would like to switch to a structure similar to recently discussed
  format/modifier blob to avoid reinventing wheel:
  https://www.spinics.net/lists/intel-gfx/msg127094.html
- How to expose the range of the supported parameters (min/max width,
  rotation values)? Is it really needed?


TODO:
- convert remaining Exynos DRM IPP drivers (FIMC, GScaller)
- remove Exynos DRM IPP subsystem
- (optional) provide virtual V4L2 mem2mem device on top of Exynos PP framework

Patches were tested on Exynos 4412-based Odroid U3 board, on top of Linux v4.11
kernel.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Changelog:
v2:
- removed usage of DRM objects and properties - replaced them with simple list
  of parameters with predefined IDs

v1:
- moved this feature from DRM core to Exynos DRM driver
- changed name from framebuffer processor to picture processor
- simplified code to cover only things needed by Exynos drivers
- implemented simple fifo task scheduler
- cleaned up rotator driver conversion (removed IPP remainings)


v0: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
- initial post of "[RFC 0/2] New feature: Framebuffer processors"
- generic approach implemented in DRM core, rejected


Patch summary:

Marek Szyprowski (2):
  drm/exynos: Add Picture Processor framework
  drm/exynos: Convert Exynos Rotator driver to Picture Processor
interface

 drivers/gpu/drm/exynos/Kconfig  |   1 -
 drivers/gpu/drm/exynos/Makefile |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   4 +
 drivers/gpu/drm/exynos/exynos_drm_pp.c  | 645 
 drivers/gpu/drm/exynos/exynos_drm_pp.h  | 153 +++
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 493 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |  19 -
 include/uapi/drm/exynos_drm.h   |  76 
 9 files changed, 1006 insertions(+), 397 deletions(-)
 create mode

[RFC v2 1/2] drm/exynos: Add Picture Processor framework

[Marek Szyprowski]

This patch extends Exynos DRM API with picture processor hardware modules.
Such modules can be used for processing image data from the one memory buffer
to another. Typical memory-to-memory operations are: rotation, scaling, colour
space conversion or mix of them.

The proposed API is heavily inspired by atomic KMS approach - it is also
based on DRM objects and their properties. A new DRM object is introduced:
picture processor (called pp for convenience). Such objects have a set of
standard DRM properties, which describes the operation to be performed by
respective hardware module. In typical case those properties are a source
fb id and rectangle (x, y, width, height) and destination fb id and
rectangle. Optionally a rotation property can be also specified if
supported by the given hardware. To perform an operation on image data,
userspace provides a set of properties and their values for given fbproc
object in a similar way as object and properties are provided for
performing atomic page flip / mode setting.

The proposed API consists of the 3 new ioctls:
- DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
  processors,
- DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
  processor,
- DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
  property set.

The proposed userspace API is extensible. Drivers can add their own,
custom parameters to add support for more advanced picture processing (for
example blending).

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Makefile |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   8 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   4 +
 drivers/gpu/drm/exynos/exynos_drm_pp.c  | 645 
 drivers/gpu/drm/exynos/exynos_drm_pp.h  | 153 
 include/uapi/drm/exynos_drm.h   |  76 
 6 files changed, 888 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_pp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_pp.h

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index f663490e949d..2632b0ee5d2d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -3,7 +3,8 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 exynosdrm-y := exynos_drm_drv.o exynos_drm_crtc.o exynos_drm_fb.o \
-   exynos_drm_gem.o exynos_drm_core.o exynos_drm_plane.o
+   exynos_drm_gem.o exynos_drm_core.o exynos_drm_plane.o \
+   exynos_drm_pp.o
 
 exynosdrm-$(CONFIG_DRM_FBDEV_EMULATION) += exynos_drm_fbdev.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 035d02ecffcd..386a9d325c5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -27,6 +27,7 @@
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_plane.h"
+#include "exynos_drm_pp.h"
 #include "exynos_drm_vidi.h"
 #include "exynos_drm_g2d.h"
 #include "exynos_drm_ipp.h"
@@ -53,6 +54,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
 
init_waitqueue_head(&private->wait);
spin_lock_init(&private->lock);
+   INIT_LIST_HEAD(&private->pp_list);
 
dev_set_drvdata(dev->dev, dev);
dev->dev_private = (void *)private;
@@ -241,6 +243,12 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_PP_GET_RESOURCES, exynos_drm_pp_get_res,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_PP_GET, exynos_drm_pp_get,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_PP_COMMIT, exynos_drm_pp_commit,
+   DRM_AUTH | DRM_RENDER_ALLOW),
 };
 
 static const struct file_operations exynos_drm_driver_fops = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cf6e08cb35a7..bdc049e8c94f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -220,6 +220,10 @@ struct exynos_drm_private {
u32 pending;
spinlock_t  lock;
wait_queue_head_t   wait;
+
+   /* for pp api */
+   int num_pp;
+   struct list_head pp_list;
 };
 
 static inline struct exynos_drm_crtc *
diff --git a/drivers/gpu/drm/exynos/exynos_drm_pp.c 
b/drivers/gpu/drm/exynos/exynos_drm_pp.c
new file mode 100644
index ..e94231dbcb9c
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_pp.c
@@ -0,0 +1,645 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics Co.Ltd
+ * Authors:
+ * Marek Szyprowski 
+ *
+ * Exynos DRM Picture Pr

[PATCH 2/4] dma-buf: Improve a size determination in dma_buf_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 10:50:09 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/dma-buf/dma-buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 53257c166f4d..9887d72cf804 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -558,7 +558,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
 
-   attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
+   attach = kzalloc(sizeof(*attach), GFP_KERNEL);
if (attach == NULL)
return ERR_PTR(-ENOMEM);
 
-- 
2.12.2

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

[RFC v2 2/2] drm/exynos: Convert Exynos Rotator driver to Picture Processor interface

[Marek Szyprowski]

This patch converts Exynos Rotator driver from Exynos IPP API to
Exynos DRM Picture Processor API.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Kconfig  |   1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 493 +++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |  19 --
 4 files changed, 118 insertions(+), 396 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d185347c64c..84c8cc2aa28d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -106,7 +106,6 @@ config DRM_EXYNOS_FIMC
 
 config DRM_EXYNOS_ROTATOR
bool "Rotator"
-   depends on DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos Rotator for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 386a9d325c5a..b3b2d0628842 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -401,6 +401,7 @@ struct exynos_drm_driver_info {
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
+   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 79282a820ecc..a23a780bfa26 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,29 +22,18 @@
 #include 
 #include 
 #include "regs-rotator.h"
+#include "exynos_drm_fb.h"
 #include "exynos_drm_drv.h"
-#include "exynos_drm_ipp.h"
+#include "exynos_drm_iommu.h"
+#include "exynos_drm_pp.h"
 
 /*
  * Rotator supports image crop/rotator and input/output DMA operations.
  * input DMA reads image data from the memory.
  * output DMA writes image data to memory.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > Rotator H/W > Memory.
- */
-
-/*
- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. need to add supported list in prop_list.
  */
 
 #define get_rot_context(dev)   platform_get_drvdata(to_platform_device(dev))
-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
-   struct rot_context, ippdrv);
 #define rot_read(offset)   readl(rot->regs + (offset))
 #define rot_write(cfg, offset) writel(cfg, rot->regs + (offset))
 
@@ -88,18 +78,19 @@ struct rot_limit_table {
  * @clock: rotator gate clock.
  * @limit_tbl: limitation of rotator.
  * @irq: irq number.
- * @cur_buf_id: current operation buffer id.
  * @suspended: suspended state.
  */
 struct rot_context {
-   struct exynos_drm_ippdrvippdrv;
+   struct exynos_drm_pp pp;
+   struct drm_device *drm_dev;
+   struct device   *dev;
struct resource *regs_res;
void __iomem*regs;
struct clk  *clock;
struct rot_limit_table  *limit_tbl;
int irq;
-   int cur_buf_id[EXYNOS_DRM_OPS_MAX];
boolsuspended;
+   struct exynos_drm_pp_task   *task;
 };
 
 static void rotator_reg_set_irq(struct rot_context *rot, bool enable)
@@ -138,9 +129,6 @@ static enum rot_irq_status 
rotator_reg_get_irq_status(struct rot_context *rot)
 static irqreturn_t rotator_irq_handler(int irq, void *arg)
 {
struct rot_context *rot = arg;
-   struct exynos_drm_ippdrv *ippdrv = &rot->ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
-   struct drm_exynos_ipp_event_work *event_work = c_node->event_work;
enum rot_irq_status irq_status;
u32 val;
 
@@ -152,13 +140,13 @@ static irqreturn_t rotator_irq_handler(int irq, void *arg)
val |= ROT_STATUS_IRQ_PENDING((u32)irq_status);
rot_write(val, ROT_STATUS);
 
-   if (irq_status == ROT_IRQ_STATUS_COMPLETE) {
-   event_work->ippdrv = ippdrv;
-   event_work->buf_id[EXYNOS_DRM_OPS_DST] =
-   rot->cur_buf_id[EXYNOS_DRM_OPS_DST];
-   queue_work(ippdrv->event_workq, &event_work->work);
-   } else {
-   DRM_ERROR("the SFR is set illegally\n");
+   if (rot->task) {
+   struct exynos_drm_pp_task *task = rot->task;
+
+   rot->task = NULL;
+   pm_runtime_put(rot->dev);
+   exynos_drm_pp_task_done(task,
+   irq_status == ROT_IRQ_STATUS_COMPLETE ? 0 : -EINVAL);
}
 
return IRQ_HANDLED;
@@ -214,9 +202,6 @@ static int rotator_src_set_fmt(struct device *dev, u32 fmt)
case DRM_FORMAT_XRGB8

[PATCH 3/4] dma-buf: Adjust a null pointer check in dma_buf_attach()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 10:54:17 +0200

The script "checkpatch.pl" pointed information out like the following.

Comparison to NULL could be written "!attach"

Thus adjust this expression.

Signed-off-by: Markus Elfring 
---
 drivers/dma-buf/dma-buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 9887d72cf804..4a038dcf5361 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -559,7 +559,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
return ERR_PTR(-EINVAL);
 
attach = kzalloc(sizeof(*attach), GFP_KERNEL);
-   if (attach == NULL)
+   if (!attach)
return ERR_PTR(-ENOMEM);
 
attach->dev = dev;
-- 
2.12.2

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

[PATCH 4/4] dma-buf: Use seq_putc() in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 10:55:42 +0200

Three single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/dma-buf/sync_debug.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index c769dc653b34..a0d780ab68c3 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -110,7 +110,7 @@ static void sync_print_fence(struct seq_file *s,
}
}
 
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj)
@@ -161,7 +161,7 @@ static int sync_debugfs_show(struct seq_file *s, void 
*unused)
 sync_timeline_list);
 
sync_print_obj(s, obj);
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
}
spin_unlock_irqrestore(&sync_timeline_list_lock, flags);
 
@@ -173,7 +173,7 @@ static int sync_debugfs_show(struct seq_file *s, void 
*unused)
container_of(pos, struct sync_file, sync_file_list);
 
sync_print_sync_file(s, sync_file);
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
}
spin_unlock_irqrestore(&sync_file_list_lock, flags);
return 0;
-- 
2.12.2

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

Re: [Nouveau] [PATCH] drm/nouveau/secboot: fix some error handling in 'ls_ucode_img_load_gr'

[Emil Velikov]

Hi Christophe,

s/fix some error handling in 'ls_ucode_img_load_gr/plug memory leak in
ls_ucode_img_load_gr() error path/

On 8 May 2017 at 08:46, Christophe JAILLET
 wrote:
> The last goto looks spurious because it releases less resources than the
> previous one.
> Add a new label in order to free the memory allocated by the 'kmemdup'
> call.
>
> Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading 
> functions")
>
> Signed-off-by: Christophe JAILLET 
> ---
> This fix is just a guess. I don't have the hardware to test it.
> At first, I just wanted to change the last 'goto free_data' into a
> 'goto free_img' in order to have a 'logical' goto layout.
> Then, I changed my mind and added another label to revert the 'kmemdup' a
> few lines above.
>
> I hope I'm correct :)
Coffee hasn't kicked in fully, but I think this is off. This free()
will be called even on success leading to issues.

> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_gr.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_gr.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_gr.c
> index d1cf02d22db1..1b83e1395c34 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_gr.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_gr.c
> @@ -116,6 +116,7 @@ ls_ucode_img_load_gr(const struct nvkm_subdev *subdev, 
> struct ls_ucode_img *img,
> ret = nvkm_firmware_get(subdev->device, f, &sig);
> if (ret)
> goto free_data;
> +
> img->sig = kmemdup(sig->data, sig->size, GFP_KERNEL);
> if (!img->sig) {
> ret = -ENOMEM;
> @@ -127,10 +128,12 @@ ls_ucode_img_load_gr(const struct nvkm_subdev *subdev, 
> struct ls_ucode_img *img,
>  &img->ucode_desc);
> if (IS_ERR(img->ucode_data)) {
> ret = PTR_ERR(img->ucode_data);
> -   goto free_data;
> +   goto free_img_sig;
Thus I'd just move the free here and use goto free_sig.

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

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

[Tomi Valkeinen]

On 06/05/17 14:58, Hans Verkuil wrote:

> My assumption was that hdmi_display_disable() was called when the hotplug 
> would go
> away. But I discovered that that isn't the case, or at least not when X is 
> running.
> It seems that the actual HPD check is done in hdmic_detect() in
> omapdrm/displays/connector-hdmi.c.

For some HW it's done there (in the case there's no IP handling the
HPD), but in some cases it's done in tpd12s015 driver (e.g. pandaboard),
and in some cases it also could be done in the hdmi driver (if the HPD
is handled by the HDMI IP, but at the moment we don't have this case
supported in the SW).

> But there I have no access to hdmi.core (needed for the 
> hdmi4_cec_set_phys_addr() call).
> 
> Any idea how to solve this? I am not all that familiar with drm, let alone 
> omapdrm,
> so if you can point me in the right direction, then that would be very 
> helpful.

Hmm, indeed, looks the the output is kept enabled even if HPD drops and
the connector status is changed to disconnected.

I don't have a very good solution... I think we have to add a function
to omapdss_hdmi_ops, which the connector-hdmi and tpd12s015 drivers can
call when they detect a HPD change. That call would go to the HDMI IP
driver.

Peter is about to send hotplug-interrupt-handling series, I think the
HPD function work should be done on top of that, as otherwise it'll just
conflict horribly.

 Tomi



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

Re: [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Ville Syrjälä]

On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
> On some (Bay Trail) devices the LCD panel is mounted upside-down.
> 
> This commit uses the code to read back the initial rotation of the
> primary plane in get_initial_plane_config from Ville Syrjala's
> "drm/fb-helper: Inherit rotation wip" patch and when re-using the
> initial fb it stores that in intel_crtc.initial_rotation.
> 
> It adds an intel_plane_get_rotation helper which combines this
> initial_rotation with any rotation requested by userspace and
> uses this in all places which look at a planes rotation, thus
> transparently dealing with upside-down LCD panels without requiring
> any user-space or fbcon changes.
> 
> This fixes the kernel boot messages switching from being shown the right
> way up in efifb to being shown upside down as soon as a native kms driver
> loads, as well as any graphics displayed by userspace being upside-down.
> 
> Note this only deals with upside-down LCD panels / 180 degrees
> rotation as the hardware in question only supports 180 degrees
> rotation in hardware. The one model known which has a panel mounted
> with 90/270 degrees rotation will need to be fully dealt with in
> userspace, even the firmware boot screen / menus are rotated 90 degrees
> on this one and there simply is nothing the kernel can do about this.

This pretty much looks like a very limited attempt at full pipe
rotation. I have posted a more generic version of that in the past
but it was pretty much shot down by everyone else.

So I'm not convinced this apporach is really the way to go. There
are a few limitations even for the 180 degree rotation so trying
to hide it inside the kernel isn't 100% possible. 

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

[Hans Verkuil]

On 05/08/2017 12:26 PM, Tomi Valkeinen wrote:
> On 06/05/17 14:58, Hans Verkuil wrote:
> 
>> My assumption was that hdmi_display_disable() was called when the hotplug 
>> would go
>> away. But I discovered that that isn't the case, or at least not when X is 
>> running.
>> It seems that the actual HPD check is done in hdmic_detect() in
>> omapdrm/displays/connector-hdmi.c.
> 
> For some HW it's done there (in the case there's no IP handling the
> HPD), but in some cases it's done in tpd12s015 driver (e.g. pandaboard),
> and in some cases it also could be done in the hdmi driver (if the HPD
> is handled by the HDMI IP, but at the moment we don't have this case
> supported in the SW).
> 
>> But there I have no access to hdmi.core (needed for the 
>> hdmi4_cec_set_phys_addr() call).
>>
>> Any idea how to solve this? I am not all that familiar with drm, let alone 
>> omapdrm,
>> so if you can point me in the right direction, then that would be very 
>> helpful.
> 
> Hmm, indeed, looks the the output is kept enabled even if HPD drops and
> the connector status is changed to disconnected.
> 
> I don't have a very good solution... I think we have to add a function
> to omapdss_hdmi_ops, which the connector-hdmi and tpd12s015 drivers can
> call when they detect a HPD change. That call would go to the HDMI IP
> driver.

Right, I was thinking the same, I just wasn't sure if that was the correct
solution.

> Peter is about to send hotplug-interrupt-handling series, I think the
> HPD function work should be done on top of that, as otherwise it'll just
> conflict horribly.

OK, I'll do that.

I'll get CEC supported on the omap4 eventually! :-)

Regards,

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Pekka Paalanen]

On Fri, 05 May 2017 07:25:14 -0700
Keith Packard  wrote:

> Pekka Paalanen  writes:
> 
> > I disagree on the details, more below.  
> 
> > Such a RandR request is something I would not like to have to replicate
> > on Wayland. The display server contains the policy, it should not just
> > expose everything up for grabs. This is a fundamental difference
> > between X11 and Wayland architectures, and I think the output
> > information database should support both ways.  
> 
> Sounds like a good idea; if you want to work on how this should appear
> in Wayland, that would be great as it would provide two implementations,
> rather than just one.

Hi Keith,

I would want to, but unfortunately I have barely enough time for
this fly-by commenting currently. However, I do have a fairly clear
idea of how all this talked about so far would be implemented in a
Wayland server, except for potential window management issues in case a
VR app connects both directly for a normal window and via a VR
compositor.

I forget if I mentioned this to you personally yet:
https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2

I wrote that before I knew about your DRM leasing work, which means
it is well outdated. The biggest difference is that instead of
flipping through the Wayland compositor, one would use DRM leases.

> > I disagree. Wayland will likely have a special protocol extension
> > exclusively for advertising HMDs, so the display server will need to
> > know which ones are HMDs and which one are not, regardless whether the
> > desktop is extended there or not. This extension could also offer the
> > DRM leasing capabilities.  
> 
> What I was thinking that a display which the window system cannot drive
> natively should probably just be ignored entirely. An HMD which can
> natively handle a desktop (such as the PSVR system) might well be
> advertised as 'desktop capable', even though it is an HMD.
> 
> However, I also think you're right -- while the window system can't deal
> with it *today*, that doesn't mean the window system won't be able to do
> that in the future.
> 
> Hrm. I think the important distinction here is that the user installed
> an application which is designed to talk directly to this display. From
> that, we should probably infer that the user would like to use that
> application with the display.

Right.


> >> Thanks again; I'm sensing that a simple 'ignore this monitor for the
> >> desktop' might suffice for now, but that we'll end up wanting something
> >> more complicated in the future. I think the key is to try and avoid
> >> making that harder by what we do now, but I don't think we should be
> >> trying to implement a larger solution too soon.  
> >
> > Yes, that I agree with.  
> 
> I guess that's the question -- is a simple command to ignore a monitor
> for purposes of the desktop sufficient for now? Or do we need to worry
> about a possible future in which the window system implements native HMD
> support?

I believe my proposal at the end of the email solves this question
both ways.

> > Ultimately I would envision an output device database describing
> > what kind of a device it is (a normal monitor, a video projector, a
> > HMD, a TV, ...) and then the software that implements the desktop or UI
> > policy will decide how that will be used. Some policy examples:
> >
> > - A projector: do not extend desktop UI, but have the output normally
> >   available, so one can put regular windows there (presentation
> >   software). Turned on by default.
> >
> > - A HMD: Do not extend desktop, do not expose to normal apps, keep it
> >   off until special request.
> >
> > - A HMD with cinematic mode support: Extend desktop, turn on by
> >   default, allow special HMD requests.
> >
> > - A TV: Try to disable overscan or try to compensate for it by
> > default.  
> 
> Those all sound useful. I wonder how much we might be able to guess from
> EDID info and whether we want to programmatically do some of this
> (especially the TV thing; that's really annoying :-). In any case, a
> problem for the future.

Indeed for the future. In the worst case, users will need to match
their devices by serial number or some other individual way one by
one.

Thinking again, I believe we have to have a way to override
database entries somehow. If we ship catch-all entries for, say,
all Sony TVs, we are bound to get some assignment wrong for
someone who then wants to make a correction without breaking
everyone else.

We are moving away from configuring outputs in a display server by the
connector name and towards configuring outputs based the actual output
device identity and type.

> > I would suggest to have a "output device type" attribute in the
> > database, and support only one value for now: "HMD". Then all display
> > servers can encode the policy to hide all HMDs by default.
> > Implementationwise it is no different from your idea, but separating
> > device description from usage policy would be a good 

Re: [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

Hi,

On 08-05-17 12:44, Ville Syrjälä wrote:

On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:

On some (Bay Trail) devices the LCD panel is mounted upside-down.

This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Syrjala's
"drm/fb-helper: Inherit rotation wip" patch and when re-using the
initial fb it stores that in intel_crtc.initial_rotation.

It adds an intel_plane_get_rotation helper which combines this
initial_rotation with any rotation requested by userspace and
uses this in all places which look at a planes rotation, thus
transparently dealing with upside-down LCD panels without requiring
any user-space or fbcon changes.

This fixes the kernel boot messages switching from being shown the right
way up in efifb to being shown upside down as soon as a native kms driver
loads, as well as any graphics displayed by userspace being upside-down.

Note this only deals with upside-down LCD panels / 180 degrees
rotation as the hardware in question only supports 180 degrees
rotation in hardware. The one model known which has a panel mounted
with 90/270 degrees rotation will need to be fully dealt with in
userspace, even the firmware boot screen / menus are rotated 90 degrees
on this one and there simply is nothing the kernel can do about this.


This pretty much looks like a very limited attempt at full pipe
rotation.


Correct, it is limited to 180 degree rotation because that is what
almost all hardware out there which needs rotation to correct
for LCD-panel mounting needs and all pipes on GEN4+ support
180 degree rotation and on GEN < 4 we will never set initial_rotation
so this patch is a nop.


I have posted a more generic version of that in the past
but it was pretty much shot down by everyone else.


I agree that trying to deal with 90/270 degree rotation in the
kernel is not a good idea, but 180 degree rotation is much
easier to deal with and all devices I know of where the kernel
can even detect it needs to do rotation use 180 degree rotation.


So I'm not convinced this apporach is really the way to go.


This ways in at about the same amount of lines added as the previous
2 patches, but unlike the previous 2 patches it actually fully solves
the problem. As my testing has shown we really should not punt this
problem to userspace because then we will get a never ending job
of needing to fix the userspace kms consumer of the week. I'm aware
of at least 6 implementations which would need fixing without
even trying: intel-ddx modesetting-ddx gnome-wayland-compositor
kde-wayland-compositor, sway-wayland-compositor, weston.


There are a few limitations even for the 180 degree rotation so
trying to hide it inside the kernel isn't 100% possible.


Looking at supported_rotations for all planes I don't see any
limitations, or are the maybe stride limitations or some such ?

The only limitation I see is that on Cherry Trail Pipe B
supports reflect-x but not when combined with 180 degree
rotation, this will get caught in intel_plane_atomic_check_with_state
just as before only now reflect cannot be combined with
0 degree rotation instead of 180 degree rotation.

Regards,

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

[PATCH 0/2] GPU-DRM-Etnaviv: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 13:16:15 +0200

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Use seq_putc() in etnaviv_buffer_dump()
  Delete an error message for a failed memory allocation in etnaviv_bind()

 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.12.2

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

[PATCH 1/2] drm/etnaviv: Use seq_putc() in etnaviv_buffer_dump()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 13:00:28 +0200

Two single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 5255278dde56..b4deb26e1e40 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -182,12 +182,12 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu, 
struct seq_file *m)
 
for (i = 0; i < size / 4; i++) {
if (i && !(i % 4))
-   seq_puts(m, "\n");
+   seq_putc(m, '\n');
if (i % 4 == 0)
seq_printf(m, "\t0x%p: ", ptr + i);
seq_printf(m, "%08x ", *(ptr + i));
}
-   seq_puts(m, "\n");
+   seq_putc(m, '\n');
 }
 
 static int etnaviv_ring_show(struct etnaviv_gpu *gpu, struct seq_file *m)
-- 
2.12.2

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

[PATCH 2/2] drm/etnaviv: Delete an error message for a failed memory allocation in etnaviv_bind()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 13:08:11 +0200

The script "checkpatch.pl" pointed information out like the following.

WARNING: Possible unnecessary 'out of memory' message

Thus remove such a statement here.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index b4deb26e1e40..b121473622d0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -530,7 +530,6 @@ static int etnaviv_bind(struct device *dev)
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
-   dev_err(dev, "failed to allocate private data\n");
ret = -ENOMEM;
goto out_unref;
}
-- 
2.12.2

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

[PATCH v2 03/28] drm: omapdrm: Remove unused dss_get_core_pdev() function

[Laurent Pinchart]

The dss_get_core_pdev() function is unused, remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c | 5 -
 drivers/gpu/drm/omapdrm/dss/dss.h  | 1 -
 2 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 6a3ebfcd7223..3351ce23f413 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -62,11 +62,6 @@ enum omapdss_version omapdss_get_version(void)
 }
 EXPORT_SYMBOL(omapdss_get_version);
 
-struct platform_device *dss_get_core_pdev(void)
-{
-   return core.pdev;
-}
-
 int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
 {
struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 56493b290731..dfb10c9b4102 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -222,7 +222,6 @@ struct seq_file;
 struct platform_device;
 
 /* core */
-struct platform_device *dss_get_core_pdev(void);
 int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask);
 void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask);
 int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 09/28] drm: omapdrm: dsi: Store DSI type and PLL hardware data in OF data

[Laurent Pinchart]

The DSI PLL hardware data and DSS channels are selected based on the
OMAP SoC model. There's no need for fine-grained model information, as
the driver only needs to differentiate between OMAP3, OMAP4 and OMAP5.
As this can be done through the DSI compatible string, store the
corresponding information in OF match data instead to avoid accessing
the OMAP SoC model.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 116 ++
 1 file changed, 55 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 3edd194d6f36..400f903d8197 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -227,6 +227,12 @@ static int dsi_vc_send_null(struct omap_dss_device 
*dssdev, int channel);
 #define DSI_MAX_NR_ISRS2
 #define DSI_MAX_NR_LANES   5
 
+enum dsi_device_type {
+   DSI_TYPE_OMAP3,
+   DSI_TYPE_OMAP4,
+   DSI_TYPE_OMAP5,
+};
+
 enum dsi_lane_function {
DSI_LANE_UNUSED = 0,
DSI_LANE_CLK,
@@ -298,12 +304,24 @@ struct dsi_lp_clock_info {
u16 lp_clk_div;
 };
 
+struct dsi_module_id_data {
+   u32 address;
+   int id;
+};
+
+struct dsi_of_data {
+   enum dsi_device_type type;
+   const struct dss_pll_hw *pll_hw;
+   const struct dsi_module_id_data *modules;
+};
+
 struct dsi_data {
struct platform_device *pdev;
void __iomem *proto_base;
void __iomem *phy_base;
void __iomem *pll_base;
 
+   const struct dsi_of_data *data;
int module_id;
 
int irq;
@@ -396,11 +414,6 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
 };
 
-struct dsi_module_id_data {
-   u32 address;
-   int id;
-};
-
 static const struct of_device_id dsi_of_match[];
 
 #ifdef DSI_PERF_MEASURE
@@ -4857,24 +4870,14 @@ static int dsi_set_config(struct omap_dss_device 
*dssdev,
  * the channel in some more dynamic manner, or get the channel as a user
  * parameter.
  */
-static enum omap_channel dsi_get_channel(int module_id)
+static enum omap_channel dsi_get_channel(struct dsi_data *dsi)
 {
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP24xx:
-   case OMAPDSS_VER_AM43xx:
-   DSSWARN("DSI not supported\n");
-   return OMAP_DSS_CHANNEL_LCD;
-
-   case OMAPDSS_VER_OMAP34xx_ES1:
-   case OMAPDSS_VER_OMAP34xx_ES3:
-   case OMAPDSS_VER_OMAP3630:
-   case OMAPDSS_VER_AM35xx:
+   switch (dsi->data->type) {
+   case DSI_TYPE_OMAP3:
return OMAP_DSS_CHANNEL_LCD;
 
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
-   switch (module_id) {
+   case DSI_TYPE_OMAP4:
+   switch (dsi->module_id) {
case 0:
return OMAP_DSS_CHANNEL_LCD;
case 1:
@@ -4884,8 +4887,8 @@ static enum omap_channel dsi_get_channel(int module_id)
return OMAP_DSS_CHANNEL_LCD;
}
 
-   case OMAPDSS_VER_OMAP5:
-   switch (module_id) {
+   case DSI_TYPE_OMAP5:
+   switch (dsi->module_id) {
case 0:
return OMAP_DSS_CHANNEL_LCD;
case 1:
@@ -5065,7 +5068,7 @@ static void dsi_init_output(struct platform_device 
*dsidev)
 
out->output_type = OMAP_DISPLAY_TYPE_DSI;
out->name = dsi->module_id == 0 ? "dsi.0" : "dsi.1";
-   out->dispc_channel = dsi_get_channel(dsi->module_id);
+   out->dispc_channel = dsi_get_channel(dsi);
out->ops.dsi = &dsi_ops;
out->owner = THIS_MODULE;
 
@@ -5240,29 +5243,7 @@ static int dsi_init_pll_data(struct platform_device 
*dsidev)
pll->id = dsi->module_id == 0 ? DSS_PLL_DSI1 : DSS_PLL_DSI2;
pll->clkin = clk;
pll->base = dsi->pll_base;
-
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP34xx_ES1:
-   case OMAPDSS_VER_OMAP34xx_ES3:
-   case OMAPDSS_VER_OMAP3630:
-   case OMAPDSS_VER_AM35xx:
-   pll->hw = &dss_omap3_dsi_pll_hw;
-   break;
-
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
-   pll->hw = &dss_omap4_dsi_pll_hw;
-   break;
-
-   case OMAPDSS_VER_OMAP5:
-   pll->hw = &dss_omap5_dsi_pll_hw;
-   break;
-
-   default:
-   return -ENODEV;
-   }
-
+   pll->hw = dsi->data->pll_hw;
pll->ops = &dsi_pll_ops;
 
r = dss_pll_register(pll);
@@ -5339,7 +5320,8 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
return r;
}
 
-   d = of_match_node(dsi_of_match, dsidev->dev.of_node)->data;
+   dsi->data = of_match_node(dsi_of_match, dsidev->dev.of_node)->data;
+   d = dsi->data->modules;
wh

[PATCH v2 01/28] drm: omapdrm: Remove duplicate error messages when mapping memory

[Laurent Pinchart]

The devm_ioremap_resource() call can handle being given a NULL resource,
and prints an error message when mapping fails. Switch the remaining
devm_ioremap() calls to devm_ioremap_resource() and remove all
extraneous resource NULL checks and error messages printed manually by
the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c  | 12 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c| 21 ++---
 drivers/gpu/drm/omapdrm/dss/dss.c| 12 ++--
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c   |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi_pll.c   |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c| 12 +++-
 drivers/gpu/drm/omapdrm/dss/rfbi.c   | 12 ++--
 drivers/gpu/drm/omapdrm/dss/venc.c   | 12 ++--
 drivers/gpu/drm/omapdrm/dss/video-pll.c  | 20 ++--
 11 files changed, 23 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index d956e6266368..820b45a94e2f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4363,17 +4363,9 @@ static int dispc_bind(struct device *dev, struct device 
*master, void *data)
return r;
 
dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
-   if (!dispc_mem) {
-   DSSERR("can't get IORESOURCE_MEM DISPC\n");
-   return -EINVAL;
-   }
-
-   dispc.base = devm_ioremap(&pdev->dev, dispc_mem->start,
- resource_size(dispc_mem));
-   if (!dispc.base) {
-   DSSERR("can't ioremap DISPC\n");
+   dispc.base = devm_ioremap_resource(&pdev->dev, dispc_mem);
+   if (!dispc.base)
return -ENOMEM;
-   }
 
dispc.irq = platform_get_irq(dispc.pdev, 0);
if (dispc.irq < 0) {
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index f74615d005a8..58f21f2b32c2 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5326,12 +5326,9 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
 
dsi_mem = res;
 
-   dsi->proto_base = devm_ioremap(&dsidev->dev, res->start,
-   resource_size(res));
-   if (!dsi->proto_base) {
-   DSSERR("can't ioremap DSI protocol engine\n");
+   dsi->proto_base = devm_ioremap_resource(&dsidev->dev, res);
+   if (!dsi->proto_base)
return -ENOMEM;
-   }
 
res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "phy");
if (!res) {
@@ -5346,12 +5343,9 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
res = &temp_res;
}
 
-   dsi->phy_base = devm_ioremap(&dsidev->dev, res->start,
-   resource_size(res));
-   if (!dsi->phy_base) {
-   DSSERR("can't ioremap DSI PHY\n");
+   dsi->phy_base = devm_ioremap_resource(&dsidev->dev, res);
+   if (!dsi->phy_base)
return -ENOMEM;
-   }
 
res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "pll");
if (!res) {
@@ -5366,12 +5360,9 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
res = &temp_res;
}
 
-   dsi->pll_base = devm_ioremap(&dsidev->dev, res->start,
-   resource_size(res));
-   if (!dsi->pll_base) {
-   DSSERR("can't ioremap DSI PLL\n");
+   dsi->pll_base = devm_ioremap_resource(&dsidev->dev, res);
+   if (!dsi->pll_base)
return -ENOMEM;
-   }
 
dsi->irq = platform_get_irq(dsi->pdev, 0);
if (dsi->irq < 0) {
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 14887d5b02e5..fb57c0471000 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1201,17 +1201,9 @@ static int dss_bind(struct device *dev)
return r;
 
dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
-   if (!dss_mem) {
-   DSSERR("can't get IORESOURCE_MEM DSS\n");
-   return -EINVAL;
-   }
-
-   dss.base = devm_ioremap(&pdev->dev, dss_mem->start,
-   resource_size(dss_mem));
-   if (!dss.base) {
-   DSSERR("can't ioremap DSS\n");
+   dss.base = devm_ioremap_resource(&pdev->dev, dss_mem);
+   if (!dss.base)
return -ENOMEM;
-   }
 
r = dss_get_clocks();
if (r)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
index e05b7ac4f7dd..ed6001613405 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
@@ -889,16 +889,9 @@ int hdmi4_core_in

[PATCH v2 10/28] drm: omapdrm: dsi: Handle pin muxing internally

[Laurent Pinchart]

Don't rely on callback functions provided by the platform, but access
the syscon internally to mux the DSI pins.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c | 20 --
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 82 --
 drivers/gpu/drm/omapdrm/dss/dss.h  |  2 -
 3 files changed, 79 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 35def6fd6acd..524ecdd138f4 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -50,26 +50,6 @@ enum omapdss_version omapdss_get_version(void)
 }
 EXPORT_SYMBOL(omapdss_get_version);
 
-int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
-{
-   struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
-
-   if (!board_data->dsi_enable_pads)
-   return -ENOENT;
-
-   return board_data->dsi_enable_pads(dsi_id, lane_mask);
-}
-
-void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask)
-{
-   struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
-
-   if (!board_data->dsi_disable_pads)
-   return;
-
-   return board_data->dsi_disable_pads(dsi_id, lane_mask);
-}
-
 int dss_set_min_bus_tput(struct device *dev, unsigned long tput)
 {
struct omap_dss_board_info *pdata = core.pdev->dev.platform_data;
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 400f903d8197..d86a1ca6da00 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -20,6 +20,8 @@
 #define DSS_SUBSYS_NAME "DSI"
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -329,6 +331,7 @@ struct dsi_data {
bool is_enabled;
 
struct clk *dss_clk;
+   struct regmap *syscon;
 
struct dispc_clock_info user_dispc_cinfo;
struct dss_pll_clock_info user_dsi_cinfo;
@@ -2073,6 +2076,64 @@ static unsigned dsi_get_lane_mask(struct platform_device 
*dsidev)
return mask;
 }
 
+/* OMAP4 CONTROL_DSIPHY */
+#define OMAP4_DSIPHY_SYSCON_OFFSET 0x78
+
+#define OMAP4_DSI2_LANEENABLE_SHIFT29
+#define OMAP4_DSI2_LANEENABLE_MASK (0x7 << 29)
+#define OMAP4_DSI1_LANEENABLE_SHIFT24
+#define OMAP4_DSI1_LANEENABLE_MASK (0x1f << 24)
+#define OMAP4_DSI1_PIPD_SHIFT  19
+#define OMAP4_DSI1_PIPD_MASK   (0x1f << 19)
+#define OMAP4_DSI2_PIPD_SHIFT  14
+#define OMAP4_DSI2_PIPD_MASK   (0x1f << 14)
+
+static int dsi_omap4_mux_pads(struct dsi_data *dsi, unsigned int lanes)
+{
+   u32 enable_mask, enable_shift;
+   u32 pipd_mask, pipd_shift;
+   u32 reg;
+
+   if (!dsi->syscon)
+   return 0;
+
+   if (dsi->module_id == 0) {
+   enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
+   enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
+   pipd_mask = OMAP4_DSI1_PIPD_MASK;
+   pipd_shift = OMAP4_DSI1_PIPD_SHIFT;
+   } else if (dsi->module_id == 1) {
+   enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
+   enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
+   pipd_mask = OMAP4_DSI2_PIPD_MASK;
+   pipd_shift = OMAP4_DSI2_PIPD_SHIFT;
+   } else {
+   return -ENODEV;
+   }
+
+   regmap_read(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET, ®);
+
+   reg &= ~enable_mask;
+   reg &= ~pipd_mask;
+
+   reg |= (lanes << enable_shift) & enable_mask;
+   reg |= (lanes << pipd_shift) & pipd_mask;
+
+   regmap_write(dsi->syscon, OMAP4_DSIPHY_SYSCON_OFFSET, reg);
+
+   return 0;
+}
+
+static int dsi_enable_pads(struct dsi_data *dsi, unsigned int lane_mask)
+{
+   return dsi_omap4_mux_pads(dsi, lane_mask);
+}
+
+static void dsi_disable_pads(struct dsi_data *dsi)
+{
+   dsi_omap4_mux_pads(dsi, 0);
+}
+
 static int dsi_cio_init(struct platform_device *dsidev)
 {
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
@@ -2081,7 +2142,7 @@ static int dsi_cio_init(struct platform_device *dsidev)
 
DSSDBG("DSI CIO init starts");
 
-   r = dss_dsi_enable_pads(dsi->module_id, dsi_get_lane_mask(dsidev));
+   r = dsi_enable_pads(dsi, dsi_get_lane_mask(dsidev));
if (r)
return r;
 
@@ -2191,7 +2252,7 @@ static int dsi_cio_init(struct platform_device *dsidev)
dsi_cio_disable_lane_override(dsidev);
 err_scp_clk_dom:
dsi_disable_scp_clk(dsidev);
-   dss_dsi_disable_pads(dsi->module_id, dsi_get_lane_mask(dsidev));
+   dsi_disable_pads(dsi);
return r;
 }
 
@@ -2204,7 +2265,7 @@ static void dsi_cio_uninit(struct platform_device *dsidev)
 
dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF);
dsi_disable_scp_clk(dsidev);
-   dss_dsi_disable_pads(dsi->module_id, dsi_get_lane_mas

[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

[Laurent Pinchart]

Hello,

This patch series is a second, extended version of the code previously posted
as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code".

The omapdss/omapdrm initialization code is quite a mess. The physical devices
are instantiated from DT, but two virtual devices named omapdrm and omapdss
are instanciated from platform code to pass various pieces of platform data to
the drivers.

The omapdrm and omapdss platform devices are currently used to pass data and
function pointers from board code to the drivers for the purpose of

- identifying the OMAP SoC revision
- controlling the DSI pads
- configuring bus throughput

It turns out that all these can be handled in the omapdrm and omapdss drivers
without the need for platform data.

- The SoC revision is used to identify the version of various DSS IP cores,
which can instead be done through compatible string matching (with the help of
soc_device_match() in two cases where ES version is needed).

- The DSI pads control can be performed by the driver directly without calling
board code, accessing the related registers through syscon.

- Bus throughput control is implemented in mach-omap2 as a no-op, so we can
just drop the code.

This patch series starts with a few small cleanups and unused features removal
(01/28 to 04/28). It then slowly replaces all uses of the omapdrm and omapdss
platform data as explained above (05/28 to 20/28).

The next step is to remove the omapdss platform driver (for the virtual
omapdss platform device, also known as core code, not to be confused with the
omapdss_dss driver for the DSS hardware device). Patches 21/28 to 23/28 move
the useful features of the core to the omapdss_dss driver. Patch 24/28 adds
omapdrm platform device registration to the omapdss_dss driver to replace
board code, and patch 25/28 finally removes the omapdss platform driver.

Note that registering the omapdrm platform device from within the omapdss_dss
driver is a hack, but isn't worse than the current situation. Quite the
contrary, given that the omapdrm device exists for the sole purpose of
supporting the omapdrm/omapdss driver architecture, moving it out of platform
code can be considered as (slightly) cleaner. In any case, it will be easier
to refactor the code as everything is now isolated on the driver side.

Patches 26/28 and 27/28 remove the now unnecessary platform devices from
platform code, and patch 28/28 removes the now unused omapdrm platform data
structure.

The series will be annoying to merge given that it touches multiple subsystems
(ARM core, DRM, FBDEV and ALSA). The easiest solution would be to merge
everything through the DRM tree as that's where the bulk of changes lies. This
would require an ack from Bartlomiej for patch 04/28, from Peter, Liam or Mark
on patch 18/28 and from Tony on patches 26/28 and 27/28.

The patches are currently based on top of v4.11.

Laurent Pinchart (28):
  drm: omapdrm: Remove duplicate error messages when mapping memory
  drm: omapdrm: Drop support for non-DT devices
  drm: omapdrm: Remove unused dss_get_core_pdev() function
  drm: omapdrm: Remove unused default display name support
  drm: omapdrm: Infer the OMAP version from the SoC family
  drm: omapdrm: dispc: Select features based on compatible string
  drm: omapdrm: dpi: Remove platform driver
  drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type
  drm: omapdrm: dsi: Store DSI type and PLL hardware data in OF data
  drm: omapdrm: dsi: Handle pin muxing internally
  drm: omapdrm: dss: Select features based on compatible string
  drm: omapdrm: dss: Split operations out of dss_features structure
  drm: omapdrm: dss: Initialize DSS internal features at probe time
  drm: omapdrm: hdmi: Store PHY features in PHY data structure
  drm: omapdrm: hdmi: Store PHY features in HDMI transmitter drivers
  drm: omapdrm: hdmi: Store PLL hardware data in HDMI transmitter
drivers
  drm: omapdrm: hdmi: Replace OMAP SoC model check with HDMI xmit
version
  drm: omapdrm: hdmi: Pass HDMI core version as integer to HDMI audio
  drm: omapdrm: sdi: Remove platform driver
  drm: omapdrm: Don't forward set_min_bus_tput() to no-op platform code
  drm: omapdrm: Move all debugfs code from core to dss
  drm: omapdrm: Move shutdown() handler from core to dss
  drm: omapdrm: Merge the dss_features and omap_dss_features structures
  drm: omapdrm: Register omapdrm platform device in omapdss driver
  drm: omapdrm: Remove the omapdss driver
  ARM: OMAP2+: Remove unused omapdrm platform device
  ARM: OMAP2+: Don't register omapdss device for omapdrm
  drm: omapdrm: Remove omapdrm platform data

 arch/arm/mach-omap2/Makefile|   2 +-
 arch/arm/mach-omap2/display.c   | 118 +--
 arch/arm/mach-omap2/display.h   |   1 -
 arch/arm/mach-omap2/drm.c   |  53 -
 drivers/gpu/drm/omapdrm/dss/core.c  | 230 ++---
 drivers/gpu/drm/omapdrm/dss/dispc.c |  96 +++--
 dr

[PATCH v2 04/28] drm: omapdrm: Remove unused default display name support

[Laurent Pinchart]

The default display name is both unused and never set by platform data.
Remove default display name module parameter, platform data field and
runtime infrastructure.

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

- Don't remove the platform callbacks as they're still used by the
  omapfb driver.
---
 drivers/gpu/drm/omapdrm/dss/core.c  | 18 --
 drivers/gpu/drm/omapdrm/dss/omapdss.h   |  1 -
 drivers/video/fbdev/omap2/omapfb/dss/core.c |  2 --
 include/linux/platform_data/omapdss.h   |  1 -
 4 files changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 3351ce23f413..bc4fa4ec8557 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -41,20 +41,8 @@
 
 static struct {
struct platform_device *pdev;
-
-   const char *default_display_name;
 } core;
 
-static char *def_disp_name;
-module_param_named(def_disp, def_disp_name, charp, 0);
-MODULE_PARM_DESC(def_disp, "default display name");
-
-const char *omapdss_get_default_display_name(void)
-{
-   return core.default_display_name;
-}
-EXPORT_SYMBOL(omapdss_get_default_display_name);
-
 enum omapdss_version omapdss_get_version(void)
 {
struct omap_dss_board_info *pdata = core.pdev->dev.platform_data;
@@ -175,7 +163,6 @@ static void dss_disable_all_devices(void)
 
 static int __init omap_dss_probe(struct platform_device *pdev)
 {
-   struct omap_dss_board_info *pdata = pdev->dev.platform_data;
int r;
 
core.pdev = pdev;
@@ -186,11 +173,6 @@ static int __init omap_dss_probe(struct platform_device 
*pdev)
if (r)
goto err_debugfs;
 
-   if (def_disp_name)
-   core.default_display_name = def_disp_name;
-   else if (pdata->default_display_name)
-   core.default_display_name = pdata->default_display_name;
-
return 0;
 
 err_debugfs:
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 5b3b961127bd..32eae507a669 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -781,7 +781,6 @@ void omap_dss_put_device(struct omap_dss_device *dssdev);
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
int (*match)(struct omap_dss_device *dssdev, void *data));
-const char *omapdss_get_default_display_name(void);
 
 int dss_feat_get_num_mgrs(void);
 int dss_feat_get_num_ovls(void);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/core.c 
b/drivers/video/fbdev/omap2/omapfb/dss/core.c
index 29de4827589d..eecf695c16f4 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
@@ -206,8 +206,6 @@ static int __init omap_dss_probe(struct platform_device 
*pdev)
 
if (def_disp_name)
core.default_display_name = def_disp_name;
-   else if (pdata->default_display_name)
-   core.default_display_name = pdata->default_display_name;
 
register_pm_notifier(&omap_dss_pm_notif_block);
 
diff --git a/include/linux/platform_data/omapdss.h 
b/include/linux/platform_data/omapdss.h
index 679177929045..7feb011ed500 100644
--- a/include/linux/platform_data/omapdss.h
+++ b/include/linux/platform_data/omapdss.h
@@ -27,7 +27,6 @@ enum omapdss_version {
 
 /* Board specific data */
 struct omap_dss_board_info {
-   const char *default_display_name;
int (*dsi_enable_pads)(int dsi_id, unsigned int lane_mask);
void (*dsi_disable_pads)(int dsi_id, unsigned int lane_mask);
int (*set_min_bus_tput)(struct device *dev, unsigned long r);
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 05/28] drm: omapdrm: Infer the OMAP version from the SoC family

[Laurent Pinchart]

The omapdrm exposes the SoC version to userspace through an integer that
contains the OMAP model (e.g. 0x3430 for the OMAP3430). This is an
unfortunate choice of userspace API as it's both conceptually wrong
(userspace nowadays should use /sys/bus/soc/ for that purpose) and
inaccurate as many models with different features are reported with the
same version number.

The only known user of this API is the xomap X11 driver. Even if it has
been deprecated for some time we can't drop the kernel API yet. We can,
however, infer the version number from the SoC family to avoid the need
to pass the version number through platform data.

Do this, which makes the omapdrm platform data not needed anymore, and
ready to be removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 14 --
 drivers/gpu/drm/omapdrm/omap_drv.h |  1 -
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 3f2554235225..343301ed4741 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 
 #include 
@@ -753,9 +754,17 @@ static struct drm_driver omap_drm_driver = {
.patchlevel = DRIVER_PATCHLEVEL,
 };
 
+static const struct soc_device_attribute dss_soc_devices[] = {
+   { .family = "OMAP3", .data = (void *)0x3430 },
+   { .family = "OMAP4", .data = (void *)0x4430 },
+   { .family = "OMAP5", .data = (void *)0x5430 },
+   { .family = "DRA7",  .data = (void *)0x0752 },
+   { /* sentinel */ }
+};
+
 static int pdev_probe(struct platform_device *pdev)
 {
-   struct omap_drm_platform_data *pdata = pdev->dev.platform_data;
+   const struct soc_device_attribute *soc;
struct omap_drm_private *priv;
struct drm_device *ddev;
unsigned int i;
@@ -779,7 +788,8 @@ static int pdev_probe(struct platform_device *pdev)
goto err_disconnect_dssdevs;
}
 
-   priv->omaprev = pdata->omaprev;
+   soc = soc_device_match(dss_soc_devices);
+   priv->omaprev = soc ? (unsigned int)soc->data : 0;
priv->wq = alloc_ordered_workqueue("omapdrm", 0);
 
init_waitqueue_head(&priv->commit.wait);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 65977982f15f..0351d017734e 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -21,7 +21,6 @@
 #define __OMAP_DRV_H__
 
 #include 
-#include 
 #include 
 #include 
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 02/28] drm: omapdrm: Drop support for non-DT devices

[Laurent Pinchart]

All OMAP platforms use DT nowadays, drop support for non-DT devices.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/display.c | 19 ++-
 drivers/gpu/drm/omapdrm/dss/dsi.c | 93 +++
 drivers/gpu/drm/omapdrm/dss/hdmi4.c   |  8 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c   |  8 ++-
 drivers/gpu/drm/omapdrm/dss/venc.c| 16 ++
 5 files changed, 35 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index 425a5a8dff8b..cf5f6c2ad344 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -88,26 +88,17 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
int id;
 
/*
-* Note: this presumes all the displays are either using DT or non-DT,
-* which normally should be the case. This also presumes that all
-* displays either have an DT alias, or none has.
+* Note: this presumes that all displays either have an DT alias, or
+* none has.
 */
-
-   if (dssdev->dev->of_node) {
-   id = of_alias_get_id(dssdev->dev->of_node, "display");
-
-   if (id < 0)
-   id = disp_num_counter++;
-   } else {
+   id = of_alias_get_id(dssdev->dev->of_node, "display");
+   if (id < 0)
id = disp_num_counter++;
-   }
 
snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
 
/* Use 'label' property for name, if it exists */
-   if (dssdev->dev->of_node)
-   of_property_read_string(dssdev->dev->of_node, "label",
-   &dssdev->name);
+   of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name);
 
if (dssdev->name == NULL)
dssdev->name = dssdev->alias;
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 58f21f2b32c2..3edd194d6f36 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5276,12 +5276,12 @@ static int dsi_init_pll_data(struct platform_device 
*dsidev)
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct platform_device *dsidev = to_platform_device(dev);
+   const struct dsi_module_id_data *d;
u32 rev;
int r, i;
struct dsi_data *dsi;
struct resource *dsi_mem;
struct resource *res;
-   struct resource temp_res;
 
dsi = devm_kzalloc(&dsidev->dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
@@ -5311,55 +5311,17 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
dsi->te_timer.data = 0;
 #endif
 
-   res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "proto");
-   if (!res) {
-   res = platform_get_resource(dsidev, IORESOURCE_MEM, 0);
-   if (!res) {
-   DSSERR("can't get IORESOURCE_MEM DSI\n");
-   return -EINVAL;
-   }
-
-   temp_res.start = res->start;
-   temp_res.end = temp_res.start + DSI_PROTO_SZ - 1;
-   res = &temp_res;
-   }
-
-   dsi_mem = res;
-
-   dsi->proto_base = devm_ioremap_resource(&dsidev->dev, res);
+   dsi_mem = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "proto");
+   dsi->proto_base = devm_ioremap_resource(&dsidev->dev, dsi_mem);
if (!dsi->proto_base)
return -ENOMEM;
 
res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "phy");
-   if (!res) {
-   res = platform_get_resource(dsidev, IORESOURCE_MEM, 0);
-   if (!res) {
-   DSSERR("can't get IORESOURCE_MEM DSI\n");
-   return -EINVAL;
-   }
-
-   temp_res.start = res->start + DSI_PHY_OFFSET;
-   temp_res.end = temp_res.start + DSI_PHY_SZ - 1;
-   res = &temp_res;
-   }
-
dsi->phy_base = devm_ioremap_resource(&dsidev->dev, res);
if (!dsi->phy_base)
return -ENOMEM;
 
res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "pll");
-   if (!res) {
-   res = platform_get_resource(dsidev, IORESOURCE_MEM, 0);
-   if (!res) {
-   DSSERR("can't get IORESOURCE_MEM DSI\n");
-   return -EINVAL;
-   }
-
-   temp_res.start = res->start + DSI_PLL_OFFSET;
-   temp_res.end = temp_res.start + DSI_PLL_SZ - 1;
-   res = &temp_res;
-   }
-
dsi->pll_base = devm_ioremap_resource(&dsidev->dev, res);
if (!dsi->pll_base)
return -ENOMEM;
@@ -5377,31 +5339,17 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
return r;
}
 
-   if (dsidev->dev.of_node) {
-   const struct of_device_id *match;
- 

[PATCH v2 07/28] drm: omapdrm: dpi: Remove platform driver

[Laurent Pinchart]

No device is ever registered that binds with the driver, the DPI port is
handled manually. Remove the DPI platform driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c |  6 ---
 drivers/gpu/drm/omapdrm/dss/dpi.c  | 93 --
 drivers/gpu/drm/omapdrm/dss/dss.h  |  3 --
 3 files changed, 102 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index bc4fa4ec8557..35def6fd6acd 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -208,9 +208,6 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata = 
{
 #ifdef CONFIG_OMAP2_DSS_DSI
dsi_init_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_DPI
-   dpi_init_platform_driver,
-#endif
 #ifdef CONFIG_OMAP2_DSS_SDI
sdi_init_platform_driver,
 #endif
@@ -244,9 +241,6 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
 #ifdef CONFIG_OMAP2_DSS_SDI
sdi_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_DPI
-   dpi_uninit_platform_driver,
-#endif
 #ifdef CONFIG_OMAP2_DSS_DSI
dsi_uninit_platform_driver,
 #endif
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index e75162d26ac0..3d87f3af72bb 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "omapdss.h"
 #include "dss.h"
@@ -61,12 +60,6 @@ static struct dpi_data *dpi_get_data_from_dssdev(struct 
omap_dss_device *dssdev)
return container_of(dssdev, struct dpi_data, output);
 }
 
-/* only used in non-DT mode */
-static struct dpi_data *dpi_get_data_from_pdev(struct platform_device *pdev)
-{
-   return dev_get_drvdata(&pdev->dev);
-}
-
 static enum dss_clk_source dpi_get_clk_src(enum omap_channel channel)
 {
/*
@@ -714,30 +707,6 @@ static const struct omapdss_dpi_ops dpi_ops = {
.set_data_lines = dpi_set_data_lines,
 };
 
-static void dpi_init_output(struct platform_device *pdev)
-{
-   struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
-   struct omap_dss_device *out = &dpi->output;
-
-   out->dev = &pdev->dev;
-   out->id = OMAP_DSS_OUTPUT_DPI;
-   out->output_type = OMAP_DISPLAY_TYPE_DPI;
-   out->name = "dpi.0";
-   out->dispc_channel = dpi_get_channel(0);
-   out->ops.dpi = &dpi_ops;
-   out->owner = THIS_MODULE;
-
-   omapdss_register_output(out);
-}
-
-static void dpi_uninit_output(struct platform_device *pdev)
-{
-   struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
-   struct omap_dss_device *out = &dpi->output;
-
-   omapdss_unregister_output(out);
-}
-
 static void dpi_init_output_port(struct platform_device *pdev,
struct device_node *port)
 {
@@ -782,68 +751,6 @@ static void dpi_uninit_output_port(struct device_node 
*port)
omapdss_unregister_output(out);
 }
 
-static int dpi_bind(struct device *dev, struct device *master, void *data)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpi_data *dpi;
-
-   dpi = devm_kzalloc(&pdev->dev, sizeof(*dpi), GFP_KERNEL);
-   if (!dpi)
-   return -ENOMEM;
-
-   dpi->pdev = pdev;
-
-   dev_set_drvdata(&pdev->dev, dpi);
-
-   mutex_init(&dpi->lock);
-
-   dpi_init_output(pdev);
-
-   return 0;
-}
-
-static void dpi_unbind(struct device *dev, struct device *master, void *data)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-
-   dpi_uninit_output(pdev);
-}
-
-static const struct component_ops dpi_component_ops = {
-   .bind   = dpi_bind,
-   .unbind = dpi_unbind,
-};
-
-static int dpi_probe(struct platform_device *pdev)
-{
-   return component_add(&pdev->dev, &dpi_component_ops);
-}
-
-static int dpi_remove(struct platform_device *pdev)
-{
-   component_del(&pdev->dev, &dpi_component_ops);
-   return 0;
-}
-
-static struct platform_driver omap_dpi_driver = {
-   .probe  = dpi_probe,
-   .remove = dpi_remove,
-   .driver = {
-   .name   = "omapdss_dpi",
-   .suppress_bind_attrs = true,
-   },
-};
-
-int __init dpi_init_platform_driver(void)
-{
-   return platform_driver_register(&omap_dpi_driver);
-}
-
-void dpi_uninit_platform_driver(void)
-{
-   platform_driver_unregister(&omap_dpi_driver);
-}
-
 int dpi_init_port(struct platform_device *pdev, struct device_node *port)
 {
struct dpi_data *dpi;
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index dfb10c9b4102..983838b4f45b 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -329,9 +329,6 @@ static inline u8 dsi_get_pixel_size(enum 
omap_dss_dsi_pixel_format fmt)
 #endif
 
 /* DPI */
-int dpi_init_platform_driver(void) __init;
-void dpi_uninit_platform_driver(void);
-
 #ifdef CONFIG_OMAP2_DSS_DPI
 int dpi_init_port(struct

[PATCH v2 12/28] drm: omapdrm: dss: Split operations out of dss_features structure

[Laurent Pinchart]

Move the two function pointers to a new dss_ops structure. This will
allow merging the dss_features and omap_dss_features structures without
having to expose the DPI source selection and LCD clock muxing functions
in header files.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 50 +++
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 5739d0d6216f..7546ba8ab955 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -70,6 +70,12 @@ struct dss_reg {
 #define REG_FLD_MOD(idx, val, start, end) \
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
 
+struct dss_ops {
+   int (*dpi_select_source)(int port, enum omap_channel channel);
+   int (*select_lcd_source)(enum omap_channel channel,
+   enum dss_clk_source clk_src);
+};
+
 struct dss_features {
enum dss_device_type type;
u8 fck_div_max;
@@ -77,9 +83,7 @@ struct dss_features {
const char *parent_clk_name;
const enum omap_display_type *ports;
int num_ports;
-   int (*dpi_select_source)(int port, enum omap_channel channel);
-   int (*select_lcd_source)(enum omap_channel channel,
-   enum dss_clk_source clk_src);
+   const struct dss_ops *ops;
 };
 
 static struct {
@@ -586,7 +590,7 @@ void dss_select_lcd_clk_source(enum omap_channel channel,
return;
}
 
-   r = dss.feat->select_lcd_source(channel, clk_src);
+   r = dss.feat->ops->select_lcd_source(channel, clk_src);
if (r)
return;
 
@@ -833,7 +837,7 @@ static int dss_dpi_select_source_dra7xx(int port, enum 
omap_channel channel)
 
 int dss_dpi_select_source(int port, enum omap_channel channel)
 {
-   return dss.feat->dpi_select_source(port, channel);
+   return dss.feat->ops->dpi_select_source(port, channel);
 }
 
 static int dss_get_clocks(void)
@@ -903,6 +907,25 @@ void dss_debug_dump_clocks(struct seq_file *s)
 #endif
 
 
+static const struct dss_ops dss_ops_omap2_omap3 = {
+   .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+};
+
+static const struct dss_ops dss_ops_omap4 = {
+   .dpi_select_source = &dss_dpi_select_source_omap4,
+   .select_lcd_source = &dss_lcd_clk_mux_omap4,
+};
+
+static const struct dss_ops dss_ops_omap5 = {
+   .dpi_select_source = &dss_dpi_select_source_omap5,
+   .select_lcd_source = &dss_lcd_clk_mux_omap5,
+};
+
+static const struct dss_ops dss_ops_dra7 = {
+   .dpi_select_source = &dss_dpi_select_source_dra7xx,
+   .select_lcd_source = &dss_lcd_clk_mux_dra7,
+};
+
 static const enum omap_display_type omap2plus_ports[] = {
OMAP_DISPLAY_TYPE_DPI,
 };
@@ -927,9 +950,9 @@ static const struct dss_features omap24xx_dss_feats = {
.fck_div_max=   6,
.dss_fck_multiplier =   2,
.parent_clk_name=   "core_ck",
-   .dpi_select_source  =   &dss_dpi_select_source_omap2_omap3,
.ports  =   omap2plus_ports,
.num_ports  =   ARRAY_SIZE(omap2plus_ports),
+   .ops=   &dss_ops_omap2_omap3,
 };
 
 static const struct dss_features omap34xx_dss_feats = {
@@ -937,9 +960,9 @@ static const struct dss_features omap34xx_dss_feats = {
.fck_div_max=   16,
.dss_fck_multiplier =   2,
.parent_clk_name=   "dpll4_ck",
-   .dpi_select_source  =   &dss_dpi_select_source_omap2_omap3,
.ports  =   omap34xx_ports,
.num_ports  =   ARRAY_SIZE(omap34xx_ports),
+   .ops=   &dss_ops_omap2_omap3,
 };
 
 static const struct dss_features omap3630_dss_feats = {
@@ -947,9 +970,9 @@ static const struct dss_features omap3630_dss_feats = {
.fck_div_max=   32,
.dss_fck_multiplier =   1,
.parent_clk_name=   "dpll4_ck",
-   .dpi_select_source  =   &dss_dpi_select_source_omap2_omap3,
.ports  =   omap2plus_ports,
.num_ports  =   ARRAY_SIZE(omap2plus_ports),
+   .ops=   &dss_ops_omap2_omap3,
 };
 
 static const struct dss_features omap44xx_dss_feats = {
@@ -957,10 +980,9 @@ static const struct dss_features omap44xx_dss_feats = {
.fck_div_max=   32,
.dss_fck_multiplier =   1,
.parent_clk_name=   "dpll_per_x2_ck",
-   .dpi_select_source  =   &dss_dpi_select_source_omap4,
.ports  =   omap2plus_ports,
.num_ports  =   ARRAY_SIZE(omap2plus_ports),
-   .select_lcd_source  =   &dss_lcd_clk_mux_omap4,
+   .ops=   &dss_ops_dra7,
 };
 
 static const

[PATCH v2 13/28] drm: omapdrm: dss: Initialize DSS internal features at probe time

[Laurent Pinchart]

The DSS internal features are derived from the platform device
compatible string which is available at probe time. Don't delay
initialization until bind time. This prepares for the merge of the two
DSS features structures that will be needed before the DSS is bound.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 7546ba8ab955..4fdb77dd90b8 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1183,23 +1183,10 @@ static const struct soc_device_attribute 
dss_soc_devices[] = {
 static int dss_bind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
-   const struct soc_device_attribute *soc;
struct resource *dss_mem;
u32 rev;
int r;
 
-   dss.pdev = pdev;
-
-   /*
-* The various OMAP3-based SoCs can be told apart from the compatible
-* string, use SoC device matching.
-*/
-   soc = soc_device_match(dss_soc_devices);
-   if (soc)
-   dss.feat = soc->data;
-   else
-   dss.feat = of_match_device(dss_of_match, &pdev->dev)->data;
-
dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
dss.base = devm_ioremap_resource(&pdev->dev, dss_mem);
if (!dss.base)
@@ -1331,9 +1318,22 @@ static int dss_add_child_component(struct device *dev, 
void *data)
 
 static int dss_probe(struct platform_device *pdev)
 {
+   const struct soc_device_attribute *soc;
struct component_match *match = NULL;
int r;
 
+   dss.pdev = pdev;
+
+   /*
+* The various OMAP3-based SoCs can be told apart from the compatible
+* string, use SoC device matching.
+*/
+   soc = soc_device_match(dss_soc_devices);
+   if (soc)
+   dss.feat = soc->data;
+   else
+   dss.feat = of_match_device(dss_of_match, &pdev->dev)->data;
+
/* add all the child devices as components */
device_for_each_child(&pdev->dev, &match, dss_add_child_component);
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

[Laurent Pinchart]

The DPI code only needs to differentiate between major OMAP revisions,
which can be obtained from the DSS compatible string. Replace the OMAP
SoC model checks to prepare for removal of the OMAP SoC version platform
data.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dpi.c | 59 +--
 drivers/gpu/drm/omapdrm/dss/dss.c | 10 ++-
 drivers/gpu/drm/omapdrm/dss/dss.h | 13 +++--
 3 files changed, 45 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 3d87f3af72bb..b5cb23c167db 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -39,6 +39,7 @@
 
 struct dpi_data {
struct platform_device *pdev;
+   enum dss_device_type type;
 
struct regulator *vdds_dsi_reg;
enum dss_clk_source clk_src;
@@ -60,25 +61,21 @@ static struct dpi_data *dpi_get_data_from_dssdev(struct 
omap_dss_device *dssdev)
return container_of(dssdev, struct dpi_data, output);
 }
 
-static enum dss_clk_source dpi_get_clk_src(enum omap_channel channel)
+static enum dss_clk_source dpi_get_clk_src(struct dpi_data *dpi)
 {
+   enum omap_channel channel = dpi->output.dispc_channel;
+
/*
 * XXX we can't currently use DSI PLL for DPI with OMAP3, as the DSI PLL
 * would also be used for DISPC fclk. Meaning, when the DPI output is
 * disabled, DISPC clock will be disabled, and TV out will stop.
 */
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP24xx:
-   case OMAPDSS_VER_OMAP34xx_ES1:
-   case OMAPDSS_VER_OMAP34xx_ES3:
-   case OMAPDSS_VER_OMAP3630:
-   case OMAPDSS_VER_AM35xx:
-   case OMAPDSS_VER_AM43xx:
+   switch (dpi->type) {
+   case DSS_TYPE_OMAP2:
+   case DSS_TYPE_OMAP3:
return DSS_CLK_SRC_FCK;
 
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
+   case DSS_TYPE_OMAP4:
switch (channel) {
case OMAP_DSS_CHANNEL_LCD:
return DSS_CLK_SRC_PLL1_1;
@@ -88,7 +85,7 @@ static enum dss_clk_source dpi_get_clk_src(enum omap_channel 
channel)
return DSS_CLK_SRC_FCK;
}
 
-   case OMAPDSS_VER_OMAP5:
+   case DSS_TYPE_OMAP5:
switch (channel) {
case OMAP_DSS_CHANNEL_LCD:
return DSS_CLK_SRC_PLL1_1;
@@ -99,7 +96,7 @@ static enum dss_clk_source dpi_get_clk_src(enum omap_channel 
channel)
return DSS_CLK_SRC_FCK;
}
 
-   case OMAPDSS_VER_DRA7xx:
+   case DSS_TYPE_DRA7:
switch (channel) {
case OMAP_DSS_CHANNEL_LCD:
return DSS_CLK_SRC_PLL1_1;
@@ -593,7 +590,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
if (dpi->pll)
return;
 
-   dpi->clk_src = dpi_get_clk_src(dpi->output.dispc_channel);
+   dpi->clk_src = dpi_get_clk_src(dpi);
 
pll = dss_pll_find_by_src(dpi->clk_src);
if (!pll)
@@ -613,18 +610,14 @@ static void dpi_init_pll(struct dpi_data *dpi)
  * the channel in some more dynamic manner, or get the channel as a user
  * parameter.
  */
-static enum omap_channel dpi_get_channel(int port_num)
+static enum omap_channel dpi_get_channel(struct dpi_data *dpi, int port_num)
 {
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP24xx:
-   case OMAPDSS_VER_OMAP34xx_ES1:
-   case OMAPDSS_VER_OMAP34xx_ES3:
-   case OMAPDSS_VER_OMAP3630:
-   case OMAPDSS_VER_AM35xx:
-   case OMAPDSS_VER_AM43xx:
+   switch (dpi->type) {
+   case DSS_TYPE_OMAP2:
+   case DSS_TYPE_OMAP3:
return OMAP_DSS_CHANNEL_LCD;
 
-   case OMAPDSS_VER_DRA7xx:
+   case DSS_TYPE_DRA7:
switch (port_num) {
case 2:
return OMAP_DSS_CHANNEL_LCD3;
@@ -635,12 +628,10 @@ static enum omap_channel dpi_get_channel(int port_num)
return OMAP_DSS_CHANNEL_LCD;
}
 
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
+   case DSS_TYPE_OMAP4:
return OMAP_DSS_CHANNEL_LCD2;
 
-   case OMAPDSS_VER_OMAP5:
+   case DSS_TYPE_OMAP5:
return OMAP_DSS_CHANNEL_LCD3;
 
default:
@@ -707,10 +698,8 @@ static const struct omapdss_dpi_ops dpi_ops = {
.set_data_lines = dpi_set_data_lines,
 };
 
-static void dpi_init_output_port(struct platform_device *pdev,
-   struct device_node *port)
+static void dpi_init_output_port(struct dpi_data *dpi, struct device_node 
*port)
 {
-   struct dpi_data *dpi = port->data;
struct omap_dss_device *out = &dpi->output;
int r;
u32 port_num;
@@ -732,10 +721,10 @@ static void dpi_init_output_port(struct platform_device 

[PATCH v2 06/28] drm: omapdrm: dispc: Select features based on compatible string

[Laurent Pinchart]

Use the compatible string instead of the OMAP SoC revision to determine
device features. On OMAP34xx the features depend on the ES revision that
can not be determined from the compatible string. Use soc_device_match()
in that case.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 84 +++--
 1 file changed, 24 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 820b45a94e2f..66982251d63d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -39,7 +39,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "omapdss.h"
 #include "dss.h"
@@ -4093,54 +4095,6 @@ static const struct dispc_features omap54xx_dispc_feats 
= {
.has_gamma_i734_bug =   true,
 };
 
-static int dispc_init_features(struct platform_device *pdev)
-{
-   const struct dispc_features *src;
-   struct dispc_features *dst;
-
-   dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(&pdev->dev, "Failed to allocate DISPC Features\n");
-   return -ENOMEM;
-   }
-
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP24xx:
-   src = &omap24xx_dispc_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP34xx_ES1:
-   src = &omap34xx_rev1_0_dispc_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP34xx_ES3:
-   case OMAPDSS_VER_OMAP3630:
-   case OMAPDSS_VER_AM35xx:
-   case OMAPDSS_VER_AM43xx:
-   src = &omap34xx_rev3_0_dispc_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
-   src = &omap44xx_dispc_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP5:
-   case OMAPDSS_VER_DRA7xx:
-   src = &omap54xx_dispc_feats;
-   break;
-
-   default:
-   return -ENODEV;
-   }
-
-   memcpy(dst, src, sizeof(*dst));
-   dispc.feat = dst;
-
-   return 0;
-}
-
 static irqreturn_t dispc_irq_handler(int irq, void *arg)
 {
if (!dispc.is_enabled)
@@ -4342,6 +4296,20 @@ static void dispc_errata_i734_wa(void)
 }
 
 /* DISPC HW IP initialisation */
+static const struct of_device_id dispc_of_match[] = {
+   { .compatible = "ti,omap2-dispc", .data = &omap24xx_dispc_feats },
+   { .compatible = "ti,omap3-dispc", .data = &omap34xx_rev3_0_dispc_feats 
},
+   { .compatible = "ti,omap4-dispc", .data = &omap44xx_dispc_feats },
+   { .compatible = "ti,omap5-dispc", .data = &omap54xx_dispc_feats },
+   { .compatible = "ti,dra7-dispc",  .data = &omap54xx_dispc_feats },
+   {},
+};
+
+static const struct soc_device_attribute dispc_soc_devices[] = {
+   { .machine = "OMAP3430/3530", .revision = "ES[12].?", },
+   { /* sentinel */ }
+};
+
 static int dispc_bind(struct device *dev, struct device *master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -4354,9 +4322,14 @@ static int dispc_bind(struct device *dev, struct device 
*master, void *data)
 
spin_lock_init(&dispc.control_lock);
 
-   r = dispc_init_features(dispc.pdev);
-   if (r)
-   return r;
+   /*
+* The OMAP34xx ES1.x and ES2.x can't be identified through the
+* compatible string, use SoC device matching.
+*/
+   if (soc_device_match(dispc_soc_devices))
+   dispc.feat = &omap34xx_rev1_0_dispc_feats;
+   else
+   dispc.feat = of_match_device(dispc_of_match, &pdev->dev)->data;
 
r = dispc_errata_i734_wa_init();
if (r)
@@ -4481,15 +4454,6 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
 };
 
-static const struct of_device_id dispc_of_match[] = {
-   { .compatible = "ti,omap2-dispc", },
-   { .compatible = "ti,omap3-dispc", },
-   { .compatible = "ti,omap4-dispc", },
-   { .compatible = "ti,omap5-dispc", },
-   { .compatible = "ti,dra7-dispc", },
-   {},
-};
-
 static struct platform_driver omap_dispchw_driver = {
.probe  = dispc_probe,
.remove = dispc_remove,
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 19/28] drm: omapdrm: sdi: Remove platform driver

[Laurent Pinchart]

No device is ever registered that binds with the driver, the SDI port is
handled manually. Remove the SDI platform driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c |  6 -
 drivers/gpu/drm/omapdrm/dss/dss.h  |  3 ---
 drivers/gpu/drm/omapdrm/dss/sdi.c  | 54 --
 3 files changed, 63 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 524ecdd138f4..7579de042d32 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -188,9 +188,6 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata = 
{
 #ifdef CONFIG_OMAP2_DSS_DSI
dsi_init_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_SDI
-   sdi_init_platform_driver,
-#endif
 #ifdef CONFIG_OMAP2_DSS_RFBI
rfbi_init_platform_driver,
 #endif
@@ -218,9 +215,6 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
 #ifdef CONFIG_OMAP2_DSS_RFBI
rfbi_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_SDI
-   sdi_uninit_platform_driver,
-#endif
 #ifdef CONFIG_OMAP2_DSS_DSI
dsi_uninit_platform_driver,
 #endif
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index bc75c5f8a5fe..453b4ba0bf18 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -293,9 +293,6 @@ bool dss_div_calc(unsigned long pck, unsigned long fck_min,
dss_div_calc_func func, void *data);
 
 /* SDI */
-int sdi_init_platform_driver(void) __init;
-void sdi_uninit_platform_driver(void);
-
 #ifdef CONFIG_OMAP2_DSS_SDI
 int sdi_init_port(struct platform_device *pdev, struct device_node *port);
 void sdi_uninit_port(struct device_node *port);
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c 
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index b3bda2d3c08d..35c809d85b7a 100644
--- a/drivers/gpu/drm/omapdrm/dss/sdi.c
+++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "omapdss.h"
 #include "dss.h"
@@ -355,59 +354,6 @@ static void sdi_uninit_output(struct platform_device *pdev)
omapdss_unregister_output(out);
 }
 
-static int sdi_bind(struct device *dev, struct device *master, void *data)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-
-   sdi.pdev = pdev;
-
-   sdi_init_output(pdev);
-
-   return 0;
-}
-
-static void sdi_unbind(struct device *dev, struct device *master, void *data)
-{
-   struct platform_device *pdev = to_platform_device(dev);
-
-   sdi_uninit_output(pdev);
-}
-
-static const struct component_ops sdi_component_ops = {
-   .bind   = sdi_bind,
-   .unbind = sdi_unbind,
-};
-
-static int sdi_probe(struct platform_device *pdev)
-{
-   return component_add(&pdev->dev, &sdi_component_ops);
-}
-
-static int sdi_remove(struct platform_device *pdev)
-{
-   component_del(&pdev->dev, &sdi_component_ops);
-   return 0;
-}
-
-static struct platform_driver omap_sdi_driver = {
-   .probe  = sdi_probe,
-   .remove = sdi_remove,
-   .driver = {
-   .name   = "omapdss_sdi",
-   .suppress_bind_attrs = true,
-   },
-};
-
-int __init sdi_init_platform_driver(void)
-{
-   return platform_driver_register(&omap_sdi_driver);
-}
-
-void sdi_uninit_platform_driver(void)
-{
-   platform_driver_unregister(&omap_sdi_driver);
-}
-
 int sdi_init_port(struct platform_device *pdev, struct device_node *port)
 {
struct device_node *ep;
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 14/28] drm: omapdrm: hdmi: Store PHY features in PHY data structure

[Laurent Pinchart]

PHY features are stored in a global variable, while they should be
properties of the PHY object. As existing OMAP platforms have a single
HDMI PHY this doesn't cause any issue, but doesn't follow the driver
model.

Move the PHY features to the HDMI PHY data structure to follow the
driver model and pave the road for multiple HDMI PHYs support.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/hdmi.h |  7 +++
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c | 23 ---
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index fb6cccd02374..851e5e6f6820 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -245,9 +245,16 @@ struct hdmi_pll_data {
struct hdmi_wp_data *wp;
 };
 
+struct hdmi_phy_features {
+   bool bist_ctrl;
+   bool ldo_voltage;
+   unsigned long max_phy;
+};
+
 struct hdmi_phy_data {
void __iomem *base;
 
+   const struct hdmi_phy_features *features;
u8 lane_function[4];
u8 lane_polarity[4];
 };
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
index fb5e4c724b4b..bff1ea11ed2f 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
@@ -19,14 +19,6 @@
 #include "dss.h"
 #include "hdmi.h"
 
-struct hdmi_phy_features {
-   bool bist_ctrl;
-   bool ldo_voltage;
-   unsigned long max_phy;
-};
-
-static const struct hdmi_phy_features *phy_feat;
-
 void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file *s)
 {
 #define DUMPPHY(r) seq_printf(s, "%-35s %08x\n", #r,\
@@ -36,7 +28,7 @@ void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file 
*s)
DUMPPHY(HDMI_TXPHY_DIGITAL_CTRL);
DUMPPHY(HDMI_TXPHY_POWER_CTRL);
DUMPPHY(HDMI_TXPHY_PAD_CFG_CTRL);
-   if (phy_feat->bist_ctrl)
+   if (phy->features->bist_ctrl)
DUMPPHY(HDMI_TXPHY_BIST_CONTROL);
 }
 
@@ -146,7 +138,7 @@ int hdmi_phy_configure(struct hdmi_phy_data *phy, unsigned 
long hfbitclk,
 * In OMAP5+, the HFBITCLK must be divided by 2 before issuing the
 * HDMI_PHYPWRCMD_LDOON command.
*/
-   if (phy_feat->bist_ctrl)
+   if (phy->features->bist_ctrl)
REG_FLD_MOD(phy->base, HDMI_TXPHY_BIST_CONTROL, 1, 11, 11);
 
/*
@@ -155,7 +147,7 @@ int hdmi_phy_configure(struct hdmi_phy_data *phy, unsigned 
long hfbitclk,
 */
if (hfbitclk != lfbitclk)
freqout = 0;
-   else if (hfbitclk / 10 < phy_feat->max_phy)
+   else if (hfbitclk / 10 < phy->features->max_phy)
freqout = 1;
else
freqout = 2;
@@ -170,7 +162,7 @@ int hdmi_phy_configure(struct hdmi_phy_data *phy, unsigned 
long hfbitclk,
hdmi_write_reg(phy->base, HDMI_TXPHY_DIGITAL_CTRL, 0xF000);
 
/* Setup max LDO voltage */
-   if (phy_feat->ldo_voltage)
+   if (phy->features->ldo_voltage)
REG_FLD_MOD(phy->base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
 
hdmi_phy_configure_lanes(phy);
@@ -190,7 +182,8 @@ static const struct hdmi_phy_features omap54xx_phy_feats = {
.max_phy=   18600,
 };
 
-static int hdmi_phy_init_features(struct platform_device *pdev)
+static int hdmi_phy_init_features(struct platform_device *pdev,
+ struct hdmi_phy_data *phy)
 {
struct hdmi_phy_features *dst;
const struct hdmi_phy_features *src;
@@ -218,7 +211,7 @@ static int hdmi_phy_init_features(struct platform_device 
*pdev)
}
 
memcpy(dst, src, sizeof(*dst));
-   phy_feat = dst;
+   phy->features = dst;
 
return 0;
 }
@@ -228,7 +221,7 @@ int hdmi_phy_init(struct platform_device *pdev, struct 
hdmi_phy_data *phy)
int r;
struct resource *res;
 
-   r = hdmi_phy_init_features(pdev);
+   r = hdmi_phy_init_features(pdev, phy);
if (r)
return r;
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 11/28] drm: omapdrm: dss: Select features based on compatible string

[Laurent Pinchart]

Use the compatible string instead of the OMAP SoC revision to determine
device features. The various OMAP3-based SoCs can be told apart from the
compatible string, use soc_device_match() to tell them apart.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 97 ---
 1 file changed, 29 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 6196f3ab73b7..5739d0d6216f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -38,9 +38,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include "omapdss.h"
 #include "dss.h"
@@ -993,60 +995,6 @@ static const struct dss_features dra7xx_dss_feats = {
.select_lcd_source  =   &dss_lcd_clk_mux_dra7,
 };
 
-static int dss_init_features(struct platform_device *pdev)
-{
-   const struct dss_features *src;
-   struct dss_features *dst;
-
-   dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(&pdev->dev, "Failed to allocate local DSS Features\n");
-   return -ENOMEM;
-   }
-
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP24xx:
-   src = &omap24xx_dss_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP34xx_ES1:
-   case OMAPDSS_VER_OMAP34xx_ES3:
-   case OMAPDSS_VER_AM35xx:
-   src = &omap34xx_dss_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP3630:
-   src = &omap3630_dss_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
-   src = &omap44xx_dss_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP5:
-   src = &omap54xx_dss_feats;
-   break;
-
-   case OMAPDSS_VER_AM43xx:
-   src = &am43xx_dss_feats;
-   break;
-
-   case OMAPDSS_VER_DRA7xx:
-   src = &dra7xx_dss_feats;
-   break;
-
-   default:
-   return -ENODEV;
-   }
-
-   memcpy(dst, src, sizeof(*dst));
-   dss.feat = dst;
-
-   return 0;
-}
-
 static int dss_init_ports(struct platform_device *pdev)
 {
struct device_node *parent = pdev->dev.of_node;
@@ -1195,18 +1143,42 @@ static int dss_video_pll_probe(struct platform_device 
*pdev)
 }
 
 /* DSS HW IP initialisation */
+static const struct of_device_id dss_of_match[] = {
+   { .compatible = "ti,omap2-dss", .data = &omap24xx_dss_feats },
+   { .compatible = "ti,omap3-dss", .data = &omap3630_dss_feats },
+   { .compatible = "ti,omap4-dss", .data = &omap44xx_dss_feats },
+   { .compatible = "ti,omap5-dss", .data = &omap54xx_dss_feats },
+   { .compatible = "ti,dra7-dss",  .data = &dra7xx_dss_feats },
+   {},
+};
+MODULE_DEVICE_TABLE(of, dss_of_match);
+
+static const struct soc_device_attribute dss_soc_devices[] = {
+   { .machine = "OMAP3430/3530", .data = &omap34xx_dss_feats },
+   { .machine = "AM35??",.data = &omap34xx_dss_feats },
+   { .family  = "AM43xx",.data = &am43xx_dss_feats },
+   { /* sentinel */ }
+};
+
 static int dss_bind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
+   const struct soc_device_attribute *soc;
struct resource *dss_mem;
u32 rev;
int r;
 
dss.pdev = pdev;
 
-   r = dss_init_features(dss.pdev);
-   if (r)
-   return r;
+   /*
+* The various OMAP3-based SoCs can be told apart from the compatible
+* string, use SoC device matching.
+*/
+   soc = soc_device_match(dss_soc_devices);
+   if (soc)
+   dss.feat = soc->data;
+   else
+   dss.feat = of_match_device(dss_of_match, &pdev->dev)->data;
 
dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
dss.base = devm_ioremap_resource(&pdev->dev, dss_mem);
@@ -1394,17 +1366,6 @@ static const struct dev_pm_ops dss_pm_ops = {
.runtime_resume = dss_runtime_resume,
 };
 
-static const struct of_device_id dss_of_match[] = {
-   { .compatible = "ti,omap2-dss", },
-   { .compatible = "ti,omap3-dss", },
-   { .compatible = "ti,omap4-dss", },
-   { .compatible = "ti,omap5-dss", },
-   { .compatible = "ti,dra7-dss", },
-   {},
-};
-
-MODULE_DEVICE_TABLE(of, dss_of_match);
-
 static struct platform_driver omap_dsshw_driver = {
.probe  = dss_probe,
.remove = dss_remove,
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 18/28] drm: omapdrm: hdmi: Pass HDMI core version as integer to HDMI audio

[Laurent Pinchart]

The HDMI audio driver only needs to know which generation of HDMI
transmitter it deals with, not the detailed SoC model. Pass the version
number as an integer to prepare for removal of the OMAP SoC version from
the omapdrm driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +-
 include/sound/omap-hdmi-audio.h | 2 +-
 sound/soc/omap/omap-hdmi-audio.c| 9 +++--
 4 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index a1e3f33a06f0..79bbe40a2f58 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -667,7 +667,7 @@ static int hdmi_audio_register(struct device *dev)
 {
struct omap_hdmi_audio_pdata pdata = {
.dev = dev,
-   .dss_version = omapdss_get_version(),
+   .version = 4,
.audio_dma_addr = hdmi_wp_get_audio_dma_addr(&hdmi.wp),
.ops = &hdmi_audio_ops,
};
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 67accbcf70bc..a6e88a78b8dd 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -694,7 +694,7 @@ static int hdmi_audio_register(struct device *dev)
 {
struct omap_hdmi_audio_pdata pdata = {
.dev = dev,
-   .dss_version = omapdss_get_version(),
+   .version = 5,
.audio_dma_addr = hdmi_wp_get_audio_dma_addr(&hdmi.wp),
.ops = &hdmi_audio_ops,
};
diff --git a/include/sound/omap-hdmi-audio.h b/include/sound/omap-hdmi-audio.h
index 1df2ff61a4dd..0e495ed8872e 100644
--- a/include/sound/omap-hdmi-audio.h
+++ b/include/sound/omap-hdmi-audio.h
@@ -39,7 +39,7 @@ struct omap_hdmi_audio_ops {
 /* HDMI audio initalization data */
 struct omap_hdmi_audio_pdata {
struct device *dev;
-   enum omapdss_version dss_version;
+   unsigned int version;
phys_addr_t audio_dma_addr;
 
const struct omap_hdmi_audio_ops *ops;
diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c
index 888133f9e65d..3e9cc4842a1d 100644
--- a/sound/soc/omap/omap-hdmi-audio.c
+++ b/sound/soc/omap/omap-hdmi-audio.c
@@ -337,14 +337,11 @@ static int omap_hdmi_audio_probe(struct platform_device 
*pdev)
ad->dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
mutex_init(&ad->current_stream_lock);
 
-   switch (ha->dss_version) {
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
+   switch (ha->version) {
+   case 4:
dai_drv = &omap4_hdmi_dai;
break;
-   case OMAPDSS_VER_OMAP5:
-   case OMAPDSS_VER_DRA7xx:
+   case 5:
dai_drv = &omap5_hdmi_dai;
break;
default:
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 21/28] drm: omapdrm: Move all debugfs code from core to dss

[Laurent Pinchart]

debugfs code is spread between the core and dss drivers. In preparation
for removal of the core driver, move it all to the dss driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c | 80 --
 drivers/gpu/drm/omapdrm/dss/dss.c  | 77 ++--
 drivers/gpu/drm/omapdrm/dss/dss.h  | 13 +--
 3 files changed, 84 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index ff6357df0588..dc2147ec78f6 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -27,8 +27,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -50,72 +48,6 @@ enum omapdss_version omapdss_get_version(void)
 }
 EXPORT_SYMBOL(omapdss_get_version);
 
-#if defined(CONFIG_OMAP2_DSS_DEBUGFS)
-static int dss_debug_show(struct seq_file *s, void *unused)
-{
-   void (*func)(struct seq_file *) = s->private;
-   func(s);
-   return 0;
-}
-
-static int dss_debug_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, dss_debug_show, inode->i_private);
-}
-
-static const struct file_operations dss_debug_fops = {
-   .open   = dss_debug_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
-
-static struct dentry *dss_debugfs_dir;
-
-static int dss_initialize_debugfs(void)
-{
-   dss_debugfs_dir = debugfs_create_dir("omapdss", NULL);
-   if (IS_ERR(dss_debugfs_dir)) {
-   int err = PTR_ERR(dss_debugfs_dir);
-   dss_debugfs_dir = NULL;
-   return err;
-   }
-
-   debugfs_create_file("clk", S_IRUGO, dss_debugfs_dir,
-   &dss_debug_dump_clocks, &dss_debug_fops);
-
-   return 0;
-}
-
-static void dss_uninitialize_debugfs(void)
-{
-   if (dss_debugfs_dir)
-   debugfs_remove_recursive(dss_debugfs_dir);
-}
-
-int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
-{
-   struct dentry *d;
-
-   d = debugfs_create_file(name, S_IRUGO, dss_debugfs_dir,
-   write, &dss_debug_fops);
-
-   return PTR_ERR_OR_ZERO(d);
-}
-#else /* CONFIG_OMAP2_DSS_DEBUGFS */
-static inline int dss_initialize_debugfs(void)
-{
-   return 0;
-}
-static inline void dss_uninitialize_debugfs(void)
-{
-}
-int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
-{
-   return 0;
-}
-#endif /* CONFIG_OMAP2_DSS_DEBUGFS */
-
 /* PLATFORM DEVICE */
 
 static void dss_disable_all_devices(void)
@@ -133,27 +65,15 @@ static void dss_disable_all_devices(void)
 
 static int __init omap_dss_probe(struct platform_device *pdev)
 {
-   int r;
-
core.pdev = pdev;
 
dss_features_init(omapdss_get_version());
 
-   r = dss_initialize_debugfs();
-   if (r)
-   goto err_debugfs;
-
return 0;
-
-err_debugfs:
-
-   return r;
 }
 
 static int omap_dss_remove(struct platform_device *pdev)
 {
-   dss_uninitialize_debugfs();
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 4fdb77dd90b8..618fd4dcbd5a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -22,6 +22,7 @@
 
 #define DSS_SUBSYS_NAME "DSS"
 
+#include 
 #include 
 #include 
 #include 
@@ -896,7 +897,7 @@ void dss_runtime_put(void)
 
 /* DEBUGFS */
 #if defined(CONFIG_OMAP2_DSS_DEBUGFS)
-void dss_debug_dump_clocks(struct seq_file *s)
+static void dss_debug_dump_clocks(struct seq_file *s)
 {
dss_dump_clocks(s);
dispc_dump_clocks(s);
@@ -904,8 +905,69 @@ void dss_debug_dump_clocks(struct seq_file *s)
dsi_dump_clocks(s);
 #endif
 }
-#endif
 
+static int dss_debug_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s->private;
+
+   func(s);
+   return 0;
+}
+
+static int dss_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dss_debug_show, inode->i_private);
+}
+
+static const struct file_operations dss_debug_fops = {
+   .open   = dss_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dss_debugfs_dir;
+
+static int dss_initialize_debugfs(void)
+{
+   dss_debugfs_dir = debugfs_create_dir("omapdss", NULL);
+   if (IS_ERR(dss_debugfs_dir)) {
+   int err = PTR_ERR(dss_debugfs_dir);
+
+   dss_debugfs_dir = NULL;
+   return err;
+   }
+
+   debugfs_create_file("clk", S_IRUGO, dss_debugfs_dir,
+   &dss_debug_dump_clocks, &dss_debug_fops);
+
+   return 0;
+}
+
+static void dss_uninitialize_debugfs(void)
+{
+   if (dss_debugfs_dir)
+   debugfs_remove_recursive(dss_debugfs_dir);
+}
+
+int ds

[PATCH v2 24/28] drm: omapdrm: Register omapdrm platform device in omapdss driver

[Laurent Pinchart]

The omapdrm platform device is a virtual device created for the sole
purpose of handling the omapdss/omapdrm driver split. It should
eventually be removed. As a first step to ease refactoring move its
registration from platform code to driver code.

The omapdrm driver name must be changed internally to avoid probing both
the device registered in platform code and the device registered in the
omapdss driver, as that would otherwise break bisection.

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

- Drop the CONFIG_DRM_OMAP conditional compilation
- Unregister the platform device at exit time
---
 drivers/gpu/drm/omapdrm/dss/core.c | 15 +++
 drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 2a8bf441d38d..e4781356de96 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -22,6 +22,7 @@
 
 #define DSS_SUBSYS_NAME "CORE"
 
+#include 
 #include 
 #include 
 #include 
@@ -110,6 +111,14 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
dss_uninit_platform_driver,
 };
 
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
+   .name = "omapdrm_",
+   .id = 0,
+};
+
 static int __init omap_dss_init(void)
 {
int r;
@@ -125,6 +134,10 @@ static int __init omap_dss_init(void)
goto err_reg;
}
 
+   r = platform_device_register(&omap_drm_device);
+   if (r)
+   goto err_reg;
+
return 0;
 
 err_reg:
@@ -142,6 +155,8 @@ static void __exit omap_dss_exit(void)
 {
int i;
 
+   platform_device_unregister(&omap_drm_device);
+
for (i = 0; i < ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i)
dss_output_drv_unreg_funcs[i]();
 
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 343301ed4741..6f5fddbaea65 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -957,7 +957,7 @@ static SIMPLE_DEV_PM_OPS(omapdrm_pm_ops, omap_drm_suspend, 
omap_drm_resume);
 
 static struct platform_driver pdev = {
.driver = {
-   .name = DRIVER_NAME,
+   .name = "omapdrm_",
.pm = &omapdrm_pm_ops,
},
.probe = pdev_probe,
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 15/28] drm: omapdrm: hdmi: Store PHY features in HDMI transmitter drivers

[Laurent Pinchart]

The HDMI PHY features are dependent on the HDMI transmitter model. The
PHY driver contains features for all supported transmitters, and selects
the appropriate features based on the OMAP SoC version.

It makes more sense to store the features in the HDMI transmitter
drivers and pass them to the HDMI PHY initialization function, as the
HDMI transmitter drivers are transmitter-specific and don't need to
check the OMAP SoC version.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/hdmi.h |  3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  8 -
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  8 -
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c | 55 ++
 4 files changed, 19 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index 851e5e6f6820..2b4312f8e97d 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -323,7 +323,8 @@ void hdmi_pll_uninit(struct hdmi_pll_data *hpll);
 int hdmi_phy_configure(struct hdmi_phy_data *phy, unsigned long hfbitclk,
unsigned long lfbitclk);
 void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file *s);
-int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy);
+int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy,
+ const struct hdmi_phy_features *features);
 int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const u32 *lanes);
 
 /* HDMI common funcs */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index ff4a0c04a22c..1feb6deab108 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -683,6 +683,12 @@ static int hdmi_audio_register(struct device *dev)
 }
 
 /* HDMI HW IP initialisation */
+static const struct hdmi_phy_features hdmi4_phy_feats = {
+   .bist_ctrl  =   false,
+   .ldo_voltage=   true,
+   .max_phy=   185675000,
+};
+
 static int hdmi4_bind(struct device *dev, struct device *master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -707,7 +713,7 @@ static int hdmi4_bind(struct device *dev, struct device 
*master, void *data)
if (r)
return r;
 
-   r = hdmi_phy_init(pdev, &hdmi.phy);
+   r = hdmi_phy_init(pdev, &hdmi.phy, &hdmi4_phy_feats);
if (r)
goto err;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index c037b61f7920..529653180bfc 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -715,6 +715,12 @@ static int hdmi_audio_register(struct device *dev)
 }
 
 /* HDMI HW IP initialisation */
+static const struct hdmi_phy_features hdmi5_phy_feats = {
+   .bist_ctrl  =   true,
+   .ldo_voltage=   false,
+   .max_phy=   18600,
+};
+
 static int hdmi5_bind(struct device *dev, struct device *master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -739,7 +745,7 @@ static int hdmi5_bind(struct device *dev, struct device 
*master, void *data)
if (r)
return r;
 
-   r = hdmi_phy_init(pdev, &hdmi.phy);
+   r = hdmi_phy_init(pdev, &hdmi.phy, &hdmi5_phy_feats);
if (r)
goto err;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
index bff1ea11ed2f..87ed0bc5b146 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "omapdss.h"
@@ -170,60 +169,12 @@ int hdmi_phy_configure(struct hdmi_phy_data *phy, 
unsigned long hfbitclk,
return 0;
 }
 
-static const struct hdmi_phy_features omap44xx_phy_feats = {
-   .bist_ctrl  =   false,
-   .ldo_voltage=   true,
-   .max_phy=   185675000,
-};
-
-static const struct hdmi_phy_features omap54xx_phy_feats = {
-   .bist_ctrl  =   true,
-   .ldo_voltage=   false,
-   .max_phy=   18600,
-};
-
-static int hdmi_phy_init_features(struct platform_device *pdev,
- struct hdmi_phy_data *phy)
-{
-   struct hdmi_phy_features *dst;
-   const struct hdmi_phy_features *src;
-
-   dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(&pdev->dev, "Failed to allocate HDMI PHY Features\n");
-   return -ENOMEM;
-   }
-
-   switch (omapdss_get_version()) {
-   case OMAPDSS_VER_OMAP4430_ES1:
-   case OMAPDSS_VER_OMAP4430_ES2:
-   case OMAPDSS_VER_OMAP4:
-   src = &omap44xx_phy_feats;
-   break;
-
-   case OMAPDSS_VER_OMAP5:
-   case OMAPDSS_VER_DRA7xx:
-   src = &omap54xx_phy_feats;
-   break;
-
-

[PATCH v2 22/28] drm: omapdrm: Move shutdown() handler from core to dss

[Laurent Pinchart]

In preparation for removal of the core module, move the shutdown()
handler from core to dss.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c | 20 
 drivers/gpu/drm/omapdrm/dss/dss.c  | 16 
 2 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index dc2147ec78f6..839bfb5a2e48 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -50,19 +50,6 @@ EXPORT_SYMBOL(omapdss_get_version);
 
 /* PLATFORM DEVICE */
 
-static void dss_disable_all_devices(void)
-{
-   struct omap_dss_device *dssdev = NULL;
-
-   for_each_dss_dev(dssdev) {
-   if (!dssdev->driver)
-   continue;
-
-   if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
-   dssdev->driver->disable(dssdev);
-   }
-}
-
 static int __init omap_dss_probe(struct platform_device *pdev)
 {
core.pdev = pdev;
@@ -77,15 +64,8 @@ static int omap_dss_remove(struct platform_device *pdev)
return 0;
 }
 
-static void omap_dss_shutdown(struct platform_device *pdev)
-{
-   DSSDBG("shutdown\n");
-   dss_disable_all_devices();
-}
-
 static struct platform_driver omap_dss_driver = {
.remove = omap_dss_remove,
-   .shutdown   = omap_dss_shutdown,
.driver = {
.name   = "omapdss",
},
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 618fd4dcbd5a..34d5caa7d0b5 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1421,6 +1421,21 @@ static int dss_remove(struct platform_device *pdev)
return 0;
 }
 
+static void dss_shutdown(struct platform_device *pdev)
+{
+   struct omap_dss_device *dssdev = NULL;
+
+   DSSDBG("shutdown\n");
+
+   for_each_dss_dev(dssdev) {
+   if (!dssdev->driver)
+   continue;
+
+   if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
+   dssdev->driver->disable(dssdev);
+   }
+}
+
 static int dss_runtime_suspend(struct device *dev)
 {
dss_save_context();
@@ -1460,6 +1475,7 @@ static const struct dev_pm_ops dss_pm_ops = {
 static struct platform_driver omap_dsshw_driver = {
.probe  = dss_probe,
.remove = dss_remove,
+   .shutdown   = dss_shutdown,
.driver = {
.name   = "omapdss_dss",
.pm = &dss_pm_ops,
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 17/28] drm: omapdrm: hdmi: Replace OMAP SoC model check with HDMI xmit version

[Laurent Pinchart]

The HDMI wrapper code only needs to differentiate between major OMAP
revisions, which can be obtained from the HDMI transmitter compatible
string. Replace the OMAP SoC model checks to prepare for removal of the
OMAP SoC version platform data.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/hdmi.h|  4 +++-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c   |  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c   |  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 12 +---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index 7ae26c7c5189..42d77b77bf45 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -234,6 +234,7 @@ struct hdmi_core_audio_config {
 struct hdmi_wp_data {
void __iomem *base;
phys_addr_t phys_base;
+   unsigned int version;
 };
 
 struct hdmi_pll_data {
@@ -310,7 +311,8 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
struct videomode *vm);
 void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt,
struct videomode *vm, struct hdmi_config *param);
-int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp);
+int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp,
+unsigned int version);
 phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp);
 
 /* HDMI PLL funcs */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index b34f82bb61d5..a1e3f33a06f0 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -730,7 +730,7 @@ static int hdmi4_bind(struct device *dev, struct device 
*master, void *data)
if (r)
return r;
 
-   r = hdmi_wp_init(pdev, &hdmi.wp);
+   r = hdmi_wp_init(pdev, &hdmi.wp, 4);
if (r)
return r;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 54df41f24085..67accbcf70bc 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -763,7 +763,7 @@ static int hdmi5_bind(struct device *dev, struct device 
*master, void *data)
if (r)
return r;
 
-   r = hdmi_wp_init(pdev, &hdmi.wp);
+   r = hdmi_wp_init(pdev, &hdmi.wp, 5);
if (r)
return r;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index b1ab9e563915..adb6b6311ec7 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -176,9 +176,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
 * However, we don't support OMAP5 ES1 at all, so we can just check for
 * OMAP4 here.
 */
-   if (omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES1 ||
-   omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES2 ||
-   omapdss_get_version() == OMAPDSS_VER_OMAP4)
+   if (wp->version == 4)
hsync_len_offset = 0;
 
timing_h |= FLD_VAL(vm->hback_porch, 31, 20);
@@ -233,9 +231,7 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
DSSDBG("Enter hdmi_wp_audio_config_format\n");
 
r = hdmi_read_reg(wp->base, HDMI_WP_AUDIO_CFG);
-   if (omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES1 ||
-   omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES2 ||
-   omapdss_get_version() == OMAPDSS_VER_OMAP4) {
+   if (wp->version == 4) {
r = FLD_MOD(r, aud_fmt->stereo_channels, 26, 24);
r = FLD_MOD(r, aud_fmt->active_chnnls_msk, 23, 16);
}
@@ -280,7 +276,8 @@ int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, 
bool enable)
return 0;
 }
 
-int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp)
+int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp,
+unsigned int version)
 {
struct resource *res;
 
@@ -290,6 +287,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct 
hdmi_wp_data *wp)
return PTR_ERR(wp->base);
 
wp->phys_base = res->start;
+   wp->version = version;
 
return 0;
 }
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 27/28] ARM: OMAP2+: Don't register omapdss device for omapdrm

[Laurent Pinchart]

The omapdrm driver doesn't need the omapdss device anymore. Although it
can't be removed completely as the fbdev driver still requires it, we
can condition its registration to the usage of the omapfb driver.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-omap2/display.c | 111 +++---
 1 file changed, 60 insertions(+), 51 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5f5697668de8..798fc718fffe 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -66,6 +66,7 @@
  */
 #define FRAMEDONE_IRQ_TIMEOUT  100
 
+#if defined(CONFIG_FB_OMAP2)
 static struct platform_device omap_display_device = {
.name  = "omapdss",
.id= -1,
@@ -163,6 +164,64 @@ static enum omapdss_version __init 
omap_display_get_version(void)
return OMAPDSS_VER_UNKNOWN;
 }
 
+static int __init omapdss_init_fbdev(void)
+{
+   static struct omap_dss_board_info board_data = {
+   .dsi_enable_pads = omap_dsi_enable_pads,
+   .dsi_disable_pads = omap_dsi_disable_pads,
+   .set_min_bus_tput = omap_dss_set_min_bus_tput,
+   };
+   struct device_node *node;
+
+   board_data.version = omap_display_get_version();
+   if (board_data.version == OMAPDSS_VER_UNKNOWN) {
+   pr_err("DSS not supported on this SoC\n");
+   return -ENODEV;
+   }
+
+   omap_display_device.dev.platform_data = &board_data;
+
+   r = platform_device_register(&omap_display_device);
+   if (r < 0) {
+   pr_err("Unable to register omapdss device\n");
+   return r;
+   }
+
+   /* create vrfb device */
+   r = omap_init_vrfb();
+   if (r < 0) {
+   pr_err("Unable to register omapvrfb device\n");
+   return r;
+   }
+
+   /* create FB device */
+   r = omap_init_fb();
+   if (r < 0) {
+   pr_err("Unable to register omapfb device\n");
+   return r;
+   }
+
+   /* create V4L2 display device */
+   r = omap_init_vout();
+   if (r < 0) {
+   pr_err("Unable to register omap_vout device\n");
+   return r;
+   }
+
+   /* add DSI info for omap4 */
+   node = of_find_node_by_name(NULL, "omap4_padconf_global");
+   if (node)
+   omap4_dsi_mux_syscon = syscon_node_to_regmap(node);
+
+   return 0;
+}
+#else
+static inline int omapdss_init_fbdev(void)
+{
+   return 0;
+}
+#endif /* CONFIG_FB_OMAP2 */
+
 static void dispc_disable_outputs(void)
 {
u32 v, irq_mask = 0;
@@ -335,16 +394,9 @@ static struct device_node * __init 
omapdss_find_dss_of_node(void)
 int __init omapdss_init_of(void)
 {
int r;
-   enum omapdss_version ver;
struct device_node *node;
struct platform_device *pdev;
 
-   static struct omap_dss_board_info board_data = {
-   .dsi_enable_pads = omap_dsi_enable_pads,
-   .dsi_disable_pads = omap_dsi_disable_pads,
-   .set_min_bus_tput = omap_dss_set_min_bus_tput,
-   };
-
/* only create dss helper devices if dss is enabled in the .dts */
 
node = omapdss_find_dss_of_node();
@@ -354,13 +406,6 @@ int __init omapdss_init_of(void)
if (!of_device_is_available(node))
return 0;
 
-   ver = omap_display_get_version();
-
-   if (ver == OMAPDSS_VER_UNKNOWN) {
-   pr_err("DSS not supported on this SoC\n");
-   return -ENODEV;
-   }
-
pdev = of_find_device_by_node(node);
 
if (!pdev) {
@@ -374,41 +419,5 @@ int __init omapdss_init_of(void)
return r;
}
 
-   board_data.version = ver;
-
-   omap_display_device.dev.platform_data = &board_data;
-
-   r = platform_device_register(&omap_display_device);
-   if (r < 0) {
-   pr_err("Unable to register omapdss device\n");
-   return r;
-   }
-
-   /* create vrfb device */
-   r = omap_init_vrfb();
-   if (r < 0) {
-   pr_err("Unable to register omapvrfb device\n");
-   return r;
-   }
-
-   /* create FB device */
-   r = omap_init_fb();
-   if (r < 0) {
-   pr_err("Unable to register omapfb device\n");
-   return r;
-   }
-
-   /* create V4L2 display device */
-   r = omap_init_vout();
-   if (r < 0) {
-   pr_err("Unable to register omap_vout device\n");
-   return r;
-   }
-
-   /* add DSI info for omap4 */
-   node = of_find_node_by_name(NULL, "omap4_padconf_global");
-   if (node)
-   omap4_dsi_mux_syscon = syscon_node_to_regmap(node);
-
-   return 0;
+   return omapdss_init_fbdev();
 }
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 26/28] ARM: OMAP2+: Remove unused omapdrm platform device

[Laurent Pinchart]

The omapdrm platform device is unused, as a replacement is now
registered in the omapdss driver. Remove it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-omap2/Makefile  |  2 +-
 arch/arm/mach-omap2/display.c |  7 --
 arch/arm/mach-omap2/display.h |  1 -
 arch/arm/mach-omap2/drm.c | 53 ---
 4 files changed, 1 insertion(+), 62 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/drm.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c89757abb0ae..9d3ba1e0119c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -8,7 +8,7 @@ ccflags-y := -I$(srctree)/$(src)/include \
 # Common support
 obj-y := id.o io.o control.o devices.o fb.o timer.o pm.o \
 common.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
-omap_device.o omap-headsmp.o sram.o drm.o
+omap_device.o omap-headsmp.o sram.o
 
 hwmod-common   = omap_hwmod.o omap_hwmod_reset.o \
  omap_hwmod_common_data.o
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 8fa01c0ecdb2..5f5697668de8 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -384,13 +384,6 @@ int __init omapdss_init_of(void)
return r;
}
 
-   /* create DRM device */
-   r = omap_init_drm();
-   if (r < 0) {
-   pr_err("Unable to register omapdrm device\n");
-   return r;
-   }
-
/* create vrfb device */
r = omap_init_vrfb();
if (r < 0) {
diff --git a/arch/arm/mach-omap2/display.h b/arch/arm/mach-omap2/display.h
index 9a39646d4316..42ec2e99a2f4 100644
--- a/arch/arm/mach-omap2/display.h
+++ b/arch/arm/mach-omap2/display.h
@@ -26,7 +26,6 @@ struct omap_dss_dispc_dev_attr {
boolhas_framedonetv_irq;
 };
 
-int omap_init_drm(void);
 int omap_init_vrfb(void);
 int omap_init_fb(void);
 int omap_init_vout(void);
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
deleted file mode 100644
index 44fef961bb70..
--- a/arch/arm/mach-omap2/drm.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * DRM/KMS device registration for TI OMAP platforms
- *
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "soc.h"
-#include "display.h"
-
-#if IS_ENABLED(CONFIG_DRM_OMAP)
-
-static struct omap_drm_platform_data platform_data;
-
-static struct platform_device omap_drm_device = {
-   .dev = {
-   .coherent_dma_mask = DMA_BIT_MASK(32),
-   .platform_data = &platform_data,
-   },
-   .name = "omapdrm",
-   .id = 0,
-};
-
-int __init omap_init_drm(void)
-{
-   platform_data.omaprev = GET_OMAP_TYPE;
-
-   return platform_device_register(&omap_drm_device);
-
-}
-#else
-int __init omap_init_drm(void) { return 0; }
-#endif
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 16/28] drm: omapdrm: hdmi: Store PLL hardware data in HDMI transmitter drivers

[Laurent Pinchart]

The HDMI PLL hardware data are dependent on the HDMI transmitter model.
The PLL driver contains hardware data for all supported transmitters,
and selects the appropriate hardware data based on the OMAP SoC version.

It makes more sense to store the PLL hardware data in the HDMI
transmitter drivers and pass them to the HDMI PLL initialization
function, as the HDMI transmitter drivers are transmitter-specific and
don't need to check the OMAP SoC version.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/hdmi.h |  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c| 27 +++-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c| 28 -
 drivers/gpu/drm/omapdrm/dss/hdmi_pll.c | 77 +++---
 4 files changed, 60 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index 2b4312f8e97d..7ae26c7c5189 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -316,7 +316,7 @@ phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data 
*wp);
 /* HDMI PLL funcs */
 void hdmi_pll_dump(struct hdmi_pll_data *pll, struct seq_file *s);
 int hdmi_pll_init(struct platform_device *pdev, struct hdmi_pll_data *pll,
-   struct hdmi_wp_data *wp);
+ const struct dss_pll_hw *pll_hw, struct hdmi_wp_data *wp);
 void hdmi_pll_uninit(struct hdmi_pll_data *hpll);
 
 /* HDMI PHY funcs */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 1feb6deab108..b34f82bb61d5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -689,6 +689,31 @@ static const struct hdmi_phy_features hdmi4_phy_feats = {
.max_phy=   185675000,
 };
 
+static const struct dss_pll_hw hdmi4_pll_hw = {
+   .type = DSS_PLL_TYPE_B,
+
+   .n_max = 255,
+   .m_min = 20,
+   .m_max = 4095,
+   .mX_max = 127,
+   .fint_min = 50,
+   .fint_max = 250,
+
+   .clkdco_min = 5,
+   .clkdco_low = 10,
+   .clkdco_max = 20,
+
+   .n_msb = 8,
+   .n_lsb = 1,
+   .m_msb = 20,
+   .m_lsb = 9,
+
+   .mX_msb[0] = 24,
+   .mX_lsb[0] = 18,
+
+   .has_selfreqdco = true,
+};
+
 static int hdmi4_bind(struct device *dev, struct device *master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -709,7 +734,7 @@ static int hdmi4_bind(struct device *dev, struct device 
*master, void *data)
if (r)
return r;
 
-   r = hdmi_pll_init(pdev, &hdmi.pll, &hdmi.wp);
+   r = hdmi_pll_init(pdev, &hdmi.pll, &hdmi4_pll_hw, &hdmi.wp);
if (r)
return r;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 529653180bfc..54df41f24085 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -721,6 +721,32 @@ static const struct hdmi_phy_features hdmi5_phy_feats = {
.max_phy=   18600,
 };
 
+static const struct dss_pll_hw hdmi5_pll_hw = {
+   .type = DSS_PLL_TYPE_B,
+
+   .n_max = 255,
+   .m_min = 20,
+   .m_max = 2045,
+   .mX_max = 127,
+   .fint_min = 62,
+   .fint_max = 250,
+
+   .clkdco_min = 75000,
+   .clkdco_low = 15,
+   .clkdco_max = 25UL,
+
+   .n_msb = 8,
+   .n_lsb = 1,
+   .m_msb = 20,
+   .m_lsb = 9,
+
+   .mX_msb[0] = 24,
+   .mX_lsb[0] = 18,
+
+   .has_selfreqdco = true,
+   .has_refsel = true,
+};
+
 static int hdmi5_bind(struct device *dev, struct device *master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -741,7 +767,7 @@ static int hdmi5_bind(struct device *dev, struct device 
*master, void *data)
if (r)
return r;
 
-   r = hdmi_pll_init(pdev, &hdmi.pll, &hdmi.wp);
+   r = hdmi_pll_init(pdev, &hdmi.pll, &hdmi5_pll_hw, &hdmi.wp);
if (r)
return r;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
index 46239358655a..870c5e633075 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
@@ -77,58 +77,9 @@ static const struct dss_pll_ops dsi_pll_ops = {
.set_config = dss_pll_write_config_type_b,
 };
 
-static const struct dss_pll_hw dss_omap4_hdmi_pll_hw = {
-   .type = DSS_PLL_TYPE_B,
-
-   .n_max = 255,
-   .m_min = 20,
-   .m_max = 4095,
-   .mX_max = 127,
-   .fint_min = 50,
-   .fint_max = 250,
-
-   .clkdco_min = 5,
-   .clkdco_low = 10,
-   .clkdco_max = 20,
-
-   .n_msb = 8,
-   .n_lsb = 1,
-   .m_msb = 20,
-   .m_lsb = 9,
-
-   .mX_msb[0] = 24,
-   .mX_lsb[0] = 18,
-
-   .has_selfreqdco = true,
-};
-
-static const struct dss_pll_hw dss_omap5_hdmi_pll_hw = {
-   .t

Re: [PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

[Ville Syrjälä]

On Thu, May 04, 2017 at 03:20:22PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 05:09:08PM +0300, Ville Syrjälä wrote:
> > On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote:
> > > In the previous patch we've implemented hwmode tracking a la i915 for
> > > the vblank timestamp calculations. But that was just the basic
> > > semantics, i915 has some nice sanity checks to make sure we keep
> > > getting this right. Move them over too.
> > > 
> > > Cc: Ville Syrjälä 
> > > Reviewed-by: Neil Armstrong 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_irq.c|  8 +++-
> > >  drivers/gpu/drm/i915/i915_irq.c  | 10 ++
> > >  drivers/gpu/drm/i915/intel_display.c | 11 ++-
> > >  3 files changed, 15 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index 89f0928b042a..942183a2aa3c 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -775,8 +775,10 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
> > > drm_device *dev,
> > >   /* If mode timing undefined, just return as no-op:
> > >* Happens during initial modesetting of a crtc.
> > >*/
> > > - if (mode->crtc_clock == 0) {
> > > + if (WARN_ON(mode->crtc_clock == 0)) {
> > >   DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
> > > + WARN_ON(drm_drv_uses_atomic_modeset(dev));
> > 
> > I would make these _ONCE() otherwise the machine might end up
> > practically dead.
> 
> Will do.
> 
> > > +
> > >   return false;
> > >   }
> > >  
> > > @@ -1338,6 +1340,10 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
> > >   send_vblank_event(dev, e, seq, &now);
> > >   }
> > >   spin_unlock_irqrestore(&dev->event_lock, irqflags);
> > > +
> > > + /* Will be reset by the modeset helpers when re-enabling the crtc by
> > > +  * calling drm_calc_timestamping_constants(). */
> > > + vblank->hwmode.crtc_clock = 0;
> > >  }
> > >  EXPORT_SYMBOL(drm_crtc_vblank_off);
> > 
> > Shouldn't we do this in drm_crtc_vblank_reset() as well?
> > 
> > Hmm. Except we call that after drm_calc_timestamping_constants(). I
> > guess we should be able to move the reset() into
> > intel_modeset_readout_hw_state(). And possibly move the vblank_on()
> > call as well?
> 
> Yeah, it'd be nice to clean this stuff up some more, but there's also the
> problem that legacy and new drivers callc drm_calc_timestamping_constants
> at opposite ends of the modeset sequence. Doing more here is a bunch more
> work, maybe for the next patche series ...
> 
> I don't think we need to call it in _reset, at least at boot-up it should
> be 0 already. And for s/r we already shut down the pipe on suspend, so
> it's gone through this here.

Hmm. Indeed that seems like it should cover it.

> 
> With the _ONCE nit address (and the build breakage I've introduced in this
> version fixed), ack from you on the entire series?

Sure, for the series
Acked-by: Ville Syrjälä 

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 28/28] drm: omapdrm: Remove omapdrm platform data

[Laurent Pinchart]

The omapdrm platform data are not used anymore, remove them.

Signed-off-by: Laurent Pinchart 
---
 include/linux/platform_data/omap_drm.h | 53 --
 1 file changed, 53 deletions(-)
 delete mode 100644 include/linux/platform_data/omap_drm.h

diff --git a/include/linux/platform_data/omap_drm.h 
b/include/linux/platform_data/omap_drm.h
deleted file mode 100644
index f4e4a237ebd2..
--- a/include/linux/platform_data/omap_drm.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * DRM/KMS platform data for TI OMAP platforms
- *
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#ifndef __PLATFORM_DATA_OMAP_DRM_H__
-#define __PLATFORM_DATA_OMAP_DRM_H__
-
-/*
- * Optional platform data to configure the default configuration of which
- * pipes/overlays/CRTCs are used.. if this is not provided, then instead the
- * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
- * one manager, with priority given to managers that are connected to
- * detected devices.  Remaining overlays are used as video planes.  This
- * should be a good default behavior for most cases, but yet there still
- * might be times when you wish to do something different.
- */
-struct omap_kms_platform_data {
-   /* overlays to use as CRTCs: */
-   int ovl_cnt;
-   const int *ovl_ids;
-
-   /* overlays to use as video planes: */
-   int pln_cnt;
-   const int *pln_ids;
-
-   int mgr_cnt;
-   const int *mgr_ids;
-
-   int dev_cnt;
-   const char **dev_names;
-};
-
-struct omap_drm_platform_data {
-   uint32_t omaprev;
-   struct omap_kms_platform_data *kms_pdata;
-};
-
-#endif /* __PLATFORM_DATA_OMAP_DRM_H__ */
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 25/28] drm: omapdrm: Remove the omapdss driver

[Laurent Pinchart]

The omapdss driver (not to be confused with the omapdss_dss driver) is
now a dummy driver with empty probe and remove functions. Remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c| 48 ---
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  1 -
 2 files changed, 49 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index e4781356de96..fe176978d127 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -25,50 +25,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 #include "omapdss.h"
 #include "dss.h"
-#include "dss_features.h"
-
-static struct {
-   struct platform_device *pdev;
-} core;
-
-enum omapdss_version omapdss_get_version(void)
-{
-   struct omap_dss_board_info *pdata = core.pdev->dev.platform_data;
-   return pdata->version;
-}
-EXPORT_SYMBOL(omapdss_get_version);
-
-/* PLATFORM DEVICE */
-
-static int __init omap_dss_probe(struct platform_device *pdev)
-{
-   core.pdev = pdev;
-
-   return 0;
-}
-
-static int omap_dss_remove(struct platform_device *pdev)
-{
-   return 0;
-}
-
-static struct platform_driver omap_dss_driver = {
-   .remove = omap_dss_remove,
-   .driver = {
-   .name   = "omapdss",
-   },
-};
 
 /* INIT */
 static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
@@ -124,10 +84,6 @@ static int __init omap_dss_init(void)
int r;
int i;
 
-   r = platform_driver_probe(&omap_dss_driver, omap_dss_probe);
-   if (r)
-   return r;
-
for (i = 0; i < ARRAY_SIZE(dss_output_drv_reg_funcs); ++i) {
r = dss_output_drv_reg_funcs[i]();
if (r)
@@ -146,8 +102,6 @@ static int __init omap_dss_init(void)
++i)
dss_output_drv_unreg_funcs[i]();
 
-   platform_driver_unregister(&omap_dss_driver);
-
return r;
 }
 
@@ -159,8 +113,6 @@ static void __exit omap_dss_exit(void)
 
for (i = 0; i < ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i)
dss_output_drv_unreg_funcs[i]();
-
-   platform_driver_unregister(&omap_dss_driver);
 }
 
 module_init(omap_dss_init);
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 32eae507a669..6a9a502ac672 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -766,7 +766,6 @@ struct omap_dss_driver {
const struct hdmi_avi_infoframe *avi);
 };
 
-enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
 int omap_dss_register_driver(struct omap_dss_driver *);
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures

[Laurent Pinchart]

Both structures describe features of a particular OMAP DSS version,
there's no reason to keep them separate. Merge them together, allowing
initialization of the features based on the DSS compatible string
instead of the OMAP SoC version.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/core.c |   2 -
 drivers/gpu/drm/omapdrm/dss/dss.c  | 128 +
 drivers/gpu/drm/omapdrm/dss/dss.h  |   6 +
 drivers/gpu/drm/omapdrm/dss/dss_features.c | 220 -
 drivers/gpu/drm/omapdrm/dss/dss_features.h |  41 +-
 5 files changed, 204 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 839bfb5a2e48..2a8bf441d38d 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -54,8 +54,6 @@ static int __init omap_dss_probe(struct platform_device *pdev)
 {
core.pdev = pdev;
 
-   dss_features_init(omapdss_get_version());
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 34d5caa7d0b5..edfb1ecded76 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -77,16 +77,6 @@ struct dss_ops {
enum dss_clk_source clk_src);
 };
 
-struct dss_features {
-   enum dss_device_type type;
-   u8 fck_div_max;
-   u8 dss_fck_multiplier;
-   const char *parent_clk_name;
-   const enum omap_display_type *ports;
-   int num_ports;
-   const struct dss_ops *ops;
-};
-
 static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -108,7 +98,7 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
 
-   const struct dss_features *feat;
+   const struct omap_dss_features *feat;
 
struct dss_pll  *video1_pll;
struct dss_pll  *video2_pll;
@@ -969,114 +959,25 @@ static inline void dss_uninitialize_debugfs(void)
 }
 #endif /* CONFIG_OMAP2_DSS_DEBUGFS */
 
-static const struct dss_ops dss_ops_omap2_omap3 = {
+const struct dss_ops dss_ops_omap2_omap3 = {
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
 };
 
-static const struct dss_ops dss_ops_omap4 = {
+const struct dss_ops dss_ops_omap4 = {
.dpi_select_source = &dss_dpi_select_source_omap4,
.select_lcd_source = &dss_lcd_clk_mux_omap4,
 };
 
-static const struct dss_ops dss_ops_omap5 = {
+const struct dss_ops dss_ops_omap5 = {
.dpi_select_source = &dss_dpi_select_source_omap5,
.select_lcd_source = &dss_lcd_clk_mux_omap5,
 };
 
-static const struct dss_ops dss_ops_dra7 = {
+const struct dss_ops dss_ops_dra7 = {
.dpi_select_source = &dss_dpi_select_source_dra7xx,
.select_lcd_source = &dss_lcd_clk_mux_dra7,
 };
 
-static const enum omap_display_type omap2plus_ports[] = {
-   OMAP_DISPLAY_TYPE_DPI,
-};
-
-static const enum omap_display_type omap34xx_ports[] = {
-   OMAP_DISPLAY_TYPE_DPI,
-   OMAP_DISPLAY_TYPE_SDI,
-};
-
-static const enum omap_display_type dra7xx_ports[] = {
-   OMAP_DISPLAY_TYPE_DPI,
-   OMAP_DISPLAY_TYPE_DPI,
-   OMAP_DISPLAY_TYPE_DPI,
-};
-
-static const struct dss_features omap24xx_dss_feats = {
-   .type   =   DSS_TYPE_OMAP2,
-   /*
-* fck div max is really 16, but the divider range has gaps. The range
-* from 1 to 6 has no gaps, so let's use that as a max.
-*/
-   .fck_div_max=   6,
-   .dss_fck_multiplier =   2,
-   .parent_clk_name=   "core_ck",
-   .ports  =   omap2plus_ports,
-   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
-   .ops=   &dss_ops_omap2_omap3,
-};
-
-static const struct dss_features omap34xx_dss_feats = {
-   .type   =   DSS_TYPE_OMAP3,
-   .fck_div_max=   16,
-   .dss_fck_multiplier =   2,
-   .parent_clk_name=   "dpll4_ck",
-   .ports  =   omap34xx_ports,
-   .num_ports  =   ARRAY_SIZE(omap34xx_ports),
-   .ops=   &dss_ops_omap2_omap3,
-};
-
-static const struct dss_features omap3630_dss_feats = {
-   .type   =   DSS_TYPE_OMAP3,
-   .fck_div_max=   32,
-   .dss_fck_multiplier =   1,
-   .parent_clk_name=   "dpll4_ck",
-   .ports  =   omap2plus_ports,
-   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
-   .ops=   &dss_ops_omap2_omap3,
-};
-
-static const struct dss_features omap44xx_dss_feats = {
-   .type   =   DSS_TYPE_OMAP4,
-   .fck_div_max=   32,
-   .dss_fck_multiplier =   1,
-   .parent_clk_name=   "dpll_per_x2_ck",
-

[PATCH v2 20/28] drm: omapdrm: Don't forward set_min_bus_tput() to no-op platform code

[Laurent Pinchart]

The OMAP implementation of the set_min_bus_tput() API is a no-op.
There's no point in forwarding the driver calls to the platform code.
Remove the use of the related platform data callback, but keep the
internal function as a reminder that the feature will need to be
implemented when the OMAP platform will provide support.

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

- Make the function inline
---
 drivers/gpu/drm/omapdrm/dss/core.c | 10 --
 drivers/gpu/drm/omapdrm/dss/dss.h  |  7 ++-
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 7579de042d32..ff6357df0588 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -50,16 +50,6 @@ enum omapdss_version omapdss_get_version(void)
 }
 EXPORT_SYMBOL(omapdss_get_version);
 
-int dss_set_min_bus_tput(struct device *dev, unsigned long tput)
-{
-   struct omap_dss_board_info *pdata = core.pdev->dev.platform_data;
-
-   if (pdata->set_min_bus_tput)
-   return pdata->set_min_bus_tput(dev, tput);
-   else
-   return 0;
-}
-
 #if defined(CONFIG_OMAP2_DSS_DEBUGFS)
 static int dss_debug_show(struct seq_file *s, void *unused)
 {
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 453b4ba0bf18..1ef7c0e75d4c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -230,7 +230,12 @@ struct seq_file;
 struct platform_device;
 
 /* core */
-int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
+static inline int dss_set_min_bus_tput(struct device *dev, unsigned long tput)
+{
+   /* To be implemented when the OMAP platform will provide this feature */
+   return 0;
+}
+
 int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file 
*));
 
 static inline bool dss_mgr_is_lcd(enum omap_channel id)
-- 
Regards,

Laurent Pinchart

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

[Bug 100437] IO_PAGE_FAULT is spammed in dmesg

[bugzilla-daemon]

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

--- Comment #5 from Christian Lanig  ---
The bug is not fixed but it only happens on a cold boot for me. When I reboot
the PC these messages disappear.

There also seem to be reports about comparable behavior with older AMD systems.
It is perhaps a Bios bug, because something obviously works as soon as the PC
isn't shut down entirely.
It seems unlikely to be related to the GPU driver because the driver should not
depend on whether the computer has been turned off or just reboots.

It might still be helpful to know if your issues disappear by rebooting your
machine as well.

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

[PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 8 May 2017 13:42:03 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index f4eb412f3604..54d66b732d55 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -946,7 +946,7 @@ static int mipi_dbi_debugfs_command_show(struct seq_file 
*m, void *unused)
 
for (i = 0; i < len; i++)
seq_printf(m, "%02x", val[i]);
-   seq_puts(m, "\n");
+   seq_putc(m, '\n');
}
 
return 0;
-- 
2.12.2

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

Re: [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Chris Wilson]

On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
> On some (Bay Trail) devices the LCD panel is mounted upside-down.
> 
> This commit uses the code to read back the initial rotation of the
> primary plane in get_initial_plane_config from Ville Syrjala's
> "drm/fb-helper: Inherit rotation wip" patch and when re-using the
> initial fb it stores that in intel_crtc.initial_rotation.
> 
> It adds an intel_plane_get_rotation helper which combines this
> initial_rotation with any rotation requested by userspace and
> uses this in all places which look at a planes rotation, thus
> transparently dealing with upside-down LCD panels without requiring
> any user-space or fbcon changes.
> 
> This fixes the kernel boot messages switching from being shown the right
> way up in efifb to being shown upside down as soon as a native kms driver
> loads, as well as any graphics displayed by userspace being upside-down.
> 
> Note this only deals with upside-down LCD panels / 180 degrees
> rotation as the hardware in question only supports 180 degrees
> rotation in hardware. The one model known which has a panel mounted
> with 90/270 degrees rotation will need to be fully dealt with in
> userspace, even the firmware boot screen / menus are rotated 90 degrees
> on this one and there simply is nothing the kernel can do about this.

I shall just mention a concern with hiding the transformation on the
connection, we do expose the subpixel layout to userspace and that
should be adjusted based on this lie. There are probably other places
where the orientation of the output leaks through the current interface.

The commit message fails to explain how userspace, which should already
have the tools available to it, is unable to reapply the existing
rotation - i.e. why this is a kernel problem, and whether by hiding this
from userspace we are not trapping ourselves with warts in the ABI.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 04/28] drm: omapdrm: Remove unused default display name support

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday, May 08, 2017 02:32:39 PM Laurent Pinchart wrote:
> The default display name is both unused and never set by platform data.
> Remove default display name module parameter, platform data field and
> runtime infrastructure.
> 
> Signed-off-by: Laurent Pinchart 

For fbdev part:

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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

Re: [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

HI,

On 08-05-17 14:27, Chris Wilson wrote:

On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:

On some (Bay Trail) devices the LCD panel is mounted upside-down.

This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Syrjala's
"drm/fb-helper: Inherit rotation wip" patch and when re-using the
initial fb it stores that in intel_crtc.initial_rotation.

It adds an intel_plane_get_rotation helper which combines this
initial_rotation with any rotation requested by userspace and
uses this in all places which look at a planes rotation, thus
transparently dealing with upside-down LCD panels without requiring
any user-space or fbcon changes.

This fixes the kernel boot messages switching from being shown the right
way up in efifb to being shown upside down as soon as a native kms driver
loads, as well as any graphics displayed by userspace being upside-down.

Note this only deals with upside-down LCD panels / 180 degrees
rotation as the hardware in question only supports 180 degrees
rotation in hardware. The one model known which has a panel mounted
with 90/270 degrees rotation will need to be fully dealt with in
userspace, even the firmware boot screen / menus are rotated 90 degrees
on this one and there simply is nothing the kernel can do about this.


I shall just mention a concern with hiding the transformation on the
connection, we do expose the subpixel layout to userspace and that
should be adjusted based on this lie. There are probably other places
where the orientation of the output leaks through the current interface.

The commit message fails to explain how userspace, which should already
have the tools available to it, is unable to reapply the existing
rotation - i.e. why this is a kernel problem,


This is a kernel problem because one of the things the kernel does
is hardware abstraction, as I mentioned in my reply to Ville, there is
not single userspace to fix here, there is a large supply of userspace
consumers of the kms API which need fixing to fix this in userspace.

For touchscreens which are mounted with a wrong orientation the
input layer fixes things up, I don't see how this is any different
really. Now if it was impossible or very complicated to fix this
in the kernel that would be a different story, but as this patch
shows it is quite doable to fix this in the kernel.

Regards,

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

Re: [PATCH v2 01/28] drm: omapdrm: Remove duplicate error messages when mapping memory

[Tomi Valkeinen]

On 08/05/17 14:32, Laurent Pinchart wrote:
> The devm_ioremap_resource() call can handle being given a NULL resource,
> and prints an error message when mapping fails. Switch the remaining
> devm_ioremap() calls to devm_ioremap_resource() and remove all
> extraneous resource NULL checks and error messages printed manually by
> the driver.

Looks like in some places we check for "!ret" and in some "IS_ERR(ret)"...

 Tomi



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

[PATCH] drm/vgem: Convert to a struct drm_device subclass

[Chris Wilson]

With Laura's introduction of the fake platform device for importing
dmabuf, we add a second static that is logically tied to the vgem_device.
Convert vgem over to using the struct drm_device subclassing, so that
the platform device is stored inside its owner.

Signed-off-by: Chris Wilson 
Cc: Laura Abbott 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 63 +++--
 1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c9381d457a03..4b23ba049632 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -42,7 +42,10 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
-static struct platform_device *vgem_platform;
+static struct vgem_device {
+   struct drm_device drm;
+   struct platform_device *platform;
+} *vgem_device;
 
 static void vgem_gem_free_object(struct drm_gem_object *obj)
 {
@@ -307,7 +310,9 @@ static struct sg_table *vgem_prime_get_sg_table(struct 
drm_gem_object *obj)
 static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
 {
-   return drm_gem_prime_import_dev(dev, dma_buf, &vgem_platform->dev);
+   struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+   return drm_gem_prime_import_dev(dev, dma_buf, &vgem->platform->dev);
 }
 
 static struct drm_gem_object *vgem_prime_import_sg_table(struct drm_device 
*dev,
@@ -377,8 +382,19 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
 }
 
+static void vgem_release(struct drm_device *dev)
+{
+   struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+   platform_device_unregister(vgem->platform);
+   drm_dev_fini(&vgem->drm);
+
+   kfree(vgem);
+}
+
 static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .release= vgem_release,
.open   = vgem_open,
.postclose  = vgem_postclose,
.gem_free_object_unlocked   = vgem_gem_free_object,
@@ -408,45 +424,48 @@ static struct drm_driver vgem_driver = {
.minor  = DRIVER_MINOR,
 };
 
-static struct drm_device *vgem_device;
-
 static int __init vgem_init(void)
 {
int ret;
 
-   vgem_device = drm_dev_alloc(&vgem_driver, NULL);
-   if (IS_ERR(vgem_device))
-   return PTR_ERR(vgem_device);
+   vgem_device = kzalloc(sizeof(*vgem_device), GFP_KERNEL);
+   if (!vgem_device)
+   return -ENOMEM;
 
-   vgem_platform = platform_device_register_simple("vgem",
-   -1, NULL, 0);
+   ret = drm_dev_init(&vgem_device->drm, &vgem_driver, NULL);
+   if (ret)
+   goto out_free;
 
-   if (!vgem_platform) {
+   vgem_device->platform =
+   platform_device_register_simple("vgem", -1, NULL, 0);
+   if (!vgem_device->platform) {
ret = -ENODEV;
-   goto out;
+   goto out_fini;
}
 
-   dma_coerce_mask_and_coherent(&vgem_platform->dev,
-   DMA_BIT_MASK(64));
+   dma_coerce_mask_and_coherent(&vgem_device->platform->dev,
+DMA_BIT_MASK(64));
 
-   ret  = drm_dev_register(vgem_device, 0);
+   /* Final step: expose the device/driver to userspace */
+   ret  = drm_dev_register(&vgem_device->drm, 0);
if (ret)
-   goto out_unref;
+   goto out_unregister;
 
return 0;
 
-out_unref:
-   platform_device_unregister(vgem_platform);
-out:
-   drm_dev_unref(vgem_device);
+out_unregister:
+   platform_device_unregister(vgem_device->platform);
+out_fini:
+   drm_dev_fini(&vgem_device->drm);
+out_free:
+   kfree(vgem_device);
return ret;
 }
 
 static void __exit vgem_exit(void)
 {
-   platform_device_unregister(vgem_platform);
-   drm_dev_unregister(vgem_device);
-   drm_dev_unref(vgem_device);
+   drm_dev_unregister(&vgem_device->drm);
+   drm_dev_unref(&vgem_device->drm);
 }
 
 module_init(vgem_init);
-- 
2.11.0

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

Re: [RFC v2 1/2] drm/exynos: Add Picture Processor framework

[Emil Velikov]

Hi Marek,

A couple of small nitpicks from UAPI POV.

On 8 May 2017 at 10:11, Marek Szyprowski  wrote:

> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h

> +struct drm_exynos_pp_get_res {
> +   __u64 pp_id_ptr;
> +   __u32 count_pps;
Add __u32 pad - sizeof(struct ...) should be multiple of sizeof(__u64).


> +struct drm_exynos_pp_get {
> +   __u32 pp_id;
> +   __u32 capabilities;
> +
> +   __u32 src_format_count;
> +   __u32 dst_format_count;
> +   __u32 params_count;
> +   __u32 reserved1;
> +
Replace with __u32 flags; so that you can extend the struct as applicable.

> +   __u64 src_format_type_ptr;
> +   __u64 dst_format_type_ptr;
> +   __u64 params_ptr;
> +   __u64 reserved2;
And now you can drop this piece.


> +struct drm_exynos_pp_commit {
> +   __u32 id;
> +   __u32 flags;
> +   __u32 params_count;
> +   __u32 reserved;
Why the reserved here - flags should help you extend as needed.

> +   __u64 param_ids_ptr;
> +   __u64 param_values_ptr;
> +   __u64 user_data;
Unused user_data?


> +struct drm_exynos_pp_event {
> +   struct drm_eventbase;
> +   __u64   user_data;
Unused user_data?

> +   __u32   tv_sec;
> +   __u32   tv_usec;
> +   __u32   pp_id;
> +   __u32   sequence;
> +   __u64   reserved;
Drop in favour of flags?

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

Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel

[Fabio Estevam]

On Tue, Apr 25, 2017 at 1:18 PM, Marco Franchi  wrote:
> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel.
>
> Datasheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they
> require a specific power on/down sequence.
> For this reason the simple panel driver cannot be used to drive this
> panel, so create a new one heavily based on simple panel.
>
> Based on initial patch submission from Breno Lima.
>
> Signed-off-by: Marco Franchi 

Works fine on a imx6sx-sdb board:

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

Re: [PATCH v2 01/28] drm: omapdrm: Remove duplicate error messages when mapping memory

[Laurent Pinchart]

Hi Tomi,

On Monday 08 May 2017 15:52:07 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > The devm_ioremap_resource() call can handle being given a NULL resource,
> > and prints an error message when mapping fails. Switch the remaining
> > devm_ioremap() calls to devm_ioremap_resource() and remove all
> > extraneous resource NULL checks and error messages printed manually by
> > the driver.
> 
> Looks like in some places we check for "!ret" and in some "IS_ERR(ret)"...

Oops :-/

From 94d2a8f445cd298d99ffc4717d2184dcf21e8889 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart 
Date: Sun, 7 May 2017 00:29:09 +0300
Subject: [PATCH v2.1 01/28] drm: omapdrm: Remove duplicate error messages when 
mapping memory

The devm_ioremap_resource() call can handle being given a NULL resource,
and prints an error message when mapping fails. Switch the remaining
devm_ioremap() calls to devm_ioremap_resource() and remove all
extraneous resource NULL checks and error messages printed manually by
the driver.

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

- Fix devm_ioremap_resource() return value checks
---
 drivers/gpu/drm/omapdrm/dss/dispc.c  | 14 +++---
 drivers/gpu/drm/omapdrm/dss/dsi.c| 27 +--
 drivers/gpu/drm/omapdrm/dss/dss.c| 14 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c   |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi_pll.c   |  9 +
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c| 12 +++-
 drivers/gpu/drm/omapdrm/dss/rfbi.c   | 14 +++---
 drivers/gpu/drm/omapdrm/dss/venc.c   | 14 +++---
 drivers/gpu/drm/omapdrm/dss/video-pll.c  | 20 ++--
 11 files changed, 30 insertions(+), 121 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index d956e6266368..59fd6bac4306 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4363,17 +4363,9 @@ static int dispc_bind(struct device *dev, struct device 
*master, void *data)
return r;
 
dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
-   if (!dispc_mem) {
-   DSSERR("can't get IORESOURCE_MEM DISPC\n");
-   return -EINVAL;
-   }
-
-   dispc.base = devm_ioremap(&pdev->dev, dispc_mem->start,
- resource_size(dispc_mem));
-   if (!dispc.base) {
-   DSSERR("can't ioremap DISPC\n");
-   return -ENOMEM;
-   }
+   dispc.base = devm_ioremap_resource(&pdev->dev, dispc_mem);
+   if (IS_ERR(dispc.base))
+   return PTR_ERR(discp.base);
 
dispc.irq = platform_get_irq(dispc.pdev, 0);
if (dispc.irq < 0) {
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index f74615d005a8..5388f798356a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5326,12 +5326,9 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
 
dsi_mem = res;
 
-   dsi->proto_base = devm_ioremap(&dsidev->dev, res->start,
-   resource_size(res));
-   if (!dsi->proto_base) {
-   DSSERR("can't ioremap DSI protocol engine\n");
-   return -ENOMEM;
-   }
+   dsi->proto_base = devm_ioremap_resource(&dsidev->dev, res);
+   if (IS_ERR(dsi->proto_base))
+   return PTR_ERR(dsi->proto_base);
 
res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "phy");
if (!res) {
@@ -5346,12 +5343,9 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
res = &temp_res;
}
 
-   dsi->phy_base = devm_ioremap(&dsidev->dev, res->start,
-   resource_size(res));
-   if (!dsi->phy_base) {
-   DSSERR("can't ioremap DSI PHY\n");
-   return -ENOMEM;
-   }
+   dsi->phy_base = devm_ioremap_resource(&dsidev->dev, res);
+   if (IS_ERR(dsi->phy_base))
+   return PTR_ERR(dsi->phy_base);
 
res = platform_get_resource_byname(dsidev, IORESOURCE_MEM, "pll");
if (!res) {
@@ -5366,12 +5360,9 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
res = &temp_res;
}
 
-   dsi->pll_base = devm_ioremap(&dsidev->dev, res->start,
-   resource_size(res));
-   if (!dsi->pll_base) {
-   DSSERR("can't ioremap DSI PLL\n");
-   return -ENOMEM;
-   }
+   dsi->pll_base = devm_ioremap_resource(&dsidev->dev, res);
+   if (IS_ERR(dsi->pll_base))
+   return PTR_ERR(dsi->pll_base);
 
dsi->irq = platform_get_irq(dsi->pdev, 0);
if (dsi->irq < 0) {
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
inde

Re: [PATCH 1/6] drm/omap: add new connector types

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote:
> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
> because there has not been a proper connector type for them.
> 
> We now have connector type for DPI so let's take it into use. At the
> same time, add better connector types for the remaining outputs too.
> 
> This patch sets the following outputs to use the following connector
> types:
> 
> DPI -> DPI
> DBI -> DPI (MIPI DBI is very similar to DPI at the bus level)

This looks OK to me.

> SDI -> LVDS (SDI is a type of LVDS)

If we're talking about this 
https://en.wikipedia.org/wiki/Serial_digital_interface SDI, it's not a type of 
LVDS at all. DRM_MODE_CONNECTOR_LVDS is interpreted as meaning that an LVDS 
display panel is attached to the device, and is likely not removable. I don't 
think it's a good match for SDI. We might need a new connector type.

> VENC -> SVIDEO (it could also be composite, but we don't have that
> information here, so svideo should be quite good match)

Do we have the information anywhere ?

> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index e1f47f0b3ccf..58c639e1e8e9
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -214,6 +214,13 @@ static int get_connector_type(struct omap_dss_device
> *dssdev) return DRM_MODE_CONNECTOR_DVID;
>   case OMAP_DISPLAY_TYPE_DSI:
>   return DRM_MODE_CONNECTOR_DSI;
> + case OMAP_DISPLAY_TYPE_DPI:
> + case OMAP_DISPLAY_TYPE_DBI:
> + return DRM_MODE_CONNECTOR_DPI;
> + case OMAP_DISPLAY_TYPE_VENC:
> + return DRM_MODE_CONNECTOR_SVIDEO;
> + case OMAP_DISPLAY_TYPE_SDI:
> + return DRM_MODE_CONNECTOR_LVDS;
>   default:
>   return DRM_MODE_CONNECTOR_Unknown;
>   }

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/6] drm/omap: remove unused ovl_enabled()

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 27 Apr 2017 13:27:50 Tomi Valkeinen wrote:
> ovl_enabled() is not used anywhere, so remove it.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 6 --
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
>  2 files changed, 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5ac0145fbae6..9fba92973d0e
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2935,11 +2935,6 @@ static int dispc_ovl_enable(enum omap_plane_id plane,
> bool enable) return 0;
>  }
> 
> -static bool dispc_ovl_enabled(enum omap_plane_id plane)
> -{
> - return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
> -}
> -
>  static enum omap_dss_output_id dispc_mgr_get_supported_outputs(enum
> omap_channel channel) {
>   return dss_feat_get_supported_outputs(channel);
> @@ -4377,7 +4372,6 @@ static const struct dispc_ops dispc_ops = {
>   .mgr_set_gamma = dispc_mgr_set_gamma,
> 
>   .ovl_enable = dispc_ovl_enable,
> - .ovl_enabled = dispc_ovl_enabled,
>   .ovl_set_channel_out = dispc_ovl_set_channel_out,
>   .ovl_setup = dispc_ovl_setup,
>   .ovl_get_color_modes = dispc_ovl_get_color_modes,
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h index b19dae1fd6c5..d9ad33df0455
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -913,7 +913,6 @@ struct dispc_ops {
>   unsigned int length);
> 
>   int (*ovl_enable)(enum omap_plane_id plane, bool enable);
> - bool (*ovl_enabled)(enum omap_plane_id plane);
>   void (*ovl_set_channel_out)(enum omap_plane_id plane,
>   enum omap_channel channel);
>   int (*ovl_setup)(enum omap_plane_id plane,

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 3/6] drm/omap: remove ovl_set_channel_out

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 27 Apr 2017 13:27:51 Tomi Valkeinen wrote:
> At the moment we have ovl_set_channel_out() to configure the output
> channel of an overlay. It makes sense to have this configuration as part
> of the reset of overlay configuration, and in DSS6+ we need the output

Do you mean s/reset/rest/ ?

> channel when doing the other overlay configuration.
> 
> This patch adds 'channel' parameter to ovl_setup(), so that all overlay

s/adds/adds a/

> configuration is done via the same function, and removes the
> ovl_set_channel_out().
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 13 ++---
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  3 ++-
>  drivers/gpu/drm/omapdrm/omap_plane.c  |  6 ++
>  3 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 9fba92973d0e..97f4a1163fbe
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2834,21 +2834,21 @@ static int dispc_ovl_setup_common(enum omap_plane_id
> plane,
> 
>  static int dispc_ovl_setup(enum omap_plane_id plane,
>   const struct omap_overlay_info *oi,
> - const struct videomode *vm, bool mem_to_mem)
> + const struct videomode *vm, bool mem_to_mem,
> + enum omap_channel channel)
>  {
>   int r;
>   enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
> - enum omap_channel channel;
>   const bool replication = true;
> 
> - channel = dispc_ovl_get_channel_out(plane);
> -
>   DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d -
>"
>   " %dx%d, cmode %x, rot %d, mir %d, chan %d repl %d\n",
>   plane, &oi->paddr, &oi->p_uv_addr, oi->screen_width, oi-
>pos_x,
>   oi->pos_y, oi->width, oi->height, oi->out_width, oi-
>out_height,
>   oi->color_mode, oi->rotation, oi->mirror, channel, 
replication);
> 
> + dispc_ovl_set_channel_out(plane, channel);
> +
>   r = dispc_ovl_setup_common(plane, caps, oi->paddr, oi->p_uv_addr,
>   oi->screen_width, oi->pos_x, oi->pos_y, oi->width, oi->height,
>   oi->out_width, oi->out_height, oi->color_mode, oi->rotation,
> @@ -4304,8 +4304,8 @@ static void dispc_errata_i734_wa(void)
>   REG_FLD_MOD(DISPC_CONFIG, 0x1f, 8, 4);
> 
>   /* Setup and enable GFX plane */
> - dispc_ovl_set_channel_out(OMAP_DSS_GFX, OMAP_DSS_CHANNEL_LCD);
> - dispc_ovl_setup(OMAP_DSS_GFX, &ovli, &i734.vm, false);
> + dispc_ovl_setup(OMAP_DSS_GFX, &ovli, &i734.vm, false,
> + OMAP_DSS_CHANNEL_LCD);
>   dispc_ovl_enable(OMAP_DSS_GFX, true);
> 
>   /* Set up and enable display manager for LCD1 */
> @@ -4372,7 +4372,6 @@ static const struct dispc_ops dispc_ops = {
>   .mgr_set_gamma = dispc_mgr_set_gamma,
> 
>   .ovl_enable = dispc_ovl_enable,
> - .ovl_set_channel_out = dispc_ovl_set_channel_out,
>   .ovl_setup = dispc_ovl_setup,
>   .ovl_get_color_modes = dispc_ovl_get_color_modes,
>  };
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h index d9ad33df0455..a2b9b7f29472
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -917,7 +917,8 @@ struct dispc_ops {
>   enum omap_channel channel);

Shouldn't you also remove the .ovl_set_channel_out() operation from this 
structure ?

Apart from that,

Reviewed-by: Reviewed-by: Laurent Pinchart 

>   int (*ovl_setup)(enum omap_plane_id plane,
>const struct omap_overlay_info *oi,
> - const struct videomode *vm, bool mem_to_mem);
> + const struct videomode *vm, bool mem_to_mem,
> + enum omap_channel channel);
> 
>   enum omap_color_mode (*ovl_get_color_modes)(enum omap_plane_id plane);
>  };
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c index 9168154d749e..81d9822f6f4a
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -118,12 +118,10 @@ static void omap_plane_atomic_update(struct drm_plane
> *plane, DBG("%d,%d %pad %pad", info.pos_x, info.pos_y,
>   &info.paddr, &info.p_uv_addr);
> 
> - priv->dispc_ops->ovl_set_channel_out(omap_plane->id,
> -   omap_crtc_channel(state->crtc));
> -
>   /* and finally, update omapdss: */
>   ret = priv->dispc_ops->ovl_setup(omap_plane->id, &info,
> -   omap_crtc_timings(state->crtc), false);
> +   omap_crtc_timings(state->crtc), false,
> +   omap_crtc_channel(state->crtc));
>   if (ret) {
>   dev_err(plane->dev->dev, "Failed to setup plane %s\n",
>   omap_plane->name)

Re: [PATCH 4/6] drm/omap: remove read_irqenable()

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 27 Apr 2017 13:27:52 Tomi Valkeinen wrote:
> We only use read_irqenable() to flush posted write. Instead of having a
> separate function for this, do the flush implicitly in write_irqenable().
> Thus we can remove read_irqenable().
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 9 +++--
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
>  drivers/gpu/drm/omapdrm/omap_irq.c| 1 -
>  3 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 97f4a1163fbe..352fad583571
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -3782,11 +3782,6 @@ static void dispc_clear_irqstatus(u32 mask)
>   dispc_write_reg(DISPC_IRQSTATUS, mask);
>  }
> 
> -static u32 dispc_read_irqenable(void)
> -{
> - return dispc_read_reg(DISPC_IRQENABLE);
> -}
> -
>  static void dispc_write_irqenable(u32 mask)
>  {
>   u32 old_mask = dispc_read_reg(DISPC_IRQENABLE);
> @@ -3795,6 +3790,9 @@ static void dispc_write_irqenable(u32 mask)
>   dispc_clear_irqstatus((mask ^ old_mask) & mask);
> 
>   dispc_write_reg(DISPC_IRQENABLE, mask);
> +
> + /* flush posted write */
> + dispc_read_reg(DISPC_IRQENABLE);
>  }
> 
>  void dispc_enable_sidle(void)
> @@ -4345,7 +4343,6 @@ static void dispc_errata_i734_wa(void)
>  static const struct dispc_ops dispc_ops = {
>   .read_irqstatus = dispc_read_irqstatus,
>   .clear_irqstatus = dispc_clear_irqstatus,
> - .read_irqenable = dispc_read_irqenable,
>   .write_irqenable = dispc_write_irqenable,
> 
>   .request_irq = dispc_request_irq,
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h index a2b9b7f29472..44bf53351e00
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -881,7 +881,6 @@ void dss_mgr_unregister_framedone_handler(enum
> omap_channel channel, struct dispc_ops {
>   u32 (*read_irqstatus)(void);
>   void (*clear_irqstatus)(u32 mask);
> - u32 (*read_irqenable)(void);
>   void (*write_irqenable)(u32 mask);
> 
>   int (*request_irq)(irq_handler_t handler, void *dev_id);
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
> b/drivers/gpu/drm/omapdrm/omap_irq.c index 115104cdcc59..7afe4b90befd
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -41,7 +41,6 @@ static void omap_irq_update(struct drm_device *dev)
>   DBG("irqmask=%08x", irqmask);
> 
>   priv->dispc_ops->write_irqenable(irqmask);
> - priv->dispc_ops->read_irqenable();/* flush posted write */
>  }
> 
>  static void omap_irq_wait_handler(struct omap_irq_wait *wait)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 5/6] drm/omap: 64bit compile fixes

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 27 Apr 2017 13:27:53 Tomi Valkeinen wrote:
> Fix a few type issues that cause compile warnings on 64 bit ARM
> compiler. The change should not affect 32bit platforms.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c| 2 +-
>  drivers/gpu/drm/omapdrm/omap_gem.c   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index 3cab06661a08..1dd3dafc59af
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -388,7 +388,7 @@ struct tiler_block *tiler_reserve_2d(enum tiler_fmt fmt,
> uint16_t w, u32 min_align = 128;
>   int ret;
>   unsigned long flags;
> - size_t slot_bytes;
> + u32 slot_bytes;
> 
>   BUG_ON(!validfmt(fmt));
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
> b/drivers/gpu/drm/omapdrm/omap_fb.c index 29dc677dd4d3..2dca19a0c2ff 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -449,7 +449,7 @@ struct drm_framebuffer *omap_framebuffer_init(struct
> drm_device *dev,
> 
>   if (size > omap_gem_mmap_size(bos[i]) - mode_cmd->offsets[i]) 
{
>   dev_dbg(dev->dev,
> - "provided buffer object is too small! %d < 
%d\n",
> + "provided buffer object is too small! %zu < 
%d\n",
>   bos[i]->size - mode_cmd->offsets[i], size);
>   ret = -EINVAL;
>   goto fail;
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index 68a75b829b71..f076c63e5b08
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -1046,7 +1046,7 @@ void omap_gem_describe(struct drm_gem_object *obj,
> struct seq_file *m) area->p1.x, area->p1.y);
>   }
>   } else {
> - seq_printf(m, " %d", obj->size);
> + seq_printf(m, " %zu", obj->size);
>   }
> 
>   seq_printf(m, "\n");

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/4] dma-buf: Combine two function calls into one in dma_buf_debug_show()

[Gustavo Padovan]

2017-05-08 SF Markus Elfring :

> From: Markus Elfring 
> Date: Mon, 8 May 2017 10:32:44 +0200
> 
> A bit of data was put into a sequence by two separate function calls.
> Print the same data by a single function call instead.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/dma-buf/dma-buf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

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

Re: [PATCH 2/4] dma-buf: Improve a size determination in dma_buf_attach()

[Gustavo Padovan]

2017-05-08 SF Markus Elfring :

> From: Markus Elfring 
> Date: Mon, 8 May 2017 10:50:09 +0200
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/dma-buf/dma-buf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan 

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

Re: [PATCH 6/6] drm/omap: define compat_ioctl

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 27 Apr 2017 13:27:54 Tomi Valkeinen wrote:
> Define compat_ioctl in omapdriver_fops to make it possible to use 32bit
> apps on 64bit platform.
> 
> Signed-off-by: Tomi Valkeinen 

None of the omapdrm custom ioctls seem to need compat handling, so

Reviwed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 58c639e1e8e9..3cfff88c7d79
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -615,6 +615,7 @@ static const struct file_operations omapdriver_fops = {
>   .owner = THIS_MODULE,
>   .open = drm_open,
>   .unlocked_ioctl = drm_ioctl,
> + .compat_ioctl = drm_compat_ioctl,
>   .release = drm_release,
>   .mmap = omap_gem_mmap,
>   .poll = drm_poll,

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 3/4] dma-buf: Adjust a null pointer check in dma_buf_attach()

[Gustavo Padovan]

2017-05-08 SF Markus Elfring :

> From: Markus Elfring 
> Date: Mon, 8 May 2017 10:54:17 +0200
> 
> The script "checkpatch.pl" pointed information out like the following.
> 
> Comparison to NULL could be written "!attach"
> 
> Thus adjust this expression.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/dma-buf/dma-buf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan 

Gustavo

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

Re: [PATCH 4/4] dma-buf: Use seq_putc() in two functions

[Gustavo Padovan]

Hi Markus,

Thank for your patches.

2017-05-08 SF Markus Elfring :

> From: Markus Elfring 
> Date: Mon, 8 May 2017 10:55:42 +0200
> 
> Three single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/dma-buf/sync_debug.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan 

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

Re: [PATCH 1/6] drm/omap: add new connector types

[Tomi Valkeinen]

On 08/05/17 17:21, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote:
>> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
>> because there has not been a proper connector type for them.
>>
>> We now have connector type for DPI so let's take it into use. At the
>> same time, add better connector types for the remaining outputs too.
>>
>> This patch sets the following outputs to use the following connector
>> types:
>>
>> DPI -> DPI
>> DBI -> DPI (MIPI DBI is very similar to DPI at the bus level)
> 
> This looks OK to me.
> 
>> SDI -> LVDS (SDI is a type of LVDS)
> 
> If we're talking about this 
> https://en.wikipedia.org/wiki/Serial_digital_interface SDI, it's not a type 
> of 
> LVDS at all. DRM_MODE_CONNECTOR_LVDS is interpreted as meaning that an LVDS 
> display panel is attached to the device, and is likely not removable. I don't 
> think it's a good match for SDI. We might need a new connector type.

No, it's not that. It's Serial display interface. I think it's
FPDLink/FlatLink.

>> VENC -> SVIDEO (it could also be composite, but we don't have that
>> information here, so svideo should be quite good match)
> 
> Do we have the information anywhere ?

Yes, in the dts. At some point we should use that data, but I didn't
want to start digging the encoder/connector properties here.

 Tomi



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

[Bug 100964] RX-480 [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
Sounds like maybe a power supply issues.  Do you have another power supply you
could try?

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

[RFC v4 00/18] vb2: Handle user cache hints, allow drivers to choose cache coherency

[Sakari Ailus]

Hello,

This is a rebased and partially reworked version of the vb2 cache hints
support patch series posted by first myself, then Laurent and then myself
again.

I'm still posting this as RFC primarily because more testing and driver
changes will be needed. In particular, a lot of platform drivers assume
non-coherent memory but are not properly labelled as such.

Please see the end of the message for detailed changes.

This set unifies the cache coherency hint flags and corrects cache
management in videobuf2 dma-contig and dma-sg memtype implementation. The
support for non-coherent memory is completed: support for MMAP buffers is
added and begin_cpu_access and end_cpu_access functions are added to DMA
ops.

Comments are welcome.

changes since RFC v3:

- Document V4L2_BUF_FLAG_NO_CACHE_SYNC flag behaviour for QBUF and DQBUF
  for CAPTURE and OUTPUT buffers.

- Set queue dma_attrs DMA_ATTR_NON_CONSISTENT flag for omap3isp.

- Put dma_sgt in vb2_dc_buf in order to avoid allocating and releasing it
  separately. It's generally needed anyway.

- Buffer preparation DMA direction is generally DMA_TO_DEVICE for both
  CAPTURE and OUTPUT buffers: V4L2 does not guarantee that the user space
  could not write to capture buffers as well.

  Documentation/DMA-API.txt:

- Before reading values that have been written by DMA from the device
  (use the DMA_FROM_DEVICE direction)
- After writing values that will be written to the device using DMA
  (use the DMA_TO_DEVICE) direction
- before *and* after handing memory to the device if the memory is
  DMA_BIDIRECTIONAL

  Cache maintenance can also be skipped for OUTPUT buffers in buffer
  finish as the hardware did not write to the buffer.

changes since RFC v2:

- Nicer looking tests for the need for syncing.

- Also set DMA attributes for USERPTR buffers.

- Unconditionally assign buf->attrs for MMAP buffers.

- Don't call vb2_dc_get_base_sgt() until buf->dev is set.

- Provide {begin,end}_cpu_access() dmabuf ops for cache management.

- Make similar changes to dma-sg memops to support DMA attributes.


Sakari Ailus (13):
  vb2: Rename confusingly named internal buffer preparation functions
  vb2: Move buffer cache synchronisation to prepare from queue
  vb2: Move cache synchronisation from buffer done to dqbuf handler
  v4l: Unify cache management hint buffer flags
  vb2: Anticipate queue specific DMA attributes for USERPTR buffers
  vb2: dma-contig: Assign DMA attrs for a buffer unconditionally
  vb2: dma-contig: Remove redundant sgt_base field
  vb2: dma-contig: Don't warn on failure in obtaining scatterlist
  vb2: dma-contig: Move vb2_dc_get_base_sgt() up
  vb2: dma-contig: Fix DMA attribute and cache management
  vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs
  vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs
  vb2: Improve struct vb2_mem_ops documentation; alloc and put are for
MMAP

Samu Onkalo (1):
  vb2: Don't sync cache for a buffer if so requested

 Documentation/media/uapi/v4l/buffer.rst|  24 ++--
 .../media/uapi/v4l/vidioc-prepare-buf.rst  |   5 +-
 drivers/media/v4l2-core/videobuf2-core.c   | 129 ++---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 120 ---
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  47 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c   |  14 ++-
 drivers/media/v4l2-core/videobuf2-vmalloc.c|   3 +-
 include/media/videobuf2-core.h |  46 +---
 include/trace/events/v4l2.h|   3 +-
 include/uapi/linux/videodev2.h |   7 +-
 10 files changed, 263 insertions(+), 135 deletions(-)

-- 
Regards,
Sakari



Sakari Ailus (17):
  vb2: Rename confusingly named internal buffer preparation functions
  vb2: Move buffer cache synchronisation to prepare from queue
  vb2: Move cache synchronisation from buffer done to dqbuf handler
  v4l: Unify cache management hint buffer flags
  vb2: Anticipate queue specific DMA attributes for USERPTR buffers
  vb2: dma-contig: Assign DMA attrs for a buffer unconditionally
  vb2: dma-contig: Remove redundant sgt_base field
  vb2: dma-contig: Don't warn on failure in obtaining scatterlist
  vb2: dma-contig: Allocate sgt as part of struct vb2_dc_buf
  vb2: dma-contig: Fix DMA attribute and cache management
  vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs
  vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs
  vb2: Improve struct vb2_mem_ops documentation; alloc and put are for
MMAP
  vb2: Dma direction is always DMA_TO_DEVICE in buffer preparation
  vb2: Do sync plane cache only for CAPTURE buffers in finish memop
  docs-rst: Document precise V4L2_BUF_FLAG_NO_CACHE_SYNC flag behaviour
  v4l: Use non-consistent DMA mappings for hardware that deserves it

Samu Onkalo (1):
  vb2: Don't sync cache for a buffer if so requested

 Documentation/media/uapi

[RFC v4 02/18] vb2: Move buffer cache synchronisation to prepare from queue

[Sakari Ailus]

The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.

Mmap buffers do not need cache synchronisation since they are always
coherent.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 8df680d..8bf3369 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1227,23 +1227,19 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
const void *pb)
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
-   unsigned int plane;
 
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(&q->owned_by_drv_count);
 
trace_vb2_buf_queue(q, vb);
 
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
-
call_void_vb_qop(vb, buf_queue, vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_queue *q = vb->vb2_queue;
+   unsigned int plane;
int ret;
 
if (q->error) {
@@ -1268,11 +1264,19 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
ret = -EINVAL;
}
 
-   if (ret)
+   if (ret) {
dprintk(1, "buffer preparation failed: %d\n", ret);
-   vb->state = ret ? VB2_BUF_STATE_DEQUEUED : VB2_BUF_STATE_PREPARED;
+   vb->state = VB2_BUF_STATE_DEQUEUED;
+   return ret;
+   }
 
-   return ret;
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+
+   vb->state = VB2_BUF_STATE_PREPARED;
+
+   return 0;
 }
 
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
-- 
2.7.4

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

[RFC v4 10/18] vb2: dma-contig: Fix DMA attribute and cache management

[Sakari Ailus]

Patch ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA
attrs") added support for driver specific DMA attributes to
videobuf2-dma-contig but it had several issues in it.

In particular,

- cache operations were only performed on USERPTR buffers,

- DMA attributes were set only for MMAP buffers and

- it did not provide begin_cpu_access() and end_cpu_access() dma_buf_ops
  callbacks for cache syncronisation on exported MMAP buffers.

This patch corrects these issues.

Also arrange the header files alphabetically.

Fixes: ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA attrs")
Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 94 --
 1 file changed, 72 insertions(+), 22 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 0afc3da..8b0298a 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -11,12 +11,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -97,12 +97,13 @@ static void vb2_dc_prepare(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
 
-   /* DMABUF exporter will flush the cache for us */
-   if (!buf->vec)
-   return;
-
-   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
-  buf->dma_dir);
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+  buf->dma_dir);
 }
 
 static void vb2_dc_finish(void *buf_priv)
@@ -110,11 +111,13 @@ static void vb2_dc_finish(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
 
-   /* DMABUF exporter will flush the cache for us */
-   if (!buf->vec)
-   return;
-
-   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
+   buf->dma_dir);
 }
 
 /*/
@@ -142,6 +145,7 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long 
attrs,
  gfp_t gfp_flags)
 {
struct vb2_dc_buf *buf;
+   int ret;
 
if (WARN_ON(!dev))
return ERR_PTR(-EINVAL);
@@ -152,9 +156,9 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long 
attrs,
 
buf->attrs = attrs;
buf->cookie = dma_alloc_attrs(dev, size, &buf->dma_addr,
-   GFP_KERNEL | gfp_flags, buf->attrs);
+ GFP_KERNEL | gfp_flags, buf->attrs);
if (!buf->cookie) {
-   dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
+   dev_err(dev, "dma_alloc_attrs of size %ld failed\n", size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
@@ -167,6 +171,16 @@ static void *vb2_dc_alloc(struct device *dev, unsigned 
long attrs,
buf->size = size;
buf->dma_dir = dma_dir;
 
+   ret = dma_get_sgtable_attrs(buf->dev, &buf->__dma_sgt, buf->cookie,
+   buf->dma_addr, buf->size, buf->attrs);
+   if (ret < 0) {
+   dma_free_attrs(dev, size, buf->cookie, buf->dma_addr,
+  buf->attrs);
+   put_device(dev);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   buf->dma_sgt = &buf->__dma_sgt;
buf->handler.refcount = &buf->refcount;
buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
@@ -339,6 +353,40 @@ static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, 
unsigned long pgnum)
return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
 }
 
+static int vb2_dc_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf,
+ enum dma_data_direction direction)
+{
+   struct vb2_dc_buf *buf = dbuf->priv;
+   struct sg_table *sgt = buf->dma_sgt;
+
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents,
+   buf->dma_dir);
+
+   return 0;
+}
+
+static int vb2_dc_dmabuf_ops_end_cpu_ac

[RFC v4 04/18] v4l: Unify cache management hint buffer flags

[Sakari Ailus]

The V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and V4L2_BUF_FLAG_NO_CACHE_CLEAN
buffer flags are currently not used by the kernel. Replace the definitions
by a single V4L2_BUF_FLAG_NO_CACHE_SYNC flag to be used by further
patches.

Different cache architectures should not be visible to the user space
which can make no meaningful use of the differences anyway. In case a
device can make use of non-coherent memory accesses, the necessary cache
operations depend on the CPU architecture and the buffer type, not the
requests of the user. The cache operation itself may be skipped on the
user's request which was the purpose of the two flags.

On ARM the invalidate and clean are separate operations whereas on
x86(-64) the two are a single operation (flush). Whether the hardware uses
the buffer for reading (V4L2_BUF_TYPE_*_OUTPUT*) or writing
(V4L2_BUF_TYPE_*CAPTURE*) already defines the required cache operation
(clean and invalidate, respectively). No user input is required.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/buffer.rst| 24 --
 .../media/uapi/v4l/vidioc-prepare-buf.rst  |  5 ++---
 include/trace/events/v4l2.h|  3 +--
 include/uapi/linux/videodev2.h |  7 +--
 4 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73..9eb42bd 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -559,23 +559,17 @@ Buffer Flags
:ref:`VIDIOC_PREPARE_BUF `,
:ref:`VIDIOC_QBUF` or
:ref:`VIDIOC_DQBUF ` ioctl is called.
-* .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`:
+* .. _`V4L2-BUF-FLAG-NO-CACHE-SYNC`:
 
-  - ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE``
+  - ``V4L2_BUF_FLAG_NO_CACHE_SYNC``
   - 0x0800
-  - Caches do not have to be invalidated for this buffer. Typically
-   applications shall use this flag if the data captured in the
-   buffer is not going to be touched by the CPU, instead the buffer
-   will, probably, be passed on to a DMA-capable hardware unit for
-   further processing or output.
-* .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
-
-  - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
-  - 0x1000
-  - Caches do not have to be cleaned for this buffer. Typically
-   applications shall use this flag for output buffers if the data in
-   this buffer has not been created by the CPU but by some
-   DMA-capable unit, in which case caches have not been used.
+  - Do not perform CPU cache synchronisation operations when the buffer is
+   queued or dequeued. The user is responsible for the correct use of
+   this flag. It should be only used when the buffer is not accessed
+   using the CPU, e.g. the buffer is written to by a hardware block and
+   then read by another one, in which case the flag should be set in both
+   :ref:`VIDIOC_QBUF` and :ref:`VIDIOC_DQBUF` ioctls. This flag has no
+   effect on some devices / architectures.
 * .. _`V4L2-BUF-FLAG-LAST`:
 
   - ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst 
b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
index bdcfd9f..80aeb7e 100644
--- a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
@@ -36,9 +36,8 @@ pass ownership of the buffer to the driver before actually 
enqueuing it,
 using the :ref:`VIDIOC_QBUF` ioctl, and to prepare it for future I/O. Such
 preparations may include cache invalidation or cleaning. Performing them
 in advance saves time during the actual I/O. In case such cache
-operations are not required, the application can use one of
-``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE`` and
-``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` flags to skip the respective step.
+operations are not required, the application can use the
+``V4L2_BUF_FLAG_NO_CACHE_SYNC`` flag to skip the cache synchronization step.
 
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
index b3a85b3..3d5897d 100644
--- a/include/trace/events/v4l2.h
+++ b/include/trace/events/v4l2.h
@@ -81,8 +81,7 @@ SHOW_FIELD
{ V4L2_BUF_FLAG_ERROR,   "ERROR" },   \
{ V4L2_BUF_FLAG_TIMECODE,"TIMECODE" },\
{ V4L2_BUF_FLAG_PREPARED,"PREPARED" },\
-   { V4L2_BUF_FLAG_NO_CACHE_INVALIDATE, "NO_CACHE_INVALIDATE" }, \
-   { V4L2_BUF_FLAG_NO_CACHE_CLEAN,  "NO_CACHE_CLEAN" },  \
+   { V4L2_BUF_FLAG_NO_CACHE_SYNC,   "NO_CACHE_SYNC" },   \
{ V4L2_BUF_FLAG_TIMESTAMP_MASK,  "TIMESTAMP_MASK" },  \
{ V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN,   "TIMESTAMP_UNKNOWN" },   \
 

[RFC v4 11/18] vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs

[Sakari Ailus]

The scatterlist should always be present when the cache would need to be
flushed. Each buffer type has its own means to provide that. Add
WARN_ON_ONCE() to check the scatterist exists.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 8b0298a..f572911 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -101,7 +101,7 @@ static void vb2_dc_prepare(void *buf_priv)
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
   buf->dma_dir);
 }
@@ -115,7 +115,7 @@ static void vb2_dc_finish(void *buf_priv)
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
buf->dma_dir);
 }
@@ -363,7 +363,7 @@ static int vb2_dc_dmabuf_ops_begin_cpu_access(struct 
dma_buf *dbuf,
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents,
buf->dma_dir);
 
@@ -380,7 +380,7 @@ static int vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf 
*dbuf,
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents,
   buf->dma_dir);
 
-- 
2.7.4

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

[RFC v4 08/18] vb2: dma-contig: Don't warn on failure in obtaining scatterlist

[Sakari Ailus]

vb2_dc_get_base_sgt() which obtains the scatterlist already prints
information on why the scatterlist could not be obtained.

Also, remove the useless warning of a failed kmalloc().

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index ddbbcf0..22636cd 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -370,10 +370,8 @@ static struct sg_table *vb2_dc_get_base_sgt(struct 
vb2_dc_buf *buf)
struct sg_table *sgt;
 
sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
-   if (!sgt) {
-   dev_err(buf->dev, "failed to alloc sg table\n");
+   if (!sgt)
return NULL;
-   }
 
ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
buf->size, buf->attrs);
@@ -400,7 +398,7 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv, 
unsigned long flags)
if (!buf->dma_sgt)
buf->dma_sgt = vb2_dc_get_base_sgt(buf);
 
-   if (WARN_ON(!buf->dma_sgt))
+   if (!buf->dma_sgt)
return NULL;
 
dbuf = dma_buf_export(&exp_info);
-- 
2.7.4

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

[RFC v4 13/18] vb2: Don't sync cache for a buffer if so requested

[Sakari Ailus]

From: Samu Onkalo 

The user may request to the driver (vb2) to skip the cache maintenance
operations in case the buffer does not need cache synchronisation, e.g. in
cases where the buffer is passed between hardware blocks without it being
touched by the CPU.

Also document that the prepare and finish vb2_mem_ops might not get called
every time the buffer ownership changes between the kernel and the user
space.

Signed-off-by: Samu Onkalo 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 101 +--
 drivers/media/v4l2-core/videobuf2-v4l2.c |  14 -
 include/media/videobuf2-core.h   |  23 ---
 3 files changed, 97 insertions(+), 41 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index c659b64..fbe0db1 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -189,6 +189,28 @@ static void __vb2_queue_cancel(struct vb2_queue *q);
 static void __enqueue_in_driver(struct vb2_buffer *vb);
 
 /**
+ * __mem_prepare_planes() - call finish mem op for all planes of the buffer
+ */
+static void __mem_prepare_planes(struct vb2_buffer *vb)
+{
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+}
+
+/**
+ * __mem_finish_planes() - call finish mem op for all planes of the buffer
+ */
+static void __mem_finish_planes(struct vb2_buffer *vb)
+{
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
+}
+
+/**
  * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
  */
 static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
@@ -953,20 +975,29 @@ EXPORT_SYMBOL_GPL(vb2_discard_done);
 /**
  * __prepare_mmap() - prepare an MMAP buffer
  */
-static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb, const void *pb,
+ bool no_cache_sync)
 {
-   int ret = 0;
+   int ret;
 
-   if (pb)
+   if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
 vb, pb, vb->planes);
-   return ret ? ret : call_vb_qop(vb, buf_prepare, vb);
+   if (ret)
+   return ret;
+   }
+
+   if (!no_cache_sync)
+   __mem_prepare_planes(vb);
+
+   return call_vb_qop(vb, buf_prepare, vb);
 }
 
 /**
  * __prepare_userptr() - prepare a USERPTR buffer
  */
-static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb, const void *pb,
+bool no_cache_sync)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1057,6 +1088,11 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
const void *pb)
dprintk(1, "buffer initialization failed\n");
goto err;
}
+
+   /* This is new buffer memory --- always synchronise cache. */
+   __mem_prepare_planes(vb);
+   } else if (!no_cache_sync) {
+   __mem_prepare_planes(vb);
}
 
ret = call_vb_qop(vb, buf_prepare, vb);
@@ -1084,7 +1120,8 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
void *pb)
 /**
  * __prepare_dmabuf() - prepare a DMABUF buffer
  */
-static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb,
+   bool no_cache_sync)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1199,6 +1236,11 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const 
void *pb)
dprintk(1, "buffer initialization failed\n");
goto err;
}
+
+   /* This is new buffer memory --- always synchronise cache. */
+   __mem_prepare_planes(vb);
+   } else if (!no_cache_sync) {
+   __mem_prepare_planes(vb);
}
 
ret = call_vb_qop(vb, buf_prepare, vb);
@@ -1231,10 +1273,10 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
call_void_vb_qop(vb, buf_queue, vb);
 }
 
-static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
+static int __buf_prepare(struct vb2_buffer *vb, const void *pb,
+bool no_cache_sync)
 {
struct vb2_queue *q = vb->vb2_queue;
-   unsigned int plane;
int ret;
 
if (q->error) {
@@ -1246,13 +1288,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
 
switch (q->memory) {
case VB2_MEMORY_MMAP:
-   ret = __prepare_mmap(vb, pb);
+   ret = __prepare_mmap(vb, pb, no_

[RFC v4 17/18] docs-rst: Document precise V4L2_BUF_FLAG_NO_CACHE_SYNC flag behaviour

[Sakari Ailus]

Document when should the user specify V4L2_BUF_FLAG_NO_CACHE_SYNC flag.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/buffer.rst | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 9eb42bd..e1f93dd 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -570,6 +570,27 @@ Buffer Flags
then read by another one, in which case the flag should be set in both
:ref:`VIDIOC_QBUF` and :ref:`VIDIOC_DQBUF` ioctls. This flag has no
effect on some devices / architectures.
+
+   More specifically, this flag causes cache synchronisation to
+   be skipped for OUTPUT buffers when the buffer is queued. The
+   flag can be used if the buffer has been previously written to
+   by hardware but has not been written to by the CPU.
+
+   Additionally, if this flag is specified for a CAPTURE buffer
+   when it is queued, cache synchronisation is skipped. This
+   signals that the application can guarantee that it has not
+   written to the buffer memory since it was last dequeued from
+   the device.
+
+   Specifying this flag for a CAPTURE buffer when
+   dequeueing a buffer will skip cache maintenance for the buffer
+   memory. An application may not access the buffer memory in
+   that case but it may well be passed onwards to another device
+   in the system.
+
+   Specifying this flag has no effect when dequeuing an OUTPUT
+   buffer.
+
 * .. _`V4L2-BUF-FLAG-LAST`:
 
   - ``V4L2_BUF_FLAG_LAST``
-- 
2.7.4

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