On Thu, Sep 24, 2020 at 05:15:00PM +0100, Qais Yousef wrote:
> On 09/24/20 10:49, Daniel Vetter wrote:
>
> [...]
>
> > > > I also thought kernel threads can be distinguished from others, so
> > > > userspace shouldn't be able to sneak in and get elevate
cking up patches and
cleaning up drivers for compile testing! Very much appreciated.
I think for now we can just leave fbdev in drm-misc, with people
picking up patches ad-hoc (and maintainers serving as fallbacks).
Reviewed-by: Daniel Vetter
I guess you'll push this yourself as the last
On Wed, Sep 23, 2020 at 07:33:17PM -0700, Rob Clark wrote:
> On Wed, Sep 23, 2020 at 8:25 AM Daniel Vetter wrote:
> >
> > On Tue, Sep 22, 2020 at 07:48:10AM -0700, Rob Clark wrote:
> > > On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote:
> > > >
> &g
ped out the notifier
in the middle that was angering lockdep completely, so not it's at
least fixable. But this still needs someone to sit down and come up
with something that works.
Locking is one, but in general there's all kinds of resizing fun when
you switch modes through
On Tue, Sep 22, 2020 at 07:48:10AM -0700, Rob Clark wrote:
> On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote:
> >
> > On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote:
> > >
> > > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> > > >
>
gt; mutex_unlock(&vgasr_mutex);
> pci_wakeup_bus(pdev->bus);
> - ret = dev->bus->pm->runtime_resume(dev);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return dev->bus->pm->runtime_resume(dev);
> }
>
> /**
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
oder
> *encoder)
> cr_tries = 0;
>
> DRM_DEBUG_KMS("\n");
> - reg = DP | DP_LINK_TRAIN_PAT_2;
> + reg = DP | DP_LINK_TRAIN_PAT_2;
>
> for (;;) {
>
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Sep 21, 2020 at 07:55:42AM -0700, Rob Clark wrote:
> On Mon, Sep 21, 2020 at 2:23 AM Daniel Vetter wrote:
> >
> > On Sat, Sep 19, 2020 at 12:37:25PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > This will allow us to more ea
On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote:
>
> On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> >
> > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The android userspace treats the disp
t; + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned i;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + return crtc->worker;
> +
> + return NULL;
> +}
> +
> /**
> * drm_atomic_crtc_needs_modeset - compute combined modeset need
> * @state: &drm_crtc_state for the CRTC
> --
> 2.26.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 31
> include/drm/drm_crtc.h | 10
> include/uapi/drm/drm.h | 13 ++
> 7 files changed, 117 insertions(+), 4 deletions(-)
>
> --
> 2.26.2
>
> ___
> 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
? And use cross-module notifiers/calls
> > > > ? I did that with amdkfd and amdgpu/radeon a couple of years back. It
> > > > worked (that's the best thing I can say about it).
> > >
> > > That's fine with me.
> > >
> > > > The main problem with this "virtual bus" thing is that I'm not
> > > > familiar with it at all and from my experience I imagine it would take
> > > > a considerable time and effort to upstream this infrastructure work.
> > >
> > > It shouldn't be taking that long, but for some unknown reason, the
> > > original author of that code is sitting on it and not resending it. Go
> > > poke them through internal Intel channels to find out what the problem
> > > is, as I have no clue why a 200-300 line bus module is taking so long to
> > > get "right" :(
> > >
> > > I'm _ALMOST_ at the point where I would just do that work myself, but
> > > due to my current status with Intel, I'll let them do it as I have
> > > enough other things on my plate...
> > >
> > > > This could delay the NIC code for a couple of years, which by then
> > > > this won't be relevant at all.
> > >
> > > Why wouldn't this code be relevant in a year? It's going to be 2+ years
> > > before any of this shows up in an "enterprise distro" based on their
> > > release cycles anyway :)
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> > ok, I'll take a look. Do you happen to have the name of the patch-set /
> > author ?
>
> Here's at least one copy:
>
> https://lore.kernel.org/linux-rdma/20200520070227.3392100-2-jeffrey.t.kirs...@intel.com/
>
> there might have been a newer one, can't remember, sorry.
Maybe I'm missing something or maybe the in-tree code we have already
should be refactored to use more buses and drivers, but
drivers/base/component.c is made for this. We use this to glue all kinds
of things across all kinds of subsystems already.
Of course it really should be only used for one-off problems, as soon as
you have a standard interface/interaction there should be some kind of
standard lookup way to get at your thing (and the driver behind it), e.g.
in drivers/gpu we're now building up drm_bridge and trying to get away
from componenent.c for these things.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
izeof(debugfs), GFP_KERNEL);
> >> if (!dsi->debugfs_vpg)
> >> return;
> >>
> >> -memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
> >> -
> >> for (i = 0; i < ARRAY_SIZE(debugfs); i++)
> >> debugfs_create_fi
On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote:
> On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote:
> > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
> >> I think it should be the case, but I want to double check: Will
> >> copy_*_user be allo
On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
>
> On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner wrote:
> >
> > First of all, sorry for the horribly big Cc list!
> >
> > Following up to the discussion in:
> >
> > https://lore.kernel.or
1
> arch/xtensa/include/asm/highmem.h |9 +
> arch/xtensa/mm/highmem.c | 44 ---
> b/arch/x86/Kconfig|3
> include/linux/highmem.h | 141 +++-
> include/linux/io-mapping.h |2
>
(struct
> backlight_device *bd)
>
> /* Update Brightness Control & Backlight */
> data[0] = MIPI_DCS_WRITE_CONTROL_DISPLAY;
> - otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data));
> + otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data));
>
> return 0;
> }
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
@@ -59,6 +59,8 @@ static void dma_buf_release(struct dentry *dentry)
> > struct dma_buf *dmabuf;
> > dmabuf = dentry->d_fsdata;
> > + if (unlikely(!dmabuf))
> > + return;
> > BUG_ON(dmabuf->vmapping_counter);
>
> ___
> 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
4 ++-
> 2 files changed, 90 insertions(+), 78 deletions(-)
>
> --
> 2.27.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
c bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> vc->vc_video_erase_char,
> vc->vc_size_row * count);
> return true;
> - break;
>
>
gt; 2) {
> > > @@ -1818,7 +1817,6 @@ static bool fbcon_scroll(struct vc_data *vc,
> > > unsigned int t, unsigned int b,
> > > vc->vc_video_erase_char,
> > > vc->vc_size_row * count);
> > > return true;
> > > - break;
> > >
> > > case SCROLL_WRAP_MOVE:
> > > if (b - t - count > 3 * vc->vc_rows >> 2) {
> > >
> > .
> >
--
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
n't unify
anything, all it would give you is a constant vma->vm_ops to do some
kind of upcasting. And that would still only give you a slightly less
opaque pointer with a callback to upcast to a dma-buf in some
driver/subsystem specific way.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
um 14:18 schrieb Jason Gunthorpe:
> > > > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote:
> > > > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe:
> > > > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrot
On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote:
> Am 17.09.20 um 14:18 schrieb Jason Gunthorpe:
> > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote:
> > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe:
> > > > On Thu, Sep 17, 2020 at 1
> /**
> * drm_mm_nodes - list of nodes under the drm_mm range manager
> - * @mm: the struct drm_mm range manger
> + * @mm: the struct drm_mm range manager
> *
> * As the drm_mm range manager hides its node_list deep with its
> * structure, extracting it looks painfu
On Wed, Sep 16, 2020 at 11:27:27AM -0400, Kazlauskas, Nicholas wrote:
> On 2020-09-16 5:12 a.m., Daniel Vetter wrote:
> > On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
> > > Debug issues related to display can be a challenge due to the complexity
> >
On Thu, Sep 17, 2020 at 09:14:33AM +0200, Neil Armstrong wrote:
> On 08/09/2020 10:46, Daniel Vetter wrote:
> > On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote:
> >> Hi,
> >>
> >> On 07/09/2020 20:03, Daniel Vetter wrote:
> >>>
On Thu, Sep 17, 2020 at 9:11 AM Christian König
wrote:
>
> Am 17.09.20 um 08:23 schrieb Daniel Vetter:
> > On Wed, Sep 16, 2020 at 5:31 PM Christian König
> > wrote:
> >> Am 16.09.20 um 17:24 schrieb Daniel Vetter:
> >>> On Wed, Sep 16, 2020 at 4:14 PM
On Thu, Sep 17, 2020 at 12:39 AM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney
> > wrote:
> > >
> > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wr
On Wed, Sep 16, 2020 at 5:31 PM Christian König
wrote:
>
> Am 16.09.20 um 17:24 schrieb Daniel Vetter:
> > On Wed, Sep 16, 2020 at 4:14 PM Christian König
> > wrote:
> >> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
> >>> On Wed, Sep 16, 2020 a
On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
> > >
> > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> &
On Wed, Sep 16, 2020 at 4:14 PM Christian König
wrote:
>
> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
> > On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
> >
> >> But within the driver, we generally need thousands of these, and that
> >> t
On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> > wrote:
> > >
> > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner
> &g
On Wed, Sep 16, 2020 at 04:02:18PM +0200, Christian König wrote:
> Am 16.09.20 um 15:36 schrieb Alex Deucher:
> > On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
> > > On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> > > > Am 15.09.20
to make sure this really works and keeps working.
Plus ofc the documentation patch so that core mm folks can officially
ack this as legit.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
moving buffer objects in/out of vram.
Hence why we'd like to be able to forward aliasing mappings and adjust the
file and pgoff, while hopefully everything keeps working. I thought this
would work, but Christian noticed it doesn't really.
Cheers, Daniel
>
> Christian.
>
> >
> > Jason
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ted
> T: git git://anongit.freedesktop.org/drm/drm-misc
> F: Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
clk_mgr/dcn30/dcn30_clk_mgr.c | 4 +
> drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +
> .../gpu/drm/amd/display/dc/dce/dce_clk_mgr.c | 5 +
> .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 17 +-
> 10 files changed, 747 insertions(+), 36 deletions(-)
>
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/gpu/drm/amd/amdgpu/uvd_v6_0.c| 4 ++--
> > > > >8 files changed, 11 insertions(+), 11 deletions(-)
> > > > >
> > > > > --
> > > > > 2.26.0.106.g9fadedd
> > > > >
> > > > ___
> > > > amd-gfx mailing list
> > > > amd-...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> 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
int fbcon_resize(struct vc_data *vc, unsigned
> > int width,
> > struct fb_var_screeninfo var = info->var;
> > int x_diff, y_diff, virt_w, virt_h, virt_fw, virt_fh;
> >
> > - if (ops->p && ops->p->userfont && FNTSIZE(vc->vc_font.data)) {
> > + if (p->userfont && FNTSIZE(vc->vc_font.data)) {
> > int size;
> > int pitch = PITCH(vc->vc_font.width);
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ions, where I recently
made a real big fool of myself because I didn't realize how much that
impacts everything that's run within - suddenly "GFP_KERNEL for small
stuff never fails" is wrong everywhere.
It's all great for debugging and sanity checks (and we run with all
that stuff enabled in our CI), but really semantic changes depending
upon magic context checks freak my out :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Sep 15, 2020 at 1:03 PM Christian König
wrote:
>
> Am 15.09.20 um 12:39 schrieb Daniel Vetter:
> > On Mon, Sep 14, 2020 at 3:29 PM Christian König
> > wrote:
> >> This reverts commit 26d3ac3cb04d171a861952e89324e347598a347f.
> >>
> >> We nee
_gem_shmem_get_pages(shmem);
> --
> 2.17.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
private;
> struct drm_device_dma *dma = dev->dma;
> - int i, ret = 0;
> + int i;
> RING_LOCALS;
>
> i810_kernel_lost_context(dev);
> @@ -882,7 +882,7 @@ static int i810_flush_queue(struct drm_device *dev)
> DRM_DEBUG("still on client\n"
onst u32 scaling_factors_666[] = {
> > - ZYNQMP_DISP_AV_BUF_6BIT_SF,
> > - ZYNQMP_DISP_AV_BUF_6BIT_SF,
> > - ZYNQMP_DISP_AV_BUF_6BIT_SF,
> > -};
> > -
> > static const u32 scaling_factors_888[] = {
> > ZYNQMP_DISP_AV_BUF_8BIT_SF,
> > ZYNQMP_DISP_AV_BUF_8BIT_SF,
> > --
> > 2.25.4
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
compile-testing and all that.
> Signed-off-by: Laurentiu Palcu
> Reported-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Please push to drm-misc-next.
-Daniel
---
> drivers/gpu/drm/imx/dcss/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Wed, Sep 09, 2020 at 05:03:37PM +0200, Daniel Vetter wrote:
> On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson
> wrote:
> >
> > On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> &g
3 +534,7 @@ int s6e63m0_remove(struct device *dev)
> return 0;
> }
> EXPORT_SYMBOL_GPL(s6e63m0_remove);
> +
> +MODULE_AUTHOR("Paweł Chmiel ");
> +MODULE_DESCRIPTION("s6e63m0 LCD Driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.1
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
connector API
> > > > > MAINTAINERS: Add entry for i.MX 8MQ DCSS driver
> > > > > dt-bindings: display: imx: add bindings for DCSS
> > > > >
> > > > > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 108 +++
> > > > > MAINTAINERS | 8 +
> > > > > drivers/gpu/drm/Makefile | 2 +-
> > > > > drivers/gpu/drm/imx/Kconfig | 2 +
> > > > > drivers/gpu/drm/imx/Makefile | 1 +
> > > > > drivers/gpu/drm/imx/dcss/Kconfig | 9 +
> > > > > drivers/gpu/drm/imx/dcss/Makefile | 6 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-blkctl.c| 70 ++
> > > > > drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-dev.c | 325 +++
> > > > > drivers/gpu/drm/imx/dcss/dcss-dev.h | 177
> > > > > drivers/gpu/drm/imx/dcss/dcss-dpr.c | 562
> > > > > drivers/gpu/drm/imx/dcss/dcss-drv.c | 138 +++
> > > > > drivers/gpu/drm/imx/dcss/dcss-dtg.c | 409 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 198 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-kms.h | 44 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 +
> > > > > drivers/gpu/drm/imx/dcss/dcss-scaler.c| 826
> > > > > ++
> > > > > drivers/gpu/drm/imx/dcss/dcss-ss.c| 180
> > > > > 20 files changed, 4112 insertions(+), 1 deletion(-)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> > > > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> > > > >
> > > > > --
> > > > > 2.23.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
;
> > @@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, dpi);
> >
> > + dpi->bridge.funcs = &mtk_dpi_bridge_funcs;
> > + dpi->bridge.of_node = dev->of_node;
> > + dpi->bridge.type = DRM_MODE_CONNECTOR_DPI;
> > +
> > + drm_bridge_add(&dpi->bridge);
> > +
> > ret = component_add(dev, &mtk_dpi_component_ops);
> > if (ret) {
> > + drm_bridge_remove(&dpi->bridge);
> > dev_err(dev, "Failed to add component: %d\n", ret);
> > return ret;
> > }
> > @@ -802,7 +812,10 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> >
> > static int mtk_dpi_remove(struct platform_device *pdev)
> > {
> > + struct mtk_dpi *dpi = platform_get_drvdata(pdev);
> > +
> > component_del(&pdev->dev, &mtk_dpi_component_ops);
> > + drm_bridge_remove(&dpi->bridge);
> >
> > return 0;
> > }
> > --
> > 2.28.0
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
358775.c
> @@ -485,7 +485,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> val |= TC358775_LVCFG_PCLKDIV(DIVIDE_BY_6);
> } else {
> val |= TC358775_LVCFG_PCLKDIV(DIVIDE_BY_3);
> - };
> + }
> d2l_write(tc->i2c, LVCFG, val);
On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson
wrote:
>
> On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > >
On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner wrote:
>
> On 2020-09-08 10:48, Daniel Vetter wrote:
> > On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> On 08/09/2020 10:55, Stefan Agner wrote:
> >> > On 2020-09-07
On Tue, Sep 08, 2020 at 11:39:10AM +0200, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
Btw going all in on devm_drm_dev_alloc and managed functions might be good
cleanup for virtio.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
> 1 fil
virtio_has_dma_quirk() checks isn't going to fly.
>
> Using dma_max_mapping_size() should be fine though. It might use a
> lower limit than needed for virtio, but it should not break things.
Makes sense. On this patch here:
Reviewed-by: Daniel Vetter
And I guess would be good if
; struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
>
> - if (use_dma_api)
> - dma_sync_sg_for_device(vgdev->vdev->dev.parent,
> - shmem->pages->sgl, shmem->pages->nents,
> -DMA_TO_DEVICE);
> + dma_sync_sg_for_device(vgdev->vdev->dev.parent,
> +shmem->pages->sgl, shmem->pages->nents,
> +DMA_TO_DEVICE);
>
> cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
> memset(cmd_p, 0, sizeof(*cmd_p));
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Sep 08, 2020 at 07:48:58AM +0200, Gerd Hoffmann wrote:
> On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote:
> > On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote:
> > >
> > > Add drm_device argument to drm_prime_pages_to_sg(), so we can
> >
On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 08/09/2020 10:55, Stefan Agner wrote:
> > On 2020-09-07 20:18, Daniel Vetter wrote:
> >> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
> >>> Hi Stefan,
On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote:
> Hi,
>
> On 07/09/2020 20:03, Daniel Vetter wrote:
> > On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote:
> >> On 07/09/2020 10:44, Daniel Vetter wrote:
> >>> On Mon, Sep 07, 202
"Invalid pitch: fb and crtc widths must be the same");
>
> I'd turn this into a dev_dbg(), printing error messages to the kernel
> log in response to user-triggered conditions is a bit too verbose and
> could flood the log.
>
> Wouldn't it be best to catch this issue when creating the framebuffer ?
Yeah this should be verified at addfb time. We try to validate as early as
possible.
-Daniel
>
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > }
> >
> > static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; for (i = 0; i < info->num_planes; i++) {
> unsigned int width = fb_plane_width(r->width, info, i);
> unsigned int height = fb_plane_height(r->height, info, i);
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote:
> On 07/09/2020 10:44, Daniel Vetter wrote:
> > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote:
> >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote:
> >>> The Amlogic AXg
On Mon, Sep 07, 2020 at 02:46:21PM +0530, Vaibhav Gupta wrote:
> On Mon, Sep 07, 2020 at 09:55:59AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> > > Linux Kernel Mentee: Remove Legacy Power Management.
> > >
> >
vers/gpu/drm/vgem/vgem_drv.c
> @@ -321,7 +321,7 @@ static struct sg_table *vgem_prime_get_sg_table(struct
> drm_gem_object *obj)
> {
> struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
>
> - return drm_prime_pages_to_sg(bo->pages, bo->base.size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(obj->dev, bo->pages, bo->base.size >>
> PAGE_SHIFT);
> }
>
> static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> index 39ff95b75357..aed7510e2710 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> @@ -179,7 +179,8 @@ struct sg_table *xen_drm_front_gem_get_sg_table(struct
> drm_gem_object *gem_obj)
> if (!xen_obj->pages)
> return ERR_PTR(-ENOMEM);
>
> - return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
> + return drm_prime_pages_to_sg(gem_obj->dev,
> +xen_obj->pages, xen_obj->num_pages);
> }
>
> struct drm_gem_object *
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote:
> > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
> > with a custom
> > glue managing the IP resets, clock and data
gt;dev, "Unable to get reset control:
> %d\n", ret);
> +
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(mipi_dsi->px_clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Unable to prepare/enable PX clock\n");
> + goto err_clkdisable;
> + }
> +
> + reset_control_assert(top_rst);
> + usleep_range(10, 20);
> + reset_control_deassert(top_rst);
> +
> + /* MIPI DSI Controller */
> +
> + mipi_dsi->pdata.base = mipi_dsi->base;
> + mipi_dsi->pdata.max_data_lanes = 4;
> + mipi_dsi->pdata.phy_ops = &meson_dw_mipi_dsi_phy_ops;
> + mipi_dsi->pdata.host_ops = &meson_dw_mipi_dsi_host_ops;
> + mipi_dsi->pdata.priv_data = mipi_dsi;
> + platform_set_drvdata(pdev, mipi_dsi);
> +
> + mipi_dsi->dmd = dw_mipi_dsi_probe(pdev, &mipi_dsi->pdata);
> + if (IS_ERR(mipi_dsi->dmd)) {
> + ret = PTR_ERR(mipi_dsi->dmd);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev,
> + "Failed to probe dw_mipi_dsi: %d\n", ret);
> + goto err_clkdisable;
> + }
> +
> + return component_add(mipi_dsi->dev, &meson_dw_mipi_dsi_ops);
> +
> +err_clkdisable:
> + clk_disable_unprepare(mipi_dsi->px_clk);
> +
> + return ret;
> +}
> +
> +static int meson_dw_mipi_dsi_remove(struct platform_device *pdev)
> +{
> + struct meson_dw_mipi_dsi *mipi_dsi = dev_get_drvdata(&pdev->dev);
> +
> + component_del(mipi_dsi->dev, &meson_dw_mipi_dsi_ops);
> +
> + clk_disable_unprepare(mipi_dsi->px_clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id meson_dw_mipi_dsi_of_table[] = {
> + { .compatible = "amlogic,meson-axg-dw-mipi-dsi", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, meson_dw_mipi_dsi_of_table);
> +
> +static struct platform_driver meson_dw_mipi_dsi_platform_driver = {
> + .probe = meson_dw_mipi_dsi_probe,
> + .remove = meson_dw_mipi_dsi_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = meson_dw_mipi_dsi_of_table,
> + },
> +};
> +module_platform_driver(meson_dw_mipi_dsi_platform_driver);
> +
> +MODULE_AUTHOR("Neil Armstrong ");
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> --
> 2.22.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
r
> fbdev: radeonfb:use generic power management
>
> drivers/video/fbdev/aty/radeon_base.c | 10 ---
> drivers/video/fbdev/aty/radeon_pm.c | 38 ++++++++---
> drivers/video/fbdev/aty/radeonfb.h| 3 +--
> 3 files changed, 35 insertions(+), 16 deletions(-)
>
> --
> 2.27.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
t; 0 && table[0] < table[num_levels - 1])
> > + table[0] = 0;
> > +
> > /*
> > * As we use interpolation lets remove current
> > * brightness levels table and replace for the
> > --
> > 2.27.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
information */
> + struct drm_vma_offset_manager *vma_offset_manager;
> +
> + /**
> +* @max_segment:
> +*
> +* Max size for scatter list segments for GEM objects. When
> + * unset the default (SCATTERLIST_MAX_SEGMENT) is used.
> +*/
> + size_t max_segment;
> +};
> +
> struct drm_gem_object;
>
> /**
>
> ___
> 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 4, 2020 at 3:06 PM Melissa Wen wrote:
>
> Add myself as maintainer of VKMS driver
>
> Signed-off-by: Melissa Wen
Acked-by: Daniel Vetter
Congrats!
-Daniel
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINT
et);
> -
> - DRM_MODESET_LOCK_ALL_END(ctx, ret);
> }
> EXPORT_SYMBOL(drm_atomic_helper_shutdown);
>
> --
> 2.17.1
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; > /**
> >* dma_fence_end_signalling - end a critical DMA fence signalling section
> > + * @cookie: opaque cookie from dma_fence_begin_signalling()
> >*
> >* Closes a critical section annotation opened by
> > dma_fence_begin_signalling().
> > */
>
--- a/include/drm/drm_connector.h
> > > > > +++ b/include/drm/drm_connector.h
> > > > > @@ -207,6 +207,9 @@ struct drm_hdmi_info {
> > > > > /** @y420_dc_modes: bitmap of deep color support index */
> > > > > u8 y420_dc_modes;
for legacy 8bpc you get C8.
> - Make the test skip if the pixel format is >8bpc and gamma isn't
> supported
Yeah the test should skip if gamma isn't there.
-Daniel
>
> ___
> 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
!= old_state->src_y ||
> + output->needs_modeset) {
> + output->needs_modeset = false;
> DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
> bo->hw_res_handle,
> plane->state->crtc_w, plane->state->crtc_h,
> --
> 2.18.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
uot;dma-buf.rst: Document why indefinite fences are a bad
> idea")
> Signed-off-by: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Dave Airlie
Applied to drm-misc-fixes, thanks for your patch.
-Daniel
> ---
> Documentation/driver-api/dma-buf.rst
const char __user *ubuf,
> > source[len - 1] = '\0';
> >
> > ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
> > - if (ret)
> > + if (ret) {
> > + kfree(source);
> > return ret;
> > + }
> >
> > spin_lock_irq(&crc->lock);
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+321,8 @@ static struct sg_table *vgem_prime_get_sg_table(struct
> drm_gem_object *obj)
> {
> struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
>
> - return drm_prime_pages_to_sg(bo->pages, bo->base.size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(bo->pages, bo->base.size >> PAGE_SHIFT,
> + obj->dev->max_segment);
> }
>
> static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> index f0b85e094111..61a8c1a9fb04 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> @@ -179,7 +179,8 @@ struct sg_table *xen_drm_front_gem_get_sg_table(struct
> drm_gem_object *gem_obj)
> if (!xen_obj->pages)
> return ERR_PTR(-ENOMEM);
>
> - return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
> + return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages,
> + gem_obj->dev->max_segment);
> }
>
> struct drm_gem_object *
> --
> 2.18.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> >
> > > Cc: 1882...@bugs.launchpad.net
> > > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't
> > > change")
> > > Signed-off-by: Gerd Hoffmann
> >
> > Tested-by: Jiri Sla
h cpu cache, since the __GFP_ZERO on the
> + * allocation means the zeroing was done by the cpu and thus it is
> + * likely cached. Map (and implicitly flush) it out now so we don't
> + * get corruption later on.
> + *
> + * Ideally we could do this without using the heap device as a dummy
> dev.
> + */
> + dma_map_sgtable(dma_heap_get_dev(heap), table, DMA_BIDIRECTIONAL, 0);
> +
> + return ret;
> +
> +free_pages:
> + for_each_sgtable_sg(table, sg, i)
> + __free_page(sg_page(sg));
> + sg_free_table(table);
> +free_buffer:
> + kfree(buffer);
> +
> + return ret;
> +}
> +
> +static struct dma_heap_ops uncached_heap_ops = {
> + .allocate = uncached_heap_allocate,
> +};
> +
> +static int uncached_heap_create(void)
> +{
> + struct uncached_heap *heap;
> + struct dma_heap_export_info exp_info;
> +
> + heap = kzalloc(sizeof(*heap), GFP_KERNEL);
> + if (!heap)
> + return -ENOMEM;
> +
> + exp_info.name = "system-uncached";
> + exp_info.ops = &uncached_heap_ops;
> + exp_info.priv = heap;
> + heap->heap = dma_heap_add(&exp_info);
> + if (IS_ERR(heap->heap)) {
> + int ret = PTR_ERR(heap->heap);
> +
> + kfree(heap);
> + return ret;
> + }
> + dma_coerce_mask_and_coherent(dma_heap_get_dev(heap->heap),
> DMA_BIT_MASK(64));
> +
> + return 0;
> +}
> +device_initcall(uncached_heap_create);
> --
> 2.17.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
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> > @@ -11,6 +11,7 @@
> > * Jianhua Li
> > */
> >
> > +#include
> > #include
> >
> > #include
> >
>
> --
; > So please just select ZONE_DEVICE if this is so much better rather
> > than maintaining two variants.
>
> We still need to other variant for Arm at least, so both need to be
> maintained anyway, even if we force ZONE_DEVICE on x86.
Why does arm not have ZONE_DEVICE?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
>
> On Tue, 11 Aug 2020, Daniel Vetter wrote:
>
> > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > > Hi Folks,
> > > I know this thread eventually dropped off due to not identifying
ite the pid recorded
> > in the trace entry?
> >
> > The following patch does exactly that for the vm_grab_id() trace point, but
> > I'm not 100% sure if that is legal or not.
> >
> > Any ideas? Comments?
> >
> > Thanks,
> > Christian.
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nded for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; aux_dev = drm_dp_aux_dev_get_by_minor(minor);
> if (!aux_dev)
> return -ENODEV;
>
> file->private_data = aux_dev;
> return 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
> return ret;
> -
> out_unregister:
> platform_device_unregister(vkms_device->platform);
> out_free:
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
platform_driver_unregister(&v3d_platform_driver);
> -}
> -
> -module_init(v3d_drm_register);
> -module_exit(v3d_drm_unregister);
> +module_platform_driver(v3d_platform_driver);
>
> MODULE_ALIAS("platform:v3d-drm");
> MODULE_DESCRIPTION("Broadcom V3D DRM Driver");
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
vice->drm);
> + platform_device_unregister(vgem_device->platform);
> return ret;
> -
> out_unregister:
> platform_device_unregister(vgem_device->platform);
> out_free:
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
179,7 @@ DMA Fence uABI/Sync File
> > :internal:
> > Indefinite DMA Fences
> > -~~~~~~~~
> > +~
> > At various times &dma_fence with an indefinite time until dma_fence_wait()
> > finishes have been proposed. Examples include:
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
r and while crc capture is needed.
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
>
> Co-debugged-by: Sidong Yang
> Signed-off-by: Sidong Yang
> Signed-off-by: Melissa Wen
> Reviewed-by: Daniel Vetter
>
> ---
>
> v2:
> - extract a vkms_set_composer helper
&
nfig: Enable devfreq cooling device
> > > > arm64: dts: allwinner: h6: Add cooling map for GPU
> > > > [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
> > > > [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always
> > >
> > > Patches 1-10 applied to drm-misc.
> >
> > This serie has been superseded by v5.
> >
> > Could you apply the v5 instead.
>
> Oups forget my email
>
> I got an issue with my gmail...
drm-misc is a non-rebasing tree (because it's got lots of
maintainers/committers). Which means we need fixup patches now.
Not that currently drm-misc-next isn't in linux-next because of the merge
window, so just rebasing on top of linux-next wont work (at least not
until -rc1 is out). You can get the tree here meanwhile:
https://cgit.freedesktop.org/drm/drm-misc/
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
the
> vga ports any more to avoid that happening.
>
> Signed-off-by: Gerd Hoffmann
Does what it says on the label.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/
bo->hw_res_handle,
> plane->state->crtc_w, plane->state->crtc_h,
> @@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct
> drm_plane *plane,
> plane->state->src_h >> 16,
while crc capture is needed.
For next time around, please include a patch changelog here so people know
what was changed, and why. E.g.
v2:
- extract a vkms_set_composer helper
- fix vblank refcounting for the disabling case
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Co-devel
t; +
> + return written;
> +}
> +
> static DEVICE_ATTR_RW(status);
> static DEVICE_ATTR_RO(enabled);
> static DEVICE_ATTR_RO(dpms);
> static DEVICE_ATTR_RO(modes);
> +static DEVICE_ATTR_RO(current_mode);
>
> static struct attribute *connector_dev_attrs[] = {
&
ion level. Please, describe
> what
> it is that you are trying to achieve.
For added entertainment (since this is specifically about dma-buf) you
can stuff them into various gpu drivers, and convert to a native gpu
driver handle thing. That's actually the expected use case, first
tatic int ingenic_ipu_bind(struct device *dev,
> > > struct device *master, void *d)
> > > drm_object_attach_property(&plane->base, ipu->sharpness_prop,
> > > ipu->sharpness);
> > >
> > > -err = clk_prepare_enable(ipu->clk);
> > > +err = clk_prepare(ipu->clk);
> > > if (err) {
> > > -dev_err(dev, "Unable to enable clock\n");
> > > +dev_err(dev, "Unable to prepare clock\n");
> > > return err;
> > > }
> > >
> > > @@ -775,7 +792,7 @@ static void ingenic_ipu_unbind(struct device
> > > *dev,
> > > {
> > > struct ingenic_ipu *ipu = dev_get_drvdata(dev);
> > >
> > > -clk_disable_unprepare(ipu->clk);
> > > +clk_unprepare(ipu->clk);
> > > }
> > >
> > > static const struct component_ops ingenic_ipu_ops = {
> > > --
> > > 2.27.0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
eady under Greg's
maintainership.
So I think this match gives reasonably useful Cc: lists for the files
and places I've tested.
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg KH
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Daniel Vetter
---
MAINTAINER
601 - 700 of 2735 matches
Mail list logo
