[no subject]

From: Yonatan Maman Date: Mon, 7 Oct 2024 14:48:26 +0300 Subject: [PATCH v2 0/2] drm/nouveau/dmem: Fix Memory Leaking and Device Channels configuration This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling, and memory leaks. - Memory L

[no subject]

Bcc: Subject: Re: [PATCH v9 3/8] x86/vmware: Introduce VMware hypercall API Reply-To: In-Reply-To: <683225e0-1cd3-4dea-bb68-086d46b23...@broadcom.com> + Joe Perches On Wed, May 22, 2024 at 04:39:57PM -0700, Alexey Makhalov wrote: > Hi Simon, apologize for long delay > > On 5/11/24 8:02 AM, Sim

[no subject]

Hi Dave, A few fixes for v6.8, description below The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b: drm/msm/dp: call dp_display_get_next_bridge() during probe (2023-12-14 09:27:46 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/drm/ms

[no subject]

Subject: [PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH") disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch. This innocent change has a significant side-effect on the ARM's multi_v7_defconfig, bec

[no subject]

This patch fix's the failure of the frame buffer driver on my Asahi kernel which prevented X11 from starting on my Apple M1 laptop. It seems like a straight forward failure to follow the procedure described in drivers/video/aperture.c to remove the ealier driver. This patch is very simple and m

[no subject]

Any progress on this? Is it ok if yi...@chromium.org and I do the followups on this patch so that we can also submit the Hotplug patch I wrote (that's now archived?).

[no subject]

Date: Sat, 11 Mar 2023 19:00:03 + Subject: [PATCH 5.10 1/1] drm/amdgpu: add error handling for drm_fb_helper_initial_config The type of return value of drm_fb_helper_initial_config is int, which may return wrong result, so we add error handling for it to reclaim memory resource, and return w

[no subject]

Date: Thu, 10 Nov 2022 16:47:26 +0300 Subject: [PATCH] drm/amdgpu/display: Add pointer check Return value of a function 'dc_create_state' is dereferenced at amdgpu_dm.c:2027 without checking for null Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev -

[no subject]

Date: Tue, 22 Nov 2022 15:51:44 +0300 Subject: [PATCH] powerplay: hwmgr: added result check The return value of the 'div64_s64' function called in ppevvmath.h:371 was not checked. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev --- drivers/gpu/drm/

[no subject]

Just sending that out once more to intel-gfx to let the CI systems take a look. No functional change compared to the last version. Christian.

[no subject]

Just sending that to intel-gfx to let the CI systems take a look at it. Regards, Christian.

[no subject]

Hey Linus, pretty quiet week, one fbdev, msm, kconfig, and 2 amdgpu fixes, about what I'd expect for rc6. Regards, Dave. drm-fixes-2022-05-06: drm fixes for 5.18-rc6 fbdev: - hotunplugging fix amdgpu: - Fix a xen dom0 regression on APUs - Fix a potential array overflow if a receiver were to

[no subject]

Hi Daniel, rebased on top of all the changes in drm-misc-next now and hopefully ready for 5.19. I think I addressed all concern, but there was a bunch of rebase fallout from i915, so better to double check that once more. Regards, Christian.

[no subject]

Hello everyone, my name is Shashank Singh. I hope this is the right platform to reach out to the 'X.org' community. I was curious about the X.org Endless Vacation of Code. Is this program still active?

[no subject]

>From Dmitry Baryshkov # This line is ignored. From: Dmitry Baryshkov Reply-To: Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code In-Reply-To: There is no need to request most of hardware blocks through the resource manager (RM), since typically there is 1:1 or N:1 relationship between cor

[no subject]

Hi Linus, Regular fixes for final, there is a ttm regression fix, dp-mst fix, one amdgpu revert, two i915 fixes, and some misc fixes for sun4i, xlnx, and vc4. All pretty quiet and don't think we have any known outstanding regressions. Dave. drm-fixes-2021-02-12: drm fixes for 5.11-rc8 ttm: - p

[no subject]

Ayuda ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

Signed-off-by: Sandeep Raghuraman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

The goal here is to make the ttm_tt object just represent a memory backing store, and now whether the store is bound to a global translation table. It moves binding up to the bo level. There's a lot more work on removing the global TT from the core of TTM, but this seems like a good start. Dave.

[no subject]

Hi Dave, A few fixes, mostly fallout from the address space refactor and dpu color processing. The following changes since commit 1cb2c4a2c89b2004a36399860c85a1af9b3fcba7: Revert "drm/msm/dpu: add support for clk and bw scaling for display" (2020-06-01 20:56:18 -0700) are available in the Gi

[no subject]

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.gh13...@intel.com> References: <20200219203544.31013-1-ville.syrj...@linux.intel.com> <20200219203544.31013-5-ville.syrj...@linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com> <20200225112114.ga13.

[no subject]

Hi Dave, This time around: + OCMEM support to enable the couple generations that had shared OCMEM rather than GMEM exclusively for the GPU (late a3xx and I think basically all of a4xx). Bjorn and Brian decided to land this through the drm tree to avoid having to coordinate merge requests.

[no subject]

Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes With further testing of recent changes with lockdep and other locking checks enabled, we've found several bugs in the shrinker code and one sleep while atomic in panfrost_gem_open(). This series addresses those issues. Delaying the un

[no subject]

The first three patches prepare for the removal of drmP.h. The last patch remove use of drmP.h and replace with necessary include files to fix build. Build tested with various configs and various architectures. I had preferred that the via driver was replaced by the openchrome driver, but until w

[no subject]

Hey Linus, A small bit more lively this week but not majorly so. I'm away in Japan next week for family holiday, so I'll be pretty disconnected, I've asked Daniel to do fixes for the week while I'm out. core: - Allow fb changes in async commits (drivers as well) udmabuf: - Unmap scatterlist when

[no subject]

From tho...@m3y3r.de Sun May 26 13:49:04 2019 Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated To: tomi.valkei...@ti.com, airl...@linux.ie, dan...@ffwll.ch, dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Mime-Version

[no subject]

Hi Linus, Just a couple of fixes PRs for rc1, One MAINTAINERS address change, two panels fixes, and set of amdgpu fixes (build fixes, display fixes and some others). Thanks Dave. drm-next-2018-08-24: amdgpu and panel/misc fixes. The following changes since commit 3d63a3c14741ed015948943076f3c6a

[no subject]

Hi Linus, (apologies for blank body pull earlier) This is the drm fixes for rc4. It's a bit larger than I'd like but the exynos cleanups are pretty mechanical, and I'd rather have them in sooner rather than later so we can avoid too much conflicts around them. The non-mechanincal exynos changes ar

[no subject]

___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

linux-...@vger.kernel.org,Noralf Trønnes ,Sean Paul ,ker...@martin.sperl.org Cc: Bcc: Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers Reply-To: In-Reply-To: On Sun, Mar 04, 2018 at 06:38:42PM +0100, Noralf Trønnes wrote: > > Den 02.03.2018 12.11, skrev Meghana Madhyastha: > >On

[no subject]

Hi Linus, This is the main set of fixes for rc4, one amdgpu fix, some exynos regression fixes, some msm fixes and some i915 and GVT fixes. I've got a second regression fix for some DP chips that might be a bit large, but I think we'd like to land it now, I'll send it along tomorrow, once you are

No subject

hi, I'm a new programmer, i just was wondering if i can get some docs to start learning DRI. I googled a lot but i didn't find a starter documentation. Some refs will be apreciated thx

No subject

Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges Hi, This serie is about adding support for the RGB to VGA bridge found in the A13-Olinuxino and the CHIP VGA adapter. Both these boards rely on an entirely passive bridge made out of resitor ladders that do not require any i

No subject

With patch http://patchwork.freedesktop.org/patch/msgid/1455106118-32145-1-git-send-email-palminha at synopsys.com i2c slave encoder drivers no longer need to implement dummy mode_fixup function. This patch set nukes the dummy functions from i2c slave encoder drivers. (changes made on top of Da

[no subject]

On 2014.09.07 at 23:47 -0400, Alex Deucher wrote: > On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf > wrote: > > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote: > >> Let me know if it works for you, cause we don't really have any hardware > >> any more to test it. > > > > I've tested your

[no subject]

On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf wrote: > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote: >> Let me know if it works for you, cause we don't really have any hardware >> any more to test it. > > I've tested your patch series today (using drm-next-3.18 from > ~agd5f/linux) on

[no subject]

On 2014.08.25 at 11:10 +0200, Christian K?nig wrote: > Let me know if it works for you, cause we don't really have any hardware > any more to test it. I've tested your patch series today (using drm-next-3.18 from ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264 videos. While

[no subject]

Let me know if it works for you, cause we don't really have any hardware any more to test it. Christian. Am 24.08.2014 um 15:34 schrieb Mike Lothian: > > Thanks for this > > Good work > > On 24 Aug 2014 14:15, "Christian K?nig" > wrote: > > Hello everyone,

No subject

Hello everyone, the following patches add UVD support for older ASICs (RV6xx, RS[78]80, RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release Additionally to the patches you need UVD firmware as wel

[no subject]

Thanks for this Good work On 24 Aug 2014 14:15, "Christian K?nig" wrote: > Hello everyone, > > the following patches add UVD support for older ASICs (RV6xx, RS[78]80, > RV7[79]0). For everybody wanting to test it I've also uploaded a branch to > FDO: > http://cgit.freedesktop.org/~deathsimple/li

No subject

After a previous patch series and a discussion with Daniel Vetter and David Herrmann, I've reworked the patches a bit. Please review. Patch 5 is already reviewed. /Thomas >From Thomas Hellstrom # This line is ignored. From: Thomas Hellstrom Subject: In-Reply-To:

No subject

Hey Alex, here are my patches for reworking the ring function pointers and separating out the UVD and DMA rings. Everything is rebased on your drm-next-3.12-wip branch, please review and add them to your branch. Thanks, Christian.

[no subject]

On Tue, Aug 13, 2013 at 5:56 AM, Christian K?nig wrote: > Hey Alex, > > here are my patches for reworking the ring function pointers and separating > out the UVD and DMA rings. > > Everything is rebased on your drm-next-3.12-wip branch, please review and add > them to your branch. Patches look

[no subject]

Hey Alex, here are my patches for reworking the ring function pointers and separating out the UVD and DMA rings. Everything is rebased on your drm-next-3.12-wip branch, please review and add them to your branch. Thanks, Christian. ___ dri-devel mail

No subject

, pza Bcc: Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings Reply-To: In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 09:13:09 up 103 days, 22:24, 36

[no subject]

, pza Bcc: Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings Reply-To: In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 09:13:09 up 103 days, 22:24, 36

No subject

issue is that changing it will break any app relying on it being REALTIME clock.

No subject

0x0314e050: 0x61010006: STATE_BASE_ADDRESS 0x0314e054: 0x0001:general state base address 0x 0x0314e058: 0x0001:surface state base address 0x 0x0314e05c: 0x0001:indirect state base address 0x 0x0314e060: 0x0001:instruct

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has be

No subject

i don't think kernel is the right place for it, for instance you need to set the primary surface thing, i don't want to parse cmd stream in kernel to figure that out. I would rather have userspace tool that postprocess thing and convert it to proper AMD dump format. Cheers, Jerome

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has be

[no subject]

On 05/18/2012 02:27 PM, Sascha Hauer wrote: > Hi All, > > The following adds a drm/kms driver for the Freescale i.MX LCDC > controller. Most notable change to the last SDRM based version is that > the SDRM layer has been removed and the driver now is purely i.MX > specific. I hope that this is mor

No subject

Hi All, The following adds a drm/kms driver for the Freescale i.MX LCDC controller. Most notable change to the last SDRM based version is that the SDRM layer has been removed and the driver now is purely i.MX specific. I hope that this is more acceptable now. Another change is that the probe is n

[no subject]

Hi All, The following adds a drm/kms driver for the Freescale i.MX LCDC controller. Most notable change to the last SDRM based version is that the SDRM layer has been removed and the driver now is purely i.MX specific. I hope that this is more acceptable now. Another change is that the probe is n

No subject

is still queued, which I don't completely like but at least the pinning and hw use of the userspace buffer is just temporary and not able to exist for an indefinite amount of time. BR, -R > Thanks, > Inki Dae > >> So I'm really not sure the best way to move this forward, maybe a very >> clear set

No subject

> Those two checks could probably be combined into one (< values || > values) > for further simplification. Answer: Fixed. The new function was just copy-paste, but your suggestion is good. diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index d3aaeb6..6014413 100644 --- a/dr

No subject

> Please add that to the error message and use printk_once() since we only > really want to annoy the user the first time. For each time we see the message, we need to increase the value by 1, so instead of using printk_once, I just added this information to the message. Anyway, we shouldn't be se

No subject

> > Perhaps we could add a debug message here for catch the unhandled types.. > This shouldn't happen. The previous checks should eliminate all objects that don't have properties. The only possibility I can think of is if we add properties to a new kind of object and forget to include it in the s

No subject

> How about adding obj->properties.count to avoid having to count every > time? I just blindly followed the connector properties example. But your idea is good, so I implemented it. Fixed, but in a new patch near the end of the series. Putting the in the end of the series should make it easier to r

No subject

> Subject: [PATCH 1/1] =A0=A0=A0 drivers/gpu/drm/i915: Fixed uninitialized=A0variables (warnings).MIME-Version: 1.0Content-Type: text/plain;= charset=3DUTF-8Content-Transfer-Encoding: 8bitAs you see, this= modifications were really very important because if the remain variable re= ceives a value

No subject

than escalating the bug into a random failure. -Chris -- Chris Wilson, Intel Open Source Technology Centre

No subject

No subject

No subject

No subject

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers.

No subject

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers.

[no subject]

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers. >From EDID spec we can (might?) infer modes using GTF and CVT when monitor >allows it trough range limited flag... obviously limiting by the range. >From our code: * EDID spec

[no subject]

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers. >From EDID spec we can (might?) infer modes using GTF and CVT when monitor >allows it trough range limited flag... obviously limiting by the range. >From our code: * EDID spec

No subject

Under some circumstances, pci_map_rom() can return a valid mapping but a size of 0 (if it cannot find an image in the header). This causes nouveau to try to kmalloc() a 0 sized pointer and dereference it, which crashes. Signed-off-by: Benjamin Herrenschmidt --- Please send to Linus asap, withou

No subject

when the corresponding pins are not actually hooked up to anything. In these cases, there is no NAK, nor timeout, nor any other indication from the GMBUS controller that a transaction fails. The first gmbus transaction timeout is caught by the "wait_for" timeout, causing the transition to bit-ban

No subject

makes me afraid of some weird GTT flushing issue, given the adventures we had with VT-d on that hardware where we idle the gpu before any GTT updates. I wonder what would happen if we idled the GPU before any GTT updates even when VT-d wasn't running... > The latest thinking on the hibernate issue

No subject

-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

by the DMM so that we can do the PAT programming and that can only be gotten from the hwmod entry. And if you use the hwmod device entry, you have to match the name used for that entry. Regards, Andy

No subject

k in return path of radeon_fence_count_emitted" fixes=0Athe problem. Tested= on top of 47492a23a and 3.3.0-rc3+00188-g3ec1e88.=0A=0A=0AThanks,=0A=0AMik= ko

No subject

sl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand th= at if I don't have kernel with support for the new ioctl it breaks the test= s, however if the ioctl was disabled later shouldn't be current git working un= less another regression happened? > Anyway, sorry,

No subject

disable the output polling during suspend. The following patch seems to get rid of the problems I'm seeing. Does this look okay to you?

No subject

dangerball: intel_tris.c:128: intel_extend_inline: Assertion 'intel->prim.flush == intel_flush_inline_primitive' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

GPU lockup CP stall for more than 1msec Jan 23 23:53:54 thoregon kernel: [17121.080137] GPU lockup (waiting for 0x002080B7 last fence id 0x002080B6) Jan 23 23:53:54 thoregon kernel: [17121.096334] radeon :07:00.0: GPU softreset Jan 23 23:53:54 thoregon kernel: [17121.096341] radeon :07:

No subject

/usr/sbin/run-crons && /usr/sbin/run-crons) Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0: GPU lockup CP stall for more than 1msec Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting for 0x0003F1F2 last fence id 0x0003F1F1) Jan 21 19:39:41 thoregon kernel:

No subject

symbol is exported without explicit consent of the original author (regardless of what we think about GPL/proprietary modules covtroversy). So if NVidia needs to link DMA buffer sharing against their proprietary driver, they should have explicit permission from the original author to turn its s

No subject

this sort of thing, nouveau is a good solution its just not going to beat the binary driver in a lot of ways, just not sure whether I care enough yet. Dave.

No subject

However softpipe does not have polygons disappearing at all, so it would appear to be a r300g problem. PrBoom uses GL_TRIANGLE_STRIPs to draw the walls, so this is probably unrelated to this bug. And another thing I noticed fixed. The OGLSB4th Edition chapter 16 vertexblend draws the shiny light c

No subject

Dec 11 17:16:36 nf7 kernel: [drm] Initialized drm 1.1.0 20060810 Dec 11 17:16:37 nf7 kernel: [drm] radeon kernel modesetting enabled. Dec 11 17:16:37 nf7 kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: PCI INT A -> Link[APC4] -> GSI 19 (l

No subject

Windows. There are only two physical keys: - power-on button - "keyboard"-labeled button, which seems to do nothing hardware-related; it triggers an event caught up by acer_wmi. I think all it does is telling the OS: "hey, pull up the software virtual keyboard on the second display". >

No subject

start_kernel |-> setup_arch |-> x86_init.oem.arch_setup = xen_arch_setup |-> check_bugs |-> identify_boot_cpu |-> identify_cpu |-> select_idle_routine so xen_arch_setup will set pm_idle and select_idle_routine will honour it. I'm being told thi

No subject

allocating request. Though, it's unlikely cause if request is NULL then BUG_ON will be hit in i915_add_request(). So, to unify the callee uses of i915_add_request(), I'm proposing the following patch. Please let me know what do you guys think. If you guys agree, I can sent a formal patch. Index: w

No subject

are looking for. I recognize that it disrupts your current views/plans on how this should be done, but I do want to work with you to find a suitable middle ground that covers most of the possiblities. In case you are looking at my code to follow the above-described scenarios, please make sure y

No subject

When the root cause will be discovered, we should allow both of course. But so far, all the attempts on this weren't successful. -- Eugeni Dodonov --bcaec54306ded2a5b704b258e725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

No subject

some other method before passing the frame off to the overlay. Rather disappointing, and seemingly not of too much use. But, I'd like to expose what functionality there is in any case. Ben. > > v2: fix ABI of get_plane - move format_type_ptr to the end > > Acked-by: Alan Cox > Reviewed-by: R

No subject

be -EREMOTEIO, which could be caused by transmission error so it should be retried. -- Eugeni Dodonov --bcaec51f8fc3b70e6504af85018a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2011 at 18:41, Keith Packard

No subject

install libtxc_dxtn -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no evict flags, then i guess it got evicted on first bo allocation which is strange, maybe first bo has some lpfn constraint. >> > =A0 =A0 =A0 =A0Second question I have is how are monochrome cursor ima= ges >> > handled with KMS. Yes

No subject

Hi, Dave. I am sending a mail I wonder where are we on this. I had sent DRM Driver patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any comments from you. You can refer to these patches I sent from links below. v1: < https://lwn.net/Articles/454380/ > v2: < http://www.sp

[no subject]

Hi, Dave. I am sending a mail I wonder where are we on this. I had sent DRM Driver patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any comments from you. You can refer to these patches I sent from links below. v1: < https://lwn.net/Articles/454380/ > v2: < http://www.

No subject

Power_Down_delay value, which is actually documented to be the 'T3 time sequence' value used 'during power up'. There aren't separate T1 and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS register, so I use that instead. VBT doesn't provide any values for T1 or T2, so we'll alw

No subject

> Please report at bugs.freedesktop.org This also happens with the wine tests. I wanted to add this on the Mesa bug, but I don't have my password at the moment(different keychain). For the Mesa devs debugging the tests may be easier than debugging NFS:MW. (see: http://bugs.winehq.org/show_bug.cgi?

No subject

Power_Down_delay value, which is actually documented to be the 'T3 time sequence' value used 'during power up'. There aren't separate T1 and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS register, so I use that instead. VBT doesn't provide any values for T1 or T2, so we'll alw

No subject

legacy interface provided on top of DRM/KMS driver mostly via helper functions. With this approach, you get the richer KMS API (and all the related plumbing for hotplug, EDID parsing, multi-head support, flipping, etc) for userspace stuff that needs that, but can keep the fbdev userspace interface

No subject

bisecting brought me to commit 288d5abec8314ae50fe6692f324b0444acae8486. Reverting seems to work as microcode is loaded with compiled in firmware and radeon kms driver. That's commit 288d5abec8314ae50fe6692f324b0444acae8486 Author: Linus Torvalds Date: Wed Aug 3 22:03:29 2011 -1000 Boot

No subject

-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

  1   2   >