On Sat, Dec 05, 2015 at 11:02:09AM +, Russell King - ARM Linux wrote:
> On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote:
> > Given that I think the current etnaviv is a sound architecture. And I'm
> > not saying that because drm requires everything to
gether in
one driver.
- How likely is the IP block to be reused in a totally different SoC/GPU?
That's why we've done the split in intel for libva since that additional
core was a licensed IP core also used it other SoCs. Since the proposed
etnaviv driver can already work to
MS buffers in the client, and right now I don't see any way
> to know what the KMS DRM device being used is in the DRI3/Present Xorg
> extensions.
>
> Moreover, DRI3 is not yet available for Gallium, so if we're talking
> about Xorg, then functional DRI2 is a r
On Wed, Dec 02, 2015 at 04:24:19PM +0100, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 12:23:00PM +, Liviu Dudau wrote:
> > The HDLCD controller is a display controller that supports resolutions
> > up to 4096x4096 pixels. It is present on various development boards
> >
ed int
> reg)
> +{
> + return readl(hdlcd->mmio + reg);
> +}
> +
> +int hdlcd_setup_crtc(struct drm_device *dev);
> +void hdlcd_set_scanout(struct hdlcd_drm_private *hdlcd);
> +void hdlcd_crtc_suspend(struct drm_crtc *crtc);
> +void hdlcd_crtc_resume(stru
On Tue, Dec 01, 2015 at 06:34:43PM +0800, Xinliang Liu wrote:
> On 1 December 2015 at 15:13, Daniel Vetter wrote:
> > On Tue, Dec 01, 2015 at 11:16:19AM +0800, Xinliang Liu wrote:
> >> On 30 November 2015 at 15:54, Daniel Vetter wrote:
> >> > On Sat, Nov 28, 2015
On Tue, Dec 01, 2015 at 06:52:20PM +0800, Xinliang Liu wrote:
> On 30 November 2015 at 15:46, Daniel Vetter wrote:
> > On Sat, Nov 28, 2015 at 03:25:35PM +, Emil Velikov wrote:
> >> Hi Xinliang,
> >>
> >> On 28 November 2015 at 10:38, Xinliang Liu wro
On Tue, Dec 01, 2015 at 11:16:19AM +0800, Xinliang Liu wrote:
> On 30 November 2015 at 15:54, Daniel Vetter wrote:
> > On Sat, Nov 28, 2015 at 06:39:01PM +0800, Xinliang Liu wrote:
> >> Add vblank handle for ADE.
> >>
> >> Signed-off-by: Xinliang Liu
> >
On Mon, Nov 30, 2015 at 11:25:28AM -0600, Rob Herring wrote:
> On Mon, Nov 30, 2015 at 08:46:03AM +0100, Daniel Vetter wrote:
> > On Sat, Nov 28, 2015 at 03:25:35PM +, Emil Velikov wrote:
> > > Hi Xinliang,
> > >
> > > On 28 November 2015 at 10:38, Xinlian
er hisi_drm_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
> - DRIVER_ATOMIC,
> + DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
> .load = hisi_drm_load,
> .unload
> +
> > + /* mali gpu need pitch 8 bytes alignment for 32bpp */
> > + args->pitch = roundup(min_pitch, 8);
> > +
> I'm not sure you want this kind of dependency of an out of tree driver
> upstream. If this is some limitation on the display engine so b
for the arm/clk parts I
think you should just send a pull requests for this to Dave for 4.5. And
yes, that means Acked-by: Daniel Vetter (too lazy
to do a full review again) for the drm side.
Cheers, Daniel
>
> Changes since v5:
> - Updated DISP_MUTEX description in binding documentation
On Wed, Nov 11, 2015 at 02:14:12PM -0800, Maxime Ripard wrote:
> Hi Daniel,
>
> Thanks for your review!
Back from vacation, sorry for the delay.
>
> On Fri, Oct 30, 2015 at 03:44:09PM +0100, Daniel Vetter wrote:
> > > +static void sun4i_crtc_disab
te mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.h
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.h
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.
On Fri, Oct 30, 2015 at 03:20:54PM +0100, Maxime Ripard wrote:
> The Allwinner A10 and subsequent SoCs share the same display pipeline, with
> variations in the number of controllers (1 or 2), or the presence or not of
> some output (HDMI, TV, VGA) or not.
>
> This hardware supports 4 layers and 3
On Wed, Oct 28, 2015 at 06:13:49PM +0100, Philipp Zabel wrote:
> Hi Daniel,
>
> Am Montag, den 19.10.2015, 10:56 +0200 schrieb Daniel Vetter:
> > On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote:
> > > From: CK Hu
> > >
> > > This patch a
On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote:
> From: CK Hu
>
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
>
> Signed-off-by: CK
y horrid.
Atm the rule for display outputs is that nothing gets yanked until
userspace approves, since otherwise compositors get stuck (or fall over
with an unexpected -EINVAL from the kernel). The exception is DP MST
because the current implementation is a complete hack for DP MST sink
lifetimes and
On Fri, Sep 18, 2015 at 06:12:00PM +0200, Philipp Zabel wrote:
> From: CK Hu
>
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
>
> Signed-off-by: CK
gt; +
> + if (helper->fb) {
> + drm_framebuffer_unregister_private(helper->fb);
> + mtk_drm_fb_destroy(helper->fb);
> + }
> +
> + drm_fb_helper_fini(helper);
> +}
> +
> +void mtk_drm_mode_output_poll_changed(struct drm_device *dev)
&g
I'm
> not sure what else to do. In the end, other hypothetical OS is free
> to ignore those extra fields in the bindings if it doesn't need them.
> So meh?
I thought we agreed a while back that these kind of "pull everything for
the logical device together" dt nodes w
ion
> more like tegra's, but still using the typical "component" code.
> Drop no-op hooks for atomic_begin and mode_fixup() now that
> they're optional. Drop sentinel in Makefile. Fix minor style
> nits I noticed on another reread.
fwiw Acked-by: Danie
On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
> >> This is the start of a full VC4 driver. Right now this just supports
> >> configuring the display using a pr
On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
> This is the start of a full VC4 driver. Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is). However, this is e
ock_all before config_reset. Instead please test "drm: Fixup
locking WARNINGs in drm_mode_config_reset" which should address this
problem too.
Thanks, Daniel
> -adjust patch order for creating pull request
>
> Changed in v12
>
> -Add one patch for MAINTAINER entry for drm/layer
On Fri, Jul 24, 2015 at 11:21:57AM +0800, jianwei wang wrote:
> Hi Dave,
>
> I think Freescale DCU DRM driver is ready now, can it land?
>
> I have worked on this driver for about nine month. Daniel Vetter,
> Thierry Reding, Mark yao,
> Alexander Stein, Paul Bolle, Alis
wei Wang
Can't find any other use of deprecated functions or legacy code patterns
or anything else that we've recently started cleaning up, looks good. No
detailed review though (for one I lack hw docs).
Acked-by: Daniel Vetter
Might be good to get some cross-review from some o
On Fri, Jul 10, 2015 at 10:43:11AM +, Wang J.W. wrote:
> Hi Daniel,
>
> Thank you very much for your review!
> See below...
>
> > -Original Message-----
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sen
; - remove redundant enable the clock implicitly using regmap
> - Add maintainer message
>
> Changed in V4:
>
> -This version doesn't have functionality changed
> Just a minor adjustment.
>
> Changed in V3:
>
> - Test driver on Vybrid board and add compatib
On Mon, Mar 09, 2015 at 12:44:03PM +, Zubair Lutfullah Kakakhel wrote:
> Add drm driver for the Ingenic JZ4780 SoC.
>
> Signed-off-by: Zubair Lutfullah Kakakhel
This driver neither supports universal planes nor atomic. Imo adding new
drivers using old internal interfaces and only supporting
pi_dsi_device *dsi);
> int mipi_dsi_detach(struct mipi_dsi_device *dsi);
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
ple don't have to go
through all the invidual patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
drm_dev_unref(ddev);
>
> return ret;
> }
>
> Daniel, can you confirm that's what you had in mind ?
Yup. To be able to have race-free driver load we need to split object
into an _init step (allocates structs and links to kernel-internal lists)
and _register (makes the ob
On Tue, Nov 18, 2014 at 02:21:30PM +0100, Boris Brezillon wrote:
> Hi Daniel,
>
> On Tue, 18 Nov 2014 09:32:34 +0100
> Daniel Vetter wrote:
>
> > On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> > > From: Mark yao
> > >
> > > This pa
On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> From: Mark yao
>
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark Yao
> Signed-off-by: Daniel Kurtz
> Acked-by: Daniel Vetter
> Reviewed-by: Rob Clark
> -
On Tue, Sep 30, 2014 at 10:10:20AM +0200, Daniel Vetter wrote:
> On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote:
> > From: Mark yao
> >
> > This add a display subsystem comprise the all display interface nodes.
> >
> > Signed-off-by: Mark Yao
On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote:
> From: Mark yao
>
> This add a display subsystem comprise the all display interface nodes.
>
> Signed-off-by: Mark Yao
> Signed-off-by: Daniel Kurtz
> Acked-by: Daniel Vetter
> Reviewed-by: Rob Clark
Just a
a really high
level up I think, so Ack: me.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 24, 2014 at 11:31 AM, Mark yao wrote:
> On 2014年09月24日 16:20, Daniel Vetter wrote:
>>
>> On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote:
>>>
>>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>>
>>>
cs to rockchip drm crtc.
> - use vop reset at first init
> - reference framebuffer when used and unreference when swap out vop
>
> Changes in v3:
> - change "crtc->fb" to "crtc->primary-fb"
> Adviced by Daniel Vetter
> - init cursor plane with univer
gem module
> >>+ * of kernel side with user virtual address which is allocated
> >>+ * by do_mmap().
> >>+ */
> >>+struct drm_rockchip_gem_mmap {
> >>+ uint32_t handle;
> >>+ uint32_t pad;
> >>+ uint64_t s
de just calls the relevant plane functions that
should even simplify your driver ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a
On Thu, Sep 18, 2014 at 04:52:14PM +0200, Daniel Vetter wrote:
> On Thu, Sep 18, 2014 at 05:36:31PM +0800, Mark yao wrote:
> > This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> >
> > Signed-off-by: Mark yao
> > ---
> > Changes in v2:
>
t; bunch of things in DRM (one being the framebuffer console instantiation
> > > that I referred to in the other thread).
> >
> > For now, I wait until there is a device connected on the RGB connector
> > (connector status set to connector_status_connected) before creating an
> > fbdev. It might not be the cleanest way to solve this issue, but it
> > works :-).
>
> Yeah, I guess that's one way to do it. But it's tricky to get right when
> you have several outputs. Which one should be considered the primary and
> trigger fbdev creation?
We could just reallocate the fbdev backing storage (probably only increase
it for safety since fbdev is bonghits) when new outputs show up. There has
been (and maybe still is) some provisions in the fbdev helper library to
do just that.
Mostly it would mean to split out drm_fb_helper_single_fb_probe so that
drivers could call it from their hotplug work. And then adjust the
->fb_probe callback of drivers which do this to reallocate the fbdev
buffer if it's only a resize. Overall this shouldn't be too much fuzz to
get going. Of course only as an opt-in, but imo that's the only sane way
to do this anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt;pipe] = crtc;
> + ctx->plane = rockchip_plane_init(drm_dev, 1 << ctx->pipe, true);
> + drm_crtc_init(drm_dev, crtc, &rockchip_crtc_funcs);
This function is deprecated, please use the _with_planes versions so that
this new driver supports universal planes properly.
Thanks, Da
currently has patches to make use of cursors via the
> > univeral plane interface (probably landing for kernel 3.17).
>
> That's great news. I knew there were some work in progress on this
> topic, but didn't know it was planned for 3.17.
>
> I'll move to th
ere though, and newer hdmi all just increase the max link
clock to push higher res modes over the wire. Imo can't hurt to just
enumerate all type of physical connectors standardized.
HDMI revisions themselves are only relevant for the sink (as advertised
capabilities in the EDID) and for
on the connector,
> it's unlikely to be problematical (the only problem is when someone
> omits it...)
If you plug a dual-link dvi screen into a soc which can do dual-link but
the actual connector is cheap and doesn't have this wired up
(differentiate wtf) then the kernel needs
On Mon, Nov 04, 2013 at 12:06:57PM +0100, Thierry Reding wrote:
> On Mon, Nov 04, 2013 at 11:20:55AM +0100, Daniel Vetter wrote:
> > On Mon, Oct 07, 2013 at 10:34:30AM +0200, Thierry Reding wrote:
> > > +static struct drm_bus drm_host1x_bus = {
> > > + .b
_platform.c
stuff until I've gotten around to completely rip it all out?
Adding Dave.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
50 matches
Mail list logo
