Hi Tomi,
On Tuesday 20 Sep 2016 16:27:22 Tomi Valkeinen wrote:
> On 19/09/16 15:27, Laurent Pinchart wrote:
> > As the FIFO underflow IRQ handler just prints an error message to the
> > kernel log, simplify the code by not registering one IRQ handler per
> > plane but print the messages directly f
Hi Tomi,
On Tuesday 20 Sep 2016 15:47:57 Tomi Valkeinen wrote:
> On 19/09/16 15:27, Laurent Pinchart wrote:
> > The driver stores in a custom structure named format several pieces of
> > information about the format that are available in the DRM core. Remove
> > them and get the information from t
*
>>> * *** Build context (function also used for validation)
>>> **/
>>> result = core_dc->res_pool->funcs->validate_with_context(
>>> core_dc,set,target_count,context);
>>>
>>> /**
>>> * *** Apply safe power state
>>> **/
>>> pplib_apply_safe_state(core_dc);
>>>
>>> /
>>> * *** Apply the context to HW (program HW)
>>> /
>>> result = core_dc->hwss.apply_ctx_to_hw(core_dc,context)
>>> {
>>> /* reset pipes that need reprogramming */
>>> /* disable pipe power gating */
>>> /* set safe watermarks */
>>>
>>> /* for all pipes with an attached stream */
>>> /
>>> * *** Programming all per-pipe contexts
>>> /
>>> status = apply_single_controller_ctx_to_hw(...)
>>> {
>>> pipe_ctx->tg->funcs->set_blank(...);
>>> pipe_ctx->clock_source->funcs->program_pix_clk(...);
>>> pipe_ctx->tg->funcs->program_timing(...);
>>> pipe_ctx->mi->funcs->allocate_mem_input(...);
>>> pipe_ctx->tg->funcs->enable_crtc(...);
>>> bios_parser_crtc_source_select(...);
>>>
>>> pipe_ctx->opp->funcs->opp_set_dyn_expansion(...);
>>> pipe_ctx->opp->funcs->opp_program_fmt(...);
>>>
>>> stream->sink->link->link_enc->funcs->setup(...);
>>> pipe_ctx->stream_enc->funcs->dp_set_stream_attribute(...);
>>> pipe_ctx->tg->funcs->set_blank_color(...);
>>>
>>> core_link_enable_stream(pipe_ctx);
>>> unblank_stream(pipe_ctx,
>>>
>>> program_scaler(dc, pipe_ctx);
>>> }
>>> /* program audio for all pipes */
>>> /* update watermarks */
>>> }
>>>
>>> program_timing_sync(core_dc, context);
>>> /* for all targets */
>>> target_enable_memory_requests(...);
>>>
>>> /* Update ASIC power states */
>>> pplib_apply_display_requirements(...);
>>>
>>> /* update surface or page flip */
>>> }
>>> }
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
-- next part --
A non-text attachment was scrubbed...
Name: DAL3.JPG
Type: image/jpeg
Size: 117556 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/0323c37c/attachment-0001.jpe>
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the rem
On Dec 12 2016 21:55, Takashi Iwai wrote:
> On Mon, 12 Dec 2016 13:12:16 +0100,
> Takashi Sakamoto wrote:
>>
>> On Dec 12 2016 18:54, Takashi Iwai wrote:
>> +enum hdmi_codec_cea_spk_placement {
>> +FL = (1 << 0),/* Front Left */
>> +FC = (1 << 1),
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/29abf44b/attachment-0001.html>
t
input. We had to clean up linux style for them everytime we pull. Our
HW diagnostic suite has different set of requirements and they
frequently contribute to our code. We took you and Jerome's patch. If
it's validated we want that code.
At end of the day I think the architectur
goto done;
>
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/ec688820/attachment-0001.sig>
On 2016-12-11 03:28 PM, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
>> We propose to use the Display Core (DC) driver for display support on
>> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
>> avoid a flag day the plan is to
On Dec 12 2016 18:54, Takashi Iwai wrote:
+enum hdmi_codec_cea_spk_placement {
+ FL = (1 << 0),/* Front Left */
+ FC = (1 << 1),/* Front Center */
+ FR = (1 << 2),/* Front Right */
+ FLC = (1 << 3),/* Fro
On 2016-12-12 02:22 AM, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
>> Current version of DC:
>>
>> *
>> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>>
>> Once Alex pulls in the latest patches:
>>
>> *
On 2016å¹´12æ12æ¥ 18:38, Arnaud Pouliquen wrote:
>>> + */
>>> +static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
>>> +/* channel: 7 6543 210 */
>>> +{ .ca_index = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR,
>>>
Hi Dave,
Apologies for waking you up with the RFC on a Friday morning. I'll try
to time big stuff better next time.
A couple of thoughts below after having some discussions internally. I
think Tony might add to some of them or provide his own.
On 2016-12-11 09:57 PM, Dave Airlie wrote:
> On 8
On Mon, Dec 12, 2016 at 05:41:08PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Previously we were returning garbage here, fix it by setting it to -1
> before the first possible point of failure.
The convention is that on error paths you do not modify user inputs. In
particular, con
Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it
only gives VGA resolution on screen. Use the same chipset as nv134
then it shows FullHD. This commit copies fields from nv134_chipset
to nv136_chipset for GTX 1060.
Signed-off-by: Chris Chiu
---
drivers/gpu/drm/nouveau/nvkm/engi
2016-12-12 Chris Wilson :
> On Mon, Dec 12, 2016 at 05:41:08PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Previously we were returning garbage here, fix it by setting it to -1
> > before the first possible point of failure.
>
> The convention is that on error paths you do n
Hello,
On Monday 12 Dec 2016 10:45:47 Rob Herring wrote:
> On Wed, Dec 07, 2016 at 11:42:43AM +0100, Bartosz Golaszewski wrote:
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required to
> > make it work.
>
From: Gustavo Padovan
To reflect the (backward compatible) changes in the uabi we are bumping
the driver's version.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv
From: Gustavo Padovan
On the out-fence side we get fence returned by the submitted draw call
and attach it to a sync_file and send the sync_file fd to userspace. On
error -1 is returned to userspace.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 51 +++
From: Gustavo Padovan
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd and wait on it before submitting the draw call.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 41 ++
1 file changed,
From: Gustavo Padovan
Add a new field called fence_fd that will be used by userspace to send
in-fences to the kernel and receive out-fences created by the kernel.
This uapi enables virtio to take advantage of explicit synchronization of
dma-bufs.
There are two new flags:
* VIRTGPU_EXECBUF_FENC
From: Gustavo Padovan
Refactor fence creation to remove the potential allocation failure from
the cmd_submit and atomic_commit paths. Now the fence should be allocated
first and just after we should proceed with the rest of the execution.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virt
static const struct snd_kcontrol_new hdmi_controls[] = {
{
.access = SNDRV_CTL_ELEM_ACCESS_READ |
@@ -79,6 +400,17 @@ static const struct snd_kcontrol_new hdmi_controls[] =
{
.info = hdmi_eld_ctl_info,
.get = hdmi_eld_ctl_get,
From: Gustavo Padovan
Previously we were returning garbage here, fix it by setting it to -1
before the first possible point of failure.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/msm_gem_submit.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
From: Gustavo Padovan
virtio was missing this call to clean up core plane usage.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index
From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Ah, yeah, great to see the silly implementation being replaced the
> radix tree. ida_pre_get() looks suspicious tho. idr_preload()
> immedicately being followed by idr_preload_end() probably is broken.
> Maybe what we need is movi
On 12 December 2016 at 15:07, Jonathan Gray wrote:
> On Mon, Dec 12, 2016 at 02:10:31PM +, Emil Velikov wrote:
>> On 10 December 2016 at 05:52, Jonathan Gray wrote:
>> > When constructing a path to a device node the minor number retrieved
>> > from fstat needs to have the offset of the node t
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> The range restriction should be applied after the color adjustment, or
> else we may inadvertently apply the color adjustment to the restricted
> hole (and not against its neighbours).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lah
> -Original Message-
> From: Luke A. Guest [mailto:laguest at archeia.com]
> Sent: Monday, December 12, 2016 11:17 AM
> To: Deucher, Alexander; 'Daniel Vetter'; Bridgman, John
> Cc: Grodzovsky, Andrey; Cheng, Tony; amd-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org
> Su
On 12/12/16 15:28, Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
>> Of Daniel Vetter
>> Sent: Monday, December 12, 2016 4:27 AM
>> To: Bridgman, John
>> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-devel at lists.fre
On 12/12/2016 03:05 PM, Takashi Sakamoto wrote:
> On Dec 12 2016 21:55, Takashi Iwai wrote:
>> On Mon, 12 Dec 2016 13:12:16 +0100,
>> Takashi Sakamoto wrote:
>>>
>>> On Dec 12 2016 18:54, Takashi Iwai wrote:
>>> +enum hdmi_codec_cea_spk_placement {
>>> + FL = (1 << 0),/* F
Thierry ---
Correct, and this is no longer needed.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/529cd99a/attachment-0
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Monday, December 12, 2016 4:27 AM
> To: Bridgman, John
> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-devel at lists.freedesktop.org; amd-
> gfx at lists.freedesktop.org;
On 12/12/2016 01:03 PM, Takashi Sakamoto wrote:
> On 2016å¹´12æ12æ¥ 18:38, Arnaud Pouliquen wrote:
+ */
+static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
+/* channel: 7 6543 21
0 */
+{ .ca_ind
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/958e30e4/attachment.html>
.c and .h source files should not be executable, change
the permissions to 0644.
Signed-off-by: Joe Perches
Acked-by: David Howells
---
Linus, Andrew Morton suggested privately that you apply this
directly as his toolchain doesn't support
rename/permission only patches.
Apparently, Andrew hasn
On 10 December 2016 at 05:52, Jonathan Gray wrote:
> When iterating over all the device nodes if drmProcessPciDevice()
> returned an error for any node the function would return an error,
> ignoring any valid nodes.
>
> The result of this on OpenBSD where drmProcessPciDevice() results in
> device
Hi,
On 11/29/2016 10:34 AM, John Stultz wrote:
> Wanted to send out v2 of this patch set improving the EDID
> probing on the adv7511 used on HiKey.
>
> The first three patches are fixups that are hopefully straight
> forward, integrating feedback I got from Laurant.
>
> One of the previous patches
On 10 December 2016 at 05:52, Jonathan Gray wrote:
> When constructing a path to a device node the minor number retrieved
> from fstat needs to have the offset of the node type subtracted from it.
> Control and render node types have the same major as the primary node
> but each has their own bloc
On 11 December 2016 at 18:03, Grazvydas Ignotas wrote:
> xf86drm.c:3601:21: warning: comparison between signed and unsigned integer
> expressions [-Wsign-compare]
> while (expected < sizeof(match)) {
> ^
>
Pushed to master.
Thanks !
Emil
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
http://processors.wiki.ti.com/index.ph
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
---
arch/arm/boot/dts/da850-lcdk.dts | 67 +
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
---
.../bindings/display/bridge/ti,ths8135.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3
>
>>This code needs rewriting, not cleaning, not polishing, it needs to be
>>split into its constituent parts, and reintegrated in a form more
>>Linux process friendly.
>
>
> Can we say "restructuring" just for consistency with Daniel's message (the
> HW-dependent bits don't need to be rewritten bu
On 11 December 2016 at 18:03, Grazvydas Ignotas wrote:
> Just tell the compiler that drm_event will alias the char buffer,
> so that it has no excuse to warn or generate bad code.
>
Afacit this patch [1] from Thierry should correctly address the issue, correct ?
I've been meaning to parse through
On Mon, 12 Dec 2016 13:12:16 +0100,
Takashi Sakamoto wrote:
>
> On Dec 12 2016 18:54, Takashi Iwai wrote:
> +enum hdmi_codec_cea_spk_placement {
> +FL = (1 << 0),/* Front Left */
> +FC = (1 << 1),/* Front Center */
> +
t;
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/9d919df0/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/a98c3dbd/attachment.html>
Am 12.12.2016 um 12:53 schrieb Chris Wilson:
> In places (e.g. i915.ko), the alignment is exported to userspace as u64
> and there now exists hardware for which we can indeed utilize a u64
> alignment. As such, we need to keep 64bit integers throughout when
> handling alignment.
>
> Testcase: igt/d
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/c42f02d0/attachment-0001.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/f72d39bb/attachment.html>
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
v9: Have intel_display_cr
patch help with the issue?
Best regards,
Jyri
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-tilcdc-Send-pendig-vblank-event-before-recovery-.patch
Type: text/x-patch
Size: 1489 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/b3f8c50b/attachment.bin>
On 10 December 2016 at 21:52, Daniel Vetter wrote:
> No one looks at the major/minor versions except the unique/busid
> stuff. If we protect that with the master_mutex (since it also affects
> the unique of each master, oh well) we can mark these two IOCTL with
> DRM_UNLOCKED.
>
> While doing this
2016-12-12 12:26 GMT+01:00 Jyri Sarha :
> On 12/05/16 19:07, Bartosz Golaszewski wrote:
>> 2016-12-05 12:01 GMT+01:00 Bartosz Golaszewski > baylibre.com>:
>>> Hi Jyri,
>>>
>>> I pulled your recent tilcdc pull request on top of v4.9 and Sekhar's
>>> davinci branch (+ vga dac DT)[1].
>>>
>>> I'm gett
Hello, Matthew.
On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote:
> I know the preload followed by preload_end looks wrong. I don't
> think it's broken though. If we get preempted, then the worst
> situation is that we'll end up with the memory we preallocated being
> allocated to
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors
on HiKey.
Investigating further, it seems some of the register state
in the regmap cache is somehow getting lost. Using the logic
in __adv7511_power_on/off() which syncs and dirtys
In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.
This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
From: Archit Taneja
On some adv7511 implementations, we can get some spurious
disconnect signals which can cause monitor probing to fail.
This patch enables HPD (hot plug detect) interrupt support
which allows the monitor to be properly re-initialized when
the spurious disconnect signal goes awa
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.
Thus this patch replaces drm_helper_hpd_irq_event() with
drm_kms_helper_hotpl
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.
Digging deeper, I found this was due to the fact that
IRQs were disabled as we were running in IRQ context from
the HPD signal.
Wanted to send out v3 of this patch set improving the EDID
probing on the adv7511 used on HiKey.
The first three patches are fixups that are hopefully straight
forward, integrating feedback I got from Laurant.
The last two patches try to clean up and resue code to avoid
an issue I'm seeing where
On 8 December 2016 at 12:02, Harry Wentland wrote:
> We propose to use the Display Core (DC) driver for display support on
> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
> avoid a flag day the plan is to only support uGPU initially and transition
> to older ASICs gr
Hi,
On 05-12-16 14:23, Hans de Goede wrote:
> Hi,
>
> On 05-12-16 11:59, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 05-12-16 08:46, Thierry Reding wrote:
On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote:
> The pr
omap_crtc_vblank_irq(crtc);
> }
>
Did you look at the code you have above =).
I think the bottom change is a good one. Just remove pipe2vbl().
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/c53352e9/attachment.sig>
Hi Tomi,
On Tuesday 27 Sep 2016 15:24:47 Tomi Valkeinen wrote:
> On 19/09/16 15:27, Laurent Pinchart wrote:
> > The vblank interrupt is disabled after one occurrence, preventing the
> > atomic update event from being processed twice. However, this also
> > prevents the software frame counter from
On Wed, Dec 7, 2016 at 11:26 PM, Caesar Wang wrote:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Read the panel edid information;
>
> EDID MODE DETAILS
> name
Hi Daniel,
On Tuesday 27 Sep 2016 23:05:20 Daniel Kurtz wrote:
> On Mon, Sep 19, 2016 at 8:27 PM, Laurent Pinchart wrote:
> > The vblank interrupt is disabled after one occurrence, preventing the
> > atomic update event from being processed twice. However, this also
> > prevents the software frame
Hello,
On Fri, Dec 09, 2016 at 02:01:40PM -0800, Andrew Morton wrote:
> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes rasmusvillemoes.dk> wrote:
>
> > TL;DR: these patches save 250 KB of memory, with more low-hanging
> > fruit ready to pick.
> >
> > While browsing through the lib/idr.c co
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 89
2 files
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
Using mm->color_adjust makes the eviction scanner much tricker since we
don't know the actual neighbours of the target hole until after it is
created (after scanning is complete). To work out whether we need to
evict the neighbours because they impact upon the hole, we have to then
check the hole a
Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
after drm_mm_scan_add_block() we can further simplify the list
manipulations when generating the temporary scan-hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 22 +-
include/drm/drm_mm.h
For power-of-two alignments, we can avoid the 64bit divide and do a
simple bitwise add instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers
Compute the minimal required hole during scan and only evict those nodes
that overlap. This enables us to reduce the number of nodes we need to
evict to the bare minimum.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 60 +++--
drivers/gpu/d
The range restriction should be applied after the color adjustment, or
else we may inadvertently apply the color adjustment to the restricted
hole (and not against its neighbours).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file changed, 9 insertions(+), 6 d
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
include/drm/drm_mm.h
Acknowledging that we were building up the hole was more useful to me
when reading the code, than knowing the relationship between this node
and the previous node.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
dif
The scan state occupies a large proportion of the struct drm_mm and is
rarely used and only contains temporary state. That makes it suitable to
moving to its struct and onto the stack of the callers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 128 ++
Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and
validation checking using BUG_ON. Ideally these paths should all be
exercised by CI selftests (with the asserts enabled).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 45 +++--
To test whether there are any nodes allocated within the range manager,
we merely have to ask whether the node_list is empty.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 19 +--
include/drm/drm_mm.h | 14 +-
2 files changed, 14 insertions(+), 19 del
Mark up the pointers as constant through the API where appropriate.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 20 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 2 +-
include/drm/drm_mm.h
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/align64
Testcase: igt/gem_exec_alignment
Signed-of
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 597648c7a645..5
Check that after applying the driver's color adjustment, restricted
eviction scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 205 +++
2 files changed, 206 i
Check that after applying the driver's color adjustment, eviction
scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 198 +++
2 files changed, 199 insertions(+
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 183 +++
2 files changed,
Check that if we request top-down allocation with a particular alignment
from drm_mm_insert_node() that the start of the node matches our
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 92 ++
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 97
2 files cha
Check that we add arbitrary blocks to a restrited eviction scanner in
order to find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 189 ++
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 252 +++
2 fil
Check that we can request alignment to any power-of-two or prime using a
plain drm_mm_node_insert(), and also handle a reasonable selection of
primes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_mm.c | 104
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 188 +++
2 files changed, 189 insertions(+)
Reuse drm_mm_insert_node() with a temporary node to exercise
drm_mm_replace_node(). We use the previous test in order to exercise the
various lists following replacement.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 209 +++
2 fil
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 132
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing struct drm_mm alignment computations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/lib/drm_pr
1 - 100 of 136 matches
Mail list logo
