This ensures that there are no concurrency issues when multiple users
are trying to use VIC concurrently, and also simplifies the code
slightly.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/vic.c | 47 +++--
1 file changed, 20 insertions(+), 27
The size of a single channel's aperture is different on Tegra186 vs.
previous chips. Parameterize the value using a new define in the
register definition headers.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/hw/channel_hw.c | 3 +--
drivers/gpu/host1x/hw/hw_host1x01_channel.h |
With the new channel allocation model, multiple threads can be
allocating channels simultaneously. Therefore we need to add a lock
around the code.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/channel.c | 7 +++
drivers/gpu/host1x/channel.h | 2 ++
2 files changed, 9 insertions(+)
Add support for dumping current MLOCK state in debug dumps also
on T186, now that MLOCKs are used by the driver.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/hw/debug_hw_1x06.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/hw/d
To allow client drivers to free resources when jobs have completed,
deliver job completion callbacks to them. This requires adding
reference counting to context objects, as job completion can happen
after the userspace application has closed the context. As such,
also add kref-based refcounting for
In the traditional channel allocation model, a single hardware channel
was allocated for each client. This is simple from an implementation
perspective but prevents use of hardware scheduling.
This patch implements a channel allocation model where when a user
submits a job for a context, a hardwar
Host1x has a feature called MLOCKs which allow a certain class
(~HW unit) to be locked (in the mutex sense) and unlocked during
command execution, preventing other channels from accessing the
class while it is locked. This is necessary to prevent concurrent
jobs from messing up class state.
This h
Allow job submitters to set a callback to be called when the job has
completed. The jobs are stored and the callbacks called outside the
CDMA lock area to allow the callbacks to do CDMA-requiring operations
like freeing channels.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/cdma.c | 44
As a preparation for each context potentially being able to have a
separate hardware channel, and thus requiring a separate syncpoint,
move syncpoints to be stored inside each context instead of global
client data.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 8
dri
Add an option to host1x_channel_request to interruptibly wait for a
free channel. This allows IOCTLs that acquire a channel to block
the userspace.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 9 +
drivers/gpu/drm/tegra/gr2d.c | 6 +++---
drivers/gpu/drm/tegra/gr3d
Hi all,
this adds support for a new model of hardware channel allocation for
Host1x/TegraDRM. In the current model, one hardware channel is
allocated for each client device at probe time. This is simple but
does not allow for optimal use of hardware resources.
In the new model, we allocate channe
From: Colin Ian King
The variable len is assigned but never read, therefore it is redundant
and can be removed. Cleans up clang warning:
drivers/video/backlight/ili922x.c:276:2: warning: Value stored to 'len'
is never read
Signed-off-by: Colin Ian King
---
drivers/video/backlight/ili922x.c |
From: Markus Elfring
Date: Sun, 5 Nov 2017 14:00:52 +0100
Add a jump target so that a specific error message is stored only once
at the end of this function implementation.
Replace two calls of the function "dev_err" by goto statements.
This issue was detected by using the Coccinelle software.
https://bugs.freedesktop.org/show_bug.cgi?id=103576
--- Comment #1 from Christian König ---
IIRC the ASIC is identical, just configuration parameter like amount of video
memory and clocks are different.
As you can see on the lspci output even the PCI-IDs are the same. So why should
amdgpu differ
Hi Noralf,
On Sat, Nov 04, 2017 at 02:03:58PM +0100, Noralf Trønnes wrote:
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also us
On Sat, Nov 04, 2017 at 02:04:13PM +0100, Noralf Trønnes wrote:
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also use the drm_fb
From: Markus Elfring
Date: Sun, 5 Nov 2017 14:54:52 +0100
Add a jump target so that a bit of exception handling can be better reused
at the end of this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/dnfb.c | 13 +++
tree: git://people.freedesktop.org/~gabbayo/linux amdkfd-next
head: c0307884529de823406fb17daf477f6af34ca5e5
commit: 88bd109688cf71dac908e5a06915996ee79fcef6 [5/8] drm/amdgpu: Add support
for resuming SDMA queues w/o HWS
config: i386-randconfig-s0-201745 (attached as .config)
compiler: gcc-6 (
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #35 from har...@gmx.de ---
(In reply to Thomas Hellström from comment #34)
> (In reply to haro41 from comment #33)
> > No freezes, works great for me.
>
> Want to add a Tested-by: tag?
>
> /Thomas
... if it helps, but where and how
Hi Dave,
A few more fixes for 4.15.
The following changes since commit bf6eb600e5b835a96d676b2b9df603362a1e714c:
Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-next
(2017-11-03 09:17:08 +1000)
are available in the git repository at:
git://people.freedesktop.org/~agd5
https://bugs.freedesktop.org/show_bug.cgi?id=103576
Alex Deucher changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
On Sunday, November 5, 2017 6:53 AM, Colin King wrote:
>
> From: Colin Ian King
>
> The variable len is assigned but never read, therefore it is redundant
> and can be removed. Cleans up clang warning:
>
> drivers/video/backlight/ili922x.c:276:2: warning: Value stored to 'len'
> is never read
>
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #36 from Thomas Hellström ---
(In reply to haro41 from comment #35)
> (In reply to Thomas Hellström from comment #34)
> > (In reply to haro41 from comment #33)
> > > No freezes, works great for me.
> >
> > Want to add a Tested-by: t
Hi Marek,
2017년 11월 03일 21:28에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
>
> On 2017-11-01 07:26, Inki Dae wrote:
>> 2017년 10월 23일 16:54에 Marek Szyprowski 이(가) 쓴 글:
>>> Some hardware modules, like FIMC in Exynos4 series are shared between
>>> V4L2 (camera support) and DRM (memory-to-memory processing
2017-11-03 20:35 GMT+08:00 Rob Herring :
> On Thu, Nov 2, 2017 at 11:45 PM, Chih-Wei Huang
> wrote:
>> The file contains rules that are executed on incremental builds.
>> Since commit 4f7dc9b6 the library was moved to /vendor so
>> the old file must be removed.
>>
>> Signed-off-by: Chih-Wei Huang
https://bugs.freedesktop.org/show_bug.cgi?id=102800
--- Comment #10 from higu...@gmx.net ---
So will kernel 4.14 will bring any fix to this? or you need more info about my
system?
--
You are receiving this mail because:
You are the assignee for the bug.___
On 11/01/2017 07:51 PM, Jani Nikula wrote:
drm_add_edid_modes() now fills in the ELD automatically, so the calls to
drm_edid_to_eld() are redundant. Remove them.
All the other places are obvious, but nv50 has detached
drm_edid_to_eld() from the drm_add_edid_modes() call.
For the bridge drive
Hi Vijendar,
Below is the patch from Guenter Roeck to fix build
errors on 32 bit.
Regards,
Akshu
From 3aa3a8549e986d860300e0623d048ec93482da19 Mon Sep 17 00:00:00 2001
From: Guenter Roeck
Date: Fri, 22 Sep 2017 09:43:27 -0700
Subject: [PATCH] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_p
https://bugs.freedesktop.org/show_bug.cgi?id=103544
--- Comment #10 from Ilia Mirkin ---
(In reply to Ilia Mirkin from comment #9)
> Created attachment 135237 [details] [review]
> enable simple_float logic for blending
>
> Entirely untested (not even compiled) patch to force blending to be 0*NaN
On Sat, Nov 04, 2017 at 10:16:23AM +0100, walter harms wrote:
>
>
> Am 04.11.2017 07:12, schrieb Dan Carpenter:
> > The if statement wasn't indented so it makes static analysis tools and
> > probably very recent GCC versions complain.
> >
> > Signed-off-by: Dan Carpenter
> > ---
> > I went over
Static analysis tools get annoyed that we don't indent this if
statement. Actually, the if statement isn't required because kfree()
can handle NULL pointers just fine. The DCE110STRENC_FROM_STRENC()
macro is a wrapper around container_of() but it's basically a no-op or a
cast. Anyway, it's not r
On 03.11.2017 18:01, Andrey Gusakov wrote:
> Do not fail data rates higher than 2.7 and more than 2 lanes.
> Try to fall back to 2.7Gbps and 2 lanes.
> ---
> drivers/gpu/drm/bridge/tc358767.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/
On 03.11.2017 18:01, Andrey Gusakov wrote:
> Minimum pixel clock period is 6.5 nS for DPI. Do not accept modes
> with lower pixel clock period.
> ---
> drivers/gpu/drm/bridge/tc358767.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767
On Sat, Nov 04, 2017 at 02:04:08PM +0100, Noralf Trønnes wrote:
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also use the drm_fb
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #13 from d...@jerber.co.uk ---
Hi,
It is still a problem. I detailed the card in comment 8 (HD 4890). Could you
advise what other information you would need about the GPU?
Thanks.
--
You are receiving this mail because:
You are the
On Fri, Nov 03, 2017 at 10:10:26AM +0700, Nhan Nguyen wrote:
> From: John Stultz
>
> commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream.
>
> In chasing down issues with EDID probing, I found some
> duplicated but incomplete logic used to power the chip on and
> off.
>
> This patch refacto
On 03.11.2017 18:01, Andrey Gusakov wrote:
> This set of patches fixes several issues that was found during testing
> tc358767 with desktop DisplayPort displays.
>
> Changes in V2:
> - fixed maximum pixelclock frequency
> - copyright patch added
>
> Andrey Gusakov (7):
> drm/bridge: t
37 matches
Mail list logo
