On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
wrote:
>
> On (06/19/19 01:20), Ilia Mirkin wrote:
> > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > wrote:
> > >
> > > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > > dmesg
> &
On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
wrote:
>
> On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > dmesg
> >
> > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> > nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> > nouveau :01:00.0: fifo: runli
On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia wrote:
>
> Add an optional CRTC gamma LUT support, and enable it on RK3288.
> This is currently enabled via a separate address resource,
> which needs to be specified in the devicetree.
>
> The address resource is required because on some SoCs, such
On Tue, Jun 18, 2019 at 9:36 AM Ezequiel Garcia wrote:
>
> On Thu, 2019-06-13 at 15:36 -0400, Ilia Mirkin wrote:
> > Note that userspace may provide any size of gamma lut. Have a look at
> > i915/intel_color.c:intel_color_check which filters out only the
> > allowed
Note that userspace may provide any size of gamma lut. Have a look at
i915/intel_color.c:intel_color_check which filters out only the
allowed sizes. Consider having a special allowance for 256-sized LUTs
since that's what most legacy userspace will set, and it seems like a
waste to create a 10-bit
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- ctm -> csc
- mark csc.valid = false when there is no ctm property
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.
For GF119:GV100, we can enable DEGAMMA/CTM/GAMMA. For earlier GPUs, as
there is no CTM, having both degamma and gamma is a bit pointless. Later
GPUs currently lack an implementation.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 5 +
1 file changed, 5 insertions
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 +
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 13 +
drivers/gpu/drm
On Thu, Jun 6, 2019 at 11:51 AM Emil Velikov wrote:
>
> On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
> >
> > Signed-off-by: Ilia Mirkin
> > ---
> > tests/modetest/modetest.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >
On Sun, Jun 2, 2019 at 8:40 PM Ilia Mirkin wrote:
>
> This series improves the pattern generation logic to support additional
> formats, as well as a new "gradient" pattern (see patch comments on why
> I found it useful).
>
> Furthermore, these formats are piped throug
On Mon, Jun 3, 2019 at 3:32 AM Daniel Vetter wrote:
>
> On Sun, Jun 02, 2019 at 08:40:08PM -0400, Ilia Mirkin wrote:
> > This series improves the pattern generation logic to support additional
> > formats, as well as a new "gradient" pattern (see patch comments
Signed-off-by: Ilia Mirkin
---
tests/modetest/buffers.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 5ec4ec8e..8a8d9e01 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -194,6 +194,13
Instead of hacking the binary every time, we can now specify directly.
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 29 -
tests/util/pattern.c | 20
tests/util/pattern.h | 2 ++
3 files changed, 46 insertions(+), 5
As new features are added and others are declared to be legacy, it's
nice to be able to implement fallbacks. As such, create a
property-setting variant that does not generate errors which can very
well be entirely expected.
Will be used for gamma control in a future change.
Signed-off-by:
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9c85c07b..a1c81f6c 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1335,8
This change adds support for all current patterns.
Signed-off-by: Ilia Mirkin
---
tests/util/format.c | 5 ++
tests/util/pattern.c | 207 ++-
2 files changed, 209 insertions(+), 3 deletions(-)
diff --git a/tests/util/format.c b/tests/util/format.c
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 8
1 file changed, 8 insertions(+)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 37796dbf..d197c444 100644
--- a/tests/util/pattern.c
+++ b/tests/util/pattern.c
@@ -788,6 +788,14 @@ static void make_pwetty(void
This includes logic to configure the LUT accordingly.
Signed-off-by: Ilia Mirkin
---
tests/modetest/buffers.c | 2 ++
tests/modetest/modetest.c | 47 ++-
2 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests
for the C8 indexed
format.
This was tested on nouveau, and used for bring-up of the C8, XB30, and
FP16 formats on the NVIDIA hardware that supports these.
Ilia Mirkin (10):
util: add C8 format, support it with SMPTE pattern
util: fix MAKE_RGBA macro for 10bpp modes
util: add gradient pattern
We need to shift the values up, otherwise we'd end up with a negative
shift. This works for up-to 16-bit components, which is fine for now.
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/tests
This also adds a helper to generate a color LUT, which has to be used in
conjunction with the C8 indexed format.
Signed-off-by: Ilia Mirkin
---
tests/util/format.c | 2 ++
tests/util/pattern.c | 75
tests/util/pattern.h | 4 +++
3 files changed
).
This is really only useful on 10bpc formats, but we also add support for
8bpc formats to ease testing. In the future, this could be applied to
16bpc formats as well.
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 113 +--
tests/util/pattern.h | 1 +
2
e, which
copies mode into adjusted_mode...
Assuming it makes sense to use "mode", Ben, want to just do a fixup
locally, or want me to send a revert + new patch?
-ilia
On Mon, May 27, 2019 at 2:24 AM Ben Skeggs wrote:
>
> On Sun, 26 May 2019 at 08:41, Ilia Mirkin wrote:
> &g
/show_bug.cgi?id=110660
Signed-off-by: Ilia Mirkin
---
Tested on a 1920x1200-native screen with a 640x480 mode (got letter
boxes on the side) and 720x400 mode (got letter boxes on top/bottom).
drivers/gpu/drm/nouveau/dispnv50/head.c | 28 +
1 file changed, 24 insertions(+), 4
, and i915 already does it this way.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660
Signed-off-by: Ilia Mirkin
---
Untested for now, hoping that the bugzilla filer will test it out. Seems
obvious though.
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 +++--
1 file changed, 7 inser
On Tue, May 14, 2019 at 3:57 PM Peteris Rudzusiks
wrote:
>
> On Tue, May 14, 2019 at 04:55:05PM +1000, Ben Skeggs wrote:
> > On Sun, 12 May 2019 at 04:23, Peteris Rudzusiks
> > wrote:
> > >
> > > nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom
> > > struct. This patch adds copyi
On Sat, Feb 16, 2019 at 10:02 AM Colin Ian King
wrote:
>
> Hi,
>
> Static Analysis with CoverityScan as detected an issue with the setting
> of the RON pull value in function nvkm_gddr3_calc in
> drm/nouveau/bios/ramcfg.c
>
> This was introduced by commit: c25bf7b6155cb ("drm/nouveau/bios/ramcfg:
You don't appear to set the mm in the new macro. Not sure if it's on
purpose.
On Sun, Jan 20, 2019, 06:43 Noralf Trønnes This adds a helper macro to specify modes that only contain info about
> resolution.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/tinydrm/hx8357d.c | 2 +-
> d
On Fri, Jan 11, 2019, 05:26 Daniel Vetter On Fri, Jan 11, 2019 at 10:43:42AM +0100, Gerd Hoffmann wrote:
> > On Fri, Jan 11, 2019 at 10:11:09AM +0100, Daniel Vetter wrote:
> > > On Fri, Jan 11, 2019 at 10:08 AM Gerd Hoffmann
> wrote:
> > > >
> > > > On F
Hi Gerd,
What happened with this series (and the next one)?
Semi-relatedly, I wonder if it wouldn't be better to just dump the
BIG_ENDIAN flag and just define the "host" format to be the right one
for a consistent little-endian interpretation.
Cheers,
-ilia
On Wed, Sep 5, 2018 at 2:04 AM Ge
On Tue, Jan 1, 2019 at 5:30 PM Jan Vlietland wrote:
>
> Hi Ilia, many thanks for answering my mail.
>
> Tonight I tried to see what happens if I generate a xorg.conf file and place
> it in /etc/X11/xorg.conf, as described here:
> https://askubuntu.com/questions/4662/where-is-the-x-org-config-file
On Tue, Jan 1, 2019 at 4:06 PM Jan Vlietland wrote:
>
> Hi Ben, David and Daniel ,
>
> First of all happy new year. Based on advice of Greg K-H herewith a mail
> about a number of Nouveau issues with my laptop.
>
> I installed various Kali linux versions up to Linux 4.20.0-rc7
> (downloaded, compi
Ben - ping? Just ran into this myself on a NV42.
On Wed, Nov 14, 2018 at 11:01 AM Takashi Iwai wrote:
>
> On Fri, 14 Sep 2018 13:59:25 +0200,
> Martin Peres wrote:
> >
> > On 14/09/2018 10:28, Ben Skeggs wrote:
> > > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai wrote:
> > >>
> > >> When a fan is c
GF117 appears to use the same register as GK104 (but still with the
general Fermi readout mechanism).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf100.c | 3 ++-
1 file changed, 2 insertions(+), 1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine
On Fri, Nov 23, 2018 at 7:31 AM Thierry Reding wrote:
>
> From: Thierry Reding
>
> The register region allocated per channel was decreased from 16384 bytes
> to 256 bytes on Tegra186 and later. Resize the region to make sure every
> channel (instead of only the first) is properly programmed.
>
>
On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding wrote:
>
> On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Irrespective of whether or not the device has any usable outputs, the
On Tue, Oct 30, 2018 at 4:24 AM Y.C. Chen wrote:
>
> From: "Y.C. Chen"
>
> over-sample data to increase the stability with some specific monitors
>
> Signed-off-by: Y.C. Chen
> ---
> drivers/gpu/drm/ast/ast_mode.c | 32 ++--
> 1 file changed, 26 insertions(+), 6 dele
On Tue, Oct 9, 2018 at 1:40 PM Laurent Pinchart
wrote:
>
> Hi Jernej,
>
> Thank you for the patch.
>
> On Sunday, 7 October 2018 12:38:51 EEST Jernej Skrabec wrote:
> > It turns out that even new DW HDMI controllers exhibits same magenta
> > line issues as older versions.
> >
> > Enable workaround
On Tue, Sep 4, 2018 at 11:02 AM, Michel Dänzer wrote:
> On 2018-09-04 3:05 p.m., Ilia Mirkin wrote:
>> On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
>>> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
>>>> On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
&g
On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
>> On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
>>> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
>>>> Userspace on big endian machhines typ
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++
.../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 +
.../gpu
When SCDC is supported, make sure that we configure the GPU and monitor
to the same parameters.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
d by one or the
other. But at least it works a little bit!
Note that I have limited testing equipment, but I did verify that a
GM204 trace referred to the same register for controlling
scrambling. I may get access to a GM206 later in the week to verify
there.
Ilia Mirkin (5):
drm/nouveau/disp: add
Scrambling is required for supporting any mode over 340MHz. If it's not
supported, reject any modes that would require it.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff
The register programmed by the clock method needs to contain a different
setting for the link speed as well as special divider settings.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5
High pixel clocks are required to use a 40 TMDS divider instead of 10,
and even low ones may optionally use scrambling depending on device
support.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 -
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
>> Userspace on big endian machhines typically expects the ADDFB ioctl
>> returns a big endian framebuffer. drm_mode_addfb() will call
>> drm_mode_addfb2() unconditionally with l
On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> +bool
> +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> +{
> + bool hotplug;
> +
> + if (!fbcon)
> + return false;
> +
> + mutex_lock(&fbcon->hotplug_lock);
> + hotplug = fbcon->hotplug_w
Lyude bisected a similar problem on a much newer GPU to this very same
change as well. [Sorry, no useful information beyond that, but thought
I'd make the connection.]
On Sun, Jun 17, 2018 at 5:46 PM, Adam Borowski wrote:
> Hi!
> On v4.18-rc1, the mouse cursor is missing on my right monitor.
> Ca
On Sun, May 27, 2018 at 5:54 PM, Colin King wrote:
> From: Colin Ian King
>
> The constant values being shifted are 32 bit integers and may potentially
> overflow on the shift. Avoid this potential overflow by making them
> unsigned long long values before the shift.
>
> Detected by CoverityScan
On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer wrote:
> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE ena
On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
> try to allocate huge pages. However, not all drivers can take advantage
> of huge pages, but they would incur the overhead for allocating and
>
A NV34 GPU was seeing temp and pwm entries in hwmon, which would error
out when read. These should not have been visible, but also the whole
hwmon object should just not have been registered in the first place.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 16
On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote:
> On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
>>> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
>>>> Am 01.04.2018 um 20:21 schrieb Taka
On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
>> Am 01.04.2018 um 20:21 schrieb Takashi Iwai:
>> > On Sun, 01 Apr 2018 19:58:11 +0200,
>> > Christian K6nig wrote:
>> > > Am
On Sun, Apr 1, 2018 at 1:39 PM, Christian König
wrote:
> Am 30.03.2018 um 22:45 schrieb Takashi Iwai:
>>
>> amdgpu driver lacks of modeset module option other drm drivers provide
>> for enforcing or disabling the driver load. Interestingly, the
>> amdgpu_mode variable declaration is already found
On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
wrote:
> Cc'ing mesa-dev, which was left out.
>
>
> On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
>> wrote:
>>> Afaics EGL does the right thing wr
On Wed, Mar 7, 2018 at 6:44 PM, wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be incre
On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
wrote:
> On 02/05/2018 12:50 AM, Ilia Mirkin wrote:
>>
>> In case anyone's curious about 30bpp framebuffer support, here's the
>> current status:
>>
>> Kernel:
>>
>> Ben and I have switched the
On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> wrote:
>> From: Ville Syrjälä
>>
>> Replace the ad-hoc iturbt_709 property with the new standard
>> COLOR_ENCODING property. Compiles, but not tested.
>&g
On Mon, Feb 19, 2018 at 4:33 AM, Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 10:21:54AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 05, 2018 at 09:10:12AM -0500, Ilia Mirkin wrote:
>> > On Mon, Feb 5, 2018 at 8:58 AM, Ville Syrjälä
>> > wrote:
>> > > O
On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Replace the ad-hoc iturbt_709 property with the new standard
> COLOR_ENCODING property. Compiles, but not tested.
>
> Cc: Daniel Vetter
> Cc: nouv...@lists.freedesktop.org
> Cc: Ben S
On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin wrote:
> On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote:
>>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>>
>> NV5 in another PC (secondary card in x86-64) made the systrem crash on
>> bo
On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote:
>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>
> NV5 in another PC (secondary card in x86-64) made the systrem crash on
> boot, in nvkm_therm_clkgate_fini.
Mind booting with nouveau.debug=trace? That should hopeful
On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
wrote:
> On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
>> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
>> > In case anyone's curious about 30bpp framebuffer support, here's the
>>
On Mon, Feb 5, 2018 at 8:58 AM, Ville Syrjälä
wrote:
> On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
>> Nouveau only exposes support for XBGR2101010. Prior to the atomic
>> conversion, drm would pass in the wrong format in the framebuffer, but
>> it was a
In case anyone's curious about 30bpp framebuffer support, here's the
current status:
Kernel:
Ben and I have switched the code to using a 256-based LUT for Kepler+,
and I've also written a patch to cause the addfb ioctl to use the
proper format. You can pick this up at:
https://github.com/skeggsb
er to specify that it
prefers the XBGR format variant for the addfb ioctl, and makes nouveau's
nv50 display driver set it. (Prior gens had no support for 30bpp at all.)
Signed-off-by: Ilia Mirkin
Cc: sta...@vger.kernel.org # v4.10+
---
Wasn't sure if the nouveau line needs to be split out
Yeah, a lot of people were getting that, as a result of some drm/ttm
hugepage usage.
Christian, did a fix ever end up going out? If so, what kernel was it
included in?
-ilia
On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez
wrote:
> Hello,
>
> I've noticed firefox got randomly stuck,
On Thu, Jan 25, 2018 at 10:35 PM, Lyude Paul wrote:
> Same as the previous patch, but for Kepler2 now
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
> drivers/gpu/drm/nouveau/nvkm/engin
On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith wrote:
> On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote:
>> On Tue, Dec 19, 2017 at 8:45 AM, Christian König
>> wrote:
>> > Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
>> >>
>> >
On Sun, Dec 31, 2017 at 1:15 PM, Ilia Mirkin wrote:
> Currently there's no way to allow a driver to reimplement any ioctls
> from the drm core. This can be desirable to, e.g., override fixed format
> selection logic, without turning to a midlayer-like solution.
>
> Signed
On Tue, Dec 19, 2017 at 8:45 AM, Christian König
wrote:
> Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
>>
>> On 2017-12-19 11:37 AM, Michel Dänzer wrote:
>>>
>>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote:
On 12/18/17 7:06 PM, Mike Galbraith wrote:
>
> Greetings,
>
>
Currently there's no way to allow a driver to reimplement any ioctls
from the drm core. This can be desirable to, e.g., override fixed format
selection logic, without turning to a midlayer-like solution.
Signed-off-by: Ilia Mirkin
---
I want drm_mode_addfb to pick a different format for
NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However
drmAddFB with depth = 30 will use the mapping in
drm_mode_legacy_fb_format and pick the XRGB version of the format.
One solution is to tell userspace "stop using addfb, move to addfb2".
However I'm hoping that there's some sort o
On Wed, Dec 20, 2017 at 6:22 PM, Kristian Kristensen
wrote:
> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico
> wrote:
>> On Wed, 20 Dec 2017 11:54:10 -0800
>> Kristian Høgsberg wrote:
>> > I'd like to see concrete examples of actual display controllers
>> > supporting more format layouts th
On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone wrote:
> Hi Russell,
>
> On 8 December 2017 at 12:31, Russell King wrote:
>> Add the defacto-standard "iturbt_709" property to the overlay plane to
>> control the YUV to RGB colorspace conversion. This is mutually
>> exclusive with the CSC_YUV CRTC
We need to shift the values up, otherwise we'd end up with a negative
shift. This works for up-to 16-bit components, which is fine for now.
Signed-off-by: Ilia Mirkin
---
v1 -> v2: fill low bits with high bits
Fun - this breaks things for GK208. Not sure why. Works on G92 though.
Prob
On Fri, Nov 24, 2017 at 2:08 PM, Christian Zigotzky
wrote:
> On 24.11.2017 17:09, Michel Dänzer wrote:
>>
>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>
>>> Hi All,
>>>
>>> I bisected today and the first bad commit is:
>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper fun
On Fri, Nov 24, 2017 at 8:38 AM, Ville Syrjälä
wrote:
> On Thu, Nov 23, 2017 at 03:14:46PM -0500, Ilia Mirkin wrote:
>> On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä
>> wrote:
>> > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
>> >> We need to
On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä
wrote:
> On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
>> We need to shift the values up, otherwise we'd end up with a negative
>> shift. This works for up-to 16-bit components, which is fine for now.
>
We need to shift the values up, otherwise we'd end up with a negative
shift. This works for up-to 16-bit components, which is fine for now.
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests
On Wed, Nov 22, 2017 at 8:40 AM, Christian Zigotzky
wrote:
> On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:
>>
>> On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> I reverted the following files in
On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
wrote:
> Hi Alex,
>
> I reverted the following files in the first bad commit (first DRM updates)
Is the merge commit really the first bad commit? i.e. both parents of
the merge are good, but the merge commit itself is bad? Or did you do
this man
Tested on nouveau with the CRTC only (no planes).
Signed-off-by: Ilia Mirkin
---
v1 -> v2: always set a flat gamma ramp for non-indexed modes
tests/modetest/buffers.c | 2 ++
tests/modetest/modetest.c | 24
tests/util/format.c | 2 ++
tests/util/pattern.c |
On Fri, Nov 17, 2017 at 11:56 PM, Ilia Mirkin wrote:
> Tested on nouveau with the CRTC only.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> Please note that I have no clue what the proper way to operate the gamma
> interface is. This seemed OK, but the 256 seems awefully hard
Tested on nouveau with the CRTC only.
Signed-off-by: Ilia Mirkin
---
Please note that I have no clue what the proper way to operate the gamma
interface is. This seemed OK, but the 256 seems awefully hardcoded. Perhaps
that won't work on other HW?
tests/modetest/buffers.c | 2 ++
On Wed, Oct 11, 2017 at 9:46 AM, Bjorn Helgaas wrote:
> On Wed, Oct 11, 2017 at 08:54:05AM -0400, Ilia Mirkin wrote:
>> On Wed, Oct 11, 2017 at 7:47 AM, Bjorn Helgaas wrote:
>> > /* do magic */
>> > nvif_mask(&device->object, 0x088488, (1 <<
On Wed, Oct 11, 2017 at 7:47 AM, Bjorn Helgaas wrote:
> On Mon, Oct 09, 2017 at 10:41:38AM -0400, Ilia Mirkin wrote:
>> Hello,
>>
>> As a bit of background, all NVIDIA GPUs since GT215 have an audio
>> subfunction for HDMI(/DP) audio to be sent to the sink. This genera
On Mon, Oct 9, 2017 at 11:45 AM, Christian König
wrote:
> Am 09.10.2017 um 16:41 schrieb Ilia Mirkin:
>>
>> Hello,
>>
>> As a bit of background, all NVIDIA GPUs since GT215 have an audio
>> subfunction for HDMI(/DP) audio to be sent to the sink. This gener
Hello,
As a bit of background, all NVIDIA GPUs since GT215 have an audio
subfunction for HDMI(/DP) audio to be sent to the sink. This generally
works.
However some, especially laptop, devices come up with that function
disabled. We have a quirk to enable it when coming back from runpm,
but that d
On Wed, Aug 30, 2017 at 10:55 PM, Rhys Kidd wrote:
> Signed-off-by: Rhys Kidd
> ---
> .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 1 +
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +++
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 +
> drivers/gpu/drm/nouveau/n
On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote:
> From: Colin Ian King
>
> The null check on the array msto is incorrect since msto is never
> null. The null check should be instead on msto[i] since this is
> being dereferenced in the call to drm_mode_connector_attach_encoder.
>
> Thanks to Em
55 however, as tested with modetest.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 36 -
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/cr
ction.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 62 --
1 file changed, 34 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index e54944d23268..5bd63c2
some modest modetest testing on NV5, NV17, NV34, and NV4A. I
noticed
some odd issues on NV5 with certain scaling factors, but I'm somewhat sure that
those issues were there before - either the hw can't keep up or we're not
twiddling
some clocks.
Ilia Mirkin (4):
drm/nouv
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index 5bd63c2f14a6..c8c2333f24ee 100644
--- a/drivers
Pre-nv50 YUV overlays have stringent requirements for working with the
internal machinery. Instead of rejecting these at update_plane time, we
should instead prevent the framebuffers from being created in the first
place.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_display.c
Signed-off-by: Ilia Mirkin
---
This was helpful when debugging our earlier mpeg woes. May as well have it
upstream.
drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 7 ++-
drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv40.c | 7 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff
101 - 200 of 520 matches
Mail list logo
