-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/4af8c21b/attachment.html>
be you can see why from the
memdumps in the dmesg.
I haven't been able to reproduce this.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-
Hi Dave -
Our first bag of fixes for drm-next/v4.5.
BR,
Jani.
The following changes since commit 7447a2b221cd4df3960e82478a4ee29312589611:
drm/i915: Update DRIVER_DATE to 20151218 (2015-12-18 20:26:17 +0100)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel
did not crash and produced
attached output.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/d11be581/attachment.html>
On Tue, 12 Jan 2016, Jonathan Corbet wrote:
> On Sat, 12 Dec 2015 12:13:45 +0100
> Daniel Vetter wrote:
>
>> I just figured there's no way this could get it, and I'd
>> much rather improve the docs themselves than trying to convince core
>> kernel folks that this might be useful.
>
> So I'm not q
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/60e8ac2e/attachment.html>
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/1f788ca1/attachment.html>
this be
a new bug then? Mesa version is 11.1.1.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/68d8030e/attachment.html>
On Thu, Jan 14, 2016 at 04:25:08PM +0100, Maxime Ripard wrote:
> Add support for the Olimex LCD-OLinuXino-4.3TS panel to the DRM simple
> panel driver.
>
> It is a 480x272 panel connected through a 24-bits RGB interface.
>
> Signed-off-by: Maxime Ripard
> ---
> .../display/panel/olimex,lcd-olin
On Thu, Jan 14, 2016 at 04:25:07PM +0100, Maxime Ripard wrote:
> Olimex is an open source hardware boards vendors based in Bulgaria.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring
On Thu, Jan 14, 2016 at 04:25:00PM +0100, Maxime Ripard wrote:
> The display pipeline of the Allwinner A10 is involving several loosely
> coupled components.
>
> Add a documentation for the bindings.
>
> Signed-off-by: Maxime Ripard
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 2
On Thu, Jan 14, 2016 at 04:24:51PM +0100, Maxime Ripard wrote:
> The Allwinner SoCs have a gate controller to gate the access to the DRAM
> clock to the some devices that need to access the DRAM directly (mostly
> display / image related IPs).
>
> Use a simple gates driver to support the one found
On Thu, Jan 14, 2016 at 04:24:50PM +0100, Maxime Ripard wrote:
> The TCON is a controller generating the timings to output videos signals,
> acting like both a CRTC and an encoder.
>
> It has two channels depending on the output, each channel being driven by
> its own clock (and own clock controll
On Thu, Jan 14, 2016 at 04:24:49PM +0100, Maxime Ripard wrote:
> The A10 SoCs and relatives have a PLL controller to drive the PLL3 and
> PLL7, clocked from a 3MHz oscillator, that drives the display related
> clocks (GPU, display engine, TCON, etc.)
>
> Add a driver for it.
>
> Signed-off-by: Ma
On Thu, Jan 14, 2016 at 04:24:48PM +0100, Maxime Ripard wrote:
> The A10 SoCs and its relatives has a special clock controller to drive the
> display engines (both frontend and backend), that have a lot in common with
> the clock to drive the first TCON channel.
>
> Add a driver to support both.
>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/7f2e9ca4/attachment.html>
On Tuesday 17 November 2015 16:58:25 Jani Nikula wrote:
> On Mon, 16 Nov 2015, Thierry Reding wrote:
> > An encoder is associated with a connector by the DRM core as a result of
> > setting up a configuration. Drivers using the atomic or legacy helpers
> > should never set up this link, even if it
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/4cd19064/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/3d0da3c7/attachment-0001.html>
Hi Daniel,
On Monday 11 January 2016 14:51:46 Daniel Stone wrote:
> On 10 January 2016 at 23:48, Laurent Pinchart wrote:
> > On Saturday 09 January 2016 14:28:46 Daniel Vetter wrote:
> >> @@ -353,18 +354,16 @@ static void drm_events_release(struct drm_file
> >> *file_priv) {
> >>
> >> struc
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/5529eab4/attachment.html>
Hi Daniel,
Thank you for the patch.
On Monday 11 January 2016 22:40:59 Daniel Vetter wrote:
> Use them in the core vblank code and exynos/vmwgfx drivers.
>
> Note that the difference between wake_up_all and _interruptible in
> vmwgfx doesn't matter since the only waiter is the core code in
> drm
Hi Daniel,
Thank you for the patch.
On Monday 11 January 2016 22:40:56 Daniel Vetter wrote:
> An attempt at not spreading out the file_priv->event_space stuff out
> quite so far and wide. And I think fixes something in ipp_get_event()
> that is broken (or if they are doing something more weird/s
Hi Daniel,
Thank you for the patch.
On Monday 11 January 2016 22:41:03 Daniel Vetter wrote:
> There's really no reason to not do so, instead of replicating this
> for every use-case and every driver. Now we can't just nuke the events,
> since that would still mean that all drm_event users would n
+ Rob Herring
2016ë
01ì 14ì¼ 19:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> It seems this patch and 04/10 did not get picked up yet.
> Could you merge it?
Yes, I can. However, 04/10 is required for acked-by from dt or SoC maintainer.
Krzysztof and Rob, could you give me acked-by?
Hi Archit,
On Wed, 2016-01-13 at 12:41 +0530, Archit Taneja wrote:
> Hi Jitao,
>
> On 01/13/2016 07:48 AM, Jitao Shi wrote:
> > This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
> >
> > Signed-off-by: Jitao Shi
> > ---
> > Changes since v6:
> > - Add ps8640 firmware update
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/ace1a82b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/e9c98fad/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/014fb90b/attachment.html>
n:
vsraytrace
fsraytrace
gsraytrace
Have a look at the attachments.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/187f2ef7/attachment.html>
On 2016-01-14 16:01, Mark Brown wrote:
> On Thu, Jan 14, 2016 at 02:30:50PM -0800, Stefan Agner wrote:
>
>> I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a
>> Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following
>> warning on startup:
>
> Please don't paste ent
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/81e2449f/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/f086cd21/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/f6ffd9cb/attachment-0001.html>
On 2016å¹´01æ14æ¥ 16:32, Daniel Vetter wrote:
> On Thu, Jan 14, 2016 at 2:16 AM, Mark yao wrote:
>> On 2016å¹´01æ14æ¥ 01:39, John Keeping wrote:
>>> On Wed, 13 Jan 2016 18:19:17 +0100, Daniel Vetter wrote:
>>>
On Wed, Jan 13, 2016 at 04:40:38PM +, John Keeping wrote:
> On Wed, 1
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/9e69d146/attachment.html>
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/cb730894/attachment.html>
On Thu, 14 Jan 2016 15:57:05 +0100, Thierry Reding wrote:
> On Thu, Jan 14, 2016 at 02:39:42PM +, John Keeping wrote:
> > Signed-off-by: John Keeping
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/r
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts
b/arch/arm/boot/dts/sun5i-r8-chip.dts
index c26c095b42c6..147c39106f63 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm
Add support for the Olimex LCD-OLinuXino-4.3TS panel to the DRM simple
panel driver.
It is a 480x272 panel connected through a 24-bits RGB interface.
Signed-off-by: Maxime Ripard
---
.../display/panel/olimex,lcd-olinuxino-43-ts.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c
Olimex is an open source hardware boards vendors based in Bulgaria.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/binding
The CHIP has a composite output available muxed with the microphone in the
micro-jack plug.
Enable the composite output in its DTS.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-c
The TCON, tv-encoder and display engine backends and frontends are combined
to create our display pipeline.
Add them to the R8 DTSI. It's supposed to be perfectly compatible with the
A10s and A13, but since we haven't tested it on them yet, it's safer to
just enable it on the R8. Eventually, it sh
Add the settings to support the NTSC standard.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 45
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 4f369de2a1fc..4
Now that we have support for the composite output, we can start adding new
supported standards. Start with PAL, and we will add other eventually.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 42
1 file changed, 42 insertions(+)
dif
Some Allwinner SoCs have an IP called the TV encoder that is used to output
composite and VGA signals. In such a case, we need to use the second TCON
channel.
Add support for that TV encoder.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 1 +
drivers/gpu/drm/sun4i/sun4i_
One of the A10 display pipeline possible output is an RGB interface to
drive LCD panels directly. This is done through the first channel of the
TCON that will output our video signals directly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 2 +
drivers/gpu/drm/sun4i/sun
The display pipeline of the Allwinner A10 is involving several loosely
coupled components.
Add a documentation for the bindings.
Signed-off-by: Maxime Ripard
---
.../bindings/display/sunxi/sun4i-drm.txt | 228 +
1 file changed, 228 insertions(+)
create mode 100644
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.
Add a driver with a limited set of features for now, and we will hopefully
support all of them eventually
Sig
The drm subsystem also uses the video= kernel parameter, and in the
documentation refers to the fbdev documentation for that parameter.
However, that documentation also says that instead of giving the mode using
its resolution we can also give a name. However, DRM doesn't handle that
case at the m
Rewrite the command line parser in order to get away from the state machine
parsing the video mode lines.
Hopefully, this will allow to extend it more easily to support named modes
and / or properties set directly on the command line.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c
The drm_fbdev_cma_init function always calls the
drm_helper_disable_unused_functions. Since it's part of the usual probe
process, all the drivers using that helper will end up having their encoder
and CRTC disable functions called at probe if their device has not been
reported as enabled.
This cou
It turns out that the A13 / R8 also have a tve encoder block, and a gate
for it.
Add it to the DT.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/s
The DRAM gates control whether the image / display devices on the SoC have
access to the DRAM clock or not.
Enable it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a10s.dtsi | 7 ---
arch/arm/boot/dts/sun5i-a13.dtsi | 2 +-
arch/arm/boot/dts/sun5i-r8.dtsi | 2 +-
arch/arm/
Enable the display and TCON (channel 0 and channel 1) clocks that are going
to be needed to drive the display engine, tcon and TV encoders.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 38 +-
arch/arm/boot/dts/sun5i-r8.dtsi | 5 +++--
Enable the pll3 and pll7 clocks in the DT that are used to drive the
display-related clocks.
Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun5i.dtsi | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/su
The Allwinner SoCs have a gate controller to gate the access to the DRAM
clock to the some devices that need to access the DRAM directly (mostly
display / image related IPs).
Use a simple gates driver to support the one found in the A13 / R8 SoCs.
Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu T
The TCON is a controller generating the timings to output videos signals,
acting like both a CRTC and an encoder.
It has two channels depending on the output, each channel being driven by
its own clock (and own clock controller).
Add a driver for the channel 1 clock.
Signed-off-by: Maxime Ripard
The A10 SoCs and relatives have a PLL controller to drive the PLL3 and
PLL7, clocked from a 3MHz oscillator, that drives the display related
clocks (GPU, display engine, TCON, etc.)
Add a driver for it.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
d
The A10 SoCs and its relatives has a special clock controller to drive the
display engines (both frontend and backend), that have a lot in common with
the clock to drive the first TCON channel.
Add a driver to support both.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/cloc
The composite clock didn't have any unregistration function, which forced
us to use clk_unregister directly on it.
While it was already not great from an API point of view, it also meant
that we were leaking the clk_composite structure allocated in
clk_register_composite.
Add a clk_unregister_com
From: Matthias Brugger
Some devices like SoCs from Mediatek need to use the clock
through a regmap interface.
This patch adds regmap support for the simple multiplexer clock,
the divider clock and the clock gate code.
Signed-off-by: Matthias Brugger
Signed-off-by: Maxime Ripard
---
drivers/cl
The ops pointer is holding a pointer to a structure that is usually not
modified. Make it const.
Signed-off-by: Maxime Ripard
---
include/linux/reset-controller.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller
The core currently doesn't check that the DT cell size matches what the
driver declares, which means that every xlate function needs to duplicate
that check.
Make sure that of_reset_control_get checks for this to avoid duplication
and errors.
Signed-off-by: Maxime Ripard
---
drivers/reset/core.
Hi everyone,
The Allwinner SoCs (except for the very latest ones) all share the
same set of controllers, loosely coupled together to form the display
pipeline.
Depending on the SoC, the number of instances of the controller will
change (2 instances of each in the A10, only one in the A13, for
exa
2016ë
01ì 14ì¼ 16:01ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 01/14/2016 07:25 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> This patch series incurred merge conflicts at severial patches so I had to
>> merge them manually.
>> It looks good to me but it seems to need more tests so I merged them t
use?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/20fef853/attachment-0001.sig>
On Thu, Jan 14, 2016 at 02:39:40PM +, John Keeping wrote:
> The Rockchip driver cannot use drm_atomic_helper_wait_for_vblanks()
> because it has hardware counters for neither vblanks nor scanlines.
>
> In order to simplify re-implementing the functionality for this driver,
> export the framebu
|Linux (All)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/e18a7fb9/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/a95647f0/attachment.html>
Hi Andrzej,
This patch series incurred merge conflicts at severial patches so I had to
merge them manually.
It looks good to me but it seems to need more tests so I merged them to
exynos-drm-next-todo.
After that, I will move them to exynos-drm-next. Sorry for late reivew again.
Thanks,
Inki Da
On Thu, Jan 14, 2016 at 02:00:10PM +0800, Liu Ying wrote:
> We've done sanity NULL pointer check on set->mode at the beginning of
> drm_crtc_helper_set_config() and bailed out if necessary, thus any later on
> check is redundant.
>
> Signed-off-by: Liu Ying
Both applied to drm-misc, thanks.
-Dan
On Thu, Jan 14, 2016 at 04:46:37PM +0800, Mark yao wrote:
> On 2016å¹´01æ14æ¥ 16:32, Daniel Vetter wrote:
> >On Thu, Jan 14, 2016 at 2:16 AM, Mark yao wrote:
> >>On 2016å¹´01æ14æ¥ 01:39, John Keeping wrote:
> >>>On Wed, 13 Jan 2016 18:19:17 +0100, Daniel Vetter wrote:
> >>>
> On Wed, Jan
Signed-off-by: John Keeping
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 679d23a..b267ce4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_f
As commented in drm_atomic_helper_wait_for_vblanks(), userspace relies
on cursor ioctls being unsynced. Converting the rockchip driver to
atomic has significantly impacted cursor performance by making every
cursor update wait for vblank.
By skipping the vblank sync when the framebuffer has not ch
The Rockchip driver cannot use drm_atomic_helper_wait_for_vblanks()
because it has hardware counters for neither vblanks nor scanlines.
In order to simplify re-implementing the functionality for this driver,
export the framebuffer_changed() helper so it can be reused.
Signed-off-by: John Keeping
On Thu, 14 Jan 2016 15:20:47 +0100, Daniel Vetter wrote:
> Ugh. Oh well, there's not really anything we can do in core nore helpers
> to make this easier for drivers. This really only can be fixed sensibly at
> the hardware level.
>
> So yeah I think exposing framebuffer_changed as a helper is th
Hi Mark,
I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a
Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following
warning on startup:
[1.327284] [ cut here ]
[1.332010] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755
lockdep_
2015ë
11ì 02ì¼ 22:16ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> With incoming support for newer SoCs different set of clocks will be required,
> depending on IP version. The patch prepares the driver for it.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 184
>
We've done sanity NULL pointer check on set->mode at the beginning of
drm_crtc_helper_set_config() and bailed out if necessary, thus any later on
check is redundant.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
We've done sanity NULL pointer check on set->fb at the beginning of
drm_crtc_helper_set_config() and bailed out if necessary, thus any later on
check or case handling is redundant.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/drm_crtc_helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/badda96f/attachment.html>
Hi Andrzej,
Really sorry for missing this.
I will merge them soon.
Thanks,
Inki Dae
2016ë
01ì 13ì¼ 23:01ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> Ping.
>
> Regards
> Andrzej
>
> On 11/02/2015 02:16 PM, Andrzej Hajda wrote:
>> Hi Inki, Krzysztof,
>>
>> This patchset adds support
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/10acc7b6/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/43151496/attachment.html>
|hawaii r9 390X |grenada r9 390X
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/742d5
On Thu, 14 Jan 2016 22:03:26 +0200
Jani Nikula wrote:
> What if we added support for some markup language as an alternative to
> DocBook for the high level documentation? What if we taught kernel-doc
> to output said markup natively, and included those generated pieces into
> the high level docum
On Tue, Jan 12, 2016 at 02:39:18PM +0100, Marek Szyprowski wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to drm core and plane state structures
> - added helpers for normalizing zpos properties of given set of pl
Hi Inki,
It seems this patch and 04/10 did not get picked up yet.
Could you merge it?
Regards
Andrzej
On 10/26/2015 12:59 PM, Andrzej Hajda wrote:
> DECON-TV(Display and Enhancement Controller for TV) is a variation
> of DECON IP. Its main purpose is to produce video stream for HDMI IP.
>
> Sign
||g/show_bug.cgi?id=91865
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/72953
||g/show_bug.cgi?id=93706
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/687fc
||g/show_bug.cgi?id=88263
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/fdbea
||g/show_bug.cgi?id=93706
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/230eb
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/000cfe08/attachment.html>
||g/show_bug.cgi?id=86720
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/9941c
||g/show_bug.cgi?id=93706
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/be7d3
.0
X server 1.17.2
Intel Sandybridge
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/5b3ceeb9/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/623720cd/attachment-0001.html>
ng this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/59fc42bc/attachment.html>
UG=nosb, gsraytrace also freezes the GPU
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160114/fef01e9f/attachment.html>
1 - 100 of 131 matches
Mail list logo
