On Wed, Sep 11, 2024 at 10:19 AM Jocelyn Falempe
wrote:
> On 06/09/2024 21:36, James Jones wrote:
> > Right, there are 3 iterations of block linear tiling actually. NV50 does
> > support scanout of block linear surfaces. All block-linear-capable GPUs
> > do. The 3 generations are:
> >
> > NV5x/G8
On Fri, Sep 6, 2024 at 9:10 AM Jocelyn Falempe wrote:
> On 06/09/2024 14:53, Ilia Mirkin wrote:
> > On Fri, Sep 6, 2024 at 6:05 AM Jocelyn Falempe > <mailto:jfale...@redhat.com>> wrote:
> >
> > Add drm_panic support, for nv50+ cards.
> > It's
On Fri, Sep 6, 2024 at 6:05 AM Jocelyn Falempe wrote:
> Add drm_panic support, for nv50+ cards.
> It's enough to get the panic screen while running Gnome/Wayland on a
> GTX 1650.
> It doesn't support multi-plane or compressed format.
> Support for other formats and older cards will come later.
>
On Tue, Jul 23, 2024 at 12:58 PM Christophe JAILLET
wrote:
>
> Le 15/07/2024 à 15:15, Ilia Mirkin a écrit :
> > On Mon, Jul 15, 2024 at 7:49 AM Markus Elfring
> > wrote:
> >>
> >> From: Markus Elfring
> >> Date: Mon, 15 Jul 2024 13:36:54 +0200
>
On Mon, Jul 15, 2024 at 7:49 AM Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Mon, 15 Jul 2024 13:36:54 +0200
>
> Single characters should be put into a sequence.
> Thus use the corresponding function “seq_putc” for one selected call.
>
> This issue was transformed by using the Coccinell
On Fri, Jan 12, 2024 at 11:50 AM Jani Nikula wrote:
>
> Prefer the parsed results for is_hdmi and has_audio in display info over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also removes the need to use edid_blob_ptr.
>
> Cc: Karol Herb
On Fri, May 26, 2023 at 5:11 AM Karol Herbst wrote:
>
> 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
>
> We use the blit subchannel inside our vblank handling, so we should keep
> at least this par
On Mon, Mar 14, 2022 at 10:06 AM Geert Uytterhoeven
wrote:
>
> Hi Ilia,
>
> On Mon, Mar 14, 2022 at 2:44 PM Ilia Mirkin wrote:
> > On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven
> > wrote:
> > > On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven
> >
On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven wrote:
>
> Hi Ilia,
>
> On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven
> wrote:
> > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin wrote:
> > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> > >
On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven wrote:
> diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> index 953bf95492ee150c..42d75d700700dc3d 100644
> --- a/tests/util/pattern.c
> +++ b/tests/util/pattern.c
> @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
> util
I'm not saying this is wrong, but could you file a bug at
gitlab.freedesktop.org/drm/nouveau/-/issues and include the VBIOS
(/sys/kernel/debug/dri/0/vbios.rom)? That would make it easier to
review the full situation.
On Mon, Feb 14, 2022 at 11:03 AM Icenowy Zheng wrote:
>
> On PowerBook6,1 (Power
On Wed, Feb 9, 2022 at 11:16 AM Maxime Ripard wrote:
>
> On Wed, Feb 09, 2022 at 10:38:41PM +0800, Sui Jingfeng wrote:
> > On 2022/2/9 16:49, Maxime Ripard wrote:
> > > On Fri, Feb 04, 2022 at 12:04:19AM +0800, Sui Jingfeng wrote:
> > > > > > +/* Get the simple EDID data from the device tree
> > >
On Fri, Feb 4, 2022 at 10:53 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.02.22 um 14:43 schrieb Javier Martinez Canillas:
> > Add support to convert XR24 and 8-bit grayscale to reversed monochrome for
> > drivers that control monochromatic panels, that only have 1 bit per pixel.
> >
> > The drm_f
On Mon, Jan 17, 2022 at 2:47 PM Helge Deller wrote:
>
> On 1/17/22 17:21, Helge Deller wrote:
> > On 1/17/22 16:58, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 17.01.22 um 16:42 schrieb Helge Deller:
> >>> [...]
> > c) reintroduce the state where fbcon is fast on fbdev. This is
> > impo
On Thu, Nov 4, 2021 at 4:03 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> [Why]
> 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> or Degamma props in the new CRTC state, allowing any invalid size to
> be passed on.
> 2. Each driver has its own LUT size, which could
that later
> today.
>
> Regards,
> Christian.
>
> Am 09.06.21 um 16:52 schrieb Ilia Mirkin:
> > Christian - potentially relevant is that Tegra doesn't have VRAM at
> > all -- all GTT (or GART or whatever it's called nowadays). No
> > fake/stolen VRAM.
Christian - potentially relevant is that Tegra doesn't have VRAM at
all -- all GTT (or GART or whatever it's called nowadays). No
fake/stolen VRAM.
Cheers,
-ilia
On Wed, Jun 9, 2021 at 10:18 AM Christian König
wrote:
>
> Hi Mikko,
>
> strange sounds like Nouveau was somehow also using the GEM
Another instance of a report like this here:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/92
On Sat, Jun 5, 2021 at 3:53 PM Ondrej Zary wrote:
>
> Hello,
> I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference in
> nouveau_bo_sync_for_device.
> Found various reports lik
Some trivia, no comment on the real logic of the changes:
On Fri, Apr 23, 2021 at 2:43 PM Lyude Paul wrote:
>
> Since AUX adapters on nouveau have their respective DRM connectors as
> parents, we need to make sure that we register then after their connectors.
then -> them
>
> Signed-off-by: Lyu
On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
>
> Found this while trying to make some changes to the kms_cursor_crc test.
> curs507a_acquire checks that the width and height of the cursor framebuffer
> are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> want to be conce
On Thu, Mar 11, 2021 at 5:58 PM Peter Stuge wrote:
>
> Ilia Mirkin wrote:
> > > > #define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
> > > > x:R:G:B 8:8:8:8 little endian */
> > >
> > > O
On Thu, Mar 11, 2021 at 3:02 PM Peter Stuge wrote:
> > > Hence the question: What does DRM promise about the XRGB mode?
> >
> > That it's a 32-bit value. From include/uapi/drm/drm_fourcc.h:
> >
> > /* 32 bpp RGB */
> > #define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
> >
The struct is giant, and triggers an order-7 allocation (512K). There is
no reason for this to be kmalloc-type memory, so switch to vmalloc. This
should help loading nouveau on low-memory and/or long-running systems.
Reported-by: Nathan E. Egge
Signed-off-by: Ilia Mirkin
Cc: sta
Just wanted to mention ... nouveau supports two separate properties,
one controlling the type of dithering, and the other the dithering
depth:
dithering depth: auto
supported: auto, 6 bpc, 8 bpc
dithering mode: auto
supported: auto, off, static 2x2,
On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> > On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
> > wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > > Just to be crystal clear -- ar
On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
> > wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > > The fact that you'
On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
wrote:
> Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > The fact that you're getting lines with modetest means there's
> > something wrong with 256x256. What if you do 128x128 -- does that work
> > OK?
>
> Yes.
[+emersion, -various people and lists who definitely don't care]
On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
> > wrote:
> > >
> > > $ xr
On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
wrote:
>
> Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> > Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > > I'd recommend using xf86-video-nouveau in any case, but some distros
> >
> > I would like try this
On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen
wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
> > wrote:
> > > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > > diff --git a/drivers/gpu/drm/nou
On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
wrote:
>
> Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index c6367035970e..5f4f09a601d4 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
On Fri, Feb 5, 2021 at 6:45 PM Lyude Paul wrote:
>
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
> 1 file changed,
On Tue, Jan 5, 2021 at 8:44 AM Christian König
wrote:
>
> Otherwise the CPU can't fully access the BAR.
>
> Signed-off-by: Christian König
> ---
> drivers/pci/pci.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 1621
On Sat, Jan 2, 2021 at 1:35 PM Mario Kleiner wrote:
> I'm less sure about nouveau. It uses modifiers, but has atomic support
> only on nv50+ and that atomic support is off by default -- needs a
> nouveau.nouveau_atomic=1 boot parameter to switch it on. It seems to
> enable modifier support uncondi
On Wed, Dec 30, 2020 at 6:08 AM Chenyang Li wrote:
> + switch (format->format) {
> + case DRM_FORMAT_RGB565:
> + lcrtc->cfg_reg |= 0x3;
> + break;
> + case DRM_FORMAT_RGB888:
> + default:
> + lcrtc->cfg_reg |= 0x4;
> +
FWIW this is something I added, hoping it was going to get used at
some point, but I never followed up with support in xf86-video-nouveau
for Xv. At this point, I'm not sure I ever will. I encoded the
"enabled" part into the value with a high bit (1<<24) -- not sure that
was such a great idea. All
Unfortunately this isn't a crash, but rather a warning that things are
timing out. By the time you get this, the display is most likely hung.
Was there anything before this, e.g. an error state dump perhaps?
What GPU are you using, what displays, and how are they connected?
What kind of userspace
uninitialized_var() usage")
> Signed-off-by: Lyude Paul
For the very little it's worth,
Reviewed-by: Ilia Mirkin
> ---
> drivers/gpu/drm/drm_edid.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
&g
On Tue, Nov 3, 2020 at 5:15 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Changes si
On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote:
>
> Sorry! Thought I had responded to this but apparently not, comments down below
>
> On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> > On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
> > >
> > >
On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Signed-o
On Tue, Oct 20, 2020 at 1:17 PM Alex Deucher wrote:
>
> On Mon, Oct 19, 2020 at 3:43 PM Kevin Brace wrote:
> >
> > Hi Sam,
> >
> > Thanks for asking the question.
> > The current OpenChrome DRM code has these two major issues.
> >
> > 1) It does not support atomic modesetting
> >
> > I do interna
On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote:
>
> On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
> >
> > Hello,
> > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working:
> > [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6)
> > 8.3.0, GNU ld (GNU Binuti
On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote:
> > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
> > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > > > Can we use 6bpc on arbitrary DP m
On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
>
> I don'
Can we use 6bpc on arbitrary DP monitors, or is there a capability for
it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul wrote:
>
> While I thought I had this correct (since it actually did reject modes
> like I expected during testin
On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote:
>
> On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
> >
> > On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> > >
> > > On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> > > >
> > > > Sorry for the slow reply here as well. I've b
Hi Boris,
There was a fixup to that patch that you'll also have to revert first
-- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some
subtle difference between the old open-coded logic and the helper,
they were supposed to be identical.
Cheers,
-ilia
On Thu, Jun 18, 2020 at 4:09 P
Isn't this already fixed by
https://cgit.freedesktop.org/drm/drm/commit/?id=7dbbdd37f2ae7dd4175ba3f86f4335c463b18403
On Wed, May 27, 2020 at 9:43 AM Arnd Bergmann wrote:
>
> Calling directly into the fbdev stack only works when the
> fbdev layer is built into the kernel as well, or both are
> lo
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 43bcbb6d73c4..6dae00da5d7e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connec
On Fri, May 1, 2020 at 9:15 AM Souptick Joarder wrote:
>
> On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin wrote:
> >
> > Interesting. I do remember seeing some snow on NV5's overlay at high
> > resolutions. Wonder if it was because of this missing code...
>
> W
Interesting. I do remember seeing some snow on NV5's overlay at high
resolutions. Wonder if it was because of this missing code...
On Thu, Apr 30, 2020 at 4:19 PM Souptick Joarder wrote:
>
> These are dead code since 3.10. If there is no plan to use
> it further, these can be removed forever.
>
>
Not an enormous fan of what you had to do in atomic_set_planes, but
OTOH I don't see a much better way to do it either.
Reviewed-by: Ilia Mirkin
On Tue, Mar 17, 2020 at 8:11 AM Rohit Visavalia
wrote:
>
> Current implementation shows error as "failed to set gamma: Function
>
uld be drivers that didn't
support a LUT.
On Fri, Mar 13, 2020 at 6:08 AM Rohit Visavalia wrote:
>
> Hi Ilia Mirkin,
>
>
>
> But it should not go for setting gamma(drmModeCrtcSetGamma) as user has not
> asked to do so in just simple mode set command(modetest -M -s
&
Hm. I'm not sure offhand how to check if drmModeCrtcSetGamma is supported.
I guess you could check if gamma size > 0 or something?
On Thu, Mar 12, 2020, 02:39 Rohit Visavalia wrote:
> Hi Ilia Mirkin,
>
> Thanks for the review.
>
> By old-fashioned way you mean to say us
)
Cc: Boris Brezillon
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/msm/edp/edp.c | 4
drivers/gpu/drm/msm/hdmi/hdmi.c | 4
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
index ad4e963ccd9b..106a67473af5 100644
--- a/drivers
; > Subject: RE: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if
> > add_property_optional returns true
> >
> > Gentle reminder.
> >
> > + Ilia Mirkin, +Emil Velikov.
> >
> > Thanks & Regards,
> > Rohit
> >
> > > -Or
On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann wrote:
>
> Non-KMS drivers store state in struct drm_driver. This bloats the
> structure for KMS drivers and prevents it from being declared with
> 'static const' qualifiers. Moving the non-KMS state into a separate
> data structure resolves this.
Hi Frédéric,
It appears Ben made his own version of this patch (probably based on
the one you added to the kernel bz), and it's already upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2
Cheers,
-ilia
On
Probably want ULL for 32-bit arches to be correct here too.
On Tue, Dec 31, 2019 at 3:53 PM Wambui Karuga wrote:
>
> Explicitly declare constants are unsigned long to address the following
> sparse warnings:
> warning: constant is so big it is long
>
> Signed-off-by: Wambui Karuga
> ---
> drive
On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote:
>
> Allow setting the block layout of a nouveau FB
> object using DRM format modifiers. When
> specified, the format modifier block layout and
> kind overrides the GEM buffer's implicit layout
> and kind. The specified format modifier is
> valid
On Wed, Nov 13, 2019 at 11:59 AM Böszörményi Zoltán wrote:
>
> 2019. 11. 12. 17:41 keltezéssel, Ilia Mirkin írta:
> > On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán wrote:
> >> But no, all GPU devices (now only one, the UDL device) have screen 0
> >>
On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán wrote:
> But no, all GPU devices (now only one, the UDL device) have screen 0
> (a.k.a. DISPLAY=:0.0) set when AutoBindGPU is true:
>
> [ 2444.576] xf86AutoConfigOutputDevices: xf86NumScreens 2 xf86NumGPUScreens 1
> [ 2444.576] xf86AutoConfigOut
On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote:
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 29d6e93fd15e..03446be8a7be 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -673,6 +673,8 @@
> #define PCI_EXP_LNKCTL2_T
On Wed, Oct 23, 2019 at 2:41 AM Böszörményi Zoltán wrote:
>
> 2019. 10. 22. 22:57 keltezéssel, Ilia Mirkin írta:
> > On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote:
> >> Section "Device"
> >> Identifier "UD
On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote:
>
> Hi,
>
> I have the below configuration for an Intel based POS system that,
> while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel),
> only two are usable. DP1 for the built-in touchscreen and VGA1 for
> the external VG
On Mon, Oct 14, 2019 at 9:16 PM james qian wang (Arm Technology China)
wrote:
> On Mon, Oct 14, 2019 at 11:58:48AM -0400, Ilia Mirkin wrote:
> > On Fri, Oct 11, 2019 at 1:43 AM james qian wang (Arm Technology China)
> > wrote:
> > > + *
> > > + * Convert and clam
On Fri, Oct 11, 2019 at 1:43 AM james qian wang (Arm Technology China)
wrote:
>
> Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
> convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
> hardware.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
On Thu, Oct 10, 2019 at 12:01 PM Sean Paul wrote:
> > > > +static int vop_crtc_atomic_check(struct drm_crtc *crtc,
> > > > + struct drm_crtc_state *crtc_state)
> > > > +{
> > > > + struct vop *vop = to_vop(crtc);
> > > > +
> > > > + if (vop->lut_regs && crtc_st
On Mon, Sep 30, 2019 at 7:05 AM Brian Starkey wrote:
>
> Hi James,
>
> On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
> China) wrote:
> > This function is used to convert drm_color_ctm S31.32 sign-magnitude
> > value to komeda required Q2.12 2's complement
> >
> > Signe
On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs wrote:
>
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
> >
> > Hi guys,
> >
> > while working through more old TTM functionality I stumbled over the
> > io_reserve_lru.
> >
> > Basic idea is that when this flag is set the driver->io_mem_reserv
On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang wrote:
>
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ---
> drivers/gpu/drm/nouveau/dispnv50
On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
>
> When drm_connector_helper_funcs->atomic_best_encoder is defined,
> ->best_encoder is ignored both by the atomic modesetting helpers. That
By both the atomic modesetting helpers and ... (usually "both" implies 2 things)
> being said, this hook
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote:
>
> On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote:
> >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
> >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> >> >
On Fri, Sep 13, 2019 at 10:46 AM Sasha Levin wrote:
>
> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> >Hi Greg,
> >
> >This feels like it's missing a From: line.
> >
> >commit b513a18cf1d705bd04efd91c417e79e4938be093
> >Author:
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul
Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I
never noticed
On Tue, Sep 10, 2019 at 9:21 AM Ilia Mirkin wrote:
>
> On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
> wrote:
> >
> > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > > wrote:
> >
On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
wrote:
>
> On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > wrote:
> > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > > On Fr
On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding wrote:
>
> On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > Changing the order doesn't look hard. Patch attached (untested, have
> > > > > no
> > >
On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
wrote:
>
> On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > wrote:
> > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> > &g
On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
wrote:
>
> On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Ilia Mirkin
> > >Sent: Tuesday, September 3, 2019 6:12 PM
> > >To:
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Signed-off-by: Ilia Mirkin
---
Only tested on G84 and GK208. The GV100+ is entirely untested.
With the fixed modetest tool, setting ilut and olut sizes to different
On Wed, Sep 4, 2019 at 4:08 PM Jyri Sarha wrote:
>
> On 04/09/2019 14:11, Laurent Pinchart wrote:
> > Hi Jyri,
> >
> > On Wed, Sep 04, 2019 at 10:17:00AM +0300, Jyri Sarha wrote:
> >> On 03/09/2019 18:24, Laurent Pinchart wrote:
> >>> On Mon, Sep 02, 2019 at 03:53:56PM +0300, Tomi Valkeinen wrote:
So how would this work with a DP++ connector? Should it list the HDMI
or DP properties? Or do we need a custom property checker which is
aware of what is currently plugged in to validate the values?
On Tue, Sep 3, 2019 at 5:12 AM Gwan-gyeong Mun
wrote:
>
> In order to use colorspace property to D
On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä
wrote:
>
> On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> > wrote:
> > >
> > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
>
On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
wrote:
>
> On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > This should probably be fixed to account for the scenario where an
> > HDMI connector is plugged directly into the DP++ port. I don't think
> >
This should probably be fixed to account for the scenario where an
HDMI connector is plugged directly into the DP++ port. I don't think
the dp.subconnector property will be valid in that case.
(Unfortunately I don't remember how one detects that particular
situation.)
On Mon, Aug 26, 2019 at 9:22
You'll probably get a more detailed reply during the week, but for now
have a look at the "link-status" property, which was made for
precisely this situation. I think basically the idea is to ignore link
training as part of the modeset, and just return the link status
depending on the success. (And
On Wed, Aug 7, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> > The code claims to grab a runtime PM ref when at least one CRTC is
> > active, but that's not actually the case as we grab a runtime PM ref
> > whenever a CRTC is enabled regardl
On Fri, Jul 26, 2019 at 4:36 PM Sam Ravnborg wrote:
>
> Hi all.
>
> The Atmel at91sam9263 has a nice LCDC IP core that supports several
> formats:
> DRM_FORMAT_XBGR, DRM_FORMAT_BGR888, DRM_FORMAT_BGR565
>
> (It also supports a palletized C8 format, but thats for later).
>
> The formats are
On Mon, Jul 22, 2019 at 10:38 AM Takashi Iwai wrote:
> +static void
> +nv50_audio_component_init(struct nouveau_drm *drm)
> +{
> + if (!component_add(drm->dev->dev, &nv50_audio_component_bind_ops))
> + drm->audio.component_registered = true;
> +}
Pardon my ignorance on this to
On Mon, Jul 8, 2019 at 2:06 PM Qian Cai wrote:
>
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
>
> drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file
> drm_memory.c
>
> Also, silence a checkpatch warning by a
On Sun, Jul 7, 2019 at 2:15 PM Laurent Pinchart
wrote:
>
> Sorry, forgot to CC Bartlomiej on this patch.
>
> On Sun, Jul 07, 2019 at 09:07:54PM +0300, Laurent Pinchart wrote:
> > The hdmi_avi_infoframe_init() never needs to return an error, change its
> > return type to void.
> >
> > Signed-off-by
On Wed, Jul 3, 2019 at 1:49 PM Ralph Campbell wrote:
> On 6/30/19 11:20 PM, Christoph Hellwig wrote:
> > hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
> > the current nouvea flow. Move it to the only user in preparation for
>
> I didn't quite parse the phrase "quite suit
Make it actually clear the LUT.
Reported-by: Dave Airlie
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 42a0e5c7..bf1797d4 100644
--- a/tests/util/pattern.c
+++ b/tests
Reviewed-by: Ilia Mirkin
One minor comment below though:
(Maybe let it sit on the list for a day in case anyone feels like
objecting strenuously.)
On Mon, Jun 24, 2019 at 4:27 PM John Stultz wrote:
>
> Often there are many similar modes, which cannot be selected
> via modetest d
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/pattern.h b/tests/util/pattern.h
index 424b0e19..ea38cafd 100644
--- a/tests/util/pattern.h
+++ b/tests/util/pattern.h
@@ -26,7 +26,7 @@
#ifndef UTIL_PATTERN_H
to be set.
>
> Cc: Ilia Mirkin
> Cc: Rob Clark
> Cc: Bjorn Andersson
> Cc: Sumit Semwal
> Signed-off-by: John Stultz
> ---
> tests/modetest/modetest.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/tests/mode
On Thu, Jun 20, 2019 at 11:46 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Currently the logs show nothing about the mode's aspect ratio.
> Include that information in the normal mode dump.
>
> Cc: Ilia Mirkin
> Signed-off-by: Ville Syrjälä
> --
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Finally, experimental evidence suggests you can't mix sizes for degamma
and gamma. Disallow this as well.
Signed-off-by: Ilia Mirkin
---
Note that all the gv100+ change
1 - 100 of 520 matches
Mail list logo
