The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts.

Every time we go through this we need a
- active object that can be retired
- and there are no other references to that object than the one from
  the active list, so that it gets unbound and freed immediately.
Otherwise the recursion stops. So the recursion is only limited by the
number of objects that fit these requirements sitting in the active list
any time retire_request is called.

Issue exercised by tests/gem_unref_active_buffers from i-g-t.

There's been a decent bikeshed discussion whether it wouldn't be
better to pass around a flag, but imo this is o.k. for such a limited
case that only supports a w/a.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson>
[ickle- we built better bikesheds, but this keeps the rain off for now]
Tested-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Seems like something got mis-merged here.

Noticed by kallisti5 on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are two issues in vmw_kms_update_layout_ioctl().  First, the
for loop forgets to index rects and only checks the first element.
Second, there is a potential integer overflow if userspace passes
in a large arg->num_outputs.  The call to kzalloc() would allocate
a small buffer, leading to out-of-bounds read.
Reported-by: NHaogang Chen <haogangchen@gmail.com>
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43191Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43191Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Disabling the CRTC by setting its framebuffer to NULL, as used by
drm_framebuffer_cleanup(), was failing to pass the current framebuffer
to the crtc_func->disable callback. This is because of the dance within
drm_crtc_helper_set_config to pass the new_fb (NULL in this case) to the
drm_crtc_helper_set_mode with the currently attached fb as a parameter.
drm_crtc_helper_set_mode treats this as a no-op and the encoder is still
enabled. And so the current fb is forgotten before the call to
drm_helper_disable_unused_functions.

This patch treats disabling the CRTC as a simple special case rather
than adding further complexity into the configuration logic.

This fixes a pin-leak of the fb bo on Xserver close.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I am under the impression that it only makes sense to call the ATIF
method if the graphics device has an ACPI handle attached. So we could
skip the call altogether if there is no such handle.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the proper macro to issue the debugging message in
radeon_atif_call(). Otherwise we spam the log of many systems with a
message which looks like an error message of unknown origin, and could
thus confuse the user. Commit dc77de12
was a first step in this direction, but was not sufficient IMHO.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Avoid infinite loops waiting for surface updates if a GPU
reset happens while waiting for a page flip.

See:
https://bugs.freedesktop.org/show_bug.cgi?id=43191Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Reviewed-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Tested-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

NFI why this only started appearing now.  The use of the uninitialised var
can't actually happen, so perhaps my compiler just got stupider.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The entire RAMIN is allocated to be 'size', but the heap is
specified as 'base' + 'size' inside RAMIN, so it will overflow
past RAMIN by 'base' bytes on NV50+ and clobber other allocatons
unless it's size is adjusted.
Signed-off-by: NYounes Manton <younes.m@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Without this, they return bytes written since the last update of
the offset, but we want the full offset.

Trace shows setting this on GPC[0]/TP[0] is enough.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.
Reported-by: NHaogang Chen <haogangchen@gmail.com>
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Split the quirks and i2c_rec assignment into separate
functions used by both radeon_lookup_i2c_gpio() and
radeon_atombios_i2c_init().  This avoids duplicating code
and cases where quirks were only added to one of the
functions.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

I missed this part the first time through.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

An unlikely race could case a bo to be returned reserved on an error path.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds a new optional chunk to the CS ioctl that specifies optional flags
to the CS parser. Why this is useful is explained below. Note that some regs
no longer need the NOP relocation packet if this feature is enabled.
Tested on r300g and r600g with this flag disabled and enabled.

Assume there are two contexts sharing the same mipmapped tiled texture.
One context wants to render into the first mipmap and the other one
wants to render into the last mipmap. As you probably know, the hardware
has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
but that only applies to samplers.
(at least on r300-r500, though later hardware likely behaves the same)

So we want to just re-set the tiling flags before rendering (writing
packets), right? ... No. The contexts run in parallel, so they may
set the tiling flags simultaneously and then fire their command streams
also simultaneously. The last one setting the flags wins, the other one
loses.

Another problem is when one context wants to render into the first and
the last mipmap in one CS. Impossible. It must flush before changing
tiling flags and do the rendering into the smaller mipmaps in another CS.

Yet another problem is that writing copy_blit in userspace would be a mess
involving re-setting tiling flags to please the kernel, and causing races
with other contexts at the same time.

The only way out of this is to send tiling flags with each CS, ideally
with each relocation. But we already do that through the registers.
So let's just use what we have in the registers.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When the brightness property is inquired while the backlight is disabled,
the driver returns a wrong value (zero) because it probes the value after
the backlight was turned off.  This caused a black screen even after the
backlight is enabled again.  It should return the internal backlight_level
instead, so that it won't be influenced by the backlight-enable state.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=41926
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652Tested-by: NKamal Mostafa <kamal@canonical.com>
Cc: Alex Davis <alex14641@yahoo.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NKeith Packard <keithp@keithp.com>

A call to i915_add_request() has been made in function i915_gem_busy_ioctl(). i915_add_request can fail,
so in it's exit path previously allocated memory needs to be freed.
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The BIOS VBT value for an eDP panel has been shown to be incorrect on
one machine, and we haven't found any machines where the DPCD value
was wrong, so we'll use the DPCD value everywhere.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Limit the link training setting command to the lanes needed for the
current mode. It seems vaguely possible that a monitor will try to
train the other lanes and fail in some way, so this seems like the
safer plan.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Found a couple of bare tabs in intel_dp.c
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Make sure the sequence of operations in all three functions makes
sense:

 1) The backlight must be off unless the screen is running
 2) The link must be running to turn the eDP panel on/off
 3) The CPU eDP PLL must be running until everything is off
Signed-off-by: NKeith Packard <keithp@keithp.com>

The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

No persistent data was ever stored here, so link_status is instead
allocated on the stack as needed.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.

No functional changes.
Signed-off-by: NKeith Packard <keithp@keithp.com>

- exynos_drm_buf_create() returns err pointer so NULL check is wrong.
- Case that exynos_gem_obj is not created, destroy call in exception
  handle lable uses this pointer. so instead buffer is directly used.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

In case that vblank_disable_allowed is 1, the problem that manager->pipe
could be -1 at vsync interrupt handler could be induced so this patch fixes
that.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

the purpose of this patch is to consider IOMMU support in the future.
EXYNOS4 SoC supports IOMMU also so the address for DMA could be
physical address with IOMMU or device address with IOMMU.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>