Re: [PATCH] drm/tinydrm: Fix drm_driver.fops.owner

2017-03-26 Thread Daniel Vetter 
On Sun, Mar 26, 2017 at 01:56:55AM +0100, Noralf Trønnes wrote:
> 
> Den 25.03.2017 22.32, skrev Daniel Vetter:
> > On Sat, Mar 25, 2017 at 02:56:20PM +0100, Noralf Trønnes wrote:
> > > drm_driver.fops can't be shared since the owner then becomes tinydrm.ko.
> > > Move the fops declaration to the driver.
> > > 
> > > Reported-by: Daniel Vetter 
> > > Signed-off-by: Noralf Trønnes 
> > Since it only "breaks" unloading (and only if you force-unload without
> > knowing what you're doing, which is explicitly a developer feature with a
> > big warning) I think perfectly ok to push this in only for 4.12.
> > 
> > > ---
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 15 ---
> > >   drivers/gpu/drm/tinydrm/mi0283qt.c  | 13 +
> > >   include/drm/tinydrm/tinydrm.h   |  4 +---
> > >   3 files changed, 14 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
> > > b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > > index 6a257dd..fd25c7e5 100644
> > > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > > @@ -122,21 +122,6 @@ void tinydrm_gem_cma_free_object(struct 
> > > drm_gem_object *gem_obj)
> > >   }
> > >   EXPORT_SYMBOL_GPL(tinydrm_gem_cma_free_object);
> > > -const struct file_operations tinydrm_fops = {
> > > - .owner  = THIS_MODULE,
> > > - .open   = drm_open,
> > > - .release= drm_release,
> > > - .unlocked_ioctl = drm_ioctl,
> > > -#ifdef CONFIG_COMPAT
> > > - .compat_ioctl   = drm_compat_ioctl,
> > > -#endif
> > > - .poll   = drm_poll,
> > > - .read   = drm_read,
> > > - .llseek = no_llseek,
> > > - .mmap   = drm_gem_cma_mmap,
> > > -};
> > > -EXPORT_SYMBOL(tinydrm_fops);
> > > -
> > >   static struct drm_framebuffer *
> > >   tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
> > > const struct drm_mode_fb_cmd2 *mode_cmd)
> > > diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
> > > b/drivers/gpu/drm/tinydrm/mi0283qt.c
> > > index b29fe86..fdca37a 100644
> > > --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
> > > +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
> > > @@ -132,9 +132,22 @@ static const struct drm_display_mode mi0283qt_mode = 
> > > {
> > >   TINYDRM_MODE(320, 240, 58, 43),
> > >   };
> > > +static const struct file_operations mi0283qt_fops = {
> > > + .owner  = THIS_MODULE,
> > > + .open   = drm_open,
> > > + .release= drm_release,
> > > + .unlocked_ioctl = drm_ioctl,
> > > + .compat_ioctl   = drm_compat_ioctl,
> > > + .poll   = drm_poll,
> > > + .read   = drm_read,
> > > + .llseek = no_llseek,
> > > + .mmap   = drm_gem_cma_mmap,
> > > +};
> > And then you could use the shiny new DECLARE_DRM_GEM_CMA_FOPS here!
> > 
> > Can you pls respin on top of drm-misc-next?
> 
> Sure, I thought I neeeded to fix this in 4.11 first.

As a rule of thumb, -fixes has the same rules as stable backports. And one
of the guidelines there is that it must be a fix for a real problem, i.e.
something a users could conceivably hit. Entirely theoretic race
condiditions, bugs in module unload code and similar things you'll never
get a bug report for don't qualify.
-Daniel

> 
> Noralf.
> 
> > Thanks, Daniel
> > 
> > > +
> > >   static struct drm_driver mi0283qt_driver = {
> > >   .driver_features= DRIVER_GEM | DRIVER_MODESET | 
> > > DRIVER_PRIME |
> > > DRIVER_ATOMIC,
> > > + .fops   = &mi0283qt_fops,
> > >   TINYDRM_GEM_DRIVER_OPS,
> > >   .lastclose  = tinydrm_lastclose,
> > >   .debugfs_init   = mipi_dbi_debugfs_init,
> > > diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
> > > index cf9ca20..00b800d 100644
> > > --- a/include/drm/tinydrm/tinydrm.h
> > > +++ b/include/drm/tinydrm/tinydrm.h
> > > @@ -58,8 +58,7 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
> > >   .gem_prime_mmap = drm_gem_cma_prime_mmap, \
> > >   .dumb_create= drm_gem_cma_dumb_create, \
> > >   .dumb_map_offset= drm_gem_cma_dumb_map_offset, \
> > > - .dumb_destroy   = drm_gem_dumb_destroy, \
> > > - .fops   = &tinydrm_fops
> > > + .dumb_destroy   = drm_gem_dumb_destroy
> > >   /**
> > >* TINYDRM_MODE - tinydrm display mode
> > > @@ -84,7 +83,6 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
> > >   .type = DRM_MODE_TYPE_DRIVER, \
> > >   .clock = 1 /* pass validation */
> > > -extern const struct file_operations tinydrm_fops;
> > >   void tinydrm_lastclose(struct drm_device *drm);
> > >   void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj);
> > >   struct drm_gem_object *
> > > -- 
> > > 2.10.2
> > > 
> > > ___
> > > dri-devel mailing list

Re: [PATCH v2] drm/tinydrm: Fix drm_driver.fops.owner

2017-03-26 Thread Daniel Vetter 
On Sun, Mar 26, 2017 at 04:25:29PM +0200, Noralf Trønnes wrote:
> drm_driver.fops can't be shared since the owner then becomes tinydrm.ko.
> Move the fops declaration to the driver.
> 
> v2: Use DEFINE_DRM_GEM_CMA_FOPS
> 
> Reported-by: Daniel Vetter 
> Signed-off-by: Noralf Trønnes 

Applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 15 ---
>  drivers/gpu/drm/tinydrm/mi0283qt.c  |  3 +++
>  include/drm/tinydrm/tinydrm.h   |  4 +---
>  3 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
> b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> index 6a257dd..fd25c7e5 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> @@ -122,21 +122,6 @@ void tinydrm_gem_cma_free_object(struct drm_gem_object 
> *gem_obj)
>  }
>  EXPORT_SYMBOL_GPL(tinydrm_gem_cma_free_object);
>  
> -const struct file_operations tinydrm_fops = {
> - .owner  = THIS_MODULE,
> - .open   = drm_open,
> - .release= drm_release,
> - .unlocked_ioctl = drm_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl   = drm_compat_ioctl,
> -#endif
> - .poll   = drm_poll,
> - .read   = drm_read,
> - .llseek = no_llseek,
> - .mmap   = drm_gem_cma_mmap,
> -};
> -EXPORT_SYMBOL(tinydrm_fops);
> -
>  static struct drm_framebuffer *
>  tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
> b/drivers/gpu/drm/tinydrm/mi0283qt.c
> index b29fe86..482ff1c3 100644
> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
> @@ -132,9 +132,12 @@ static const struct drm_display_mode mi0283qt_mode = {
>   TINYDRM_MODE(320, 240, 58, 43),
>  };
>  
> +DEFINE_DRM_GEM_CMA_FOPS(mi0283qt_fops);
> +
>  static struct drm_driver mi0283qt_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
> DRIVER_ATOMIC,
> + .fops   = &mi0283qt_fops,
>   TINYDRM_GEM_DRIVER_OPS,
>   .lastclose  = tinydrm_lastclose,
>   .debugfs_init   = mipi_dbi_debugfs_init,
> diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
> index cf9ca20..00b800d 100644
> --- a/include/drm/tinydrm/tinydrm.h
> +++ b/include/drm/tinydrm/tinydrm.h
> @@ -58,8 +58,7 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
>   .gem_prime_mmap = drm_gem_cma_prime_mmap, \
>   .dumb_create= drm_gem_cma_dumb_create, \
>   .dumb_map_offset= drm_gem_cma_dumb_map_offset, \
> - .dumb_destroy   = drm_gem_dumb_destroy, \
> - .fops   = &tinydrm_fops
> + .dumb_destroy   = drm_gem_dumb_destroy
>  
>  /**
>   * TINYDRM_MODE - tinydrm display mode
> @@ -84,7 +83,6 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
>   .type = DRM_MODE_TYPE_DRIVER, \
>   .clock = 1 /* pass validation */
>  
> -extern const struct file_operations tinydrm_fops;
>  void tinydrm_lastclose(struct drm_device *drm);
>  void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj);
>  struct drm_gem_object *
> -- 
> 2.10.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCHv2 26/31] drm/omap: Create fbdev emulation only for the first DRM connector

2017-03-26 Thread Daniel Vetter 
On Mon, Mar 27, 2017 at 09:28:07AM +0300, Tomi Valkeinen wrote:
> On 25/03/17 23:22, Daniel Vetter wrote:
> > On Fri, Mar 24, 2017 at 11:40:47AM +0200, Tomi Valkeinen wrote:
> >> From: Peter Ujfalusi 
> >>
> >> Add fbdev emulation only for the first DRM connector.
> >> When the fbdev emulation was created for all connectors with different
> >> resolution, the lower res display would only be able to show part of the
> >> framebuffer.
> >> By creating the fbdev emulation only for the first connector we can avoid
> >> this.
> >>
> >> Signed-off-by: Peter Ujfalusi 
> >> Signed-off-by: Tomi Valkeinen 
> > 
> > Why this driver-specific behavior? This is how it works everywhere.
> > 
> > If this doesn't work in some case, then we need to fix this in the fbdev
> > helper. Or have a modparam for that. But definitely not diverging
> > behaviour between drivers.
> 
> The default behavior often results in a rather unusable fbdev on the
> other screen.
> 
> For example, a board with a low-res LCD and HDMI. Fbdev is created based
> in the LCD resolution, and on HDMI you'll get 1080p resolution with a
> tiny fbdev. Or, if fbdev is created based on the HDMI resolution, on the
> LCD you'll see a tiny portion of the huge fbdev.
> 
> I personally did suggest our folks to just disable the fbdev totally,
> but apparently there are still some uses for the fbdev, so this patch
> seemed like a simple way to make the behavior a bit nicer.
> 
> But I agree that it would be best to have this fully configurable, as
> different use cases have different needs. Then again, I'd rather just
> disable the fbdev than start spending time on improving it =).

Yeah I think a module option for  the fbdev helper which implements
exactly this would be fine. Assuming that would make your users happy.

I just want to avoid everyone having to hand-roll the same hacks, since
this problem is the same everywhere (never boot with a retina screen and
the low-res projector plugged in ...).
-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 v5 4/8] drm: Add driver-private objects to atomic state

2017-03-26 Thread Daniel Vetter 
On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran" 
> 
> It is necessary to track states for objects other than connector, crtc
> and plane for atomic modesets. But adding objects like DP MST link
> bandwidth to drm_atomic_state would mean that a non-core object will be
> modified by the core helper functions for swapping and clearing
> it's state. So, lets add void * objects and helper functions that operate
> on void * types to keep these objects and states private to the core.
> Drivers can then implement specific functions to swap and clear states.
> The other advantage having just void * for these objects in
> drm_atomic_state is that objects of different types can be managed in the
> same state array.
> 
> v4: Avoid redundant NULL checks when private_objs array is empty (Maarten)
> v3: Macro alignment (Chris)
> v2: Added docs and new iterator to filter private objects (Daniel)
> 
> Acked-by: Harry Wentland 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_atomic.c| 69 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
>  include/drm/drm_atomic.h| 93 
> +
>  3 files changed, 167 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9b892af..e590148 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> drm_atomic_state *state)
>   kfree(state->connectors);
>   kfree(state->crtcs);
>   kfree(state->planes);
> + kfree(state->private_objs);
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_release);
>  
> @@ -184,6 +185,21 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   state->planes[i].ptr = NULL;
>   state->planes[i].state = NULL;
>   }
> +
> + for (i = 0; i < state->num_private_objs; i++) {
> + void *private_obj = state->private_objs[i].obj;
> + void *obj_state = state->private_objs[i].obj_state;
> +
> + if (!private_obj)
> + continue;
> +
> + state->private_objs[i].funcs->destroy_state(obj_state);
> + state->private_objs[i].obj = NULL;
> + state->private_objs[i].obj_state = NULL;
> + state->private_objs[i].funcs = NULL;
> + }
> + state->num_private_objs = 0;

Here we set num_private_objs = 0;

> +
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
>  
> @@ -978,6 +994,59 @@ static void drm_atomic_plane_print_state(struct 
> drm_printer *p,
>  }
>  
>  /**
> + * drm_atomic_get_private_obj_state - get private object state
> + * @state: global atomic state
> + * @obj: private object to get the state for
> + * @funcs: pointer to the struct of function pointers that identify the 
> object
> + * type
> + *
> + * This function returns the private object state for the given private 
> object,
> + * allocating the state if needed. It does not grab any locks as the caller 
> is
> + * expected to care of any required locking.
> + *
> + * RETURNS:
> + *
> + * Either the allocated state or the error code encoded into a pointer.
> + */
> +void *
> +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
> +   const struct drm_private_state_funcs *funcs)
> +{
> + int index, num_objs, i;
> + size_t size;
> + struct __drm_private_objs_state *arr;
> +
> + for (i = 0; i < state->num_private_objs; i++)
> + if (obj == state->private_objs[i].obj &&
> + state->private_objs[i].obj_state)
> + return state->private_objs[i].obj_state;
> +
> + num_objs = state->num_private_objs + 1;
> + size = sizeof(*state->private_objs) * num_objs;
> + arr = krealloc(state->private_objs, size, GFP_KERNEL);

But here we unconditionally realloc to a presumably smaller size. If you
look at drm_atomic_state->num_connector (which also does dynamic array
realloc), that one works a bit differently (and hence needs these NULL
checks).

I think aligning with how we do things with connectors, for consistency
(no other reason really) would be good.

Just noticed this while reading Maarten's review, which seems to go even
farther away from how we handle this for connectors.
-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: [PATCHv2 31/31] drm/omap: fix crash on module unload

2017-03-26 Thread Tomi Valkeinen 
On 25/03/17 23:25, Daniel Vetter wrote:
> On Fri, Mar 24, 2017 at 11:40:52AM +0200, Tomi Valkeinen wrote:
>> When unloading omapdrm we get a NULL pointer deref in
>> omap_drm_irq_uninstall(). This is caused by:
>>
>> 967dd48417874dd25491a4e933648f394a64f70f ("drm: remove
>> drm_vblank_no_hw_counter assignment from driver code")
>>
>> As OMAP DSS does not have a HW vblank counter, vblank[i].last is anyway
>> always 0, so we can just remove the call to get_vblank_counter().
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_irq.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
>> b/drivers/gpu/drm/omapdrm/omap_irq.c
>> index 26a3c06aa14d..130fdc3225ed 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
>> @@ -299,8 +299,6 @@ void omap_drm_irq_uninstall(struct drm_device *dev)
>>  for (i = 0; i < dev->num_crtcs; i++) {
>>  wake_up(&dev->vblank[i].queue);
>>  dev->vblank[i].enabled = false;
>> -dev->vblank[i].last =
>> -dev->driver->get_vblank_counter(dev, i);
>>  }
>>  spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> 
> Why do you even need to open-code this? Assuming you shut down all crtc
> before unloading (there's a nice new atomic helper for that, soon in
> drm-misc-next), and you properly call drm_crtc_vblank_on/off() in the crtc
> enable/disable functions, this should all behandled for your already ...

Yes, I thought this all felt a bit pointless. But I haven't written that
code and I didn't quite figure out all the details about vblank handling
while going through the code, so I decided to just fix the crash bug for
now.

So there should not be anything in any of the vblank queues if
drm_crtc_vblank_off()s have been called? Yes... Looks like it. Ok, I'll
ensure that we disable the crtcs (we should) when unloading, and update
the patch to drop all that code in the omap_drm_irq_uninstall().

Thanks for pointing this out, I love dropping unneeded code lines =).

 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 v2] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD

2017-03-26 Thread Archit Taneja 

Hi,

On 03/10/2017 03:01 PM, Romain Perier wrote:

Currently, the irq handler that monitores changes for HPD anx RX_SENSE
relies on the status of the bridge for updating the status of the HPD.
The update is done only when the bridge is enabled.

However, on Rockchip platforms we have found use cases where it could be
a problem. When HDMI is being used, turning off/on the screen or
unplugging/re-plugging the cable, the following simplified code path
will happen:

- dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on
hdmi->disabled is false, then the handler will update the rxsense flag
accordingly.
- dw_hdmi_update_power() will be invoked with the mode
DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be
called and the PHY will be desactivated (its pixel clocks and TMDS)

[...]

- dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as
disabled.

- dw_hdmi_irq() will be triggered by an HPD event, as the bridge is
currently disabled the HPD status won't be updated, so hdmi->rxsense
won't be changed. Even if the data part of the PHY is disabled, this
information coming from the HDMI Transmitter is correct and should be
saved.

[...]

- dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as
enabled.
- dw_hdmi_update_power() will be called. When hdmi->force is equal to
DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this
field has not been updated by the irq handler, it will be false and
DRM_FORCE_ON won't be put to hdmi->force.

Consequently, most of the time dw_hdmi_poweron() won't be called in this
use case, TMDS won't be re-enabled the PHY won't be re-initialized,
resulting in a "Signal not found".

This commit fixes the issue by removing the check for "!hdmi->disabled".
As already explained, even if the PHY is partially disabled, information
coming from HDMI Transmitter about HPD should be saved for a later use.


I pushed this to drm-misc-next after incorporating the directory change and
fixing some typos in the commit message.

Thanks,
Archit



Signed-off-by: Romain Perier 
---

Changes in v2:
- I have re-worded the commit message, as suggested by Russel

 drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 3a70016..5b6090c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1793,7 +1793,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
mutex_lock(&hdmi->mutex);
-   if (!hdmi->disabled && !hdmi->force) {
+   if (!hdmi->force) {
/*
 * If the RX sense status indicates we're disconnected,
 * clear the software rxsense status.



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 26/31] drm/omap: Create fbdev emulation only for the first DRM connector

2017-03-26 Thread Tomi Valkeinen 
On 25/03/17 23:22, Daniel Vetter wrote:
> On Fri, Mar 24, 2017 at 11:40:47AM +0200, Tomi Valkeinen wrote:
>> From: Peter Ujfalusi 
>>
>> Add fbdev emulation only for the first DRM connector.
>> When the fbdev emulation was created for all connectors with different
>> resolution, the lower res display would only be able to show part of the
>> framebuffer.
>> By creating the fbdev emulation only for the first connector we can avoid
>> this.
>>
>> Signed-off-by: Peter Ujfalusi 
>> Signed-off-by: Tomi Valkeinen 
> 
> Why this driver-specific behavior? This is how it works everywhere.
> 
> If this doesn't work in some case, then we need to fix this in the fbdev
> helper. Or have a modparam for that. But definitely not diverging
> behaviour between drivers.

The default behavior often results in a rather unusable fbdev on the
other screen.

For example, a board with a low-res LCD and HDMI. Fbdev is created based
in the LCD resolution, and on HDMI you'll get 1080p resolution with a
tiny fbdev. Or, if fbdev is created based on the HDMI resolution, on the
LCD you'll see a tiny portion of the huge fbdev.

I personally did suggest our folks to just disable the fbdev totally,
but apparently there are still some uses for the fbdev, so this patch
seemed like a simple way to make the behavior a bit nicer.

But I agree that it would be best to have this fully configurable, as
different use cases have different needs. Then again, I'd rather just
disable the fbdev than start spending time on improving it =).

 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 06/19] drm/vmwgfx: Drop the cursor locking hack

2017-03-26 Thread Daniel Vetter 
We discussed this quickly on irc, transcribing.

On Mon, Mar 27, 2017 at 5:01 AM, Michel Dänzer  wrote:
> Strictly speaking, the (virtual) hardware is too limited to support the
> legacy KMS cursor API. AFAIR e.g. weston at least used to make use of HW
> cursors for other surfaces, not sure that's currently the case though.

That was disabled again because of lack of atomic (together with all
overlay support if your driver isn't atomic). But atomic/universal
planes allows us to at least model vmwgfx correctly. For each crtc
we'd have one primary plane, but only one global cursor plane that we
attach to the cursor slot of each crtc. Then universal/atomic aware
userspace could realize that there's only 1 cursor plane and make sure
it's not over-used.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/8] drm: Add driver-private objects to atomic state

2017-03-26 Thread Maarten Lankhorst 
Hey,

There are still 2 unnecessary NULL checks, afaict.

Op 22-03-17 om 23:30 schreef Dhinakaran Pandiyan:
> From: "Pandiyan, Dhinakaran" 
>
> It is necessary to track states for objects other than connector, crtc
> and plane for atomic modesets. But adding objects like DP MST link
> bandwidth to drm_atomic_state would mean that a non-core object will be
> modified by the core helper functions for swapping and clearing
> it's state. So, lets add void * objects and helper functions that operate
> on void * types to keep these objects and states private to the core.
> Drivers can then implement specific functions to swap and clear states.
> The other advantage having just void * for these objects in
> drm_atomic_state is that objects of different types can be managed in the
> same state array.
>
> v4: Avoid redundant NULL checks when private_objs array is empty (Maarten)
> v3: Macro alignment (Chris)
> v2: Added docs and new iterator to filter private objects (Daniel)
>
> Acked-by: Harry Wentland 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_atomic.c| 69 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
>  include/drm/drm_atomic.h| 93 
> +
>  3 files changed, 167 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9b892af..e590148 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> drm_atomic_state *state)
>   kfree(state->connectors);
>   kfree(state->crtcs);
>   kfree(state->planes);
> + kfree(state->private_objs);
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_release);
>  
> @@ -184,6 +185,21 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   state->planes[i].ptr = NULL;
>   state->planes[i].state = NULL;
>   }
> +
> + for (i = 0; i < state->num_private_objs; i++) {
> + void *private_obj = state->private_objs[i].obj;
> + void *obj_state = state->private_objs[i].obj_state;
> +
> + if (!private_obj)
> + continue;
^This one.
> + state->private_objs[i].funcs->destroy_state(obj_state);
> + state->private_objs[i].obj = NULL;
> + state->private_objs[i].obj_state = NULL;
> + state->private_objs[i].funcs = NULL;
> + }
> + state->num_private_objs = 0;
> +
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
>  
> @@ -978,6 +994,59 @@ static void drm_atomic_plane_print_state(struct 
> drm_printer *p,
>  }
>  
>  /**
> + * drm_atomic_get_private_obj_state - get private object state
> + * @state: global atomic state
> + * @obj: private object to get the state for
> + * @funcs: pointer to the struct of function pointers that identify the 
> object
> + * type
> + *
> + * This function returns the private object state for the given private 
> object,
> + * allocating the state if needed. It does not grab any locks as the caller 
> is
> + * expected to care of any required locking.
> + *
> + * RETURNS:
> + *
> + * Either the allocated state or the error code encoded into a pointer.
> + */
> +void *
> +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
> +   const struct drm_private_state_funcs *funcs)
> +{
> + int index, num_objs, i;
> + size_t size;
> + struct __drm_private_objs_state *arr;
> +
> + for (i = 0; i < state->num_private_objs; i++)
> + if (obj == state->private_objs[i].obj &&
> + state->private_objs[i].obj_state)
> + return state->private_objs[i].obj_state;
> +
> + num_objs = state->num_private_objs + 1;
> + size = sizeof(*state->private_objs) * num_objs;
> + arr = krealloc(state->private_objs, size, GFP_KERNEL);
> + if (!arr)
> + return ERR_PTR(-ENOMEM);
> +
> + state->private_objs = arr;
> + index = state->num_private_objs;
> + memset(&state->private_objs[index], 0, sizeof(*state->private_objs));
> +
> + state->private_objs[index].obj_state = funcs->duplicate_state(state, 
> obj);
> + if (!state->private_objs[index].obj_state)
> + return ERR_PTR(-ENOMEM);
> +
> + state->private_objs[index].obj = obj;
> + state->private_objs[index].funcs = funcs;
> + state->num_private_objs = num_objs;
> +
> + DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
> +  state->private_objs[index].obj_state, state);
> +
> + return state->private_objs[index].obj_state;
> +}
> +EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
> +
> +/**
>   * drm_atomic_get_connector_state - get connector state
>   * @state: global atomic state object
>   * @connector: connector to get state object for
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/

Re: [PATCH 1/2] drm/bridge: ti-tfp410: support hpd via gpio

2017-03-26 Thread Archit Taneja 

Hi,

On 03/07/2017 03:21 AM, Christopher Spinrath wrote:

Hi Fabio,

On 03/06/2017 10:46 PM, Fabio Estevam wrote:

Hi Christopher,

On Mon, Mar 6, 2017 at 6:40 PM,   wrote:

From: Christopher Spinrath 

On some boards the hpd pin of a hdmi connector is wired up to a gpio
pin. Since in the DRM world the tfp410 driver is responsible for
handling the connector, add support for hpd gpios in this very driver.

Signed-off-by: Christopher Spinrath 
---
 drivers/gpu/drm/bridge/ti-tfp410.c | 72 --


It would be nice to add 'hpd-gpios' property in the binding doc as well:
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt


The hpd-gpios property does *not* belong to the ti,tfp410 binding but to the 
hdmi-connector one
where it is already documented:
Documentation/devicetree/bindings/display/connector/hdmi-connector.txt

Unfortunatly, there is no dedicated driver for the connector in Linux; the 
connector properties have
to be handled by the encoder (here  the tfp410) driver. Note that this already 
happens for the
ddc-i2c-bus property.



The patch looks good to me.

Jyri,

Is it possible for you to verify this on Beaglebone platform?

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

2017-03-26 Thread Michel Dänzer 
On 23/03/17 07:32 PM, Thomas Hellstrom wrote:
> On 03/23/2017 11:10 AM, Daniel Vetter wrote:
>> On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
>>> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
 On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
>> On 03/22/2017 10:50 PM, Daniel Vetter wrote:
>>> It's been around forever, no one bothered to address the FIXME, so I
>>> presume it's all fine.
>>>
>>> Cc: Sinclair Yeh 
>>> Cc: Thomas Hellstrom 
>>> Signed-off-by: Daniel Vetter 
>> NAK. We need to properly address this. Probably as part of the atomic
>> update.
> So could someone with vmwgfx understanding explain this? Note that the
> FIXME was originally added by me years ago, because I wasn't sure (only
> about 90%) that this is safe, and was essentially pleading for a vmwgfx
> expert to review this?
>
> Since it didn't happen I presume it's not that terribly and probably safe
> ...
>
> I'm still 90% sure that this is correct, but I'd love for a vmwgfx to
> audit it. Replying with a NAK is kinda not the response I was hoping for
> (and yes I guess I should have explained what's going on here better, but
> it's just a git blame of the FIXME comment away).
>>> So the code has been left in place because it works. Altering it now
>>> will create unnecessary merge conflicts with the atomic code, and the
>>> change isn't tested and audited which means we need to drop focus from
>>> what we're doing and audit and test code that isn't going to be used
>>> anyway for not apparent reason? But otoh put in the below context there
>>> indeed is a reason.
>>>
>>> From a quick audit of the existing code it seems like at least
>>> vmw_cursor_update_position is touching global device state so I think at
>>> a minimum we need to take a spinlock in that function. Otherwise it
>>> seems to be safe.
>> Note that you're holding the crtc lock already, which gives you exclusion
>> against concurrent page_flips, mode_sets and property changes. Note also
>> that page_flips themselves also only hold the crtc lock, so you can run
>> multiple page_flips in parallel on different crtc (iirc vmwgfx has
>> multiple crtc, if not this discussion is entirely moot).
>>
>> tbh I'd be surprised if my patch really breaks something that hasn't been
>> a pre-existing issue for a long time. The original commit which added this
>> FIXME comment is from 2012. Note also that because it's a hack, you
>> already have a pretty a real race with the core drm state keeping, and no
>> one seems to have hit that either.
>>
>> I mean I can dig through vmwgfx code and do the audit, but it'll take a
>> few hours and vmwgfx is it's own world, so much harder to understand (for
>> me).
>>
> 
> I'm thinking of the situation when someone would call a cursor_set ioctl
> in parallell for two crtcs at the same time and race writing the
> position registers?
> Note that the device has only a single global cursor.
> Admittedly the effects of a race would probably be small, but I'd rather
> see it being properly protected.

Indeed, as long as userspace uses cursor positions (and images) on each
CRTC which are consistent with a single cursor in a single framebuffer,
it shouldn't matter in which order they write the registers. And if the
per-CRTC positions aren't consistent like that, locking won't help either.

Strictly speaking, the (virtual) hardware is too limited to support the
legacy KMS cursor API. AFAIR e.g. weston at least used to make use of HW
cursors for other surfaces, not sure that's currently the case though.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] xf86drm: remove memory leaks in drmGetBusid/drmGetReservedContextList

2017-03-26 Thread Seung-Woo Kim 
In error path of drmGetBusid() and drmGetReservedContextList(),
there are memory leaks for error path. So this removes them.

Signed-off-by: Seung-Woo Kim 
---
 xf86drm.c |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 88f86ed..685cf69 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -994,8 +994,10 @@ char *drmGetBusid(int fd)
 if (drmIoctl(fd, DRM_IOCTL_GET_UNIQUE, &u))
 return NULL;
 u.unique = drmMalloc(u.unique_len + 1);
-if (drmIoctl(fd, DRM_IOCTL_GET_UNIQUE, &u))
+if (drmIoctl(fd, DRM_IOCTL_GET_UNIQUE, &u)) {
+drmFree(u.unique);
 return NULL;
+}
 u.unique[u.unique_len] = '\0';
 
 return u.unique;
@@ -1523,14 +1525,12 @@ drm_context_t *drmGetReservedContextList(int fd, int 
*count)
 
 if (!(list   = drmMalloc(res.count * sizeof(*list
 return NULL;
-if (!(retval = drmMalloc(res.count * sizeof(*retval {
-drmFree(list);
-return NULL;
-}
+if (!(retval = drmMalloc(res.count * sizeof(*retval
+goto err_free_list;
 
 res.contexts = list;
 if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res))
-return NULL;
+goto err_free_context;
 
 for (i = 0; i < res.count; i++)
 retval[i] = list[i].handle;
@@ -1538,6 +1538,12 @@ drm_context_t *drmGetReservedContextList(int fd, int 
*count)
 
 *count = res.count;
 return retval;
+
+err_free_list:
+drmFree(list);
+err_free_context:
+drmFree(retval);
+return NULL;
 }
 
 void drmFreeReservedContextList(drm_context_t *pt)
-- 
1.7.4.1

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

linux-next: manual merge of the kspp tree with the drm-misc tree

2017-03-26 Thread Stephen Rothwell 
Hi Kees,

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

  include/drm/drm_drv.h

between commit:

  91faa0478b59 ("drm: drop extern from function decls")

from the drm-misc tree and commit:

  6bbaac116552 ("initify: Mark functions with the __nocapture attribute")

from the kspp tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/drm/drm_drv.h
index 53b98321df9b,ade960c65929..
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@@ -510,19 -403,11 +510,19 @@@ struct drm_driver 
int num_ioctls;
const struct file_operations *fops;
  
 +  /* Everything below here is for legacy driver, never use! */
 +  /* private: */
 +
/* List of devices hanging off this driver with stealth attach. */
struct list_head legacy_dev_list;
 +  int (*firstopen) (struct drm_device *);
 +  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);
 +  int dev_priv_size;
  };
  
- __printf(6, 7)
 -extern __printf(6, 7) __nocapture(4)
++__printf(6, 7) __nocapture(4)
  void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

2017-03-26 Thread Michel Dänzer 
On 25/03/17 03:59 AM, Julien Isorce wrote:
> Hi Michel,
> 
> I double checked and you are right, the change 0 -> i works. 

Thanks for testing, fix submitted for review.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one

2017-03-26 Thread Ilia Mirkin 
On Sun, Mar 26, 2017 at 6:14 PM, Ben Skeggs  wrote:
> On 03/19/2017 06:23 AM, Ilia Mirkin wrote:
>>
>> The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
>> and PCI varieties, rather than a core PCIE chip with a bridge for
>> AGP/PCI as necessary. As a result, it appears that the MMU is also
>> non-functional. For AGP cards, the vast majority of the NV4A lineup,
>> this worked out since we force AGP cards to use the nv04 mmu. However
>> for PCI variants, this did not work.
>>
>> Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
>> the suggestion. This should be a no-op for NV4A AGP boards, as they were
>> using it already.
>
> This is probably fine for NV4A in that case (more below).
>
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
>> Signed-off-by: Ilia Mirkin 
>> Cc: sta...@vger.kernel.org
>> ---
>>
>> OK, so I'm not 100% sure about my claims, but I don't have the necessary
>> hardware to test it out. Right now, AGP nv41+ boards are getting the nv04
>> mmu, while PCI nv41+ boards are getting the PCIE one. Perhaps this works
>> for them, however such boards are rare, and I don't have one. Perhaps all
>> PCI boards should be routed to the nv04 mmu, not just the NV4A ones.
>
> I wonder if it wouldn't be useful to also change the checks in nv41/nv44
> implementations to be "if (device->type != NVKM_DEVICE_PCIE ..." too?

So ... mwk and I were talking about it, and we weren't sure. Were
there non-NV4A, non-IGP PCI boards? And if so, if it's a PCIE <-> PCI
thing that translates the bus transactions, the GPU-side MMU should
still be there, no? (Is there anything PCIE-specific going on?) In
case you can't tell, I'm well past the edge of my understanding of how
all this works...

Perhaps you could check if you have such a board, or if they're purely
mythical? If such boards do exist, see what happens when you plug it
in and boot nouveau with it. My issues with NV4A were immediate - the
fifo basically didn't initialize. If the boards are mythical, then we
can just change nv44/nv41 to check for != PCIE.

Cheers,

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

Re: [PATCH] drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one

2017-03-26 Thread Ben Skeggs 

On 03/19/2017 06:23 AM, Ilia Mirkin wrote:

The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
and PCI varieties, rather than a core PCIE chip with a bridge for
AGP/PCI as necessary. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.

Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.

This is probably fine for NV4A in that case (more below).



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
Signed-off-by: Ilia Mirkin 
Cc: sta...@vger.kernel.org
---

OK, so I'm not 100% sure about my claims, but I don't have the necessary
hardware to test it out. Right now, AGP nv41+ boards are getting the nv04
mmu, while PCI nv41+ boards are getting the PCIE one. Perhaps this works
for them, however such boards are rare, and I don't have one. Perhaps all
PCI boards should be routed to the nv04 mmu, not just the NV4A ones.
I wonder if it wouldn't be useful to also change the checks in nv41/nv44 
implementations to be "if (device->type != NVKM_DEVICE_PCIE ..." too?


Ben.



 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 273562d..0fc41db 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -714,7 +714,7 @@ nv4a_chipset = {
.i2c = nv04_i2c_new,
.imem = nv40_instmem_new,
.mc = nv44_mc_new,
-   .mmu = nv44_mmu_new,
+   .mmu = nv04_mmu_new,
.pci = nv40_pci_new,
.therm = nv40_therm_new,
.timer = nv41_timer_new,


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

Re: [PATCH v2 0/5] Thunderbolt GPU fixes

2017-03-26 Thread Lukas Wunner 
On Sat, Mar 25, 2017 at 10:06:03PM +0100, Daniel Vetter wrote:
> On Sat, Mar 25, 2017 at 09:05:20AM +0100, Lukas Wunner wrote:
> > Dear drm-misc maintainers,
> > 
> > please consider merging this series:
> 
> I think I pinged you in private already, but want to become drm-misc
> committer so that you don't have to wait for lazy maintainers to get
> around to merging patch series which are ready?

Sure. \o/

I've resurrected this old request for an fdo account as that seems
to be a prerequisite:

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

I'm digging into the dim documentation meanwhile...

Thanks!

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

[Bug 89906] Account request for DRM

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=89906

Lukas Wunner  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mcla...@redhat.com
   |.org|
Product|DRI |accountsservice
  Component|DRM/other   |general
Version|DRI git |unspecified
 CC||marius.voll...@redhat.com,
   ||rstr...@redhat.com,
   ||st...@gnome.org

--- Comment #4 from Lukas Wunner  ---
Resurrecting this old account request to be able to become a drm-misc
committer, as suggested by danvet here:

Message-Id: <20170325210542.pmriu3oycyg5spkk@phenom.ffwll.local>
Link: https://lists.freedesktop.org/archives/dri-devel/2017-March/136913.html

An fdo account seems to be a prerequisite for drm-misc committership according
to:

https://cgit.freedesktop.org/drm/drm-intel/tree/drm-misc.rst?h=maintainer-tools#n26

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

[Bug 89906] Account request for DRM

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=89906

--- Comment #3 from Lukas Wunner  ---
Created attachment 130467
  --> https://bugs.freedesktop.org/attachment.cgi?id=130467&action=edit
ssh public key (4096 bit)

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

[Bug 89906] Account request for DRM

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=89906

Lukas Wunner  changed:

   What|Removed |Added

 Attachment #114867|ssh public key  |ssh public key (2048 bit)
description||
 Attachment #114867|0   |1
is obsolete||

-- 
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 v2] drm/tinydrm: Fix drm_driver.fops.owner

2017-03-26 Thread Noralf Trønnes 
drm_driver.fops can't be shared since the owner then becomes tinydrm.ko.
Move the fops declaration to the driver.

v2: Use DEFINE_DRM_GEM_CMA_FOPS

Reported-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 15 ---
 drivers/gpu/drm/tinydrm/mi0283qt.c  |  3 +++
 include/drm/tinydrm/tinydrm.h   |  4 +---
 3 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 6a257dd..fd25c7e5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -122,21 +122,6 @@ void tinydrm_gem_cma_free_object(struct drm_gem_object 
*gem_obj)
 }
 EXPORT_SYMBOL_GPL(tinydrm_gem_cma_free_object);
 
-const struct file_operations tinydrm_fops = {
-   .owner  = THIS_MODULE,
-   .open   = drm_open,
-   .release= drm_release,
-   .unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
-   .compat_ioctl   = drm_compat_ioctl,
-#endif
-   .poll   = drm_poll,
-   .read   = drm_read,
-   .llseek = no_llseek,
-   .mmap   = drm_gem_cma_mmap,
-};
-EXPORT_SYMBOL(tinydrm_fops);
-
 static struct drm_framebuffer *
 tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
  const struct drm_mode_fb_cmd2 *mode_cmd)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index b29fe86..482ff1c3 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -132,9 +132,12 @@ static const struct drm_display_mode mi0283qt_mode = {
TINYDRM_MODE(320, 240, 58, 43),
 };
 
+DEFINE_DRM_GEM_CMA_FOPS(mi0283qt_fops);
+
 static struct drm_driver mi0283qt_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
  DRIVER_ATOMIC,
+   .fops   = &mi0283qt_fops,
TINYDRM_GEM_DRIVER_OPS,
.lastclose  = tinydrm_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
index cf9ca20..00b800d 100644
--- a/include/drm/tinydrm/tinydrm.h
+++ b/include/drm/tinydrm/tinydrm.h
@@ -58,8 +58,7 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
.gem_prime_mmap = drm_gem_cma_prime_mmap, \
.dumb_create= drm_gem_cma_dumb_create, \
.dumb_map_offset= drm_gem_cma_dumb_map_offset, \
-   .dumb_destroy   = drm_gem_dumb_destroy, \
-   .fops   = &tinydrm_fops
+   .dumb_destroy   = drm_gem_dumb_destroy
 
 /**
  * TINYDRM_MODE - tinydrm display mode
@@ -84,7 +83,6 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
.type = DRM_MODE_TYPE_DRIVER, \
.clock = 1 /* pass validation */
 
-extern const struct file_operations tinydrm_fops;
 void tinydrm_lastclose(struct drm_device *drm);
 void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj);
 struct drm_gem_object *
-- 
2.10.2

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

[Bug 193651] Amdgpu error messages at boot with Amd RX460

2017-03-26 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=193651

--- Comment #19 from fin4...@hotmail.com ---
Created attachment 23
  --> https://bugzilla.kernel.org/attachment.cgi?id=23&action=edit
Kernel 4.11-rc3 config file for RX400 series, add drivers for your hardware

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

[Bug 193651] Amdgpu error messages at boot with Amd RX460

2017-03-26 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=193651

--- Comment #18 from fin4...@hotmail.com ---
(In reply to Milo from comment #17)

> So it  built as version 4.10.0-rc5-gec3fa8e6ca19. When I booted from it,
> after 20 minutes the screen was still blank so I rebooted.

All your software must in sync, so use Debian testing Xfce, Oibaf ppa yakkety
version and latest kernels. I will post my kernel 4.11-rc config.

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

[Bug 100400] Game Valhalla Hills crash on startup

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100400

--- Comment #5 from beham.christop...@gmx.at ---
Created attachment 130465
  --> https://bugs.freedesktop.org/attachment.cgi?id=130465&action=edit
Source files packagecreation archlinux with enabled debug

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

[Bug 100400] Game Valhalla Hills crash on startup

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100400

--- Comment #4 from beham.christop...@gmx.at ---
Created attachment 130464
  --> https://bugs.freedesktop.org/attachment.cgi?id=130464&action=edit
cpuinfo

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

[Bug 100400] Game Valhalla Hills crash on startup

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100400

--- Comment #3 from beham.christop...@gmx.at ---
Created attachment 130463
  --> https://bugs.freedesktop.org/attachment.cgi?id=130463&action=edit
lspci

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

[Bug 100400] Game Valhalla Hills crash on startup

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100400

--- Comment #2 from beham.christop...@gmx.at ---
Created attachment 130462
  --> https://bugs.freedesktop.org/attachment.cgi?id=130462&action=edit
glxinfo

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

[Bug 100400] Game Valhalla Hills crash on startup

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100400

--- Comment #1 from beham.christop...@gmx.at ---
Created attachment 130461
  --> https://bugs.freedesktop.org/attachment.cgi?id=130461&action=edit
gdb output of running and backtracing the game logged with script

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

[Bug 100400] Game Valhalla Hills crash on startup

2017-03-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100400

Bug ID: 100400
   Summary: Game Valhalla Hills crash on startup
   Product: Mesa
   Version: 17.0
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: beham.christop...@gmx.at
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 130460
  --> https://bugs.freedesktop.org/attachment.cgi?id=130460&action=edit
Output of the game execution logged with script

The Game Valhalla Hills crashes for me on Mesa 17.0.2 on Archlinux.

I tried the mesa packages from the standard archlinux extra repo.
To get a little bit more information I added the line '--enable-debug \' to
./configure in the mesa_archlinux_package_source_files and created the packages
and installed the packages mesa and mesa-vdpau, except from builded with
enabled debug these packages are the same as from the standard archlinux extra
repo.

The attached file run is the output of executing:
ST_DEBUG=tgsi MESA_DEBUG=1 LIBGL_DEBUG=verbose ./ValhallaHills-Linux-Shipping

The attached file gdb is the output of executing:
ST_DEBUG=tgsi MESA_DEBUG=1 LIBGL_DEBUG=verbose gdb
./ValhallaHills-Linux-Shipping

I also tried to play with MESA_GL_VERSION_OVERRIDE (the game seems to need at
least 3.2) and MESA_GLSL_VERSION_OVERRIDE (the game seems to need at least 150)
but with no effects on the error outputs.

The game works very well when using the amdgpu-pro driver version 16.60.379184
and turning off vsync in the game options. But I want to keep Mesa because of
the need to downgrade packages for amdgpu-pro and bad performance on Grid
Autosport. 

The game also works with an old nvidia GeForce GT240 in my old PC in my cellar
with both nvidia version 340 and mesa nouveau driver, with colour and blinking
light issues but quite playable.

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

RE: [PATCH v2] drm: Add description for scdc variable

2017-03-26 Thread Sharma, Shashank 
Thanks, V5 will do the trick for sure :-)

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Saturday, March 25, 2017 11:30 PM
To: Sharma, Shashank 
Cc: dri-devel@lists.freedesktop.org; Daniel Vetter 
Subject: Re: [PATCH v2] drm: Add description for scdc variable

On Sat, Mar 25, 2017 at 11:21:29AM +0200, Shashank Sharma wrote:
> This patch adds description about 'scdc' variable in drm_hdmi_info 
> structure, to fix this warning during doc-build.
> 
> "drm_connector.h:140: warning: No description found for parameter 'scdc'"
> 
> V2: Rebase
> 
> Cc: Daniel Vetter 
> Signed-off-by: Shashank Sharma 

Since you're bikeshedding this to v4 already, might as well jump in too
:-)
> ---
>  include/drm/drm_connector.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h 
> index f8b766d..9fba967 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -133,6 +133,8 @@ struct drm_scdc {
>   * This information is available in CEA-861-F extension blocks (like 
> HF-VSDB).
>   */
>  struct drm_hdmi_info {
> +

Please no empty line here.

> + /* @scdc: sink's scdc support and capabilities */

One-line struct member kerneldoc works, but you need to prefix it with /** like 
any other kernel-doc comment. See

https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#in-line-member-documentation-comments

Cheers, Daniel

>   struct drm_scdc scdc;
>  };
>  
> --
> 2.7.4
> 

-- 
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 193651] Amdgpu error messages at boot with Amd RX460

2017-03-26 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=193651

--- Comment #17 from Milo (milo...@gmail.com) ---
(In reply to fin4478 from comment #16)
> (In reply to Milo from comment #15)
> 
> > 
> > I tried the above but notice that it fails when trying to build headers. 
> 
> You do not need kernel headers unless you are using some dkms drivers.
> Currently there is a temperature bug in wip kernel. 4.11-rc3 kernel from
> kernel.org works. 
> 
> Some kernel version headers build failed because missing BUG-REPORTS file.
> Create the file into the linux directory.

Thanks.

Yes I do have some dkms packages installed that need headers. As you suggested,
creating REPORTING-BUGS solved the headers build fail.

So it  built as version 4.10.0-rc5-gec3fa8e6ca19. When I booted from it, after
20 minutes the screen was still blank so I rebooted.

I had built 4.9.10 before from kernel.org which after 10 minutes eventually
booted into X. I used this .config along with you comments in comment #8 to
build 4.10.0-rc5-gec3fa8e6ca19.

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