give atomic state
> and let the driver determine what it does and does not need from it.
>
> Eventually all atomic functions should do this, but that's just too much
> busy work for me.
>
> Changes in v3:
> - Added to the set
>
> Cc: Daniel Vetter
> Cc: Vi
dd forward of drm_gem_object to drm_framebuffer.h (Noralf)
> - Drop "drm: move DRM_IF_VERSION to drm_internal.h" as it is applied to
> drm-misc
> - Drop "drm: make drm_file.h self contained" as Jan made a similar patch that
> was appleid to drm-misc
> - Rebased on
.h.
>
> In the files touched sort the include files
>
> Build tested on x86 and arm allmodconfig / allyesconfig.
>
> Signed-off-by: Sam Ravnborg
> Cc: Greg Kroah-Hartman
> Cc: Hans de Goede
> Cc: Daniel Vetter
Hi Greg,
Ack for merging this through drm-misc? I t
ce-de...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Reviewed-by: Emil Velikov
Reviewed-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
dr
If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers.
Also remove all the flag usage from non-legacy drivers.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc:
On Thu, Jan 24, 2019 at 10:46:47AM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2019 at 06:00:15PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty muc
On Wed, Jan 23, 2019 at 06:00:15PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> > Having the probe helper stuff (which pretty much everyone needs) in
> > the drm_crtc_helper.h file (which atomic drivers
eah in the process of splitting up drmP.h we've created a few smaller
such piles of headers. I think in some cases it's just not going to be
worth it to fully split them up, e.g. drm_crtc_helper.h is going to be
a pure legacy helper, only needed by pre-atomic drivers. Splitting
that up doesn't seem to useful to me. Similarly we might want
drm_atomic_helper.h to keep pulling in the other helper headers. So
probably going to be a judgement call on a case-by-case basis.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Jan 21, 2019 at 11:03:44AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> On Mon, Jan 21, 2019 at 10:35 AM Daniel Vetter wrote:
> > On Fri, Jan 18, 2019 at 05:22:58PM +0100, Geert Uytterhoeven wrote:
> > > Since its incarnation in v3.7 almost 7 years
On Fri, Jan 18, 2019 at 05:22:58PM +0100, Geert Uytterhoeven wrote:
> Since its incarnation in v3.7 almost 7 years ago, no users of the SH
> Mobile DRM driver have appeared.
>
> Hence remove the driver. It can be resurrected from git history,
> if/when needed.
>
> Signed-off-by: Geert Uytterhoev
_helper.h| 27 +++
> This on the other hand is fine - as expected as this is a new file.
>
> But the above is just some random comments so:
>
> Acked-by: Sam Ravnborg
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
y headers, so the change is simple.
>
> While at it, remove unneeder inclusion of other headers, and unneeded
> forward declarations of structures.
>
> Signed-off-by: Laurent Pinchart
Nice, first driver where all that header cleanup work finally lead
somewhere useful!
Acked-by: Da
On Mon, Dec 10, 2018 at 02:40:25PM +0100, Benjamin Gaignard wrote:
> Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
> a écrit :
> >
> > Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> > a écrit :
> > >
> > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Dan
On Thu, Nov 29, 2018 at 3:45 PM Linus Walleij wrote:
>
> On Mon, Nov 26, 2018 at 3:12 PM Daniel Vetter wrote:
> > On Sat, Nov 24, 2018 at 10:17:13PM +0100, Linus Walleij wrote:
>
> > > It was especially scary.
> > >
> > > But I think I managed to apply
On Sat, Nov 24, 2018 at 10:17:13PM +0100, Linus Walleij wrote:
> On Wed, Nov 21, 2018 at 10:42 AM Daniel Vetter wrote:
> > On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote:
> > > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos
> > > wrote:
> > >
On Wed, Nov 21, 2018 at 08:21:29PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday, 21 November 2018 11:42:33 EET Daniel Vetter wrote:
> > On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote:
> > > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos
t;. That's what this patch
> > series is
> > about.
>
> The series:
> Reviewed-by: Linus Walleij
Since your reviewed it all, and there's a pile of acks for the driver
parts too: Want to go ahead and apply it too?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Oct 22, 2018 at 01:51:35PM +0530, Souptick Joarder wrote:
> Hi Laurent,
>
> On Thu, Oct 11, 2018 at 1:48 PM Daniel Vetter wrote:
> >
> > On Mon, Oct 08, 2018 at 09:57:52PM +0530, Souptick Joarder wrote:
> > > Hi Laurent,
> > > On Mon, Oct 1
On Mon, Oct 08, 2018 at 09:57:52PM +0530, Souptick Joarder wrote:
> Hi Laurent,
> On Mon, Oct 1, 2018 at 6:12 PM Noralf Trønnes wrote:
> >
> >
> > Den 01.10.2018 13.56, skrev Laurent Pinchart:
> > > Hi Daniel,
> > >
> > > On Monday, 1 October 20
rv.h
> > >> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index b3a25e8..ff25c8d 100644
> > >> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > >> @@ -78,7 +78,6 @@ struct rcar_du_device {
> > >> struct drm_device *ddev;
> > >> struct drm_fbdev_cma *fbdev;
> > >>
> > >> - struct drm_atomic_state *suspend_state;
> > >>
> > >> struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
> > >> unsigned int num_crtcs;
> > >> diff --git a/include/drm/drm_fb_cma_helper.h
> > >> b/include/drm/drm_fb_cma_helper.h index 4a65f0d..8dbbe1e 100644
> > >> --- a/include/drm/drm_fb_cma_helper.h
> > >> +++ b/include/drm/drm_fb_cma_helper.h
> > >> @@ -26,8 +26,6 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct
> > >> drm_device *dev,
> > >>
> > >> void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma);
> > >> void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma *fbdev_cma);
> > >> -void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma
> > >> *fbdev_cma,
> > >> - bool state);
> > >>
> > >> struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
> > >> drm_framebuffer *fb,
> > >> unsigned int plane);
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote:
> On 2018-05-15 12:22, Daniel Vetter wrote:
> > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin wrote:
> >> On 2018-05-14 18:28, Daniel Vetter wrote:
> >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Ros
On Mon, May 14, 2018 at 10:40 PM, Peter Rosin wrote:
> On 2018-05-14 18:28, Daniel Vetter wrote:
>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>>> On 2018-05-10 10:10, Andrzej Hajda wrote:
>>>> On 04.05.2018 15:52, Peter Rosin wrote:
>>>>
n using "<->", do you have a reference?
> But I guess the different arrow notations in math are somewhat overloaded
> and that someone at some point must have used "<->" to indicate a
> symmetric relationship...
Yeah I agree with Andrzej here, for me <-> implies a symmetric
relationship. Spelling it out like Andrzej suggested sounds like the
better idea.
-Daniel
>
> > Anyway:
> > Reviewed-by: Andrzej Hajda
>
> Thanks!
>
> Cheers,
> Peter
>
> > --
> > Regards
> > Andrzej
> >
> >> * @funcs: control functions
> >> * @driver_private: pointer to the bridge driver's internal context
> >> */
> >> @@ -271,6 +272,7 @@ struct drm_bridge {
> >>struct drm_bridge *next;
> >>struct list_head list;
> >>const struct drm_bridge_timings *timings;
> >> + struct device_link *link;
> >>
> >>const struct drm_bridge_funcs *funcs;
> >>void *driver_private;
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
> drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> drivers/gpu/drm/sti/sti_hda.c | 1 +
> drivers/gpu/drm/sti/sti_hdmi.c | 1 +
> include/drm/drm_bridge.h | 8 +++
> 30 files changed, 57 insertions(+), 36 deletions(-)
>
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; > index b656e505d11e..804189c63a4c 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> > * @list: to keep track of all added bridges
> > * @timings: the timing specification for the bridge, if any (may
> > * be NULL)
> > + * @link: drm consumer <-> bridge supplier
> > * @funcs: control functions
> > * @driver_private: pointer to the bridge driver's internal context
> > */
> > @@ -271,6 +272,7 @@ struct drm_bridge {
> > struct drm_bridge *next;
> > struct list_head list;
> > const struct drm_bridge_timings *timings;
> > + struct device_link *link;
> >
> > const struct drm_bridge_funcs *funcs;
> > void *driver_private;
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 01, 2018 at 10:58:02AM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 30-04-18 om 16:56 schreef Daniel Vetter:
> > On Mon, Apr 30, 2018 at 04:55:24PM +0200, Daniel Vetter wrote:
> >> On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchar
stent bridge supplier.
>
> Signed-off-by: Peter Rosin
Minus the ->owner bikeshed I brought up in the previous patch I agree with
this approach as the best way to move forward for now.
Acked-by: Daniel Vetter
One small suggestion below, for merging I'd say pls get Jyri's
review/t
> if (previous && (!previous->dev || previous->encoder != encoder))
> return -EINVAL;
>
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
dp_bridge.c | 1 +
> > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> > drivers/gpu/drm/rcar-du/rcar_lvds.c| 2 +-
> > drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> > drivers/gpu/drm/sti/sti_hda.c | 1 +
> > drivers/gpu/drm/sti/sti_hdmi.c | 1 +
> > include/drm/drm_bridge.h | 8
> > 27 files changed, 51 insertions(+), 33 deletions(-)
>
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 30, 2018 at 04:55:24PM +0200, Daniel Vetter wrote:
> On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > (Removing the linux-media mailing list from CC as it is out of scope)
> >
> > You enquired on IRC whether thi
; drivers/media/platform/vsp1/vsp1_pipe.c | 6 +-
> > drivers/media/platform/vsp1/vsp1_pipe.h | 6 +-
> > drivers/media/platform/vsp1/vsp1_regs.h | 46 -
> > drivers/media/platform/vsp1/vsp1_rpf.c| 6 +-
> > drivers/media/platform/vsp1/vsp1_rwpf.c | 6 +-
> > drivers/media/platform/vsp1/vsp1_rwpf.h | 6 +-
> > drivers/media/platform/vsp1/vsp1_sru.c| 6 +-
> > drivers/media/platform/vsp1/vsp1_sru.h| 6 +-
> > drivers/media/platform/vsp1/vsp1_uds.c| 6 +-
> > drivers/media/platform/vsp1/vsp1_uds.h| 6 +-
> > drivers/media/platform/vsp1/vsp1_uif.c| 271 +++
> > drivers/media/platform/vsp1/vsp1_uif.h| 32
> > drivers/media/platform/vsp1/vsp1_video.c | 6 +-
> > drivers/media/platform/vsp1/vsp1_video.h | 6 +-
> > drivers/media/platform/vsp1/vsp1_wpf.c| 6 +-
> > include/media/vsp1.h | 39 -
> > 44 files changed, 896 insertions(+), 417 deletions(-)
> > create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c
> > create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
eram.h| 95
>> 15 files changed, 1 insertion(+), 993 deletions(-)
>> delete mode 100644 drivers/video/fbdev/sh_mobile_meram.c
>> delete mode 100644 include/video/sh_mobile_meram.h
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_dev_unref(dev);
> + drm_dev_put(dev);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 94b99c90425a..259c85fcd32c 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -312,7 +312,7 @@ static int vc4_drm_bind(struct device *dev)
> vc4_gem_destroy(drm);
> vc4_bo_cache_destroy(drm);
> dev_unref:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> return ret;
> }
>
> @@ -327,7 +327,7 @@ static void vc4_drm_unbind(struct device *dev)
>
> drm_mode_config_cleanup(drm);
>
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> }
>
> static const struct component_master_ops vc4_drm_ops = {
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2524ff116f00..305f87665499 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -505,7 +505,7 @@ static int __init vgem_init(void)
> static void __exit vgem_exit(void)
> {
> drm_dev_unregister(&vgem_device->drm);
> - drm_dev_unref(&vgem_device->drm);
> + drm_dev_put(&vgem_device->drm);
> }
>
> module_init(vgem_init);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> index 7df8d0c9026a..094b876f6da6 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> @@ -85,6 +85,6 @@ int drm_virtio_init(struct drm_driver *driver, struct
> virtio_device *vdev)
> return 0;
>
> err_free:
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
> return ret;
> }
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 6f4205e80378..02ae1caf6e8a 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -122,7 +122,7 @@ static int zx_drm_bind(struct device *dev)
> component_unbind_all(dev, drm);
> out_unregister:
> dev_set_drvdata(dev, NULL);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> return ret;
> }
>
> @@ -136,7 +136,7 @@ static void zx_drm_unbind(struct device *dev)
> drm_mode_config_cleanup(drm);
> component_unbind_all(dev, drm);
> dev_set_drvdata(dev, NULL);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> }
>
> static const struct component_master_ops zx_drm_master_ops = {
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index d23dcdd1bd95..c16dd4424b8a 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -622,7 +622,6 @@ void drm_dev_unregister(struct drm_device *dev);
>
> void drm_dev_get(struct drm_device *dev);
> void drm_dev_put(struct drm_device *dev);
> -void drm_dev_unref(struct drm_device *dev);
> void drm_put_dev(struct drm_device *dev);
> void drm_dev_unplug(struct drm_device *dev);
>
> --
> 2.14.1
>
> ___
> 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
piod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> > + gpiod_get_direction(pb->enable_gpio) != 0)
> > gpiod_direction_output(pb->enable_gpio, 1);
> >
> > pb->power_supply = devm_regulator_get(&pdev->dev, "power");
> > --
> > 2.11.0
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Mar 21, 2018 at 10:52:19AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday, 21 March 2018 10:34:33 EET Daniel Vetter wrote:
> > On Tue, Mar 20, 2018 at 01:24:09PM +0200, Laurent Pinchart wrote:
> > > Hi Ulrich,
> > >
> > > Thank y
On Tue, Mar 20, 2018 at 01:32:17PM +0200, Laurent Pinchart wrote:
> Hello,
>
> On Monday, 19 March 2018 18:41:05 EET Ulrich Hecht wrote:
> > On Fri, Mar 16, 2018 at 9:55 AM, Daniel Vetter wrote:
> > > On Thu, Mar 15, 2018 at 03:45:36PM +0100, Ulrich Hecht wrote:
> >
(native -> upscaled or 2 different upscaled
versions).
-Daniel
>
> > for_each_pipe_with_valid_output(display, pipe, output) {
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> 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
> tests/kms_panel_fitting.c | 1 +
> tests/kms_plane_lowres.c | 1 +
> 5 files changed, 35 insertions(+), 26 deletions(-)
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedeskto
igt_require(is_i915_device(fd));
> - gem_set_tiling(fd, gem_bo_small, I915_TILING_X, 1024*4);
> + gem_set_tiling(fd, gem_bo_small, I915_TILING_X, 512*4);
> igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
>
On Thu, Mar 15, 2018 at 03:45:37PM +0100, Ulrich Hecht wrote:
> Add is_i915_device() requirement to tests using Intel-specific APIs.
>
> Signed-off-by: Ulrich Hecht
Reviewed-by: Daniel Vetter
> ---
> tests/kms_addfb_basic.c | 3 +++
> 1 file changed, 3 insertions(+)
>
On Thu, Mar 15, 2018 at 03:45:38PM +0100, Ulrich Hecht wrote:
> Fixes false negatives on non-i915 platforms.
>
> Signed-off-by: Ulrich Hecht
Reviewed-by: Daniel Vetter
> ---
> tests/kms_panel_fitting.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tes
_8) == 0)
> + igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB,
> &f_8.fb_id) == 0);
> f.fb_id = 0;
> }
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.free
list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> 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
nk with the next patch changed per my suggestion you could drop this
one here outright, and still retain all the benefits of your cleanup.
-Daniel
>
> Cc: Keith Packard
> Cc: Daniel Vetter
> Cc: Hans de Goede
> Cc: Shashank Sharma
> Cc: Stefan Agner
> Cc: Thierry Redin
e zpos
> field from the rcar_du_vsp_plane_state structure. Remove it.
>
> Fixes: 2fc4d838aaf2 ("drm: rcar: use generic code for managing zpos plane
> property")
> Signed-off-by: Laurent Pinchart
More Cc: helps sometimes, e.g. dim fixes autoadds all you ever want :-)
Revie
> > [ 44.003597] Console: switching to colour frame buffer device 128x48
> > [ 54.240707] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
> > [CRTC:58:crtc-3] flip_done timed out
> > [ 64.480706] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
&
On Thu, Sep 28, 2017 at 11:16 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Thursday, 28 September 2017 10:10:34 EEST Daniel Vetter wrote:
>> On Wed, Sep 27, 2017 at 07:58:42PM +0100, Kieran Bingham wrote:
>> > Hi Laurent,
>> >
>> > Thankyou for the pa
dev_dbg(dev->dev, "%s: plane can't be fully off-screen\n",
> > + __func__);
> > + return -EINVAL;
> > + }
> > +
> > *format = rcar_du_format_info(state->fb->format->format);
> > if (*format == NULL) {
> > dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Sep 15, 2017 at 08:23:19PM +0300, Laurent Pinchart wrote:
> Gentle review ping.
Reviewed-by: Daniel Vetter on both.
Please push to drm-misc or wherever.
Thanks, Daniel
>
> On Tuesday, 15 August 2017 16:05:45 EEST Laurent Pinchart wrote:
> > Since commit 4a97a3da42
as-soc@vger.kernel.org
Didn't compile-test, but looks correct now.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 57
> -
> 1 file changed, 28 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/d
It's dead code, the core handles all this directly now. This also
allows us to unexport drm_atomic_helper_plane_set_property.
Signed-off-by: Daniel Vetter
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: Mali DP Maintainers
Cc: Boris Brezillon
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Pau
On Thu, Jul 20, 2017 at 11:53:39AM +0200, Maxime Ripard wrote:
> Hi Daniel,
>
> On Tue, Jul 18, 2017 at 09:35:03AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 18, 2017 at 9:07 AM, Maxime Ripard
> > wrote:
> > > On Mon, Jul 17, 2017 at 02:57:19PM +0800, Chen-Yu Tsa
On Tue, Jul 18, 2017 at 2:47 PM, Laurent Pinchart
wrote:
> On Tuesday 18 Jul 2017 14:08:39 Daniel Vetter wrote:
>> On Tue, Jul 18, 2017 at 01:14:12PM +0300, Laurent Pinchart wrote:
>> > On Tuesday 18 Jul 2017 09:05:22 Maxime Ripard wrote:
>> >> On Fri, Jul 14, 201
/planes/enable
> - DRM_PLANE_COMMIT_ACTIVE_ONLY vs. all CRTCs
> - drm_atomic_helper_wait_for_vblanks vs drm_atomic_helper_wait_for_flip_done
>
> Maybe we could add a few CRTC commit helper flags along the line of
> DRM_PLANE_COMMIT_ACTIVE_ONLY, add a field to the drm_crtc structure to store
> them, and have drm_atomic_helper_commit_tail() use those flags to control the
> sequence of operations.
Why not write your own? Yes it's a bit of copypaste, but imo that's really
not horrible. I'm already not happy with the flags for commit_planes
because the docs for them are not great and it's hard to know when to use
them and when not to.
->commit_tail was specifically done to allow drivers to overwrite the hw
commit stage without having to reinvent all the other commit tracking. I
expect most non-simple drivers to have their own commit_tail function.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
for example).
You can upgrade any property change to an atomic modeset by e.g.
setting connector->mode_changed (and then making sure to call
check_modeset() helper again perhaps). This is for cases where your hw
can't handle a property change within 1 vblank. The default is jus
n't fit, just redo in your driver. Goal
should be that shared parts are good for about 90% of
drivers/use-cases (maybe even less, there's so many special
cases).
tldr; I still think the _runtime_pm variant is the recommended way to do this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
-git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index f0a8678ae98e..9ff64c6d3043 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -41,6 +41,7 @@ int drm_atomic_helper_check_planes(struct drm_device *dev,
> int drm_atomic_helper_check(struct drm_device *dev,
> struct drm_atomic_state *state);
> void drm_atomic_helper_commit_tail(struct drm_atomic_state *state);
> +void drm_atomic_helper_commit_tail_runtime_pm(struct drm_atomic_state
> *state);
> int drm_atomic_helper_commit(struct drm_device *dev,
>struct drm_atomic_state *state,
>bool nonblock);
> --
> git-series 0.9.1
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
planes.
> */
> rgrp->num_planes = rgrp->num_crtcs + 7;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> index 8b91dd3a46e4..f62e09f195de 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/dr
7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
> idx = rcar_du_plane_hwalloc(plane, plane_state,
> free & crtc_planes);
> if (idx < 0)
> - idx = rcar_du_plane_hwalloc(plane, plane_state,
> + idx = rcar_du_plane_hwalloc(plane, new_plane_state,
> free);
> if (idx < 0) {
> dev_dbg(rcdu->dev, "%s: no available hardware plane\n",
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ha to 1 for the plane when it's not
> matched?
I think generic color-key for plane compositioning would be nice, but I'm
not sure that's possible due to differences in how the key works.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t;state->event;
> + crtc->state->event = NULL;
> + spin_unlock_irqrestore(&dev->event_lock, flags);
> + }
> +
> if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> rcar_du_vsp_atomic_flush(rcrtc);
> }
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Mar 02, 2017 at 02:30:09AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote:
> > On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote:
> > > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote
ep 1
> >
> > I have no idea what this means.
>
> The existing code has bugs. We got as far as applying the testcases to
> demonstrate the bugs, the actual fix is still queued.
Hm, I thought I merged them all. What's missing?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote:
> On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote:
> > Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be
> > enough, or not? My idea is to use this for the case where the only
> > thi
On Wed, Jan 4, 2017 at 2:08 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote:
>> On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote:
>> > On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote:
>> >>
On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote:
> > > The LVDS encoder driver is a DRM bridge driver that suppor
On Tue, Dec 13, 2016 at 07:19:15PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 13 Dec 2016 18:11:34 Daniel Vetter wrote:
> > On Tue, Dec 13, 2016 at 02:59:48PM +0200, Laurent Pinchart wrote:
> > > From: Laurent Pinchart
> > >
> > > Th
nction and call drm_dev_alloc() and
> drm_dev_register() explicitly.
>
> For consistency inline the .unload() handler in the remove function as
> well.
>
> Signed-off-by: Laurent Pinchart
> Acked-by: Daniel Vetter
> ---
> Changes since v1:
>
> - Removed manual the dr
loc() and
> drm_dev_register() explicitly.
>
> For consistency inline the .unload() handler in the remove function as
> well.
>
> Signed-off-by: Laurent Pinchart
Yay, another put_dev gone.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206
> +
On Tue, Nov 29, 2016 at 07:49:22PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 11:27:20 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> > > On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> &
ching them all here, but that's a bit intrusive and should be
> tested correctly. The patch series is already growing big, could we do that
> in
> a separate patch ?
I think you're bridge-for-panels driver is the first one that's actually
getting chained. I guess you do have to fix this here ;-) And if you go
through with making drm_bridge_detach be a purely drm.ko internal thing,
we can make it recursive like all the other functions. Problem solved.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> > > The drm_bridge object models on- or off-chip hardware encoders and
> > >
On Tue, Nov 29, 2016 at 11:43:19AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > > Instead of linking encoders and bridges in every driver (an
__
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
cted;
> +}
We have piles of this exact dummy callback all over, maybe make it the
default and rip them all out?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ector->encoder = encoder;
>
> drm_connector = (struct drm_connector *)connector;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index c3ff10f559cc..ce071c17134b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -219,6 +219,7 @@ int sun4i_rgb_init(struct drm_device *drm)
> struct sun4i_drv *drv = drm->dev_private;
> struct sun4i_tcon *tcon = drv->tcon;
> struct drm_encoder *encoder;
> + struct drm_bridge *bridge;
> struct sun4i_rgb *rgb;
> int ret;
>
> @@ -229,8 +230,8 @@ int sun4i_rgb_init(struct drm_device *drm)
> encoder = &rgb->encoder;
>
> tcon->panel = sun4i_tcon_find_panel(tcon->dev->of_node);
> - encoder->bridge = sun4i_tcon_find_bridge(tcon->dev->of_node);
> - if (IS_ERR(tcon->panel) && IS_ERR(encoder->bridge)) {
> + bridge = sun4i_tcon_find_bridge(tcon->dev->of_node);
> + if (IS_ERR(tcon->panel) && IS_ERR(bridge)) {
> dev_info(drm->dev, "No panel or bridge found... RGB output
> disabled\n");
> return 0;
> }
> @@ -271,16 +272,12 @@ int sun4i_rgb_init(struct drm_device *drm)
> }
> }
>
> - if (!IS_ERR(encoder->bridge)) {
> - encoder->bridge->encoder = &rgb->encoder;
> -
> - ret = drm_bridge_attach(drm, encoder->bridge);
> + if (!IS_ERR(bridge)) {
> + ret = drm_bridge_attach(encoder, bridge, NULL);
> if (ret) {
> dev_err(drm->dev, "Couldn't attach our bridge\n");
> goto err_cleanup_connector;
> }
> - } else {
> - encoder->bridge = NULL;
> }
>
> return 0;
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 530a1d6e8cde..94e5ee96b3b5 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -201,7 +201,8 @@ struct drm_bridge {
> int drm_bridge_add(struct drm_bridge *bridge);
> void drm_bridge_remove(struct drm_bridge *bridge);
> struct drm_bridge *of_drm_find_bridge(struct device_node *np);
> -int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge);
> +int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> + struct drm_bridge *previous);
> void drm_bridge_detach(struct drm_bridge *bridge);
>
> bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
of using
> a forward declaration.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_encoder.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
>
tain a
> forward declaration of struct drm_encoder in order to allow including it
> as the first header in a compilation unit.
>
> Signed-off-by: Laurent Pinchart
Assuming it all still compiles the various defconfigs we have (I didn't
check that, but lgtm otherwise):
Reviewed
f --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 29e4b400e25e..881bf489478b 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -735,8 +735,6 @@ void vc4_plane_async_set_fb(struct drm_plane *plane,
> struct drm_fr
On Thu, Aug 04, 2016 at 10:57:29AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 11:50:27AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> > > On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > > > On Thu, Jun 30, 2
On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> >> Backlights controlled by i915.ko and only associated with its connectors
> >> and al
OK, I see.
> But, I will keep Cc to you for this patch-set.
Archit Tajena is the maintainer of last resort for anything related to
drm_bridge.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+0x5d/0x70
> [ 18.984349] [] drm_fb_helper_initial_config+0x25f/0x3f0
> [ 18.984388] [] intel_fbdev_initial_config+0x18/0x30
> [i915]
> [ 18.984389] [] async_run_entry_fn+0x48/0x150
> [ 18.984391] [] process_one_work+0x1e7/0x750
> [ 18.984392] [] ? process_one_wo
register_all() to drm_dev_register() and not suffer
> from any backwards compatibility issues with drivers not following the
> more rigorous init ordering.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: dri-de...@lists
On Fri, Jun 10, 2016 at 05:24:12PM +0200, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:48:01PM +0200, Boris Brezillon wrote:
> > For all outputs except dp_mst, we have a 1:1 relationship between
> > connectors and encoders and the driver is relying on the atomic helpers:
>
gpu/drm/tegra/hdmi.c | 1 -
> drivers/gpu/drm/tegra/output.c | 8
> drivers/gpu/drm/tegra/rgb.c| 1 -
> drivers/gpu/drm/tegra/sor.c| 1 -
> drivers/gpu/drm/vc4/vc4_dpi.c | 9 -
> drivers/gpu/drm/vc4/vc4_hdmi.c | 9 -
> drivers/gpu/drm/virtio/virtgpu_display.c | 10 --
> include/drm/drm_modeset_helper_vtables.h | 10 --
> 50 files changed, 24 insertions(+), 305 deletions(-)
>
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 223129d..47fe241 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1512,7 +1512,6 @@ static const struct drm_connector_funcs
> intel_tv_connector_funcs = {
> static const struct drm_connector_helper_funcs
> intel_tv_connector_helper_funcs = {
> .mode_valid = intel_tv_mode_valid,
> .get_modes = intel_tv_get_modes,
> - .best_encoder = intel_best_encoder,
> };
>
> static const struct drm_encoder_funcs intel_tv_enc_funcs = {
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
uncs {
>* need to select the best encoder depending upon the desired
>* configuration and can't select it statically.
>*
> - * This function is used by drm_atomic_helper_check_modeset() and either
> - * this or @best_encoder is required.
> +
On Fri, Jun 03, 2016 at 09:37:43AM +0200, Boris Brezillon wrote:
> On Thu, 2 Jun 2016 23:57:02 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> > wrote:
> > > Hi Boris,
> > >
> > > Thank you for the patch.
&g
connector_funcs->best_encoder(connector);
>> +
>> + /*
>> + * If the DRM device implements atomic hooks and ->best_encoder() is
>> + * NULL we fallback to the default drm_atomic_helper_best_encoder()
>> + * helper.
>> + */
>> + if (fb_helper-
p;scrtc->crtc, event);
> > drm_vblank_put(dev, 0);
> > }
> > spin_unlock_irqrestore(&dev->event_lock, flags);
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
onnectors that makes sense (since users need
to know whether it's the hdmi or DP plug), but for internal panels I'd
honestly just go with lvds for anything that's not a more complex standard
like eDP or DSI.
Just my 2 cents really, not strong opinion, and we'll not run
On Fri, Apr 22, 2016 at 12:00:39AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Thursday 21 Apr 2016 18:10:25 Daniel Vetter wrote:
> > On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> > > Make the Z-order of VSP planes configurable through the zpos
> unsigned int alpha;
> + unsigned int zpos;
There's lots of effort by various people to create a generic zpos/blending
set of properties. Care to jump onto that effort and making it finally
happen for real? I kinda don't want to have a propliferation of slightly
diffferent zpos/blending props across all the drivers ...
-Daniel
> };
>
> static inline struct rcar_du_vsp_plane_state *
> --
> 2.7.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ins of both register_ and unregister_all()
> * Updated commit messages (mostly spellos and grammar issues)
>
> Changes v1 -> v2:
> * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> * Use drm_for_each_connector() instead of list_for_each_entry()
> *
rivers/gpu/drm/udl/udl_drv.c| 2 +-
> include/drm/drm_crtc.h | 5 ++-
> 6 files changed, 64 insertions(+), 61 deletions(-)
>
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Boris Brezillon
> Cc: Laurent Pinchart
> Cc: linux-renesas-soc@vger.kernel.org
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 8
> drivers/gpu/drm/sti/sti_crtc.c | 9 -
> drivers/gpu/drm/udl/udl_modeset.c | 9 -
> drivers/gpu/drm/virtio/virtgpu_display.c | 8
> 22 files changed, 12 insertions(+), 158 deletions(-)
>
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
c,
> >> }
> >>
> >> static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
> >> - .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
> >>.mode_set = drm_helper_crtc_mode_set,
> >>.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
> >>.mode_set_base = drm_helper_crtc_mode_set_base,
> >> @@ -349,4 +341,3 @@ fail:
> >>atmel_hlcdc_crtc_destroy(&crtc->base);
> >>return ret;
> >> }
> >> -
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
adjusted_mode))) {
>
>You haven't run the patch thru scripts/checkpatch.pl, have you? :-)
> (It curses on assignment inside the *if* expression.)
pre-existing, so checkpatch.pl doesn't get a vote ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
1 - 100 of 101 matches
Mail list logo
