Re: [Intel-gfx] (no subject)
Listen, here’s the problem I’m having guys and I need someone to reply back to me. Because I wrote to FSF and they wrote me right back and I join their and I have no problem with free software and complain but I don’t exactly know what you want me to do and I don’t have “git” on my windows computer. And it seems like you guys are making it hard for me to do anything in the first place I can’t even connect to the Internet can someone help me out? what problem am Iresolving > > On Jun 20, 2023 at 7:55 PM, (mailto:patchw...@emeril.freedesktop.org)> wrote: > > > > == Series Details == Series: drm/i915:fix kernel-doc trivial warnings URL : > https://patchwork.freedesktop.org/series/119620/ State : failure == Summary > == Error: patch > https://patchwork.freedesktop.org/api/1.0/series/119620/revisions/1/mbox/ not > applied Applying: drm/i915:fix kernel-doc trivial warnings Using index info > to reconstruct a base tree... M drivers/gpu/drm/i915/i915_active.h M > drivers/gpu/drm/i915/i915_gpu_error.c M drivers/gpu/drm/i915/i915_perf.c M > drivers/gpu/drm/i915/i915_scatterlist.h M drivers/gpu/drm/i915/i915_utils.h M > drivers/gpu/drm/i915/i915_vma_resource.h Falling back to patching base and > 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_vma_resource.h > Auto-merging drivers/gpu/drm/i915/i915_utils.h Auto-merging > drivers/gpu/drm/i915/i915_scatterlist.h Auto-merging > drivers/gpu/drm/i915/i915_perf.c CONFLICT (content): Merge conflict in > drivers/gpu/drm/i915/i915_perf.c Auto-merging > drivers/gpu/drm/i915/i915_gpu_error.c CONFLICT (content): Merge conflict in > drivers/gpu/drm/i915/i915_gpu_error.c error: Failed to merge in the changes. > hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch > failed at 0001 drm/i915:fix kernel-doc trivial warnings When you have > resolved this problem, run "git am --continue". If you prefer to skip this > patch, run "git am --skip" instead. To restore the original branch and stop > patching, run "git am --abort". Build failed, no error log produced > >
[Intel-gfx] (no subject)
Subject: [PATCH 0/1] Add PXP firmware respose on ARB failure Add PXP firmware respose on ARB failure Signed-off-by: Alan Previn Alan Previn (1): drm/i915/pxp: Add firmware status when ARB session fails drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 1 + drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 2 ++ 2 files changed, 3 insertions(+) base-commit: fea329811a7bc341aac5f51ab66ec41a3d0844af -- 2.25.1
Re: [Intel-gfx] (no subject)
On Thu, 19 May 2022 at 10:55, Christian König wrote: > > Just sending that out once more to intel-gfx to let the CI systems take > a look. If all went well it should normally appear at [1][2], if CI was able to pick up the series. Since it's not currently there, I assume it's temporarily stuck in the moderation queue, assuming you are not subscribed to intel-gfx ml? If so, perhaps consider subscribing at [3] and then disable receiving any mail from the ml, so you get full use of CI without getting spammed. [1] https://intel-gfx-ci.01.org/queue/index.html [2] https://patchwork.freedesktop.org/project/intel-gfx/series/ [3] https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > No functional change compared to the last version. > > Christian. > >
Re: [Intel-gfx] (no subject)
On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä > wrote: > > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > > > wrote: > > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > > are not simple but contains a display controller and memory. > > > > > That means that the speed over the link to the display and > > > > > actual refresh rate on the actual display is asymmetric because > > > > > well we are just updating a RAM, the resolution just limits how > > > > > much data we are sending, the clock limits the speed on the > > > > > bus over to the RAM on the other side. > > > > > > > > IMO even in command mode mode->clock should probably be the actual > > > > dotclock used by the display. If there's another clock for the bus > > > > speed/etc. it should be stored somewhere else. > > > > > > Good point. For the DSI panels we have the field hs_rate > > > for the HS clock in struct mipi_dsi_device which is based > > > on exactly this reasoning. And that is what I actually use for > > > setting the HS clock. > > > > > > The problem is however that we in many cases have so > > > substandard documentation of these panels that we have > > > absolutely no idea about the dotclock. Maybe we should > > > just set it to 0 in these cases? > > > > Don't you always have a TE interrupt or something like that > > available? Could just measure it from that if no better > > information is available? > > Yes and I did exactly that, so that is why this comment is in > the driver: > > static const struct drm_display_mode sony_acx424akp_cmd_mode = { > (...) > /* > * Some desired refresh rate, experiments at the maximum "pixel" > * clock speed (HS clock 420 MHz) yields around 117Hz. > */ > .vrefresh = 60, > > I got a review comment at the time saying 117 Hz was weird. > We didn't reach a proper conclusion on this: > https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=l...@mail.gmail.com/ > > Thierry wasn't sure if 60Hz was good or not, so I just had to > go with something. > > We could calculate the resulting pixel clock for ~117 Hz with > this resolution and put that in the clock field but ... don't know > what is the best? I would vote for that approach. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä wrote: > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > > wrote: > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > are not simple but contains a display controller and memory. > > > > That means that the speed over the link to the display and > > > > actual refresh rate on the actual display is asymmetric because > > > > well we are just updating a RAM, the resolution just limits how > > > > much data we are sending, the clock limits the speed on the > > > > bus over to the RAM on the other side. > > > > > > IMO even in command mode mode->clock should probably be the actual > > > dotclock used by the display. If there's another clock for the bus > > > speed/etc. it should be stored somewhere else. > > > > Good point. For the DSI panels we have the field hs_rate > > for the HS clock in struct mipi_dsi_device which is based > > on exactly this reasoning. And that is what I actually use for > > setting the HS clock. > > > > The problem is however that we in many cases have so > > substandard documentation of these panels that we have > > absolutely no idea about the dotclock. Maybe we should > > just set it to 0 in these cases? > > Don't you always have a TE interrupt or something like that > available? Could just measure it from that if no better > information is available? Yes and I did exactly that, so that is why this comment is in the driver: static const struct drm_display_mode sony_acx424akp_cmd_mode = { (...) /* * Some desired refresh rate, experiments at the maximum "pixel" * clock speed (HS clock 420 MHz) yields around 117Hz. */ .vrefresh = 60, I got a review comment at the time saying 117 Hz was weird. We didn't reach a proper conclusion on this: https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=l...@mail.gmail.com/ Thierry wasn't sure if 60Hz was good or not, so I just had to go with something. We could calculate the resulting pixel clock for ~117 Hz with this resolution and put that in the clock field but ... don't know what is the best? Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display controller and memory. > > > That means that the speed over the link to the display and > > > actual refresh rate on the actual display is asymmetric because > > > well we are just updating a RAM, the resolution just limits how > > > much data we are sending, the clock limits the speed on the > > > bus over to the RAM on the other side. > > > > IMO even in command mode mode->clock should probably be the actual > > dotclock used by the display. If there's another clock for the bus > > speed/etc. it should be stored somewhere else. > > Good point. For the DSI panels we have the field hs_rate > for the HS clock in struct mipi_dsi_device which is based > on exactly this reasoning. And that is what I actually use for > setting the HS clock. > > The problem is however that we in many cases have so > substandard documentation of these panels that we have > absolutely no idea about the dotclock. Maybe we should > just set it to 0 in these cases? Don't you always have a TE interrupt or something like that available? Could just measure it from that if no better information is available? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä wrote: > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > I have long suspected that a whole bunch of the "simple" displays > > are not simple but contains a display controller and memory. > > That means that the speed over the link to the display and > > actual refresh rate on the actual display is asymmetric because > > well we are just updating a RAM, the resolution just limits how > > much data we are sending, the clock limits the speed on the > > bus over to the RAM on the other side. > > IMO even in command mode mode->clock should probably be the actual > dotclock used by the display. If there's another clock for the bus > speed/etc. it should be stored somewhere else. Good point. For the DSI panels we have the field hs_rate for the HS clock in struct mipi_dsi_device which is based on exactly this reasoning. And that is what I actually use for setting the HS clock. The problem is however that we in many cases have so substandard documentation of these panels that we have absolutely no idea about the dotclock. Maybe we should just set it to 0 in these cases? Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (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...@intel.com> <3ca785f2-9032-aaf9-0965-8657d3111...@samsung.com> <20200225154506.gf13...@intel.com> <20200225192720.gg13...@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä > wrote: > > > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples. > > That's impressive :D > > > Unfortunately it found a lot of strange stuff: > > I will answer for the weirdness I caused. > > I have long suspected that a whole bunch of the "simple" displays > are not simple but contains a display controller and memory. > That means that the speed over the link to the display and > actual refresh rate on the actual display is asymmetric because > well we are just updating a RAM, the resolution just limits how > much data we are sending, the clock limits the speed on the > bus over to the RAM on the other side. IMO even in command mode mode->clock should probably be the actual dotclock used by the display. If there's another clock for the bus speed/etc. it should be stored somewhere else. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Next try of prework for unpinned DMA-buf operation. Only send to intel-gfx to trigger unit tests on the following patches. Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Hi everyone, I don't know if this is too specialised for this list. Anyway, no harm in asking the question :-) *Preamble* Build: Yocto from the Apollo Lake BSP release *gold, * Hardware: Oxbow Hill Rev B CRB with Intel Atom E3950 and 4GB DDR3 RAM (one SODIMM) Build: core-image-sato-sdk Installed on the onboard eMMC. OpenCL: installed user space drivers from SRB4 https://software.intel. com/file/533571/download I'm currently evaluating the Apollo Lake platform as a candidate to run our embedded application. We already have this application running on less powerful ARM based Linux systems with Mali GPU using OpenCL 1.2. We're now evaluating the E3950 as a faster alternative. To evaluate the application I need OpenCL 1.2 or later. To verify the OpenCL installation I have built and run the Intel demo apps: CapsBasic and Bitonic Sort. CapsBasic sees two devices: CPU and GPU and Bitonic sort can run its kernels correctly on both the CPU and the GPU. *The issue* Simply put, the application has - thread 1 (feeder): has a loop that feeds data into OpenCL and queues kernels - thread 2 (consumer): waits for results and reads output data. - an OpenCL Host command queue with out-of-order execution enabled When I run my app and select the GPU OpenCL device, the feeder thread *stalls inside a blocking call to clEnqueueMapBuffer(). *At this point only one thing has been queued on the command queue: a buffer unmap command for a different buffer. This unmap is waiting for an OpenCL event that will indicate data ready to be processed. In contrast, when I run my app and select the *CPU OpenCL *device, it works perfectly. Does anyone have any ideas on 1. what might be causing this problem running with the GPU? 2. how to debug this on the Yocto platform? Best regards, Tony -- Tony Whittam Rapt Touch -- Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Rapt Touch Ltd via email at i...@rapttouch.com and delete or destroy any copy of this message and its attachments. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
On 11.11.2016 18:16, Daniel Vetter wrote: > On Fri, Nov 11, 2016 at 07:41:10PM +0200, Abdiel Janulgue wrote: >> A lot of igt testcases need some GPU workload to make sure a race >> window is big enough. Unfortunately having a fixed amount of >> workload leads to spurious test failures or overtly long runtimes >> on some fast/slow platforms. This library contains functionality >> to submit GPU workloads that should consume exactly a specific >> amount of time. >> >> v2 : Add recursive batch feature from Chris >> v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch >> by adding a dummy reloc to the bo as suggested by Ville. >> v4: Fix dependency reloc as write instead of read (Ville). >> Fix wrong handling of batchbuffer start on ILK causing >> test failure >> >> Cc: Daniel Vetter>> Cc: Ville Syrjälä >> Cc: Chris Wilson >> Signed-off-by: Abdiel Janulgue >> --- >> lib/Makefile.sources | 2 + >> lib/igt.h| 1 + >> lib/igt_dummyload.c | 276 >> +++ >> lib/igt_dummyload.h | 42 > > Did you check that your new docs do show up in the generated > documentation? Iirc you need to edit some xml under docs/. > -Daniel > Yeah I missed that. Updated now to include the docs in generated documentation. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On 17/06/15 12:04, Daniel Vetter wrote: On Fri, Jun 12, 2015 at 09:25:36PM +0100, Dave Gordon wrote: Updated version split into two. The first tidies up the _ring_prepare() functions and removes the corner case where we might have had to wait twice; the second is a temporary workaround to solve a kernel OOPS that can occur if logical_ring_begin is called while the ringbuffer is not mapped because there's no current request. The latter will be superseded by the Anti-OLR patch series currently in review. But this helps with GuC submission, which is better than the execlist path at exposing the problematic case :( Maintainer broken record: Lack of changelog makes it hard to figure out what changed and which patches are the latest version. Even more so when trying to catch up from vacation ... -Daniel Oops, that wasn't ready to go to the mailing list, that was just supposed to go to myself so I could test whether the changes I'd made to my git-format-patch and git-send-email settings worked! Hence lack of subject line :( And the settings obviously /weren't/ right; apart from it going to the list, it didn't have the proper Organisation header, which was the thing I was trying to update, as well as setting up proper definitions so I could write git send-email --identity=external --to=myself ... I think I got them all sorted out before sending the GuC submission sequence though :) .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On Fri, Jun 12, 2015 at 09:25:36PM +0100, Dave Gordon wrote: Updated version split into two. The first tidies up the _ring_prepare() functions and removes the corner case where we might have had to wait twice; the second is a temporary workaround to solve a kernel OOPS that can occur if logical_ring_begin is called while the ringbuffer is not mapped because there's no current request. The latter will be superseded by the Anti-OLR patch series currently in review. But this helps with GuC submission, which is better than the execlist path at exposing the problematic case :( Maintainer broken record: Lack of changelog makes it hard to figure out what changed and which patches are the latest version. Even more so when trying to catch up from vacation ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On Wed, 17 Jun 2015, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Jun 12, 2015 at 09:25:36PM +0100, Dave Gordon wrote: Updated version split into two. The first tidies up the _ring_prepare() functions and removes the corner case where we might have had to wait twice; the second is a temporary workaround to solve a kernel OOPS that can occur if logical_ring_begin is called while the ringbuffer is not mapped because there's no current request. The latter will be superseded by the Anti-OLR patch series currently in review. But this helps with GuC submission, which is better than the execlist path at exposing the problematic case :( Maintainer broken record: Lack of changelog makes it hard to figure out what changed and which patches are the latest version. Even more so when trying to catch up from vacation ... Is it time we adopted Greg's formletter approach with copy-pasted snippets from [1]...? See [2] for an example. BR, Jani. [1] https://github.com/gregkh/gregkh-linux/blob/master/forms/patch_bot [2] http://mid.gmane.org/20150612153842.ga12...@kroah.com -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Updated version split into two. The first tidies up the _ring_prepare() functions and removes the corner case where we might have had to wait twice; the second is a temporary workaround to solve a kernel OOPS that can occur if logical_ring_begin is called while the ringbuffer is not mapped because there's no current request. The latter will be superseded by the Anti-OLR patch series currently in review. But this helps with GuC submission, which is better than the execlist path at exposing the problematic case :( ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
This series is revised based on Jani's good comments. In this series the patch which read out DP link training parameters from VBT is discarded as based on the comments that I received. Files changed: drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_drv.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Addresses the comments and feedback herein. VLV2 and gen4 have separate bit definitions now. The correct bits are selected in gen4x_dp_detect() based on the detected platform. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
On Mon, Dec 30, 2013 at 07:59:49AM +0530, Oravil Nair wrote: Hi, i915_gem_object_pin(), during i915 driver create, seems to write to the memory written by BIOS. Where can the start address be specified to allocate memory so that the memory written by BIOS is not overwritten at initialization? I guess you want Jesse's patches to save the screen contents from the BIOS modeset setup? But tbh I'm not clear at all what exactly you're talking about. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Hi, i915_gem_object_pin(), during i915 driver create, seems to write to the memory written by BIOS. Where can the start address be specified to allocate memory so that the memory written by BIOS is not overwritten at initialization? Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] Hi, saw your posting in [1]... can you try the patches below? Not sure if they apply. Did you try v3.11-rc6(+)... or drm-intel-nightly? Regards, - Sedat - [1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html Same thing observed with v3.11-rc7. Looks like when this happens, external monitor does not work. It shows this message: not optimum mode: recommended mode 1280x1024 60Hz while this is exactly what I configured in xrandr. -- Forwarded message -- From: Sedat Dilek sedat.di...@gmail.com Date: Tue, Jul 2, 2013 at 7:31 AM Subject: Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ] To: Daniel Vetter daniel.vet...@ffwll.ch Cc: Barnes, Jesse jbar...@virtuousgeek.org, Stephen Rothwell s...@canb.auug.org.au, linux-next linux-n...@vger.kernel.org, Linux Kernel Mailing List linux-ker...@vger.kernel.org, intel-gfx intel-gfx@lists.freedesktop.org, DRI dri-de...@lists.freedesktop.org, Dave Airlie airl...@gmail.com On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130628: The regulator tree gained a build failure so I used the version from next-20130628. The trivial tree gained a conflict against the fbdev tree. The arm-soc tree gained a conflict against the net-next tree. The akpm tree lost a few patches that turned up elsewhere and I removed 2 that were causing run time problems. [ CC drm and drm-intel folks ] [ Did not check any relevant MLs ] Please, see attached dmesg output. Clock mismatch, one for Jesse to figure out. Note that this patch is for 3.12, I simply haven't yet gotten around to properly split my patch queue so a few spilled into -next. I'll do that now. I like lightspeed-fast replies :-). Guess drm/i915: get mode clock when reading the pipe config v9 [1] is the cause. Problem solved by applying these patches to next-20130701 from intel-gfx patchwork-service [0]: [1/2] drm/i915: fixup messages in pipe_config_compare [2/2] drm/i915: get clock config when checking CRTC state too AFAICS 2/2 was folded into updated drm/i915: get mode clock when reading the pipe config v9 [3]. It would be kind to be CCed on the patches and get also some credits. Also a CC to the report in linux-next should IMHO be done. - Sedat - [0] https://patchwork.kernel.org/project/intel-gfx/list/ [1] https://patchwork.kernel.org/patch/2809031/ [2] https://patchwork.kernel.org/patch/2809021/ [3] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightlyid=f1f644dc66cbaf5a4c7dcde683361536b41885b9 - Sedat - [1] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queuedid=d325d8b4f351f9d45e7c8baabf581fd21f343133 -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] (no subject)
Hi all, Two things: - Please _always_ include a public mailing list when reporting bugs, your dear maintainer sometimes slacks off. - We need to see the error_state before we can assess what kind of hang you have (it's like gettting a SIGSEGV for a normal program, no two gpu hangs are the same ...). Cheers, Daniel On Wed, Apr 3, 2013 at 5:42 PM, Dihan Wickremasuriya dwickremasur...@rethinkrobotics.com wrote: Hi Chris/Daniel, This is Dihan from Rethink Robotics and we were hoping you could help with the GPU hang problem in the i915 driver mentioned in bug #26345: https://bugs.freedesktop.org/show_bug.cgi?id=26345 We are running into the same problem with the 3.8.5 kernel (which has the fix mentioned in comment #153 of the bug report) when running a Qt 5 application in Gentoo. At times the entire X session would freeze. The x11-perf tests described in the bug report run without any issues though. Would you happen to know whether this is because of an issue in the driver that is not currently being addressed by the fix? I have attached the Xorg log, the dmesg output and i915_error_state from a hung session. Please let me know if you need any more info. Thanks in advance! Best regards, Dihan -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Hi, This is the second verion of the clipping/interpolation patches. Main differences: - I tried to take all of Paul's remarks into account - I exploded the first patch in 4 independant ones - I've added a patch to ensure that integers pass through unscathed Patch 4/9 is (slightly) controversial. There may be better ways to do it, or at least more general ones. But it's simple, it works, and it allows to validate the other 8. It's an easy one to revert if we build an alternative. Best, OG. [PATCH 1/9] intel gen4-5: fix the vue view in the fs. [PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf. [PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection. [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one [PATCH 5/9] intel gen4-5: Compute the interpolation status for every [PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf. [PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the [PATCH 8/9] intel gen4-5: Make noperspective clipping work. [PATCH 9/9] intel gen4-5: Don't touch flatshaded values when ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (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 says modes should be preferred in this order: * - preferred detailed mode * - other detailed modes from base block * - detailed modes from extension blocks * - CVT 3-byte code modes * - standard timing codes * - established timing codes * - modes inferred from GTF or CVT range information * * We get this pretty much right. Not actually so right... We were inferring just using GTF... not CVT or even GTF2. This patch not just add some common cvt modes but also allows some modes been inferred when using gtf2 as well. Cheers, Rodrigo. From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi rodrigo.v...@intel.com Date: Wed, 11 Apr 2012 15:36:31 -0300 Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/drm_edid.c | 37 +- drivers/gpu/drm/drm_edid_modes.h | 101 ++ 2 files changed, 136 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7ee7be1..3179572 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid, return modes; } +static int +drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid, + struct detailed_timing *timing) +{ + int i, modes = 0; + struct drm_display_mode *newmode; + struct drm_device *dev = connector-dev; + + for (i = 0; i drm_num_cvt_inferred_modes; i++) { + if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) { + newmode = drm_mode_duplicate(dev, drm_cvt_inferred_modes[i]); + if (newmode) { + drm_mode_probed_add(connector, newmode); + modes++; + } + } + } + + return modes; +} + static void do_inferred_modes(struct detailed_timing *timing, void *c) { struct detailed_mode_closure *closure = c; struct detailed_non_pixel *data = timing-data.other_data; - int gtf = (closure-edid-features DRM_EDID_FEATURE_DEFAULT_GTF); + int timing_level = standard_timing_level(closure-edid); - if (gtf data-type == EDID_DETAIL_MONITOR_RANGE) + if (data-type == EDID_DETAIL_MONITOR_RANGE) + switch (timing_level) { + case LEVEL_DMT: + break; + case LEVEL_GTF: + case LEVEL_GTF2: closure-modes += drm_gtf_modes_for_range(closure-connector, closure-edid, timing); + break; + case LEVEL_CVT: + closure-modes += drm_cvt_modes_for_range(closure-connector, + closure-edid, + timing); + break; + } } static int diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h index a91ffb1..7e14a32 100644 --- a/drivers/gpu/drm/drm_edid_modes.h +++ b/drivers/gpu/drm/drm_edid_modes.h @@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = { static const int drm_num_dmt_modes = sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode); +static const struct drm_display_mode drm_cvt_inferred_modes[] = { + /* 640x480@60Hz */ + { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750 640, 664, + 720, 800, 0, 480, 483, 487, 500, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 800x600@60Hz */ + { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832, + 912, 1024, 0, 600, 603, 607, 624, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 900x600@60Hz */ + { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992, + 1088, 1216, 0, 600, 603, 609, 624, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 1024x576@60Hz */ + { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064, + 1160, 1296, 0, 576, 579, 584, 599, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 1024x768@60Hz */ + { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072, + 1176, 1328, 0, 768, 771, 775, 798, 0, +
[Intel-gfx] (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 says modes should be preferred in this order: * - preferred detailed mode * - other detailed modes from base block * - detailed modes from extension blocks * - CVT 3-byte code modes * - standard timing codes * - established timing codes * - modes inferred from GTF or CVT range information * * We get this pretty much right. Not actually so right... We were inferring just using GTF... not CVT or even GTF2. This patch not just add some common cvt modes but also allows some modes been inferred when using gtf2 as well. Cheers, Rodrigo. From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi rodrigo.v...@intel.com Date: Wed, 11 Apr 2012 15:36:31 -0300 Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/drm_edid.c | 37 +- drivers/gpu/drm/drm_edid_modes.h | 101 ++ 2 files changed, 136 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7ee7be1..3179572 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid, return modes; } +static int +drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid, + struct detailed_timing *timing) +{ + int i, modes = 0; + struct drm_display_mode *newmode; + struct drm_device *dev = connector-dev; + + for (i = 0; i drm_num_cvt_inferred_modes; i++) { + if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) { + newmode = drm_mode_duplicate(dev, drm_cvt_inferred_modes[i]); + if (newmode) { + drm_mode_probed_add(connector, newmode); + modes++; + } + } + } + + return modes; +} + static void do_inferred_modes(struct detailed_timing *timing, void *c) { struct detailed_mode_closure *closure = c; struct detailed_non_pixel *data = timing-data.other_data; - int gtf = (closure-edid-features DRM_EDID_FEATURE_DEFAULT_GTF); + int timing_level = standard_timing_level(closure-edid); - if (gtf data-type == EDID_DETAIL_MONITOR_RANGE) + if (data-type == EDID_DETAIL_MONITOR_RANGE) + switch (timing_level) { + case LEVEL_DMT: + break; + case LEVEL_GTF: + case LEVEL_GTF2: closure-modes += drm_gtf_modes_for_range(closure-connector, closure-edid, timing); + break; + case LEVEL_CVT: + closure-modes += drm_cvt_modes_for_range(closure-connector, + closure-edid, + timing); + break; + } } static int diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h index a91ffb1..7e14a32 100644 --- a/drivers/gpu/drm/drm_edid_modes.h +++ b/drivers/gpu/drm/drm_edid_modes.h @@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = { static const int drm_num_dmt_modes = sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode); +static const struct drm_display_mode drm_cvt_inferred_modes[] = { + /* 640x480@60Hz */ + { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750 640, 664, + 720, 800, 0, 480, 483, 487, 500, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 800x600@60Hz */ + { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832, + 912, 1024, 0, 600, 603, 607, 624, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 900x600@60Hz */ + { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992, + 1088, 1216, 0, 600, 603, 609, 624, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 1024x576@60Hz */ + { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064, + 1160, 1296, 0, 576, 579, 584, 599, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) }, + /* 1024x768@60Hz */ + { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072, + 1176, 1328, 0, 768, 771, 775, 798, 0, +
[Intel-gfx] (no subject)
http://www.signsandsites.com/wp-content/themes/duotone/nav21.php Muhammad Jamil Sumintar 4/3/2012 11:25:11 AM___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
GIT: [Intel-gfx] [PATCH 1/3] drm/i915: proper use of forcewake GIT: [Intel-gfx] [PATCH 2/3] drm/i915: refcounts for forcewake GIT: [Intel-gfx] [PATCH 3/3] drm/i915: userspace interface to the forcewake refcount ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
GIT: [Intel-gfx] [PATCH 1/4] drm/i915: proper use of forcewake GIT: [Intel-gfx] [PATCH 2/4] drm/i915: refcounts for forcewake GIT: [Intel-gfx] [PATCH 3/4] drm/i915: userspace interface to the forcewake refcount GIT: [Intel-gfx] [PATCH 4/4] drm/i915: optional fewer warning patch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
These are some prep patches I'd like to get feedback on. I've only compile tested them so far (the actual hw support code this is for was tested before the split), so testing would be appreciated as well. Thanks, Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Hi folks, I am a bit new to graphics, but had a few questions that I was hoping that someone could answer for me. I hope this is the right forum to ask these questions. My interest is in seeing whether I can use the Intel integrated graphics part for non-graphics (GPGPU) work, while driving the display through another discrete card. I have an Ironlake system (core setup with base Debian (no X-related packages), a basic PCI-E graphics card (NVIDIA NV37GL) and a 2.6.36 kernel with the following relevant config entries. CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 # CONFIG_VGA_SWITCHEROO is not set CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m CONFIG_DRM_R128=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y I have libdrm libva installed, and was hoping to use libdrm APIs to do some basic operations on the integrated graphics. I can insmod the DRM the DRM_KMS_HELPER module fine, but when trying to insert the I915 driver, I get a no such device error, even though the module object exists. lspci doesn't seem to return the Intel integrated graphics PCI device either. 00:00.0 Host bridge: Intel Corporation Auburndale/Havendale DRAM Controller (rev 02) 00:01.0 PCI bridge: Intel Corporation Auburndale/Havendale PCI Express x16 Root Port (rev 02) 00:16.0 Communication controller: Intel Corporation Ibex Peak HECI Controller (rev 06) 00:16.2 IDE interface: Intel Corporation Ibex Peak PT IDER Controller (rev 06) 00:16.3 Serial controller: Intel Corporation Ibex Peak KT Controller (rev 06) 00:19.0 Ethernet controller: Intel Corporation Device 10f0 (rev 06) 00:1a.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 06) 00:1b.0 Audio device: Intel Corporation Ibex Peak High Definition Audio (rev 06) 00:1d.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation Ibex Peak LPC Interface Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation Ibex Peak 6 port SATA AHCI Controller (rev 06) 00:1f.3 SMBus: Intel Corporation Ibex Peak SMBus Controller (rev 06) 01:00.0 VGA compatible controller: nVidia Corporation NV37GL [Quadro PCI-E Series] (rev a2) 02:02.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08) First off, is there a way for the Intel integrated graphics to appear in the list of PCI devices when it's not being used for driving the display? Secondly, can I simply use the libdrm APIs to directly perform operations on the Intel integrated part? Does there exist any documentation describing the DRM APIs? Finally, can I use the DRM APIs for using the GPU media pipe (architecturally different from the 3D graphics pipe)? Thanks, Hari ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx