> I can't dig into details of DC, so this is not a 100% assessment, but if
> you call a function called "validate" in atomic_commit, you're very, very
> likely breaking atomic. _All_ validation must happen in ->atomic_check,
> if that's not the case TEST_ONLY mode is broken. And atomic userspace is
On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote:
>
> > DRM drivers don't strike me as suitable for small/slow cores with dumb
> > framebuffers or simple 2D only accel, such as the one found in the ASpeed
> > BMCs.
>
> Then the DRM framework should be improved to be suitable.
Dave ? :-)
On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote:
> Yeah, small drivers like these we have piles now, things exploded a lot
> after atomic landed two years ago. And they seem to shrink with every
> release a bit more (since lots more drivers gives you lots more insight
> into what other refac
On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
> > From memory, David claimed you cannot directly work on the fb with a
> > "proper"
>
> DRM driver. Maybe I misunderstood but then the DRM shines by its complete
> absence of useful documentation
That sentence should have been i
On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> argument that shadowing through memory was necessary and precluded 2D
> accel, though I don't fully remember the root of the argument. If that
> is indeed not the ca
On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
> > With drmfb you basically have to shadow everything into memory & copy
> > over everything, and locks you out of simple 2D accel. For a simple text
> > console the result is orders of magnitude slower and memory hungry than
> > a simple fbd
Hi Daniel,
On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> > Atomic drivers may set properties like rotation on the same fb, which
> > may require a call to prepare_fb even when framebuffer stays identical.
> >
> > Inste
>
> No.
>
I'd also like to apologise for the formatting, gmail great for typing,
crap for editing.
So I've thought about it a bit more and Daniel mentioned something
useful I thought I should add.
Merging this code as well as maintaining a trust relationship with
Linus, also maintains a trust re
On 9 December 2016 at 07:28, Benjamin Herrenschmidt
wrote:
> On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
>> > With drmfb you basically have to shadow everything into memory & copy
>> > over everything, and locks you out of simple 2D accel. For a simple text
>> > console the result is o
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/7e823363/attachment.html>
.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/4d78adf7/attachment-0001.html>
unappealing to me.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/ae1214bd/attachment.html>
On 12/08/2016 11:52 PM, Stefan Agner wrote:
> The LCD bus width does not need to align with the pixel format. The
> LCDIF controller automatically converts between pixel formats and
> bus width by padding or dropping LSBs.
>
> The DRM subsystem has the notion of bus_format which allows to
> determ
On Dec 9 2016 01:37, Arnaud Pouliquen wrote:
> Aim of this patch is to add 'Playback Channel Map' control to export
> audio capabilities in term of HDMI sink speakers allocation.
> This patch follow discussion initiates here:
> [RFC] ASOC: HDMI audio info frame speaker allocation
> http://www.spin
On 12/08/2016 09:46 PM, Stefan Agner wrote:
> On 2016-12-07 18:37, Marek Vasut wrote:
>> On 12/08/2016 02:26 AM, Stefan Agner wrote:
>>> On 2016-12-07 16:59, Stefan Agner wrote:
On 2016-12-07 16:49, Marek Vasut wrote:
> On 12/08/2016 01:27 AM, Stefan Agner wrote:
>> The DRM subsystem s
On Dec 9 2016 05:52, Takashi Sakamoto wrote:
> On Dec 9 2016 01:37, Arnaud Pouliquen wrote:
>> Aim of this patch is to add 'Playback Channel Map' control to export
>> audio capabilities in term of HDMI sink speakers allocation.
>> This patch follow discussion initiates here:
>> [RFC] ASOC: HDMI au
s.freedesktop.org/archives/dri-devel/attachments/20161209/4e24e6d2/attachment.html>
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/a35506f7/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/02925f0e/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/b41e2562/attachment.html>
hment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/3e3cbac5/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/dfe0441c/attachment.html>
oot you'll lose the change.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/db2a459f/attachment-0001.html>
Hi Marek,
MXSFB can connect with LDB(LVDS display bridge) on i.MX6SX.
We have an existing LDB drm driver which works with IPUv3
embedded in i.MX6Q/DL and i.MX53.
Do you see a clear picture how all of these stuffs work together?
Adding Philipp also.
Regards,
Liu Ying
On Fri, Dec 2, 2016 at 2:02
as scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/bb3d0d50/attachment.html>
Hi Linus,
Just a single fix for amdgpu to just suspend the gpu on "shutdown"
instead of shutting it down fully, as for some reason the hw was
getting upset in some situations.
Dave.
The following changes since commit 3e5de27e940d00d8d504dfb96625fb654f641509:
Linux 4.9-rc8 (2016-12-04 12:50:51
On Fri, 9 Dec 2016 08:22:37 +0100 (CET)
Stefan Wahren wrote:
> Hi,
>
> > Boris Brezillon hat am 2. Dezember
> > 2016 um 14:48 geschrieben:
> >
> >
> > Sorry for the noise, but I forgot to Cc the DT maintainers.
> >
> > Here is the 2nd version of the VC4/VEC series.
> >
> > We still miss th
Hi Dave,
On Fri, Dec 9, 2016 at 1:08 AM, Dave Airlie wrote:
> On 9 December 2016 at 07:28, Benjamin Herrenschmidt
> wrote:
>> On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
>>> > With drmfb you basically have to shadow everything into memory & copy
>>> > over everything, and locks you o
On Fri, Dec 09, 2016 at 08:43:13AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
> > > From memory, David claimed you cannot directly work on the fb with a
> > > "proper"
> >
> > DRM driver. Maybe I misunderstood but then the DRM shines by
On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> > On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> > > Atomic drivers may set properties like rotation on the same fb, which
> > > may requ
On Fri, Dec 09, 2016 at 01:24:07PM +0800, Ying Liu wrote:
> Hi Marek,
>
> MXSFB can connect with LDB(LVDS display bridge) on i.MX6SX.
> We have an existing LDB drm driver which works with IPUv3
> embedded in i.MX6Q/DL and i.MX53.
> Do you see a clear picture how all of these stuffs work together?
On Thu, Dec 08, 2016 at 04:21:34PM +0100, Daniel Vetter wrote:
> [back from my walk, the sunset here is stellar ;-)]
>
> On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
> > Hi Thomas,
> >
> > On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
> > wrote:
> > > On Thu, 8 Dec 2016
On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> > As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> > argument that shadowing through memory was necessary and precluded 2D
> > accel, though
cases and prevent them from
showing up in the list of modes.
So we basically have two different things to care about. We want to be
tolerant so that most panels just work, but not too tolerant to rule
out modes that we know we can't reach. We're only covering the latter,
and we should take into account the former, but we definitely need
some kind of check.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/4b5f65f7/attachment.sig>
On Fri, Dec 09, 2016 at 09:34:42AM +0100, Daniel Vetter wrote:
> On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> > > As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> > > argument that sh
e consumer electronics products, and people like to have
a panel that works on their tablet).
However, bridges are a different story, and provide on some SoCs modes
that are way out of reach for our pixel clock, which is why we had
that test in the first place.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/89de3049/attachment.sig>
e
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/18a5ba71/attachment.sig>
On Fri, 09 Dec 2016, Manasi Navare wrote:
> If link training fails, then we need to fallback to lower
> link rate first and if link training fails at RBR, then
> fallback to lower lane count.
> This function finds the next lower link rate/lane count
> value after link training failure and limits t
On Fri, 09 Dec 2016, Manasi Navare wrote:
> This patch does not change anything functionally, just cleans up
> the DP compliance related variables and stores them all together
> in a separate struct intel_dp_compliance. There is another struct
> intel_dp_compliance_data to store all the test data.
We thought that no userspace is using them, but oops libdrm is using
them to figure out whether a driver supports modesetting. Check out
drmCheckModesettingSupported but maybe don't because it's horrible and
totally runs counter to where we want to go with libdrm device
handling. The function looks
Hi Dave,
Am Montag, den 05.12.2016, 12:03 +0100 schrieb Philipp Zabel:
> Hi Dave,
>
> this tag fixes a regression in the imx-drm YUV plane support [1] that
> was introduced in v4.9-rc4, as well as an error returned when changing
> U/V offsets of an active plane to otherwise valid values.
Is ther
On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter
Hey
On Fri, Dec 9, 2016 at 11:42 AM, Daniel Vetter
wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter t
Hi Greg
On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman
wrote:
> On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote:
>> We thought that no userspace is using them, but oops libdrm is using
>> them to figure out whether a driver supports modesetting. Check out
>> drmCheckModesetting
On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/561f936c/attachment-0001.sig>
ly if we
don't have any display outputs.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/c02e482b/attachment.sig>
In a perfect world we would be able to read GPU registers of interest
via the command stream with a 'read-register' command/package. For perf counters
it is a must to read them synchronized with the GPU to put the values in
relation to a draw command. As Vivante GPUs do not provide this functionali
Prep work for following changes.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b1254f8..09aa67a 1006
This commits extends etnaviv_gpu_cmdbuf_new(..) to define the size
of struct etnaviv_readback gets used.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 14 --
drivers/gpu/drm/etnaviv/etnaviv_gp
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 73c278d..6527ceb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/dr
We can not defere the readback of the registers as the values likely
getting changed by an other command buffer.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
We need to readout some registers _after_ the submited command
buffer got executed in order to support perf counters.
There is no way to read register via command stream - even the
Vivante kernel driver does it via a special ioctl.
Signed-off-by: Christian Gmeiner
---
include/uapi/drm/etnaviv_dr
Each perf counter 'unit' consits of a multipler configuration register
and a register to read the selected value. Extend the uapi to handle
this case gracefully. Before the readback is done the mux (config_reg)
get reconfigured (vale).
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 53 ++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index ede5d71..a69eff7 1
Reading some registers end in a system crash ala:
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfe641000
Internal error: : 1028 [#1] PREEMPT ARM
Avoid those by register validation.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 26 +
We need this for perf counters.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4
include/uapi/drm/etnaviv_drm.h| 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b
In the interrupt handler struct etnaviv_event is the only
information source to process readbacks.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/etna
Hi Steve,
Am Mittwoch, den 07.12.2016, 16:57 -0800 schrieb Steve Longerbeam:
> To allow for IPU client devices that are composed of more than one
> port for input and output (SMFC and IC), change the nodes from being
> a single port node to nodes that can contain multiple ports. Rename
> the nodes
On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote:
> What are people using fbcon for that needs acceleration, this is where I get
> a bit lost.
>
> It's a console, if you aren't sshing into the machine.
>
> It's main purpose should just be for gathering oopses and you've a lot better
> chance
On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> Yeah if you have discrete vram then your dumb display driver isn't all
> that pretty. We essentially just have the few drivers Dave hacked up to be
> able to boot some servers. And there's definitely lots of room for more
> shared code for t
On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:
>
> And since I failed to make this clear: There's not really a
> fundamental
> reason ast and cirrus use the dirty tracking for fbdev. It's just that
> doing it that way was the fastest way to get those servers booting, and
> ever since no o
Hi Ben,
On Fri, Dec 9, 2016 at 12:44 PM, Benjamin Herrenschmidt
wrote:
>> So it is possible, only reason vram dumb buffers look worse is that there's
>> only 3 and no one cares about them, vs about 20 and a very active community
>> of contributors (also for core drm improvements) for the other ca
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 41 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_mm_se
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 143
Check that we can request alignment to any power-of-two or prime using a
plain drm_mm_node_insert().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 3 +
drivers/gpu/drm/test-drm_mm.c | 113 +
2 files changed, 116 insertions(+)
dif
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 167 +
2 files changed
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 178 +
2 files changed, 179 inser
Check that if we request top-down allocation with a particular alignment
from drm_mm_insert_node() that the start of the node matches our
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 92 ++
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 188 +
2 files changed, 189 insertions(+)
diff --git
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 271 +
2 files changed
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm_selftests.h | 1 +
drivers/gpu/drm/test-drm_mm.c | 96 ++
2 files changed, 97 i
Am Freitag, den 09.12.2016, 22:44 +1100 schrieb Benjamin Herrenschmidt:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boo
84
96178eeb Vandana Kannan 2015-01-10 1185 /**
96178eeb Vandana Kannan 2015-01-10 1186 * HIGH_RR is the highest eDP panel
refresh rate read from EDID
96178eeb Vandana Kannan 2015-01-10 1187 * LOW_RR is the lowest eDP panel
refresh rate found from EDID
96178eeb Vandana Kannan 2015-01-10 1188 * parsing for same resolution.
96178eeb Vandana Kannan 2015-01-10 1189 */
96178eeb Vandana Kannan 2015-01-10 @1190 enum drrs_refresh_rate_type {
96178eeb Vandana Kannan 2015-01-10 1191DRRS_HIGH_RR,
96178eeb Vandana Kannan 2015-01-10 1192DRRS_LOW_RR,
96178eeb Vandana Kannan 2015-01-10 1193DRRS_MAX_RR, /* RR count */
:: The code at line 1106 was first introduced by commit
:: 40521054fd46f94e0368cead312d56e9e442aaab drm/i915: context basic create
& destroy
:: TO: Ben Widawsky
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/4b507515/attachment-0001.gz>
On Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boo
On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:
> >
> > And since I failed to make this clear: There's not really a
> > fundamental
> > reason ast and cirrus use the dirty tracking for fbdev. It's just that
> > doing
On Fri, Dec 09, 2016 at 01:03:33PM +0200, Tomi Valkeinen wrote:
> On 30/11/16 15:32, Daniel Vetter wrote:
> > On Wed, Nov 30, 2016 at 01:17:05PM +0200, Tomi Valkeinen wrote:
> >> Add DRM property for crtc background color property. Background
> >> color is shown on areas where there are no planes.
I am not sure how the correct solution should look like.
Maybe enable debug registers globally via not existing
SET_PARAM ioctl.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm
On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> Simple first test to just exercise initialisation of struct drm_mm.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
Hello, Rasmus.
On Thu, Dec 08, 2016 at 02:22:55AM +0100, Rasmus Villemoes wrote:
> TL;DR: these patches save 250 KB of memory, with more low-hanging
> fruit ready to pick.
>
> While browsing through the lib/idr.c code, I noticed that the code at
> the end of ida_get_new_above() probably doesn't w
On Fri, Dec 09, 2016 at 11:57:34AM +0100, David Herrmann wrote:
> Hi Greg
>
> On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman
> wrote:
> > On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote:
> >> We thought that no userspace is using them, but oops libdrm is using
> >> them to figu
We thought that no userspace is using them, but oops libdrm is using
them to figure out whether a driver supports modesetting. Check out
drmCheckModesettingSupported but maybe don't because it's horrible and
totally runs counter to where we want to go with libdrm device
handling. The function looks
Hey
On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter wrote:
>> > So it is possible, only reason vram dumb buffers look worse is that there's
>> > only 3 and no one cares about them, vs about 20 and a very active community
>> > of contributors (also for core drm improvements) for the other case.
>>
>
Hi Dave,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.10-rc1
for you to fetch changes up to 8c31f6034b24601721dae
On Fri, Dec 09, 2016 at 02:57:24PM +0100, David Herrmann wrote:
> Hey
>
> On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter wrote:
> >> > So it is possible, only reason vram dumb buffers look worse is that
> >> > there's
> >> > only 3 and no one cares about them, vs about 20 and a very active
> >>
On 9 December 2016 at 13:56, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to where we
On Fri, Dec 09, 2016 at 01:13:11PM +0200, Tomi Valkeinen wrote:
> On 30/11/16 15:46, Daniel Vetter wrote:
> > On Wed, Nov 30, 2016 at 01:17:09PM +0200, Tomi Valkeinen wrote:
> >> From: Peter Ujfalusi
> >>
> >> Do not try to init the fbdev if either num_crtcs or num_connectors is 0.
> >> In this ca
Hi Dave,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.10-rc1
for you to fetch changes up to 585ee0f27ef7b8db46807
Hey
On Fri, Dec 9, 2016 at 2:56 PM, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus poi
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, b
Looping when we keep track of this is silly. Only thing we have to
be careful is with sampling the connector count. To avoid inconsisten
results due to gcc re-computing this, use READ_ONCE.
And to avoid surprising userspace, make sure we don't copy more
connectors than planned, and report the actu
It only updates per-file feature flags. And all the ioctl which change
behaviour depending upon these flags (they're all kms features) do
_not_ hold the BKL. Therefor this is pure cargo-cult and can be
removed.
Note that there's a risk that the ioctl will behave inconsistently,
but that's ok. The
With the last round of changes all ioctls called by modern drivers now
have their own locking. Everything else is only allowed for legacy
drivers and hence the lack of locking doesn't matter.
One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag.
But that only works its magic on the
No one looks at the major/minor versions except the unique/busid
stuff. If we protect that with the master_mutex (since it also affects
the unique of each master, oh well) we can mark these two IOCTL with
DRM_UNLOCKED.
While doing this I realized that the comment for the magic_map is
outdated, I'v
We can be more clever than that and merge the 2 list walking loops.
It's all under the one mutex critical section anyway, so nothing funny
can happen.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 28 +++-
1 file changed, 11 insertions(+), 17 deleti
On Fri, Dec 09, 2016 at 02:56:56PM +0100, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter
--
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/5352ac96/attachment.sig>
On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote:
> Exercise drm_mm_reserve_node(), check that we can't reserve an already
> occupied range and that the lists are correct after reserving/removing.
>
> Signed-off-by: Chris Wilson
> ---
> Â drivers/gpu/drm/drm_mm_selftests.h |Â Â Â 1 +
> Â driv
Hi Tomi,
On Friday 09 Dec 2016 16:23:05 Tomi Valkeinen wrote:
> On 08/12/16 01:53, Laurent Pinchart wrote:
> > The header defines the userspace API exported by the omapdrm driver,
> > install it to make the definitions available to userpace.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
>
1 - 100 of 166 matches
Mail list logo
