On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
>> > MSIs were only problematic on some old, broken chipsets. But now that we
>> > already see systems where PCI legacy interr
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>>>> On Wed, Aug 28, 2013 a
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
>>> wrote:
>>>> On Wed, Aug 28, 2013 a
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
>>> wrote:
>>>> On Wed, Aug 28, 2013 at 8
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>>> wrote:
>>>> On Thu, Aug 29, 2013 at 12
On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont
wrote:
> Hi,
>
> With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau:
> [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type
> mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95)
> [ 657
On Wed, Dec 4, 2013 at 6:15 AM, Ilia Mirkin wrote:
> On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont
> wrote:
>> [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22
>> [ 657.802123] general protection fault: [#1] SMP
>> [ 657.802130] Modules l
All instances of drm_dev_register are followed by drm_dev_free on
failure. Don't free dev->control/render/primary on failure, as they will
be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor
destruction to drm_dev_free()).
Reported-by: Bruno Pr?mont
Signed-off-by: Ili
gned-off-by: Ilia Mirkin
---
v2: use drm_unplug_minor instead of just removing the puts, as suggested by
David Herrman.
drivers/gpu/drm/drm_stub.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index f53d524.
Some firmware images may be large (64K), so using kmalloc memory is
inappropriate for them. Use vmalloc instead, to avoid high-order
allocation failures.
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org
---
Couldn't get video decoding started on a long-running system due to high-
The intent was to only enable it by default for optimus, e.g. see the
runtime_idle callback. The suspend callback may be called directly, e.g.
as a result of nouveau_crtc_set_config.
Reported-by: Stefan Lippers-Hollmann
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org
---
See http
On Thu, Dec 12, 2013 at 12:07 PM, Rob Clark wrote:
> If driver failed to load (for example, -EPROBE_DEFER), we'd end up doing
> drm_put_minor() both from drm_dev_register() and drm_dev_free(), the
> second time with a bogus pointer.
FYI, I sent a similar patch ~week ago that changed put_minor int
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 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 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 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 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 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
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
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 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
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 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, 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 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 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, 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
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 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 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 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 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 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, 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 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
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,
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
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
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
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 Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote:
>> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
>> usage we could convert to WARN_ONCE?
>
> Shooting the messenger is generally considered uncool :)
That's never
On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann
wrote:
> The conversion is a nice catch, but i'd like to have a bit more context, see
> below!
>
> With a better description:
>
> Tobias Klausmann
I don't think it was meant as a serious patch. WARN_ON_ONCE should
work. The fix isn't to remove a
On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce
On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin wrote:
> On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
>> Greetings,
>>
>> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
>> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>>
On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce
On Sun, Jul 16, 2017 at 12:43 AM, Mike Galbraith wrote:
> On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote:
>>
>> OK, so this issue appears to be that we're calling
>> drm_crtc_vblank_off() on a crtc for which vblank is already disabled.
>> My guess is that
I believe the solution is to not call drm_crtc_vblank_off for atomic
modesetting in nouveau_display_fini. I think Ben's working on it.
On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann
wrote:
> mimic the behavior of vblank_disable_fn(), another caller of
> drm_vblank_disable_and_save().
>
> This
On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote:
> Laurent Pinchart writes:
>
>> Hi Eric,
>>
>> (CC'ing Daniel)
>>
>> Thank you for the patch.
>>
>> On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote:
>>> This will let drivers reduce the error cleanup they need, in
>>> particular the "is_panel_b
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
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
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
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
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 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 (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 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
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
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 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.
>
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 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
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 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
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
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
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
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,
>
>
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 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 Wed, Mar 30, 2016 at 9:47 AM, Daniel Vetter
wrote:
> virtual is a protected keyword in C++ and can't be used at all. Ugh.
>
> This aligns the kernel versions of the drm headers with the ones in
> libdrm.
>
> Cc: Emil Velikov
> Signed-off-by: Daniel Vetter
> ---
> include/uapi/drm/drm.h | 4
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 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
While using chrome, I got the following. It was able to render the bug
to the screen, so at least something was working (and it also made it
to my logs).
[223614.867297] BUG: unable to handle kernel paging request at c90013a0
[223614.867372] IP: [] iowrite32+0x12/0x33
[223614.867427] PGD 1
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko wrote:
> On Wed 27-03-13 14:25:36, Ilia Mirkin wrote:
>> Hello,
>>
>> My system died last night apparently due to OOM conditions. Note that
>> I don't have any swap set up, but my understanding is that this is not
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>
>> The GPF happens at +160, which is in the argument setup for the
>> cmpxchg in slab_alloc_node. I think it's the call to
>> get_freepointer(). There was a si
On Sat, Apr 6, 2013 at 5:01 AM, Ilia Mirkin wrote:
> On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
>> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>>
>>> The GPF happens at +160, which is in the argument setup for the
>>> cmpxchg in slab_all
mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace
component didn't work
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
> These chipsets include the VP2 engine which is composed of a bitstream
> processor (BSP) that decodes H.264 and a video processor (VP) which can
> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
> driven by sep
On Tue, Jun 4, 2013 at 4:48 PM, Henrik Rydberg wrote:
> Hi Ben,
>
> The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my
> MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem.
A bunch of people saw it earlier. Fixed for nv50 (which is what I
assume you have) in
http
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 04-06-13 20:38, Ilia Mirkin schreef:
>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
>>> These chipsets include the VP2 engine which is composed of a bitstream
>>> processor (BS
mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- factored out similar logic between vp and bsp into a new xtensa.c, similar
to falcon
- moved firmware loading to init rather than c
This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin
Signed-off-by: Ilia Mirkin
---
The actual
I was just looking at
https://bugs.freedesktop.org/show_bug.cgi?id=20341 (see last comment).
Basically he's able to to use the card with agpmode=2 but not the
auto-detected agpmode=4. I also saw that the radeon driver has a large
quirks list, and it seems silly to reproduce it in nouveau.
However
On Fri, Oct 11, 2013 at 12:50 PM, Alex Deucher wrote:
> On Fri, Oct 11, 2013 at 12:33 AM, Ilia Mirkin wrote:
>> I was just looking at
>> https://bugs.freedesktop.org/show_bug.cgi?id=20341 (see last comment).
>> Basically he's able to to use the card with agpmode=2 bu
audit and version SOR_HDA_ELD method")
Cc: sta...@vger.kernel.org # v3.17+
Reviewed-by: Ilia Mirkin
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hd
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> In theory it's possible for any of the nouveau_getparam calls to
> fail whist the last one being successful.
>
> Thus at least one of the following (hard requirements) drmVersion,
> chipset and vram/gart memory size will be filled with garbag
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> Current handling relies on atoi which does not detect errors
> additionally, any integer value will be considered as a valid
> percent.
>
> Resolve that by using strtol and limiting the value within
> the 5-100 (percent) range.
>
> Signed-off
On Wed, Mar 12, 2014 at 9:04 PM, Emil Velikov
wrote:
> On 13/03/14 00:45, Ilia Mirkin wrote:
>>
>> On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
>> wrote:
>>>
>>> In theory it's possible for any of the nouveau_getparam calls to
>>> fail whist
On Wed, Mar 12, 2014 at 9:24 PM, Emil Velikov
wrote:
> On 13/03/14 01:05, Ilia Mirkin wrote:
> [snip]
>
>>
>> Not really. drm->drm_version will be 0 if ver fails.
>>
> Indeed, dev is calloc'ated by its callers, and if they mess around with
> that'
Signed-off-by: Ilia Mirkin
---
nouveau/nouveau.c | 29 -
nouveau/private.h | 3 ++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index ee7893b..72c31cf 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz
wrote:
> [ 326.168487] ==
> [ 326.168491] [ INFO: possible circular locking dependency detected ]
> [ 326.168496] 3.13.6 #1270 Not tainted
> [ 326.168500] ---
On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote:
> On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
>> On 03/20/2014 10:43 AM, David Herrmann wrote:
>> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>> > wrote:
>> > Given that the legacy node is always around and _alw
On Thu, Mar 20, 2014 at 10:44 AM, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote:
>> On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
>>> On 03/20/2014 10:43 AM, David Herrmann wrote:
>>> > On Thu, Mar 20, 2014
textdata bss dec hex filename
453459 159463 480 613402 95c1a drivers/gpu/drm/nouveau/nouveau.ko
NV04 + NV50 + NVC0: 1343482 bytes
textdata bss dec hex filename
579171 184264 480 763915 ba80b drivers/gpu/drm/nouveau/nouveau.ko
Signed-off-by: Ilia
NULL);
for (i = 0; i < 50; i++) {
nouveau_bo_ref(NULL, &bo[i]);
}
nouveau_device_del(&dev);
return 0;
}
On Wed, Mar 12, 2014 at 10:05 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
> nouveau/nouveau.c | 29 -
> nouveau/private.h
vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475
Signed-off-by: Ilia Mirkin
Cc: # v2.6.35+
---
Not sure if the stable CC is warranted... it's technically not a
regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test th
On Tue, May 6, 2014 at 4:29 PM, Felipe Balbi wrote:
> Hi,
>
> Just caught this with v3.14-rc4 running with
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce
> GTX 650] (rev a1)
>
> full dmesg attached
>
> [ 239.589213] ==
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>
>> The GPF happens at +160, which is in the argument setup for the
>> cmpxchg in slab_alloc_node. I think it's the call to
>> get_freepointer(). There was a si
301 - 400 of 521 matches
Mail list logo
