[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #18 from ojab 2012-08-18 14:45:07 UTC --- Still the same on latest libdrm/mesa/xf86-video-ati & kernel-3.5.2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 Yunrui Hu changed: What|Removed |Added CC||hyrathb at gmail.com --- Comment #3 from Yunrui Hu 2012-08-18 14:08:01 UTC --- (In reply to comment #2) > I can confirm this. > I suffer from the same problem with the same chip(i855).The terminal output > and > dmesg show the same thing as Bruno's. > The only difference is the game.I haven't tried > Imperialism 2 or other games,but both Warcraft3 and Heroes of Might & Magic3 > can cause this problem. > Please let me know if I can help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 --- Comment #2 from Yunrui Hu 2012-08-18 14:03:11 UTC --- I can confirm this. I suffer from the same problem with the same chip(i855).The terminal output and dmesg show the same thing as Bruno's. The only difference is the game.I don't know whether I haven't tried Imperialism 2 or other games,but both Warcraft3 and Heroes of Might & Magic3 can cause this problem. Please let me know if I can help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[UDL] general protection fault in fb_deferred_io_mkwrite()
Am Sonntag, den 12.08.2012, 14:22 -0700 schrieb Bernie Thompson: > On Sun, Aug 12, 2012 at 3:34 AM, Thomas Meyer wrote: > guilty driver is probably udl_fb.c > any ideas? > > > Hi Thomas, Hi Bernie! > We were seeing similar issues in udlfb (the original fbdev version of > this driver), which were fixed earlier this year by getting all > rendering operations out of probe/disconnect -- those which might > trigger fb_defio page faults in an inappropriate context, or be > long-running. Here's some more detail: > http://plugable.com/2012/06/21/displaylink-usb-devices-on-linux-kernel-3-4-0/comment-page-1/#comment-5896 > > > > Unfortunately, I haven't had time to get going with udl myself, so > haven't been able to port and confirm. Thanks for raising and staying > on this. Okay, I see. I'll switch to FB_UDL for now and remove DRM_UDL from my config. Is somebody working on porting commit https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8d21547d3c9c3bc653261f26d554cfabc4a083de to the DRM_UDL driver? In Airlie's tree seems to be no commit related to this: http://cgit.freedesktop.org/~airlied/linux/ with kind regards thomas > > > Best wishes, > Bernie > > > [ 45.66] RIP [] > fb_deferred_io_mkwrite+0xdc/0xf0 > [ 45.66] RSP > [ 45.711547] ---[ end trace d4732d5a0bf375fb ]--- > [ 45.720961] released /dev/fb1 user=1 count=0 > >
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: >> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >> >>> for , we have verified cases on inteldrmfb, radeondrmfb, and >>> cirrusdrmfb. >>> >>> This is the last message displayed before the system hangs. This seems >>> to be hitting a large number of users in Fedora, though certainly not >>> everyone. This started happening with the 3.5 updates, and is still an >>> issue. It appears to be a race condition, because various things have >>> allowed boot to continue for some users, though there is no clear work >>> around. Has anyone else run across this? Any ideas. For more >>> background we have the following bugs: >>> >>> inteldrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >>> >>> radeondrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >>> >>> cirrusdrmfb : >>> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >>> >>> It should be noted that the conflicting fb hw usage message is not new, >>> it has been around for a while, but this is the last message seen before >>> the hang. >> >> >> Hi, (adding dri-devel mailing list) >> >> >> I started seeing this problem on 3.5-rc6. >> >> AFAICT, the system is not actually hung, it's just that no output >> is showing up on the real (physical) output device (display) -- it's >> going somewhere else (or to the bit bucket). >> > > Can we bisect this at all? > > I worry the intel one will bisect to where we moved the conflict > resolution earlier, but I'd like to see if applying that patch earlier > causes the issue, since radeon has it. > > I haven't reproduced this on any hw I own, I also can't get it under qemu. I'm also wondering whether this grub2 related in some way, grub2 is starting to mess with the graphics adapter pointlessly. Dave.
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: > On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > >> for , we have verified cases on inteldrmfb, radeondrmfb, and >> cirrusdrmfb. >> >> This is the last message displayed before the system hangs. This seems >> to be hitting a large number of users in Fedora, though certainly not >> everyone. This started happening with the 3.5 updates, and is still an >> issue. It appears to be a race condition, because various things have >> allowed boot to continue for some users, though there is no clear work >> around. Has anyone else run across this? Any ideas. For more >> background we have the following bugs: >> >> inteldrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >> >> radeondrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >> >> cirrusdrmfb : >> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >> >> It should be noted that the conflicting fb hw usage message is not new, >> it has been around for a while, but this is the last message seen before >> the hang. > > > Hi, (adding dri-devel mailing list) > > > I started seeing this problem on 3.5-rc6. > > AFAICT, the system is not actually hung, it's just that no output > is showing up on the real (physical) output device (display) -- it's > going somewhere else (or to the bit bucket). > Can we bisect this at all? I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. I haven't reproduced this on any hw I own, I also can't get it under qemu. Dave.
[Bug 4804] endless loop in dri_utils.c
https://bugs.freedesktop.org/show_bug.cgi?id=4804 Matt Turner changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Matt Turner 2012-08-18 05:26:04 UTC --- DRI-1 code is long dead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #11 from Alexandre Demers 2012-08-18 05:09:01 UTC --- Created attachment 65723 --> https://bugs.freedesktop.org/attachment.cgi?id=65723 apitrace -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #10 from Alexandre Demers 2012-08-18 05:08:00 UTC --- Well, it seems running it through qapitrace doesn't lock. But running only this single test in a terminal does. One thing though: when using qapitrace and looking up state, framebuffer under surfaces is pretty much garbage whatever stage I look at. I don't know if this is expected fom depthstencil-render-miplevels 146 s=z24_s8_d=z32f_s8. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC 0/5] Generic panel framework
Hi Tomi, On Friday 17 August 2012 14:42:31 Tomi Valkeinen wrote: > On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: > > What kind of directory structure do you have in mind ? Panels are already > > isolated in drivers/video/panel/ so we could already ditch the panel- > > prefix in drivers. > > The same directory also contains files for the framework and buses. But > perhaps there's no need for additional directories if the amount of > non-panel files is small. And you can easily see from the name that they > are not panel drivers (e.g. mipi_dbi_bus.c). I don't expect the directory to contain many non-panel files, so let's keep it as-is for now. mipi-dbi-bus might not belong to include/video/panel/ though, as it can be used for non-panel devices (at least in theory). The future mipi-dsi-bus certainly will. > > Would you also create include/video/panel/ ? > > Perhaps that would be good. Well, having all the files prefixed with > panel- is not bad as such, but just feel extra. > > > > --- > > > > > > Should we aim for DT only solution from the start? DT is the direction > > > we are going, and I feel the older platform data stuff would be > > > deprecated soon. > > > > Don't forget about non-ARM architectures :-/ We need panel drivers for SH > > as well, which doesn't use DT. I don't think that would be a big issue, a > > DT- compliant solution should be easy to use through board code and > > platform data as well. > > I didn't forget about them as I didn't even think about them ;). I > somehow had the impression that other architectures would also use DT, > sooner or later. I could be mistaken, though. > > And true, it's not a big issue to support both DT and non-DT versions, > but I've been porting omap stuff for DT and keeping the old platform > data stuff also there, and it just feels burdensome. For very simple > panels it's easy, but when you've passing lots of parameters the code > starts to get longer. > > > > This one would be rather impossible with the upper layer handling the > > > enabling of the video stream. Thus I see that the panel driver needs to > > > control the sequences, and the Sharp panel driver's enable would look > > > something like: > > > > > > regulator_enable(...); > > > sleep(); > > > dpi_enable_video(); > > > sleep(); > > > gpip_set(..); > > > > I have to admit I have no better solution to propose at the moment, even > > if I don't really like making the panel control the video stream. When > > several devices will be present in the chain all of them might have > > similar annoying requirements, and my feeling is that the resulting code > > will be quite messy. At the end of the day the only way to really find > > out is to write an implementation. > > If we have a chain of devices, and each device uses the bus interface > from the previous device in the chain, there shouldn't be a problem. In > that model each device can handle the task however is best for it. > > I think the problems come from the divided control we'll have. I mean, > if the panel driver would decide itself what to send to its output, and > it would provide the data (think of an i2c device), this would be very > simple. And it actually is for things like configuration data etc, but > not so for video stream. Would you be able to send incremental patches on top of v2 to implement the solution you have in mind ? It would be neat if you could also implement mipi- dsi-bus for the OMAP DSS and test the code with a real device :-) > > > It could cause some locking issues, though. First the panel's remove > > > could take a lock, but the remove sequence would cause the display > > > driver to call disable on the panel, which could again try to take the > > > same lock... > > > > We have two possible ways of calling panel operations, either directly > > (panel->bus->ops->enable(...)) or indirectly (panel_enable(...)). > > > > The former is what V4L2 currently does with subdevs, and requires display > > drivers to hold a reference to the panel. The later can do without a > > direct reference only if we use a global lock, which is something I would > > like to > > Wouldn't panel_enable() just do the same panel->bus->ops->enable() > anyway, and both require a panel reference? I don't see the difference. Indeed, you're right. I'm not sure what I was thinking about. > > avoid. A panel-wide lock wouldn't work, as the access function would need > > to take the lock on a panel instance that can be removed at any time. > > Can't this be handled with some kind of get/put refcounting? If there's > a ref, it can't be removed. Trouble will come when the display driver will hold a reference to the panel, and the panel will hold a reference to the display driver (for instance because the display driver provides the DBI/DSI bus, or because it provides a clock used by the panel). > Generally about locks, if we define that panel ops may only be called > exclusively, does it simplify things? I
DRM/V4L2 buffer sharing
Hi Mauro, On Friday 17 August 2012 19:03:47 Mauro Carvalho Chehab wrote: > Em 17-08-2012 18:01, Sylwester Nawrocki escreveu: > > On 08/15/2012 11:09 PM, Laurent Pinchart wrote: > >> On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: > >>> On 08/15/2012 12:06 AM, Laurent Pinchart wrote: > On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: > > On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: > >> This one requires more testing: > >> > >> May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API > >> > >>http://patchwork.linuxtv.org/patch/11268 Sylwester > >>Nawrocki > >> > >> > > > > Hmm, this is not valid any more. Tomasz just posted a new patch series > > that adds DMABUF importer and exporter feature altogether. > > > > [PATCHv8 00/26] Integration of videobuf2 with DMABUF > > > > I guess we need someone else to submit test patches for other H/W than > > just Samsung SoCs. I'm not sure if we've got enough resources to port > > this to other hardware. We have been using these features internally > > for some time already. It's been 2 kernel releases and I can see only > > Ack tags from Laurent on Tomasz's patch series, hence it seems there > > is no wide interest in DMABUF support in V4L2 and this patch series is > > probably going to stay in a fridge for another few kernel releases. > > What would be required to push it to v3.7 ? > >>> > >>> Mauro requested more test coverage on that, which is understood since > >>> this is a fairly important API enhancement and the V4L2 video overlay > >>> API replacement. > >>> > >>> We need DMABUF support added at some webcam driver and a DRM driver with > >>> prime support (or some V4L2 output driver), I guess it would be best to > >>> have that in a PC environment. It looks like i915/radeon/nouveau drivers > >>> already have prime support. > >> > >> uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can > >> easily test that, except that I have no idea how to export buffers on > >> the i915 side when X is running. Have you looked into that ? > > > > All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop > > with i915 driver, but in the running system drmModeGetResources() just > > fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some > > light on this. > > Likely, you need to run with root permission to use it, or to write an Xorg > driver. > > It is probably easier to get the V4L driver there, that uses the > VIDIOC_OVERLAY stuff, and make it work via DMABUF: > http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/ That won't really help for our test cases. I want to capture from a UVC device using DMABUF import directly to the i915 DRM device using DRM export. In order to do so I will need to get hold of GEM objects that I can use to display the data, possibly through the OpenGL API. I'm looking for help on that last point, I can easily handle the UVC capture code myself. > In order to test it, xawtv has already the code needed to talk with the v4l > plugin. > > What the plugin does is to export the video board as a XV extension, > accessible via xawtv. It currently talks with the display card also via XV, > but I believe it won't be hard to port it to work with DMABUF. > > As the interface between xawtv and the v4l plugin is just Xv, changing the > code there from VIDIOC_OVERLAY to DMABUF should be trivial. -- Regards, Laurent Pinchart
DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org)
Hi Laurent, On 08/15/2012 11:09 PM, Laurent Pinchart wrote: > On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: >> On 08/15/2012 12:06 AM, Laurent Pinchart wrote: >>> On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: > This one requires more testing: > > May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API >http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki > Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether. [PATCHv8 00/26] Integration of videobuf2 with DMABUF I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases. >>> >>> What would be required to push it to v3.7 ? >> >> Mauro requested more test coverage on that, which is understood since this >> is a fairly important API enhancement and the V4L2 video overlay API >> replacement. >> >> We need DMABUF support added at some webcam driver and a DRM driver with >> prime support (or some V4L2 output driver), I guess it would be best to >> have that in a PC environment. It looks like i915/radeon/nouveau drivers >> already have prime support. > > uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily > test that, except that I have no idea how to export buffers on the i915 side > when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. >> The DRM driver could be an exporter of buffers that would be passed to the >> webcam driver. >> >> And except the kernel patches we would need a test application, similar >> to that one: >> http://git.infradead.org/users/kmpark/public-apps/blob/a7e755629a74a7ac13788 >> 2032a0f7b2480fa1490:/v4l2-drm-example/dmabuf-sharing.c >> >> I haven't been closely following the DMABUF APIs development, I think >> Tomasz could provide more details on that. >> >> It's likely I'll get around and prepare a test case as outlined above in >> coming days. Anyway, it would be appreciated if someone else could give this >> patch series a try. > > I've previously tested the patches on Renesas hardware, exporting buffers on > the FBDEV side and importing them on the V4L2 side. We thus have test results > for two different platforms, albeit all ARM-based. I guess ARM is where those APIs will be used mostly, still it would be helpful to have easier reproducible test environment. -- Thanks, Sylwester
[Bug 4804] endless loop in dri_utils.c
https://bugs.freedesktop.org/show_bug.cgi?id=4804 Matt Turner matts...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Matt Turner matts...@gmail.com 2012-08-18 05:26:04 UTC --- DRI-1 code is long dead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 --- Comment #2 from Yunrui Hu hyra...@gmail.com 2012-08-18 14:03:11 UTC --- I can confirm this. I suffer from the same problem with the same chip(i855).The terminal output and dmesg show the same thing as Bruno's. The only difference is the game.I don't know whether I haven't tried Imperialism 2 or other games,but both Warcraft3 and Heroes of Might Magic3 can cause this problem. Please let me know if I can help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 Yunrui Hu hyra...@gmail.com changed: What|Removed |Added CC||hyra...@gmail.com --- Comment #3 from Yunrui Hu hyra...@gmail.com 2012-08-18 14:08:01 UTC --- (In reply to comment #2) I can confirm this. I suffer from the same problem with the same chip(i855).The terminal output and dmesg show the same thing as Bruno's. The only difference is the game.I haven't tried Imperialism 2 or other games,but both Warcraft3 and Heroes of Might Magic3 can cause this problem. Please let me know if I can help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #18 from ojab o...@ojab.ru 2012-08-18 14:45:07 UTC --- Still the same on latest libdrm/mesa/xf86-video-ati kernel-3.5.2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.
Hi Hans I didnt catch this sentence in the documentation of the API It is not possible to set part of an EDID, it is always all or nothing. . Guess, I have to read the documentation thoroughly before making assumptions. It makes my question irrelevant. Best Regards Soby Mathew On Thu, Aug 16, 2012 at 11:25 PM, Soby Mathew soby.linu...@gmail.com wrote: Hi Hans, For EDID update, it is recommended that the HPD line be toggled after the EDID update is completed. So for the driver to detect the EDID write is complete, probably a field mentioning the EDID write completed would be good, so that the HPD toggling can be done by the driver. Best Regards Soby Mathew clipped ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/usb: select USB_SUPPORT in Kconfig
Hi Dave, What is your opinion about this patch? On 15 August 2012 01:27, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Aug 14, 2012 at 05:12:22PM +0530, Sachin Kamat wrote: In general what you suggested seems to be the right thing to do. However in this particular case, making this depends on creates recursive dependencies and probably that is the reason Dave Airlie decided to make it select USB (?) Probably, yes. Trying to fix this resulted in a race through Kconfig entries throughout the kernel. Given that your patch is probably ok, though this should really be fixed properly. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] Display switching support for Apple laptops
This series adds display switching support for Apple laptops. The first two patches contain preparatory changes to vga_switcheroo, and the third contains the changes to support display switching with the gmux. While these patches will allow switching the display mux, most Macbook owners will not be able to switch GPUs in practice until the graphics drivers are updated to deal with missing or incorrect vbios information on Apple machines. These patches do fix an issue seen by some users of Linux on Macbooks, however. These users will switch to the internal GPU in OS X and then reboot into Linux to save power, but after S3 the gmux gets reset to the discrete GPU. Adding the display mux support will fix this problem by restoring the gmux state during resume. v2: Disable interrupts during suspend and re-enable them during resume to fix timeouts waiting for switching to complete after S3 Thanks, Seth Andreas Heider (1): apple-gmux: Add display mux support Seth Forshee (2): vga_switcheroo: Don't require handler init callback vga_switcheroo: Remove assumptions about registration/unregistration ordering drivers/gpu/drm/nouveau/nouveau_acpi.c |6 - drivers/gpu/vga/vga_switcheroo.c | 61 + drivers/platform/x86/apple-gmux.c | 224 3 files changed, 262 insertions(+), 29 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] vga_switcheroo: Don't require handler init callback
This callback is a no-op in nouveau, and the upcoming apple-gmux
switcheroo support won't require it either. Rather than forcing drivers
to stub it out, just make it optional and remove the callback from
nouveau.
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_acpi.c |6 --
drivers/gpu/vga/vga_switcheroo.c |3 ++-
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index fc841e8..26ebffe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -211,11 +211,6 @@ static int nouveau_dsm_power_state(enum
vga_switcheroo_client_id id,
return nouveau_dsm_set_discrete_state(nouveau_dsm_priv.dhandle, state);
}
-static int nouveau_dsm_init(void)
-{
- return 0;
-}
-
static int nouveau_dsm_get_client_id(struct pci_dev *pdev)
{
/* easy option one - intel vendor ID means Integrated */
@@ -232,7 +227,6 @@ static int nouveau_dsm_get_client_id(struct pci_dev *pdev)
static struct vga_switcheroo_handler nouveau_dsm_handler = {
.switchto = nouveau_dsm_switchto,
.power_state = nouveau_dsm_power_state,
- .init = nouveau_dsm_init,
.get_client_id = nouveau_dsm_get_client_id,
};
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 5b3c7d1..ec9069d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -98,7 +98,8 @@ static void vga_switcheroo_enable(void)
struct vga_switcheroo_client *client;
/* call the handler to init */
- vgasr_priv.handler-init();
+ if (vgasr_priv.handler-init)
+ vgasr_priv.handler-init();
list_for_each_entry(client, vgasr_priv.clients, list) {
if (client-id != -1)
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] vga_switcheroo: Remove assumptions about registration/unregistration ordering
vga_switcheroo assumes that the handler will be registered before the
last client, otherwise switching will not be enabled. Likewise it's
assumed that the handler will not be unregistered without at least one
client also being unregistered, otherwise switching will remain enabled
despite no longer having a handler. These assumptions cannot be enforced
if the handler is in a separate driver from both clients, as with the
gmux found in Apple laptops. Remove this assumption.
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/gpu/vga/vga_switcheroo.c | 58 +++---
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index ec9069d..e25cf31 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -70,27 +70,12 @@ static struct vgasr_priv vgasr_priv = {
.clients = LIST_HEAD_INIT(vgasr_priv.clients),
};
-int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
-{
- mutex_lock(vgasr_mutex);
- if (vgasr_priv.handler) {
- mutex_unlock(vgasr_mutex);
- return -EINVAL;
- }
-
- vgasr_priv.handler = handler;
- mutex_unlock(vgasr_mutex);
- return 0;
-}
-EXPORT_SYMBOL(vga_switcheroo_register_handler);
-
-void vga_switcheroo_unregister_handler(void)
+static bool vga_switcheroo_ready(void)
{
- mutex_lock(vgasr_mutex);
- vgasr_priv.handler = NULL;
- mutex_unlock(vgasr_mutex);
+ /* we're ready if we get two clients + handler */
+ return !vgasr_priv.active
+ vgasr_priv.registered_clients == 2 vgasr_priv.handler;
}
-EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
static void vga_switcheroo_enable(void)
{
@@ -114,6 +99,37 @@ static void vga_switcheroo_enable(void)
vgasr_priv.active = true;
}
+int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
+{
+ mutex_lock(vgasr_mutex);
+ if (vgasr_priv.handler) {
+ mutex_unlock(vgasr_mutex);
+ return -EINVAL;
+ }
+
+ vgasr_priv.handler = handler;
+ if (vga_switcheroo_ready()) {
+ printk(KERN_INFO vga_switcheroo: enabled\n);
+ vga_switcheroo_enable();
+ }
+ mutex_unlock(vgasr_mutex);
+ return 0;
+}
+EXPORT_SYMBOL(vga_switcheroo_register_handler);
+
+void vga_switcheroo_unregister_handler(void)
+{
+ mutex_lock(vgasr_mutex);
+ vgasr_priv.handler = NULL;
+ if (vgasr_priv.active) {
+ pr_info(vga_switcheroo: disabled\n);
+ vga_switcheroo_debugfs_fini(vgasr_priv);
+ vgasr_priv.active = false;
+ }
+ mutex_unlock(vgasr_mutex);
+}
+EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
+
static int register_client(struct pci_dev *pdev,
const struct vga_switcheroo_client_ops *ops,
int id, bool active)
@@ -135,9 +151,7 @@ static int register_client(struct pci_dev *pdev,
if (client_is_vga(client))
vgasr_priv.registered_clients++;
- /* if we get two clients + handler */
- if (!vgasr_priv.active
- vgasr_priv.registered_clients == 2 vgasr_priv.handler) {
+ if (vga_switcheroo_ready()) {
printk(KERN_INFO vga_switcheroo: enabled\n);
vga_switcheroo_enable();
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] apple-gmux: Add display mux support
From: Andreas Heider andr...@meetr.de
Add support for the gmux display muxing functionality and register a mux
handler with vga_switcheroo.
Signed-off-by: Andreas Heider andr...@meetr.de
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/platform/x86/apple-gmux.c | 224 +
1 file changed, 224 insertions(+)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
index 612b6f6..c72e81e 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -2,6 +2,7 @@
* Gmux driver for Apple laptops
*
* Copyright (C) Canonical Ltd. seth.fors...@canonical.com
+ * Copyright (C) 2010-2012 Andreas Heider andr...@meetr.de
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -19,6 +20,8 @@
#include linux/apple_bl.h
#include linux/slab.h
#include linux/delay.h
+#include linux/pci.h
+#include linux/vga_switcheroo.h
#include acpi/video.h
#include asm/io.h
@@ -29,8 +32,17 @@ struct apple_gmux_data {
struct mutex index_lock;
struct backlight_device *bdev;
+
+ /* switcheroo data */
+ acpi_handle dhandle;
+ int gpe;
+ enum vga_switcheroo_client_id resume_client_id;
+ enum vga_switcheroo_state power_state;
+ struct completion powerchange_done;
};
+static struct apple_gmux_data *apple_gmux_data;
+
/*
* gmux port offsets. Many of these are not yet used, but may be in the
* future, and it's useful to have them documented here anyhow.
@@ -257,6 +269,146 @@ static const struct backlight_ops gmux_bl_ops = {
.update_status = gmux_update_status,
};
+static int gmux_switchto(enum vga_switcheroo_client_id id)
+{
+ if (id == VGA_SWITCHEROO_IGD) {
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
+ } else {
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
+ }
+
+ return 0;
+}
+
+static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data,
+ enum vga_switcheroo_state state)
+{
+ INIT_COMPLETION(gmux_data-powerchange_done);
+
+ if (state == VGA_SWITCHEROO_ON) {
+ gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 1);
+ gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 3);
+ pr_debug(Discrete card powered up\n);
+ } else {
+ gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 1);
+ gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 0);
+ pr_debug(Discrete card powered down\n);
+ }
+
+ gmux_data-power_state = state;
+
+ if (gmux_data-gpe = 0
+
!wait_for_completion_interruptible_timeout(gmux_data-powerchange_done,
+ msecs_to_jiffies(200)))
+ pr_warn(Timeout waiting for gmux switch to complete\n);
+
+ return 0;
+}
+
+static int gmux_set_power_state(enum vga_switcheroo_client_id id,
+ enum vga_switcheroo_state state)
+{
+ if (id == VGA_SWITCHEROO_IGD)
+ return 0;
+
+ return gmux_set_discrete_state(apple_gmux_data, state);
+}
+
+static int gmux_get_client_id(struct pci_dev *pdev)
+{
+ /*
+* Early Macbook Pros with switchable graphics use nvidia
+* integrated graphics. Hardcode that the 9400M is integrated.
+*/
+ if (pdev-vendor == PCI_VENDOR_ID_INTEL)
+ return VGA_SWITCHEROO_IGD;
+ else if (pdev-vendor == PCI_VENDOR_ID_NVIDIA
+pdev-device == 0x0863)
+ return VGA_SWITCHEROO_IGD;
+ else
+ return VGA_SWITCHEROO_DIS;
+}
+
+static enum vga_switcheroo_client_id
+gmux_active_client(struct apple_gmux_data *gmux_data)
+{
+ if (gmux_read8(gmux_data, GMUX_PORT_SWITCH_DISPLAY) == 2)
+ return VGA_SWITCHEROO_IGD;
+
+ return VGA_SWITCHEROO_DIS;
+}
+
+static struct vga_switcheroo_handler gmux_handler = {
+ .switchto = gmux_switchto,
+ .power_state = gmux_set_power_state,
+ .get_client_id = gmux_get_client_id,
+};
+
+static inline void gmux_disable_interrupts(struct apple_gmux_data *gmux_data)
+{
+ gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE,
+ GMUX_INTERRUPT_DISABLE);
+}
+
+static inline void gmux_enable_interrupts(struct apple_gmux_data *gmux_data)
+{
+ gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE,
+ GMUX_INTERRUPT_ENABLE);
+}
+
+static inline u8 gmux_interrupt_get_status(struct apple_gmux_data *gmux_data)
+{
+
DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org)
Hi Laurent, On 08/15/2012 11:09 PM, Laurent Pinchart wrote: On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: On 08/15/2012 12:06 AM, Laurent Pinchart wrote: On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: This one requires more testing: May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki s.nawro...@samsung.com Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether. [PATCHv8 00/26] Integration of videobuf2 with DMABUF I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases. What would be required to push it to v3.7 ? Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement. We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support. uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. The DRM driver could be an exporter of buffers that would be passed to the webcam driver. And except the kernel patches we would need a test application, similar to that one: http://git.infradead.org/users/kmpark/public-apps/blob/a7e755629a74a7ac13788 2032a0f7b2480fa1490:/v4l2-drm-example/dmabuf-sharing.c I haven't been closely following the DMABUF APIs development, I think Tomasz could provide more details on that. It's likely I'll get around and prepare a test case as outlined above in coming days. Anyway, it would be appreciated if someone else could give this patch series a try. I've previously tested the patches on Renesas hardware, exporting buffers on the FBDEV side and importing them on the V4L2 side. We thus have test results for two different platforms, albeit all ARM-based. I guess ARM is where those APIs will be used mostly, still it would be helpful to have easier reproducible test environment. -- Thanks, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM/V4L2 buffer sharing
Em 17-08-2012 18:01, Sylwester Nawrocki escreveu: Hi Laurent, On 08/15/2012 11:09 PM, Laurent Pinchart wrote: On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: On 08/15/2012 12:06 AM, Laurent Pinchart wrote: On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: This one requires more testing: May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki s.nawro...@samsung.com Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether. [PATCHv8 00/26] Integration of videobuf2 with DMABUF I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases. What would be required to push it to v3.7 ? Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement. We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support. uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. Likely, you need to run with root permission to use it, or to write an Xorg driver. It is probably easier to get the V4L driver there, that uses the VIDIOC_OVERLAY stuff, and make it work via DMABUF: http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/ In order to test it, xawtv has already the code needed to talk with the v4l plugin. What the plugin does is to export the video board as a XV extension, accessible via xawtv. It currently talks with the display card also via XV, but I believe it won't be hard to port it to work with DMABUF. As the interface between xawtv and the v4l plugin is just Xv, changing the code there from VIDIOC_OVERLAY to DMABUF should be trivial. Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [UDL] general protection fault in fb_deferred_io_mkwrite()
Am Sonntag, den 12.08.2012, 14:22 -0700 schrieb Bernie Thompson: On Sun, Aug 12, 2012 at 3:34 AM, Thomas Meyer tho...@m3y3r.de wrote: guilty driver is probably udl_fb.c any ideas? Hi Thomas, Hi Bernie! We were seeing similar issues in udlfb (the original fbdev version of this driver), which were fixed earlier this year by getting all rendering operations out of probe/disconnect -- those which might trigger fb_defio page faults in an inappropriate context, or be long-running. Here's some more detail: http://plugable.com/2012/06/21/displaylink-usb-devices-on-linux-kernel-3-4-0/comment-page-1/#comment-5896 Unfortunately, I haven't had time to get going with udl myself, so haven't been able to port and confirm. Thanks for raising and staying on this. Okay, I see. I'll switch to FB_UDL for now and remove DRM_UDL from my config. Is somebody working on porting commit https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8d21547d3c9c3bc653261f26d554cfabc4a083de to the DRM_UDL driver? In Airlie's tree seems to be no commit related to this: http://cgit.freedesktop.org/~airlied/linux/ with kind regards thomas Best wishes, Bernie [ 45.66] RIP [8123becc] fb_deferred_io_mkwrite+0xdc/0xf0 [ 45.66] RSP 880126559c98 [ 45.711547] ---[ end trace d4732d5a0bf375fb ]--- [ 45.720961] released /dev/fb1 user=1 count=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
MSAA is impossible without them.
Signed-off-by: Marek Olšák mar...@gmail.com
---
drivers/gpu/drm/radeon/r600_cs.c | 94 +-
drivers/gpu/drm/radeon/r600d.h | 17 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
4 files changed, 101 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 3dab49c..1bec5b8 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -47,13 +47,17 @@ struct r600_cs_track {
u32 npipes;
/* value we track */
u32 sq_config;
+ u32 log_nsamples;
u32 nsamples;
u32 cb_color_base_last[8];
struct radeon_bo*cb_color_bo[8];
u64 cb_color_bo_mc[8];
- u32 cb_color_bo_offset[8];
- struct radeon_bo*cb_color_frag_bo[8]; /* unused */
- struct radeon_bo*cb_color_tile_bo[8]; /* unused */
+ u64 cb_color_bo_offset[8];
+ struct radeon_bo*cb_color_frag_bo[8];
+ u64 cb_color_frag_offset[8];
+ struct radeon_bo*cb_color_tile_bo[8];
+ u64 cb_color_tile_offset[8];
+ u32 cb_color_mask[8];
u32 cb_color_info[8];
u32 cb_color_view[8];
u32 cb_color_size_idx[8]; /* unused */
@@ -349,10 +353,6 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
unsigned array_mode;
u32 format;
- if (G_0280A0_TILE_MODE(track-cb_color_info[i])) {
- dev_warn(p-dev, FMASK or CMASK buffer are not supported by
this kernel\n);
- return -EINVAL;
- }
size = radeon_bo_size(track-cb_color_bo[i]) -
track-cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track-cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
@@ -441,7 +441,7 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
* broken userspace.
*/
} else {
- dev_warn(p-dev, %s offset[%d] %d %d %d %lu too big
(%d %d) (%d %d %d)\n,
+ dev_warn(p-dev, %s offset[%d] %d %llu %d %lu too big
(%d %d) (%d %d %d)\n,
__func__, i, array_mode,
track-cb_color_bo_offset[i], tmp,
radeon_bo_size(track-cb_color_bo[i]),
@@ -458,6 +458,51 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
tmp = S_028060_PITCH_TILE_MAX((pitch / 8) - 1) |
S_028060_SLICE_TILE_MAX(slice_tile_max - 1);
ib[track-cb_color_size_idx[i]] = tmp;
+
+ /* FMASK/CMASK */
+ switch (G_0280A0_TILE_MODE(track-cb_color_info[i])) {
+ case V_0280A0_TILE_DISABLE:
+ break;
+ case V_0280A0_FRAG_ENABLE:
+ if (track-nsamples 1) {
+ uint32_t tile_max =
G_028100_FMASK_TILE_MAX(track-cb_color_mask[i]);
+ /* the tile size is 8x8, but the size is in units of
bits.
+* for bytes, do just * 8. */
+ uint32_t bytes = track-nsamples * track-log_nsamples
* 8 * (tile_max + 1);
+
+ if (bytes + track-cb_color_frag_offset[i]
+ radeon_bo_size(track-cb_color_frag_bo[i])) {
+ dev_warn(p-dev, %s FMASK_TILE_MAX too large
+(tile_max=%u, bytes=%u, offset=%llu,
bo_size=%lu)\n,
+__func__, tile_max, bytes,
+track-cb_color_frag_offset[i],
+
radeon_bo_size(track-cb_color_frag_bo[i]));
+ return -EINVAL;
+ }
+ }
+ /* fall through */
+ case V_0280A0_CLEAR_ENABLE:
+ {
+ uint32_t block_max =
G_028100_CMASK_BLOCK_MAX(track-cb_color_mask[i]);
+ /* One block = 128x128 pixels, one 8x8 tile has 4 bits..
+* (128*128) / (8*8) / 2 = 128 bytes per block. */
+ uint32_t bytes = (block_max + 1) * 128;
+
+ if (bytes + track-cb_color_tile_offset[i]
+ radeon_bo_size(track-cb_color_tile_bo[i])) {
+ dev_warn(p-dev, %s CMASK_BLOCK_MAX too large
+(block_max=%u, bytes=%u, offset=%llu,
bo_size=%lu)\n,
+__func__, block_max, bytes,
+track-cb_color_tile_offset[i],
+
